도메인 5: 문맥 관리 및 신뢰성 (15%) — 심화편
비중: 전체 시험의 15%
태스크: 6개 (5.1 ~ 5.6)
교차 시나리오: 고객 지원 해결 에이전트, 코드 생성, 멀티 에이전트 연구 시스템, 구조화된 데이터 추출
핵심 기술: 케이스 팩트 블록, 에스컬레이션 기준, 구조화된 에러 전파, 스크래치패드,/compact, 주장-출처 매핑
이 도메인은 비중이 15%로 가장 낮지만, 가볍게 볼 수 없는 이유가 있다. 시험 개요에서 확인했듯이, 6개 시나리오 중 4개에 걸쳐 있어 교차 출제 빈도가 가장 높다. 고객 지원, 코드 생성, 멀티 에이전트 연구, 데이터 추출 — 거의 모든 시나리오에서 문맥 관리와 신뢰성 판단이 등장한다.
이 도메인이 다루는 질문은 본질적으로 하나다: 에이전트가 장시간 작동하면서 정보가 늘어날 때, 어떻게 정확성과 신뢰성을 유지하는가? 문맥 창은 유한하고, 모델의 주의력은 균등하지 않으며, 에러는 전파되고, 출처 정보는 요약 과정에서 사라진다. 이 모든 제약 속에서 올바른 설계를 하는 것이 이 도메인의 핵심이다.
이 장은 아래 세 질문을 기준으로 읽으면 전체 구조가 잘 잡힌다.
- 이 정보는 압축해도 되는 흐름 정보인가, 아니면 원문 그대로 보존해야 하는 사실 정보인가?
- 에이전트가 여기서 계속 진행해야 하는가, 아니면 사람이나 상위 단계로 넘겨야 하는가?
- 숫자상 성능이 좋아 보여도, 어떤 조건이 충족되어야 실제로 믿을 수 있는가?
Domain 5 Concept Primer
이 도메인은 단순히 문맥을 길게 다루는 법이 아니라, 장기 실행에서도 신뢰 가능한 상태를 유지하는 법을 다룬다. 핵심은 더 많이 기억하는 것이 아니라, 어떤 문맥이 아직 유효한지 판단하고, 필요한 의미를 보존해 압축하고, 출처를 잃지 않으며, 적절한 시점에 handoff하고, external state와 re-grounding 패턴으로 드리프트를 제어하는 데 있다.
관련 개념 문서:
- Context Lifecycle Management
- Compression Without Losing Meaning
- Source-grounded Context & Citation Fidelity
- Escalation & Handoff Boundaries
- Scratchpads, Working Memory & External State
- Reliability Patterns for Long-running Agents
5.1 — 긴 대화에서 중요한 정보를 잃지 않으려면
관련 개념:
- Context Lifecycle Management
- Compression Without Losing Meaning
- Source-grounded Context & Citation Fidelity
점진적 요약의 함정
에이전트가 고객과 긴 대화를 진행하면, 초반의 세부 정보가 점점 뒤로 밀린다. 많은 시스템이 이 문제를 **점진적 요약(progressive summarization)**으로 해결하려 한다 — 오래된 대화를 요약하여 문맥을 줄이는 것이다.
문제는, 요약 과정에서 숫자, 날짜, 금액, 고객이 명시한 기대치 같은 거래적 사실(transactional facts)이 모호해진다는 것이다. “고객이 3월 5일에 주문한 $127.50짜리 상품의 교환을 요청함”이 “고객이 최근 주문에 대해 불만을 제기함”으로 요약되면, 이후 에이전트가 정확한 처리를 할 수 없다.
짧게 나누면 이렇다.
| 요약해도 되는 것 | 요약하면 안 되는 것 |
|---|---|
| 대화 흐름, 현재 분위기, 처리 진행 상황 | 고객 ID, 주문 번호, 금액, 날짜, 명시적 요청 |
| ”무슨 이야기를 해왔는가" | "무엇이 사실로 확정되었는가” |
케이스 팩트 블록
이 문제의 해결책은 거래적 사실을 요약과 분리해 별도의 영속적 블록으로 관리하는 것이다.
예시를 표로 풀어 쓰면 다음과 같다.
케이스 팩트 블록
| 항목 | 값 |
|---|---|
| 고객 ID | CUS-29481 (검증 완료) |
| 주문 | ORD-88312 · 2026-03-05 · $127.50 |
| 상품 | 무선 키보드 (Model K7) |
| 이슈 | 배송 시 포장 손상, 키캡 3개 파손 |
| 고객 요청 | 교환 (환불 아님) |
| 상태 | get_customer 완료 · lookup_order 완료 |
대화 요약
- 고객이 손상된 상품에 대한 교환을 요청했다.
- 에이전트가 주문을 확인하고 교환 자격을 검증 중이다.
핵심은, 케이스 팩트 블록이 요약 대상에서 제외된다는 것이다. 대화가 아무리 길어져도, 이 블록은 매 API 요청마다 그대로 포함된다. 요약은 대화의 흐름을 압축하지만, 숫자와 식별자는 원본 그대로 보존된다.
도구 출력의 축소
또 다른 문맥 소비원은 도구 출력이다. 주문 조회 도구가 40개 이상의 필드(배송 추적 이력, 내부 처리 로그, 창고 정보 등)를 반환하는데, 에이전트가 실제로 필요한 것은 5개(주문 번호, 상품, 금액, 상태, 반품 자격)뿐인 경우가 대부분이다.
40개 필드가 모두 문맥에 쌓이면 두 가지 문제가 생긴다:
- 토큰 낭비: 관련 없는 정보가 유한한 문맥 창을 차지
- 주의 분산: 모델이 관련 없는 필드에 주의를 빼앗겨 판단 품질이 저하
올바른 접근은 도구 출력이 대화 이력에 추가되기 전에 관련 필드만 추출하여 축소하는 것이다. 도메인 1에서 다뤘던 PostToolUse 훅이 이 역할을 할 수 있다.
기준은 간단하다. 다음 행동을 결정하는 데 직접 필요한 필드만 문맥에 남기고, 감사나 재현을 위한 원본 응답은 별도 로그나 저장소에 보존하는 편이 좋다.
입력의 배치 순서가 중요하다
시험 개요에서 다뤘던 “중간 부분 손실(lost in the middle)” 효과가 여기서 실전에 적용된다. 여러 서브에이전트의 결과를 집계하여 종합 에이전트에게 전달할 때:
- 핵심 결과 요약을 입력의 앞부분에 배치한다
- 상세 결과는 명시적인 섹션 헤더로 구조화한다
- 각 섹션 내에서도 가장 중요한 정보가 먼저 오도록 정렬한다
완전한 대화 이력 전달
Claude API를 사용할 때, 후속 요청에서 이전 대화 이력을 누락하면 모델은 이전 맥락을 완전히 잃는다. 이것은 “기억”의 문제가 아니라 API의 작동 방식이다 — 각 요청은 독립적이므로, 대화의 연속성을 유지하려면 매 요청에 전체 이력을 포함해야 한다.
서브에이전트 출력의 구조화
즉, 전체 이력은 유지하되 그 안에 들어가는 각 덩어리는 최대한 구조화되어 있어야 한다. “모두 다 보내기”와 “아무렇게나 길게 보내기”는 같은 뜻이 아니다.
멀티 에이전트 시스템에서 다운스트림 에이전트(특히 종합 에이전트)의 문맥 예산이 제한적일 때, 업스트림 에이전트의 출력을 어떻게 설계해야 할까?
올바른 접근: 업스트림 에이전트가 장황한 내용과 추론 과정 전체를 보내는 대신, **구조화된 데이터(핵심 사실, 인용, 관련성 점수)**만 반환하도록 수정한다. 다운스트림 에이전트가 필요한 것은 결론이지, 결론에 도달한 과정이 아니다.
또한, 서브에이전트의 출력에 **메타데이터(날짜, 출처 위치, 방법론적 맥락)**를 포함시키면, 다운스트림에서 정확한 종합이 가능해진다.
5.2 — 언제 에스컬레이션하고, 언제 직접 해결하는가
관련 개념:
에스컬레이션 판단의 3가지 기준
| # | 기준 | 예시 |
|---|---|---|
| 1 | 고객이 명시적으로 인간 상담원을 요청 | ”사람과 이야기하고 싶어요” |
| 2 | 정책이 해당 요청에 대해 모호하거나 침묵 | 경쟁사 가격 매칭 요청 — 정책에 자사 사이트 가격 조정만 있고 경쟁사 매칭은 언급 없음 |
| 3 | 에이전트가 의미 있는 진전을 이룰 수 없음 | 필요한 도구가 실패하고, 대안도 없는 상태 |
첫 번째 기준에서 중요한 세부 사항이 있다: 고객이 “사람과 이야기하고 싶다”고 할 때, 먼저 조사를 시도하지 않고 즉시 에스컬레이션해야 한다. “제가 먼저 확인해 볼게요”라고 하면 고객의 명시적 요청을 무시하는 것이다.
빠른 판단 규칙으로 정리하면 이렇다.
- 고객이 사람을 원하면
즉시 에스컬레이션 - 규칙은 명확하고 해결 가능하면
먼저 직접 해결 시도 - 감정, 최근 활동, 자기 확신 점수 같은 휴리스틱만으로는
자동 에스컬레이션 금지
에스컬레이션하지 말아야 할 때
반대로, 에스컬레이션하면 안 되는 상황도 있다:
이슈가 단순하고 에이전트의 능력 범위 안에 있지만, 고객이 화가 나 있는 경우
이때의 올바른 대응은:
- 고객의 감정을 인정한다 (“불편을 드려 죄송합니다”)
- 해결책을 제안한다
- 고객이 제안을 거부하고 다시 한번 인간 상담원을 요청할 때만 에스컬레이션한다
시험에서 자주 나오는 두 가지 잘못된 라우팅 신호
잘못된 신호 1: 감정 분석(sentiment analysis)
고객의 좌절감을 감지하여 자동 에스컬레이션하는 접근은 그럴듯해 보이지만 효과적이지 않다. 고객의 감정적 상태와 사례의 복잡도 사이에는 상관관계가 없기 때문이다. 화가 난 고객의 이슈가 단순할 수도 있고, 차분한 고객의 이슈가 극히 복잡할 수도 있다.
잘못된 신호 2: 자기 보고 신뢰도(self-reported confidence)
에이전트에게 “이 답변에 대한 확신을 1~10으로 평가하라”고 한 뒤, 낮은 점수일 때 에스컬레이션하는 접근이다. LLM의 신뢰도 점수가 제대로 교정(calibrated)되어 있지 않다는 것이 문제다. 특히 어려운 경우에 확신이 높은 것이 가장 위험한 패턴이다.
공식 샘플 문제 3번이 이것을 직접 묻는다:
에이전트가 55% 최초 접촉 해결률을 보이며, 단순한 사례를 에스컬레이션하면서 복잡한 사례를 자율적으로 처리하려 합니다. 에스컬레이션 교정을 개선하는 가장 효과적인 방법은?
정답은 (A) 시스템 프롬프트에 명시적 에스컬레이션 기준과 few-shot 예시를 추가하는 것이다. 자기 보고 신뢰도(B)는 교정이 잘못되어 있고, 별도의 분류기 모델(C)은 과도한 인프라를 요구하며, 감정 분석(D)은 사례 복잡도와 무관한 지표이다.
다중 고객 매칭
도구가 여러 고객을 반환했을 때, 가장 최근 활동이 있는 고객을 자동으로 선택하는 것은 안티패턴이다. 올바른 접근은 고객에게 **추가 식별 정보(이메일, 전화번호, 주소 등)**를 요청하는 것이다.
최근 활동, 높은 주문 금액, 주소 유사도 같은 휴리스틱은 편리해 보여도 오식별 비용이 큰 문제에서는 정답 근거가 될 수 없다.
5.3 — 서브에이전트가 실패하면 코디네이터에게 무엇을 알려야 하는가
관련 개념:
- Escalation & Handoff Boundaries
- Source-grounded Context & Citation Fidelity
- Reliability Patterns for Long-running Agents
에러 전파의 원칙
서브에이전트가 실패했을 때 코디네이터에게 전달해야 하는 정보:
| 필드 | 설명 | 예시 |
|---|---|---|
| 실패 유형 | 무엇이 잘못되었는가 | ”웹 검색 API 타임아웃” |
| 시도한 쿼리 | 무엇을 시도했는가 | ”AI healthcare regulations 2026” |
| 부분 결과 | 실패 전에 수집한 것이 있는가 | 3개 중 2개 소스 검색 성공, 1개 실패 |
| 대안 접근법 | 다른 방법이 가능한가 | ”학술 DB 검색으로 대체 가능” |
예시 형태로 쓰면 아래와 비슷하다.
{
"status": "error",
"error_type": "timeout",
"attempted_query": "AI healthcare regulations 2026",
"partial_results": ["WHO policy brief", "EU draft guidance"],
"fallback": "search_academic_db"
}세 가지 에러 처리 패턴 — 두 개는 안티패턴
✗ 패턴 1: 조용한 실패 — 빈 결과를 성공으로 위장. 코디네이터는 “정보 없음”으로 판단하고, 보고서에서 해당 영역이 누락된다. 사용자는 불완전함을 모른다.
✗ 패턴 2: 전체 중단 — 하나의 서브에이전트 실패로 전체 워크플로 종료. 나머지 결과도 폐기.
✓ 패턴 3: 구조화된 전파 + 부분 진행 — 서브에이전트가 먼저 로컬 복구를 시도하고, 해결 불가 시 구조화된 에러와 부분 결과를 전달. 코디네이터가 재시도, 대안 위임, 또는 부분 진행을 결정.
공식 샘플 문제 8번이 이 패턴을 묻는다. 정답은 (A) 실패 유형, 시도한 쿼리, 부분 결과, 대안을 포함한 구조화된 에러 문맥 반환이다.
접근 실패와 빈 결과의 구분 (재강조)
| 상황 | 코디네이터의 올바른 대응 |
|---|---|
| 검색 성공, 매칭 결과 없음 | ”이 영역에 관련 자료 없음” — 재시도 불필요 |
| 서비스 접근 실패 (타임아웃) | 재시도 또는 대안 시도 — 자료가 있을 수 있음 |
5.4 — 대규모 코드베이스에서 문맥이 열화되면 어떻게 하는가
관련 개념:
- Scratchpads, Working Memory & External State
- Reliability Patterns for Long-running Agents
- Compression Without Losing Meaning
문맥 열화란 무엇인가
확장된 탐색 세션에서 모델의 응답 품질이 점진적으로 저하되는 현상이다. 구체적 증상:
- 이전에 발견한 **특정 클래스명 대신 “일반적인 패턴”**을 참조하기 시작
- 동일 질문에 일관되지 않은 답변
- 초반에 수집한 정보를 잊어버린 것처럼 행동
이것은 모델의 “기억력” 문제가 아니라, 문맥 창에 쌓인 정보량이 많아져 주의(attention)가 분산되는 것이다.
대응 전략 5가지
전략 1: 스크래치패드 파일
에이전트가 핵심 발견 사항을 외부 파일에 기록하게 한다. 문맥 창에서 정보가 밀려나더라도, 이 파일을 참조하면 정확성을 유지할 수 있다.
# scratchpad.md
## 핵심 발견
- OrderService: src/services/order.ts (L45-L200)
- 환불 로직: processRefund() → validateEligibility() → executeRefund()
- 의존성: OrderService → PaymentGateway → RefundProcessor
전략 2: 서브에이전트 위임 — 장황한 탐색을 서브에이전트에 맡기고, 메인 에이전트는 요약된 결과만 받아 상위 조정을 유지한다.
전략 3: 단계 간 요약 주입 — 한 단계의 핵심을 짧게 정리한 뒤 다음 단계의 서브에이전트에 넘긴다.
- 코드 구조를 탐색하고 “주요 모듈 3개, 진입점 2개, 테스트 커버리지 40%“처럼 핵심만 요약한다.
- 이 요약을 포함해 고영향 영역을 심층 분석하고, “OrderService의
processRefund에 에러 처리가 빠져 있다” 같은 새 발견을 다시 요약한다. - 앞 단계 요약을 함께 넘겨 테스트 작성 단계로 이어 간다.
전략 4: 장애 복구 매니페스트 — 각 에이전트가 상태를 매니페스트 파일로 내보내고, 크래시 후 재개할 때 코디네이터가 이를 로드해 프롬프트에 주입한다.
전략 5: /compact — 문맥을 줄이되, 중요한 발견 사항은 반드시 스크래치패드에 먼저 기록한 뒤 /compact를 실행해야 한다. 그렇지 않으면 핵심 정보까지 함께 압축될 수 있다.
어떤 전략을 먼저 쓸지도 구분해 두면 좋다.
- 긴 탐색에서 핵심 사실이 밀리기 시작하면
스크래치패드 - 장황한 조사 자체가 메인 문맥을 오염시키면
서브에이전트 위임 - 단계가 바뀔 때마다 핵심만 넘겨야 하면
단계 간 요약 주입 - 중단 후 재개 가능성이 중요하면
장애 복구 매니페스트 - 이미 문맥이 불어난 상태라면
스크래치패드 기록 후 /compact
5.5 — 97% 정확도라는 숫자를 어떻게 믿을 것인가
관련 개념:
- Source-grounded Context & Citation Fidelity
- Reliability Patterns for Long-running Agents
- Context Lifecycle Management
전체 정확도의 함정
전체 97% 정확도가 특정 문서 유형이나 특정 필드의 저조한 성능을 감출 수 있다. 예를 들어, 인보이스는 99%이지만 수기 영수증은 82%일 수 있다. 전체 평균만 보고 인간 리뷰를 줄이면 특정 유형에서 오류가 급증한다.
반대로 말하면, 유형별 성능, 필드별 성능, 신뢰도 임계값 교정이 확인되기 전에는 전체 평균 정확도만으로 자동화를 확대하면 안 된다.
정확도를 세분화하라
인간 리뷰를 줄이기 전에 두 가지 축으로 분석한다:
| 분석 축 | 확인할 것 |
|---|---|
| 문서 유형별 | 인보이스, 영수증, 계약서, 수기 문서 각각의 정확도 |
| 필드별 | 날짜, 금액, 이름, 주소, 분류 각각의 정확도 |
두 축 모두에서 일관된 성능을 확인한 후에만 리뷰 빈도를 줄인다.
층화 무작위 샘플링
전체에서 무작위로 뽑지 않고, 문서 유형별·필드별·신뢰도 수준별로 층(stratum)을 나누고 각 층에서 표본을 추출한다. 소수 유형의 오류도 감지할 수 있다.
필드 수준 신뢰도와 임계값 교정
- 라벨링된 검증 세트를 준비한다
- 모델의 신뢰도 점수와 실제 정확도의 관계를 측정한다
- “신뢰도 X% 이상이면 자동 처리, 미만이면 인간 리뷰”의 임계값을 실험적으로 조정한다
인간 리뷰 라우팅 우선순위
- 낮은 모델 신뢰도 → 반드시 인간 리뷰
- 원본 문서가 모호/모순적 → 인간 리뷰
- 높은 신뢰도 + 전형적 유형 → 층화 샘플링으로 일부만
- 새로운 문서 유형 → 초기 전수 리뷰 후 점진적 자동화
5.6 — 여러 출처를 종합할 때 출처 정보를 어떻게 보존하는가
관련 개념:
- Source-grounded Context & Citation Fidelity
- Compression Without Losing Meaning
- Escalation & Handoff Boundaries
출처가 사라지는 지점
종합(synthesis) 단계가 출처 정보가 사라지는 핵심 지점이다. 서브에이전트가 “A 출처에서 수치 X”를 반환했는데, 종합 에이전트가 “수치는 대략 X 정도”로 압축하면 출처가 사라진다.
주장-출처 매핑
해결책: 서브에이전트 출력을 주장(claim)과 출처(source)가 구조적으로 연결된 형태로 설계한다.
핵심은 종합 단계에서 “무슨 말을 하는가”와 “그 말을 어디서 가져왔는가”가 떨어지지 않게 만드는 것이다. 이 연결이 끊기면, 나중에 충돌을 해석하거나 신뢰도를 설명할 수 없게 된다.
{
"findings": [
{
"claim": "AI 의료 시장 규모는 2026년에 450억 달러 도달 예측",
"source": {
"url": "https://example.com/report",
"document_name": "Global AI in Healthcare Report 2026",
"relevant_excerpt": "The AI healthcare market is projected to reach $45B...",
"publication_date": "2026-01-15"
}
}
]
}출처가 충돌할 때
| 접근 | 올바른가 | 이유 |
|---|---|---|
| ✗ A 출처 값 채택 (더 최근) | 아니오 | 임의적 선택 |
| ✗ 두 값의 평균 | 아니오 | 통계적으로 무의미 |
| ✓ 양쪽 값을 출처와 함께 모두 표기 | 예 | 독자가 판단 가능 |
시간적 차이는 모순이 아니다
발행일이나 수집 시점이 다르면 수치가 다른 것이 정상이다. 서브에이전트 출력에 발행일을 반드시 포함시키고, 종합 에이전트가 시간적 맥락을 고려하도록 한다.
보고서 구조
[잘 확립된 발견 사항]
- 여러 출처에서 일관되게 지지. 출처 명시.
[논쟁 중인 발견 사항]
- 양쪽 값과 출처 병기. 가능한 원인 분석.
[커버리지 갭]
- 조사 실패 영역. 원인과 대안 명시.
이 구분이 중요한 이유는, 독자가 “무엇은 바로 믿어도 되는지”, “무엇은 논쟁 중인지”, “어디는 아직 비어 있는지”를 한눈에 판단할 수 있기 때문이다.
콘텐츠 유형에 맞는 렌더링
| 콘텐츠 유형 | 적합한 렌더링 |
|---|---|
| 재무 데이터 | 표 (정확한 수치 비교) |
| 뉴스 | 산문 (맥락과 시간 순서) |
| 기술 발견 | 구조화된 목록 (코드 참조, 파일 경로) |
자주 나오는 오답 패턴 정리
| # | 안티패턴 | 왜 틀린가 | 올바른 접근 |
|---|---|---|---|
| 1 | 점진적 요약으로 모든 정보 압축 | 거래적 사실 손실 | 케이스 팩트 블록을 요약에서 분리 |
| 2 | 감정 분석으로 에스컬레이션 | 좌절감 ≠ 사례 복잡도 | 명시적 기준 + few-shot |
| 3 | 자기 보고 신뢰도로 라우팅 | 교정 안 됨 | 라벨링 데이터로 임계값 조정 |
| 4 | 서브에이전트 실패를 빈 결과로 위장 | 복구 기회 차단 | 구조화된 에러 + 부분 결과 |
| 5 | 단일 실패로 전체 종료 | 나머지 결과 폐기 | 부분 진행 + 커버리지 갭 주석 |
| 6 | 충돌 출처에서 임의 선택 | 정보 손실 | 양쪽 값을 출처와 병기 |
| 7 | 전체 97%만으로 리뷰 축소 | 특정 유형/필드 저성능 감춤 | 유형별·필드별 분석 후 판단 |
| 8 | 다중 매칭에서 휴리스틱 선택 | 잘못된 고객 식별 | 추가 식별 정보 요청 |
| 9 | 도구 출력 40개 필드 전부 유지 | 토큰 낭비 + 주의 분산 | 관련 5개 필드만 축소 |
직접 해보기
연습 1: 장기 대화 문맥 관리
-
케이스 팩트 블록을 설계한다. 10턴 이상의 고객 지원 대화를 시뮬레이션하고, 팩트 블록 유무에 따른 후반부 정확도 차이를 비교한다.
-
도구 출력 축소를 구현한다. 40개 필드 반환 도구에 PostToolUse 훅으로 5개만 남기고, 문맥 사용량과 응답 품질을 비교한다.
연습 2: 에스컬레이션 패턴
- 에스컬레이션 기준과 few-shot 예시를 시스템 프롬프트에 정의한다. 다양한 시나리오(단순+화난 고객, 복잡+차분한 고객, 정책 모호 사례)로 테스트한다.
연습 3: 멀티 에이전트 출처 추적
-
주장-출처 매핑이 있는 서브에이전트 출력을 설계한다. 의도적 충돌 데이터를 제공하고, 종합 결과가 양쪽 값을 보존하는지, 확립/논쟁/갭을 구분하는지 확인한다.
-
서브에이전트 타임아웃을 시뮬레이션하고, 코디네이터가 부분 결과로 진행하며 커버리지 갭을 주석 처리하는지 확인한다.