프롬프팅 방법을 이미 알고 있는 사람들을 위한 컨텍스트 엔지니어링 (Context Engineering)

지난 2년 동안 프롬프팅 (Prompting) 실력을 키우는 데 시간을 보냈다면, 아마도 2026년 내내 그 기술은 이제 끝났으며 "컨텍스트 엔지니어링 (Context Engineering)"이 그것을 대체했다는 말을 크고 반복적으로 들어왔을 것입니다.

그러한 프레임은 무시하세요. 그것은 틀렸으며, 이를 믿는 것은 당신을 두 가지 모두에 더 서툴게 만들 것입니다.

정확한 버전은 다음과 같습니다: 프롬프트 엔지니어링 (Prompt Engineering)은 컨텍스트 엔지니어링 (Context Engineering)의 하위 집합입니다. 프롬프팅 (Prompting)은 당신이 모델에게 _말하는 것_입니다. 컨텍스트 엔지니어링 (Context Engineering)은 당신이 말을 할 때 모델이 볼 수 있는 모든 것 — 시스템 프롬프트 (System Prompt), 도구 정의 (Tool Definitions), 검색된 문서 (Retrieved Documents), 이전 대화 (Prior Turns), 그리고 메모리 (Memory) — 을 큐레이션하는 규율입니다. 당신이 정성스럽게 작성한 프롬프트는 그 더 큰 영역 내부의 하나의 (하중을 견디는) 구성 요소입니다. 이 용어를 대중화하는 데 가장 큰 역할을 한 Anthropic은 그들의 주제에 관한 글에서도 여전히 "시스템 프롬프트 디자인 (System Prompt Design)"과 "퓨샷 프롬프팅 (Few-shot Prompting)"을 컨텍스트 엔지니어링 (Context Engineering) 기술로 나열하고 있습니다. 아무것도 죽지 않았습니다. 영역이 더 커졌을 뿐입니다.

이 포스트는 이미 프롬프팅을 잘하고 있으며 다음 단계로 나아가고 싶은 엔지니어들을 위한 것입니다: 컨텍스트 엔지니어링 (Context Engineering)이 기계적으로 실제로 무엇인지, 그리고 내재화할 가치가 있는 몇 가지 패턴들에 대해 다룹니다.

더 큰 컨텍스트 윈도우 (Context Window)가 당신을 구원하지 못한 이유

2025년의 유혹적인 생각은 긴 컨텍스트 윈도우 (Context Window)가 이 모든 것을 무의미하게 만들 것이라는 점이었습니다 — 그냥 모든 것을 집어넣고 모델이 알아서 정리하게 두면 된다는 것이었죠. 그것은 작동하지 않았으며, 왜 그런지 이해할 가치가 있습니다. 왜냐하면 그 이유가 이 규율의 전체 기초이기 때문입니다.

백만 토큰의 윈도우 (window)를 가진 모델이라고 해서 백만 토큰의 사용 가능한 어텐션 (attention)을 갖는 것은 아닙니다. 트랜스포머 (Transformer) 어텐션은 시퀀스 길이 (sequence length)의 제곱에 비례하여 확장됩니다. 즉, 모든 토큰은 다른 모든 토큰과 관계를 맺어야 하므로, 어텐션은 당신이 추가하는 모든 토큰이 소모하는 유한한 예산과 같습니다. 더 많은 입력은 단순히 비용과 지연 시간 (latency)만을 발생시키는 것이 아니라, 모델의 집중 능력을 희석시킵니다.

이는 당신이 반드시 이름을 알아야 할 두 가지 방식으로 경험적으로 나타납니다:

