Confidence는 확률이 아니라 신호다

Confidence는 모델 출력의 신뢰도를 나타내는 보조 신호로 볼 수 있습니다. 다만 모델이 직접 적은 점수를 검증된 확률처럼 받아들이면 안 됩니다.

예를 들어 모델이 특정 값에 대해 높은 점수를 적었다고 해도, 실제 정확도가 그 숫자와 같다는 보장은 없습니다. 따라서 Confidence는 자동 승인 여부를 판단하는 유일한 기준이 아니라, 검토 라우팅을 돕는 입력 중 하나로 사용해야 합니다.

CCA-F 관점에서는 “모델이 자신 있어 보인다”가 아니라 “이 신호를 어떤 검증 정책과 연결할 것인가”가 핵심입니다.

Record-level과 Field-level의 차이

Record-level Confidence는 전체 결과 하나에 점수를 붙이는 방식입니다. 단순하지만 어느 항목이 약한지 숨길 수 있습니다.

Field-level Confidence는 추출된 각 값마다 점수를 붙이는 방식입니다. 이 방식은 불확실한 항목만 검토 큐로 보내고, 확실한 항목은 다음 단계로 넘길 수 있어 효율적입니다.

시험에서는 전체 결과 기준 검토와 개별 값 기준 검토의 차이를 구분해야 합니다.

Routing Threshold 설계

Routing Threshold는 자동 처리와 검토 큐를 나누는 기준입니다. 낮은 신뢰도 또는 높은 위험도 출력은 사람 검토로 보내고, 위험도가 낮고 충분히 안정적인 출력은 자동 처리할 수 있습니다.

Threshold는 임의로 정하면 안 됩니다. 평가 데이터로 실제 정확도와 오류 유형을 확인한 뒤 업무 위험도와 검토 가능 인력을 함께 고려해야 합니다.

또한 경계선 근처의 출력에는 2차 검증, 추가 도구 확인, 사람 검토 같은 중간 단계를 둘 수 있습니다.

Review Queue의 역할

Review Queue는 단순한 목록이 아니라 품질 관리를 위한 운영 계층입니다. 어떤 출력이 검토로 가야 하는지, 어떤 순서로 처리해야 하는지, 검토 결과를 어떻게 기록할지 포함합니다.

검토 큐에는 원 입력, 모델 출력, 신뢰도 신호, 위험도, 제안 수정 내용이 함께 표시되어야 합니다. 검토자가 필요한 정보를 따로 찾게 만들면 지연시간이 늘고 판단 품질도 흔들립니다.

우선순위는 낮은 신뢰도와 높은 위험도를 함께 고려해야 합니다. 단순히 먼저 들어온 순서대로만 처리하면 중요한 항목이 뒤로 밀릴 수 있습니다.

Review Queue 예시

아래는 실제 서비스 값이 아닌 더미 예시입니다. 실제 사용자 정보, 계정, 도메인, 내부 리소스명은 블로그 예시에 넣지 않습니다.

이 구조의 목적은 검토자가 무엇을 봐야 하는지 명확히 하고, 검토 결과를 나중에 평가와 개선에 다시 사용할 수 있게 만드는 것입니다.

검토 액션과 피드백 루프

검토자는 보통 승인, 수정, 거절 중 하나를 선택합니다. 승인은 모델 출력이 그대로 사용 가능하다는 뜻이고, 수정은 사람이 정답에 가까운 출력을 제공한다는 뜻입니다. 거절은 해당 출력을 사용하지 않는 결정입니다.

이 기록은 단순 운영 로그가 아닙니다. 어떤 입력에서 오류가 자주 발생하는지, 어떤 점수대가 실제로 위험한지, 어떤 프롬프트나 스키마를 고쳐야 하는지 알려주는 평가 데이터가 됩니다.

검토는 동기식으로 처리할 수도 있고 비동기식으로 처리할 수도 있습니다. 즉시 정확성이 필요한 흐름은 검토가 끝날 때까지 기다리고, 지연을 줄여야 하는 흐름은 임시 상태를 반환한 뒤 나중에 확정할 수 있습니다.

시험에서 헷갈리기 쉬운 포인트

첫째, Confidence 점수는 검증 전에는 확률이 아닙니다. 평가 데이터로 실제 정확도와 비교해야 라우팅 기준으로 쓸 수 있습니다.

둘째, 낮은 신뢰도만 검토 큐로 보내는 것이 아닙니다. 신뢰도가 높아도 영향도가 큰 출력은 검토 대상이 될 수 있습니다.

셋째, Review Queue는 방어 장치이면서 개선 데이터 생성 장치입니다. 검토 결과를 기록하지 않으면 같은 오류를 줄이기 어렵습니다.

공식 문서 기준 확인 사항

Anthropic 평가 도구 문서는 테스트 케이스를 만들고 결과를 비교하며 응답 품질을 등급화할 수 있다고 설명합니다. 이는 Confidence나 라우팅 기준을 감으로 정하지 않고, 실제 평가 흐름으로 검증해야 한다는 점과 연결됩니다.

가드레일 문서는 입력과 도구 결과를 스크리닝하고, 민감하거나 위험한 작업에는 추가 확인 단계를 두는 방식을 설명합니다. Review Queue는 이런 확인 단계를 운영 흐름으로 만든 형태로 이해할 수 있습니다.

FAQ

Conversation Compaction이란 무엇인가

Conversation Compaction은 긴 대화 이력을 짧은 요약으로 바꿔 컨텍스트 공간을 확보하는 방식입니다. 대화가 길어질수록 사용자 메시지, Assistant 응답, Tool 결과, 파일 내용이 누적되기 때문에 언젠가는 정리가 필요합니다.

Compaction의 목적은 모든 내용을 보존하는 것이 아닙니다. 다음 행동에 필요한 목표, 결정, 현재 상태, 중요한 제약을 남기고 나머지 세부 사항을 줄이는 것입니다.

CCA-F 관점에서는 Compaction을 “긴 대화를 계속 이어가기 위한 요약 전략”으로 이해하면 됩니다. 다만 요약은 본질적으로 일부 정보가 빠질 수 있다는 전제를 함께 가져야 합니다.

Context Window Pressure와 다른 문제들

Context Window Pressure는 대화와 도구 결과가 누적되어 컨텍스트 한계에 가까워지는 현상입니다. 이 경우 오래된 내용이 압축되거나, 일부 정보가 직접 보이지 않게 될 수 있습니다.

이 문제는 긴 컨텍스트 안의 중간 정보가 덜 주목받는 현상과 구분해야 합니다. 하나는 공간이 부족한 문제이고, 다른 하나는 정보가 있어도 위치 때문에 덜 반영될 수 있는 문제입니다.

