컨텍스트 엔지니어링 입문: 많이 넣을수록 흐려지는 맥락의 설계

맥락 창이 100만 토큰까지 커졌으니 이제는 관련 있어 보이는 것을 전부 넣으면 된다고 생각하기 쉽습니다. 문서 전체, 대화 전체, 도구 결과 전체를 넣으면 적어도 빠뜨린 것은 없을 테니까요.

Chroma 가 2025년 7월에 낸 Context Rot 보고서는 이 생각이 어디서 틀리는지 보여 줍니다. GPT-4.1, Claude 4, Gemini 2.5, Qwen3 를 포함한 모델 18개를 시험했는데, 결론은 한 문장이었습니다. 「모델은 맥락을 고르게 쓰지 않고, 입력이 길어질수록 성능을 점점 믿을 수 없게 된다.」 맥락은 창고가 아니라 책상에 가깝습니다. 넓어졌다고 다 올려 두면 정작 필요한 것을 못 찾습니다. 컨텍스트 엔지니어링은 그 책상 위에 무엇을 올릴지 설계하는 일입니다.

프롬프트 엔지니어링의 다음 단계라는 말의 뜻

이 말은 2025년 6월에 빠르게 퍼졌습니다. Cognition 의 Walden Yan 은 Don't Build Multi-Agents에서 프롬프트 엔지니어링이 챗봇에 넣을 글을 잘 쓰는 일이었다면 「컨텍스트 엔지니어링은 그다음 단계」이고, 그것을 동적인 시스템 안에서 자동으로 하는 일이라고 썼습니다. 같은 달 Shopify 의 Tobi Lütke 는 이 말이 핵심 기술을 더 잘 설명한다며 「LLM 이 그럴듯하게 풀 수 있도록 과제의 맥락을 모두 제공하는 기술」이라고 정의했고, Andrej Karpathy 가 거들었습니다.

context engineering is the delicate art and science of filling the context window with just the right information for the next step.

Simon Willison 은 이 흐름을 정리한 글에서 재미있는 관찰을 남깁니다. 「프롬프트 엔지니어링」은 사람들이 이름만 보고 「챗봇에 글 치는 일을 거창하게 부른 말」로 받아들이는 바람에 뜻이 흐려졌는데, 「컨텍스트 엔지니어링」은 이름만 보고 짐작한 뜻이 원래 뜻에 훨씬 가깝다는 것입니다. 저는 이 말이 오래갈 이유가 여기 있다고 봅니다.

Anthropic 은 2025년 9월 Effective context engineering for AI agents에서 가장 실무적인 정의를 내놓았습니다. 추론하는 동안 모델이 보는 토큰 묶음 전체를 최적으로 고르고 유지하는 전략들이라는 것입니다. 프롬프트뿐 아니라 시스템 지침, 도구 정의, 도구 결과, 이전 대화, 외부에서 가져온 자료까지 전부 여기 들어갑니다. 프롬프트는 그중 한 칸일 뿐입니다.

창이 커져도 주의력은 예산

맥락이 길어질수록 왜 나빠질까요. Anthropic 은 트랜스포머 구조에서 이유를 찾습니다. 모든 토큰이 다른 모든 토큰을 참조하므로 토큰이 n 개면 관계는 n² 개가 됩니다. 길이가 늘수록 관계 하나하나에 돌아가는 주의가 얇아집니다. 그래서 이 글은 LLM 에 「주의력 예산」이 있다고 표현하고, 토큰이 늘수록 맥락에서 정보를 정확히 떠올리는 능력이 떨어지는 현상을 컨텍스트 부패(context rot)라고 부릅니다.

Chroma 의 실험이 그 모양을 구체적으로 보여 줍니다. 몇 가지가 실무와 바로 닿습니다.

발견	실무에서 뜻하는 것
질문과 정답 문장이 덜 비슷할수록, 길이가 늘 때 성능이 더 크게 떨어짐	키워드가 겹치지 않는 질문일수록 긴 맥락에서 놓치기 쉬움
비슷하지만 틀린 문장 하나만 섞여도 성능이 떨어짐	옛 버전 문서, 비슷한 다른 함수가 같이 들어가면 해로움
앞뒤가 이어지는 글보다 문장을 섞은 글에서 오히려 성능이 나았음	길이만이 아니라 구조도 결과를 바꿈

