블로그 | 모하지?

이 글은 Anthropic Engineering의 글 “Effective context engineering for AI agents”를 바탕으로, 한국어 독자가 이해하기 쉽도록 다시 구성한 해설 글입니다. 원문의 문제의식과 주요 논점을 빠짐없이 다루되, 문장을 그대로 옮긴 번역문이 아니라 개념과 실천 방법을 풀어 설명하는 방식으로 작성했습니다.

프롬프트 엔지니어링 다음에 온 질문: “무엇을 보여줄 것인가”

LLM을 다루는 방법은 처음에는 주로 “프롬프트를 어떻게 잘 쓰느냐”에 집중되어 있었습니다. 어떤 지시문을 넣을지, 시스템 프롬프트를 어떻게 정리할지, 예시를 몇 개 줄지 같은 문제가 핵심이었죠.

하지만 AI 에이전트가 단순한 한 번짜리 답변 생성기를 넘어, 여러 번 생각하고 도구를 호출하고 작업을 이어가는 존재가 되면서 문제의 중심이 바뀌었습니다. 이제 중요한 질문은 단순히 “어떤 문장으로 지시할 것인가”가 아닙니다.

더 큰 질문은 이것입니다.

지금 이 모델에게 어떤 정보 묶음을 보여줘야 원하는 행동이 가장 잘 나올까?

여기서 말하는 정보 묶음이 바로 **컨텍스트(context)**입니다. LLM이 답변을 생성할 때 참고하는 토큰 전체, 즉 시스템 지시문, 사용자 메시지, 이전 대화, 도구 설명, 도구 실행 결과, 외부 문서, 검색 결과, 메모리 등이 모두 컨텍스트에 포함됩니다.

Anthropic이 말하는 **컨텍스트 엔지니어링(context engineering)**은 이 제한된 컨텍스트 공간에 어떤 정보를 넣고, 무엇을 빼고, 언제 다시 가져올지를 설계하는 일입니다. 쉽게 말하면 “모델의 작업대 위에 무엇을 올려둘지 관리하는 기술”입니다.

컨텍스트는 넓어졌지만, 무한하지 않다

요즘 모델들은 예전보다 훨씬 긴 컨텍스트 창을 지원합니다. 그래서 얼핏 보면 “그냥 관련 있어 보이는 정보를 전부 넣으면 되는 것 아닌가?”라고 생각하기 쉽습니다. 하지만 실제로는 그렇지 않습니다.

Anthropic은 LLM도 사람처럼 어느 순간부터 집중력이 흐려지고 혼란스러워진다고 설명합니다. 긴 문서 안에 특정 정보를 숨겨두고 모델이 그 정보를 잘 찾아내는지 보는 ‘needle-in-a-haystack’류 평가에서도 비슷한 현상이 관찰됩니다. 컨텍스트가 길어질수록 모델이 그 안의 정보를 정확히 회수하는 능력이 떨어지는 현상, 이른바 context rot이 나타납니다.

중요한 점은 이것이 특정 모델 하나의 약점이 아니라는 것입니다. 어떤 모델은 더 완만하게 성능이 떨어지고, 어떤 모델은 더 빨리 흔들릴 수 있지만, 긴 컨텍스트에서 집중력이 희석되는 문제는 전반적으로 나타납니다.

그래서 컨텍스트는 “많을수록 좋은 것”이 아니라 한계효용이 줄어드는 유한한 자원으로 봐야 합니다.

왜 긴 컨텍스트가 어려운가: attention budget의 관점

LLM은 Transformer 구조를 기반으로 합니다. Transformer에서는 각 토큰이 다른 토큰들과 관계를 맺으며 의미를 파악합니다. 토큰이 n개라면 토큰 간 관계는 대략 n² 규모로 늘어납니다.

컨텍스트가 길어질수록 모델은 더 많은 토큰 관계를 고려해야 합니다. 이때 모델의 주의력, 즉 attention은 무한히 정밀하게 확장되지 않습니다. 긴 컨텍스트 안에서 중요한 정보와 덜 중요한 정보가 섞이면, 모델은 필요한 연결을 놓치거나 멀리 떨어진 정보를 덜 정확하게 활용할 수 있습니다.

