컨텍스트 엔지니어링이란 무엇인가? 에이전트가 프로덕션 환경에서 생존할지 결정하는 네 가지 운영 방식

AI 에이전트를 위한 컨텍스트 엔지니어링(Context engineering)은 모델이 실행의 모든 단계에서 무엇을 보게 할지를 결정하는 실습입니다. 즉, 지침(instructions), 현재 작업 상태(live task state), 검색된 증거(retrieved evidence), 메모리(memory), 그리고 도구 정의(tool definitions)를 포함합니다. 프롬프트 엔지니어링(Prompt engineering)은 지침을 작성하는 부분입니다. 컨텍스트 엔지니어링은 모델에 전달되는 나머지 모든 것과, 그것을 유지하는 데 드는 비용까지 결정합니다.

Four operations sit between an agent's evidence store and its context window: load eagerly, fetch just in time, compact, and hand to a sub-agent. Each buys back tokens and each charges a different price, so context engineering is a choice among four costs rather than a ladder of best practice. 에이전트의 컨텍스트 창을 가로지르는 증거를 결정하는 네 가지 운영 방식을 설명하는 슬라이드.

핵심 요약 (Key takeaways)

• 컨텍스트 엔지니어링은 에이전트 실행의 각 단계에서 모델이 무엇을 보게 할지를 결정합니다. 프롬프트 엔지니어링은 그중 지침을 작성하는 부분입니다.
• 더 큰 컨텍스트 창(context window)이 만능 해결책은 아닙니다. 모델은 자신이 확실하게 사용할 수 있는 것보다 훨씬 더 많은 토큰을 받아들이며, 이 격차는 종종 10배 이상에 달합니다.
• 컨텍스트 창을 제어할 네 가지 방법이 있으며, 각각 다른 비용이 발생합니다: 항목을 모든 단계에서 로드 유지하기, 특정 단계가 필요할 때만 가져오기(fetch), 오래된 기록을 요약으로 압축하기, 또는 작업의 일부를 별도의 서브 에이전트(sub-agent)에 맡기기입니다.
• 중요한 테스트는 기록이 압축된 후에도 에이전트가 여전히 어려운 규칙(hard rule)을 복구할 수 있는지 여부입니다. Oracle AI Agent Memory를 사용하면 해당 규칙을 가이드라인으로 고정하고, 그 규칙이 필요한 단계의 컨텍스트 카드에 여전히 포함되어 있는지 확인할 수 있습니다.

지원 에이전트가 환불 처리 과정의 38단계에 도달했습니다.

1단계에서는 '200파운드를 초과하는 건 인간의 개입이 필요하다'는 정책을 받았습니다. 22단계에서 대화가 길어지자, 시스템은 공간 확보를 위해 기록을 요약으로 압축했고, 그 과정에서 정책 내용이 요약에 포함되지 못했습니다. 38단계에서 이 에이전트는 900파운드를 환불 처리하고, 자신이 할 수 있는 한도 내에서는 정책을 따랐다고 솔직하게 보고합니다.

팀원 누구도 그 규칙을 삭제하겠다고 선택하지 않았습니다. 하지만 하네스(harness)가 스스로 그렇게 했습니다. 기록이 토큰 임계값을 넘을 때마다 요약하도록 설정되어 있었고, 어떤 라인이 절대로 잃어버릴 수 없는 규칙인지 아무것도 알려주지 못했기 때문입니다.

이것은 꾸며낸 실패 사례가 아닙니다. 2026년 6월에 한 연구자가 ConstraintRot이라는 벤치마크를 구축하여 바로 이것을 테스트했습니다. 에이전트에게 어떤 도구 액션이 금지되어 있는지에 대한 정책을 주고, 그 기록이 압축될 만큼 충분히 오래 실행시킨 다음, 나중에 얼마나 자주 이 정책을 위반하는지 계산하는 것입니다. 총 1,323회 실행과 7개 모델 패밀리를 거치며 그 차이는 극명했습니다. 정책이 요약 과정을 통과했을 때는 위반 건수가 0으로 유지되었습니다. 하지만 요약 과정에서 정책이 삭제되었을 때는 38%에 달하는 수치가 나왔습니다(Governance Decay). 이것은 단일 저자가 작성한 프리프린트(preprint)이며 아직 아무도 재현하지 못했기 때문에, 저는 이 숫자를 법이라기보다는 경고로 받아들이는 것이 좋다고 생각합니다. 테스트된 해결책 자체는 거의 지루할 정도입니다. 즉, 정책을 요약기가 건드릴 수 없는 곳에 보관하면 위반 건수가 다시 0으로 돌아갔습니다.

이것이 바로 컨텍스트 엔지니어링(context engineering)이 하는 일의 맥락입니다.

엔지니어가 사용하는 서비스 차량을 생각해 보세요. 어떤 장비는 한 주 내내 트렁크에 실려 옵니다. 어떤 것은 정비소로 다시 가져가야 합니다. 어떤 것은 포장재를 버리기 전에 작업표에 적고, 또 어떤 일은 견습생에게 시키게 됩니다. 네 가지 선택지, 네 가지 다른 가격이 있으며, 그중 어느 것도 다른 것들의 고급 버전은 아닙니다. 호출할 때마다 이 중 하나를 비용으로 지불해야 합니다.