세 번째 결과는 직관과 반대라서 저자들도 일반화에 조심스럽습니다. 다만 앞의 두 가지는 분명합니다. 관련 있어 보이는 것을 많이 넣는 것은 공짜가 아닙니다. 특히 「거의 맞는」 자료가 가장 비쌉니다.

Anthropic 이 내놓은 원칙도 이 방향입니다.

find the smallest set of high-signal tokens that maximize the likelihood of your desired outcome.

원하는 결과가 나올 가능성을 가장 높이는, 신호가 강한 토큰의 가장 작은 묶음을 찾으라는 말입니다. 「가장 작은」이 핵심입니다.

시스템 프롬프트, 도구, 예시에서 덜어 내는 기준

맥락에 늘 올라가는 것부터 봅니다. Anthropic 의 글은 세 가지에 대해 각각 기준을 줍니다.

시스템 프롬프트는 「알맞은 고도」로 씁니다. 너무 낮으면 if-else 를 줄줄이 적은 깨지기 쉬운 규칙이 되고, 너무 높으면 「잘 해라」 같은 막연한 말이 됩니다. 기대하는 행동을 빠짐없이 그려 내는 최소한의 정보가 목표입니다. 최소라는 말이 짧다는 뜻은 아니라고 글은 덧붙입니다.

도구는 기능이 겹치지 않게 적게 둡니다. Anthropic 은 가장 흔한 실패로 「부풀어 오른 도구 목록」을 꼽습니다. 사람 엔지니어가 어느 도구를 써야 할지 단번에 답하지 못하는 목록이라면, 에이전트도 헷갈립니다. 도구 설명 하나하나가 매 턴 맥락을 차지한다는 점도 잊기 쉽습니다.

예시는 여러 경우를 대표하는 정형적인 것 몇 개를 고릅니다. 규칙마다 예외 사례를 붙여 끝없이 늘어놓는 방식은 권하지 않는다고 분명히 적었습니다. 모델에게 예시는 그림 한 장이 천 마디보다 나은 자리입니다.

미리 다 넣지 않고 필요할 때 꺼내는 방식

두 번째 축은 시점입니다. 흔한 방식은 작업 전에 관련 문서를 검색해 맥락에 미리 넣는 것입니다. RAG 가 대표적입니다. Anthropic 은 그 대신, 또는 그와 함께 「필요한 때에」 꺼내는 방식을 소개합니다.

에이전트는 자료 본문 대신 가벼운 식별자를 들고 다닙니다. 파일 경로, 저장해 둔 쿼리, 링크 같은 것입니다. 실제 내용은 그것이 필요해지는 순간 도구로 가져옵니다. Claude Code 가 이렇게 일합니다. glob 과 grep 으로 저장소를 훑고 필요한 파일만 열며, 큰 데이터는 head 와 tail 로 일부만 봅니다. 데이터 전체를 맥락에 올리지 않고도 분석이 됩니다.

사람이 일하는 방식과 같습니다. 우리는 책 한 권을 외우고 일하지 않고, 어디에 있는지만 알고 필요할 때 펼칩니다. 폴더 이름, 파일 이름, 수정 시각 같은 메타데이터도 그 자체로 신호가 됩니다. tests/ 아래에 있는 파일과 src/core/ 아래에 있는 같은 이름의 파일은 다른 뜻을 가집니다.

대가는 속도입니다. 필요할 때마다 찾으면 미리 넣어 둔 것보다 느립니다. 그래서 글은 둘을 섞는 쪽을 권합니다. 자주 쓰는 지침 파일 몇 개는 처음부터 넣고, 나머지는 에이전트가 직접 찾게 하는 식입니다.

긴 작업에서 맥락을 비우는 방법

몇 시간씩 이어지는 작업은 아무리 아껴도 창을 넘칩니다. Anthropic 은 여기서 세 가지 방법을 나란히 놓습니다.

