Context Engineering (컨텍스트 엔지니어링)
프롬프트 엔지니어링이 "모델에게 어떻게 지시할 것인가"를 다룬다면, 컨텍스트 엔지니어링은 모델이 이번 추론에서 실제로 보게 될 정보를 어떻게 구성할 것인가를 다룹니다. 에이전트에서는 시스템 프롬프트뿐 아니라 도구 정의, 검색 결과, 메시지 이력, 메모리, 중간 실행 결과까지 모두 컨텍스트에 들어갑니다.
문제는 컨텍스트 창이 크다고 해서 그 안의 정보를 모두 같은 품질로 활용하는 것은 아니라는 점입니다. 관련 없는 정보가 늘어나면 필요한 근거를 찾기 어려워지고, 오래된 도구 결과나 잘못된 중간 판단이 남아 있으면 이후 추론까지 오염시킬 수 있습니다. 긴 컨텍스트를 지원하는 능력과 긴 컨텍스트를 안정적으로 사용하는 능력은 같은 개념이 아닙니다.
그래서 핵심은 많이 넣는 것이 아니라 현재 판단에 필요한 고신호 정보만 남기는 것입니다. 필요 없는 정보는 밖에 저장하고(Write), 필요한 것만 다시 선택하며(Select), 오래된 이력은 압축하고(Compress), 독립적인 하위 작업은 별도 컨텍스트로 격리합니다(Isolate).
컨텍스트 엔지니어링은 결국 프롬프트 한 문장을 다듬는 작업이 아니라, 에이전트가 여러 스텝을 실행하는 동안 정보의 생명주기를 관리하는 작업입니다.
1장. 프롬프트 엔지니어링만으로는 부족한 이유
프롬프트 엔지니어링은 개별 지시문을 잘 쓰는 법이고, 컨텍스트 엔지니어링은 추론 시점에 창을 채우는 토큰 전체를 고르고 유지하는 전략입니다.
단발성 챗봇은 프롬프트 하나로 끝납니다. 에이전트는 계획하고 도구를 부르고 결과를 받고 다시 판단하기를 여러 턴 반복합니다.
그러면서 컨텍스트가 눈덩이처럼 누적되고, 매 턴 이번 추론에 무엇이 실제로 필요한지를 다시 결정해야 합니다. 프롬프트 한 줄이 아니라 컨텍스트 상태 전체가 관리 대상이 됩니다.
이 관점을 한 문장으로 압축하면 다음과 같습니다.
좋은 컨텍스트는 많은 컨텍스트가 아니다. 바라는 결과의 확률을 최대화하는 가장 작은 고신호 토큰 집합을 찾는 것이다.
아래의 모든 기법은 결국 이 목표를 서로 다른 방식으로 구현합니다.
2장. 긴 컨텍스트가 곧 좋은 컨텍스트는 아니다
전통적인 full self-attention은 길이 n에 대해 토큰 쌍 상호작용이 O(n²)로 늘어나지만, 이 계산 복잡도만으로 장문맥 성능 저하를 설명할 수는 없습니다. 중요한 것은 모델이 긴 입력 안에서 관련 정보를 찾아내고 방해 정보를 무시하며, 필요한 관계를 끝까지 유지해야 한다는 점입니다. 그래서 컨텍스트 길이는 단순한 저장 공간이 아니라 관련성 관리가 필요한 추론 자원으로 보는 편이 낫습니다.
Chroma의 Context Rot 보고서입니다. GPT-4.1, Claude 4, Gemini 2.5, Qwen3 등 18개 모델을 평가했습니다.
모델은 컨텍스트를 균일하게 쓰지 않는다. 입력이 길어질수록 성능이 점점 더 불안정해진다.
실험에서 특히 눈에 띄는 결과는 세 가지입니다. 먼저 의미로 찾아야 하는 정보일수록 취약합니다. 질문과 정답의 표면 유사도가 낮을수록 길이에 따라 더 빨리 무너집니다. 키워드가 딱 맞는 검색은 버티지만 의미로 연결해야 하는 것은 무너집니다.
방해 정보의 악영향이 증폭됩니다. 관련 없는 문서 하나가 짧은 컨텍스트에서는 별 영향이 없지만 길어지면 판단을 크게 흐립니다.
가장 반직관적인 것은 haystack structure 실험입니다. Chroma가 사용한 특정 needle-retrieval 설정에서는 같은 문장들을 논리적으로 이어 둔 원문보다 문장 순서를 섞은 haystack에서 18개 모델 모두 더 높은 성능을 보였습니다. 구조가 언제나 해롭다는 보편 법칙이 아니라, 자연스러운 서사가 오히려 검색해야 할 단서와 경쟁하는 distractor가 될 수 있음을 보여준 실험입니다.
관련 정보가 컨텍스트에 있느냐만으로 충분하지 않고, 어떤 정보와 어떤 구조 속에 배치되는지도 성능에 영향을 준다.
따라서 이 결과는 문서를 일부러 뒤섞으라는 처방보다 불필요한 서사와 근접한 방해 정보를 줄이고 실제 과제에 필요한 부분을 선택하라는 근거로 읽는 편이 안전합니다.
2023년 연구는 당시 모델들이 관련 정보가 입력의 처음이나 끝에 있을 때보다 중간에 있을 때 성능이 낮아지는 U자형 경향을 보일 수 있음을 보여줬습니다. 이후 모델에서 위치 편향의 모양은 달라질 수 있지만, Chroma의 2025년 결과도 길이·방해 정보·표현 방식에 따라 장문맥 활용 신뢰도가 흔들린다는 더 넓은 문제를 확인했습니다.
3장. 실제로 관리해야 하는 다섯 가지
관리 대상은 시스템 프롬프트, 도구 정의, 예시, 검색 결과와 외부 데이터, 메시지 이력입니다. 통짜가 아니라 조각마다 관리 원칙이 다릅니다.
너무 구체적이면 하드코딩된 조건문 나열이 되어 취약해지고, 너무 추상적이면 모호해집니다. 행동을 이끌 만큼 구체적이되 모델에게 판단 여지를 줄 만큼 유연한 곳을 찾고, 섹션으로 나눠 최소 집합으로 유지합니다.
자주 생기는 실패 중 하나가 너무 많은 기능을 덮거나 어느 도구를 쓸지 모호한 비대한 도구 집합입니다. 인간 엔지니어조차 어느 도구를 써야 하는지 판단 기준이 모호한 상황이라면 에이전트의 도구 선택도 불안정해지기 쉽습니다.
엣지케이스를 잔뜩 나열하지 않고 기대 행동을 잘 보여주는 정준적인 예시를 고릅니다.
원시 검색·도구 출력은 컨텍스트를 빠르게 키울 수 있습니다. 검색 5건이 각 2,000토큰이면 1만 토큰인데 그중 실제로 쓰이는 것은 몇 문장일 수 있습니다.
실행이 길어질수록 도구 호출과 결과가 매 턴 쌓이기 때문입니다.
다섯 조각 전부에 같은 잣대를 댑니다. 정보적이되 빡빡하게 유지합니다.
4장. Write·Select·Compress·Isolate
컨텍스트 창 (유한한 주의 예산)
시스템 프롬프트
도구 정의
메시지 이력
도구 실행 결과
네 갈래로 관리한다
① Write 밖에 저장 ──► 외부 저장소
파일, 메모리, 벡터 DB
② Select 필요한 것만 ◄── 거기서 골라 다시 넣음
③ Compress 창 안에서 ──► 요약하고 정리
④ Isolate 하위작업 분리 ──► 서브에이전트
깨끗한 컨텍스트에서 실행
요약만 반환쓰기는 지금 당장 필요 없는 정보를 창 밖으로 내보냅니다. 세션 안에서는 스크래치패드로, 세션을 넘어서는 파일이나 DB로 보냅니다. 창이 무거워지지 않으면서 정보는 잃지 않습니다.
선택은 밖에 쌓아둔 것 중 이번 스텝에 필요한 것만 골라 넣습니다. 흥미로운 사례로 도구 선택에도 검색을 적용하는 방식이 있습니다. 도구 설명을 검색이나 선택기로 좁혀 주면 불필요한 스키마를 줄이고 도구 선택을 더 안정적으로 만들 수 있습니다. 도구가 수십 개인 에이전트에서 전부를 넣는 대신 지금 상황에 맞는 것만 넣습니다.
압축은 대화가 길어지면 오래된 이력을 요약하거나 compact해서 부피를 줄입니다. 장시간 동작하는 코딩 에이전트도 컨텍스트 한계에 가까워지면 이전 작업을 요약해 다음 컨텍스트로 넘기는 방식을 사용합니다. 정확한 트리거 비율은 제품과 버전에 따라 바뀔 수 있으므로 고정 숫자보다 무엇을 보존하고 무엇을 압축할지가 핵심입니다.
격리는 무거운 하위 작업을 서브에이전트나 샌드박스로 분리합니다. 각자 깨끗한 컨텍스트에서 좁은 작업을 하고 메인에는 결론 요약만 돌려줍니다. 멀티에이전트 구조가 여기 속합니다.
5장. 에이전트 런타임에서는 어떻게 구현하나
컨텍스트 엔지니어링은 추상적인 원칙에 그치지 않고 에이전트 런타임 기능으로 들어가고 있습니다. 예를 들어 LangChain은 모델 호출 전후에 컨텍스트를 바꿀 수 있는 middleware를 제공하고, 오래된 대화를 요약하거나 도구 결과를 정리하는 전략을 기본 컴포넌트로 제공합니다.
| 미들웨어 | 전략 | 주요 인자 |
|---|---|---|
| SummarizationMiddleware | 압축 | trigger로 요약 시점, keep으로 원문 분량, token_counter로 세는 방법 |
| ContextEditingMiddleware | 선택 | edits로 무엇을 지울지. ClearToolUsesEdit는 오래된 도구 호출과 결과를 지움 |
오래된 도구 호출과 결과를 지운다는 것이 기본 편집 규칙입니다.
도구 결과를 먼저 정리하는 이유가 있습니다. 에이전트가 여러 스텝을 돌면 검색 결과와 도구 출력이 반복해서 누적되어 컨텍스트의 큰 비중을 차지하기 쉽습니다. 이미 판단에 반영됐고 다시 참조할 가능성이 낮은 원시 출력은 최근 결과만 남기거나 placeholder로 치환할 수 있습니다. ClearToolUsesEdit가 이 패턴을 기본 전략으로 제공한다는 점이 실무적인 의미입니다.
Summarization은 오래된 내용을 새로운 요약으로 바꾸기 때문에 정보의 일부를 보존하지만 추가 모델 호출과 요약 오류 가능성이 있습니다. ContextEditing은 오래된 tool result처럼 재사용 가치가 낮은 항목을 지우거나 placeholder로 바꿔 즉시 토큰을 줄입니다. 별도 요약 모델 호출은 필요 없지만 삭제한 세부 정보는 이후 추론에서 사용할 수 없습니다.
실무에서는 섞습니다. 도구 결과는 지우고 대화 흐름은 요약합니다.
6장. Context rot·distraction·poisoning
context rot은 길이가 늘면서 신뢰도가 떨어지는 것입니다. 앞부분 지시를 무시하고, 중간에 넣은 정보를 못 찾고, 턴이 진행될수록 답이 나빠지는 것이 증상입니다.
distraction은 과잉 컨텍스트가 판단을 흐리는 것입니다. 혹시 필요할까 봐 넣은 문서가 오히려 답을 망칩니다. 앞서 본 두 번째 발견이 이것을 실측으로 보여줍니다. 길수록 방해 정보의 악영향이 증폭됩니다.
poisoning은 환각이 컨텍스트에 눌러앉는 것입니다. 모델이 한 번 잘못 말한 내용이 이력에 남아 다음 턴에서 사실처럼 참조됩니다. 에이전트 루프에서 특히 위험한데 잘못된 관찰이 계속 재사용되기 때문입니다.
대응은 도구 결과를 검증하고 넣는 것, 틀린 턴을 이력에서 제거하는 것, 주기적으로 요약해 오염을 끊는 것입니다.
7장. RAG는 전체 문제의 한 부분이다
RAG는 외부에서 필요한 것을 찾아 넣는 것이고, 컨텍스트 엔지니어링은 창에 들어가는 토큰 전체를 관리하는 것입니다. RAG는 컨텍스트 엔지니어링의 한 수단이고 선택 전략의 구현 하나입니다.
시스템 프롬프트 길이, 도구 정의 개수, 메시지 이력 누적, 도구 결과 정리는 전부 RAG 밖의 문제이고 전부 성능에 영향을 줍니다.
실무에서 문제를 진단할 때는 다음 순서가 유용합니다.
① 창에 뭐가 들어가는지 실제로 센다
② 안 써도 되는 걸 뺀다
③ 그래도 부족하면 밖에 저장하고 골라 넣는다 (RAG)
④ 그래도 길면 압축한다
⑤ 그래도 안 되면 분리한다이 순서는 절대 규칙은 아니지만 좋은 진단 순서입니다. 외부 지식이 실제로 필요한 문제라면 처음부터 RAG가 필요할 수 있습니다. 다만 컨텍스트가 이미 과도하게 부풀어 있는 문제를 검색 시스템 하나로 해결하려고 하면 검색 결과까지 더해져 오히려 악화될 수 있으므로, retrieval과 context budgeting을 함께 설계해야 합니다.
8장. 실무에서는 무엇부터 측정할까
컨텍스트에 실제로 몇 토큰이 들어가는지 시스템 프롬프트와 도구 정의, 검색 결과, 메시지 이력으로 나눠 셉니다. 세보면 대개 도구 정의와 검색 결과가 예상보다 큽니다.
쓰이지 않는 도구가 있는지, 검색 결과 원문을 그대로 넣고 있는지, 예시가 필요 이상으로 많은지, 시스템 프롬프트에 중복이 있는지 봅니다.
요약 트리거를 걸었는지, 도구 결과 정리를 걸었는지, 도구가 많으면 선택기를 넣었는지 확인합니다.
컨텍스트를 줄인 뒤 품질이 유지되는지 잽니다. 줄였더니 빨라졌다만 보고 품질 회귀를 안 재면 안 됩니다.
9장. 좋은 컨텍스트의 기준
컨텍스트 엔지니어링은 프롬프트 문구 하나가 아니라 각 모델 호출에 어떤 정보가 들어가고, 상태에 무엇이 남고, 무엇을 밖으로 보낼지를 관리하는 작업입니다. 긴 컨텍스트를 지원한다는 사양만으로 실제 활용 품질이 보장되지 않으며, Chroma의 18개 모델 실험처럼 길이와 distractor, 정보 배치가 성능을 흔들 수 있습니다.
실무 전략은 크게 쓰기, 선택, 압축, 격리로 볼 수 있습니다. 최근 에이전트 프레임워크는 summarization, tool selection, context editing, subagent 같은 기능으로 이 전략을 직접 지원합니다.
결국 목표는 컨텍스트를 무조건 짧게 만드는 것이 아니라 현재 판단에 필요한 신호는 남기고 이미 소비된 원시 출력과 무관한 정보를 제거하는 것입니다.
용어 정리
| 용어 | 한 줄 뜻 |
|---|---|
| 컨텍스트 엔지니어링 | 추론 시점에 창을 채우는 토큰 전체를 고르고 유지하는 규율 |
| 주의 예산 | 모델이 컨텍스트 전체에 나눠 쓰는 한정된 어텐션 |
| context rot | 입력이 길어질수록 성능이 불안정해지는 현상 |
| distraction | 과잉 컨텍스트가 판단을 흐리는 것 |
| poisoning | 환각이 이력에 남아 이후 턴에서 사실처럼 참조되는 것 |
| Lost in the Middle | 긴 컨텍스트에서 가운데 정보를 흘리는 현상 |
| Write (쓰기) | 지금 필요 없는 정보를 창 밖 저장소로 내보내는 전략 |
| Select (선택) | 저장된 것 중 이번 스텝에 필요한 것만 골라 넣는 전략 |
| Compress (압축) | 요약으로 컨텍스트 부피를 줄이는 전략 |
| Isolate (격리) | 하위 작업을 서브에이전트로 분리해 요약만 받는 전략 |
SummarizationMiddleware |
요약 전략을 구현한 LangChain 미들웨어 |
ContextEditingMiddleware |
컨텍스트 편집을 구현한 LangChain 미들웨어 |
ClearToolUsesEdit |
오래된 도구 호출과 결과를 지우는 편집 규칙 |
| 고신호 토큰 | 결과에 실제로 기여하는 정보를 담은 토큰 |
참고자료
- Anthropic, "Effective context engineering for AI agents"
- Chroma, "Context Rot: How Increasing Input Tokens Impacts LLM Performance" (18개 모델 평가)
- LangChain Docs, "Context engineering in agents"
- LangChain Docs, Built-in middleware
- Lost in the Middle: How Language Models Use Long Contexts (arXiv 2307.03172). Figure 5 가 정답 문서 위치에 따른 U 자 성능 곡선이다. ar5iv
- langchain 소스,
agents/middleware(Summarization, ContextEditing)
'LLM > Context' 카테고리의 다른 글
| Prompt Caching (프롬프트 캐싱) (0) | 2025.09.01 |
|---|
댓글