또 하나의 이유는 학습 데이터의 분포입니다. 모델은 보통 짧은 시퀀스를 긴 시퀀스보다 훨씬 더 많이 접하며 학습합니다. 따라서 아주 긴 문맥 전체에 걸친 의존 관계를 정교하게 처리하는 경험은 상대적으로 적습니다.

물론 position encoding interpolation 같은 기법을 통해 모델은 더 긴 입력을 다룰 수 있게 됩니다. 다만 이것은 “긴 입력을 받을 수 있다”는 뜻이지, “긴 입력에서도 짧은 입력만큼 모든 정보를 똑같이 잘 활용한다”는 뜻은 아닙니다. 성능은 절벽처럼 갑자기 무너지기보다 완만한 기울기로 낮아집니다. 모델은 여전히 강력하지만, 긴 컨텍스트에서 정보 검색과 장거리 추론의 정밀도는 떨어질 수 있습니다.

그래서 좋은 에이전트를 만들려면 컨텍스트를 신중하게 다뤄야 합니다.

좋은 컨텍스트의 핵심: 작지만 신호가 강한 정보

Anthropic의 핵심 원칙은 단순합니다.

원하는 결과가 나올 가능성을 최대화하는, 가능한 한 작은 고신호 토큰 집합을 만들어라.

여기서 “작다”는 말은 무조건 짧게 쓰라는 뜻이 아닙니다. 필요한 정보는 충분히 줘야 합니다. 다만 불필요한 반복, 오래된 도구 출력, 애매한 지시, 서로 겹치는 예시처럼 모델의 주의를 흐리는 요소를 줄여야 한다는 뜻입니다.

이 원칙은 시스템 프롬프트, 도구 설계, 예시, 메시지 히스토리, 외부 검색 결과 등 컨텍스트의 모든 구성 요소에 적용됩니다.

시스템 프롬프트: 너무 딱딱하지도, 너무 흐릿하지도 않게

시스템 프롬프트는 에이전트의 기본 행동 방식을 정하는 중요한 컨텍스트입니다. Anthropic은 시스템 프롬프트가 명확하고 단순한 언어로 작성되어야 한다고 말합니다.

여기서 중요한 표현이 “적절한 고도”입니다. 시스템 프롬프트는 너무 낮은 고도에서도, 너무 높은 고도에서도 실패합니다.

너무 낮은 고도는 복잡한 if-else 규칙을 프롬프트에 잔뜩 박아 넣는 방식입니다. 예를 들어 “A면 B를 하고, C면 D를 하고, 단 E가 있으면 F를 하라” 같은 규칙이 끝없이 늘어나는 형태입니다. 이런 프롬프트는 당장은 잘 작동해 보일 수 있지만, 상황이 조금만 바뀌어도 깨지기 쉽고 유지보수가 어려워집니다.

반대로 너무 높은 고도는 “사용자를 잘 도와줘”, “정확하게 답해줘”, “좋은 품질로 처리해줘”처럼 추상적인 지시만 주는 방식입니다. 이런 지시는 모델에게 구체적인 행동 신호를 주지 못합니다. 작성자는 어떤 맥락을 당연히 알고 있다고 생각하지만, 모델은 그 맥락을 공유하지 못할 수 있습니다.

좋은 시스템 프롬프트는 두 극단 사이에 있습니다. 원하는 행동을 충분히 구체적으로 알려주되, 상황마다 모델이 유연하게 판단할 수 있는 휴리스틱을 남겨둡니다.

실무적으로는 프롬프트를 섹션으로 나누는 것이 도움이 됩니다. 예를 들어 배경 정보, 지시사항, 도구 사용 지침, 출력 형식 같은 구획을 Markdown 헤더나 XML 태그로 나누는 방식입니다. 모델이 점점 강해지면서 정확한 포맷 자체의 중요성은 줄어들 수 있지만, 정보를 구조적으로 배치하는 습관은 여전히 유용합니다.

