프롬프트 엔지니어링은 AI에게 주는 지시문을 고쳐서 결과를 원하는 쪽으로 맞추는 일입니다. 결론부터 말하면 요령은 많지 않습니다. 새로 온 유능한 직원에게 일을 맡기듯 구체적으로 쓰고, 규칙에는 이유를, 형식에는 예시를 붙이고, 원하는 출력 모양을 정해 주는 것이 Anthropic·OpenAI·구글 공식 가이드가 공통으로 말하는 핵심입니다. 이 글은 2026년 10월 12일 기준 세 회사의 공식 문서만 근거로, 바로 써먹을 수 있는 6가지와 프롬프트로는 안 풀리는 경우를 정리했습니다.
프롬프트 엔지니어링이란 정확히 무엇을 하는 일인가요?
모델을 다시 학습시키지 않고, 입력 문장만 바꿔서 결과의 정확도와 일관성을 높이는 작업입니다. 모델을 예시 데이터로 추가 학습시키는 쪽은 파인튜닝이라고 부르며, 프롬프트로 해결되지 않을 때 검토합니다. 같은 모델이라도 "보고서 써 줘"와 "지난달 매출 표를 보고, 팀장에게 보낼 5줄 요약을 써 줘"는 전혀 다른 결과를 냅니다.
Anthropic 문서는 시작 전에 세 가지를 갖추라고 합니다. 무엇이 성공인지에 대한 기준, 그 기준으로 결과를 확인할 방법, 그리고 고칠 첫 초안입니다. 막연히 "더 좋게"를 목표로 프롬프트를 고치면 무엇이 나아졌는지 알 수 없기 때문입니다. 업무에 쓰는 프롬프트라면 대표 질문 5~10개를 정해 두고, 고칠 때마다 같은 질문으로 결과를 비교하는 습관부터 들이는 것이 좋습니다.
공식 가이드가 공통으로 말하는 원칙은 무엇인가요?
세 회사의 문서를 나란히 놓으면 표현은 달라도 내용은 거의 같습니다.
1. 맥락 없는 새 직원에게 설명하듯 구체적으로
Anthropic은 Claude를 유능하지만 우리 회사 규칙과 업무 방식을 모르는 새 직원으로 생각하라고 합니다. 이 문서가 '황금률'로 꼽는 확인법도 단순합니다. 내 프롬프트를 일의 배경을 모르는 동료에게 보여 주고 그대로 해 보라고 했을 때 동료가 헷갈린다면, AI도 헷갈립니다. 구글 가이드도 첫 항목이 "명확하고 구체적인 지시"입니다.
2. 규칙에는 이유를 붙인다
"절대 말줄임표를 쓰지 마"보다 "이 답변은 음성 합성(TTS)으로 읽히니, 읽을 수 없는 말줄임표는 쓰지 마"가 더 잘 지켜진다는 것이 Anthropic 문서의 예시입니다. 이유를 알면 모델이 비슷한 다른 상황까지 알아서 맞춥니다.
3. 하지 말 것보다 할 것을 말한다
"마크다운을 쓰지 마" 대신 "이어지는 문단으로 써 줘"처럼 원하는 결과를 직접 말하는 쪽이 효과적이라고 Anthropic은 안내합니다. 금지만 나열하면 모델은 무엇을 해야 할지 추측해야 합니다.
4. 예시를 3~5개 보여 준다
예시(퓨샷)는 형식과 말투를 맞추는 가장 확실한 방법입니다. Anthropic은 3~5개를 권하고, 예시가 지시와 섞이지 않게 태그로 감싸라고 합니다. 구글은 아예 "예시를 항상 넣으라"고 권하면서도, 너무 많으면 결과가 예시에 과하게 맞춰질 수 있으니 형식을 일정하게 유지하라고 주의를 줍니다.
5. 구조를 나눠 쓴다
긴 프롬프트는 역할, 자료, 지시, 예시를 구분해야 모델이 덜 헷갈립니다. Anthropic은 <instructions>, <context> 같은 XML 태그를, OpenAI는 마크다운 제목과 XML을 함께 쓰라고 합니다. OpenAI 문서는 개발자 메시지를 정체성(목적·말투), 지시, 예시, 맥락으로 나누는 구성을 예로 듭니다.
6. 출력 형식을 정해 준다
표, 번호 목록, 글자 수, JSON처럼 원하는 결과의 모양을 명시합니다. 구글 문서는 "한 문장으로 요약"처럼 길이 제약을 거는 예를 들고, 시스템 지시로 기본 문체를 정해 둘 수 있다고 설명합니다.
고치기 전과 후는 어떻게 다른가요?
실무에서 자주 쓰는 요청 하나를 위 원칙대로 고쳐 보겠습니다.
고치기 전
이 고객 문의에 답장 써 줘.
고친 후
<role>당신은 온라인 쇼핑몰의 고객 응대 담당자입니다.</role>
<context>
고객은 주문한 지 5일이 지났는데 배송이 안 왔다고 문의했습니다.
우리 쇼핑몰의 기본 배송 기간은 영업일 기준 3~5일입니다.
</context>
<instructions>
1. 불편을 겪은 점에 먼저 사과합니다.
2. 배송 조회 방법을 안내합니다.
3. 내일까지 도착하지 않으면 다시 연락 달라고 요청합니다.
답장은 고객이 휴대폰으로 읽으니 5문장 이내로 짧게 씁니다.
</instructions>
바뀐 점은 역할, 상황 정보, 순서가 있는 지시, 그리고 짧게 써야 하는 이유입니다. 예시 답장 2~3개를 <example> 태그로 덧붙이면 말투까지 맞출 수 있습니다. 자주 쓰는 지시는 매번 붙여 넣지 말고 클로드 프로젝트의 지침이나 챗GPT의 맞춤 설정에 저장해 두면 편합니다.
클로드·챗GPT·제미나이 가이드는 무엇이 다른가요?
| 항목 | Anthropic(클로드) | OpenAI(챗GPT) | 구글(제미나이) |
|---|---|---|---|
| 예시 | 3~5개 권장, 태그로 감싸기 | 다양한 입력·출력 예시 | 항상 넣기 권장, 과다 주의 |
| 구조화 | XML 태그 | 마크다운 + XML | 접두어, 응답 형식 지정 |
| 긴 자료 위치 | 맨 위에, 질문은 맨 끝 | 맥락은 끝 쪽 | 별도 언급 없음 |
| 단계 나누기 | 초안→검토→수정 체이닝 | 별도 언급 없음 | 프롬프트 분할·연결 |
| 특이 사항 | 최신 모델은 응답 앞부분 미리 채우기(프리필) 미지원 | 개발자 메시지가 사용자 메시지보다 우선 | 시스템 지시로 기본 문체 설정 |
눈여겨볼 차이가 하나 있습니다. 긴 자료의 위치입니다. Anthropic은 긴 문서를 프롬프트 위쪽에 두고 질문을 맨 끝에 두면 복잡한 다중 문서 입력에서 응답 품질이 테스트상 최대 30% 좋아졌다고 밝힙니다. 반면 OpenAI 문서는 맥락을 프롬프트 끝 쪽에 두는 것이 대개 좋다고 안내합니다. 쓰는 모델의 문서를 따르면 됩니다.
또 Anthropic은 4.6 이후 모델에서 응답 앞부분을 미리 채워 형식을 강제하던 방식(프리필)을 더는 지원하지 않는다고 밝혔습니다. 예전 글에서 이 기법을 봤다면, 지금은 출력 형식을 지시하거나 구조화된 출력 기능을 쓰는 쪽으로 바꿔야 합니다.
복잡한 일은 어떻게 나눠서 시키나요?
한 번에 많은 것을 요구하면 일부를 빠뜨리기 쉽습니다. 이럴 때는 단계를 나눕니다. Anthropic이 대표 패턴으로 드는 것은 초안 → 기준에 맞춰 검토 → 검토를 반영해 수정의 세 단계입니다. 각 단계를 따로 요청하면 중간 결과를 눈으로 확인하고, 어느 단계에서 틀렸는지 찾기 쉽습니다.
다만 최신 모델은 여러 단계의 추론을 내부에서 스스로 처리하는 경우가 많아서, Anthropic도 명시적인 체이닝은 중간 결과를 확인해야 하거나 정해진 순서를 강제해야 할 때 쓰라고 합니다. 코딩처럼 결과를 검증할 수 있는 일이라면 "끝내기 전에 테스트 기준으로 확인해 줘"처럼 스스로 점검하게 하는 문장도 도움이 됩니다.
프롬프트만 고쳐서는 안 되는 경우는 언제인가요?
프롬프트는 만능이 아닙니다. 다음 상황에서는 문장을 아무리 다듬어도 한계가 있습니다.
- AI가 모르는 자료가 답의 근거일 때: 사내 규정, 우리 상품 정보, 최신 가격은 모델이 학습하지 않았습니다. 이때는 자료를 찾아 붙여 주는 RAG(검색 증강 생성)가 필요합니다. OpenAI 문서도 관련 자료를 프롬프트에 넣는 방법으로 RAG를 직접 언급합니다.
- 속도나 비용이 문제일 때: Anthropic 문서는 지연 시간과 비용은 프롬프트보다 다른 모델을 고르는 편이 더 쉽게 개선될 때가 있다고 말합니다.
- 성공 기준이 없을 때: 무엇이 좋은 결과인지 정해지지 않으면 프롬프트를 고쳐도 나아졌는지 판단할 수 없습니다. 기준과 테스트 질문부터 만듭니다.
- 무료 요금제 한도에 걸릴 때: 긴 자료와 예시를 넣으면 대화가 빨리 길어집니다. 챗GPT 무료 한도처럼 사용량 제한이 있는 요금제라면 프롬프트 품질보다 한도가 먼저 문제가 됩니다.
주의
프롬프트에 개인정보나 회사 기밀을 넣기 전에 쓰는 서비스의 데이터 학습 설정을 먼저 확인하세요. 프롬프트를 잘 쓰는 것과 안전하게 쓰는 것은 별개의 문제입니다.
업무용 프롬프트는 어떻게 관리하나요?
한두 번 쓰고 마는 질문이 아니라 매일 쓰는 프롬프트라면 문서처럼 관리하는 것이 좋습니다. OpenAI 문서는 운영 중인 서비스라면 모델 버전(스냅샷)을 고정하고, 프롬프트 동작을 확인하는 평가(evals)를 만들어 고칠 때마다 돌려 보라고 권합니다. 프롬프트를 코드처럼 버전 관리하라는 이야기입니다.
개인 업무라면 거창할 필요 없습니다.
- 잘 된 프롬프트를 메모 앱이나 프로젝트 지침에 저장합니다.
- 대표 질문 몇 개를 같이 적어 둡니다.
- 모델이 바뀌거나 결과가 달라지면 같은 질문으로 다시 확인합니다.
개발 중이라면 클로드 코드의 CLAUDE.md처럼 프로젝트 규칙을 파일로 두는 방식도 같은 원리입니다.
정리: 오늘 바로 해 볼 것
- 자주 쓰는 프롬프트 하나를 골라, 배경을 모르는 동료가 읽어도 이해되는지 확인합니다.
- 규칙마다 이유를 한 줄씩 붙이고, "하지 마"를 "이렇게 해"로 바꿉니다.
- 원하는 결과 예시를 3개 정도 만들어 태그로 감싸 넣습니다.
- 출력 형식(길이, 표, 목록)을 마지막에 명시합니다.
- 그래도 안 되면 프롬프트가 아니라 자료(RAG)나 모델 선택의 문제인지 의심합니다.
다른 AI 활용 글은 AI 자동화 글 모음에 정리하고 있습니다.