컨텍스트 엔지니어링이란 무엇이며, 프롬프트 엔지니어링과는 어떻게 다릅니까?

컨텍스트 엔지니어링은 에이전트의 실행 단계마다 모델이 실제로 받는 토큰(instructions, live task state, retrieved evidence, memory, tool definitions)을 결정하고, 네 가지 작업 중 어떤 것이 각 항목에 대한 비용을 지불하는지를 결정하는 실천입니다: 즉, 이를 미리 로드할지(load it eagerly), 적시에 가져올지(fetch it just in time), 압축할지(compact it), 아니면 서브 에이전트에게 넘겨줄지(hand it to a sub-agent).

프롬프트 엔지니어링(Prompt engineering)은 지침을 다듬는 역할을 합니다. 반면 컨텍스트 엔지니어링(Context engineering)은 모델에 도달하는 모든 것, 즉 시스템이 스스로 조립하는 수백 단계 전반을 통제합니다. Anthropic은 이를 '프롬프트 엔지니어링의 자연스러운 발전'이라고 부르며 (Effective Context Engineering for AI Agents) 언급했고, Andrej Karpathy가 2025년 6월에 이 용어를 확산시킨 버전은 '다음 단계를 위해 컨텍스트 창(context window)을 적절한 정보로 채우는 섬세한 예술이자 과학'입니다 (Karpathy on X).

<table><tbody><tr><td>&nbsp;</td><td><strong>프롬프트 엔지니어링 (Prompt engineering)</strong></td><td><strong>컨텍스트 엔지니어링 (Context engineering)</strong></td></tr><tr><td>답변하는 질문</td><td>어떻게 지침을 작성해야 할까?</td><td>이 단계에서 모델은 무엇을 봐야 하며, 그것을 유지하는 데 드는 비용은 얼마일까?</td></tr><tr><td>범위 (Scope)</td><td>하나의 프롬프트 또는 템플릿</td><td>실행의 모든 단계: 지침, 상태(state), 증거(evidence), 메모리, 도구</td></tr><tr><td>발생 시점 (When it happens)</td><td>실행 전에 작성됨</td><td>실행이 진행되는 동안 결정되며, 종종 시스템에 의해 이루어짐</td></tr><tr><td>실패하는 방식 (How it fails)</td><td>모호하거나 상충되는 지침</td><td>필요한 단계에서 적절한 정보가 누락되거나, 묻히거나, 떨어져 나감</td></tr><tr><td>디버깅 방법 (How you debug it)</td><td>프롬프트 읽기</td><td>실패한 단계에서 실제로 창 안에 무엇이 있었는지 검사하기</td></tr></tbody></table>

작동하는 결과물(working artefact)은 컨텍스트 예산(context budget)입니다. 이는 다섯 가지 범주에 걸쳐 유한한 입력 토큰을 단계별로 할당하며, 각 항목에 대한 비용을 지불할 운영 규칙이 포함됩니다. 환불 단계의 샘플 컨텍스트 창은 다음과 같을 수 있습니다:

<table <tbody> <tr> <td><strong>예산 항목 (Budget line)</strong></td> <td><strong>예시 내용 (Example content)</strong></td> <td><strong>정책 (Policy)</strong></td> </tr> <tr> <td>지침 (Instructions)</td> <td>환불 한도 및 에스컬레이션 규칙</td> <td>고정됨, 요약되지 않음 (Pinned, never summarised)</td> </tr> <tr> <td>실시간 작업 상태 (Live task state)</td> <td>케이스 ID, 고객 ID, 요청 금액 및 마지막 조치</td> <td>이 단계에서 로드됨 (Loaded for this step)</td> </tr> <tr> <td>검색된 증거 (Retrieved evidence)</td> <td>정확한 정책 조항 및 해당 출처 URL</td> <td>환불 결정이 내려질 때 가져옴 (Fetched when the refund decision is made)</td> </tr> <tr> <td>기억 (Memory)</td> <td>이전 고객 약속, 기록 ID 포함</td> <td>사용자, 에이전트, 스레드 및 생존 시간(time to live)에 따라 범위 지정됨 (Scoped by user, agent, thread and time to live)</td> </tr> <tr> <td>도구 정의 (Tool definitions)</td> <td>이 단계에서 사용할 수 있는 결제 및 환불 도구만</td> <td>전체 카탈로그가 아닌 라우트별로 로드됨 (Loaded by route, not as a whole catalogue)</td> </tr> </tbody> </table>

이는 크기 문제라기보다는 할당(allocation) 문제로 간주해야 합니다. 왜냐하면 모든 행동이 다음 단계에 필요한 것을 변화시키기 때문입니다. 조회(lookup)는 한 단락을 정당화합니다. 되돌릴 수 없는 도구 호출은 원래의 지침, 현재 권한 및 정확한 식별자 모두가 동시에 필요합니다. Anthropic 자체에서 목표를 간결하게 표현하는 방식은 원하는 결과를 가장 가능성 높게 만드는 '최소한의 고신호 토큰 세트(smallest possible set of high-signal tokens)'를 찾는 것입니다 (AI 에이전트를 위한 효과적인 컨텍스트 엔지니어링 (Effective Context Engineering for AI Agents)).