가장 좋은 접근은 처음부터 거대한 프롬프트를 쓰는 것이 아닙니다. 가능한 한 단순한 프롬프트로 시작해, 실제 실패 사례를 보고 필요한 지시와 예시를 추가하는 편이 낫습니다.

도구 설계: 에이전트의 행동 공간을 정리하는 일

도구는 에이전트가 외부 세계와 상호작용하는 통로입니다. 파일을 읽고, 검색하고, API를 호출하고, 코드를 실행하는 모든 행위가 도구를 통해 일어납니다.

도구는 단순한 기능 목록이 아닙니다. 에이전트가 어떤 정보를 가져올 수 있고 어떤 행동을 할 수 있는지 정의하는 계약입니다. 그래서 도구는 컨텍스트 효율성에 큰 영향을 미칩니다.

좋은 도구는 다음 조건을 만족해야 합니다.

모델이 언제 써야 하는지 분명해야 합니다.
기능이 서로 과도하게 겹치지 않아야 합니다.
입력 파라미터가 모호하지 않아야 합니다.
실패 상황에도 견고해야 합니다.
반환값이 불필요하게 장황하지 않아야 합니다.
모델이 효율적인 행동을 하도록 유도해야 합니다.

현장에서 자주 나타나는 실패 모드는 도구가 너무 많고 서로 애매하게 겹치는 것입니다. 사람이 봐도 어떤 도구를 써야 할지 확신하기 어렵다면, 에이전트가 더 잘 고르길 기대하기 어렵습니다.

도구가 많아질수록 모델은 도구 설명을 더 많이 읽어야 하고, 선택지도 늘어나며, 잘못된 도구를 호출할 가능성도 커집니다. 따라서 에이전트에게 필요한 최소한의 도구 집합을 선별하는 일은 성능뿐 아니라 장기적인 유지보수에도 중요합니다.

예시는 규칙집이 아니라 ‘대표 장면’이어야 한다

Few-shot prompting, 즉 예시를 주는 방식은 여전히 강력합니다. 하지만 예시를 많이 넣는다고 항상 좋아지는 것은 아닙니다.

팀들이 자주 하는 실수는 가능한 모든 엣지 케이스를 프롬프트에 넣으려는 것입니다. “이 경우에는 이렇게, 저 경우에는 저렇게”를 끝없이 추가하다 보면 프롬프트는 규칙집처럼 비대해집니다. 그러면 모델은 핵심 패턴보다 세부 조건에 끌려가거나, 서로 충돌하는 신호를 받게 됩니다.

Anthropic이 권하는 방식은 다양하면서도 대표성 있는 예시를 고르는 것입니다. LLM에게 좋은 예시는 천 마디 설명보다 강한 그림과 같습니다. 예시는 “이런 상황에서 이런 식으로 판단하면 된다”는 행동의 형태를 보여줍니다.

따라서 예시는 많아야 좋은 것이 아니라, 정확히 어떤 행동을 기대하는지 잘 보여주는 표준 사례여야 합니다.

런타임 검색: 모든 것을 미리 넣지 말고, 필요할 때 꺼내라

기존의 많은 AI 애플리케이션은 모델 호출 전에 임베딩 검색으로 관련 문서를 찾아 컨텍스트에 넣는 방식을 사용했습니다. 이 방식은 여전히 유용하지만, 에이전트가 더 자율적으로 도구를 사용하게 되면서 새로운 전략이 중요해지고 있습니다.

Anthropic은 이를 “just-in-time context”라고 설명합니다. 모든 데이터를 미리 넣어두는 대신, 파일 경로, 저장된 쿼리, 웹 링크 같은 가벼운 참조만 들고 있다가 필요할 때 도구로 실제 내용을 불러오는 방식입니다.

Claude Code가 좋은 예입니다. 큰 데이터베이스나 코드베이스를 다룰 때 모든 내용을 한 번에 컨텍스트에 넣지 않습니다. 대신 필요한 쿼리를 작성하고, 결과를 저장하고, head, tail, grep, glob 같은 도구로 필요한 부분만 확인합니다. 이렇게 하면 전체 자료를 모델의 작업 기억에 올리지 않고도 복잡한 분석을 수행할 수 있습니다.

