앞 글에서는 좋은 프롬프트의 기본 구조를 정리했다. 역할을 정하고, 작업을 명확히 쓰고, 필요한 자료를 구분하고, 출력 형식을 지정하는 것이 핵심이었다.
이번 글에서는 한 단계 더 나아가 복잡한 문제를 더 잘 풀게 만드는 고급 프롬프트 기법을 정리한다. 대표적으로 Few-shot, Chain of Thought, Case Breakdown, Incremental Query, Chain of Draft가 있다.
이 기법들은 모델을 더 똑똑하게 바꾸는 기술이 아니다. 오히려 모델이 이미 가진 능력을 더 잘 꺼내 쓰도록 문제를 보여주는 방식을 바꾸는 기술에 가깝다.
핵심부터 말하면, 고급 프롬프 트 기법은 모델에게 “정답만 말해”라고 하는 대신, 예시를 보여주거나, 문제를 나누거나, 단계적으로 해결하게 만드는 방법이다. 복잡한 작업일수록 질문 하나로 끝내기보다 구조를 잡아주는 것이 중요하다.
1. 왜 고급 프롬프트 기법이 필요한가?
간단한 질문은 기본 프롬프트만으로도 충분하다.
예를 들어 “Azure OpenAI가 뭐야?”처럼 개념을 묻는 질문은 모델이 바로 설명할 수 있다.
하지만 실제 업무에서는 질문이 그렇게 단순하지 않다.
리뷰를 분석해 야 할 수도 있고, 보고서를 요약해야 할 수도 있고, 여러 조건을 고려해 의사결정을 해야 할 수도 있다.
이런 작업은 모델 이 한 번에 처리하려고 하면 답변이 흐려지거나, 기준이 흔들리거나, 중요한 조건을 놓칠 수 있다.
예를 들어 다음 요청을 보자.
고객 리뷰를 분석해서 우리 서비스의 개선 방향을 알려줘.
겉으로는 간단해 보이지만 실제로는 여러 작업이 섞여 있다.
- 리뷰에서 긍정 의견과 부정 의견을 구분해야 한다.
- 자주 언급되는 문제를 찾아야 한다.
- 문제의 원인을 추정해야 한다.
- 실제로 개선 가능한 방향을 제안해야 한 다.
- 결과를 보기 쉽게 정리해야 한다.
이런 경우에는 모델에게 “분석해줘”라고만 말하기보다, 작업을 어떻게 처리할지 길을 만들어주는 것이 좋다. 고급 프롬프트 기법은 바로 이때 필요하다.
상황 기본 프롬프트의 한계 필요한 기법
| 원하는 답변 형식이 정해져 있음 | 모델이 형식을 마음대로 바꿀 수 있음 | Few-shot |
| 계산이나 논리 단계가 필요함 | 중간 과정을 건너뛰고 틀릴 수 있음 | Chain of Thought |
| 질문이 너무 크고 모호함 | 답변이 넓고 얕아질 수 있음 | Case Breakdown |
| 처음부터 완성 답변을 만들기 어려움 | 중요한 세부사 항을 놓칠 수 있음 | Incremental Query |
| 단계적 사고는 필요하지만 답변은 간결해야 함 | 추론 과정이 너무 길어질 수 있 음 | Chain of Draft |
고급 프롬프트 기법의 목표는 답변을 화려하게 만드 는 것이 아니라, 모델이 문제를 더 안정적으로 이해하고, 더 일관된 방식으로 해결하게 만드는 것이 다.
2. Zero-shot, One-shot, Few-shot
먼저 Few-shot을 이해하려면 Zero-shot과 One-shot부터 같이 봐야 한다. 이 세 가지는 모델에게 예시를 몇 개 보여주고 작업을 시킬 것인가의 차이다.
기법 의미 쉽게 말하면
| Zero-shot | 예시 없이 지시만 주는 방식 | “이 렇게 해줘”라고 바로 시키는 것 |
| One-shot | 예시를 1개 보여주고 작업시키는 방식 | “이 예시처럼 해줘”라고 한 번 보여주는 것 |
| Few-shot | 예시를 여러 개 보여주고 작업시키는 방식 | “이런 패턴으로 답해 줘”라고 몇 가지 사례를 보여주는 것 |
감성 분석 예시로 이해하기
고객 리뷰를 긍정, 부정, 중립으로 분류하는 작업을 예로 들어보자. 2
Zero-shot 예시
다음 리뷰의 감성을 positive, negative, neutral 중 하나로 분류해줘.
리뷰: "배송은 빨랐지만 제품 포장이 너무 아쉬웠어요."이 방식은 가장 간단하다. 하지만 모델이 어떤 기준으로 분류해야 하는 지 예시를 보지 못했기 때문에 결과가 흔들릴 수 있다.
One-shot 예시
다음 예시를 참고해서 리뷰 감성을 positive, negative, neutral 중 하나로 분류해줘.
예시: 리뷰: "제품 품질이 좋고 배송도 빨랐어요." 분류: positive
분류할 리뷰: "배송은 빨랐지만 제품 포장이 너무 아쉬웠어요."이제 모델은 출력 형식과 분류 방식의 힌트를 하나 얻었다. 하지만 예시 가 하나뿐이면 다양한 상황을 충분히 보여주기 어렵다.
Few-shot 예시
다음 예시를 참고해서 리뷰 감성을 positive, negative, neutral 중 하나로 분류해줘.
예시 1: 리뷰: "제품 품질이 좋고 배송도 빨랐어요." 분류: positive
예시 2: 리뷰: "가격은 괜찮지만 포장이 찢어져서 왔어요." 분류: negative
예시 3: 리뷰: "아직 사용 전이라 잘 모르겠어요." 분류: neutral
분류할 리뷰: "배송은 빨랐지만 제품 포장이 너무 아쉬웠어요."Few-shot은 모델에게 기준을 더 명확하게 보여준다. “어떤 문장을 positive로 보고, 어떤 문장을 negative로 보고, 어떤 문장을 neutral로 보는지”를 예시로 학습시키는 느낌이다.
Few-shot은 모델에게 별도로 학습을 시키는 것이 아니다. 프롬프트 안에 예시를 넣어 이번 작업에서 원하는 패턴을 즉석에서 보여주는 방식이다.
3. Few-shot 예시 설계법
Few-shot에서 가장 중요한 것은 예시의 개수가 아니라 예시의 품질이다. 예시를 많이 넣는다고 무조건 좋아지지 않는다. 잘못된 예시나 한쪽으로 치우친 예시는 오히려 모델의 답변을 왜곡할 수 있다.
좋은 Few-shot 예시의 조건
| 조건 | 설명 | 이유 |
| 대표성 | 실제 입력과 비슷한 예시를 사용 | 모델이 실제 작업 상황을 더 잘 이해함 |
| 다양성 | 여러 유형의 사례 를 포함 | 특정 패턴에 과하게 치우치는 것을 방지 |
| 일관성 | 입력과 출력 형식을 통일 | 모델이 원하는 출력 구조를 쉽게 따라감 |
| 명확성 | 애매한 예시보다 기준이 분명한 예시 사용 | 분류 기준이 흔들리지 않음 |
| 간결성 | 불필요하 게 긴 예시는 피함 | 토큰 비용을 줄이고 핵심 패턴만 전달 |
나쁜 Few-shot 예시
예시 1: 리뷰: "좋아요." 분류: positive
예시 2: 리뷰: "최고예요." 분류: positive
예시 3: 리뷰: "만족합니다." 분류: positive이 예시는 모두 positive만 보여준다. 이렇게 되면 모델은 부정적인 표 현이나 중립적인 표현을 어떻게 처리해야 하는지 충분히 알기 어렵다.
개선된 Few-shot 예시
예시 1: 리뷰: "배송도 빠르고 제품도 만족스러웠어요." 분류: positive
예시 2: 리뷰: "가격은 괜찮지만 포장이 찢어져서 왔어요." 분류: negative
예시 3: 리뷰: "아직 사용 전이라 평가하기 어려워요." 분류: neutral개선된 예시는 긍정, 부정, 중립을 모두 포함한다. 그래서 모델이 분류 기준을 더 균형 있게 이해할 수 있다.
주의할 점
Few-shot 예 시는 모델의 기준을 만든다. 예시가 편향되어 있으면 답변도 편향될 수 있다. 따라서 분류, 평가, 추천처럼 기준이 중요 한 작업에서는 예시를 균형 있게 구성해야 한다.
4. Chain of Thought
Chain of Thought는 줄여서 CoT라고도 부른다. 말 그대로 생각의 사슬이라는 뜻이다. 복잡한 문제를 한 번에 답하게 하지 않고, 단계별로 나누어 생각하도록 유도하는 프롬프트 기법이다.
간단한 예를 들어보자.
식당에는 원래 식빵이 72개 있었습니다. 점심을 준비하기 위해 샌드위치 30인분을 만들었
고, 1인분의 샌드위치에는 식빵 2개가 필요합니다. 내일 점심을 위해 식빵 10개짜리 묶음 7개를 추가로 구매했습니다.
현재 식빵은 몇 개 남아 있나요?이 문제는 숫자가 여러 개 나오기 때문에 모델이 대충 합산하거나 조건 을 놓치면 틀릴 수 있다. 이럴 때는 이렇게 지시할 수 있다.
문제를 단계별로 계산한 뒤, 최종 답만 마지막에 제시해줘.그러면 모델은 다음 순서로 문제를 풀 가능성이 높아진다.
- 처음 식빵 개수를 확인한다.
- 샌드위치에 사용한 식빵 개 수를 계산한다.
- 남은 식빵을 계산한다.
- 추가 구매한 식빵 개수를 계산한다.
- 최종 식빵 개수를 구한다.
CoT가 필요한 상황
| 계산 문 제 | 중간 계산을 분리해야 실수를 줄일 수 있음 |
| 논리 추론 | 조건을 순서대로 따져야 함 |
| 복잡한 의사결정 | 여러 기준을 비교해야 함 |
| 분석 보고서 작성 | 문제 원인과 해결책을 단계적으로 연결해야 함 |
CoT를 쓰지 않아도 되는 상황
반대로 모든 질문에 CoT를 쓸 필요는 없다. 간단한 정의, 번역, 짧은 요약처럼 중간 추론이 크게 필요하지 않은 작업에서는 오히려 답변이 불필요하게 길어질 수 있다.
사용하지 않아도 되는 상황 이유
| 단순 번역 | 단계적 추론보다 정확한 변환이 중요함 |
| 짧은 요약 | 중간 과정보다 최종 요약이 필요함 |
| 정의 설명 | 개념을 바로 설명하는 것이 더 효율적임 |
실무에서의 주의점
CoT는 정확도를 높이는 데 도움이 될 수 있지만, 중간 추론을 항상 사용자에게 길게 보여줄 필요는 없다. 서비스에서는 “단계적으로 검토한 뒤 최종 답변만 간결하게 제시해줘”처럼 요청하는 방식이 더 적절할 때가 많다.
5. Case Breakdown
Case Breakdown은 하나의 큰 질문을 여러 개의 하위 질문으로 나누어 해결하는 기법이다.
쉽게 말하면 큰 문제를 작은 상자들로 쪼개는 방식이다.
예를 들어 다음 질문은 너무 넓다.
우리 서비스의 고객 리뷰를 분석해서 개선 전략을 제안해줘.
이 요청에는 여러 작업이 섞여 있다. 그냥 한 번에 답하게 하면 모델이 일부 항목만 다루거나, 답변이 추상적으로 끝날 수 있다.
Case Breakdown을 적용하면 이렇게 나눌 수 있다.
고객 리뷰 분석을 다음 하위 질문으로 나누어 처리해줘.
1. 리뷰에서 자주 등장하는 긍정 키워드는 무엇인가?
2. 리뷰에서 자주 등장하는 부정 키워드는 무엇인가?
3. 부정 리뷰에서 반복되는 핵심 문제는 무엇인가?
4. 이 문제들이 사용자 경험에 어떤 영향을 주는가?
5. 우선순위가 높은 개선 방향 3가지를 제안해줘.
이렇게 나누면 모델은 큰 질문을 한 번에 처리하지 않고, 각 하위 문제 를 순서대로 다룰 수 있다. 답변도 더 구조적으로 나온다.
Case Breakdown이 유용한 작업
| 작업 | 나누는 기준 | 예시 |
| 고객 리뷰 분석 | 긍정, 부정, 원인, 개선안 | 리뷰 기반 서비스 개선 전략 |
| 마케팅 전략 수립 | 타깃, 채널, 메시지, 경쟁사 | 신제 품 출시 전략 |
| 데이터 분석 | 지표, 추세, 원인, 액션 | 매출 하락 원인 분석 |
| 학습 계획 설계 | 목표, 현재 수준, 기간, 자료, 루틴 | 데이터 엔지니어 로드맵 |
Case Breakdown은 질문이 너무 클 때 유용하다. 큰 질문을 작은 질문으로 나누면 모델이 놓치는 부분이 줄고, 답변의 구조가 훨씬 선명해진다.
6. Incremental Query
Incremental Query는 한 번에 완성된 답을 요구하지 않고, 작은 질문 부터 시작해서 점진적으로 결과를 구체화하는 방식이다. Least-to-Most Prompting이라고도 부른다.
쉽게 말하면 처음부터 “완벽한 보고서 써줘”라고 하는 대신, 먼저 큰 틀 을 잡고, 그다음 세부 내용을 추가하고, 마지막에 형식을 다듬는 방식이다.
한 번에 요청하는 방식
고객 리뷰를 분석해서 문제점, 원인, 개선 전략, 우선순위, 실행 계획까지 모두 작성해줘.이렇게 요청하면 모델이 많은 일을 한 번에 처리해야 한다. 결과가 그럴 듯해 보일 수는 있지만, 세부 내용이 얕거나 기준이 흔들릴 수 있다.
Incremental Query 방식
1단계: 아래 고객 리뷰에서 긍정 의견과 부정 의견을 분류해줘.
2단계: 부정 의견에서 반복적으로 등장하는 문제를 3가지로 묶어줘.
3단계: 각 문제의 가능한 원인을 추정해줘.
4단계: 개선 효과와 실행 난이도를 기준으로 우선순위를 정해줘.
5단계: 최종 개선 전략을 표로 정리해줘.이 방식은 모델과 대화하면서 결과물을 점점 발전시키는 데 좋다. 특히 분석, 기획, 글쓰기, 보고서 작성처럼 한 번에 완성하기 어려운 작업에 잘 맞는다.
Incremental Query의 장점
- 중간 결과를 확인하면서 방향을 수정할 수 있다.
- 모델이 한 번에 너무 많은 조건을 처리하지 않아도 된다.
- 사용자가 원하는 결과물에 더 가깝게 조정할 수 있다.
- 복잡한 작업을 더 안정적으로 진행할 수 있다.
대화 예시
사용자: 이 고객 리뷰들을 긍정/부정/중립으로 먼저 분류해줘.
AI: 리뷰를 분류한 결과는 다음과 같습니다...
사용자: 좋아. 이제 부정 리뷰에서 가장 많이 반복되는 문제 3가지를 뽑아줘.
AI: 반복적으로 나타나는 문제는 배송, 포장, 고객 응대입니다...
사용자: 각 문제에 대해 개선 우선순위를 정해줘.
AI: 개선 효과와 실행 난이도를 기준으로 우선순위를 정리하면...Incremental Query는 대화 기록을 활용하기 때문 에 토큰 비용이 늘어날 수 있다. 긴 작업을 할 때는 중간 결과를 요약해두거나, 필요한 메시지만 이어서 사용하는 방식이 좋다.
7. Chain of Draft
Chain of Draft는 Chain of Thought의 변형 기법이다. CoT가 단계별 사고를 자세히 쓰게 하는 방식이라면, Chain of Draft는 중간 과정을 짧고 핵심적인 메모 형태로 남기게 한다.
왜 이런 방식이 필요할까? CoT는 복잡한 문제를 푸는 데 도움이 되지 만, 답변이 너무 길어질 수 있다. 중간 설명이 길어지면 토큰 비용도 증가하고, 사용자가 정작 필요한 최종 답을 찾기 어 려울 수 있다.
Chain of Draft는 단계적 사고 의 장점은 살리면서, 중간 과정을 길게 풀어쓰지 않고 핵심 계산식이나 짧은 메모로만 정리하는 방식이다.
CoT 방식 예시
문제를 단계별로 자세히 풀어줘.
식당에는 원래 식빵이 72개 있었습니다. 샌드위치 30인분을 만들었고, 1인분에 식빵 2개가 필요합니다. 내일을 위해 식
빵 10개짜리 묶음 7개를 추가로 구매했습니다. 현재 식빵은 몇 개 남아 있나요?이 방식은 친절하지만 답변이 길어질 수 있다.
Chain of Draft 방식 예시
Chain of Draft 방식으로 풀어줘. 각 단계는 짧은 메모와 계산식만 남기고, 마지막에 최종 답
을 제시해줘.
식당에는 원래 식빵이 72개 있었습니다. 샌드위치 30인분을 만들었고, 1인분에 식빵 2개가 필요합니다. 내일을 위해 식
빵 10개짜리 묶음 7개를 추가로 구매했습니다. 현재 식빵은 몇 개 남아 있나요?예상 출력
1. 초기 식빵: 72개 2. 사용한 식빵: 30 × 2 = 60개 3. 남은 식빵: 72 - 60 = 12개 4. 추가 구
매: 10 × 7 = 70개 5. 최종 식빵: 12 + 70 = 82개
정답: 82개Chain of Draft는 보고서나 서비스 응답에서 특히 유용하다. 모델이 내 부적으로 단계를 나누어 검토하되, 사용자에게는 간결한 근거와 최종 답만 보여줄 수 있기 때문이다.
| 구분 | Chain of Thouth | Chain of Draft |
| 중간 과정 | 자세히 설명 | 짧은 메모와 계산식 중심 |
| 응답 길이 | 길어질 수 있음 | 상대적으로 짧음 |
| 장점 | 학습용 설명에 좋음 | 실무형 응답에 좋음 |
| 주의점 | 토큰 사용량 증가 | 너무 줄이면 근거가 부족해 보일 수 있음 |
8. 기법별 사용 상황 비교
이제 각 기법을 언제 써야 하는지 정리해보자. 고급 프롬프트 기법은 서 로 경쟁 관계가 아니다. 작업의 성격에 따라 하나만 쓰기도 하고, 여러 개를 조합하기도 한다.
기법 핵심 역할 사용하면 좋은 상황 주의점
| Zero-shot | 예시 없이 바 로 지시 | 간단한 질문, 일반 설명 | 출력 형식이 흔들릴 수 있음 |
| Few-shot | 예시로 패턴 제공 | 분류, 형식 고정, 스타일 통일 | 예시 편향 주의 |
| Chain of Thought | 단계 별 추론 유도 | 계산, 논리, 복잡한 판단 | 응답이 길어질 수 있음 |
| Case Breakdown | 큰 문제를 하위 질문으로 분해 | 분석, 전략, 기획 | 하위 질문 설계 가 중요함 |
| Incremental Query | 작 은 단계부터 점진적 구체화 | 보고서, 글쓰기, 데이터 분석 | 대화 기록으로 토큰 증가 가능 |
| Chain of Draft | 간결한 단계 메모 | 근거는 필요하지만 답변은 짧아야 할 때 | 너무 짧으면 설명 부족 가능 |
실무에서는 Few-shot으로 출력 형식을 잡고, Case Breakdown으로 문제를 나눈 뒤, 필요한 부분에 Chain of Draft를 적용하는 식으로 여러 기법을 함께 사용할 수 있다.
9. 실습: 같은 문제를 여러 기법으로 풀어보기
이제 하나의 문제를 여러 프롬프트 기법으로 풀어보자. 이번 실습 주제 는 고객 리뷰 분석이다.
실습 데이터
리뷰 1: 배송은 빨랐지만 포장이 찢어져서 왔어요.
리뷰 2: 제품 품질은 만족스럽고 재구매 의사가 있어요.
리뷰 3: 고객센터 연결이 너무 오래 걸렸어요.
리뷰 4: 가격은 괜찮지만 설명서가 부족해서 사용이 어려웠어요.
리뷰 5: 전체적으로 만족하지만 배송 조회가 잘 안 됐어요.[그림 8 넣기: 실습 데이터 카드 이미지. 5개의 고객 리뷰 를 말풍선 카드로 보여주고, 이 데이터를 다양한 프롬프트 기법으로 분석한다고 표시]
1단계: Zero-shot으로 분석하기
아래 고객 리뷰를 분석해서 주요 문제점과 개선 방향을 알려줘.
[리뷰 데이터]Zero-shot은 가장 빠르다. 하지만 분석 기준이 명확하지 않기 때문에 답변이 넓고 추상적으로 나올 수 있다.
2단계: Few-shot으로 분류 기준 잡기
다음 예시를 참고해서 리뷰를 분류해줘.
예시 1: 리뷰: "배송이 빠르고 제품이 만족스러웠어요." 분류: positive 문제 영역: 없음
예시 2: 리뷰: "배송은 빨랐지만 포장이 찢어져서 왔어요." 분류: mixed 문제 영역: 포장
예시 3: 리뷰: "고객센터 연결이 너무 오래 걸렸어요." 분류: negative 문제 영역: 고객지원
분류할 리뷰: [리뷰 데이터]
출력 형식: 리뷰 번호 | 감성 | 문제 영역 | 핵심 근거Few-shot을 사용하면 모델이 원하는 분류 기준과 출력 형식을 더 잘 따라간다. 특히 positive, negative뿐 아니라 mixed처럼 애매한 경우를 예시로 넣으면 실제 리뷰 분석 품질이 좋아진다.
3단계: Case Breakdown으로 분석 쪼개기
아래 고객 리뷰 분석을 다음 단계로 나누어 진행해줘.
1. 각 리뷰의 감성을 분류해줘.
2. 부정 또는 혼합 리뷰에서 문제 영역을 추출해줘.
3. 문제 영역별 빈도를 계산해줘.
4. 가장 우선적으로 개선해야 할 문제를 2개 선정해줘.
5. 각 문제에 대한 개선 방안을 제안해줘.
[리뷰 데이터]Case Breakdown을 적용하면 분석 흐름이 훨씬 분명해진다. 모델이 단순 감상평을 쓰는 대신, 단계별 분석 결과를 만들게 된다.
4단계: Chain of Draft로 간결하게 근거 정리하기
Chain of Draft 방식으로 분석해줘. 각 단계는 짧은 메모로만 작성하고, 마지막에 최종 개선
방향을 제시해줘.
분석 단계: 1. 감성 분류 2. 문제 영역 추출 3. 반복 문제 확인 4. 우선순위 판단 5. 최종 개선 방향
[리뷰 데이터]Chain of Draft를 쓰면 중간 근거는 남기되, 답변이 과하게 길어지는 것을 줄일 수 있다. 보고서 초안이나 회의 자료용 요약에 잘 맞는다.
5단계: Incremental Query로 점진적으로 완성하기
첫 번째 요청: 리뷰를 긍정, 부정, 혼합, 중립으로 분류해줘.
두 번째 요청: 부정 또는 혼합 리뷰에서 문제 영역을 추출해줘.
세 번째 요청: 문제 영역별 빈도와 심각도를 기준으로 우선순위를 정해줘.
네 번째 요청: 우선순위가 높은 문제 2개에 대해 실행 가능한 개선안을 제안해줘.
다섯 번째 요청: 지금까지의 결과를 표로 정리하고, 최종 결론을 3줄로 요약해줘.Incremental Query는 사용자가 중간 결과를 보면서 방향을 조정할 수 있다는 장점이 있다. 처음부터 완성된 결과를 맡기는 것보다 실제 업무 흐름에 더 가깝다.
실습 결과 비교표
| 기법 | 특징 | 장점 | 아쉬운점 |
| Zero-shot | 빠르고 간단 한 분석 | 바로 사용 가능 | 기준이 흐릴 수 있음 |
| Few-shot | 예시와 비슷한 형식으로 출력 | 분 류 기준과 형식이 안정적 | 예시 설계가 중요함 |
| Case Breakdown | 문제를 단계별로 분석 | 복잡한 분석에 강함 | 하위 질문을 잘못 나누면 품질 저하 |
| Chain of Draft | 간결한 근거와 최종 답변 | 토큰 사용량을 줄이기 좋음 | 너무 짧으면 설명이 부족할 수 있음 |
| Incremental Query | 중간 결과를 보며 점진적 개선 | 실무 작업 흐름에 적합 | 대화가 길어지면 토큰 비용 증가 |
Prompt Evaluation: 프롬프트도 테스트해야 한다
프롬프트를 만들었다고 끝이 아니다. 실무에서는 프롬프트도 테스트해 야 한다. 같은 프롬프트가 다양한 입력에서도 안정적으로 동작하는지 확인해야 하기 때문이다.
예를 들어 고객 리뷰 분류 프롬프트를 만들었다면, 긍정 리뷰만 테스트 하면 안 된다. 부정 리뷰, 중립 리뷰, 애매한 리뷰, 비꼬는 리뷰, 짧은 리뷰, 긴 리뷰를 모두 넣어봐야 한다.
프롬프트 테스트 케이스 예시
| 테스트 유형 | 입력 예시 | 확인할 점 |
| 명확한 긍정 | 정말 만족스럽고 재구매하고 싶어요. | positive로 분류하는가 |
| 명확한 부정 | 포장이 망가져서 다시는 주문하지 않을 것 같아요. | negative로 분류하는가 |
| 혼합 의견 | 제품은 좋은데 배송이 너무 늦었어요. | mixed 또는 적절한 문제 영역을 찾는가 |
| 중립 | 아직 사용 전 이라 판단하기 어려워요. | neutral로 분류하는가 |
| 비꼼 | 와, 이렇게 늦게 올 줄은 몰랐네요. 대단합니다. | 문맥상 부정으로 이해하는가 |
좋은 프롬프트는 한 번 좋은 답변을 만드는 프롬프트가 아니라, 여러 입력에서도 안정적으로 원하는 결과를 내는 프롬프트다.
10. 정리
이번 글에서는 고급 프롬프트 기법을 정리했다. 기본 프롬프트가 AI에 게 작업을 지시하는 방법이라면, 고급 프롬프트 기법은 복잡한 작업을 더 안정적으로 처리하게 만드는 방법이다.
Zero-shot은 예시 없이 바로 지시하는 방식이고, Few-shot은 몇 개의 예시를 보여주어 원하는 패턴을 유도하는 방식이다. Chain of Thought는 단계별 사고를 유도하고, Case Breakdown은 큰 문제를 작은 하위 질문으로 나누며, Incremental Query는 작은 요청부터 시작해 점진적으로 결과 를 구체화한다. Chain of Draft는 단계적 사고를 간결한 메모 형태로 줄여 토큰 사용량과 응답 길이를 관리하는 데 도움 을 준다.
기법 한 줄 정의 대표 활용
| Zero-shot | 예시 없이 바로 작업 지시 | 간단한 설명, 기본 요약 |
| Few-shot | 예시를 통해 답변 패턴 유도 | 분류, 스타일 통일, 형식 고정 |
| Chain of Thought | 문제를 단계적으로 생각하게 유도 | 계산, 논리 추론, 복잡한 판단 |
| Case Breakdown | 큰 문제를 하위 질문으로 분해 | 전략 수립, 분석, 기획 |
| Incremental Query | 작은 질문부터 점진적으로 구체화 | 보고서 작성, 데이터 분석, 글쓰기 |
| Chain of Draft | 중간 과 정을 짧은 메모로 정리 | 간결한 근거 제시, 토큰 절약 |
전체 흐름 한 번에 정리
고급 프롬프트 기법은 예시를 보여주고, 문제를 나누고, 단계적으로 해결하고, 결과를 테스트하는 과정이다. 간단한 작업은 Zero-shot으로 충분하지 만, 형식이 중요하면 Few-shot을 쓰고, 논리나 계산이 필요하면 Chain of Thought 또는 Chain of Draft를 사용할 수 있다. 문제가 크고 복잡하면 Case Breakdown으로 나누고, 결과를 점진적으로 다듬고 싶다면 Incremental Query가 적합하다.
실무에서 중요한 것은 기법 이름을 외우는 것이 아니다. 내가 해결하려 는 작업이 단순한지, 예시가 필요한지, 단계적 판단이 필요한지, 문제를 나눠야 하는지 판단하는 것이 더 중요하다.
또한 프롬프트는 한 번 작성하고 끝나는 것이 아니라 테스트하고 개선 해야 한다. 여러 입력을 넣어보고, 결과가 흔들리는 지점을 찾고, 예시나 조건을 보완하는 과정이 필요하다. 결국 좋은 프롬프트는 모델에게 답을 강제로 만들게 하는 문장이 아니라, 모델이 문제를 제대로 이해하고 안정적으로 처리할 수 있 게 돕는 설계도에 가깝다.
[그림 11 넣기: 전체 요약 이미지. 작업이 단순하면 Zero shot, 형식이 중요하면 Few-shot, 논리가 필요하면 CoT/CoD, 문제가 크면 Case Breakdown, 점진적 개선이 필요하 면 Incremental Query를 선택하는 의사결정 트리]
'Azure OpenAI Engineering > Prompt' 카테고리의 다른 글
| [ Azure OpenAI #9] 프롬프트 엔지니어링 완전 정리: 좋은 지시문은 어떻게 설계되는가? (0) | 2026.06.18 |
|---|