프롬프트 구조 설계: 다섯 요소, 시스템 프롬프트, 퓨샷 예시

프롬프트 구조 설계는 AI에게 보내는 요청을 목표, 자료, 제약, 출력 형식, 역할 다섯 부품으로 나눠 적는 방법입니다. 이 다섯 요소는 업계 공식 틀이 아니라 준이아빠블로그가 공식 문서들의 공통점을 묶은 틀이며, 오픈AI는 Identity, Instructions, Examples, Context로, 구글 워크스페이스 가이드는 Persona, Task, Context, Format으로 나눕니다. 이 글은 한 줄 요청을 설계도로 펼쳐 부품마다 결과의 어느 줄이 바뀌는지 보고, 시스템 프롬프트와 퓨샷 예시까지 이어서 다룹니다.

프롬프트 엔지니어링이란 무엇인가요?

프롬프트 엔지니어링은 AI에게 원하는 결과를 얻도록 요청 문장을 설계하고, 결과를 보고 고쳐 다시 시도하는 일입니다. 앤트로픽 문서는 클로드를 "맥락을 모르는 똑똑한 신입 사원"처럼 대하라고 권하며, 원하는 것을 정확히 설명할수록 결과가 좋아진다고 씁니다. 거창한 기법보다 목표와 자료와 조건을 빠짐없이 전달하는 것이 출발점입니다.

세 회사의 공식 문서가 공통으로 권하는 내용은 다음과 같습니다.

• 분명하고 직접적으로 쓰기: 앤트로픽은 "명확하고 구체적인 지시"를, 구글은 "목표를 분명하고 간결하게"를 첫 원칙으로 둡니다.
• 부분을 나눠 표시하기: 앤트로픽은 XML(Extensible Markup Language) 태그, 즉 <회의록>처럼 시작과 끝을 표시하는 이름표를, 오픈AI와 구글은 마크다운 제목과 XML 태그를 함께 예로 듭니다.
• 예시로 보여 주기: 세 회사 모두 예시를 권하지만 개수와 대상 모델은 다르게 말합니다(아래 퓨샷 절).
• 하지 말 것 대신 할 것을 적기: 앤트로픽은 "마크다운을 쓰지 마" 대신 "부드럽게 이어지는 문단으로 써 줘"처럼 원하는 행동을 적으라고 권합니다.

프롬프트의 다섯 부품은 무엇인가요?

다섯 요소는 준이아빠블로그가 정리한 틀이고, 모든 요청에 다섯 개가 다 필요하지는 않습니다. 짧은 번역이나 계산처럼 목표만으로 충분한 일도 많습니다. 결과에서 문제가 보이면 그 문제를 맡은 부품을 더합니다. 회의록에 없는 담당자가 생겼다면 제약을, 날마다 모양이 다르면 출력 형식을 더하는 식입니다.

막연한 말은 확인할 수 있는 조건으로 바꿉니다. "짧게"는 "세 줄 이내"로, "깔끔하게"는 "확정, 논의 중, 검토 중 세 묶음으로"로, "정확하게"는 "회의록에 없는 내용은 확인 필요로"로 적으면 결과를 보고 지켜졌는지 바로 판단할 수 있습니다.

역할을 주면 답이 더 정확해지나요?

역할은 말투와 초점을 잡는 데 쓰고, 사실 정확도를 올리는 장치로 기대하지 않습니다. 앤트로픽 문서는 시스템 프롬프트에 역할을 주면 클로드의 "행동과 말투"가 쓰임새에 맞게 잡힌다고 설명합니다. 반면 2024년 EMNLP Findings에 실린 연구는 네 계열의 언어 모델과 사실 질문 2,410개로 시험했을 때, 시스템 프롬프트에 사람 역할을 넣어도 성능이 오르지 않았고 역할마다 효과가 거의 무작위였다고 보고했습니다.

그래서 "너는 20년 차 회계사야"를 넣는 것보다 "회의록에 없는 숫자는 만들지 마"를 넣는 편이 사실 오류를 줄이는 데 직접적입니다. 사실 오류를 다루는 방법은 할루시네이션 수업에서 이어집니다.

긴 자료는 질문 앞에 두나요, 뒤에 두나요?

긴 자료는 앞에 두고 질문은 끝에 둡니다. 앤트로픽 문서는 긴 문서를 프롬프트 위쪽에 두고 질문을 끝에 두면 자사 시험에서 응답 품질이 최대 30% 좋아졌고, 여러 문서가 섞인 복잡한 입력에서 특히 그렇다고 적습니다. 구글 Gemini 문서도 많은 자료를 줄 때는 자료를 먼저 모두 주고 구체적인 지시나 질문은 맨 끝에 두라고 씁니다.

30%는 클로드를 대상으로 한 앤트로픽 자체 시험의 수치이고 시험 조건은 공개되지 않았습니다. 짧은 메모 한 장이라면 순서의 차이가 작을 수 있습니다. 반대로 역할, 꼭 지킬 제약, 출력 형식은 구글 문서가 시스템 지시나 사용자 프롬프트 맨 앞에 두라고 권합니다. 정리하면 "규칙은 맨 앞, 자료는 가운데, 이번 질문은 맨 끝"입니다.

시스템 프롬프트와 사용자 프롬프트는 무엇이 다른가요?

시스템 프롬프트는 서비스나 앱이 대화 전체에 깔아 두는 기본 지시이고, 사용자 프롬프트는 사용자가 이번에 보내는 요청입니다. 앤트로픽 API 문서는 시스템 프롬프트를 "특정 목표나 역할처럼 클로드에게 맥락과 지시를 주는 방법"으로 설명합니다. 오픈AI는 이 지시를 개발자 메시지(developer)라고 부르며, 개발자 메시지를 사용자 메시지보다 앞서 따른다고 씁니다.

