[AI 에이전트] 2주차 : 프롬프트 기법 4가지

성찬홍·2026년 4월 1일

AI Agent

AI

목록 보기

2/3

주요 프롬프트 기법 4가지 정의 각 프롬프팅별 테스트 결과를 정리해 보았습니다.
각 프롬프팅병 결과 테스트를 정리해보았습니다.

Zero-Shot Prompting ( 제로샷 프롬프팅 )

(1) 한 줄 정리

제로샷 프롬프팅은 LLM에게 별도의 예시나 사전 학습 데이터 없이 바로 작업을 수행하도록 지시하는 기법입니다.

(2) 핵심 원리

별도의 예시 없이 , 해당 모델이 이미 데이터를 통해 학습한 지식을 바탕으로 결과물을 추론하여 도출하는 방식입니다.

LLM의 AR( autoregressive ) 특성상 초기 생성되는 토큰들이 맥락을 결정하게 되기에 , 질문이 모호하거나 학습 데이터가 적다면 맥락을 이탈하거나 환각(Hallucination)을 생성하는 빈도가 높아질 수 있다

(3) 사용 예시

광화문 BTS 공연이라는 특정 상황에 대해 정해진 양식없이 질문을 한 예시입니다.

어떤 특별한 지침없이 , 키워드를 바탕으로 보고서 형태로 답변을 받을 수 있었습니다.,
2번째 질문에서는 표 형태 라는 지시를 추가해서 , 표 형태 답변을 받을 수 있었습니다.,

→ 이렇게 제로샷 프롬프트의 경우 질문에 따라, 추론되어 자유로운 형태의 답변을 받게됩니다.

구분	질문 1 (자유 추론)	질문 2 (형식 지정)
프롬프트	키워드 기반의 정보 요청	명확한 출력 형식(표) 지시
추론 방식	가장 보편적인 보고서 맥락 선택	지시어에 따른 구조적 변환
AR 특징	문맥의 일관성을 유지하는 서술적 생성	특정 기호(표)에 고착된 패턴 생성

(4) 사용처

언제 사용되면 좋을까?
- 범용적인 질의응답 (General-Purpose Chat)
  → Gemini, GPT와 같이 카테고리가 정해지지 않은 서비스에서 상식적인 질문이나 일상적인 대화를 나눌 때 가장 효율적입니다.
- 단순 텍스트 처리
  → 지시어 정도로 충분한 작업들
언제 효과가 적을까?
- 도메인 특화 지식 (Niche Expertise)
  → 모델이 학습하지 않은 기업 내부 문서, 최신 법령, 혹은 특정 전문 분야의 기술적 깊이가 필요한 경우 할루시네이션(환각) 위험이 큽니다.
- 엄격한 출력 형식 유지
  → 복잡한 JSON 구조나 아주 특수한 문서 양식을 따라야 할 때, 예시(Few-shot) 없이는 모델이 '첫 토큰'을 엉뚱하게 잡아 형식이 무너질 수 있습니다.
- 다단계 추론
  → 논리적인 단계를 거쳐야 하는 수학 문제나 코딩 아키텍처 설계 시, 과정에 대한 가이드가 없으면 중간 단계에서 논리가 이탈하기 쉽습니다.

Few-Shot Prompting ( 퓨-샷 프롬프팅 )

(1) 한 줄 정리

퓨 샷 프롬프팅은 원하는 결과에 대한 예시를 들어서 먼저 예시(Shot) 주고 LLM이 추론하는데 패턴과 형식을 컨텍스트로 학습시키는 방법입니다.

(2) 핵심 원리

: 모델을 별도로 학습시키지 않고 , 입력된 문맥만으로 모델의 행동을 변화시키는 문맥 내 학습을 핵심으로 합니다.

→ 퓨샷 프롬프팅은 "명령(Instruction)"만으로는 부족한 작업의 "답변 패턴(Pattern)"과 "출력 형식(Format)"을 데모(예시)로 직접 보여줌으로써, 모델이 방대한 지식 중 사용자가 원하는 특정 맥락에 빠르게 안착(Anchoring)하도록 유도하는 기법입니다.

확률 분포에서의 강력한 조건부 역할
- 조로샷이 거대한 확률 지표에서 , 퓨샷은 데모라는 이정표를 미리 세웁니다.
- 이를 통해서 , 모델이 생성해야 할 후속 답변에 매우 강한 조건부 역할을 수행합니다. 즉 , 수많은 패턴 중에 사용자가 원하는 ‘특정 패턴’의 확률값을 높일 수 있습니다.
레이블 공간과 형식
- 레이블 공간 : 답변으로 나올 수 있는 후보군이 무엇인지 모델에게 미리 인지시키는것이 중요합니다.
- 입력 분포 : 어떤 종류의 텍스트가 입력될 것인지 분포를 보여주는 것만으로도 성능이 올라갑니다.
- 형식 : 예시의 정답이 틀려도 , 일정 형식을 유지시키는 것 자체가 모델이 답변궤도에 머물도록 도와주는 강력한 가이드가 됩니다.