왜 더 큰 컨텍스트 창(Context Window)이 이것을 해결하지 못하는가?

토큰을 수용하고 그것들을 신뢰성 있게 사용하는 것은 두 가지 다른 속성이기 때문이며, 모델 카드에는 첫 번째 속성만 기재됩니다. Claude Opus 5.5는 백만 토큰 컨텍스트 창(Anthropic models overview)을 제시하며, 이것만이 아닙니다. GPT-4.1과 여러 Gemini 모델도 백만 토큰을 광고합니다. 그 용량은 실제로 존재합니다. 다만 그것이 신뢰할 수 있는 주의(attention)를 가진 백만 개의 토큰은 아니며, 이 격차를 측정하는 연구들은 여전히 그 간극이 크다는 것을 발견하고 있습니다.

Three blocks, one per model, each comparing the context window on the model card with the longest input the model handled dependably under test. GPT-4.1 advertises one million tokens and held up to sixteen thousand on NoLiMa. GPT-4o advertises one hundred and twenty-eight thousand and held up to eight thousand. Llama 3.1 70B advertises one hundred and twenty-eight thousand, held up to sixty-four thousand on RULER and two thousand on NoLiMa. These studies did not test Claude Opus 5.5. NoLiMa 및 RULER 테스트 하에서 광고된 모델 컨텍스트 창과 신뢰할 수 있는 입력 길이를 비교하는 막대 그래프.

각 블록을 하나의 모델이 스스로 측정한 것으로 간주해 주세요. GPT-4o는 128,000 토큰을 수용하며 질문과 증거가 같은 단어를 공유하지 않을 때 약 8,000 토큰까지 유지했습니다 (NoLiMa). Llama 3.1 70B는 RULER(RULER)에서 최대 64,000 토큰까지 유지했고 NoLiMa에서는 2,000 토큰까지 유지했습니다. 이는 동일한 모델이 테스트의 난이도에 따라 32배의 차이를 보이는 경우입니다. Claude Opus 5.5에 대한 측정 결과는 아무도 발표하지 않았기 때문에 추측하지 않겠습니다.

업계에서는 이미 이 현상에 이름을 붙였습니다. Anthropic과 Chroma 모두 이를 컨텍스트 로트(context rot)라고 부릅니다. 입력이 늘어날수록 모델이 그 안에 있는 내용을 기억하는 능력이 떨어진다는 것입니다 (Effective Context Engineering for AI Agents). Chroma는 18개 모델을 테스트하여

마지막 변명까지 제거하는 결과가 있습니다. 모델에 완벽한 검색(retrieval)을 제공하고 증거를 질문 바로 앞에 배치해도 입력이 커짐에 따라 성능은 여전히 저하됩니다(Context Length Alone Hurts LLM Performance Despite Perfect Retrieval).

따라서 유효 컨텍스트 창(effective context window)은 읽는 사양이 아니라 측정하는 지표입니다. 더 큰 밴이라고 해서 내용물이 제대로 실리는 것은 아닙니다.

네 가지 운영 방식과 각각의 비용은 무엇인가?

네 가지가 있으며, 이는 계단식 발전이라기보다는 대안들입니다. 적시 검색(Just-in-time fetching)이 즉시 로딩(eager loading)보다 더 진보된 것이 아니며, 서브 에이전트(sub-agent)도 졸업하는 단계가 아닙니다. 각각은 다른 가격으로 토큰을 되찾아 줍니다.

<table><tbody><tr><td><strong>운영 방식 (Operation</strong></td><td><strong>얻는 것 (What it buys</strong></td><td><strong>비용 (What it costs</strong></td><td><strong>실패하는 방법 (How it fails</strong></td></tr><tr><td>즉시 로딩 (Load eagerly)</td><td>첫 토큰부터 제시되며, 검색 왕복(retrieval round trip)이 없음</td><td>필요하든 아니든 매 단계 점유됨</td><td>도구 카탈로그가 현재 증거를 압도함</td></tr><tr><td>적시 검색 (Fetch just in time)</td><td>필요에 비례하여 점유됨</td><td>왕복(round trip), 그리고 발견 결정이 필요함</td><td>에이전트가 출처가 존재한다는 것을 결코 학습하지 못함</td></tr><tr><td>압축 (Compact)</td><td>작은 창에서 긴 범위 처리 가능</td><td>원래 주소 지정이 가능한 경우를 제외하고는 되돌릴 수 없는 생략</td><td>누구도 표시하지 않은 제약 조건이 사라짐</td></tr><tr><td>서브 에이전트에게 넘기기 (Hand to a sub-agent)</td><td>부모가 추적 과정(trace)을 볼 수 없음</td><td>증거 대신 주장이 들어감</td><td>상속된 자격 증명, 또는 실패한 검색에 대한 자신감 있는 요약</td></tr></tbody></table>