실무 설계에서는 두 문제를 모두 고려해야 합니다. 공간이 부족하면 줄여야 하고, 중요한 정보가 묻히면 별도 상태나 상단 요약으로 다시 고정해야 합니다.

Compaction이 보존하는 것과 잃는 것

Compaction은 대화의 흐름을 유지하는 데 유용하지만 완전한 기록은 아닙니다. 요약에 포함되지 않은 세부 정보는 이후 판단에서 빠질 수 있습니다.

따라서 중요한 값, 결정 근거, 재현 가능한 절차는 대화 요약만 믿지 말고 별도 위치에 저장해야 합니다.

Compaction이 적합한 경우

Compaction은 원문 그대로의 이력보다 작업 흐름 유지가 더 중요한 경우에 적합합니다. 예를 들어 긴 구현 작업, 여러 단계의 조사, 반복적인 설계 논의에서는 요약된 상태가 대화를 계속 이어가는 데 도움이 됩니다.

반대로 정확한 문장, 코드 조각, 숫자, 계약성 기록이 중요한 경우에는 요약만으로 부족합니다. 그런 정보는 파일, 이슈, 데이터베이스, 별도 상태 블록처럼 다시 확인 가능한 위치에 남겨야 합니다.

핵심 질문은 간단합니다. “나중에 이 내용을 정확히 그대로 다시 봐야 하는가?” 답이 예라면 Compaction 요약만으로 처리하면 안 됩니다.

Durable State 예시

Durable State는 대화 밖에 남겨야 하는 중요한 상태입니다. 아래는 실제 값이 아닌 더미 예시입니다.

이 예시의 목적은 대화를 길게 보존하는 것이 아닙니다. Compaction 이후에도 이어서 작업할 수 있도록 핵심 상태만 남기는 것입니다.

Goal Drift를 줄이는 방법

Goal Drift는 긴 대화가 진행되며 원래 목표에서 조금씩 벗어나는 현상입니다. 컨텍스트가 아직 남아 있어도 새 요청, 중간 논의, 도구 결과가 많아지면 목표가 흐려질 수 있습니다.

이를 줄이려면 대화 상단이나 별도 상태에 현재 목표, 완료 조건, 제외할 범위를 짧게 고정하는 것이 좋습니다. 긴 설명보다 업데이트 가능한 상태 블록이 실용적입니다.

또한 새로운 큰 작업으로 넘어갈 때는 이전 대화를 계속 끌고 가는 대신 정리하거나 새 세션으로 분리하는 선택도 필요합니다.

시험에서 헷갈리기 쉬운 포인트

첫째, Compaction은 완전한 백업이 아닙니다. 요약이므로 일부 정보는 사라질 수 있습니다.

둘째, 요약된 대화 흐름과 정확한 기록은 다릅니다. 정확한 값이 중요하다면 대화 밖에 저장해야 합니다.

셋째, Context Window Pressure와 Goal Drift는 다른 문제입니다. 하나는 공간 문제이고, 다른 하나는 목표 일관성 문제입니다.

공식 문서 기준 확인 사항

Claude Code 공식 문서는 컨텍스트 창이 세션에서 Claude가 알고 있는 내용을 담고, 파일 읽기와 도구 결과가 컨텍스트에 추가된다고 설명합니다. 또한 긴 세션에서는 /compact가 대화 이력을 구조화된 요약으로 바꿀 수 있다고 안내합니다.

공식 문서에 따르면 자동 압축은 컨텍스트 한계에 가까워질 때 세션을 이어가기 위한 방식이며, 압축 후 어떤 항목이 다시 주입되는지는 로딩 방식에 따라 달라집니다. 따라서 중요한 정보는 요약만 믿지 말고 별도 상태로 남기는 것이 안전합니다.

FAQ

Subagent Delegation이란 무엇인가

Subagent Delegation은 메인 Agent가 모든 탐색을 직접 처리하지 않고, 특정 하위 작업을 별도 Agent에게 맡기는 방식입니다. 핵심 목적은 역할 분리와 컨텍스트 보호입니다.

큰 코드베이스나 긴 문서에서 필요한 정보를 찾다 보면 검색 결과, 후보 파일, 실패한 경로가 많이 생깁니다. 이런 중간 정보가 메인 컨텍스트에 그대로 쌓이면 실제 판단에 필요한 핵심 정보가 흐려집니다.

Subagent는 이런 탐색 과정을 자기 컨텍스트에서 처리하고, 메인 Agent에는 정리된 결과만 돌려줍니다. 따라서 위임은 단순한 병렬 처리보다 “불필요한 중간 상태를 격리하는 설계”로 이해하는 것이 좋습니다.

언제 위임해야 하는가

위임은 탐색 범위가 넓고, 중간 결과가 많으며, 최종 판단에는 요약된 결과만 필요한 경우에 적합합니다. 예를 들어 여러 파일을 비교하거나, 여러 후보 위치를 좁히거나, 변경 전 관련 흐름을 조사하는 작업이 여기에 해당합니다.

CCA-F 관점에서는 “작업을 나눈다”보다 “메인 컨텍스트를 보호할 만큼 탐색 비용이 큰가”를 기준으로 판단하는 것이 중요합니다.

위임하지 않는 편이 나은 경우

모든 작업에 Subagent가 필요한 것은 아닙니다. 이미 파일 위치를 알고 있거나, 단일 파일만 확인하면 되거나, 즉시 수정해야 하는 작은 작업이라면 메인 Agent가 직접 처리하는 편이 더 간단합니다.

Subagent를 만들고 결과를 다시 받는 과정에도 비용과 지연시간이 있습니다. 작은 작업에 과도하게 위임하면 오히려 흐름이 느려지고 검토 지점만 늘어납니다.

따라서 위임은 기본값이 아니라 선택지입니다. 탐색 노이즈를 줄이는 이점이 위임 비용보다 클 때 사용하는 것이 좋습니다.

좋은 Subagent Prompt의 구성

좋은 Subagent Prompt는 열린 요청이 아니라 좁고 검증 가능한 질문이어야 합니다. “찾아봐”보다 “무엇을, 어디 범위에서, 어떤 형식으로, 언제 멈출지”가 들어가야 합니다.

이 네 가지가 없으면 Subagent가 필요 이상으로 넓게 탐색하거나, 긴 설명을 반환할 가능성이 커집니다.

Return Contract 예시

Return Contract는 Subagent가 어떤 형식으로 결과를 돌려줘야 하는지 정한 계약입니다. 아래는 실제 프로젝트 값이 아닌 더미 예시입니다.

