Agentic AI 플랫폼 엔지니어링

Appearance

컨텍스트 엔지니어링 원칙 ​

이 장에서 얻는 것

  • 프롬프트 엔지니어링과 컨텍스트 엔지니어링의 경계를 정확히 구분해 팀 내 용어 혼란을 없앤다.
  • "가장 작은 고신호 토큰 집합(smallest set of high-signal tokens)"이라는 Anthropic의 핵심 원칙을 구성요소별로 적용하는 법을 익힌다.
  • Part 5의 나머지 챕터(context rot, compaction, isolation, JIT retrieval)가 이 원칙에서 어떻게 파생되는지 파악하고 해당 챕터로 이동할 지점을 안다.

왜 문제가 되는가 ​

에이전트가 단발성 프롬프트-응답에서 멀티턴, 장시간 실행 루프로 이동하면 컨텍스트 윈도우는 더 이상 "이번 요청에 무엇을 넣을까"의 문제가 아니라 "에이전트 루프 전체에서 유한한 자원을 어떻게 배분할까"의 문제가 된다. Anthropic은 이를 명시적으로 프롬프트 엔지니어링의 자연스러운 확장(natural progression)이라고 정의한다. 프롬프트 엔지니어링은 "이 한 번의 요청을 어떻게 쓸까"에 최적화된 규율이고, 컨텍스트 엔지니어링은 "모델 추론 시점에 어떤 토큰 집합이 존재해야 하는가"를 시스템 지시문, 도구, MCP, 외부 데이터, 메시지 히스토리 등 전체 컨텍스트 상태에 대해 반복적으로 관리하는 규율이다.[^ctx-eng]

문제가 되는 이유는 두 가지다. 첫째, 컨텍스트 윈도우는 물리적으로 유한하고, 그 안의 모든 토큰은 모델의 attention budget을 나눠 쓴다 — 토큰이 늘어날수록 개별 토큰이 받는 attention은 옅어진다. 둘째, 단순히 창을 늘리는 것으로 이 문제가 해결되지 않는다. Chroma의 통제 실험에 따르면 GPT-4.1, Claude 4, Gemini 2.5, Qwen3 등 18개 최신 모델 전반에서 입력 토큰이 늘어날수록 단순 검색·텍스트 복제 같은 쉬운 과제에서도 신뢰도가 비균일하게 저하되는 "context rot" 현상이 관찰된다.[^chroma-rot] 이는 다음 챕터인 Context rot에서 자세히 다룬다. 즉 "컨텍스트 윈도우가 크니까 다 넣으면 된다"는 전략은 이론적으로도, 실증적으로도 성립하지 않는다.

핵심 개념 ​

프롬프트 엔지니어링 vs 컨텍스트 엔지니어링 ​

축프롬프트 엔지니어링컨텍스트 엔지니어링
시간 범위단일 요청에이전트 루프 전체(멀티턴, 장시간 실행)
최적화 대상문구, 지시문 구조, few-shot 배치시스템 지시문 + 툴 + 메시지 히스토리 + 검색 결과 + 메모리의 총량과 배치
반복 주기요청 단위턴(turn) 단위, 세션 단위로 지속
실패 신호응답 품질 저하context rot, 툴 오호출, 예산 초과로 인한 truncation/compaction 강제 발동

Anthropic은 컨텍스트 엔지니어링을 "LLM 추론 중 존재하는 토큰 집합(정보)을 큐레이션하고 유지하는 전략의 집합"으로 정의하며, 프롬프트뿐 아니라 그 외부에 놓이는 모든 정보를 포괄한다고 명시한다.[^ctx-eng] 프롬프트 엔지니어링이 컨텍스트 엔지니어링에 포함되는 부분집합이라고 보는 것이 정확하다 — 시스템 프롬프트 문구를 다듬는 일도 여전히 필요하지만, 그것만으로는 멀티턴 에이전트의 컨텍스트 예산 문제를 해결할 수 없다.

가장 작은 고신호 토큰 집합 ​

이 챕터, 그리고 사실상 Part 5 전체의 조직 원리는 Anthropic이 제시한 다음 정의다.

"좋은 컨텍스트 엔지니어링이란, 원하는 결과를 얻을 가능성을 극대화하는 가장 작은 고신호 토큰 집합(the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome)을 찾는 것이다."[^ctx-eng]

