도메인 4: 프롬프트 엔지니어링 및 구조화된 출력 (20%) — 심화편
비중: 전체 시험의 20%
태스크: 6개 (4.1 ~ 4.6)
교차 시나리오: CI/CD를 위한 Claude Code, 구조화된 데이터 추출
핵심 기술: few-shot 예시,tool_use, JSON 스키마,tool_choice, Message Batches API, Pydantic
이 도메인의 이름에 “프롬프트 엔지니어링”이 들어 있지만, 일반적인 문장 다듬기 요령을 다루는 것은 아니다. 초점은 구조화된 출력의 신뢰성이다. 모델이 JSON 스키마에 맞는 데이터를 일관되게 추출하게 만들고, 오탐을 줄이며, 검증에 실패하면 스스로 교정하도록 하고, 대량 처리에서 비용과 지연을 최적화하는 것, 이것이 이 도메인이 평가하는 능력이다.
시나리오 5(CI/CD)와 시나리오 6(구조화된 데이터 추출)이 이 도메인의 주요 출제 맥락이다. 두 시나리오 모두 “모델 출력의 정밀도와 일관성을 어떻게 보장하는가”라는 동일한 질문을 다른 상황에서 묻는다.
이 장은 아래 세 질문을 기준으로 읽으면 전체 흐름이 잘 잡힌다.
- 지금 문제는 판단 기준이 모호한 것인가, 아니면 출력 형식이 불안정한 것인가?
- 이 실패는 프롬프트 개선으로 줄일 수 있는가, 아니면 스키마/검증/도구 호출이 필요한가?
- 이 워크플로는 실시간 응답이 필요한가, 아니면 지연을 감수하고 대량 처리 비용을 낮출 수 있는가?
Domain 4 Concept Primer
이 도메인은 단순히 JSON을 예쁘게 출력하는 법을 다루지 않는다.
핵심은 모델 출력이:
- 계약처럼 정의되고
- 스키마로 구조화되고
- few-shot으로 일관성이 강화되고
- 검증과 복구 루프로 신뢰성을 높이고
- 대량 처리 상황에서도 운영 가능하며
- 사람과 시스템이라는 서로 다른 소비자에게 맞게 표현될 수 있는지
를 다루는 데 있다.
즉 Domain 4의 핵심은:
모델 출력이 자유 텍스트를 넘어, 검증 가능하고 일관되며 후속 시스템이 신뢰할 수 있는 형태가 되도록 설계하는 것
이다.
특히 아래 개념 문서를 같이 보면 흐름이 훨씬 잘 잡힌다.
- Structured Output as Contract: 출력 형식과 의미를 계약으로 보는 관점
- Schema Design for Reliability: 스키마를 검증 구조이자 출력 유도 구조로 설계하는 법
- Few-shot Patterns for Output Consistency: 출력 패턴 일관성을 높이는 예시 설계
- Validation, Repair & Retry Loops: 출력 실패를 검증·복구·재생성으로 다루는 루프
- Batch Generation Strategy: 처리량과 품질 균형을 운영 전략으로 다루는 법
- Human-readable vs Machine-usable Outputs: 사람용 출력과 시스템용 출력을 구분하는 법
4.1 — “보수적으로 하라”는 왜 통하지 않는가
관련 개념 문서: Few-shot Patterns for Output Consistency, Structured Output as Contract
모호한 지시의 실패 메커니즘
CI/CD 파이프라인에서 Claude로 코드 리뷰를 자동화한다고 가정하자. 오탐(false positive), 즉 실제로는 문제가 아닌데 문제라고 잘못 보고하는 사례가 많아져서 개발자들이 리뷰 결과를 무시하기 시작했다. 자연스러운 반응은 시스템 프롬프트에 “보수적으로 판단하라” 또는 “확신이 높은 결과만 보고하라”를 추가하는 것이다.
이것이 왜 작동하지 않을까? 핵심은, 이런 지시가 무엇을 플래그해야 하는지를 정의하지 않는다는 점이다. “보수적으로”는 모델에게 덜 확신을 가지라고 요청하는 것이지, 어떤 패턴이 진짜 문제인지를 알려주는 것이 아니다. 모델은 어려운 경우에서 확신을 낮추는 것이 아니라, 무작위적으로 일부 결과를 억제할 뿐이다.
판별 공식으로 줄이면 이렇다.
"보수적으로"는 태도가 아니라서 기준이 아니다."이 조건이면 보고, 이 조건이면 건너뛴다"가 실제 기준이다.- 오탐을 줄이려면 자신감 조절이 아니라 판단 경계 정의가 먼저다.
명시적 기준이란 무엇인가
효과적인 대안은 플래그해야 할 조건과 무시해야 할 조건을 구체적으로 정의하는 것이다.
| 접근 | 예시 | 결과 |
|---|---|---|
| ✗ 모호한 지시 | ”주석이 정확한지 확인하라” | 모델이 “정확”의 기준을 모름 → 과다 플래그 |
| ✗ 자신감 필터 | ”확신이 높은 결과만 보고하라” | 모델의 자신감이 실제 정확도와 상관없음 |
| ✓ 명시적 기준 | ”주석에서 주장하는 동작이 실제 코드 동작과 직접적으로 모순되는 경우에만 플래그하라” | 명확한 판단 기준 → 일관된 결과 |
오탐이 미치는 파급 효과
여기서 이해해야 할 중요한 역학이 있다. 오탐 비율이 높은 한 개 카테고리가 있으면, 개발자는 그 카테고리의 결과만 무시하는 것이 아니라 전체 리뷰 시스템에 대한 신뢰를 잃는다. 정확한 카테고리의 결과까지 무시하게 된다.
이 문제에 대한 실용적 대응은 두 가지다:
- 문제가 되는 카테고리의 프롬프트를 개선하는 동안 해당 카테고리를 일시적으로 비활성화한다. 부정확한 결과를 계속 보여주는 것보다, 해당 영역을 아예 안 보여주는 것이 전체 시스템 신뢰도에 이롭다.
- 심각도 수준(severity level)을 구체적인 코드 예시와 함께 정의한다. “Critical”이 무엇인지를 추상적으로 설명하는 대신, 실제 코드 스니펫으로 “이것이 Critical이다, 이것은 Warning이다”를 보여준다.
어떤 이슈를 보고하고, 어떤 것을 건너뛸 것인가
구체적인 리뷰 기준을 설계할 때는, 보고할 것과 건너뛸 것의 목록을 함께 정의해야 한다.
보고 대상:
- 버그: null 참조, 배열 범위 초과, 타입 불일치
- 보안: SQL 인젝션, 인증 없는 엔드포인트, 하드코딩된 비밀 정보
건너뛸 대상:
- 경미한 스타일 이슈: 변수 네이밍 선호, 줄 바꿈 위치
- 로컬 패턴: 해당 모듈에서만 사용되는 관용적 표현
이렇게 명시하면, 모델이 “이것을 보고해야 하는가?”를 판단할 때 자신감 추정이 아닌 명확한 기준 대조를 수행하게 된다. 보고 대상을 정의하는 것만으로는 충분하지 않다. 건너뛸 대상을 함께 명시해야, 모델이 경계 사례를 “혹시 중요할지도 모른다”며 과잉 보고하는 경향을 줄일 수 있다.
4.2 — Few-shot 예시는 왜 이렇게 효과적인가
관련 개념 문서: Few-shot Patterns for Output Consistency
지시만으로 부족한 이유
상세한 지시문을 아무리 잘 작성해도, 일부 작업에서는 출력이 일관되지 않다. 매번 다른 형식으로 결과가 나오거나, 모호한 상황에서 판단이 갈리거나, 특정 문서 구조를 제대로 처리하지 못한다.
Few-shot 예시가 이 문제를 해결하는 이유는, 예시가 제공하는 것이 규칙이 아니라 판단의 사례이기 때문이다. 모델은 예시에서 암묵적 패턴을 추출하고, 새로운 상황에 그 패턴을 **일반화(generalize)**한다.
핵심은 다음과 같다: few-shot 예시는 미리 지정된 케이스만 매칭하는 것이 아니라, 새로운 패턴에 대해서도 일관된 판단을 내리게 해준다.
빠르게 고르는 기준도 기억해 두면 좋다.
- 해야 할 일은 분명한데 결과 형식이나 경계 판단이 흔들리면 few-shot 추가
- 요구사항 자체가 빠졌거나 우선순위가 불명확하면 지시문 보강
- 둘 다 문제면, 지시문으로 기준을 세우고 few-shot으로 경계 사례를 시연한다
Few-shot 예시 설계의 원칙
| 원칙 | 설명 | 예시 |
|---|---|---|
| 모호한 상황을 포함 | 명확한 경우보다 경계 사례를 보여줄 때 효과가 큼 | 도구 선택이 애매한 요청, 두 답이 모두 가능한 추출 |
| 추론 과정을 보여줌 | 왜 이 선택을 했는지를 함께 제시 | ”이 요청은 주문 ID를 포함하므로 lookup_order를 사용 — get_customer가 아님” |
| 출력 형식을 시연 | 원하는 정확한 구조를 보여줌 | {file: "api.ts", line: 42, severity: "high", issue: "...", fix: "..."} |
| 허용 패턴도 포함 | 이슈가 아닌 것도 보여줘야 오탐 감소 | ”이 패턴은 해당 모듈의 관용적 표현이므로 플래그하지 않음” |
| 다양한 구조 포함 | 문서 형식이 다양할 때 각 형식의 예시 제공 | 인라인 인용, 참고문헌 목록, 서술문, 표 형식 |
적정 개수
2~4개의 타겟된 예시가 일반적으로 효과적이다. 핵심은 양이 아니라 다양성과 모호성 커버리지이다. 명확한 경우 10개보다 모호한 경우 3개가 더 효과적이다.
Few-shot이 할루시네이션을 줄이는 원리
추출 작업에서 모델이 원본에 없는 정보를 날조하는(hallucination) 경우가 있다. Few-shot 예시에 **“원본에 해당 정보가 없을 때 null을 반환하는 사례”**를 포함하면, 모델이 “정보가 없으면 만들어내지 않는다”는 행동을 학습한다.
예를 들어:
예시: 입력 문서에 발행일이 없음
출력: {"publication_date": null, "confidence": "absent"}
설명: 문서에 날짜 정보가 명시되어 있지 않으므로 null을 반환
이 한 가지 예시가 “모든 필드를 채워야 한다”는 모델의 암묵적 경향을 깨뜨린다.
4.3 — tool_use로 구조화된 출력을 어떻게 보장하는가
관련 개념 문서: Structured Output as Contract, Schema Design for Reliability
왜 tool_use인가
모델에게 “JSON으로 응답하라”고 프롬프트에 지시하는 것만으로는 JSON 구문 오류를 완전히 막을 수 없다. 닫히지 않은 괄호, 잘못된 쉼표, 키에 따옴표 누락 같은 오류가 간헐적으로 발생한다.
tool_use와 JSON 스키마를 결합하면, Claude는 스키마를 준수하는 구조화된 출력을 보장한다. 구문 오류(syntax error)가 제거된다.
| 접근 | 보장 수준 | 흔한 실패 |
|---|---|---|
| 프롬프트로 “JSON으로 답하라” 지시 | 낮음 | JSON 구문 오류, 필드 누락, 형식 흔들림 |
tool_use + 스키마 | 높음 | 구문 오류는 방지되지만 의미 오류는 여전히 가능 |
그러나 여기서 한 가지 중요한 구분이 있다.
| 오류 유형 | tool_use로 방지되는가 | 예시 |
|---|---|---|
| 구문 오류 (syntax error) | ✓ 예 | 닫히지 않은 괄호, 잘못된 쉼표 |
| 의미 오류 (semantic error) | ✗ 아니오 | 항목 합계 불일치, 값이 잘못된 필드에 배치 |
다시 말해, tool_use는 출력의 형식적 정확성을 보장하지만, 출력의 내용적 정확성까지 보장하지는 않는다. 의미 오류를 잡으려면 별도의 검증 단계(4.4)가 필요하다.
추출 도구의 스키마 설계
스키마를 설계할 때 가장 중요한 결정은 필드를 필수(required)로 할 것인가, 선택(optional/nullable)으로 할 것인가이다.
| 설계 선택 | 효과 | 위험 |
|---|---|---|
모든 필드를 required로 설정 | 빈 출력 방지 | 원본에 해당 정보가 없을 때 모델이 값을 날조할 수 있음 |
정보가 없을 수 있는 필드를 nullable로 설정 | 모델이 “모름”을 표현할 수 있음 | 필드 누락이 정상 경로가 됨 |
핵심 원칙: 원본 문서에 해당 정보가 존재하지 않을 수 있는 필드는 반드시 nullable로 설계한다. 이렇게 해야 모델이 빈 값을 채우기 위해 정보를 날조하는 것을 방지할 수 있다.
짧은 선택 규칙은 이렇다.
- 원문에 항상 존재해야 하는 값만
required - 문서마다 없을 수 있는 값은
nullable - “비어 있으면 안 된다”는 제품 요구와 “원문에 없을 수도 있다”는 데이터 현실을 혼동하면 안 된다
유용한 스키마 패턴 세 가지
패턴 1: “unclear” enum 값
모호한 경우를 위한 탈출구를 제공한다.
{
"document_type": {
"type": "string",
"enum": ["invoice", "receipt", "contract", "unclear"]
}
}모델이 문서 유형을 확신할 수 없을 때, 잘못된 유형을 선택하는 대신 “unclear”를 반환할 수 있다.
패턴 2: “other” + detail string
미리 정의된 카테고리에 맞지 않는 경우를 처리한다.
{
"category": {
"type": "string",
"enum": ["payment", "refund", "inquiry", "other"]
},
"category_detail": {
"type": ["string", "null"],
"description": "category가 'other'일 때만 사용. 구체적인 분류를 기술"
}
}패턴 3: 형식 정규화 규칙을 프롬프트에 포함
원본 문서의 형식이 일관되지 않을 때(날짜가 “2026-03-12”, “March 12, 2026”, “12/03/2026” 등으로 섞여 있을 때), 스키마만으로는 형식을 통일할 수 없다. 프롬프트에 정규화 규칙(“모든 날짜를 ISO 8601 형식으로 변환하라”)을 명시하고, 스키마에서도 형식을 강제하는 것이 올바른 접근이다.
tool_choice를 추출 시나리오에서 활용하는 법
tool_choice 설정 | 추출 시나리오 | 이유 |
|---|---|---|
"any" | 문서 유형을 모르고, 여러 추출 스키마(인보이스용, 영수증용, 계약서용)가 존재 | 모델이 문서를 보고 적합한 스키마를 선택하도록 함 |
{"type": "tool", "name": "extract_metadata"} | 메타데이터를 먼저 추출한 후, 보강 도구를 실행하는 순서가 중요 | 첫 번째 턴에서 특정 도구를 강제하고, 후속 턴에서 나머지 처리 |
짧은 흐름으로 보면 더 명확하다.
| 상황 | 1턴 설정 | 다음 턴 |
|---|---|---|
| 문서 유형이 미상 | tool_choice = "any" | 선택된 추출 결과를 검증/후처리 |
| 메타데이터를 먼저 뽑아야 함 | tool_choice = extract_metadata 강제 | 그 결과를 바탕으로 보강 도구 선택 |
4.4 — 추출이 실패하면 어떻게 교정하는가
관련 개념 문서: Validation, Repair & Retry Loops, Schema Design for Reliability
재시도의 핵심: 에러 피드백을 함께 보내라
검증에 실패한 추출 결과를 단순히 “다시 해 줘”라고 요청하면 효과가 없다. 효과적인 재시도는 세 가지를 함께 보내는 것이다:
후속 요청 구성:
1. 원본 문서 (변경 없이 그대로)
2. 이전에 실패한 추출 결과
3. 구체적인 검증 오류 (어떤 필드가, 어떻게, 왜 실패했는지)
이렇게 하면 모델이 자기 이전 출력을 보면서, 구체적으로 무엇이 잘못되었는지를 인식하고 교정할 수 있다.
재시도 판단은 아래처럼 나누면 된다.
- 형식이나 배치가 잘못되었는가? → 재시도 가치가 높다.
- 원문에 정보가 실제로 있는가? → 없으면 재시도하지 말아야 한다.
- 외부 문서가 빠졌는가? → 재시도보다 입력 확장이 먼저다.
재시도가 효과 있는 경우와 없는 경우
이 구분은 시험에서 판단력을 측정하는 데 사용된다. 재시도를 시도해도 원천적으로 성공할 수 없는 경우를 식별해야 한다.
| 상황 | 재시도 효과 | 이유 |
|---|---|---|
| 출력 형식이 스키마와 불일치 | ✓ 효과적 | 모델이 형식 규칙을 놓친 것 — 피드백을 보면 교정 가능 |
| 필드 값이 잘못된 위치에 배치됨 | ✓ 효과적 | 구조적 오류 — 피드백으로 교정 가능 |
| 필요한 정보가 원본 문서에 아예 없음 | ✗ 효과 없음 | 없는 정보는 몇 번을 시도해도 나타나지 않음 |
| 정보가 별도의 외부 문서에만 존재 | ✗ 효과 없음 | 해당 문서가 제공되지 않는 한 불가능 |
재시도가 효과 없는 경우를 인식하는 것이 중요하다. 불필요한 재시도는 비용과 지연만 증가시킨다.
자기 교정을 위한 스키마 설계 패턴
패턴 1: detected_pattern 필드
코드 리뷰 결과에 detected_pattern 필드를 추가하면, 개발자가 결과를 dismiss할 때 어떤 패턴이 오탐을 유발하는지 체계적으로 분석할 수 있다.
{
"finding": "잠재적 null 참조",
"severity": "high",
"detected_pattern": "optional_chaining_missing",
"file": "api/orders.ts",
"line": 42
}시간이 지나면 “optional_chaining_missing 패턴의 dismiss율이 80%“라는 데이터가 쌓이고, 이 패턴에 대한 리뷰 기준을 조정할 수 있다.
패턴 2: 교차 검증 필드
금액 추출에서 정확성을 높이려면, 계산된 합계와 명시된 합계를 모두 추출하고 불일치를 감지한다.
{
"line_items": [...],
"calculated_total": 1250.00,
"stated_total": 1350.00,
"totals_match": false,
"conflict_detected": true
}패턴 3: conflict_detected 불리언
원본 문서 내에서 모순되는 데이터가 발견되면 플래그한다. 예를 들어, 문서 앞부분에서 “계약 기간 12개월”이라고 했는데, 뒷부분에서 “24개월 갱신 조건”이라고 되어 있으면 conflict_detected: true로 표시한다.
4.5 — Batch API를 언제 쓰고, 언제 쓰지 말아야 하는가
관련 개념 문서: Batch Generation Strategy
Message Batches API의 특성
| 특성 | 값 |
|---|---|
| 비용 절감 | 50% (입력 + 출력 토큰 모두) |
| 처리 기간 | 최대 24시간 |
| 지연 시간 SLA | 보장 없음 — “보통 더 빠르다”고 해도 의존 불가 |
| 멀티턴 tool calling | 단일 요청 내에서 지원되지 않음 |
| 요청-응답 매칭 | custom_id 필드로 상관 관계 추적 |
핵심 판단: 지연 시간을 감당할 수 있는가
이 결정은 비용이 아니라 지연 시간에 대한 수용 가능성으로 내려야 한다. 시험 개요에서 다룬 5가지 사고 모델 중 5번째(“Batch API는 비용 결정이 아니라 지연 시간 결정이다”)가 여기서 직접 적용된다.
즉, 비용 절감은 batch를 쓰는 이유일 수는 있어도, 배치 사용 가능 여부를 결정하는 1차 기준은 아니다. 먼저 “이 작업이 최대 24시간 늦어져도 되는가?”를 묻고, 그 다음에 비용 절감을 본다.
| 워크플로 | API 선택 | 판단 근거 |
|---|---|---|
| Pre-merge 검사 (개발자가 결과를 기다림) | 실시간 | 차단 워크플로 — 24시간 대기 불가 |
| 실시간 고객 상호작용 | 실시간 | 응답 지연 불가 |
| 야간 기술 부채 보고서 | Batch | 다음 날 아침 검토 — 24시간 수용 가능 |
| 주간 감사 보고서 | Batch | 비차단, 주기적 |
| 야간 테스트 생성 | Batch | 비차단, 다음 날 확인 |
공식 샘플 문제 11번
이 문제는 batch API의 판단 기준을 정확히 묻는다:
두 가지 워크플로가 있습니다: (1) 차단형 pre-merge 검사, (2) 야간 기술 부채 보고서. 관리자가 두 워크플로 모두 Message Batches API로 전환하여 비용을 50% 절감하자고 제안합니다. 이 제안을 어떻게 평가해야 합니까?
정답은 (A) 기술 부채 보고서만 batch로 전환하고, pre-merge 검사는 실시간으로 유지한다. 선택지 분석:
- (B) “상태 폴링으로 두 워크플로 모두 batch” → ✗ “보통 빠르다”는 차단 워크플로의 근거가 될 수 없음
- (C) “두 워크플로 모두 실시간 유지” → ✗
custom_id로 결과 순서를 맞출 수 있으므로, 이것이 실시간을 유지할 이유가 아님 - (D) “batch + 타임아웃 시 실시간 폴백” → ✗ 더 단순한 해법이 있는데 불필요한 복잡성 추가
배치 실패 처리 전략
대량 배치(예: 100개 문서)를 제출하면, 일부가 실패할 수 있다. 이때의 올바른 전략:
- 실패한 문서를
custom_id로 식별한다 - 실패 원인을 분석한다 — 문맥 한도 초과라면 문서를 분할(chunk)한다
- 실패한 문서만 수정하여 재제출한다 (전체를 다시 보내지 않음)
또한, 대량 제출 전에 소규모 샘플에서 프롬프트를 먼저 다듬는 것이 필수적이다. 잘못된 프롬프트로 100개 문서를 처리하면, 100개의 부정확한 결과와 반복 제출 비용이 함께 발생한다.
배치 제출 빈도 계산
SLA 제약과 배치 처리 시간을 결합하여 제출 빈도를 계산할 수 있다. 예를 들어, “30시간 이내에 결과를 받아야 한다”는 SLA가 있고 배치 처리가 최대 24시간이라면, 최소 6시간 전에 제출해야 한다. 즉, 4시간 간격으로 제출하면 여유가 생긴다.
4.6 — 모델이 자기 코드를 리뷰하면 왜 부정확한가
관련 개념 문서: Validation, Repair & Retry Loops, Human-readable vs Machine-usable Outputs
자기 리뷰 편향의 원리
이것은 직관적으로 이해하기 어려울 수 있다. 모델이 코드를 생성한 후 같은 세션에서 “이 코드를 리뷰해 줘”라고 하면 되지 않을까? 왜 별도의 인스턴스가 필요한가?
이유는 추론 문맥(reasoning context)의 잔류이다. 모델이 코드를 생성할 때, “이 방식이 적절하다”는 추론을 이미 수행했다. 같은 세션에서 리뷰를 요청하면, 그 추론이 문맥에 남아 있기 때문에 자기 결정에 의문을 제기할 가능성이 낮아진다. 사람으로 비유하면, 자기가 작성한 보고서를 자기가 교정하는 것과 같다 — 이미 “이 문장은 괜찮다”고 생각했기 때문에 오류를 놓치기 쉽다.
중요한 점은, 확장된 사고(extended thinking)를 활성화해도 이 문제가 해결되지 않는다는 것이다. 확장된 사고는 더 깊이 생각하게 해줄 뿐, 이전 추론의 편향을 제거하지는 않는다.
독립된 리뷰 세션
올바른 접근은 생성 과정의 추론 문맥을 공유하지 않는 별도 Claude 세션에 리뷰를 맡기는 것이다. 이 리뷰 세션은 코드만 보고 판단하므로, 생성 시의 판단 편향으로부터 비교적 자유롭다.
CI 문맥에서는 이 원칙이 더 중요해진다. 자동 생성과 자동 리뷰를 같은 파이프라인에 넣더라도, 같은 세션을 재사용하지 말고 역할을 분리한 독립 리뷰 단계로 두는 편이 정확하다.
| 구분 | 생성 세션 | 독립 리뷰 세션 |
|---|---|---|
| 출발점 | ”이 설계가 적절하다”라는 기존 추론을 이미 갖고 있다. | 이전 추론 없이 코드만 본다. |
| 입력 | 자신이 만든 코드와 그 과정의 문맥을 함께 본다. | 코드만 입력으로 받는다. |
| 리뷰 성향 | 자기 결정을 유지하려는 편향이 생기기 쉽다. | 더 신선한 시각으로 검토할 수 있다. |
멀티패스 리뷰: 대규모 PR을 어떻게 리뷰하는가
여러 파일에 걸친 대규모 PR을 단일 패스로 리뷰하면 도메인 1에서 다뤘던 주의 분산(attention dilution) 문제가 발생한다. 해결 패턴은 리뷰를 두 가지 패스로 분할하는 것이다.
| 패스 | 범위 | 검출 대상 |
|---|---|---|
| 파일별 로컬 패스 | 각 파일을 개별적으로 분석 | 로컬 버그, 스타일 위반, 단일 파일 내 논리 오류 |
| 파일 간 통합 패스 | 파일 간 관계를 분석 | 데이터 흐름 오류, 인터페이스 불일치, 교차 의존성 문제 |
이렇게 분할하면 각 패스가 집중된 범위에서 작동하므로, 일관된 깊이와 정확도를 유지할 수 있다.
신뢰도 기반 리뷰 라우팅
모든 리뷰 결과를 동일하게 처리할 필요는 없다. 모델이 각 결과에 **자기 보고 신뢰도(self-reported confidence)**를 함께 출력하게 하면, 이를 기반으로 차등 처리할 수 있다.
- 높은 신뢰도 결과 → 자동 처리 (코멘트 게시)
- 낮은 신뢰도 결과 → 인간 리뷰어에게 라우팅
- 중간 신뢰도 → 추가 검증 패스 실행
단, 주의할 점이 있다: 모델의 자기 보고 신뢰도는 완벽하게 교정(calibrated)되어 있지 않다. 따라서 라벨링된 검증 세트를 사용하여 임계값을 실험적으로 조정해야 한다. “모델이 80% 이상이라고 보고한 결과의 실제 정확도가 몇 %인가?”를 측정하고, 그에 맞게 라우팅 기준을 설정한다.
자주 나오는 오답 패턴 정리
| # | 안티패턴 | 왜 틀린가 | 올바른 접근 |
|---|---|---|---|
| 1 | ”보수적으로 하라”로 오탐 감소 시도 | 무엇을 보고할지 정의하지 않음 — 모델이 무작위 억제 | 보고/건너뛰기 대상을 구체적으로 정의 |
| 2 | 자기 보고 신뢰도로 에스컬레이션 결정 | 모델 신뢰도가 제대로 교정되지 않음 | 라벨링된 데이터로 임계값을 실험적으로 조정 |
| 3 | 모든 필드를 required로 설정 | 원본에 없는 정보를 모델이 날조 | 정보 부재 가능성이 있는 필드는 nullable |
| 4 | 재시도로 원본에 없는 정보를 추출 시도 | 없는 정보는 재시도해도 나타나지 않음 | 재시도 가능/불가능 판단 후 처리 |
| 5 | 모든 워크플로를 batch API로 전환 | 차단 워크플로에 SLA 보장 없음 | 비차단 작업만 batch, 차단은 실시간 |
| 6 | 같은 세션에서 코드 생성 후 리뷰 | 생성 시 추론 문맥 잔류로 편향 | 독립 인스턴스로 리뷰 |
| 7 | 더 큰 문맥 창으로 대규모 리뷰 해결 | 문맥 크기 ≠ 주의 품질 | 파일별 + 통합 멀티패스 분할 |
직접 해보기
연습: 구조화된 데이터 추출 파이프라인
-
JSON 스키마로 추출 도구를 정의한다. required 필드, nullable 필드, “unclear” enum, “other” + detail 패턴을 모두 포함한다. 원본에 특정 정보가 없는 문서로 테스트하여, nullable 필드가 null을 반환하고 required 필드에서 날조가 발생하는지 비교한다.
-
검증-재시도 루프를 구현한다. Pydantic이나 JSON 스키마 검증이 실패하면, 원본 + 실패 결과 + 검증 오류를 포함한 후속 요청을 보낸다. 형식 오류(재시도 효과적)와 정보 부재(재시도 비효과적)를 구분하여 처리하는 로직을 만든다.
-
Few-shot 예시를 추가하여 추출 정확도 변화를 측정한다. 다양한 형식의 문서(인라인 인용, 참고문헌 목록, 서술문, 표)에 대한 예시를 포함하기 전과 후의 정확도를 비교한다.
-
100개 문서를 Message Batches API로 처리한다.
custom_id로 요청-응답을 매칭하고, 실패한 문서만 식별하여 재제출한다. 문맥 한도를 초과한 문서는 분할하여 재처리한다. -
독립 리뷰 인스턴스를 구현한다. Claude 인스턴스 A로 코드를 생성하고, 인스턴스 B(생성 문맥 없이)로 리뷰한다. 같은 세션에서의 자기 리뷰와 독립 리뷰의 결과를 비교한다.
참고 링크
| 주제 | 링크 |
|---|---|
| 프롬프트 엔지니어링 개요 | Prompt Engineering Overview — Anthropic Docs |
| Claude 4 모범 사례 | Claude 4 Best Practices — Anthropic Docs |
| 멀티샷 prompting | Multishot Prompting — Anthropic Docs |
| Batch 처리 | Batch Processing — Anthropic Docs |
| 도구 사용 | Tool Use with Claude — Anthropic Docs |
| 공식 시험 가이드 PDF | CCAF Exam Guide |