핵심은 Subagent의 긴 탐색 과정을 그대로 받지 않는 것입니다. 메인 Agent는 판단에 필요한 후보, 근거, 신뢰도, 다음 행동만 받아야 합니다.

Tool Scope와 권한 제한

탐색용 Subagent에는 읽기 중심 도구만 주는 것이 안전합니다. 역할이 조사라면 파일 수정, 삭제, 외부 호출처럼 부작용이 있는 도구는 기본적으로 제한해야 합니다.

도구 권한을 좁히면 실수의 영향 범위가 줄어듭니다. 또한 Subagent가 본래 목적에서 벗어나 실행 작업까지 해버리는 문제를 줄일 수 있습니다.

CCA-F 시험에서는 Subagent의 전문화가 “더 많은 권한”을 뜻하지 않는다는 점을 기억해야 합니다. 오히려 역할에 맞게 권한을 줄이는 것이 좋은 설계일 때가 많습니다.

Trust Boundary와 검증 기준

Subagent 결과는 유용한 단서이지만 무조건적인 사실은 아닙니다. 특히 보안, 배포, 데이터 변경, 큰 구조 변경처럼 영향이 큰 작업에서는 메인 Agent가 핵심 사실을 직접 확인해야 합니다.

반대로 낮은 위험도의 단순 탐색은 Subagent 결과를 바탕으로 바로 다음 단계로 넘어갈 수 있습니다. 모든 결과를 같은 수준으로 검증하면 비용이 커집니다.

좋은 설계는 위험도에 따라 검증 수준을 조절합니다. Subagent를 믿지 않는 것이 아니라, 중요한 결정 앞에서는 확인 가능한 근거를 다시 보는 것입니다.

공식 문서 기준 확인 사항

Claude Code 공식 문서는 Subagent를 특정 작업을 처리하는 전문 Agent로 설명하며, 각 Subagent가 별도 컨텍스트, 시스템 프롬프트, 도구 접근 권한을 가질 수 있다고 안내합니다. 또한 탐색 결과가 메인 대화에 과도하게 들어오는 것을 줄이는 용도로 사용할 수 있습니다.

공식 문서에는 Explore, Plan, General-purpose 같은 내장 Subagent와 사용자 정의 Subagent 구성 방식도 설명되어 있습니다. 시험 대비 관점에서는 이름보다 역할, 컨텍스트 격리, 도구 제한, 반환 형식이 더 중요합니다.

FAQ

Scratchpad Pattern이란 무엇인가

Scratchpad Pattern은 긴 작업에서 다음 세션에도 필요한 상태를 짧게 남기는 방식입니다. 여기서 중요한 점은 모델의 내부 기억에 의존하지 않고, 사람이 확인 가능한 파일이나 기록으로 작업 상태를 유지한다는 것입니다.

Agent 작업은 한 번에 끝나지 않을 수 있습니다. 중간에 컨텍스트가 줄어들거나, 세션이 바뀌거나, 다른 사람이 이어받을 수 있습니다. 이때 현재 상태가 남아 있지 않으면 이미 끝난 판단을 다시 반복하게 됩니다.

Scratchpad는 모든 내용을 저장하는 공간이 아닙니다. “지금 작업을 안전하게 이어가기 위해 필요한 최소 상태”를 유지하는 작은 운영 기록으로 이해하는 것이 좋습니다.

무엇을 기록해야 하는가

Scratchpad에는 자주 바뀌지만 다음 작업자가 꼭 알아야 하는 정보를 기록합니다. 대표적으로 현재 진행 상태, 이미 내린 결정, 남은 질문, 피해야 할 접근 방식이 있습니다.

시험에서는 Scratchpad를 단순 메모장으로 보면 안 됩니다. Agent가 다음 행동을 결정할 때 참고하는 상태 관리 계층으로 봐야 합니다.

무엇을 기록하면 안 되는가

Scratchpad에는 민감정보, 비밀 값, 개인 식별 정보, 실제 운영 리소스 식별자를 넣으면 안 됩니다. 저장소에 남거나 공유될 수 있는 파일이라면 보안 경계를 더 엄격하게 봐야 합니다.

또한 코드 전체를 복사해 두는 것도 피해야 합니다. 구현은 실제 코드 파일에 있어야 하고, Scratchpad에는 필요한 경우 파일 경로나 결정 이유만 남기는 편이 낫습니다.

오래된 내용도 위험합니다. 지금은 맞지 않는 상태가 남아 있으면 Agent가 그것을 현재 사실로 오해할 수 있습니다.

CLAUDE.md와 Scratchpad의 차이

CLAUDE.md는 프로젝트 규칙, 코딩 기준, 자주 쓰는 명령처럼 비교적 안정적인 지시를 담는 데 적합합니다. 반면 Scratchpad는 현재 작업 상태처럼 자주 바뀌는 내용을 담는 데 적합합니다.

둘이 충돌하면 안정적인 프로젝트 규칙을 우선해야 합니다. Scratchpad는 최신 작업 상태를 보조하는 기록이지, 프로젝트 규칙을 덮어쓰는 장소가 아닙니다.

따라서 “항상 지켜야 하는 규칙”은 CLAUDE.md에 두고, “이번 작업에서 이어받아야 하는 상태”는 Scratchpad에 두는 식으로 역할을 나누는 것이 좋습니다.

Scratchpad 예시 구조

아래는 실제 프로젝트 값이 아닌 더미 예시입니다. 실제 회사명, 도메인, 계정, 리소스명, 내부 경로는 블로그 예시에 넣지 않습니다.

줄바꿈은 의미 단위로만 넣는 것이 좋습니다. 항목 사이에 빈 줄을 과하게 넣으면 읽기는 편해 보여도 실제 복사와 유지 관리가 불편해질 수 있습니다.

Hygiene과 Pruning 기준

Scratchpad Hygiene은 기록을 최신, 짧음, 구조화된 상태로 유지하는 규율입니다. 처음 만드는 것보다 계속 관리하는 쪽이 더 중요합니다.

완료된 항목은 현재 상태에서 제거하고, 오래 보관해야 하는 이력은 별도 보관 위치로 옮기는 편이 낫습니다. 현재 상태 영역은 뒤에 계속 붙이는 방식보다 매번 최신 상태로 다시 쓰는 방식이 적합합니다.

팀에서 공유하는 Scratchpad라면 소유권도 정해야 합니다. 여러 사람이 같은 현재 상태를 동시에 바꾸면 충돌이 생길 수 있으므로, 어떤 작업 흐름이 어느 기록을 관리하는지 정해 두는 것이 좋습니다.

