이제는 프롬프트가 아니라 컨텍스트다 — AI 코딩 에이전트 컨텍스트 엔지니어링 (2026)

터미널을 엽니다. MCP 서버 일곱 개가 물려 있습니다. 깃허브, 슬랙, 센트리, 파일시스템, 브라우저, 데이터베이스, 사내 위키. 편리하라고 붙여둔 것들이죠.

그리고 커서가 깜빡이는 그 순간, 아직 아무것도 입력하지 않았는데 컨텍스트 창의 33.7%는 이미 차 있습니다. 툴 정의 JSON 스키마만 67,300토큰. 깃허브 공식 MCP 서버 하나가 요청마다 17,600토큰을 먹습니다. 질문을 던지기도 전에, 모델이 집중할 수 있는 총량의 3분의 1이 "이런 도구들이 있어요"라는 설명서로 소모된 상태입니다.

프롬프트를 아무리 정성껏 다듬어도 이 숫자는 바뀌지 않습니다. 그래서 2026년의 질문은 바뀌었습니다. 어떻게 말할까가 아니라, 무엇을 보게 할까로.

프롬프트는 문장이고, 컨텍스트는 예산이다

앤트로픽은 컨텍스트 엔지니어링을 "추론 과정에서 최적의 토큰 집합을 큐레이션하고 유지하는 전략의 총체"라고 정의합니다. 프롬프트 엔지니어링이 무엇을 쓸까라면, 컨텍스트 엔지니어링은 매 호출마다 창에 무엇이 들어갈지를 누가 어떻게 결정하는가입니다. 전자는 문자열이고, 후자는 모델 호출 직전에 매번 돌아가는 시스템입니다.

여기서 핵심 개념이 어텐션 예산(attention budget)입니다. 트랜스포머는 n개 토큰에 대해 n²개의 쌍 관계를 만들어야 합니다. 토큰이 늘면 관계는 제곱으로 늘고, 한 토큰이 받는 주의력은 그만큼 얇아집니다. 창이 비어 있든 꽉 찼든 모델이 똑같이 똑똑할 거라는 가정은, 구조적으로 성립하지 않습니다.

그러니 컨텍스트 엔지니어링은 채우는 기술이 아닙니다. 빼는 기술에 가깝습니다. 정확히는, 애초에 들이지 않는 기술이고요.

더 넣을수록 나빠진다 — 숫자 세 개

감으로 하는 이야기가 아닙니다. 2026년에 나온 측정치 세 개를 나란히 놓아 보겠습니다.

1100K 요약이 5K 검색에게 졌다. 소스그래프가 동일 과제로 코딩 에이전트를 비교했을 때, 10만 토큰짜리 코드베이스 요약을 통째로 받은 에이전트가 5천 토큰짜리 표적 검색 결과만 받은 에이전트보다 못했습니다. 20배 더 많은 정보를 주고 더 나쁜 답을 받은 겁니다.

2툴 정의는 세금처럼 매 요청 부과된다. MCP 툴 하나당 이름·설명·JSON 스키마·enum을 합쳐 대략 550~1,400토큰. 서버 다섯 개에 툴 서른 개씩이면 3만~6만 토큰이 메타데이터만으로 상주합니다. 툴 수가 수십 개로 늘면 스키마가 창의 40~50%를 차지한다는 보고도 있습니다.

3검색을 갈아끼우면 도구 호출 수가 20분의 1이 된다. 소스그래프 CodeScaleBench는 370개 엔터프라이즈 과제에서 같은 에이전트에 로컬 grep만 준 경우와 코드 검색 MCP를 준 경우를 비교했습니다. 파일 회수율 0.127 → 0.277, Precision@5 0.140 → 0.478. 개별 사례가 더 극적입니다.

세 숫자가 같은 곳을 가리킵니다. 에이전트의 성능 차이는 모델을 바꿔서가 아니라, 그 모델 앞에 놓인 정보의 밀도를 바꿔서 나왔습니다. 그리고 밀도를 높이는 방향은 대체로 "더 넣기"의 반대쪽이었습니다.

업계가 내놓은 대응도 그 방향입니다. 툴 설명을 전부 싣는 대신 검색 도구 하나만 두고 필요할 때 스키마를 불러오는 방식(Tool Search)으로 토큰을 85%가량 줄이고, 아예 에이전트가 코드를 써서 SDK를 호출하게 하는 방식(Code Mode)은 98% 이상 절감을 보고합니다.

손잡이는 네 개다

그럼 실제로 뭘 조절하나. 앤트로픽이 정리한 축을 실무 언어로 옮기면 네 개입니다. 순서대로 돌려보면 대부분의 문제가 잡힙니다.

① 사전 적재 — 매번 설명하지 않아도 되는 것들