이 방식은 사람의 사고 방식과도 닮았습니다. 우리는 모든 문서를 머릿속에 외우지 않습니다. 파일 시스템, 북마크, 메일함, 노트 같은 외부 구조를 만들고 필요할 때 찾아봅니다.

메타데이터도 컨텍스트다

파일의 내용만 중요한 것이 아닙니다. 파일 이름, 폴더 위치, 수정 시간, 크기 같은 메타데이터도 중요한 신호입니다.

예를 들어 tests/test_utils.py라는 파일과 src/core_logic/test_utils.py라는 파일은 이름이 같아도 역할이 다르게 느껴집니다. 폴더 구조는 그 파일이 어떤 맥락에서 쓰이는지 알려줍니다. 파일 크기는 복잡도를 암시하고, 수정 시간은 최근성과 관련 있을 수 있습니다.

에이전트가 이런 단서를 활용해 점진적으로 탐색하면, 처음부터 모든 정보를 넣지 않아도 상황을 층층이 이해할 수 있습니다. 이를 progressive disclosure, 즉 점진적 공개라고 볼 수 있습니다. 필요한 만큼만 보고, 다음 판단에 따라 더 깊이 들어가는 방식입니다.

이 전략의 장점은 에이전트가 관련 없는 정보에 압도되지 않는다는 것입니다. 단점도 있습니다. 런타임 탐색은 미리 계산된 검색 결과를 바로 넣는 것보다 느릴 수 있습니다. 또한 도구와 탐색 휴리스틱이 잘 설계되어 있지 않으면, 에이전트가 잘못된 길을 헤매며 컨텍스트와 시간을 낭비할 수 있습니다.

그래서 어떤 작업에서는 하이브리드 전략이 가장 효과적입니다. 일부 핵심 정보는 처음부터 넣어 속도를 확보하고, 나머지는 에이전트가 필요에 따라 탐색하게 합니다. Claude Code도 이런 방식에 가깝습니다. CLAUDE.md 같은 파일은 초기에 컨텍스트로 넣고, 나머지 파일들은 glob, grep 같은 도구로 필요할 때 찾아갑니다.

법률이나 금융처럼 콘텐츠가 상대적으로 덜 변하고, 사전에 정리된 자료의 가치가 큰 분야에서는 이런 하이브리드 접근이 특히 유용할 수 있습니다. 반대로 코드베이스처럼 빠르게 변하고 구조가 복잡한 환경에서는 에이전트가 직접 탐색하는 능력이 더 중요해질 수 있습니다.

Anthropic의 실용적인 조언은 단순합니다. 작동하는 가장 단순한 방식을 택하라. 모델이 더 똑똑해질수록 사람의 과도한 사전 큐레이션보다, 모델이 스스로 필요한 정보를 찾아가는 설계가 더 자연스러워질 가능성이 큽니다.

긴 작업을 위한 컨텍스트 엔지니어링

짧은 질의응답에서는 컨텍스트 관리가 비교적 쉽습니다. 하지만 대규모 코드 마이그레이션, 장시간 리서치, 복잡한 분석처럼 수십 분에서 몇 시간에 걸친 작업에서는 문제가 달라집니다.

이런 장기 작업에서는 에이전트가 목표를 잊지 않고, 앞서 내린 결정과 아직 해결되지 않은 문제를 유지하며, 여러 단계의 행동을 일관되게 이어가야 합니다. 그런데 토큰 수는 언젠가 컨텍스트 창을 초과합니다.

“더 큰 컨텍스트 창이 나오면 해결되지 않을까?”라고 생각할 수 있습니다. 하지만 Anthropic은 앞으로도 긴 컨텍스트에는 오염과 관련성 문제가 남을 것이라고 봅니다. 특히 최고의 에이전트 성능이 필요한 상황에서는 단순히 더 많이 넣는 것만으로 충분하지 않습니다.

이를 해결하기 위한 대표 기법은 세 가지입니다.

compaction
structured note-taking
multi-agent architecture

Compaction: 대화를 압축해 새 작업 기억으로 이어가기