시험에서 헷갈리기 쉬운 포인트

첫째, Scratchpad는 장기 보관소가 아닙니다. 현재 작업을 이어가기 위한 짧은 상태 기록입니다.

둘째, 오래된 Scratchpad는 없는 것보다 더 위험할 수 있습니다. Agent가 낡은 정보를 현재 사실로 받아들이면 잘못된 판단을 할 수 있습니다.

셋째, 민감한 내용이 들어갈 가능성이 있으면 공유 파일로 두지 않는 선택도 필요합니다. 공유성과 보안성은 상황에 맞게 결정해야 합니다.

공식 문서 기준 확인 사항

Claude Code 공식 문서는 세션이 새 컨텍스트로 시작하며, CLAUDE.md와 Auto memory가 세션 간 지식을 유지하는 보완적 방식이라고 설명합니다. 또한 CLAUDE.md는 실행을 강제하는 설정이 아니라 컨텍스트로 제공되는 지시라는 점을 구분해야 합니다.

공식 문서는 지시가 구체적이고 간결할수록 잘 따르기 쉽고, 너무 큰 지시 파일은 컨텍스트를 사용한다고 안내합니다. Scratchpad도 같은 관점에서 짧고 최신 상태로 관리하는 것이 좋습니다.

FAQ

Tool Wrapper Discipline이 필요한 이유

Tool Wrapper Discipline은 외부 도구의 원시 응답을 Agent가 바로 해석하지 않도록 중간 계층에서 정리하는 설계입니다. 검색, 조회, 파일 접근, API 호출 결과는 겉으로 비슷해 보여도 의미가 다를 수 있습니다.

예를 들어 빈 배열은 “조건에 맞는 결과가 없음”일 수도 있고, 권한 문제나 시간 초과 때문에 “확인하지 못함”일 수도 있습니다. 이 둘을 구분하지 못하면 Agent는 확인 실패를 사실 부재로 잘못 말할 수 있습니다.

CCA-F 관점에서는 Tool 결과를 모델에게 넘기기 전에 상태를 명확하게 붙이는 것이 중요합니다. 모델의 추론력에 맡기기보다 Wrapper가 기계적으로 분류해야 운영 안정성이 높아집니다.

Empty Result와 Access Failure 차이

Empty Result는 도구 호출이 정상적으로 완료되었지만 조건에 맞는 데이터가 없다는 뜻입니다. 이 경우에는 “검색했지만 결과가 없습니다”라고 말할 수 있습니다.

Access Failure는 도구가 필요한 범위를 확인하지 못했다는 뜻입니다. 인증 실패, 권한 부족, 네트워크 오류, 시간 초과, 서버 오류가 여기에 포함될 수 있습니다.

두 상태의 차이는 사용자에게 전달되는 문장까지 바꿉니다. Empty Result는 결과 없음이고, Access Failure는 확인 불가입니다. 이 차이를 흐리면 사용자는 검증되지 않은 결론을 사실로 받아들일 수 있습니다.

Status Enum 중심 설계

Tool Wrapper는 결과 본문보다 상태값을 먼저 정규화해야 합니다. Agent가 빈 문자열, 빈 배열, 오류 문장을 직접 추측하게 만들면 같은 상황에서도 응답이 흔들릴 수 있습니다.

핵심은 Agent가 상태값을 기준으로 분기하도록 만드는 것입니다. 자연어 오류 메시지 안에서 의미를 찾게 하면 테스트와 운영이 어려워집니다.

Retry Policy는 어디에 둘까

Retry Policy는 프롬프트보다 Wrapper에 두는 편이 안정적입니다. 프롬프트에 “필요하면 재시도하라”고 적는 방식은 호출 횟수, 오류 유형, 중단 조건을 일관되게 제어하기 어렵습니다.

일시적 오류는 제한된 횟수만 재시도할 수 있습니다. 반면 권한 부족이나 잘못된 요청처럼 재시도해도 바뀌지 않는 오류는 즉시 실패 상태로 분류하는 것이 낫습니다.

또한 Empty Result는 보통 재시도 대상이 아닙니다. 이미 정상 확인이 끝났기 때문에 같은 조건을 반복해도 의미 있는 개선이 없을 가능성이 높습니다.

Wrapper 응답 예시

아래는 실제 서비스 값이 아닌 더미 예시입니다. 실제 계정, 도메인, 요청 식별자, 내부 리소스명은 블로그 예시에 넣지 않습니다.

이 예시에서 중요한 점은 data가 비어 있다는 사실이 아니라 status가 access_failure라는 점입니다. Agent는 빈 data만 보고 “없다”고 말하면 안 됩니다.

User-facing Language 기준

사용자에게 보이는 문장은 상태값과 일치해야 합니다. 확인 실패를 “찾을 수 없음”이라고 표현하면 사실상 잘못된 결론을 제공하는 셈입니다.

CCA-F 시험에서는 사용자 응답의 정확성도 설계 품질로 봐야 합니다. 시스템 내부 상태와 사용자 문구가 어긋나면 신뢰성이 떨어집니다.

시험에서 헷갈리기 쉬운 포인트

첫째, 빈 결과와 실패는 다릅니다. 빈 결과는 확인 완료 후 부재이고, 실패는 확인 자체가 끝나지 않은 상태입니다.

둘째, 재시도는 만능이 아닙니다. 일시적 실패에는 유용하지만 권한 문제나 잘못된 요청에는 효과가 없습니다.

셋째, 상태 분류는 Agent 프롬프트가 아니라 Tool Wrapper의 책임으로 두는 것이 안정적입니다. 그래야 여러 Agent가 같은 규칙으로 동작할 수 있습니다.

공식 문서 기준 확인 사항

Anthropic API 오류 문서는 오류 응답이 구조화된 JSON 형태이며, 오류 타입과 메시지를 포함한다고 설명합니다. 또한 SDK는 연결 오류, 일시적 서버 오류, rate limit 같은 상황에서 지수 백오프 방식의 재시도를 수행할 수 있다고 안내합니다.

Tool Use 문서 관점에서는 도구가 모델에게 외부 작업 결과를 돌려주는 구조를 이해해야 합니다. 따라서 Tool Wrapper는 도구 결과를 모델이 안전하게 사용할 수 있는 상태값으로 바꿔주는 계층으로 볼 수 있습니다.

FAQ

Error Propagation이란 무엇인가

Error Propagation은 하위 단계에서 발생한 오류를 어디까지 전달할지 정하는 설계입니다. 모든 오류를 숨기면 상위 흐름은 잘못된 상태를 정상으로 오해할 수 있습니다.