중간에서의 손실 (Lost in the middle). 모델은 정보가 컨텍스트 (context)의 시작 또는 _끝_에 위치할 때 가장 안정적으로 정보를 사용하며, 관련 내용이 중간에 파묻혀 있을 때는 측정 가능한 수준으로 성능이 저하됩니다. 이는 명시적으로 롱 컨텍스트 (long-context) 모델로 마케팅되는 모델들조차 마찬가지입니다. 이것이 해당 효과의 이름을 명명한 Liu et al. 논문이며, 후속 연구는 이러한 U자형 어텐션 편향 (U-shaped attention bias)이 본질적임을 보여주었습니다. 즉, 시작과 끝 토큰은 관련성 여부와 상관없이 더 많은 어텐션을 받습니다.
컨텍스트 부패 (Context rot). Chroma는 제가 본 것 중 가장 엄격한 테스트 — 최신 GPT, Claude, Gemini, Qwen 출시 버전을 포함한 18개 모델 — 를 수행했으며, 의도적으로 사소한 작업에서도 입력 길이가 길어짐에 따라 회상 (recall) 및 추론 (reasoning) 능력이 저하된다는 것을 발견했습니다. 당신을 괴롭힐 만한 발견은 다음과 같습니다: 모델들은 종종 논리적으로 일관된 문서보다 섞여 있는 컨텍스트에서 더 높은 점수를 기록했습니다. 용량 (Capacity)이 곧 활용 (utilization)은 아닙니다.

따라서 Anthropic의 표현을 빌리자면, 컨텍스트 엔지니어링 (context engineering)의 목표는 "원하는 결과의 가능성을 극대화하는, 신호가 높은 (high-signal) 최소한의 토큰 집합을 찾는 것"입니다. 가장 큰 컨텍스트가 아니라, 작동하는 가장 작은 컨텍스트를 찾는 것입니다.

내재화할 가치가 있는 패턴들

컨텍스트 윈도우(window)가 하나의 예산(budget)이라는 점을 받아들이고 나면, 그에 따른 관행들이 자연스럽게 도출됩니다. 여기 제가 여러분이 반드시 이해하기를 바라는 6가지 패턴이 있으며, 각 패턴별로 수행해야 할 작업과 이를 통해 방지할 수 있는 실패 모드(failure mode)를 정리했습니다.

패턴	수행할 작업	방지하는 실패 모드
어텐션 예산 편성 (Attention budgeting)	토큰을 예산처럼 취급하세요. 신호가 높은(high-signal) 콘텐츠에 비용을 쓰고, 상용구(boilerplate), 죽은 이력(dead history), 중복된 도구 문서(tool docs)는 가차 없이 잘라내세요.	컨텍스트 부패 (Context rot) — 윈도우가 채워짐에 따라 발생하는 점진적인 성능 저하.
...

검색(Retrieval)은 그 자체로 매우 깊이 있는 주제입니다. 만약 이 분야를 더 깊게 파고들고 싶다면, 인터뷰에서 팀들이 RAG에 대해 묻는 질문들이 일반적인 실패 모드들을 꽤 잘 보여줍니다. 하지만 컨텍스트 엔지니어링(context engineering) 측면에서 핵심적인 통찰은 단순히 "우리가 검색을 했는가"가 아니라, _배치(placement)와 절제(restraint)_에 있습니다.

메모리 패턴(memory pattern)은 대부분의 사람들이 과소평가하는 부분입니다. Anthropic의 장기 실행 에이전트(long-running agent) 연구는 이 패턴에 크게 의존합니다. 구조화된 진행 파일(progress files)을 작성하고 세션 시작 시 이를 다시 읽어들이는 에이전트들은, 단일 윈도우에는 절대 담을 수 없는 수백 또는 수천 단계에 걸쳐 일관성을 유지합니다. 윈도우는 작업 기억(working memory)이며, 지속 가능한 상태(durable state)는 그 외부에 존재합니다.

버려야 할 오해들