Compaction은 컨텍스트 창이 한계에 가까워졌을 때, 지금까지의 대화와 작업 내용을 고충실도 요약으로 압축한 뒤 새 컨텍스트 창에서 이어가는 방식입니다.

핵심은 단순 요약이 아닙니다. 앞으로의 작업에 필요한 결정, 구조, 미해결 버그, 구현 세부사항은 보존하고, 중복된 도구 출력이나 이미 의미가 사라진 메시지는 버려야 합니다.

Claude Code에서는 메시지 히스토리를 모델에게 넘겨 중요한 내용을 압축하게 하고, 최근 접근한 파일 일부를 함께 유지하는 방식이 사용된다고 설명합니다. 사용자는 컨텍스트 한계를 신경 쓰지 않고 작업을 계속 이어갈 수 있습니다.

Compaction의 어려움은 무엇을 남기고 무엇을 버릴지 판단하는 데 있습니다. 너무 공격적으로 압축하면 나중에 중요해질 수 있는 미묘한 단서를 잃어버릴 수 있습니다. 반대로 너무 보수적으로 압축하면 불필요한 정보가 계속 남아 컨텍스트를 오염시킵니다.

실무적으로는 복잡한 에이전트 실행 기록을 바탕으로 compaction 프롬프트를 조정해야 합니다. 처음에는 recall, 즉 관련 정보를 빠뜨리지 않는 쪽을 우선하고, 이후 precision, 즉 불필요한 내용을 줄이는 방향으로 개선하는 것이 좋습니다.

가장 안전하고 가벼운 형태의 압축 중 하나는 오래된 도구 호출 결과를 지우는 것입니다. 오래전에 실행한 도구의 원본 출력이 항상 필요할까요? 대개는 아닙니다. 필요한 사실만 남기고 원본 결과는 제거하는 것이 컨텍스트 관리에 도움이 됩니다.

Structured note-taking: 에이전트가 자기 노트를 남기게 하기

Structured note-taking, 또는 agentic memory는 에이전트가 컨텍스트 창 밖에 지속되는 메모를 남기는 방식입니다. 이후 필요한 시점에 그 메모를 다시 컨텍스트로 불러옵니다.

예를 들어 Claude Code가 할 일 목록을 만들거나, 커스텀 에이전트가 NOTES.md 파일을 유지하는 패턴이 여기에 해당합니다. 에이전트는 작업 진행 상황, 의존 관계, 결정 사항, 다음 액션을 노트에 기록해 둡니다. 그러면 수십 번의 도구 호출 이후에도 중요한 맥락을 잃지 않습니다.

Anthropic은 Claude가 포켓몬을 플레이한 사례도 언급합니다. 이 사례에서 에이전트는 수천 단계에 걸친 게임 진행 중 목표, 레벨, 탐험한 지역, 달성한 이벤트, 전투 전략 등을 기록했습니다. 컨텍스트가 초기화된 뒤에도 자기 노트를 읽고 긴 훈련이나 던전 탐험을 계속 이어갈 수 있었습니다.

중요한 점은 메모리가 단지 “예전 대화를 기억한다”는 기능이 아니라는 것입니다. 메모리는 장기 작업에서 전략과 상태를 유지하는 외부 작업 기억입니다. 모든 것을 컨텍스트 창 안에 보관하려는 대신, 필요한 상태를 파일이나 메모리 도구에 구조화해 저장하는 것이 더 안정적입니다.

Anthropic은 Sonnet 4.5 출시와 함께 Claude Developer Platform에서 파일 기반 메모리 도구를 공개 베타로 제공한다고 소개합니다. 이 도구는 에이전트가 컨텍스트 창 밖에 정보를 저장하고 나중에 참조할 수 있게 해, 세션을 넘어 프로젝트 상태와 지식 기반을 유지하는 데 도움을 줍니다.

Sub-agent architecture: 한 에이전트가 모든 것을 기억하지 않게 하기

세 번째 전략은 sub-agent architecture입니다. 하나의 에이전트가 프로젝트 전체 상태를 모두 들고 있으려 하지 않고, 전문화된 하위 에이전트들에게 특정 작업을 맡기는 방식입니다.

