복사해서 바로 쓸 수 있는 예시와 간단한 의사결정 프레임워크로, 작업에 맞는 프롬프팅 방식을 고르는 실전 가이드.
ChatGPT에 프롬프트를 붙여 넣는다. 결과는… 그럭저럭 괜찮다. 그런데 어떤 사람들은 프롬프트에 "예시"를 추가해서 훨씬 더 좋은 결과를 얻는다는 이야기를 들어봤을 것이다. 나도 그렇게 해야 할까? 예시는 몇 개나 넣어야 하지? 내가 하려는 작업에 정말 차이가 있을까?
이런 질문은 끊임없이 나오는데, 용어부터가 도움이 안 된다. "제로샷(zero-shot)", "퓨샷(few-shot)", "원샷(one-shot)" — 실용적인 가이드라기보다는 사진 용어처럼 들린다. 이 글에서는 그런 전문 용어를 걷어내고 어떤 방식을 쓸지 결정하는 명확한 프레임워크를 제시한다. 직접 복사해서 테스트해 볼 수 있는 완성형 프롬프트도 함께 담았다.
제로샷 프롬프팅이란 무엇인가
제로샷 프롬프팅은 원하는 결과의 예시를 보여 주지 않은 채 AI에 작업을 맡기는 방식이다. 필요한 내용을 설명하기만 하면, 모델이 학습한 내용을 바탕으로 알아서 처리한다.
회의록을 요약하는 제로샷 프롬프트는 다음과 같다:
다음 회의록을 핵심 결정 사항을 다루는 3~5개의 불릿 포인트로 요약해 주세요.
회의록:
{{meeting_notes}}
이게 전부다. "좋은" 요약 예시도, 샘플 입력과 출력도 없다. 모델이 요약이 어떤 모습이어야 하는지, "핵심 결정 사항"이 무엇을 의미하는지 스스로 이해한다고 믿는 것이다. 의외로 많은 작업에서 이 방식이 꽤 잘 작동한다.
퓨샷 프롬프팅이란 무엇인가
퓨샷 프롬프팅은 AI가 따라야 할 패턴을 보여 주는 예시를 2~5개 정도 프롬프트에 함께 넣는 방식이다. 본격적인 작업을 시키기 전에 "이런 식으로 처리해 줬으면 좋겠다"고 보여 주는 셈이다.
같은 회의록 요약 작업에 예시를 곁들이면 이렇게 된다:
회의록을 핵심 결정 사항을 담은 3~5개의 불릿 포인트로 요약하세요.
예시 1:
입력: "팀이 3분기 목표를 논의했다. Sarah는 매출 목표를 15% 올리자고 제안했다. Mark는 현재 파이프라인을 고려할 때 10%가 더 현실적이라며 반대했다. 팀이 투표 끝에 12%로 합의했다. 또한 웹사이트 리디자인은 4분기로 미루기로 했다."
출력:
- 3분기 매출 목표를 12% 인상하기로 합의 (15% 안과 10% 안의 절충)
- 웹사이트 리디자인을 4분기로 연기
예시 2:
입력: "예산 검토 회의. 현재 지출이 예측치 대비 8% 초과. CFO는 출장비 50% 삭감과 60일간의 신규 채용 동결을 권고했다. CEO가 두 조치 모두 즉시 시행하기로 승인했다."
출력:
- 출장비 50% 삭감 (즉시 시행)
- 60일간 채용 동결 승인
- 8% 예산 초과에 대한 대응
이제 이 회의록을 요약해 주세요:
{{meeting_notes}}
차이가 보일 것이다. 예시가 어떤 형식을 원하는지(괄호로 맥락을 덧붙인 불릿 포인트), 어느 정도 수준으로 자세히 쓸지, 여러 결정을 어떻게 다룰지를 모델에 그대로 보여 준다. 모델은 맥락 안에서 당신의 취향을 학습한다 — 파인튜닝은 필요 없다.
한눈에 보는 핵심 차이
두 방식이 가장 중요한 기준에서 어떻게 다른지 정리하면 다음과 같다:
속도: 제로샷이 더 빠르다. 처리할 토큰이 적으니 응답도 그만큼 빨라진다.
비용: 제로샷이 더 저렴하다. 토큰 단위로 과금되는데, 예시는 토큰을 꽤 잡아먹는다.
준비 부담: 제로샷은 거의 필요 없다. 퓨샷은 좋은 예시를 찾거나 만들어야 한다.
간단한 작업의 정확도: 거의 비슷하다. 요즘 모델은 평범한 요청은 어느 쪽이든 잘 처리한다.
복잡하거나 맞춤형 작업의 정확도: 보통 퓨샷이 이긴다. 특정한 형식이나 도메인 용어가 필요할 때는 예시가 눈에 띄는 차이를 만든다.
트레이드오프는 분명하다. 제로샷은 단순하고 저렴하지만, 퓨샷은 결과물에 대한 통제권이 더 크다. 문제는 그 추가 통제가 토큰 비용을 감수할 만큼 가치가 있느냐다.
제로샷이 잘 통하는 경우
제로샷 프롬프팅은 모델이 이미 학습 과정에서 "이해"하고 있는 작업에서 진가를 발휘한다. 대표적으로 다음과 같다:
일반 지식 질문: 설명, 정의, 사실 정보를 묻는 경우. 모델은 좋은 설명이 어떤 모습인지 잘 알고 있다.
창의적인 브레인스토밍: 아이디어 생성, 초안 작성, 여러 옵션 떠올리기. 이럴 때는 정해진 패턴을 따르기보다 다양성이 오히려 중요하다.
일반적인 요약: 특정 형식이 필요 없는 기사, 이메일, 문서 압축.
번역: 모델이 학습한 언어 사이의 텍스트 변환.
단순 분류: 카테고리가 자명한 경우의 분류 작업(긍정/부정, 긴급/비긴급 등).
기준이 되는 감각은 이렇다. 원하는 바를 평이한 말로 설명했을 때 사람도 예시 없이 이해할 수 있다면, 제로샷이 잘 통할 가능성이 높다.
의사결정 과정을 보여 주는 흐름도: 제로샷으로 시작해서 결과를 평가하고, 필요한 경우에만 예시를 추가하는 단계를 시각화
추가 토큰을 들여서라도 퓨샷을 쓸 만한 경우
퓨샷 프롬프팅은 지시문만으로는 모델이 추론하기 어려운 패턴을 출력에 강제해야 할 때 제값을 한다:
맞춤형 형식: 특정한 필드를 가진 JSON, 정해진 컬럼이 있는 표, 일정한 스타일의 불릿 포인트처럼 출력 구조가 명확히 정해져 있을 때. 형식은 말로 설명하는 것보다 예시로 보여 주는 편이 훨씬 정확하다.
나만의 분류 카테고리: 고객 이메일을 "청구 문의(billing-question)", "기능 요청(feature-request)", "버그 리포트(bug-report)", "일반 문의(general-inquiry)"처럼 분류해야 한다면, 각 카테고리의 예시를 보여 줘야 모델이 당신이 정한 정의를 이해한다.
브랜드 보이스나 톤 맞추기: AI가 우리 회사의 기존 콘텐츠 같은 톤으로 글을 쓰길 원한다면? 그 톤이 살아 있는 예시 2~3개를 보여 주자. "전문적이면서도 친근한 톤으로 써 주세요" 같은 지시는 모호하지만, 예시는 구체적이다.
도메인 특화 용어: 다른 분야에서는 다른 의미로 쓰이는 전문 용어나 약어를 다루는 산업이라면, 예시가 모델에 당신의 맥락을 가르쳐 준다.
예외 사례와 미묘한 뉘앙스: 비꼼, 반어법, 제로샷이 흔히 놓치는 미묘한 구분. 부정 표현이나 비꼼 같은 감성 분석의 까다로운 사례에서 퓨샷 프롬프팅이 처리 능력을 크게 끌어올린다는 연구도 있다.
한 연구에 따르면 트위터 감성 분류에서 단 20~50개의 예시만으로 한 퓨샷 프롬프팅이 10,000개 이상의 예시로 파인튜닝한 모델의 성능에 근접했다. 잘 고른 시범 예시의 위력이다.
여러 작업에 쓸 퓨샷 프롬프트가 점점 늘어난다면, PromptNest 같은 도구가 도움이 된다. {{meeting_notes}} 같은 변수를 미리 박아 두고 저장해 두면, 복사할 때 빈칸만 채워서 완성된 프롬프트를 그대로 붙여 넣을 수 있다.
"제로샷부터 시작하고, 필요하면 업그레이드" 워크플로
시간과 토큰을 모두 아끼는 실전 접근법은 다음과 같다:
1단계: 일단 제로샷부터 해 본다. 무엇을 원하는지 명확히 적어 프롬프트를 작성한다. 작업은 구체적으로 묘사하되, 아직 예시는 넣지 않는다.
2단계: 결과를 평가한다. 필요한 결과가 나왔는가? 그렇다면 거기서 끝이다. 그렇지 않다면 무엇이 잘못됐는지 짚어 낸다 — 형식인가, 톤인가, 빠진 정보인가, 작업 자체를 잘못 이해한 것인가?
3단계: 핀포인트로 예시를 추가한다. 모델이 틀린 부분을 정확히 짚는 예시 2~3개를 만든다. 형식이 어긋났다면 올바른 형식을, 톤이 어긋났다면 맞는 톤을 보여 준다.
이 워크플로가 중요한 이유는 예시가 필요한지 짐작으로 결정하지 않고, 실제 결함을 보고 대응하기 때문이다. 추론이 어긋난 경우에는 "단계적으로 생각해 봅시다" 한 줄을 더하는 것만으로 예시 없이도 해결되곤 한다. 한 연구는 추론 작업에서 제로샷 사고 사슬(chain-of-thought)이 퓨샷보다 더 좋은 결과를 내는 경우가 많다고 밝혔다.
예시는 정말 몇 개나 필요할까
여러 연구는 대부분의 작업에서 2~5개가 가장 좋은 구간이라고 일관되게 말한다. 데이터가 보여 주는 것은 다음과 같다:
- 처음 2~3개의 예시가 정확도를 가장 크게 끌어올린다
- 4~5개를 넘어가면 효과가 급격히 줄어든다
- 예시가 너무 많으면 패턴이 충돌해 오히려 성능이 떨어질 수 있다
- 양보다 질이 중요하다 — 뛰어난 예시 3개가 평범한 예시 10개를 이긴다
예시의 순서도 중요하다는 점도 기억해 둘 만하다. 연구에 따르면 예시의 배열 순서가 결과에 영향을 미치며, 최적의 순서로 정렬하느냐 아니냐가 좋은 성능과 부진한 성능을 가르기도 한다. 퓨샷 프롬프트가 잘 작동하지 않는다면, 예시를 더 추가하기 전에 순서부터 바꿔 보자.
프롬프트에 예시 카드가 추가되는 모습과 첫 몇 개 이후 효용이 점점 감소하는 양상을 표현한 일러스트
대부분의 경우 예시 2개로 시작하는 게 좋다. 정확도가 부족하면 다른 변형을 다루는 세 번째 예시를 추가한다. 4개를 넘길 일은 거의 없다.
사고 사슬: 추론 작업의 중간 지대
수학, 논리, 다단계 문제에 특히 잘 맞는 세 번째 옵션이 있다. 바로 사고 사슬(chain-of-thought) 프롬프팅이다. 입력-출력 예시를 보여 주는 대신, 모델에 "단계적으로 생각해 보라"고 요청하는 방식이다.
제로샷 사고 사슬의 모습은 이렇다:
어떤 가게에 사과 45개가 있다. 오전에 12개를 팔고, 30개를 더 입고했다. 그 뒤 오후에 18개를 더 팔았다. 폐점 시점에 사과는 몇 개 남아 있을까?
단계적으로 따져 봅시다.
이 단순한 한 마디 — "단계적으로 따져 봅시다" — 가 모델로 하여금 답을 바로 내놓는 대신 추론 과정을 펼쳐 보이게 만든다. 복잡한 추론에서는 이 방식이 제로샷과 퓨샷을 모두 능가하는 경우가 많다.
arXiv의 최근 연구는 GPT-4나 Claude처럼 강력한 모델에서 제로샷 사고 사슬이 추론 작업에서 퓨샷 프롬프팅을 자주 능가한다는 사실을 보였다. 예시가 오히려 모델의 사고를 도와주기보다 좁히는 결과를 낳을 수 있다는 것이다.
사고 사슬은 다음과 같은 경우에 사용하자:
작업이 여러 논리 단계를 요구할 때
모델이 자신의 추론 과정을 설명해야 할 때 (오류를 잡아내는 데 유용하다)
수학, 코드 로직, 분석 문제가 얽혀 있을 때
단순한 답이 아니라 모델이 거친 접근 방식 자체를 검증하고 싶을 때
그대로 복사해서 쓸 수 있는 프롬프트 예시
실제 작업을 가지고 세 가지 방식을 나란히 살펴보자. 모든 프롬프트는 GPT-4와 Claude로 검증했고, 곧바로 사용해도 좋다.
작업 1: 이메일 톤 분류
제로샷 버전:
이 고객 이메일의 톤을 다음 중 하나로 분류하세요: frustrated(불만), satisfied(만족), neutral(중립), urgent(긴급).
이메일:
{{email_text}}
톤:
퓨샷 버전 (예외 사례에 더 강함):
고객 이메일의 톤을 다음 중 하나로 분류하세요: frustrated, satisfied, neutral, urgent.
이메일: "주문한 지 3주째 기다리고 있어요. 이건 말도 안 됩니다. 지금 당장 환불해 주세요."
톤: frustrated
이메일: "고맙다는 말씀 드리고 싶었어요 — 제품이 일찍 도착했고 아주 잘 작동합니다!"
톤: satisfied
이메일: "안녕하세요, 제 주문이 발송됐는지 확인해 주실 수 있나요? 주문번호 #12345입니다."
톤: neutral
이메일: "저희 시스템이 다운됐고 오늘 안에 교체 부품을 받지 못하면 계약을 잃게 됩니다."
톤: urgent
이메일: {{email_text}}
톤:
퓨샷 버전은 당신이 정한 구체적인 정의를 모델이 이해하도록 돕는다. "urgent"와 "frustrated"의 경계가 애매할 수 있는데, 예시는 그 경계를 분명하게 그어 준다.
작업 2: 제품 설명 다시 쓰기
제로샷 버전:
이 제품 설명을 더 매력적이고 혜택 중심으로 다시 써 주세요. 100단어 이내로 유지하세요.
원문: {{product_description}}
수정본:
퓨샷 버전 (브랜드 보이스 일관성에 유리):
제품 설명을 매력적이고 혜택 중심으로 다시 써 주세요. 다음 스타일에 맞춰 주세요:
원문: "스테인리스 스틸 물병. 24oz 용량. 음료를 24시간 동안 차갑게 유지."
수정본: "세련된 24oz 스틸 물병으로 하루 종일 수분을 챙기세요. 출근길에는 모닝 커피가 따끈하게, 운동할 땐 오후의 물이 얼음처럼 시원하게 유지됩니다. 한 병으로 무한한 가능성을 누려 보세요."
원문: "무선 이어버드. 8시간 배터리. 노이즈 캔슬링."
수정본: "좋아하는 팟캐스트를 끊김 없이 8시간. 우리 무선 이어버드가 소음을 차단해, 깊은 몰입이 필요한 작업이든, 운동 플레이리스트든, 미뤄 두던 오디오북이든 정말 중요한 일에 집중할 수 있게 해 줍니다."
원문: {{product_description}}
수정본:
퓨샷 버전은 특정 카피라이팅 스타일 — 혜택을 앞세우고, 대화체이며, 구체적인 사용 장면이 있는 — 을 가르친다. 제로샷도 어떤 수정본을 만들어 주긴 하지만, 그게 우리 브랜드의 목소리라는 보장은 없다.
작업 3: 버그 리포트 정리
제로샷 버전:
이 버그 리포트를 다음 항목으로 구조화해 주세요: 요약, 재현 단계, 기대 동작, 실제 동작.
버그 리포트: {{bug_report}}
퓨샷 버전 (일관된 형식이 중요할 때 유리):
버그 리포트를 구조화된 형식으로 변환해 주세요.
입력: "PDF를 업로드하려고 하면 앱이 죽어요. 대시보드에 있다가 업로드를 클릭했고, 5MB짜리 PDF를 골랐는데 그냥 종료됐습니다. 업로드 목록에 파일이 보여야 하는데 앱 자체가 죽어 버려요."
출력:
**요약:** PDF 파일 업로드 시 앱 강제 종료
**재현 단계:**
1. 대시보드로 이동
2. 업로드 버튼 클릭
3. PDF 파일 선택 (5MB 파일로 테스트)
**기대 동작:** 업로드 섹션에 파일이 표시됨
**실제 동작:** 앱이 예기치 않게 강제 종료됨
---
입력: {{bug_report}}
출력:
기술 문서에서는 일관성이 중요하다. 퓨샷 버전은 모든 버그 리포트가 같은 구조와 같은 수준의 디테일을 따르도록 보장한다.
빠른 의사결정 프레임워크
새로운 작업을 앞두고 망설일 때 다음 질문을 차례로 던져 보자:
1. 작업이 단순하고 정의가 명확한가? → 제로샷부터 시작
2. 모델이 알아서 맞히기 어려운 특정 형식이 필요한가? → 퓨샷 사용
3. 여러 단계의 추론이 필요한 작업인가? → 제로샷 사고 사슬을 먼저 시도
4. 일관된 브랜드 보이스나 도메인 용어가 필요한가? → 그 보이스로 작성된 예시를 곁들인 퓨샷 사용
5. 제로샷이 필요한 결과의 80%를 이미 주는가? → 그대로 둔다. 토큰 3배를 들여 100%를 채울 가치는 없다.
목표는 가장 화려한 기법을 쓰는 것이 아니라, 좋은 결과를 효율적으로 얻는 것이다. 기본값은 제로샷이다. 더 단순한 방식이 부족할 때만 복잡함을 더하자.
실전에 적용하기
이 내용을 몸에 익히는 가장 좋은 방법은 직접 해 보는 것이다. 자주 하는 작업 — 보고서 요약, 이메일 초안, 피드백 분류 — 을 골라 두 방식을 모두 적용해 보자. 어디에서 제로샷이 부족한지, 어디에서 퓨샷이 진짜 차이를 만드는지 직접 확인하게 된다.
잘 작동하는 프롬프트를 찾았다면, 다시 찾을 수 있는 곳에 잘 저장해 두자. 예시와 변수를 포함한 프롬프트 컬렉션을 쌓아 가는 중이라면, PromptNest는 이를 위해 만든 네이티브 Mac 앱이다 (Mac App Store에서 $19.99 일회성 구매, 구독 없음, 계정 없음, 로컬에서 동작). 프롬프트를 정리해 검색할 수 있게 보관하고, 어떤 앱에서든 단축키 한 번이면 불러올 수 있다. 3주 전에 공들여 만든 그 완벽한 퓨샷 프롬프트를 흩어진 메모 사이에서 뒤질 일이 없어진다.
단순하게 시작하자. 필요할 때만 복잡함을 더하자. 잘 작동한 것은 저장하자. 전략은 이게 전부다.