반대로 모든 오류를 즉시 상위로 올리면 조정자가 작은 오류까지 처리하느라 전체 흐름이 흔들릴 수 있습니다. 그래서 오류 전파 경계는 기본값이 아니라 명시적인 설계 결정이어야 합니다.

CCA-F 관점에서는 “오류가 났다”보다 “이 오류가 상위 계획을 바꾸는가”를 기준으로 판단하는 것이 중요합니다.

Local Recovery가 적합한 경우

Local Recovery는 하위 단계에서 오류를 직접 복구하고 작업을 계속하는 방식입니다. 일시적 네트워크 문제, 재시도하면 성공할 수 있는 요청, 검증 가능한 입력 보정처럼 범위가 작은 오류에 적합합니다.

다만 로컬 복구가 성공해도 기록은 남겨야 합니다. 같은 유형의 오류가 반복되면 상위 시스템의 품질 저하 신호일 수 있기 때문입니다.

핵심은 복구 후 결과가 정확하다고 판단할 수 있는가입니다. 정확성을 보장할 수 없다면 조용히 넘어가면 안 됩니다.

상위 전파가 필요한 경우

상위 전파는 오류를 Coordinator, Orchestrator, 사람 검토 단계로 넘기는 방식입니다. 정책 위반, 권한 거부, 반복 실패, 복구 불가능한 입력 오류처럼 하위 단계가 단독으로 해결할 수 없는 경우에 필요합니다.

판단 기준은 단순합니다. 상위 흐름이 이 오류를 알면 계획이 바뀌는가를 보면 됩니다. 계획이 바뀐다면 전파해야 합니다.

불확실할 때는 낮은 심각도의 신호라도 남기는 편이 완전한 침묵보다 안전합니다. 침묵은 나중에 원인 추적을 어렵게 만듭니다.

Propagation Contract의 구성

Propagation Contract는 오류를 위로 전달할 때 어떤 정보를 담고, 상위 흐름이 어떻게 반응할지 정한 약속입니다. 자유 문장보다 구조화된 Error Envelope가 적합합니다.

심각도 이름만 있고 실제 정책이 없으면 의미가 약합니다. 예를 들어 recoverable이면 재시도 또는 대체 경로를 시도하고, fatal이면 중단과 검토로 이어져야 합니다.

Error Envelope 예시

아래는 실제 값이 아닌 더미 예시입니다. 실제 요청 ID, 계정 ID, 도메인, 내부 리소스명은 블로그 예시에 넣지 않습니다.

이 구조의 목적은 오류 메시지를 예쁘게 만드는 것이 아닙니다. 상위 흐름이 안전하게 분기하고, 중복 실행을 피하고, 나중에 원인을 추적할 수 있게 만드는 것입니다.

Retry Budget과 Idempotency

Retry Budget은 재시도 횟수와 조건을 제한하는 기준입니다. 일시적 오류는 재시도할 수 있지만, 같은 요청을 무한 반복하면 비용과 지연시간만 늘어납니다.

Idempotency는 같은 작업이 중복 실행되어도 결과가 잘못 누적되지 않게 하는 성질입니다. 결제, 메시지 발송, 데이터 쓰기처럼 부작용이 있는 작업에서는 특히 중요합니다.

시험에서는 재시도 가능 오류와 재시도해도 의미 없는 오류를 구분해야 합니다. 또한 상위 재시도가 있는 구조에서는 completed_steps와 idempotency_key 같은 정보가 필요합니다.

시험에서 헷갈리기 쉬운 포인트

첫째, 모든 오류를 로컬에서 처리하는 것은 안전하지 않습니다. 상위 계획을 바꿀 수 있는 오류는 반드시 전파해야 합니다.

둘째, 모든 오류를 상위로 올리는 것도 좋은 설계가 아닙니다. 복구 가능한 작은 오류까지 전부 올리면 조정자가 불필요하게 바빠집니다.

셋째, 오류 전파는 문장 메시지가 아니라 구조화된 계약이어야 합니다. 그래야 테스트, 라우팅, 감사, 재시작이 가능합니다.

공식 문서 기준 확인 사항

Anthropic API 오류 문서는 HTTP 상태 코드와 오류 타입을 구분하고, 오류 응답에 request_id가 포함된다고 설명합니다. 또한 공식 SDK는 일시적 실패에 대해 지수 백오프 방식의 재시도를 수행할 수 있습니다.

Agent 설계 관점에서는 하위 단계가 모든 복구 판단을 혼자 소유하지 않도록 해야 합니다. Coordinator는 전체 계획을 보고 복구, 대체 경로, 중단, 사람 검토 중 하나를 선택할 수 있어야 합니다.

FAQ

Escalation Design이 필요한 이유

Escalation은 Agent가 계속 자동 처리하지 않고 사람, 상위 조정자, 전문 처리 단계로 작업을 넘기는 설계입니다. 목적은 실패를 숨기지 않고, 적절한 판단 주체에게 문제를 전달하는 것입니다.

Agent가 불확실한 상태에서도 계속 진행하면 조용한 오류가 생길 수 있습니다. 반대로 너무 자주 멈추면 검토 부담이 커지고 자동화의 장점이 줄어듭니다.

CCA-F 시험에서는 Escalation을 “사람에게 물어보기”로만 외우면 부족합니다. 언제 멈추고, 어떤 정보를 넘기고, 누가 다음 결정을 하는지까지 하나의 흐름으로 이해해야 합니다.

명시적 Trigger가 중요한 이유

좋은 Escalation은 명확한 Trigger에서 시작합니다. “애매하면 넘겨라” 같은 지시는 구현마다 다르게 해석될 수 있어 운영 안정성이 떨어집니다.

Trigger는 정책 위반, 허용 범위 밖 요청, 반복 실패, 의도 불명확성, 낮은 신뢰도처럼 관찰 가능한 조건으로 작성하는 것이 좋습니다. 조건이 명확해야 로그, 테스트, 개선이 가능합니다.

특히 고위험 작업에서는 Agent의 판단만 믿기보다 허용 목록, 금지 목록, 권한 모드, 검토 단계를 함께 두는 편이 안전합니다.

Hard Trigger와 Soft Trigger

Escalation Trigger는 크게 Hard Trigger와 Soft Trigger로 나눌 수 있습니다. Hard Trigger는 규칙에 맞으면 즉시 멈추는 조건이고, Soft Trigger는 모델 판단이나 신뢰도에 따라 조정되는 조건입니다.

시험에서는 Hard Trigger는 정책 기반, Soft Trigger는 판단 기반으로 구분하면 이해하기 쉽습니다.

