학습 목표:
- 프롬프트 엔지니어링과 컨텍스트 엔지니어링의 정의를 다시 진술하고, 이 둘이 '대체'가 아니라 '진화'인 이유 말하기
- '주의 예산'과 '컨텍스트 로트'라는 두 개념으로, '윈도가 충분히 크니 전부 밀어 넣자'는 발상의 어디가 어긋나는지 동료에게 설명하기
- 이 시리즈의 '에이전트 하네스 기초: 루프와 통제' 코스에서 만든 하네스 루프에서, 컨텍스트가 늘어나기만 하고 줄어들지 않는 지점 짚어내기
전제: 이 시리즈의 '에이전트 하네스 기초: 루프와 통제' 코스를 마쳤고,
stop_reason이 구동하는 동작하는 루프를 손에 쥐고 있어야 합니다 | 다음: 레슨 2 >>
이 시리즈의 '에이전트 하네스 기초: 루프와 통제' 코스에서 여러분은 이런 루프를 손으로 직접 썼습니다(단순화한 형태입니다. 턴 상한, 예산을 비롯한 네 개의 제어 밸브는 일단 덜어냈습니다).
그때 우리의 주의는 온통 제어 흐름에 쏠려 있었습니다. stop_reason 을 어떻게 읽을지, 제어 밸브를 어떻게 달지 말입니다. 이제 각도를 바꿔 messages 배열을 가만히 들여다보십시오. 이 배열은 push 되기만 할 뿐, 한 번도 덜어내지지 않습니다. 매 턴 최소한 두 가지가 들어옵니다. 이번 턴 모델의 답변(그 안의 tool_use 블록까지)과, 도구가 돌려준 결과입니다. 두 번째 쪽이 부피의 대부분을 차지하는 경우가 많습니다. list_files 한 번이 파일 이름 수백 개를 물어 오는 장면, 로그 검색 한 번이 수십 KB의 원문 텍스트를 물어 오는 장면을 떠올려 보십시오. 그 순간부터 그것들은 윈도 안에 영원히 눌러앉아, 추론이 한 바퀴 돌 때마다 처음부터 다시 읽힙니다.
이것은 여러분의 구현이 어설퍼서 생긴 실수가 아니라 에이전트의 본성입니다. "An agent running in a loop generates more and more data that could be relevant for the next turn of inference"(루프 안에서 도는 에이전트는 다음 추론 턴에 관련이 있을 수 있는 데이터를 점점 더 많이 생성한다)1, 게다가 에이전트는 자율성을 쥐고 있으므로 아주 많은 턴 동안 계속 나아갈 수 있습니다2. 이 시리즈의 '프롬프트 엔지니어링 기초: 효과적인 지시문 쓰는 법' 코스에서 여러분은 하나의 지시문을 명확하게 쓰는 법을 배웠습니다. 그러나 지시문을 아무리 잘 써도 그것은 여전히 윈도 안의 작은 한 덩어리일 뿐입니다. 40번째 턴에서 에이전트가 어떻게 행동할지를 실제로 결정하는 것은, 그 순간 윈도 전체에 놓여 있는 모든 것입니다.
이 관찰을 형식화하면 두 개의 정의가 나옵니다.
프롬프트 엔지니어링: "Prompt engineering refers to methods for writing and organizing LLM instructions for optimal outcomes"(프롬프트 엔지니어링이란 최적의 결과를 얻기 위해 LLM 지시문을 작성하고 조직하는 방법들을 가리킨다)1. 이것이 답하는 질문은 이렇습니다. "이 지시문을 어떻게 쓰고 어떻게 배치해야 가장 효과가 좋을까?"
컨텍스트 엔지니어링: "the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference"(LLM 추론 중에 최적의 토큰(정보) 집합을 선별하고 유지하기 위한 전략들의 집합)1. 이것이 답하는 질문은 이렇습니다. "이번 추론에서 어떤 토큰이 윈도 안에 있어야 하고, 어떤 토큰은 있으면 안 되는가?"
시점이 한 단계 올라간 것에 주목하십시오. 앞의 것은 한 번으로 끝나는 글쓰기 문제입니다. 한 번 써 두면 그것으로 정해집니다. 뒤의 것은 루프가 한 바퀴 돌 때마다 다시 답해야 하는 절충입니다. Anthropic은 컨텍스트 엔지니어링을 프롬프트 엔지니어링의 자연스러운 다음 단계로 명시적으로 자리매김합니다. "we view context engineering as the natural progression of prompt engineering"(우리는 컨텍스트 엔지니어링을 프롬프트 엔지니어링의 자연스러운 진전으로 본다)1. 그러니 이 시리즈의 '프롬프트 엔지니어링 기초: 효과적인 지시문 쓰는 법' 코스에서 쌓은 실력은 조금도 낭비되지 않습니다. 그것은 더 큰 문제의 부분집합이 됩니다. 시스템 프롬프트는 여전히 잘 써야 하지만, 그것은 이제 여러분이 관리해야 할 여러 컨텍스트 재료 중 하나일 뿐입니다.
커뮤니티에는 더 과감한 견해도 있습니다. 2026년의 어느 에이전트 엔지니어링 로드맵은 "Prompt engineering is dead as a standalone skill in 2026."(2026년에 프롬프트 엔지니어링은 독립된 기술로서는 죽었다)3라고 단언합니다. 다만 이것은 그 로드맵의 주관적 단정이며, 이 레슨은 그것을 합의된 견해로 다루지 않습니다. Anthropic의 표현은 훨씬 신중합니다. 대체가 아니라 진화입니다1. 그렇더라도 같은 로드맵이 컨텍스트 엔지니어링에 붙인 한 줄짜리 정의는 기억해 둘 만합니다. "deciding what tokens are in front of the model at every step of the loop"(루프의 매 단계에서 어떤 토큰을 모델 앞에 둘지 결정하는 것)3. 그리고 같은 로드맵은 하네스가 얼마나 중요한지도 정확히 짚습니다. "Same model, different harness, completely different result."(같은 모델, 다른 하네스, 완전히 다른 결과)3 — 이 시리즈의 '에이전트 하네스 기초: 루프와 통제' 코스의 실험을 통해 이미 몸으로 느끼고 있을 이야기입니다.
왜 이것이 관리해야 하는 대상일까요? 윈도가 크면 그냥 마음대로 써도 되는 것 아닐까요? 여기서 첫 번째 물리적 사실이 등장합니다.
"LLMs have an "attention budget" that they draw on when parsing large volumes of context"(LLM은 대량의 컨텍스트를 파싱할 때 끌어다 쓰는 '주의 예산'을 가지고 있다)1. 문제는 이 예산이 유한하다는 점입니다. "Every new token introduced depletes this budget by some amount"(새로 들어오는 토큰은 하나하나 이 예산을 얼마간 고갈시킨다)1.
비유를 하나 들겠습니다. 윈도 용량은 창고의 바닥 면적이고, 주의 예산은 물건을 찾으러 들여보내는 인력입니다. 창고를 열 배로 넓혀도 인력이 함께 늘지는 않습니다. 선반이 빽빽할수록 정작 필요한 물건 하나를 파내기가 더 어려워집니다. '혹시 몰라서' 문서를 하나 더 윈도에 밀어 넣는 것은 공짜 백업이 아니라, 그것을 읽고 배제하는 비용을 치르느라 예산에서 실제로 빠져나가는 지출입니다.
이 관점으로 뒤집어 보면 다시 살펴봐야 할 습관이 꽤 많습니다. '윈도가 담을 수 있으니 API 문서를 통째로 붙여 넣자'에서, 담는 것은 창고의 문제이고 잘 읽는 것은 예산의 문제입니다. 이 둘은 같은 것이 아닙니다.
예산이 계속 빠져나갈 때 나타나는 거시적 결과에는 생생한 이름이 붙어 있습니다. 바로 컨텍스트 로트입니다. "as the number of tokens in the context window increases, the model's ability to accurately recall information from that context decreases"(컨텍스트 윈도 안의 토큰 수가 늘어날수록, 그 컨텍스트에서 정보를 정확히 회상하는 모델의 능력은 떨어진다)1.
잘못 이해하기 쉬운 두 가지 세부를 여기서 못 박아 둡니다.
첫째, 급격한 추락이 아니라 점진적입니다. 이 저하는 성능의 비탈로 나타납니다. "These factors create a performance gradient rather than a hard cliff"(이 요인들은 단단한 절벽이 아니라 성능의 경사를 만든다)1. 어떤 토큰 수를 넘어서면 갑자기 동작을 멈추는 절벽이 아닙니다. 그래서 에러는 결코 나지 않고, 에이전트가 천천히 둔해질 뿐입니다. 일상적인 표현으로 옮기면 이렇습니다(출처의 열거가 아니라, 엔지니어링 경험에서 흔히 나타나는 모습입니다). 앞서 확인한 관례를 잊기 시작하고, 이미 읽은 파일을 또 읽고, 이미 고친 버그를 되돌립니다. 경보가 울리지 않는 저하는 에러보다 추적하기 어렵습니다.
둘째, 어떤 모델 하나의 버릇이 아니라 일반 법칙입니다. 다른 모델보다 완만하게 저하하는 모델도 있지만, "some models exhibit more gentle degradation than others, this characteristic emerges across all models"(어떤 모델은 다른 모델보다 완만한 저하를 보이지만, 이 특성은 모든 모델에서 나타난다)1. 더 강한 모델로 바꾸면 문제를 뒤로 미룰 수는 있어도 없앨 수는 없습니다.
이 둘을 합치면 이 레슨의 첫 번째 주춧돌이 나옵니다. "context, therefore, must be treated as a finite resource with diminishing marginal returns"(따라서 컨텍스트는 한계 수익이 체감하는 유한한 자원으로 다뤄져야 한다)1. 윈도에 밀어 넣는 천 번째 토큰과 십만 번째 토큰은 차지하는 자리는 같지만, 보태는 가치는 하늘과 땅 차이입니다. '많을수록 안전하다'는 직감은 방향이 정확히 거꾸로입니다. 우겨 넣는 '보험'이 하나 늘어날 때마다, 정작 중요한 정보에 대한 모델의 주의는 그만큼 묽어집니다.
한 번의 질의응답에서는 컨텍스트 로트를 알아채지 못할 수도 있습니다. 윈도는 한 번 쓰이고 버려지며, 토큰 수도 대개 위험 구간까지 가지 않습니다. 에이전트는 이 문제를 '가끔 마주치는 것'에서 '매 턴 나빠지는 것'으로 바꿔 놓습니다. 루프 안의 데이터는 늘어나기만 하고 줄어들지 않으며1, 에이전트는 자율적으로 아주 많은 턴을 돌 수 있습니다2. 서두의 코드를 다시 보십시오. push 만 받고 아무것도 내놓지 않는 저 messages 배열이 바로 이 과정을 눈에 보이게 만든 것입니다.
현장의 엔지니어링 경험도 완전히 들어맞습니다. Claude Code 공식 문서는 "Claude's context window fills up fast, and performance degrades as it fills."(Claude의 컨텍스트 윈도는 빠르게 차오르고, 차오르는 만큼 성능은 저하된다)4라고 적습니다. 같은 문서는 컨텍스트 윈도를 "the most important resource to manage."(관리해야 할 가장 중요한 자원)4라고 부릅니다. 같은 문서에는 받아 적어 둘 만한 관찰도 있습니다. "A clean session with a better prompt almost always outperforms a long session with accumulated corrections."(더 나은 프롬프트로 시작한 깨끗한 세션은, 수정이 누적된 긴 세션보다 거의 언제나 낫다)4 — '오래 대화했다'가 '잘 대화했다'는 아니며, 쌓인 수정 하나하나와 흘러간 곁길 하나하나는 여전히 윈도 안에 앉아 다음 추론에 참여합니다.
그래서 컨텍스트 엔지니어링의 정확한 자리는 이렇습니다. 튜닝 단계에서 더하는 마무리 광택이 아니라, 에이전트 신뢰성의 토대입니다. 이 시리즈의 '에이전트 하네스 기초: 루프와 통제' 코스의 네 개 제어 밸브가 관리하는 것은 '루프를 폭주시키지 않기'입니다. 이 과정이 달아 주는 것은 또 한 벌의 기구, '윈도를 썩히지 않기'입니다. 두 벌이 갖춰져야 비로소 여러분의 하네스는 긴 작업을 맡길 만한 것이 됩니다.
긴 시간 축의 작업에 대해 Anthropic은 세 부류의 기법을 정리합니다. "compaction, structured note-taking, and multi-agent architectures,"(컴팩션, 구조화된 노트 작성, 그리고 멀티 에이전트 아키텍처)로, 에이전트가 "maintain coherence, context, and goal-directed behavior over sequences of actions"(일련의 행동에 걸쳐 일관성과 컨텍스트, 목표 지향적 행동을 유지)하도록 돕는 것을 겨냥합니다1. 이 과정은 그 길을 따라갑니다.
마지막으로 분수에 관한 당부 하나. 이 기구들은 하나같이 복잡성을 더하며, Anthropic의 엔지니어링 지침은 이렇게 말합니다. "you should consider adding complexity only when it demonstrably improves outcomes."(복잡성은 그것이 결과를 입증 가능하게 개선할 때에만 더하는 것을 고려해야 한다)2 그래서 앞으로의 모든 레슨은 '어떻게 하는가'보다 '언제 할 만한가'를 먼저 설명합니다. 모든 에이전트에 서브에이전트가 필요하지는 않고, 모든 작업이 컴팩션할 가치가 있지도 않습니다.
>> 레슨 2: 컨텍스트의 해부: 시스템 프롬프트, 도구, 예시
Effective context engineering for AI agents — Anthropic Engineering — https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 ↩19 ↩20
Building Effective AI Agents — Anthropic Engineering — https://www.anthropic.com/engineering/building-effective-agents ↩ ↩2 ↩3 ↩4
The 2026 Agent Engineering Roadmap — GitHub (codejunkie99/agent-roadmap-2026) — https://github.com/codejunkie99/agent-roadmap-2026 ↩ ↩2 ↩3 ↩4
Best practices for Claude Code — Claude Code Docs — https://code.claude.com/docs/en/best-practices ↩ ↩2 ↩3 ↩4
let response = await client.messages.create({
model: MODEL, max_tokens: 1024, tools, messages, // messages 배열을 눈여겨보십시오
});
while (response.stop_reason === "tool_use") {
messages.push({ role: "assistant", content: response.content });
const toolResults = await runToolUses(response.content, toolImpls);
messages.push({ role: "user", content: toolResults }); // 도구 결과도 함께 들어옵니다
response = await client.messages.create({
model: MODEL, max_tokens: 1024, tools, messages,
});
}