(3) 사용 예시

 **Prompt:**
문장에서 이름, 직업, 거주지를 추출하여 JSON 형식으로 출력하세요.
  
 **입력:** "서울에 사는 프론트엔드 개발자 김철수 씨는 오늘 연차입니다."
 **출력:** {"name": "김철수", "job": "개발자", "location": "서울"}
 
 **입력:** "부산에서 카페를 운영하는 박영희 사장님을 만났습니다."
 **출력:** {"name": "박영희", "job": "자영업자", "location": "부산"}
 
 **입력:** "도쿄에서 요리사로 일하는 사토 씨가 한국에 왔습니다."
 **출력:**

→ 결과: {"name": "사토", "job": "요리사", "location": "도쿄"}

(4) 사용처

언제 사용되면 좋을까?
- 정형화된 데이터 추출 : 특정 JSON 양식 등의 엄격한 출력 구조가 필요할 때 예시를 주면 실패율이 줄어든다
- 복잡한 분류 작업 : 여러 복잡한 카테고리 분류가 필요해지면, 각 카테고리의 기준을 예시로 샷을 주면 정확도가 높아진다.
언제 효과가 적을까?
- 다단계 논리 추론 : 수학 문제나 코딩처럼 단계별 사고가 필요한 경우에는 정확도가 떨어진다.
- 맥락 창(Context Window)이 좁은 모델 : 예시가 너무 길어지면 , 실제 질문에 할당될 문맥 용량이 부족해질 수 있다.'

Chain-of-Thought (CoT) [생각의 사슬]

(1) 한 줄 정리

CoT는 복잡한 문제를 한 번에 해결하지 않고 , 논리적인 중간 추론 단계를 순차적으로 생성하여 정답의 정확도를 높이는 기법입니다.

(2) 핵심 원리

→ 복잡한 문제를 추론하기에는 어려운 프롬프팅의 한계를 개선하기 위해 , "결과(Result)"가 아닌 "사고의 과정(Reasoning)"을 퓨샷 데모로 제공하여, 모델이 스스로 정답에 도달하기 위한 중간 논리 단계를 생성하도록 유도하는 기법입니다.

추론을 통한 계산 공간을 확보합니다.
- CoT는 중간 추론 과정을 출력하게 해서, 생각할 시간과 공간을 주게 됩니다.
- 추론한 내용들이 다시 입력으로 들어가면서(AR 효과) , 최종 정답 토큰이 생성될 때의 확률 분포를 매우 정교하게 가이드 할 수 있게 됩니다.
Zero-shot Cot
- 단계별로 생각해보자 라는 문구만으로도 성능이 올라갈 수 있게 됩니다.
- 모델이 학습해둔 논리적 전개 패턴을 트리거해주게 됩니다.
- 이로써 , 단답형이 아닌, 설명형/단계형으로 강하게 전이시켜, 정답에 도달하기 위한 유의미한 결과물 도출에 도움을 줍니다.
Auto - CoT
- 수작업으로 CoT 예시를 만드는 번거로움을 해결하고 , 예시의 편향성을 줄일 수 있습니다.
- 질문 클러스터링
  - 비슷한 유형의 질문들을 묶어 모델이 다양한 논리 구조를 경험하게 해서, 특정 유형에 매몰되지 않는 입력분포를 형성시켜줍니다.
- 휴리스틱 필터링
  - 너무 짧거나 복잡한 추론보다는 , 적당한 길이와 단계를 가진 추론 체인을 샘플링해서 모델이 학습하기 좋은 양질의 논리 경로를 예시로 제공합니다.

(3) 사용 예시

Prompt

 
 **[Task]** Next.js FSD 구조에 맞춰 '상품 목록(Product List)' 기능을 구현하세요.
 
 **[FSD Folder Rule]**
 
 - `api/`: 외부 통신 로직 (Fetcher)
 - `model/`: 상태 관리 및 비즈니스 로직 (Hooks, Types)
 - `ui/`: UI 컴포넌트

**사고 과정(CoT)**
 
 - 유저 데이터를 가져오는 API 호출 함수는 `features/user/api/`에 위치해야 함.
 - 이 API를 호출하고 상태를 관리하는 리액트 훅은 `features/user/model/`에 위치해야 함.
 - 외부에서는 이 훅을 통해 데이터에 접근함.