Handoff Payload에 들어갈 항목

Handoff Payload는 다음 처리자가 바로 판단할 수 있도록 넘기는 구조화된 정보 묶음입니다. 단순히 긴 대화 요약을 던지는 것이 아니라, 왜 넘겼고 무엇을 시도했는지 명확히 담아야 합니다.

기본 항목은 작업 요약, 사용자의 핵심 요청, 발생한 Trigger, 이미 시도한 작업, 남은 위험, 제안하는 다음 단계입니다. 자동 라우팅이 필요한 시스템이라면 유형, 심각도, 대상 처리자도 포함할 수 있습니다.

중요한 점은 Payload가 사람이 읽기 쉬운 동시에 시스템이 파싱하기 쉬워야 한다는 것입니다. 자유 문장만 있으면 검색, 집계, 라우팅, 사후 분석이 어려워집니다.

Handoff Payload 예시

아래는 실제 값이 아닌 더미 예시입니다. 민감정보나 실제 리소스명은 넣지 않고, 다음 처리자가 판단하는 데 필요한 구조만 보여줍니다.

핵심은 “무엇이 문제인지”와 “다음 사람이 무엇을 판단해야 하는지”를 분리해서 적는 것입니다. 이렇게 해야 Escalation이 단순 중단이 아니라 복구 가능한 흐름이 됩니다.

Routing과 Closing the Loop

Routing은 Escalation된 작업을 어디로 보낼지 정하는 단계입니다. 사람 검토가 필요한지, 전문 Agent가 필요한지, 상위 모델 판단이 필요한지에 따라 목적지가 달라집니다.

Routing 판단은 Escalation을 발생시킨 Agent가 단독으로 소유하기보다, Orchestrator나 정책 계층이 소유하는 편이 안정적입니다. 그래야 시스템 전체 기준이 일관됩니다.

마지막으로 Closing the Loop가 필요합니다. 검토 결과, 수정 내용, 최종 결정이 다시 시스템에 기록되어야 같은 문제가 반복될 때 더 나은 판단을 할 수 있습니다.

시험에서 헷갈리기 쉬운 포인트

첫째, Escalation은 실패가 아니라 통제 장치입니다. 자동으로 계속 진행하는 것보다 멈추고 넘기는 것이 더 안전한 상황이 있습니다.

둘째, 재시도와 Escalation은 다릅니다. 일시적 오류는 제한된 재시도가 가능하지만, 정책 위반이나 권한 불명확성은 반복보다 Escalation이 맞습니다.

셋째, Handoff Payload는 긴 설명문이 아니라 구조화된 계약이어야 합니다. 그래야 다음 처리자가 빠르게 판단하고, 시스템이 결과를 기록할 수 있습니다.

공식 문서 기준 확인 사항

Anthropic의 agent 설계 글은 Agent가 도구를 사용하며 여러 단계로 작업하고, 필요한 경우 사람의 정보나 판단을 다시 요청할 수 있다고 설명합니다. 또한 장기 실행 Agent에는 중단 조건과 안전장치가 필요합니다.

Claude Code 문서의 권한 관련 옵션도 Escalation 설계와 연결됩니다. 허용 도구와 금지 도구를 명확히 나누면 Agent가 자동 처리할 수 있는 범위와 멈춰야 하는 범위를 구분하기 쉽습니다.

FAQ

Tool Output Trimming이 필요한 이유

Tool Output Trimming은 도구가 반환한 결과 중 모델 판단에 필요한 정보만 Context에 넣는 설계입니다. 도구 결과가 길면 토큰 비용이 늘고, 첫 응답까지의 시간도 길어질 수 있습니다.

문제는 비용만이 아닙니다. 관련 없는 필드, 중복 데이터, 긴 원문이 함께 들어가면 모델이 중요한 신호보다 노이즈에 주의를 빼앗길 수 있습니다.

CCA-F 관점에서는 “도구를 호출할 수 있는가”뿐 아니라 “도구 결과를 어떤 형태로 모델에게 돌려줄 것인가”까지 설계해야 합니다.

문제는 화면이 아니라 Context다

사람에게 보이는 화면에서 긴 결과를 접어두는 것만으로는 충분하지 않습니다. 화면에는 짧게 보여도 모델 Context에 전체 결과가 들어간다면 토큰 비용과 품질 문제는 그대로 남습니다.

따라서 Trimming은 UI 표시 단계가 아니라 도구 결과가 모델에게 전달되기 전 단계에서 이뤄져야 합니다. 보통 이 역할은 Tool Wrapper나 중간 처리 계층이 담당합니다.

핵심은 원본 응답과 모델 입력 사이에 정제 계층을 두는 것입니다. 이 계층이 필요한 필드만 남기고, 불필요한 원문과 내부 메타데이터를 제거합니다.

세 가지 Trimming 전략

Tool Output을 줄이는 방식은 크게 세 가지로 볼 수 있습니다. 필드 필터링, 요약, 참조 전환입니다.

시험에서는 각 전략의 이름보다 선택 기준을 이해하는 것이 중요합니다. 스키마가 안정적이면 필터링, 구조가 유동적이면 요약, 본문이 매우 크면 참조 전환을 먼저 떠올리면 됩니다.

전략 선택 기준

필드 필터링은 가장 예측 가능하고 빠릅니다. 추가 모델 호출이 필요 없고, 결과가 항상 같은 스키마라면 유지보수도 쉽습니다. 다만 스키마가 바뀌었는데 허용 목록을 갱신하지 않으면 필요한 필드가 빠질 수 있습니다.

요약은 유연하지만 비용과 지연시간이 추가될 수 있습니다. 또한 요약 과정에서 세부 사실이 사라질 수 있으므로, 숫자나 결정 사항처럼 정확성이 필요한 값은 구조화해서 보존하는 편이 안전합니다.

참조 전환은 큰 결과를 Context에 직접 넣지 않는 방식입니다. 모델에는 요약과 참조 ID만 전달하고, 필요할 때 다시 조회하도록 설계합니다. 이 방식은 토큰 비용을 줄이지만 재조회 흐름과 권한 검증이 필요합니다.

Tool Wrapper 설계 예시

아래는 실제 서비스가 아닌 더미 예시입니다. 도구 원본 결과를 그대로 넘기지 않고, 모델이 판단에 사용할 필드만 남기는 형태입니다.

이 예시의 목적은 값을 맞히는 것이 아니라 구조를 이해하는 것입니다. 실제 시스템에서는 민감정보가 들어갈 수 있는 필드를 제거하고, 모델에게 필요한 최소 정보만 전달해야 합니다.