나누는 기준은 하나입니다. 이 조건이 다음 대화에서도 그대로 필요한지 봅니다. 필요하면 반복 지시에, 이번 한 번이면 요청에 둡니다.

챗 서비스에서는 시스템 프롬프트 칸을 직접 고칠 수 없지만, 반복 지시를 저장하는 기능이 비슷한 역할을 합니다. 챗GPT는 설정의 맞춤 지침, 클로드는 프로젝트 지침과 계정 전체의 Instructions for Claude, 제미나이는 설정 및 도움말 > Personal Intelligence의 Instructions for Gemini에 적습니다. 저장한 지시가 어느 대화에 들어가는지는 AI 학습 설정과 메모리에서 비교했습니다. 앤트로픽은 claude.ai에 쓰는 시스템 프롬프트를 모델별로 공개하고 있어, 실제 시스템 프롬프트가 XML 태그와 예시로 나뉘어 있는 모습을 직접 볼 수 있습니다.

시스템 쪽에 적었다고 항상 지켜지는 것은 아닙니다. 지시를 고쳤는데 결과가 그대로라면 저장했는지, 새 대화에서 확인했는지, 서로 부딪히는 줄은 없는지부터 봅니다.

퓨샷(few-shot)이란 무엇인가요?

퓨샷은 원하는 결과의 예시를 프롬프트 안에 몇 개 넣어 AI가 형식과 기준을 따라 하게 하는 방법입니다. 2020년 GPT-3 논문은 예시 없이 지시만 주는 것을 제로샷(zero-shot), 예시 하나를 주는 것을 원샷(one-shot), 몇 개를 주는 것을 퓨샷(few-shot)으로 구분했고, 이때 모델의 가중치는 바뀌지 않는다고 밝혔습니다. 앤트로픽 문서는 같은 뜻으로 멀티샷(multishot)이라는 말도 씁니다.

같은 논문의 퀴즈 문제(TriviaQA) 정확도는 제로샷 64.3%, 원샷 68.0%, 퓨샷 71.2%였습니다. 예시는 이번 요청 안에서 참고하는 자료일 뿐이고, 모델을 다시 학습시키거나 다음 대화에서도 기억하게 만들지는 않습니다.

예시는 몇 개가 적당한가요?

정해진 정답은 없고, 회사마다 권장도 다릅니다.

• 앤트로픽: 예시 3~5개를 권합니다. 실제 용도와 닮고(관련성), 서로 달라서 우연한 패턴을 배우지 않게(다양성), <example> 태그로 지시와 구분하라고 씁니다.
• 구글: 예시를 늘 넣으라고 권하지만 개수는 정하지 않습니다. 너무 많으면 예시에 과하게 맞춰진다고 경고하고, 예시끼리 형식을 똑같이 맞추라고 씁니다.
• 오픈AI: 추론 모델(답하기 전에 오래 생각하는 모델)에는 예시 없이 먼저 시도하고 필요하면 예시를 더하라고 씁니다.

위 장면의 고객 문의 요약처럼 쿠폰, 배송, 교환으로 유형이 다른 예시를 넣으면 길이와 빼야 할 내용이 함께 전달됩니다. 반대로 예시가 모두 "고객님"으로 시작하면 필요 없는 곳에도 같은 말이 붙을 수 있고, 지시는 25자인데 예시가 40자면 AI가 둘 중 하나를 골라야 합니다. 피할 예를 넣을 때는 왜 피하는지 이유를 함께 적습니다.

다음 요청에서 직접 해 보기

1. 지난주에 보낸 요청 하나를 골라 다섯 부품 가운데 무엇이 빠졌는지 표시합니다.
2. 결과에서 마음에 안 든 줄을 찾아, 그 줄을 맡은 부품 하나만 더해 다시 보냅니다.
3. 긴 자료가 있다면 자료를 위로, 질문을 맨 끝으로 옮겨 다시 보내고 두 답을 비교합니다.
4. 매번 같은 조건이 반복된다면 맞춤 지침이나 프로젝트 지침으로 옮깁니다.

부품을 바꾼 뒤에도 결과는 원자료와 대조합니다. 같은 요청에도 답은 조금씩 달라질 수 있어서, 한 번 좋아졌다는 이유만으로 그 부품이 유일한 원인이라고 단정하지 않습니다. 말투와 문체를 지시하는 방법은 다음 수업 말투와 문체 지시하기에서 이어집니다.

📚 참고 자료

• Prompting best practices(Anthropic): https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
• System prompts 공개 페이지(Anthropic): https://platform.claude.com/docs/en/release-notes/system-prompts/overview
• Prompt engineering 가이드(OpenAI): https://platform.openai.com/docs/guides/prompt-engineering
• Reasoning best practices(OpenAI): https://platform.openai.com/docs/guides/reasoning-best-practices
• Prompt design strategies(Google Gemini API): https://ai.google.dev/gemini-api/docs/prompting-strategies
• Language Models are Few-Shot Learners(Brown 외, 2020): https://arxiv.org/abs/2005.14165
• Personas in System Prompts Do Not Improve Performances of Large Language Models(Zheng 외, EMNLP 2024 Findings): https://arxiv.org/abs/2311.10054

2026년 10월 22일 위 공식 문서와 논문에서 권장 내용과 수치를 확인했습니다. 회의록, 광고 자료, 고객 문의와 AI의 답 문장은 이 글의 학습용 가상 예제입니다.