코딩 규약, 금지 사항, 빌드 명령, 디렉터리 구조. 매 세션 반복해서 설명할 필요가 없는 것들은 저장소 루트의 규약 문서에 둡니다. AGENTS.md가 사실상 표준이 됐고, 2026년 중반 기준 6만 개 이상의 오픈소스 저장소가 채택했습니다. 거버넌스는 MCP와 마찬가지로 리눅스 재단 산하 AAIF로 넘어갔고, 클로드 코드·커서·코덱스 CLI·코파일럿·제미나이 CLI 등이 네이티브로 읽습니다.

다만 앤트로픽은 여기에 "고도(altitude)"라는 단서를 답니다. 너무 구체적이면 하드코딩된 규칙 덩어리가 되어 부서지기 쉽고, 너무 추상적이면 공유되지 않은 맥락을 있다고 착각합니다. 그 사이 어딘가를 찾는 게 이 문서를 쓰는 일의 전부입니다.

② 적시 검색 — 파일 경로만 들고 다니기

전부 미리 읽어두는 대신, 파일 경로·쿼리·링크 같은 가벼운 식별자만 쥐고 있다가 필요한 순간에 도구로 불러옵니다. 사람이 일하는 방식과 같죠. 우리도 사내 위키 전체를 외우고 회의에 들어가지 않습니다. 북마크를 들고 가서 필요할 때 엽니다.

부수 효과가 큽니다. 인덱스가 낡아 사라진 API를 물고 오는 사고가 줄고, 파일명·폴더 구조·수정 시각 자체가 "이게 중요한지"에 대한 신호로 작동합니다.

③ 압축과 노트 — 창 밖에 기억을 두기

긴 작업에서 창이 찰 때, 대화를 요약해 다시 시작하는 게 압축(compaction)입니다. 클로드 코드는 아키텍처 결정·미해결 버그·구현 세부는 남기고 중복된 도구 출력은 버리는 식으로 이걸 합니다. 한 걸음 더 나아가면, 에이전트가 진행 상황을 컨텍스트 밖 파일에 메모로 적어두고 필요할 때 다시 읽게 만들 수 있습니다.

④ 서브에이전트 — 탐색의 지저분함을 격리하기

"이 기능이 어디에 구현돼 있지"를 찾는 데 드는 수십 번의 파일 열기는, 본 대화에 남을 이유가 없습니다. 탐색은 별도 에이전트에게 맡기고 정제된 결론만 돌려받으면, 본 창은 깨끗하게 유지됩니다.

여기서 의견이 갈린다

깔끔하게 끝나면 좋겠지만, 증거가 한 방향이 아닙니다.

앞서 소스그래프 벤치마크는 정교한 검색 도구가 grep을 압도한다고 말했습니다. 그런데 같은 해 나온 ContextBench는 GPT-5·클로드 소네트 4.5·제미나이 2.5 프로·데브스트랄 2와 코딩 에이전트 다섯 종을 놓고 재보더니, 정교한 스캐폴딩이 단순한 베이스라인을 일관되게 이기지는 못했다고 보고합니다. 복잡한 검색 계층을 얹는다고 반드시 나아지는 건 아니라는 겁니다.

모순처럼 보이지만, 갈리는 지점은 아마 규모입니다. 파일 수백 개짜리 단일 저장소라면 grep과 파일 경로만으로 충분하고, 오히려 인덱싱 계층이 낡은 정보를 물고 올 위험만 늘립니다. 수십만 파일 모노레포로 가면 이야기가 반대가 되고요. "무조건 검색 인프라를 깔아라"는 조언은 그래서 절반만 맞습니다.

더 불편한 사실이 하나 더 있습니다.

에이전트의 실행 시간과 토큰 사용량은 회차마다 흔들립니다. 그 노이즈 폭이 충분히 커서, 한 번 돌려 본 비교는 반대 방향을 가리키고도 설득력 있게 보일 수 있습니다. "규약 문서 넣어봤는데 별로던데요"라는 후기가 온라인에 도는 이유의 상당 부분이 여기 있을 겁니다.

정리하며

프롬프트 문구를 다듬는 일이 쓸모없어진 건 아닙니다. 다만 그건 이제 더 큰 문제의 부분집합입니다. 에이전트가 무엇을 보고 있는지 — 규약 문서, 코드베이스, 깃 히스토리, 의존성, 그리고 조용히 3만 토큰을 차지하고 있는 툴 정의까지 — 그 전체를 설계하는 일이 본체가 됐습니다.

오늘 당장 할 수 있는 건 한 가지입니다. 지금 붙여둔 MCP 서버 목록을 열어보고, 이번 주에 실제로 쓴 적 없는 걸 빼세요. 창이 비면 모델은 더 똑똑해집니다. 비유가 아니라, 측정된 사실입니다.

그다음 질문은 이겁니다. 당신의 저장소에서 에이전트가 가장 자주 길을 잃는 지점은 어디인가요? 그 한 줄이 규약 문서의 첫 항목이 됩니다.

참고 — Anthropic, Effective context engineering for AI agents · Sourcegraph, Context Engineering: A Practical Guide (2026) · AAIF, Measuring AGENTS.md · ContextBench(arXiv, 2026)