영수증 정보 추출 —
프롬프트 전략 비교
같은 영수증, 같은 모델이라도 프롬프트 전략에 따라 출력 품질이 달라진다. 이 실습이 끝나면 Zero-shot부터 System+Few-shot까지 4가지 전략을 한 앱에서 갈아 끼우며 비교한 결과표와, 내 업무에 맞춘 나만의 영수증 분석 프롬프트가 손에 남는다.
왜 영수증이고, 왜 전략인가
입력이 비정형이고 정확도 요구가 높은 태스크에서는 프롬프트 설계의 차이가 결과에 즉시 드러난다.
왜 영수증 처리인가
영수증은 프롬프트 전략의 효과를 비교하기에 이상적인 재료다. 입력이 제각각이고, 숫자 하나만 틀려도 실패가 드러나고, 결과를 실무에 바로 쓸 수 있기 때문이다.
4가지 프롬프트 전략
이번 실습에서 같은 영수증에 차례로 적용할 전략은 네 가지다. 무엇을 언제 쓰는지가 핵심이다.
| 전략 | 방법 | 적합한 상황 |
|---|---|---|
| Zero-shot | 예시 없이 지시만 | 간단한 분류, 번역 |
| Few-shot | 예시 2~3개 포함 | 형식 일관성 필요할 때 |
| CoT | '단계별로 생각해줘' 추가 | 계산·추론 포함 태스크 |
| System Prompt | 모델에 역할·규칙 사전 부여 | 도메인 특화 응답 필요할 때 |
프롬프트 품질이 결과에 미치는 영향 (같은 영수증, 같은 모델)
- Zero-shot → 필드 누락, 형식 불일치 빈번
- Few-shot → 형식 안정, 누락 감소
- CoT → 합계 계산 오류 현저히 감소
- Sys+Few → 경비 처리 규정 자동 반영, 업무 즉시 적용 가능
네 전략은 서로 배타적이지 않다. 마지막 Step 5에서 보듯 System Prompt와 Few-shot은 함께 쓸 때 가장 강력하다. 실습의 목표는 "어느 전략이 최고인가"를 외우는 것이 아니라, 내 태스크의 실패 모드(형식 불일치인가, 계산 오류인가, 규정 미반영인가)에 맞는 전략을 고르는 감각을 만드는 것이다.
시나리오와 샘플 영수증
실습 내내 아래 샘플 영수증 하나를 동일하게 사용한다. 입력을 고정해야 전략 간 차이가 보인다.
영수증 정보 추출기 구축
출장비 정산 담당자가 종이 영수증을 사진 찍어 업로드하면 자동으로 가게명·날짜·항목·합계를 추출해 경비 처리 양식으로 변환하는 Gradio 앱을 만든다.
비교 실험의 원칙은 하나다. 입력(영수증)과 모델은 고정하고 프롬프트 전략만 바꾼다. 그래야 출력의 차이를 전략의 차이로 귀속시킬 수 있다.
샘플 영수증 (실습 내내 동일 사용)
한식당 서울갈비 서울시 강남구 테헤란로 123 Tel: 02-1234-5678 -------------------------------------------- 2024-01-15 (월) 12:35 영수증번호: 20240115-0892 -------------------------------------------- 삼겹살 (2인분) 26,000 냉면 (1) 12,000 소주 (2병) 10,000 공기밥 (1) 1,000 -------------------------------------------- 소계 49,000 부가세 (10%) 4,900 합계 53,900 -------------------------------------------- 신용카드 결제 카드: **** **** **** 1234 승인번호: 12345678
이 샘플에는 전략 간 차이를 드러내는 함정이 미리 심어져 있다. "삼겹살 (2인분)"의 수량 해석, 소계·부가세·합계의 계산 일관성, 그리고 주류(소주) 항목이 그것이다. 각 Step에서 이 세 지점이 어떻게 처리되는지 관찰하라.
같은 3H의 프롬프트 전략을 창의적 도메인에서 적용해 보는 다른 시나리오도 있다. RAG 타로 실습(04_tarot.html)에서 같은 기법이 전혀 다른 태스크에 쓰이는 것을 비교해 보면 좋다.
앱을 만들고, 전략을 갈아 끼운다
Claude Code로 Gradio 앱을 만든 뒤, Zero-shot → Few-shot → CoT → System+Few 순서로 같은 영수증을 분석한다.
Gradio 앱 기본 구조 생성
먼저 터미널에서 claude를 실행하고, 아래 요청으로 전략 선택형 영수증 분석 앱을 만든다.
receipt_analyzer 폴더를 만들고 다음 Gradio 앱을 구현해줘:
- 왼쪽 패널: 영수증 텍스트를 붙여넣을 수 있는 큰 텍스트박스
- 가운데: 프롬프트 전략 선택 라디오버튼 (Zero-shot / Few-shot / CoT / System+Few)
- 오른쪽: 추출 결과 표시 텍스트박스
- 하단: '분석하기' 버튼
LLM은 HuggingFace Qwen3-8B, HF_TOKEN은 환경변수에서 읽어와.
결과는 JSON 형식으로 출력해줘:
{가게명, 날짜, 항목[{이름, 금액}], 소계, 부가세, 합계, 결제수단}
앱이 생성되면 실행한다.
python receipt_analyzer/app.py
- 브라우저에서 앱이 열리고 텍스트박스·라디오버튼·분석 버튼이 보인다
- 샘플 영수증을 붙여넣을 준비가 되었다
Zero-shot 테스트 — 지시만 던져 본다
예시 없이 지시 한 줄만 준다. 이 결과가 이후 모든 전략의 비교 기준선(baseline)이 된다.
아래 영수증에서 정보를 추출해서 JSON으로 반환해줘.\n\n{영수증텍스트}
예상 결과
- 가게명·합계는 대체로 맞음
- 항목 목록 누락·형식 불일치 발생 가능
- 부가세 계산이 틀리거나 필드명이 다를 수 있음
- Zero-shot 전략으로 샘플 영수증을 분석해 결과 JSON을 확인했다
- 어떤 필드가 누락되거나 필드명이 흔들리는지 기록했다
출력 JSON의 필드명이 실행할 때마다 달라진다면, 이 출력을 받아 쓰는 다음 시스템(경비 처리 양식)은 무엇을 기준으로 파싱해야 하는가? 형식을 고정하려면 무엇을 프롬프트에 넣어야 할까 — 이것이 다음 Step의 주제다.
Few-shot 프롬프트 적용 — 예시로 형식을 고정한다
입력·출력 예시 2개를 프롬프트에 포함시킨다. 모델은 예시의 필드명과 구조를 그대로 따라온다.
예시1 입력: 스타벅스 강남점 / 2024-01-10 / 아메리카노(1) 4,500 / 합계 4,500 / 신용카드
예시1 출력: {"가게명":"스타벅스 강남점","날짜":"2024-01-10","항목":[{"이름":"아메리카노","수량":1,"금액":4500}],"합계":4500,"결제수단":"신용카드"}
예시2 입력: 편의점GS25 / 2024-01-12 / 생수(2) 1,800 삼각김밥(1) 1,200 / 합계 3,000 / 현금
예시2 출력: {"가게명":"GS25","날짜":"2024-01-12","항목":[{"이름":"생수","수량":2,"금액":1800},{"이름":"삼각김밥","수량":1,"금액":1200}],"합계":3000,"결제수단":"현금"}
예상 개선
- JSON 필드명·구조가 예시와 일치
- 수량 필드 자동 추출
- 형식 일관성 크게 향상
- Few-shot 전략으로 같은 영수증을 다시 분석했다
- Zero-shot 결과와 비교해 필드명·구조가 안정되었는지 확인했다
형식은 안정되었지만 소계·부가세·합계의 숫자는 여전히 틀릴 수 있다. 예시는 "어떻게 쓸지"를 가르치지만 "어떻게 계산할지"는 가르치지 않기 때문이다. 계산 정확도를 올리는 것이 다음 Step이다.
Chain of Thought 적용 — 계산 순서를 지정한다
추출 순서를 단계로 명시하고 "직접 계산 후 비교"를 요구한다. 계산·추론이 끼는 태스크에서 오류를 줄이는 전략이다.
분석 순서: 1. 가게명과 날짜를 먼저 찾는다 2. 항목 목록을 순서대로 읽으며 이름·수량·단가를 추출한다 3. 소계 = 모든 항목 금액의 합 (직접 계산 후 영수증 값과 비교) 4. 부가세와 합계를 확인한다 5. 결제 수단을 마지막으로 확인한다 위 순서대로 생각하고 JSON을 반환해줘.
예상 개선
- 항목 합계 계산 오류 현저히 감소
- 소계·부가세·합계 불일치 탐지
- '2인분 → 수량:2' 정확도 향상
- CoT 전략으로 같은 영수증을 분석해 소계(49,000)가 항목 합과 일치하는지 확인했다
- "삼겹살 (2인분)"이 수량 2로 추출되는지 확인했다
계산은 맞아졌지만, 이 결과는 아직 "우리 회사 경비 규정"을 모른다. 소주 10,000원이 식사비에 섞여 있어도 그대로 통과된다. 규정을 모델에 심는 것이 마지막 전략이다.
시스템 프롬프트 + 도메인 페르소나
모델에 역할과 업무 규칙을 사전 부여한다. Few-shot 예시도 함께 유지하면, 형식 안정과 규정 반영을 동시에 얻는다.
당신은 삼성전자 경비처리 시스템의 영수증 분석 AI입니다. 다음 규칙을 따릅니다: - 식사비는 2인 이하 가능, 초과 시 approval_required: true 표시 - 주류(소주, 맥주, 와인 등)는 별도 항목으로 분리 - 부가세가 없는 영수증은 tax_exempt: true 표시 - 출력에 expense_category 필드 추가: 식사비/교통비/숙박비/기타 중 분류
(Few-shot 예시도 함께 유지)
예상 개선
- 주류(소주 10,000원) 자동 분리
- 2인 초과 여부 판단 → approval_required
- expense_category "식사비" 자동 분류
- 업무 규정 내재화로 별도 후처리 불필요
- System+Few 전략으로 분석해 소주가 별도 항목으로 분리되는지 확인했다
- expense_category와 approval_required 필드가 출력에 나타나는지 확인했다
규칙을 코드(후처리)로 구현하는 대신 시스템 프롬프트로 심으면 무엇이 좋고 무엇이 위험한가? 규정이 바뀔 때 수정이 쉬운 대신, 모델이 규칙을 빠뜨릴 가능성은 남는다. 어떤 규칙은 프롬프트로, 어떤 규칙은 코드 검증으로 이중화할지 생각해 보라.
결과를 표로 비교하고, 나만의 프롬프트를 만든다
네 전략의 출력을 직접 채점한 뒤, 그 기준으로 내 업무에 맞는 프롬프트를 설계한다.
4가지 전략 비교 결과표 — 직접 채우기
각 전략의 실제 출력을 보고 아래 표를 직접 채운다. 채점 기준은 6가지다.
| 비교 항목 | Zero-shot | Few-shot | CoT | Sys+Few |
|---|---|---|---|---|
| JSON 형식 일치 | ||||
| 항목 수 정확도 | ||||
| 합계 계산 정확도 | ||||
| 주류 분리 여부 | ||||
| 업무 규정 반영 | ||||
| 종합 평가 |
- 네 전략 모두 같은 샘플 영수증으로 실행해 결과를 표에 기록했다
- 어떤 항목이 어느 전략에서 처음 개선되었는지 표에서 확인했다
나만의 최적 프롬프트 설계
비교표에서 얻은 감각으로, 대괄호 부분을 내 업무 상황으로 바꿔 나만의 프롬프트를 설계 요청한다.
아래 내용을 참고해서 내 업무용 영수증 분석 프롬프트를 설계해줘: 업무 유형: [예: 구매 팀 / 해외 출장 / 연구 개발비 처리] 추가 필요 필드: [예: 프로젝트 코드, 비용 센터, 외화 환율] 규정 반영: [예: 건당 10만원 초과 시 영수증 필수, 주류 불인정] 이 조건으로 system 프롬프트와 few-shot 예시를 작성해줘.
- 대괄호 세 곳을 내 업무 상황으로 채워 요청했다
- 생성된 system 프롬프트와 few-shot 예시를 앱에 적용해 샘플 영수증으로 검증했다
생성된 프롬프트가 첫 시도에 완벽할 필요는 없다. 실패하는 영수증 사례를 만나면 그 사례를 few-shot 예시로 추가하는 것이 가장 빠른 개선 루프다. 프롬프트는 한 번 쓰고 버리는 문장이 아니라, 변수만 바꿔 재사용하는 템플릿(Prompt Template)으로 관리한다.
체크리스트와 핵심 용어
네 전략의 차이를 내 손으로 확인했는지 점검한다.
이 실습의 요점
하나. 같은 영수증, 같은 모델이라도 프롬프트 전략이 출력 품질을 결정한다. Zero-shot의 실패 모드(누락·형식 불일치)를 기준선으로 삼아야 개선이 보인다.
둘. 전략마다 고치는 문제가 다르다. Few-shot은 형식을, CoT는 계산을, System Prompt는 도메인 규정을 잡는다. 그래서 실무 최적해는 대개 System + Few-shot 조합이다.
셋. 최종 산출물은 일회성 문장이 아니라 재사용 가능한 프롬프트 템플릿이다. 실패 사례를 few-shot 예시로 추가하며 개선한다.
실습 체크리스트
- Gradio 앱 실행
- Zero-shot 한계 파악
- Few-shot 형식 개선
- CoT 계산 정확도
- 시스템 프롬프트 규정 내재화
- 비교표 완성
- 커스텀 프롬프트 설계
핵심 용어
| 용어 | 의미 |
|---|---|
| Zero-shot | 예시 없이 지시만으로 요청하는 프롬프트 전략 |
| Few-shot | 입력·출력 예시 2~3개를 포함해 형식을 고정하는 전략 |
| CoT | Chain of Thought. '단계별로 생각해줘'를 추가해 계산·추론 정확도를 올리는 전략 |
| System Prompt | 모델에 역할·규칙을 사전 부여하는 전략 |
| Structured Output | JSON 등 형식 강제 |
| Prompt Template | 변수만 바꿔 재사용 |
다음 시간(4H)에는 RAG·시스템 프롬프트·대화 히스토리를 결합한 컨텍스트 엔지니어링으로 넘어간다. 같은 3H 프롬프트 전략을 창의적 도메인에 적용하는 RAG 타로 실습이 그 다리다.
원본 삼성전자 GenAI Lv4 특강 3H 노션 실습 자료, indecisive-pyramid-af1.notion.site (3H)
이 자료는 단일 HTML 파일로 배포되며, 프롬프트 블록의 [복사] 버튼으로 원문을 그대로 복사해 실습에 사용할 수 있다.