**Result (** 파일 코드 생략 )
 - features/product-list/api/get-products.ts
 - features/product-list/model/use-products.ts

(4) 사용처

언제 사용되면 좋을까?
- 복잡한 논리 추론 : 학, 물리 문제 풀이나 논리 퀴즈 등 단계별 계산이 필요한 경우
- 코드 아키텍처 설계 : 디자인 패턴 적용, 리팩토링 로직 등 구조적 결정이 필요한 작업
언제 효과가 적을까?
- 실시간 응답이 필수인 경우: 추론 과정만큼 출력 토큰이 늘어나 응답 속도(Latency)가 느려집니다.
- 단순 사실 확인: "대한민국의 수도는?" 같은 질문에 추론 단계를 넣는 것은 비효율적입니다.

Self-Consistency [자기 일관성]

(1) 한 줄 정리

하나의 고정된 추론 경로만 따라가지 않고, 여러 개의 다양한 추론 경로를 독립적으로 생성하고 , 가장 많이 도출된 공통 답변을 최종 정답으로 선택하는 기법입니다.

(2) 핵심 원리

→ 단일 추론 경로에서 발생할 수 있는 우발적 오류(Greedy Decoding의 한계)를 극복하기 위해, 여러 번의 '생각의 사슬(CoT)'을 시도하여 결과의 신뢰도와 일관성을 확보합니다.

탐욕적 디코딩(Greedy Decoding) 대체
- 모델이 가장 확률이 높은 토큰만 선택하는 방식 대신, 다양한 후보군을 샘플링합니다.
추론 경로의 다양성 확보
- 동일 질문에 대해 조금씩 다른 논리 전개를 하도록 유도하여 , 틀린 길로 빠지는것을 방지합니다.

(3) 사용 예시

→ 사용 예시: FSD 아키텍처 리팩토링 검증

Scenario: components/Login.tsx라는 거대하고 지저분한 레거시 파일을 FSD 구조로 분리하라는 임무를 받은 에이전트.

**Prompt** 

**[Task]** 다음 레거시 파일을 FSD 구조에 맞게 리팩토링할 계획을 세우세요.
**[Rule]** 파일명과 상세 경로를 반드시 명시하세요.
**[File]** components/Login.tsx (API 호출, 유효성 검사, UI가 모두 섞여 있음) 

**Reasoning Paths (에이전트가 내부적으로 생성한 3가지 제안)**

• **시뮬레이션 1:** * API 로직 추출 → `features/auth/api/login.ts`
    ◦ 상태 관리 추출 → `features/auth/model/use-login.ts`
    ◦ UI 분리 → `features/auth/ui/login-form.tsx`
    ◦ **결정:** **`features/auth` 슬라이스로 통합.**

• **시뮬레이션 2:** * API 로직 추출 →`shared/api/auth.ts`
    ◦ 상태 관리 추출 → `features/auth/model/use-login.ts`
    ◦ UI 분리 → `features/auth/ui/login-form.tsx`
    ◦ **결정:** **API는 `shared`로, 나머지는 `features/auth`로 분리.**

• **시뮬레이션 3:** * API 로직 추출→ `features/auth/api/login.ts`
    ◦ 상태 관리 추출 → `features/auth/model/use-login.ts`
    ◦ UI 분리 → `features/auth/ui/login-form.tsx`
    ◦ **결정:** **`features/auth` 슬라이스로 통합.**

**Result (최종 의사결정)**

**[Selection]** 시뮬레이션 1과 3이 동일한 구조를 제안함.
에이전트는 **`features/auth` 내부에 모든 로직을 캡슐화하는 방안**이 가장 일관성 있다고 판단하여 해당 경로로 파일 생성을 시작함.

(4) 사용처

언제 사용되면 좋을까?
- 산술 추론 : 계산 실수가 일어나면 안되는 정밀한 작업의 경우
언제 효과가 적을까?
- 바용과 속도가 중요한 경우
- 창의적인 결과 도출이 필요한 경우

실습 및 결과 정리( [LLM 실습] 의료급여 본인부담률 추출 실험: 프롬프트 기법별 성능 비교 )

실험 정리 링크
https://github.com/DChanHong/aiagent-repo/tree/week1/DChanHong/week-2/DChanHong

: 본 포스팅에서는 의료급여 본인부담률 데이터를 바탕으로, 다양한 프롬프트 엔지니어링 기법(Zero-shot, Few-shot, CoT, Self-Consistency)이 LLM의 정답률에 미치는 영향을 실험하고 그 결과를 정리합니다.

1.실험 전 가설 설정

실습 진행 전, 데이터의 특성과 모델의 능력을 고려하여 아래와 같은 가설을 세웠습니다.

