시리즈: ChatGPT 완전정복 | 4편 / 25편 이전 편
[ChatGPT 완전정복 #3] ChatGPT한테 논리적으로 생각시키는 법 — CoT 프롬프트 실전
[ChatGPT 완전정복 #3] ChatGPT한테 논리적으로 생각시키는 법 (2026) — 7년차 개발자의 CoT 프롬프트 실
시리즈: ChatGPT 완전정복 | 3편 / 25편[ChatGPT 완전정복 #1] ChatGPT 거짓말 줄이는 방법 4가지 (2026) → https://cherrycoding0.tistory.com/24 [ChatGPT 완전정복 #1] ChatGPT 거짓말 줄이는 방법 4가지 (2026) — 7년차 개
cherrycoding0.tistory.com
솔직히 제가 프롬프트 공부 꽤 했다고 생각했어요. CoT 쓰는 법도 알고, 역할극 프롬프트도 쓰고, 맥락 잘 넣어서 질문하는 것도 익혔는데.
그런데 어느 순간 벽이 왔어요.
분명히 같은 말을 하는 것 같은데, 결과물이 들쑥날쑥한 거예요. 블로그 글 초안 부탁했더니 어떤 날은 딱 내 스타일로 나오고, 어떤 날은 완전 교과서 같은 문체로 나오고. 코드 리뷰 요청했더니 어떤 건 핵심 짚어주고, 어떤 건 그냥 표면만 훑고 끝나고.
왜 이런 차이가 생기는 걸까 고민하다가, 결국 답을 찾았어요.
예시를 안 줬기 때문이에요.

Few-shot 프롬프트, 이게 뭔데요?
AI한테 질문하는 방식을 크게 세 가지로 나눌 수 있어요.
Zero-shot: 아무 예시 없이 바로 질문 One-shot: 예시 1개 주고 질문 Few-shot: 예시 2~5개 주고 질문
이름은 거창해 보이지만 개념 자체는 단순해요. AI도 결국 "이런 식으로 해달라"는 걸 텍스트로 학습하는 모델이기 때문에, 말로 설명하는 것보다 직접 예시를 보여주는 게 훨씬 더 빠르고 정확하게 전달돼요.
비유하자면 이래요. 신입 개발자한테 "코드 리뷰 잘 해줘"라고 말만 하는 것(Zero-shot)과, 팀 내 시니어가 잘 쓴 코드 리뷰 예시 3개를 먼저 보여주고 "이런 방식으로 해줘"라고 하는 것(Few-shot). 어느 쪽이 더 정확하게 원하는 결과가 나올까요?
당연히 후자예요.
AI도 똑같아요. 제가 원하는 결과물의 형태, 길이, 말투, 관점을 직접 예시로 보여주면, AI는 그 패턴을 바로 읽고 따라와요.
Zero-shot vs Few-shot, 실제로 얼마나 차이나요?
코드 리뷰를 예시로 비교해볼게요.
Zero-shot 프롬프트 (예시 없음)
아래 코드 리뷰해줘.
function fetchUser(id) {
return fetch('/api/user/' + id)
.then(res => res.json())
}
결과: "이 코드는 에러 처리가 없습니다. .catch()를 추가하거나 try-catch를 사용하는 것이 좋습니다. 또한 백틱을 사용한 템플릿 리터럴로 변경하면 가독성이 좋아집니다."
뭔가 나오긴 나왔는데… 너무 교과서 같아요. 실제 팀 리뷰에서 이렇게 쓰는 사람 없잖아요.
Few-shot 프롬프트 (예시 3개 제공)
아래는 우리 팀 코드 리뷰 스타일 예시야.
---
[예시 1]
코드:
const greet = (name) => "Hello " + name
리뷰:
- 백틱 쓰면 더 자연스러울 것 같아요: `Hello ${name}`
- 지금 구조에선 큰 문제 없는데, 나중에 다국어 대응하면 이 부분 먼저 손봐야 할 것 같아요
---
[예시 2]
코드:
function getAge(birthYear) {
return new Date().getFullYear() - birthYear
}
리뷰:
- 동작은 잘 되는데, `birthYear`가 유효한 값인지 체크가 없어요
- 음수 나오는 케이스도 있을 수 있으니 엣지케이스 한 번 고려해보면 좋을 것 같아요
- 로직 자체는 깔끔해요 👍
---
[예시 3]
코드:
async function loadData() {
const data = await axios.get('/api/data')
return data
}
리뷰:
- await 결과를 바로 return하면 `return await` 패턴인데, 이건 async 필요 없이 `return axios.get(...)` 으로 써도 돼요
- 에러 처리 없이 그냥 던지는 구조인데, 호출부에서 try-catch 챙기고 있는지 확인 필요해요
---
이 스타일로 아래 코드 리뷰해줘.
function fetchUser(id) {
return fetch('/api/user/' + id)
.then(res => res.json())
}
결과:
- /api/user/ + id 이 부분 백틱으로 바꾸면 더 깔끔해요: `/api/user/${id}`
- .then() 체이닝이 하나인데, 에러 핸들링이 없어요. .catch() 붙이거나 호출부에서 try-catch 쳐줘야 할 것 같아요
- res.json() 실패 케이스(응답이 JSON이 아닐 때)도 있을 수 있어서, 그 부분도 방어 코드 있으면 좋겠어요
- 동작 자체는 심플하고 읽기 좋아요 👍
차이 보이세요? 두 번째 결과물이 실제로 팀 코드 리뷰에서 쓰는 말투예요. 같은 AI, 같은 코드인데 예시 3개 차이로 결과물 퀄리티가 완전히 달라졌어요.
실전에서 이렇게 써요 — 제가 매일 쓰는 Few-shot 패턴 3가지
패턴 1: 블로그 글 말투 고정시키기
이게 저한테 제일 큰 변화였어요.
티스토리 블로그 글을 ChatGPT한테 맡기면 처음엔 맨날 말투가 달라졌거든요. 어떤 날은 "~합니다" 체로 나오고, 어떤 날은 너무 가볍게 나오고. 그래서 이미 내가 쓴 글 중에 잘 됐다고 느낀 단락 3개를 뽑아서 "이 스타일로 써줘" 패턴을 만들었어요.
아래는 내 블로그 글 스타일 예시야.
[예시 1]
"솔직히 처음엔 잘 몰랐어요. 그냥 쓰면 되는 줄 알았는데, 막상 써보니 뭔가 다른 게 보이기 시작했거든요. 특히 오류 메시지를 처음 마주했을 때가 기억나요. '이게 뭐지?' 싶었는데..."
[예시 2]
"결론부터 말할게요. 저는 이 방법 쓰고 나서 작업 시간이 절반으로 줄었어요. 과장이 아니라 진짜로요. 지금부터 왜 그런지 설명해볼게요."
[예시 3]
"장점만 말하면 신뢰가 안 가죠. 단점도 솔직하게 말할게요. 이 방법, 복잡한 케이스에서는 생각보다 잘 안 돼요..."
이 스타일로 'GitHub Actions 자동화 처음 설정하는 법' 주제로 오프닝 단락 써줘.
이렇게 하면 내 목소리랑 거의 비슷한 초안이 나와요. 수정 시간이 확 줄었어요.
패턴 2: 응답 포맷 고정시키기
API 문서 정리나 기술 스펙 비교표 만들 때 유용해요.
아래는 내가 원하는 비교 정리 형식 예시야.
[예시]
도구: Vercel vs Railway
| 항목 | Vercel | Railway |
|---|---|---|
| 무료 플랜 | 있음 (제한적) | 있음 (크레딧 기반) |
| 서버리스 | 기본값 | 선택 가능 |
| 스케줄링 | 제한적 | cron 지원 |
| 한 줄 요약 | 프론트엔드 배포에 최적화 | 백엔드/풀스택에 유연 |
이 형식으로 'Supabase vs Firebase' 비교표 만들어줘.
이렇게 하면 내가 원하는 표 구조 그대로 나와요. "표로 만들어줘"만 하면 컬럼 구성이 매번 달라지거든요.
패턴 3: 커밋 메시지 스타일 고정시키기
팀 프로젝트에서 커밋 메시지 컨벤션 맞추는 데도 써요.
우리 팀 커밋 메시지 예시야.
[예시 1] feat: 사용자 로그인 API 연동 및 토큰 저장 로직 추가
[예시 2] fix: 프로필 이미지 업로드 시 확장자 검증 누락 수정
[예시 3] refactor: fetchUser 함수 async/await 패턴으로 리팩토링
[예시 4] chore: ESLint 규칙 업데이트 및 prettier 설정 추가
아래 변경사항에 맞는 커밋 메시지 3개 추천해줘.
변경사항: 결제 페이지에서 쿠폰 코드 입력 필드 추가, 유효성 검사 로직 구현, API 연동
이렇게 하면 우리 팀 컨벤션에 딱 맞는 커밋 메시지 후보가 나와요.
Few-shot 쓸 때 이것만 지키면 돼요
실제로 써보면서 정리한 규칙이에요.
예시 개수는 3개가 적당해요. 1개는 너무 적고, 5개 넘어가면 프롬프트가 너무 길어져서 오히려 AI가 앞 내용을 놓치는 경우가 생겨요. 2~3개가 가장 효율적이에요.
예시는 실제 내가 쓴 것, 또는 내가 원하는 결과물이어야 해요. 어디서 긁어온 예시 쓰면 그 스타일을 따라가요. 내 글을 예시로 줘야 내 스타일로 돌아와요.
예시 간에 패턴이 일관돼야 해요. 말투가 다른 예시 3개 섞으면 AI가 어떤 스타일을 따라야 할지 헷갈려요. 같은 결의 예시를 골라서 주세요.
예시 뒤에 반드시 "이 형식/스타일로 ~해줘"라고 명확하게 지시해야 해요. 예시만 주고 지시 안 하면 AI가 예시를 분석 대상으로 인식하는 경우가 있어요.
솔직한 한계도 있어요
Few-shot이 만능은 아니에요.
예시가 AI 컨텍스트 창 길이를 넘어가면 효과가 떨어져요. 예시를 너무 길게 넣으면 뒤쪽 내용이 밀려나는 현상이 생길 수 있어요. 예시 하나당 200~300자 이내로 적당히 압축하는 게 좋아요.
창의적인 작업보다 반복 포맷 작업에 훨씬 효과적이에요. 시나 소설처럼 정형화된 형식이 없는 작업에서는 Few-shot보다 오히려 구체적인 설명이 더 잘 통하는 경우도 있어요.
같은 세션 안에서만 패턴이 유지돼요. 대화 창 새로 열면 다시 처음부터예요. 자주 쓰는 Few-shot 프롬프트는 노션에 저장해두는 걸 추천해요.
마무리: 설명보다 예시가 빠른 이유
결국 Few-shot 프롬프트가 강력한 이유는 하나예요.
AI에게 말로 설명하는 건 "이런 느낌으로 해줘"이고, 예시를 주는 건 "이게 바로 그 느낌이야"예요.
인간도 마찬가지잖아요. 백 마디 설명보다 잘 된 예시 하나가 더 빠르게 전달될 때가 많으니까요.
다음 번에 ChatGPT한테 뭔가 시킬 때, 먼저 내가 원하는 결과물 예시 2~3개를 준비해보세요. 결과물이 달라지는 걸 바로 느낄 수 있을 거예요.
다음 포스팅 예고: [ChatGPT 완전정복 #5] 역할 프롬프트 2.0 — 페르소나 세팅으로 전문가 수준 답변 뽑는 법
'AI 정보' 카테고리의 다른 글
| ChatGPT랑 Claude가 갑자기 '만능 비서'가 된 이유 — MCP 입문 완전 정복 (0) | 2026.05.04 |
|---|---|
| AI 에이전트 시대 본격 개막 — "이제 AI가 알아서 일한다" (2026 개발자 실전 가이드) (2) | 2026.05.02 |
| 2026년 AI 모델 완벽 비교 — GPT-5.4 vs Claude 4.6 vs Gemini 3.1 vs Grok 4, 개발자는 뭘 써야 할까? (0) | 2026.05.01 |
| 2026 AI 트렌드 총정리: 개발자라면 지금 이것만큼은 알자! (0) | 2026.04.29 |
| Claude Code 프롬프트 잘 쓰는 법 — 바이브코딩 실전편 (이것만 바꿔도 결과물이 달라짐) (0) | 2026.04.28 |