프롬프트 엔지니어링
프롬프트 엔지니어링은 대규모 언어 모델(LLM)에서 원하는 출력을 안정적으로 끌어내도록 입력 프롬프트의 지시문, 예시, 형식, 역할을 설계하는 기법입니다. 모델 가중치를 바꾸지 않고 입력 텍스트만으로 응답 품질과 일관성을 끌어올리는 것이 목표입니다.
- 프롬프트 엔지니어링은 LLM의 출력을 원하는 방향으로 유도하도록 프롬프트 자체(지시문·예시·형식·역할)를 설계하는 기법입니다.
- 모델을 재학습시키지 않고 입력 텍스트만 바꾼다는 점에서, 파인튜닝보다 비용과 반복 속도 면에서 유리합니다.
- 핵심 기법으로는 제로샷·퓨샷 프롬프팅, 사고의 연쇄(CoT), 역할 부여, 형식 지정, 작업 분할(프롬프트 체이닝) 등이 있습니다.
- OpenAI·Anthropic·Google이 공통으로 강조하는 원칙은 명확하고 구체적인 지시, 충분한 맥락 제공, 좋은 예시 제시, 그리고 반복적 개선입니다.
- 컨텍스트 엔지니어링과 인접하지만, 프롬프트 엔지니어링은 모델에 전달되는 프롬프트 텍스트의 구성과 표현에 초점을 둡니다.
프롬프트 엔지니어링이란
프롬프트 엔지니어링은 대규모 언어 모델(LLM)에서 원하는 출력을 안정적으로 얻기 위해 입력 프롬프트를 의도적으로 설계하는 기법입니다. 같은 작업을 시키더라도 지시문을 어떻게 쓰고, 어떤 예시를 보여주고, 어떤 역할과 출력 형식을 부여하느냐에 따라 응답의 정확도와 일관성이 크게 달라지기 때문입니다. 모델의 가중치를 바꾸는 파인튜닝과 달리, 프롬프트 엔지니어링은 모델은 그대로 둔 채 입력 텍스트만으로 행동을 조정합니다. 그래서 비용이 거의 들지 않고, 수정과 검증을 빠르게 반복할 수 있다는 장점이 있습니다.
최근에는 ChatGPT, Claude, Gemini 같은 생성형 모델이 검색·콘텐츠·고객응대 전반에 쓰이면서, 프롬프트 설계 역량이 곧 결과물 품질을 좌우하는 핵심 변수가 되었습니다. OpenAI, Anthropic, Google 모두 자사 모델용 프롬프트 가이드를 공식 문서로 제공하고 있으며, 세부 표현은 달라도 권장 원칙은 상당 부분 겹칩니다.
컨텍스트 엔지니어링과의 차이
프롬프트 엔지니어링은 종종 컨텍스트 엔지니어링과 함께 거론됩니다. 다만 둘의 초점은 다릅니다. 프롬프트 엔지니어링은 모델에 전달하는 프롬프트 텍스트 자체의 구성과 표현, 즉 지시문 문구·예시·역할·출력 형식을 어떻게 짜느냐에 집중합니다. 반면 컨텍스트 엔지니어링은 검색 결과·문서·대화 이력·도구 출력 등 모델에게 어떤 정보를 어떤 순서와 분량으로 "채워 넣을지"를 설계하는 더 넓은 작업에 가깝습니다. 본 문서는 프롬프트 자체의 설계에 초점을 둡니다.
주요 기법
다음은 OpenAI·Anthropic·Google 공식 가이드와 학술 연구에서 공통적으로 다루는 대표적인 프롬프트 엔지니어링 기법입니다.
| 기법 | 설명 | 적합한 상황 |
|---|---|---|
| 제로샷 프롬프팅(Zero-shot) | 예시 없이 작업 지시만으로 응답을 요청 | 단순·범용 작업, 모델이 이미 잘 아는 과제 |
| 퓨샷 프롬프팅(Few-shot) | 입력·출력 예시 2~5개를 함께 제시해 형식과 패턴을 학습시킴 | 특정 출력 형식·말투·구조가 중요한 작업 |
| 사고의 연쇄(Chain-of-Thought, CoT) | "단계별로 생각해 보라"처럼 중간 추론 과정을 유도 | 산술·논리·다단계 추론이 필요한 문제 |
| 역할 부여(Role / Persona) | "당신은 숙련된 세무사입니다"처럼 역할을 지정해 톤과 전문성을 고정 | 특정 도메인 전문성·일관된 말투가 필요할 때 |
| 형식 지정(Output formatting) | 표·JSON·목록·길이 제한 등 출력 구조를 명시 | 후속 시스템이 파싱하거나 일정한 형식이 필요할 때 |
| 작업 분할 / 프롬프트 체이닝 | 복잡한 작업을 여러 단계로 쪼개 순차 호출 | 한 번에 처리하기 어려운 복합 작업 |
| 구분자·구조화(XML·마크다운) | 지시·맥락·예시를 태그나 헤딩으로 분리 | 프롬프트가 길고 구성 요소가 많을 때 |
예시: 제로샷 vs 퓨샷 vs 사고의 연쇄
# 제로샷: 지시만 제시
다음 리뷰의 감성을 긍정/부정/중립 중 하나로 분류해 줘.
리뷰: "배송은 빨랐지만 포장이 엉망이었다."
# 퓨샷: 예시로 출력 형식을 고정
리뷰: "가격 대비 훌륭하다" -> 긍정
리뷰: "두 번 다시 안 산다" -> 부정
리뷰: "배송은 빨랐지만 포장이 엉망이었다" ->
# 사고의 연쇄(CoT): 중간 추론을 유도
다음 문제를 단계별로 풀어 줘.
사과가 23개 있고 20개를 점심에 쓰고 6개를 더 샀다면 몇 개가 남는가?
단계별로 계산한 뒤 마지막 줄에 "정답: N" 형식으로 답해 줘.근거와 사례
사고의 연쇄(Chain-of-Thought)는 학술적으로 효과가 입증된 대표 기법입니다. Wei et al.(2022), "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models"(arXiv:2201.11903)는 모델에게 최종 답 대신 중간 추론 단계를 생성하도록 유도하면 산술·상식·기호 추론 과제 전반에서 성능이 크게 향상됨을 보였습니다. 특히 5,400억(540B) 파라미터 모델에 단 8개의 사고의 연쇄 예시만 제공했을 때, 수학 문장제 벤치마크 GSM8K에서 검증기(verifier)를 붙인 파인튜닝 GPT-3까지 능가하며 당시 최고 성능(SOTA)을 달성했습니다. 이는 프롬프트의 구성 방식만 바꿔도 모델의 추론 능력을 끌어낼 수 있음을 보여준 분기점이 된 연구입니다.
공식 가이드의 권고도 일관됩니다. Google의 Gemini 프롬프트 설계 문서는 "프롬프트에는 항상 퓨샷 예시를 포함할 것을 권장하며, 예시가 없는 프롬프트는 효과가 떨어질 가능성이 높다"라고 명시하고, 모든 예시의 구조와 형식을 동일하게 유지하라고 강조합니다. Anthropic의 Claude 프롬프트 엔지니어링 문서는 명확성, 예시(멀티샷), XML 태그를 통한 구조화, 역할 부여, 사고(thinking), 프롬프트 체이닝을 핵심 기법으로 정리합니다. OpenAI는 톤·역할 같은 전역 지침은 시스템 메시지에, 작업별 세부 지시와 예시는 사용자 메시지에 두라고 안내하며, 데이터 추출·사실 응답처럼 정확성이 중요한 작업에서는 temperature를 0으로 두는 것이 좋다고 권장합니다. 세 곳 모두 공통적으로 반복적 개선(iterative refinement), 즉 초안 프롬프트를 만들고 출력을 보며 다듬는 과정을 필수로 봅니다.
실행 체크리스트
- 작업·대상 독자·"완료"의 기준을 프롬프트 안에 명시적으로 적었는지 확인합니다.
- 출력 형식(표·JSON·목록·길이)을 구체적으로 지정합니다.
- 형식·말투가 중요한 작업이면 입력·출력 예시 2~5개를 동일한 구조로 제시합니다.
- 다단계 추론이 필요하면 "단계별로 생각해 보라"는 사고의 연쇄 지시를 추가합니다.
- 전문성·톤이 필요하면 역할(페르소나)을 부여합니다.
- 지시·맥락·예시가 섞여 길어지면 XML 태그나 마크다운 헤딩으로 구분합니다.
- 한 번에 처리하기 어려운 작업은 단계별 프롬프트로 분할(체이닝)합니다.
- 사실성이 중요하면 temperature를 낮게 설정하고, 출력을 보며 프롬프트를 반복 개선합니다.