Few-Shot으로 원하는 형식 한 번에 뽑아내기
장황한 규칙 설명 대신 1~2개의 입출력 예시를 제공하여 일관된 출력과 형식을 유도하는 Few-Shot 프롬프트 원리와 작성법을 살펴봅니다.
무료 공개 · 최근 수정
규칙을 열 줄 적어도 자꾸 형식을 어기는 AI
프롬프트 맨 위에 대문자로 "경고: 반드시 RFC 8259 규격을 준수하는 순수 JSON 형식으로만 응답할 것. 마크다운 백틱이나 인사말을 절대 붙이지 말 것!"이라고 열 줄에 걸쳐 금지 규칙을 빼곡하게 적어 두었습니다. 하지만 모델은 보란 듯이 "네, 요청하신 JSON 분석 결과입니다: ```json\n{...}"이라며 사족을 덧붙여 백엔드 파서를 산산조각 냈습니다. 다급해진 개발자가 느낌표를 덧붙이고 금지 목록을 스무 줄로 늘릴수록, 모델은 오히려 형식 규정을 더 빈번하게 어기는 악순환에 빠집니다.
언어 모델은 인간 관리자처럼 논리적 금지 조항 목록을 머릿속에 기억하고 위반 여부를 검사하는 방식으로 글을 쓰지 않기 때문입니다. 규칙을 길게 서술하면 오히려 프롬프트 안에 '금지 단어'와 '불필요한 설명 토큰'의 빈도만 늘어나 모델의 주의력이 엉뚱한 곳으로 분산됩니다. 복잡한 지시문으로 모델을 설득하려 애쓰는 대신, 내가 원하는 입력과 출력의 구체적인 쌍(Pair)을 단 두세 개만 보여 주는 것이 훨씬 강력한 해결책입니다. 이처럼 예시를 통해 모델의 반응 패턴을 교정하는 기법이 프롬프트 엔지니어링의 핵심 도구입니다.
지시만 있는 제로샷과 예시를 주는 퓨샷의 차이
추가적인 입출력 예시 없이 작업에 대한 설명과 지시문만 달랑 전달하는 방식을 제로샷(Zero-Shot)이라고 부릅니다. 제로샷 환경에서 모델은 사전에 대규모 사전 학습으로 습득한 내재적 가중치 지식에만 전적으로 의존하여 답변을 생성합니다. 작업이 보편적인 번역이나 상식 질문일 때는 제로샷만으로도 훌륭하게 작동하지만, 특수한 JSON 스키마를 준수해야 하거나 기업 내부의 엄격한 문서 양식을 따라야 할 때는 형식 이탈이 빈번하게 발생합니다.
반면 프롬프트 본문 안에 사용자가 기대하는 모범적인 입력과 출력 사례를 하나 이상 직접 포함하여 제공하는 방식을 퓨샷 프롬프트(Few-Shot Prompting)라고 부릅니다. 예시가 하나뿐이면 원샷(One-Shot), 두 개 이상이면 퓨샷 또는 멀티샷(Multi-Shot)이라고 지칭합니다. 퓨샷 프롬프트를 접한 모델은 지시문을 해석하기에 앞서, 주어진 예시들 사이에 흐르는 통계적 규칙과 문장 구조를 즉각적으로 모사하여 바로 다음 생성 토큰에 그대로 투영합니다.
그림: 제로샷과 퓨샷 프롬프트 구성에 따른 출력 안정성 비교
위 그림은 지시문만 있는 제로샷 경로에서 발생하는 가변적 서식 위험과, 입출력 쌍을 제공하는 퓨샷 경로가 달성하는 표준 규격 준수율을 비교하여 보여 줍니다.
가중치 변경 없이 문맥을 읽어내는 인컨텍스트 러닝
모델의 신경망 가중치(Weights)를 역전파로 단 한 번도 업데이트하지 않으면서도, 입력된 프롬프트 문맥 안에서 새로운 패턴을 즉석에서 습득하고 추론하는 능력을 인컨텍스트 러닝(In-Context Learning)이라고 부릅니다. 2020년 톰 브라운(Tom B. Brown) 등의 논문 "Language Models are Few-Shot Learners"는 수천억 개의 파라미터를 가진 거대 언어 모델이 별도의 파인튜닝 없이도 프롬프트 내부의 문맥 예시만으로 복잡한 작업을 학습자처럼 수행할 수 있음을 규명했습니다.
트랜스포머의 셀프 어텐션 계층은 프롬프트에 적힌 예시의 '입력' 부분과 '출력' 부분 사이의 대응 관계를 강력한 내적 가중치로 묶어냅니다. 모델은 새로운 질문 토큰을 마주했을 때 앞서 제시된 예시들의 출력 포맷을 일종의 거대한 '템플릿'이자 '유도 레일'로 인식합니다. 백 마디 설명보다 단 하나의 구체적인 모범 답안이 다음 단어의 확률 분포를 원하는 방향으로 훨씬 날카롭게 정렬시키는 근본적인 이유가 여기에 있습니다.
[참고] 예시 개수는 몇 개가 적절할까?
단순한 분류나 정형화된 JSON 추출 작업이라면 2
3개의 고품질 예시만으로도 포맷 안정성이 95% 이상으로 급상승합니다. 반면 복잡한 다단계 추론(CoT)이나 뉘앙스 분별이 필요한 작업에서는 48개 정도의 예시가 유의미한 성능 향상을 이끌어냅니다. 무작정 예시를 늘리면 토큰 비용이 커지고 컨텍스트 윈도우가 낭비되므로, 형식 준수가 목적이라면 2~3개에서 시작하는 것이 가장 경제적입니다.
실전 비교: 줄글 규칙 나열 vs 깔끔한 예시 제공
고객 상담 리뷰에서 감정과 주요 키워드를 정형화된 JSON 배열로 추출하는 작업을 비교해 볼 수 있습니다.
실패하기 쉬운 줄글 제로샷 프롬프트
다음 고객 리뷰를 분석해 JSON으로 반환해 줘.
- sentiment 필드는 POSITIVE, NEGATIVE, NEUTRAL 중 하나여야 해.
- keywords 필드는 문자열 배열이어야 해.
- 절대 인사말이나 다른 말은 쓰지 마.
- 코드 블록 기호(```)를 쓰지 말고 순수한 JSON 텍스트만 출력해.
리뷰: 배송은 빨랐는데 상자가 찌그러져서 내용물이 깨져 있었어요.이 프롬프트는 높은 확률로 "네, 분석 결과는 다음과 같습니다:\njson\n{...}\n" 형태의 사족을 포함하거나 감정 값을 소문자('negative')로 출력하는 등 제약 조건을 하나씩 어깁니다.
안정적인 퓨샷 프롬프트 구조
Anthropic과 Google이 공식적으로 권장하는 XML 구조 태그를 적용하면 모델이 예시의 경계를 혼동하지 않고 완벽하게 포맷을 복제합니다.
고객 리뷰에서 감정과 핵심 키워드를 추출하는 작업이야. 아래 예시의 출력 포맷을 정확히 따라 줘.
<examples>
<example>
<review>화면이 선명하고 배터리가 정말 오래 가네요. 대만족입니다.</review>
<output>{"sentiment": "POSITIVE", "keywords": ["화면", "배터리"]}</output>
</example>
<example>
<review>가격 대비 성능은 평범한데 포장이 너무 허술해요.</review>
<output>{"sentiment": "NEGATIVE", "keywords": ["가격", "포장"]}</output>
</example>
</examples>
<review>배송은 빨랐는데 상자가 찌그러져서 내용물이 깨져 있었어요.</review>
<output>이 프롬프트는 별도의 금지 조항을 한 줄도 적지 않았음에도 모델이 <output> 태그 뒤에 공백이나 사족 없이 정확히 {"sentiment": "NEGATIVE", "keywords": ["배송", "상자", "내용물"]}을 출력하고 즉시 생성을 멈춥니다. 모델에게 "어떻게 행동하지 말라"고 지시하기보다 "어떻게 행동해야 하는가"를 예시로 직접 보여 주는 것이 훨씬 효과적입니다.
최근 OpenAI의 정형화 출력(Structured Outputs)이나 함수 호출(Tool Calling)처럼 API 레벨에서 JSON 스키마를 강제하는 기능이 보편화되고 있지만, 세밀한 분류 기준 전달, 고유한 문체 모사, 그리고 스키마 강제 기능을 지원하지 않는 로컬 오픈소스 LLM 환경에서는 여전히 Few-Shot이 가장 직관적이고 강력한 기법으로 쓰입니다.
퓨샷 작성 시 주의해야 할 편향과 엣지 케이스
예시를 설계할 때 무의식적인 편향을 주입하면 모델이 엉뚱한 방향으로 오작동할 수 있으므로 두 가지 주의점을 반드시 점검해야 합니다.
첫째는 예시의 정답 클래스 비율이 한쪽으로 치우쳐 모델이 맹목적으로 특정 답안만 선택하는 레이블 편향(Label Bias)입니다. 예를 들어 감정 분석을 위해 준비한 3개의 예시가 모두 'POSITIVE'라면, 모델은 실제 입력의 내용을 제대로 읽지도 않고 무조건 긍정으로 판단하는 성향을 띠게 됩니다. 예시를 구성할 때는 긍정, 부정, 중립 등 다루고자 하는 모든 분류 카테고리를 균등한 비율로 골고루 배치해야 합니다.
둘째는 비정상적인 입력이 들어왔을 때 대처하는 모서리 사례(Edge Case)를 예시에 포함하는 것입니다. "정보가 누락되었거나 판별할 수 없는 리뷰"가 들어왔을 때 모델이 어떤 형태의 예외 JSON(예: {"sentiment": "UNKNOWN", "keywords": []})을 반환해야 하는지 퓨샷 예시 중 하나로 미리 지정해 두면, 실제 운영 환경에서 예기치 못한 입력이 들어와도 파이프라인 전체가 중단되는 사태를 깔끔하게 방지할 수 있습니다.
참고 문서
설명이 어렵거나 잘못된 부분을 발견하셨나요?
문서 수정 의견 보내기