방법	하는 일	지키는 것	버리는 것
압축(compaction)	창이 찰 즈음 대화를 요약해 새 창에서 이어감	설계 결정, 풀리지 않은 버그, 구현 세부	중복된 도구 출력
구조화된 메모	에이전트가 진행 상황을 맥락 바깥 파일에 적음	목표 대비 진척, 다음 할 일	메모에 옮긴 뒤의 대화
서브에이전트	깨끗한 창에서 탐색을 맡기고 요약만 받음	1,000~2,000 토큰 정도의 결과 요약	탐색에 쓴 수만 토큰

압축에서 가장 안전한 첫걸음은 오래된 도구 결과를 지우는 것이라고 합니다. 이미 읽고 판단까지 끝낸 파일 내용을 계속 들고 있을 이유는 없습니다. 어려운 것은 무엇을 남길지입니다. 너무 많이 버리면 몇 턴 뒤에야 중요했다는 것이 드러나는 정보를 잃습니다. 글은 복잡한 실제 작업 기록을 놓고 처음엔 빠짐없이 남기도록 맞추고, 그다음 군더더기를 덜어 내는 순서로 조정하라고 권합니다.

메모 쪽 예가 기억에 남습니다. 포켓몬 게임을 하는 Claude 가 맥락이 여러 번 초기화돼도 「지난 1,234 걸음 동안 1번 도로에서 훈련했고, 피카츄가 목표 10레벨 중 8레벨을 올렸다」 같은 메모를 보고 이어서 진행했습니다. 코딩 에이전트라면 NOTES.md 나 할 일 목록이 같은 역할을 합니다.

서브에이전트 쪽은 앞서 루프 엔지니어링 글과 이어지는 지점입니다. 서브에이전트가 수만 토큰을 들여 찾은 것을 요약 하나로 돌려주면, 지휘하는 쪽의 맥락은 깨끗하게 유지됩니다. 대신 요약에서 빠진 것은 지휘하는 쪽이 모릅니다. Cognition 이 경고한 「암묵적 결정의 충돌」이 여기서 생깁니다.

하네스, 루프, 오케스트레이션과 맞물리는 지점

이 블로그에서 다룬 네 개념은 같은 문제를 다른 높이에서 봅니다.

개념	설계하는 것	컨텍스트와의 관계
하네스	모델 하나의 환경(도구, 지침, 권한)	늘 맥락에 올라가는 것을 정함
컨텍스트 엔지니어링	매 턴 모델이 보는 토큰 묶음	무엇을 넣고, 언제 꺼내고, 언제 비울지
루프 엔지니어링	에이전트를 깨우고 재우는 반복	회차 사이에 무엇을 기억으로 넘길지
오케스트레이션	여러 에이전트 사이의 분업	에이전트끼리 맥락을 얼마나 나눌지

저는 이 표에서 컨텍스트 엔지니어링이 가운데 놓이는 것이 우연이 아니라고 봅니다. 하네스는 맥락의 바닥을 깔고, 루프는 맥락을 회차로 나누고, 오케스트레이션은 맥락을 에이전트로 나눕니다. 어느 층에서 일하든 결국 묻게 되는 것은 같습니다. 지금 이 모델이 다음 한 걸음을 위해 봐야 할 것이 정확히 무엇인가.

아직 정답이 없는 부분

Chroma 의 실험은 대부분 정보를 찾아 꺼내는 과제였고, 문장 구조에 관한 결과는 저자들 스스로 두 가지 주제만으로는 일반화하기 어렵다고 적었습니다. 실제 코딩 에이전트의 긴 맥락에서 같은 정도로 성능이 떨어지는지는 별도로 봐야 합니다.

압축에서 무엇을 남길지에도 공식이 없습니다. Anthropic 의 조언도 「직접 기록을 보며 맞춰라」입니다. 모델이 좋아질수록 덜 조심해도 된다는 말도 같은 글에 있습니다. 그래서 저는 컨텍스트 엔지니어링을 규칙 목록보다는 습관으로 봅니다. 맥락에 무언가를 넣을 때마다 「이게 없으면 다음 걸음이 틀리는가」를 한 번 묻는 습관입니다. 답이 「아니다」라면 넣지 않는 쪽이 대개 맞습니다.

참고: Effective context engineering for AI agents · Context Rot · Context engineering (Simon Willison) · Don't Build Multi-Agents