"프롬프팅은 끝났다 (Prompting is dead)." 아닙니다. 프롬프팅은 컨텍스트 엔지니어링의 하위 집합일 뿐입니다. 시스템 프롬프트 (system prompt)와 당신의 퓨샷 예시 (few-shot examples)는 일급 컨텍스트 엔지니어링 구성 요소입니다. 잘못 작성된 지시사항을 엔지니어링만으로 극복할 수는 없습니다. "좋은 프롬프팅"이 무엇을 의미하는지 압박 테스트를 해보고 싶다면, 사람들이 프롬프트 엔지니어링 면접을 위해 연습하는 기본 원칙들이 괜찮은 체크리스트가 될 것입니다. 그 계층은 이제 덜 중요한 것이 아니라, 더 중요해졌습니다.
"그냥 더 큰 컨텍스트 윈도우 (window)를 사용하면 된다." Chroma의 연구는 이를 정면으로 반박합니다. 쉬운 작업에서도 길이가 길어질수록 성능이 저하되며, 일관성 있는 긴 문서가 섞인(shuffled) 문서보다 오히려 성능이 더 나빴습니다. 용량(Capacity)이 곧 활용도(utilization)는 아닙니다.
"컨텍스트가 많을수록 좋다." 컨텍스트가 많아지면 어텐션 예산 (attention budget)이 희석되며, 핵심 사실이 중간의 데드 존 (dead zone)에 빠질 확률이 높아집니다. 신호가 높은 (high-signal) 최소한의 집합이 승리합니다.
"컨텍스트 엔지니어링은 그저 RAG일 뿐이다." RAG는 하나의 메커니즘입니다. 도구 결과 포맷팅 (tool-result formatting), 메모리 (memory), 압축 (compaction), 스키마 설계 (schema design), 그리고 시스템/턴 분리 (system/turn separation)가 모두 범위 내에 있습니다. 배치 (placement)와 예산 책정 (budgeting)의 규율이 없는 RAG는 여전히 실패합니다.

내가 의도적으로 인용하지 않는 수치들

이 주제에 대해 찾아보시다 보면 두 가지 수치를 계속 접하게 될 것입니다. "리더의 82%가 프롬프팅만으로는 충분하지 않다고 말한다"라는 통계와, "컨텍스트 엔지니어링을 통해 작업 완료율이 83%에서 96%로 급증했다"라는 주장입니다. 저는 두 가지 모두 출처를 찾아보려 노력했습니다. 82%는 컨텍스트 툴링을 판매하는 회사의 조사로, 발표된 방법론이 없는 벤더 설문조사에서 기인했습니다. 83%→96%는 실제로는 아무도 수행하지 않은 전/후 비교를 위해 서로 관련 없는 두 개의 벤치마크를 이어 붙인 것으로 보입니다.

따라서 저는 둘 다 반복하지 않을 것이며, 여러분도 그러지 말아야 합니다. 위에서 언급한 메커니즘 — 유한한 어텐션 (finite attention), 위치 편향 (position bias), 측정 가능한 컨텍스트 부패 (context rot) — 은 실재하며 재현 가능합니다. 이 실습을 정당화하기 위해 가짜 정밀함 (fake precision)은 필요하지 않습니다.

이것이 당신에게 남기는 것

컨텍스트 엔지니어링 (Context engineering)은 기존의 무언가를 대체하기 위해 나타난 새로운 것이 아닙니다. 이는 훌륭한 프롬프팅 (prompting)이 항상 존재해 왔던 더 넓은 영역을 일컫는 이름입니다. 다만 에이전트 (agents), 도구 (tools), 그리고 검색 (retrieval)이 등장하면서, 우리는 더 이상 창문의 나머지 부분을 무시할 수 없게 되었을 뿐입니다. 이는 조용히 AI 엔지니어링 역할 (AI engineering roles)의 기본 요소가 되었습니다. 이제는 단순히 운영 중 발생한 문제에 대한 사후 분석 (post-mortems)뿐만 아니라, 인터뷰에서도 등장하고 있습니다.

만약 당신이 이미 프롬프팅을 잘하고 있다면, 처음부터 다시 시작하는 것이 아닙니다. 당신은 당신의 프롬프트가 항상 소비하고 있었던 예산을 관리하는 법을 배우고 있는 것입니다.

추가 읽을거리:

Anthropic — Effective context engineering for AI agents
Anthropic — Effective harnesses for long-running agents
Chroma — Context Rot (18개 모델 연구 + 재현 가능한 툴킷)
Liu et al. — Lost in the Middle
Found in the Middle (U자형 편향이 발생하는 이유)