Trim Audit Log가 필요한 이유

Trimming을 적용하면 모델 입력은 깔끔해지지만, 나중에 문제가 생겼을 때 어떤 필드가 제거되었는지 알기 어려울 수 있습니다. 그래서 Trim Audit Log가 필요합니다.

감사 로그에는 도구 호출 시각, 남긴 필드, 제거한 필드, 참조 ID, 적용한 정책 버전을 기록하는 것이 좋습니다. 이렇게 하면 결과 품질 문제가 발생했을 때 Trimming이 원인인지 추적할 수 있습니다.

단, 감사 로그에도 실제 계정, 키, 토큰, 도메인, IP 같은 민감정보를 그대로 남기면 안 됩니다. 로그는 디버깅을 돕기 위한 것이지 민감정보 저장소가 아닙니다.

시험에서 헷갈리기 쉬운 포인트

첫째, Tool Output Trimming은 결과를 예쁘게 보여주는 UI 기능이 아닙니다. 모델 Context에 들어가기 전에 필요한 신호만 남기는 아키텍처 설계입니다.

둘째, 지나친 제거도 위험합니다. 나중 단계에서 필요한 필드까지 제거하면 모델은 올바른 판단을 할 수 없습니다. 좋은 Trimming은 노이즈를 줄이되 필요한 신호는 남깁니다.

셋째, 도구 정의와 도구 결과도 토큰 사용량에 영향을 줍니다. 쓰지 않는 도구, 과도하게 긴 스키마, 불필요한 결과 필드는 비용과 품질 양쪽에서 부담이 됩니다.

공식 문서 기준 확인 사항

Anthropic 공식 문서는 Tool Use 요청에서 도구 정의, 도구 호출 블록, 도구 결과 블록이 토큰 사용량에 영향을 준다고 설명합니다. 따라서 도구 결과를 어떻게 줄일지는 비용과 Context 품질 모두에 관련됩니다.

또한 Context Window는 모델이 한 번에 참고할 수 있는 작업 공간입니다. 도구 결과가 길어질수록 이 공간을 더 많이 사용하므로, 필요한 정보만 전달하는 설계가 중요합니다.

FAQ

긴 세션에서 문제가 생기는 이유

Claude 같은 모델은 요청에 포함된 Context 안에서 답변을 만듭니다. 세션이 길어지면 대화 이력, 도구 결과, 결정 사항, 수정 요청이 계속 누적되고 Context Window를 압박합니다.

이때 오래된 내용을 줄이기 위해 요약이나 압축을 사용할 수 있습니다. 문제는 요약이 대화의 흐름은 잘 남겨도, 숫자, 조건, 이름, 결정 사항 같은 세부 사실을 항상 완전하게 보존하지는 못한다는 점입니다.

CCA-F 시험에서는 긴 세션을 “짧은 대화가 길어진 상태”로만 보면 안 됩니다. 장기 세션은 별도의 상태 관리, 요약 관리, 사실 보존 전략이 필요한 설계 대상입니다.

요약은 왜 사실을 잃는가

요약은 핵심 흐름을 짧게 만드는 데 유리하지만, 모든 세부 정보를 그대로 복사하는 기능은 아닙니다. 그래서 “무엇을 하기로 했는지”는 남아도 “정확히 어떤 제한값을 쓰기로 했는지”는 빠질 수 있습니다.

특히 식별자, 숫자 제한, 고유명사, 정책 결정, 사용자 선호는 손실에 취약합니다. 이런 정보가 사라지면 모델은 이후 단계에서 이전 결정을 다시 묻거나, 비슷하지만 다른 값으로 대체할 수 있습니다.

따라서 긴 작업에서는 요약을 믿고 모든 사실을 맡기는 방식보다, 손실되면 안 되는 정보를 별도 구조에 보존하는 방식이 더 안전합니다.

Persistent Fact Block의 역할

Persistent Fact Block은 요약으로 사라지면 안 되는 사실을 구조화해서 보관하는 영역입니다. 핵심은 대화 전체를 저장하는 것이 아니라, 이후 판단에 꼭 필요한 사실만 따로 남기는 것입니다.

예를 들어 작업 목표, 확정된 결정, 변경하면 안 되는 제약, 검토가 필요한 열린 질문, 사용자가 명시한 선호 같은 항목이 들어갈 수 있습니다.

이 블록은 모델에게 “이 내용을 먼저 확인하고 답하라”는 지시와 함께 사용해야 효과가 있습니다. 저장만 하고 참조 지시가 없으면 Context만 소비하고 실제 품질에는 도움이 되지 않을 수 있습니다.

보존해야 할 정보와 보존하지 말아야 할 정보

Fact Block은 중요한 내용을 담는 곳이지만, 아무 정보나 넣으면 안 됩니다. 너무 커지면 Context 비용이 늘고, 오래된 정보가 남아 잘못된 판단을 유도할 수 있습니다.

시험에서는 “기억을 많이 저장한다”보다 “잃으면 안 되는 사실만 구조화하고, 오래된 항목을 관리한다”는 관점을 잡는 것이 중요합니다.

Fact Block 설계 예시

아래는 실제 값이 아닌 더미 예시입니다. 핵심은 자유 문장으로 길게 남기는 것이 아니라, 나중에 검증하고 갱신하기 쉬운 구조로 보관하는 것입니다.

이런 구조는 요약 손실을 줄이는 데 도움이 됩니다. 다만 Fact Block 자체도 Context를 사용하므로, 오래된 항목은 정리하고 현재 판단에 필요한 항목만 유지해야 합니다.

Memory와 Context의 차이

Context는 현재 요청 안에 들어온 정보입니다. 요청에 포함되지 않은 정보는 모델이 직접 볼 수 없습니다. 반면 Memory는 세션 사이에 다시 불러올 수 있도록 저장된 지식이나 지시를 의미합니다.

Claude Code 공식 문서는 세션이 새 Context Window로 시작하며, 세션 간 지식을 전달하는 방식으로 CLAUDE.md와 auto memory를 설명합니다. CLAUDE.md는 사용자가 작성한 지속 지시이고, auto memory는 Claude가 사용자의 수정과 선호를 바탕으로 남기는 기억입니다.

중요한 점은 Memory도 결국 세션 시작 시 Context로 들어와야 모델이 사용할 수 있다는 것입니다. 그래서 Memory는 작고 구체적이며 최신 상태로 유지해야 합니다.

시험에서 헷갈리기 쉬운 포인트

요약은 유용하지만 손실이 있는 압축입니다. 따라서 숫자, 식별자, 결정 사항처럼 정확성이 중요한 정보는 요약 전에 별도 상태로 추출하는 것이 안전합니다.