핵심은 두 개의 서로 당기는 힘의 균형이다. 토큰을 더 넣으면(관련 문서, few-shot 예시, 과거 대화) 모델이 참조할 정보는 늘지만 attention budget은 옅어지고 context rot 위험이 커진다. 토큰을 줄이면 attention은 집중되지만 필요한 신호를 놓칠 위험이 커진다. "고신호"라는 수식어가 의미하는 것은 양의 문제가 아니라 밀도의 문제라는 점이다 — 컨텍스트 엔지니어링의 목표는 토큰 수를 최소화하는 것 자체가 아니라, 넣은 토큰당 결과에 기여하는 정보량(신호 대 잡음비)을 최대화하는 것이다.

컨텍스트 구성요소별 원칙 ​

Anthropic은 컨텍스트를 구성하는 요소를 나누어 각각에 대한 원칙을 제시한다.[^ctx-eng]

  • System prompt: 명확하고 직접적인 언어를 사용하되, 모든 예외 케이스를 if-else로 하드코딩하는 것과 지나치게 모호하게 두는 것 사이의 균형을 잡아야 한다. XML 태그나 마크다운 헤더로 섹션을 나누면 모델이 지시문의 구조를 더 안정적으로 파싱한다.
  • Tools: 목적이 명확하고 기능이 서로 중복되지 않아야 하며, 파라미터는 설명적(descriptive)이어야 한다. "도구를 어떤 상황에서 써야 하는지가 인간에게도 모호하면 에이전트도 판단하지 못한다"는 것이 원문의 표현이다. 이 원칙은 Part 1의 툴 설계, Part 3의 툴 과부하와 직결되며, 툴 자체의 설계 디테일은 Anthropic의 별도 글 "Writing effective tools for AI agents"에서 더 다룬다.[^tool-writing]
  • Few-shot examples: 가능한 모든 엣지 케이스를 나열하는 방식은 지양해야 한다. 대신 다양하면서도 표준적인(canonical) 예시 몇 개가 "천 마디 말보다 가치 있는 그림" 역할을 한다.
  • Message history / retrieved docs / memory: 세션이 길어질수록 점진적 정제(progressive refinement)가 필요하며, 가능한 경우 사전 로딩보다 런타임 중 동적 검색을 우선해야 한다.

이 네 가지 원칙 중 마지막 항목(히스토리·검색·메모리)이 실제로는 가장 어려운 엔지니어링 과제이며, 이를 다루는 세 가지 구체적 기법이 뒤따르는 챕터들의 주제다.

이 파트의 로드맵 ​

이 챕터는 Part 5 전체의 개념적 토대이며, 나머지 챕터는 위 원칙을 구체적인 실행 기법으로 옮긴다.

  • Context rot: "토큰을 더 넣을수록 왜 성능이 떨어지는가"를 실증 데이터로 다룬다. Chroma의 controlled experiment 결과와, 이것이 왜 컨텍스트 윈도우 크기 마케팅과 실제 안전 운용 범위 사이의 간극을 만드는지 설명한다.[^chroma-rot]
  • Compaction과 요약: 메시지 히스토리가 예산을 초과하기 전에 요약해 새 컨텍스트 윈도우로 이어가는 기법. Claude Code가 아키텍처 결정과 미해결 버그는 보존하되 중복된 툴 출력은 버리는 방식이 대표적 사례다.[^ctx-eng]
  • 컨텍스트 격리와 오프로딩: 서브에이전트가 자신만의 깨끗한 컨텍스트 윈도우에서 작업하고 수만 토큰을 소비한 뒤 1,000~2,000 토큰 요약만 상위 에이전트에 반환하는 구조. Anthropic의 멀티에이전트 연구 시스템이 실증한 패턴이다.[^multi-agent]
  • JIT 검색과 토큰 예산: 파일 경로나 쿼리 같은 경량 식별자만 컨텍스트에 유지하고 실제 내용은 필요한 시점에 동적으로 로드하는 just-in-time retrieval 전략과, 사전 검색·자율 탐색을 섞는 하이브리드 접근.

각 챕터에서 다루는 세부 수치·구현 디테일은 이 챕터에서 반복하지 않는다.

결정 표 ​