1) Zero-shot(Step 1) 정답률 예측

예측: 전체 평균 정답률 70% 이상 예상.
이유: 이미지 OCR 추출 성능이 우수하여 단순 정보 추출(Easy)은 완벽에 가깝겠지만, 복합 조건이 붙는 추론(Hard)으로 갈수록 할루시네이션 위험으로 정답률이 하락할 것으로 분석했습니다.

난이도	정답률(예측)	판단 근거
Easy	90% ~ 100%	단순 키워드 매칭 및 표 내용 추출 단계
Medium	70% ~ 80%	다중 조건(예: 2종 + 특정 질환 + 시술) 결합 시 오류 가능성
Hard	약 50%	수치 연산과 추론 로직 결합 지점에서 환각 위험 높음

2) 가장 큰 개선이 일어날 난이도 예측

예측: Medium(복합 조건 및 비교형)
이유: Easy는 이미 높아서 개선 폭이 적고, Hard는 더 많은 샘플이 필요할 것이기에 비교 조건을 명확히 인지시키는 것만으로도 Medium에서 가장 빠른 성능 향상이 있을 것이라 보았습니다.

3) 가장 큰 정답률 점프가 일어날 기법

예측: CoT(Chain-of-Thought)
이유: 표를 읽고 단계를 나누어 합산/선택하는 과정이 중요하므로, 단계적 사고를 유도하는 CoT가 가장 효과적일 것으로 판단했습니다.

2. 실험 환경 및 프롬프트 구성

실행 환경

Model: gemini-2.5-flash-lite (OpenAI 호환 엔드포인트)
SDK: openai Python SDK, pydantic (구조화된 출력 검증)
Data: 이미지 OCR 결과물인 extracted-reference.md를 공통 참조 데이터로 사용

프롬프트 전략

모든 Step에서 구조화된 출력(JSON)을 강제하여 평가의 객관성을 확보했습니다.

JSON

{ "answer": "최종 답안", "reason": "판단 근거 요약" }

3. 실험 결과 요약

Step	프롬프트 구성	정확도	평균 토큰/문항	비고
Zero-shot	참조 데이터 + 직접 추론	0.9333	1,458	예측 상회 (기본 성능 우수)
Few-shot	예시 3개 추가	1.0	1,816	정답률 100% 도달
CoT	추론 단계 유도	1.0	1,993	초기 설계 시 형식 흔들림 주의
Self-Consistency	다수결 채택	1.0	6,741	비용/시간 대폭 증가

4. 가설 vs 실제 결과 비교 (인사이트)

실험 전 세운 가설과 실제 데이터를 대조해 본 결과, 몇 가지 흥미로운 점을 발견했습니다.

가설 1: Zero-shot 정답률은 70% 이상일 것이다? (적중)

실제 결과는 93.3%로 가설을 크게 상회했습니다. 텍스트로 잘 정리된 extracted-reference.md를 제공하자 모델이 Hard 난이도에서도 뛰어난 추론 능력을 보여주었습니다. "데이터 전처리의 중요성"을 다시 한번 확인했습니다.

가설 2: Medium 난이도에서 가장 큰 개선이 있을 것이다? (불일치)

실제로는 Hard 난이도에서 실질적인 개선이 일어났습니다. Zero-shot에서 이미 Medium이 완벽에 가까웠기에, 남은 오답 2개를 해결한 Few-shot과 CoT의 기여는 Hard 문항에 집중되었습니다.

가설 3: CoT가 가장 큰 점프를 만들 것이다? (불일치)

가장 큰 정답률 점프는 Few-shot(0.9333 → 1.0)에서 발생했습니다. 이번 실험처럼 정답 형식이 고정된(Exact Match) 과제에서는 복잡한 추론 과정보다 "이런 형식으로 답하라"는 명확한 예시가 더 강력한 트리거가 됨을 배웠습니다.

결론 및 느낀 점

단순함의 중요성: 무조건 복잡한 CoT나 Self-Consistency를 쓰기보다, 잘 정리된 데이터와 Few-shot 예시 몇 개가 더 가성비 좋은 해결책이 될 수 있습니다.
비용 대비 효율: Self-Consistency는 정확도는 높지만 토큰 소모가 4배 이상 많습니다. 서비스 설계 시 정확도와 비용 사이의 Trade-off를 반드시 고려해야 합니다.
프롬프트의 디테일: CoT 적용 시 '과정'에 너무 치중하면 '최종 답변 형식'이 망가질 수 있습니다. 답변 형식을 고정하는 추가 지시가 반드시 병행되어야 합니다.

참고문헌

https://www.promptingguide.ai/kr/techniques

https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices

https://ai.google.dev/gemini-api/docs/prompting-strategies