Week05 실습: 프롬프트 설계 연습
Week05 실습: 프롬프트 설계 연습
관련 강의: W05D01 프롬프팅 기초, W05D02 고급 프롬프팅
이 글은 Week05의 프롬프트 실습을 블로그에서 다시 풀어볼 수 있도록 정리한 연습지다. 핵심은 프롬프트를 한 번에 잘 쓰는 것이 아니라, baseline을 만들고 평가 기준을 정한 뒤 개선하는 흐름을 익히는 것이다.
공통 평가 기준
| 기준 | 확인 질문 |
|---|---|
| 명확성 | 모델이 해야 할 일이 한 문장으로 분명한가 |
| 입력 구조 | 입력 데이터와 작업 지시가 분리되어 있는가 |
| 출력 형식 | 채점하거나 후처리할 수 있는 형식인가 |
| 제약 조건 | 하면 안 되는 행동을 명확히 제한했는가 |
| 검증 가능성 | 결과를 비교할 기준이 있는가 |
실습 1: Zero-shot vs Few-shot
아래 작업을 Zero-shot과 Few-shot 프롬프트로 각각 작성하고 결과를 비교하세요.
작업: 고객 리뷰의 감성을 “긍정/부정/중립”으로 분류
입력 예시
1
리뷰: 배송은 빨랐지만 제품 포장이 찢어져 있어서 아쉬웠습니다.
Zero-shot 프롬프트
1
2
3
4
다음 고객 리뷰의 감성을 긍정, 부정, 중립 중 하나로 분류하세요.
반드시 감성 라벨 하나만 출력하세요.
리뷰: 배송은 빨랐지만 제품 포장이 찢어져 있어서 아쉬웠습니다.
Few-shot 프롬프트
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
다음 고객 리뷰의 감성을 긍정, 부정, 중립 중 하나로 분류하세요.
반드시 감성 라벨 하나만 출력하세요.
예시 1
리뷰: 제품 품질이 좋고 배송도 빨랐습니다.
감성: 긍정
예시 2
리뷰: 상담은 친절했지만 교환 처리가 오래 걸렸습니다.
감성: 중립
예시 3
리뷰: 제품이 파손된 상태로 도착했습니다.
감성: 부정
실제 입력
리뷰: 배송은 빨랐지만 제품 포장이 찢어져 있어서 아쉬웠습니다.
감성:
비교 분석
Zero-shot은 간단하고 비용이 낮지만, 애매한 리뷰에서 기준이 흔들릴 수 있다. Few-shot은 분류 기준을 예시로 보여줄 수 있어 안정성이 높아지지만, 예시가 편향되면 모델이 그 패턴에 과하게 끌릴 수 있다.
실습 2: 시스템 프롬프트 설계
아래 시나리오에 맞는 시스템 프롬프트를 설계하세요.
시나리오: 초등학생을 위한 과학 튜터 AI
시스템 프롬프트
1
2
3
4
5
너는 초등학생을 위한 과학 튜터다.
어려운 용어는 바로 쓰지 말고, 먼저 쉬운 비유로 설명한다.
답변은 5문장 이내로 작성한다.
학생이 위험한 실험을 요청하면 따라 하지 말라고 안내하고 안전한 대안을 제시한다.
모르는 내용은 지어내지 말고 확인이 필요하다고 말한다.
시스템 프롬프트에는 역할만 넣는 것이 아니라 톤, 난이도, 안전 기준, 모르는 경우의 행동까지 포함해야 한다. 이 기준이 있어야 같은 질문에도 일관된 응답을 기대할 수 있다.
실습 3: Chain-of-Thought
아래 문제를 CoT 프롬프팅으로 풀어보세요.
문제: “한 공장에서 하루에 자동차 바퀴 120개를 생산합니다. 자동차 한 대에 바퀴 4개가 필요하고, 예비 바퀴 1개가 추가로 필요합니다. 이 공장이 5일간 생산한 바퀴로 몇 대의 자동차를 완성할 수 있나요?”
CoT 프롬프트
1
2
3
4
5
6
문제를 단계별로 계산하되, 마지막 줄에는 정답만 "정답: N대" 형식으로 출력하세요.
문제:
한 공장에서 하루에 자동차 바퀴 120개를 생산합니다.
자동차 한 대에는 바퀴 4개와 예비 바퀴 1개가 필요합니다.
이 공장이 5일간 생산한 바퀴로 몇 대의 자동차를 완성할 수 있나요?
이 문제는 총 생산량과 자동차 1대당 필요 바퀴 수를 분리해야 한다. 단계별 풀이를 유도하면 중간 계산 오류를 찾기 쉽지만, 최종 출력 형식을 함께 제한하지 않으면 후처리가 어려워질 수 있다.
실습 4: Self-Verification 추가
CoT 답변을 한 번 생성한 뒤, 같은 모델에게 계산 과정을 검증하게 한다.
1
2
3
4
5
아래 풀이에서 계산 오류가 있는지 확인하세요.
오류가 있으면 어느 단계가 틀렸는지 말하고, 최종 정답을 다시 제시하세요.
풀이:
[이전 모델 답변 붙여넣기]
Self-Verification은 답을 무조건 믿지 않고 검산 단계를 추가하는 방식이다. 다만 검증도 LLM이 수행하므로 정답 보장은 아니다. 중요한 작업에서는 규칙 기반 계산, 테스트 코드, 외부 검증과 함께 사용해야 한다.
진행 순서
- Zero-shot baseline을 먼저 작성한다.
- 출력 형식과 평가 기준을 정한다.
- Few-shot, CoT, Self-Verification을 하나씩 추가한다.
- 결과가 좋아진 이유를 프롬프트 변화와 연결해서 설명한다.
체크포인트
- Zero-shot baseline을 남겼다.
- Few-shot 예시가 분류 기준을 잘 보여주는지 확인했다.
- 시스템 프롬프트에 역할, 톤, 제약, 안전 기준을 포함했다.
- CoT 출력과 최종 답 형식을 분리했다.
- Self-Verification이 개선한 부분과 한계를 함께 기록했다.
회고 질문
- 예시를 넣었을 때 성능이 좋아진 이유는 작업 이해 때문인가, 출력 형식 모방 때문인가?
- CoT가 필요한 문제와 필요 없는 문제를 어떻게 구분할 수 있을까?
- 프롬프트 개선보다 후처리나 평가 설계가 더 중요한 경우는 언제인가?