복잡한 작업을 한 번의 호출로 끝내는 것보다, 생성·검토·수정을 별도 패스로 나누면 품질이 크게 올라갑니다. 이 수업에서는 프롬프트 체이닝(prompt chaining), 자기 검토 패스 설계, LLM 심사위원(LLM-as-judge) 패턴, 그리고 패스 수와 비용의 균형을 다룹니다.
프롬프트 체이닝: 한 번에 하나의 작업
"문서를 분석하고, 요약하고, 요약을 검증하고, 이메일 초안까지 써라"를 한 호출에 담으면 각 단계의 품질이 모두 떨어집니다. Anthropic 문서는 복잡한 작업을 순차적 하위 작업으로 분해하는 프롬프트 체이닝을 권장합니다. 각 호출이 하나의 작업에만 집중하면 지시 이행률이 오르고, 중간 산출물을 검사·수정할 수 있는 지점이 생깁니다.
# 패스 1: 추출
facts = call(f"<doc>{document}</doc> 문서에서 핵심 사실만 추출하세요.")
# 패스 2: 초안 작성 (추출 결과만 입력)
draft = call(f"<facts>{facts}</facts> 이 사실만 근거로 요약문을 작성하세요.")
# 패스 3: 검증 (원문과 대조)
issues = call(f"<doc>{document}</doc><summary>{draft}</summary> "
"요약의 각 문장이 원문에 근거하는지 검증하고 "
"근거 없는 문장을 나열하세요.")
체이닝의 부가 이점은 단계별 모델 선택입니다. 추출은 Haiku, 작성은 Sonnet처럼 단계 난이도에 맞는 모델을 배정해 비용을 최적화할 수 있습니다. 또한 중간 산출물을 로깅하면 실패가 어느 단계에서 발생했는지 즉시 파악할 수 있어 디버깅이 단순해집니다.
체이닝과 에이전틱 루프의 구분도 시험 포인트입니다. 체이닝은 개발자가 단계를 미리 고정한 워크플로이고, 에이전틱 루프는 모델이 다음 행동을 스스로 결정하는 구조입니다. 단계가 예측 가능한 작업이라면 체이닝이 더 저렴하고 안정적입니다.
자기 검토 패스 설계
생성 직후의 출력을 그대로 쓰지 않고, 별도 호출로 검토를 시키는 것이 자기 검토(self-review) 패스입니다. 효과를 내는 설계 원칙이 있습니다.
검토는 새 대화에서 시킵니다. 같은 대화에서 "네 답을 검토해 봐"라고 하면 Claude는 자기 출력을 옹호하는 경향이 있습니다. 새 호출에서 "다른 작성자의 초안을 검토하는 편집자" 역할을 부여하면 훨씬 비판적인 검토가 나옵니다.
검토 기준을 체크리스트로 명시합니다. "문제가 있는지 봐 줘"는 피상적 승인("전반적으로 좋습니다")을 낳습니다. "각 문장에 대해 (a) 원문 근거 존재 (b) 수치 정확성 (c) 금지어 포함 여부를 표로 판정하라"처럼 검사 항목을 고정해야 합니다.
검토 출력은 구조화합니다. 검토 결과를 JSON(문제 목록, 심각도, 수정 제안)으로 받으면 '수정 패스'에 기계적으로 전달할 수 있습니다.
<role>당신은 팩트체크 전문 편집자입니다. 초안 작성자가 아닙니다.</role>
<checklist>
1. 각 수치가 <source>와 일치하는가
2. 각 주장에 원문 근거가 있는가
3. 과장 표현(최고, 유일, 혁신적)이 있는가
</checklist>
각 항목을 JSON 배열로 판정하세요:
[{"sentence": "...", "issue": "...", "severity": "high|low"}]
수정 패스에서는 원본 초안 + 구조화된 문제 목록을 입력으로 "문제만 수정하고 나머지는 유지하라"고 지시합니다. 전면 재작성을 막는 이 지시가 없으면 검토에서 통과한 부분까지 바뀌어 회귀가 생깁니다.
LLM 심사위원과 비용 균형
LLM 심사위원(LLM-as-judge)은 모델 출력의 품질을 다른 모델 호출로 평가하는 패턴입니다. 사람 평가보다 빠르고 저렴해 평가 세트 채점, A/B 프롬프트 비교, 프로덕션 출력 샘플링 감사에 쓰입니다. 신뢰할 수 있는 심사위원을 만드는 조건은 다음과 같습니다.
- 평가 기준(rubric)을 점수 구간별 예시와 함께 제공합니다. "1
5점으로 평가하라"만 주면 점수가 45에 몰리는 관대화 편향이 나타납니다. - 점수보다 판정 근거를 먼저 쓰게 합니다. 근거를 먼저 생성하면 점수의 일관성이 올라갑니다.
- 쌍대 비교(pairwise comparison)를 활용합니다. 절대 점수보다 "A와 B 중 어느 쪽이 기준에 더 부합하는가"가 더 안정적인 신호를 줍니다. 이때 순서 편향을 없애기 위해 A/B 순서를 바꿔 두 번 평가하는 것이 정석입니다.
패스 수와 비용의 균형이 마지막 설계 판단입니다. 패스를 늘릴수록 품질은 오르지만 비용과 지연은 배수로 늘어납니다. 실무 기준은 다음과 같습니다.
- 내부 참고용 저위험 출력: 단일 패스로 충분
- 고객 발송·법률·재무 등 고위험 출력: 생성 → 검토 → 수정의 3패스 + 사람 최종 승인
- 대량 처리: 전수 검토 대신 샘플링 감사(예: 5%)로 품질을 모니터링
시험에서는 "모든 출력에 무조건 다중 패스"와 "비용 때문에 검토 전면 생략"이 양쪽 오답이고, 위험도에 비례한 패스 설계가 정답 논리입니다.
시험 함정
- 복잡한 다단계 작업을 단일 호출로 처리하는 선택지는 오답입니다. 체이닝으로 분해해야 단계별 품질과 디버깅 지점을 얻습니다.
- 같은 대화에서 자기 출력을 검토시키는 선택지는 함정입니다. 새 호출에서 독립 검토자 역할을 부여해야 합니다.
- '검토해 줘'라는 개방형 요청은 체크리스트 기반 검토보다 열등합니다. 기준 없는 검토는 피상적 승인을 낳습니다.
- 쌍대 비교 시 A/B 제시 순서를 한 번만 평가하는 선택지는 순서 편향을 놓친 것입니다.
- 프롬프트 체이닝(개발자가 단계 고정)과 에이전틱 루프(모델이 행동 결정)를 혼동시키는 선택지에 주의하세요.
- 모든 출력에 3패스를 적용하거나 반대로 전부 생략하는 극단 선택지는 오답입니다. 위험도 비례가 정답 논리입니다.
실습 시나리오
실제 시험과 같은 형식의 시나리오 문제입니다.
투자자에게 발송되는 월간 실적 요약 이메일을 Claude로 생성합니다. 수치 오류가 한 번이라도 나가면 신뢰에 치명적입니다. 가장 적절한 파이프라인은 무엇입니까?
빌드 연습 · 실적 요약 3패스 파이프라인 구현
약 55분1.생성 패스
매출 데이터 JSON을 입력으로 실적 요약 초안을 생성하는 첫 패스를 구현합니다.
기대 결과 · 수치가 포함된 3문단 요약 초안이 생성됩니다.
2.검토 패스 설계
새 호출에서 편집자 역할 + 수치 대조 체크리스트로 초안을 검토하고 문제를 JSON 배열로 받습니다.
기대 결과 · 일부러 심은 수치 오류가 severity high로 검출됩니다.
3.수정 패스
초안과 문제 목록을 입력으로 '문제만 수정, 나머지 유지'를 지시하는 세 번째 패스를 구현합니다.
기대 결과 · 문제 문장만 바뀌고 정상 문장은 그대로 유지됩니다.
4.회귀 확인
수정본을 다시 검토 패스에 넣어 잔여 문제가 0인지 확인하는 루프를 추가합니다.
기대 결과 · 2회 이내 루프에서 문제 0건으로 수렴합니다.
5.심사위원 비교 실험
단일 패스 출력과 3패스 출력을 쌍대 비교(순서 교차 2회)로 평가시킵니다.
기대 결과 · 3패스 출력이 선호되는 비율이 집계되어 파이프라인의 효과가 수치화됩니다.
6.비용·지연 측정
패스별 토큰 사용량과 총 지연 시간을 기록해 단일 패스 대비 비용 배수를 계산합니다.
기대 결과 · 품질 향상 대비 비용 증가를 근거로 적용 범위(고위험 발송물 한정)를 결정할 수 있습니다.