상황선택이유트레이드오프
시스템 프롬프트에 모든 예외 규칙을 넣고 싶은 유혹이 있을 때핵심 지시문 + 계층적 섹션 구조(XML/마크다운)로 축소if-else 폭증은 고신호 원칙 위반이며 유지보수 불가드문 엣지 케이스는 놓칠 수 있음 — 툴/검증 레이어에서 별도 처리
대화가 길어져 히스토리가 예산을 위협할 때compaction(요약 후 재시작)을 우선 검토아키텍처 결정·미해결 이슈 같은 고신호 정보만 보존 가능요약 손실로 세부 디테일이 누락될 위험, recall 우선 튜닝 필요[^ctx-eng]
서브태스크가 독립적이고 산출물만 상위로 전달하면 되는 경우서브에이전트로 격리해 요약만 반환수만 토큰의 탐색 과정이 상위 컨텍스트를 오염시키지 않음토큰 총량은 오히려 증가(멀티에이전트 리서치 사례에서 단일 에이전트 대비 15배)[^multi-agent]
대용량 참조 문서(코드베이스, 매뉴얼)를 다뤄야 할 때전체를 사전 주입하지 않고 식별자만 유지, JIT 검색고신호 토큰만 실제 로드 — attention budget 보존검색 실패 시 필요한 정보를 놓칠 수 있어 하이브리드 사전 로딩 병행 필요
few-shot 예시를 늘려 정확도를 높이려 할 때엣지 케이스 나열이 아니라 다양하고 표준적인 예시 소수 선택다양성이 있는 소수 예시가 규칙을 더 잘 일반화시킴[^ctx-eng]예시 선택 편향 시 특정 패턴에 과적합될 위험

실패 모드 ​

증상근본 원인확인 방법해결
시스템 프롬프트가 수천 토큰으로 비대해지고 계속 늘어남예외가 생길 때마다 지시문에 조건문을 추가하는 습관("prompt as bugfix")시스템 프롬프트 diff 히스토리를 시간순으로 확인 — 단조 증가하는지지시문을 원칙 수준으로 재작성하고, 예외 처리는 툴 검증 로직이나 별도 정책 레이어로 이동
툴 설명이 장황해지고 서로 겹치는 툴이 늘어남툴 추가 시 기존 툴과의 경계를 재검토하지 않음툴 카탈로그에서 파라미터/설명 유사도 검사, 실제 호출 로그에서 오호출 빈도 확인툴 설계, 툴 과부하 참조해 통합/축소
긴 세션에서 후반부 턴의 응답 품질이 초반보다 눈에 띄게 떨어짐context rot — 토큰 증가에 따른 attention 희석, 조기 compaction 부재턴 번호 대비 정확도/일치도를 측정해 하락 곡선 확인Context rot, Compaction과 요약 적용
검색된 문서나 히스토리를 통째로 프롬프트에 주입해 컨텍스트가 조기에 가득 참사전 로딩 위주 설계, JIT 검색 미도입컨텍스트 사용량 중 실제로 응답에 인용/참조된 비율(신호 대 잡음비) 측정JIT 검색과 토큰 예산 적용
서로 다른 서브태스크의 탐색 과정이 하나의 컨텍스트에 뒤섞여 관련 없는 정보가 누적컨텍스트 격리 없이 단일 에이전트 루프에서 모든 작업 처리컨텍스트 내 특정 서브태스크 관련 토큰 비율이 시간이 갈수록 감소하는지 추적컨텍스트 격리와 오프로딩 적용
few-shot 예시를 계속 추가했는데도 정확도가 정체되거나 하락예시가 엣지 케이스 나열로 변질되어 다양성보다 특이성이 커짐예시 집합의 커버리지(표준 케이스 비율) vs 특이 케이스 비율 검토표준적이고 다양한 소수 예시로 교체

안티패턴 ​

  • ❌ "컨텍스트 윈도우가 크니 일단 다 넣는다" → ✅ 결과에 실제로 기여하는 토큰만 선별해 넣는다 — 창 크기는 안전 마진이 아니라 성능 저하 곡선의 시작점이다.[^chroma-rot]
  • ❌ 시스템 프롬프트에 모든 예상 시나리오를 if-else로 미리 박아둔다 → ✅ 원칙과 우선순위를 명시하고, 세부 예외는 툴·검증 레이어에 위임한다.
  • ❌ 대화 히스토리를 한 번도 압축하지 않고 예산 초과 시점까지 방치한다 → ✅ recall을 유지하면서 정밀도를 조정하는 compaction 정책을 미리 설계한다.[^ctx-eng]
  • ❌ 모든 서브태스크를 단일 에이전트의 단일 컨텍스트에서 순차 처리한다 → ✅ 독립적인 탐색이 필요한 작업은 격리된 서브에이전트로 분리하고 요약만 상위로 전달한다.[^multi-agent]
  • ❌ 참조 문서를 전부 사전 임베딩해 프롬프트에 붙여넣는다 → ✅ 경량 식별자를 유지하고 필요한 시점에 JIT으로 로드한다.