메인 에이전트는 큰 계획과 조율을 담당합니다. 하위 에이전트는 깨끗한 컨텍스트 창을 가진 상태로 특정 리서치나 기술 작업을 깊게 수행합니다. 하위 에이전트는 수만 토큰을 쓰며 탐색할 수 있지만, 메인 에이전트에게는 정제된 요약만 돌려줍니다.

이 구조의 장점은 관심사의 분리입니다. 세부 탐색 과정에서 생긴 방대한 컨텍스트는 하위 에이전트 안에 머물고, 메인 에이전트는 결과를 종합하고 판단하는 데 집중합니다.

Anthropic은 복잡한 연구 작업에서 다중 에이전트 연구 시스템이 단일 에이전트보다 큰 성능 향상을 보였다고 설명합니다. 병렬 탐색의 가치가 큰 작업에서는 특히 효과적입니다.

다만 모든 작업에 다중 에이전트가 필요한 것은 아닙니다. 작업 성격에 따라 선택해야 합니다.

대화 흐름과 앞뒤 맥락이 중요한 작업에는 compaction이 잘 맞습니다.
명확한 마일스톤이 있는 반복 개발 작업에는 structured note-taking이 좋습니다.
여러 갈래의 탐색과 분석이 필요한 복잡한 리서치에는 multi-agent architecture가 유리합니다.

결국 컨텍스트 엔지니어링은 ‘주의력 관리’다

컨텍스트 엔지니어링은 LLM 개발의 초점을 바꿉니다. 예전에는 “좋은 프롬프트 문장을 쓰는 법”이 중심이었다면, 이제는 “매 순간 모델의 제한된 주의력 안에 무엇을 넣을 것인가”가 핵심입니다.

시스템 프롬프트를 명확히 쓰는 것도, 도구를 간결하게 설계하는 것도, 예시를 대표적으로 고르는 것도, 런타임에 필요한 정보만 가져오는 것도, 긴 작업에서 압축과 메모리와 하위 에이전트를 쓰는 것도 모두 같은 원칙으로 연결됩니다.

원하는 결과를 낼 가능성을 가장 크게 만드는, 가장 작고 신호가 강한 컨텍스트를 구성하라.

모델이 더 강해질수록 사람은 덜 세세하게 지시하고, 에이전트는 더 자율적으로 정보를 탐색하게 될 것입니다. 하지만 그때에도 컨텍스트가 귀중한 자원이라는 사실은 바뀌지 않을 가능성이 큽니다.

좋은 AI 에이전트를 만든다는 것은 결국 모델에게 더 많은 것을 무작정 보여주는 일이 아닙니다. 필요한 때에, 필요한 만큼, 가장 쓸모 있는 정보를 보여주는 일입니다.

실무자가 바로 가져갈 수 있는 체크리스트

마지막으로 이 글의 관점을 실제 에이전트 설계에 적용한다면 다음 질문을 점검해 볼 수 있습니다.

시스템 프롬프트가 너무 추상적이거나, 반대로 너무 많은 if-else 규칙으로 굳어 있지는 않은가?
도구 목록이 사람에게도 명확하게 구분되는가?
도구 반환값이 모델에게 필요한 정보만 주는가, 아니면 로그를 과하게 쏟아내는가?
예시가 많기만 한가, 아니면 대표적인 행동 패턴을 잘 보여주는가?
모든 문서를 미리 넣고 있지는 않은가?
파일 경로, 링크, 쿼리 같은 참조를 들고 있다가 필요할 때 불러오는 구조를 만들 수 있는가?
장기 작업에서 압축, 노트, 하위 에이전트 중 어떤 방식이 가장 자연스러운가?
오래된 도구 결과와 중복 메시지를 계속 컨텍스트에 남겨두고 있지는 않은가?
에이전트가 스스로 진행 상황과 결정을 기록할 장소가 있는가?

이 질문들에 답하다 보면, 컨텍스트 엔지니어링은 거창한 새 유행어가 아니라 에이전트를 안정적으로 일하게 만드는 아주 실용적인 설계 원칙이라는 점이 분명해집니다.

원문: Effective context engineering for AI agents — Anthropic Engineering