Append-only 방식은 이력을 보존하지만 크기가 커질 수 있고, Replace 방식은 최신 상태를 유지하기 쉽지만 이전 값을 잃을 수 있습니다. 실제로는 변경되지 않는 사실과 변경 가능한 상태를 나누는 혼합 방식이 많이 쓰입니다.

또한 Memory와 Context는 경쟁 관계가 아닙니다. Context는 현재 작업 공간이고, Memory는 세션을 넘어 필요한 정보를 다시 가져오기 위한 저장 전략입니다.

공식 문서 기준 확인 사항

Claude Code 공식 문서는 CLAUDE.md와 auto memory를 세션 간 지식을 전달하는 보완적 방식으로 설명합니다. 또한 CLAUDE.md가 Context Window에 로드되므로, 길고 중복된 지시는 Context를 소비하고 지시 준수에도 영향을 줄 수 있다고 안내합니다.

Context Window 공식 문서는 모델이 사용할 수 있는 작업 공간과 토큰 예산을 이해하는 데 필요합니다. 긴 세션 설계에서는 이 두 문서를 함께 보는 것이 좋습니다.

FAQ

Context Window는 무엇인가

Context Window는 모델이 응답을 만들 때 참고할 수 있는 작업 공간입니다. 사용자 질문만 의미하지 않고, 요청에 포함된 시스템 지시, 이전 대화, 문서 조각, 도구 정의, 도구 결과, 그리고 생성될 출력까지 함께 고려해야 합니다.

시험 관점에서는 “긴 질문을 넣을 수 있는 최대 길이” 정도로 외우면 부족합니다. 더 정확히는 모델이 한 번의 요청에서 처리하는 입력과 출력의 토큰 한도입니다.

따라서 Context Window 설계는 단순한 입력 제한 문제가 아니라 비용, 속도, 품질, 안정성을 함께 다루는 아키텍처 문제입니다.

Token은 어디에서 발생하는가

Token은 모델이 텍스트를 처리하는 기본 단위입니다. 공식 용어집 기준으로 토큰은 단어, 부분 단어, 문자, 바이트와 대응될 수 있으며, 실제 수는 언어와 입력 형식에 따라 달라집니다.

입력 토큰에는 사용자 메시지뿐 아니라 시스템 지시, 대화 이력, 검색 결과, 도구 스키마, 첨부된 텍스트가 포함됩니다. 출력 토큰은 모델이 생성하는 답변입니다.

JSON, XML, 긴 표, 반복된 정책 문장은 사람이 보기에는 짧아 보여도 토큰 사용량이 커질 수 있습니다. CCA-F 시험에서는 “보이는 글자 수”보다 “요청 전체의 토큰 구성”을 보는 관점이 중요합니다.

큰 Context가 항상 좋은 것은 아니다

Context Window가 크면 긴 입력을 다룰 수 있지만, 모든 내용을 넣는 것이 정답은 아닙니다. 관련성이 낮은 정보가 많아지면 중요한 신호가 묻히고, 모델이 필요한 정보를 찾기 어려워질 수 있습니다.

RAG 구조에서도 같은 원칙이 적용됩니다. 전체 문서를 무조건 넣는 방식보다, 질문과 직접 관련된 조각만 선별하는 방식이 비용과 품질 면에서 더 낫습니다.

초보자는 “많이 넣으면 더 정확하다”고 생각하기 쉽지만, 시험에서는 “관련성 높은 정보를 제한된 예산 안에 배치하는 설계”가 더 중요한 포인트입니다.

비용과 지연시간 관점

Claude API의 비용은 입력 토큰과 출력 토큰을 기준으로 계산됩니다. 도구 사용 시에는 도구 정의, 도구 호출 블록, 도구 결과도 토큰 사용량에 영향을 줄 수 있습니다.

시험에서는 가격표 숫자를 외우는 것보다, 어떤 요소가 토큰 비용을 만들고 어떤 설계가 비용을 줄이는지 이해하는 쪽이 더 중요합니다.

Prompt Caching이 필요한 경우

Prompt Caching은 여러 요청에서 반복되는 프롬프트 앞부분을 재사용해 비용과 지연시간을 줄이는 기능입니다. 공식 문서 기준으로 자동 캐싱과 명시적 캐시 지점 설정 방식이 제공됩니다.

예를 들어 매 요청마다 같은 역할 지시, 같은 정책 설명, 같은 기준 문서를 반복해서 넣는다면 캐싱 후보가 됩니다. 반대로 매번 바뀌는 사용자 질문이나 최신 도구 결과는 캐싱 효과가 제한적입니다.

CCA-F 관점에서는 “캐싱은 품질을 높이는 마법 기능”이 아니라 “반복되는 입력 처리 비용과 첫 응답 지연을 줄이는 최적화”로 이해하면 됩니다.

Context Budget 설계 예시

Context Budget은 요청 안에 들어갈 요소별 토큰 예산을 미리 나누는 방식입니다. 중요한 점은 사람이 감으로 관리하는 것이 아니라 애플리케이션 코드나 프롬프트 조립 단계에서 제한을 두는 것입니다.

위 예시는 더미 구조입니다. 실제 서비스명, 계정, 도메인, 내부 경로, 운영 리소스명은 블로그 예시에 넣지 않는 것이 안전합니다.

시험에서 헷갈리기 쉬운 포인트

첫째, Context Window는 사용자 입력만의 한도가 아닙니다. 시스템 지시, 대화 이력, 검색 결과, 도구 정의, 출력까지 함께 봐야 합니다.

둘째, 긴 Context는 좋은 결과를 보장하지 않습니다. 관련 없는 토큰은 품질에 중립적이지 않고, 중요한 정보와 주의 자원을 경쟁할 수 있습니다.

셋째, 모델별 Context Window와 가격은 변할 수 있습니다. 시험 준비용 개념은 유지하되, 실제 수치가 필요한 경우에는 공식 가격 및 모델 문서를 확인해야 합니다.

공식 문서 기준 확인 사항

Anthropic 공식 용어집은 Context Window를 모델의 작업 메모리로 설명하고, Token과 TTFT도 별도 개념으로 정리합니다. 가격 문서에서는 입력 토큰, 출력 토큰, 캐시 쓰기, 캐시 읽기 같은 비용 항목을 구분합니다.

또한 공식 Prompt Caching 문서는 반복되는 프롬프트 prefix를 재사용해 처리 시간과 비용을 줄일 수 있다고 설명합니다. 이 글에서는 해당 원칙을 시험 대비용 개념으로 재구성했습니다.

FAQ