계측 (SLI) ​

컨텍스트 엔지니어링 자체는 단일 지표로 검증되지 않으며, 다음 신호들을 조합해 관찰해야 한다.

  • 턴(turn)별 정확도/일치도 곡선: 세션이 길어질수록 응답 품질이 하락하는지 추적한다. Chroma의 실험처럼 관련 문서를 컨텍스트 중간(20개 문서 중 5~15번째 위치)에 배치했을 때 대부분 모델에서 30%p 이상 정확도가 하락하는 현상이 실제 파이프라인에서도 재현되는지 확인해야 한다.[^chroma-rot]
  • 컨텍스트 신호 대 잡음비: 응답 생성에 실제로 인용/참조된 토큰 수 대비 컨텍스트에 주입된 전체 토큰 수. 이 비율이 낮으면 "저신호" 토큰이 과도하게 섞여 있다는 뜻이다.
  • compaction/context editing 발동 빈도와 효과: Anthropic이 공개한 벤치마크에서는 context editing만 적용해도 100턴 평가에서 토큰 소비가 84% 줄었고, memory tool과 결합하면 baseline 대비 에이전트 검색 성능이 39% 향상되었다(context editing 단독으로는 29%).[^ctx-mgmt] 자체 파이프라인에서도 compaction 전후의 토큰 소비량과 태스크 성공률을 함께 추적해야 한다.
  • 서브에이전트 요약 압축률: 서브에이전트가 소비한 원본 토큰 대비 상위 에이전트에 반환하는 요약 토큰의 비율. Anthropic 리서치 시스템 사례는 수만 토큰 소비 후 1,000~2,000 토큰 요약으로 귀결되는 것을 정상 범위로 제시한다.[^multi-agent]
  • 툴 오호출률: 툴 설명의 모호성이 실제 호출 오류로 이어지는지, 툴 카탈로그가 커질수록 오호출률이 어떻게 변하는지 툴 과부하의 지표와 함께 추적한다.

미정착 영역

"고신호 토큰"을 정량적으로 측정하는 표준 지표는 아직 산업 전반에 합의되어 있지 않다. Anthropic의 원문도 이를 정성적 원칙으로 제시할 뿐, attention 희석이나 신호 대 잡음비를 직접 측정하는 공식 벤치마크를 제공하지 않는다.[^ctx-eng] 위에 제시한 SLI들은 실무에서 대리 지표(proxy metric)로 쓰이는 것이며, 팀마다 자체 태스크에 맞춰 검증해야 한다.

체크리스트 ​

  • [ ] 시스템 프롬프트가 예외 처리 조건문 누적으로 비대해지지 않았는지 정기적으로 diff 리뷰한다.
  • [ ] 각 툴의 목적이 다른 툴과 명확히 구분되고, 파라미터 설명이 모호하지 않은지 점검한다(툴 설계 체크리스트와 연동).
  • [ ] few-shot 예시가 엣지 케이스 나열이 아니라 다양하고 표준적인 소수 예시로 구성되어 있는지 확인한다.
  • [ ] 세션 길이에 따른 성능 저하 곡선을 실제로 측정했는지 확인한다(Context rot 참조).
  • [ ] 컨텍스트 예산 초과를 대비한 compaction 정책(무엇을 보존하고 무엇을 버릴지)이 사전에 정의되어 있는지 확인한다(Compaction과 요약 참조).
  • [ ] 독립적으로 탐색 가능한 서브태스크가 단일 컨텍스트에 뒤섞여 있지 않은지, 격리 가능한 지점이 있는지 검토한다(컨텍스트 격리와 오프로딩 참조).
  • [ ] 대용량 참조 자료를 사전 전체 주입하는 대신 JIT 검색으로 전환할 수 있는지 검토한다(JIT 검색과 토큰 예산 참조).
  • [ ] 컨텍스트 신호 대 잡음비, compaction 발동 빈도, 서브에이전트 요약 압축률 등의 SLI를 대시보드에서 관찰하고 있는지 확인한다.

참고 ​