티스토리 뷰

TECH AND AI

LLM 엔지니어링 용어의 계보 2편 - 컨텍스트 엔지니어링 — 설계 대상이 문장에서 토큰 구성으로 넓어진 이유

ebson 2026. 6. 13. 08:25

들어가며 — 한 턴짜리 전제가 깨지는 순간

이 시리즈의 첫 글에서, 프롬프트 엔지니어링은 "한 턴, 한 과제"라는 전제 위에 서 있다고 정리했습니다. 입력 한 번과 출력 한 번 사이를 다듬는 일이고, 설계의 대상은 문장이었습니다. 좋은 예시를 고르고, 지시를 명확히 적고, 역할을 부여하는 모든 기법이 결국은 그 한 번의 주고받음을 최적화하는 데 모입니다.

그런데 우리가 요즘 쓰는 도구들은 한 번 묻고 한 번 답하는 방식으로 동작하지 않습니다. Claude Code에 "이 버그를 고쳐 줘"라고 한 줄 적으면, 도구는 파일을 읽고, 테스트를 돌리고, 그 결과를 보고 다시 다른 파일을 열고, 코드를 고치고, 또 테스트를 돌립니다. 한 번의 요청이 수십 번의 턴으로 풀려 나갑니다. 이 과정이 길어질수록 한 가지 문제가 분명해집니다. 모델이 매 턴 들여다보는 입력이, 더 이상 사람이 적은 한 문단이 아니라 그동안 쌓인 모든 것의 합이라는 점입니다. 시스템 지시, 도구 호출 결과, 이전 대화 전부가 한 자리를 두고 경쟁합니다.


2025년 9월, Anthropic은 이 변화를 짚는 글을 공식 엔지니어링 블로그에 올리면서 컨텍스트 엔지니어링을 "프롬프트 엔지니어링의 자연스러운 발전(natural progression of prompt engineering)"이라고 적었습니다. 바뀐 것은 기법이 아니라 단위입니다. 한 문장을 다듬던 일이, 여러 턴을 도는 시스템의 입력 전체를 관리하는 일로 넓어졌습니다. 이 글은 그 넓어짐이 어디서 왔고, 공식 문서가 그것을 정확히 무엇이라고 정의하는지를 정리해 보려 합니다. 기술적 사실은 가능한 한 Anthropic 공식 문서에서 확인되는 범위 안에서만 적겠습니다.

에이전트라는 단어가 먼저 바뀌었다

컨텍스트 엔지니어링을 이야기하기 전에, 그 배경이 된 한 단어를 먼저 정리하는 편이 낫습니다. 에이전트입니다. 이 말이 무엇을 가리키는지가 분명해야, 왜 컨텍스트가 갑자기 관리 대상이 됐는지가 따라 나옵니다.

Anthropic은 2024년 12월에 발표한 글 Building effective agents에서 워크플로(workflow)와 에이전트(agent)를 구분합니다. 워크플로는 "LLM과 도구가 미리 정해진 코드 경로를 통해 조율되는 시스템(systems where LLMs and tools are orchestrated through predefined code paths)"이라고 적습니다. 사람이 짠 코드가 "먼저 이걸 하고, 그다음 저걸 하라"는 흐름을 정해 두고, 그 안의 빈칸을 모델이 채우는 구조입니다. 반면 에이전트는 "LLM이 자신의 처리 과정과 도구 사용을 스스로 동적으로 지휘하면서, 과제를 어떻게 달성할지에 대한 통제권을 유지하는 시스템(systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks)"이라고 적습니다.

두 정의의 차이는 "다음에 무엇을 할지를 누가 정하는가"에 있습니다. 워크플로에서는 그 결정이 코드에 박혀 있습니다. 에이전트에서는 모델이 매 턴 스스로 정합니다. 파일을 더 읽을지, 테스트를 돌릴지, 이제 코드를 고칠지를 모델이 그 순간의 상황을 보고 고릅니다.

이 구분이 왜 컨텍스트 문제를 낳는지는 한 걸음만 더 가면 보입니다. 다음 행동을 모델이 스스로 정한다는 것은, 그 결정을 내리는 데 필요한 정보가 전부 모델의 입력 안에 들어와 있어야 한다는 뜻입니다. 지금까지 어떤 파일을 봤는지, 테스트가 어떻게 실패했는지, 앞에서 무엇을 시도했는지가 입력에 없으면 모델은 같은 자리를 맴돕니다. 그래서 에이전트가 길게 일할수록 입력에는 점점 더 많은 것이 쌓입니다. 워크플로라면 코드가 "이 단계에서는 이것만 보면 된다"고 잘라 줄 수 있지만, 스스로 결정하는 에이전트에서는 그 잘라 내기마저 설계의 대상이 됩니다. 무엇을 입력에 남기고 무엇을 덜어 낼지가 문제가 되는 것입니다.

컨텍스트는 유한 자원이다

여기서 자연스럽게 떠오르는 반문이 있습니다. 요즘 모델은 컨텍스트 윈도우가 수십만 토큰에 달하는데, 그냥 전부 다 넣어 두면 되지 않느냐는 것입니다. 길어진 대화를 굳이 관리할 게 아니라, 윈도우가 허락하는 만큼 계속 쌓아 두면 그만 아니냐는 생각입니다.

Anthropic의 컨텍스트 엔지니어링 글은 이 지점을 정면으로 짚습니다. 컨텍스트를 유한한 자원으로 다뤄야 한다고 적으면서, 그 근거로 세 가지를 듭니다. 첫째는 글에서 "context rot"이라고 부르는 현상입니다. 공식 문서의 표현을 그대로 옮기면, "컨텍스트 윈도우의 토큰 수가 늘어날수록, 그 컨텍스트에서 정보를 정확히 회상하는 모델의 능력은 떨어진다(as the number of tokens in the context window increases, the model's ability to accurately recall information from that context decreases)"는 것입니다. 윈도우에 더 많이 담을 수 있다는 것과, 담은 만큼 모델이 잘 활용한다는 것은 다른 이야기라는 뜻입니다.


둘째는 어텐션 예산(attention budget)이라는 비유입니다. 사람의 작업 기억에 한계가 있듯, 모델에게도 한 번에 주의를 나눠 줄 수 있는 총량에 한계가 있고, 토큰이 하나 더해질 때마다 그 예산이 줄어든다는 설명입니다. 셋째는 그 한계가 어디서 오는지에 대한 구조적 이유입니다. 트랜스포머 구조에서는 토큰 n개에 대해 n²개의 쌍 관계(n² pairwise relationships for n tokens)가 생기고, 컨텍스트가 길어질수록 이 관계가 늘어나면서 어텐션이 얇게 펴진다는 것입니다.

세 가지를 한 줄로 모으면 이렇습니다. 입력을 늘리는 데는 윈도우 크기라는 한계만 있는 게 아니라, 늘릴수록 한 토큰 한 토큰이 받는 주의가 묽어진다는 비용이 따로 있습니다. 그래서 "다 넣으면 된다"가 답이 되지 못합니다. 무엇을 넣고 무엇을 빼는가, 한정된 어텐션 예산을 어디에 쓰는가가 곧 성능을 좌우하는 결정이 됩니다. 컨텍스트가 관리할 가치가 있는 자원이 되는 이유가 여기에 있습니다.

공식 정의 — 토큰의 구성을 큐레이션한다

배경이 정리됐으니 정의를 볼 차례입니다. Anthropic은 컨텍스트 엔지니어링을 "LLM 추론 과정에서 최적의 토큰(정보) 집합을 큐레이션하고 유지하기 위한 전략의 집합(the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference)"이라고 정의합니다.

이 한 문장을 천천히 풀어 보면 단어 선택이 의도적이라는 게 보입니다. 먼저 관리 대상이 "프롬프트"가 아니라 "토큰의 집합"입니다. 사람이 적은 지시문만 가리키는 게 아니라, 추론 시점에 모델의 입력을 이루는 모든 것을 뜻합니다. 시스템 지시, 사용할 수 있는 도구의 정의, 외부에서 끌어온 데이터, 그동안 오간 메시지 이력이 전부 이 토큰 집합에 들어갑니다. 다음으로 동사가 "쓴다(writing)"가 아니라 "큐레이션하고 유지한다(curating and maintaining)"입니다. 한 번 잘 적고 끝나는 일이 아니라, 턴이 흐르는 동안 무엇을 남기고 무엇을 덜어 낼지를 계속 고른다는 뜻이 담겨 있습니다. 마지막으로 시점이 "추론 과정에서(during inference)"입니다. 모델이 한 번 답을 내놓는 그 순간, 입력이 어떤 모습이어야 가장 좋은가를 묻습니다.

이렇게 보면 "프롬프트 엔지니어링의 자연스러운 발전"이라는 표현이 단순한 수사가 아니라는 점이 분명해집니다. 프롬프트 엔지니어링은 입력의 한 부분, 사람이 적는 지시문을 다듬는 일이었습니다. 컨텍스트 엔지니어링은 그 일을 부정하지 않습니다. 다만 관리의 범위를 입력 전체로 넓히고, 한 번의 작성에서 여러 턴에 걸친 유지로 시간 축을 늘립니다. 잘 적는 일은 그대로 남되, 그 위에 "무엇을 입력에 들이고 무엇을 내보낼지"라는 층이 하나 더 얹힌 셈입니다. 설계의 대상이 문장에서 토큰의 구성으로 넓어졌다는 말은 이 뜻입니다.

전략 셋 — compaction, 구조적 노트, 서브에이전트

정의가 추상적으로 들린다면, 같은 글이 제시하는 장기 작업 전략 세 가지를 보면 손에 잡힙니다. 셋 모두 "에이전트가 한 윈도우로는 다 담을 수 없을 만큼 오래 일할 때 컨텍스트를 어떻게 다루는가"라는 한 문제를 각자의 방식으로 풉니다. 매뉴얼처럼 깊이 들어가기보다, 각 전략이 어떤 문제를 푸는지를 한 단락씩 짚겠습니다.

첫째는 compaction입니다. 대화가 윈도우 한계에 가까워지면 그때까지의 내용을 요약하고, 그 압축된 요약으로 새 윈도우를 다시 시작하는 방식입니다. 공식 문서는 이렇게 하면 "에이전트가 성능 저하를 최소화하면서 작업을 이어 갈 수 있다(enabling the agent to continue with minimal performance degradation)"고 적습니다. 앞 절에서 본 context rot을 떠올리면 이 전략의 의도가 분명합니다. 토큰이 무한정 쌓여 어텐션이 묽어지기 전에, 핵심만 남기고 윈도우를 비워 다시 시작하는 것입니다. Claude Code를 길게 쓰다 보면 대화가 자동으로 요약되며 정리되는 순간을 보게 되는데, 그 자리에서 일어나는 일이 바로 이것입니다.

둘째는 구조적 노트 작성(structured note-taking)입니다. 에이전트가 작업 중간중간 메모를 남기되, 그 메모를 컨텍스트 윈도우 바깥에 저장해 두었다가 나중에 다시 불러오는 방식입니다. 공식 문서는 이를 두고 "최소한의 부담으로 영속적인 기억(persistent memory with minimal overhead)"을 제공한다고 적습니다. compaction이 윈도우 안의 내용을 압축한다면, 이쪽은 아예 윈도우 밖에 기억을 두는 접근입니다. 입력에 계속 들고 다니지 않아도 되니 어텐션 예산을 아끼고, 필요할 때만 꺼내 오니 기억은 잃지 않습니다. 작업 계획을 파일에 적어 두고 참조하는 방식이 여기에 해당합니다.

셋째는 서브에이전트(sub-agent) 구조입니다. 특정한 작업에 집중하는 별도의 에이전트가 그 일을 처리한 뒤, 결과를 압축한 요약만 메인 에이전트에게 돌려주는 방식입니다. 공식 문서는 이 구조의 이점을 "관심사의 분명한 분리(clear separation of concerns)"라고 적고, 자세한 검색 과정의 컨텍스트가 전체 상태를 오염시키는 것을 막는다고 설명합니다. 예를 들어 코드베이스 곳곳을 뒤지는 탐색 작업은 그 자체로 많은 토큰을 만들어 내는데, 그 과정 전부를 메인 대화에 쏟아붓는 대신 "찾은 결론"만 돌려받는 것입니다. 메인 에이전트의 입력은 깨끗하게 유지되고, 탐색의 잡음은 서브에이전트 쪽에 남습니다.

셋을 나란히 놓으면 공통점이 보입니다. 모두 "쌓이는 것을 어떻게든 덜어 낸다"는 한 방향을 가리킵니다. compaction은 압축으로, 노트는 외부 저장으로, 서브에이전트는 위임으로 던다는 차이가 있을 뿐입니다. 앞에서 본 "컨텍스트는 유한 자원"이라는 문제 설정이, 이 세 전략에서 구체적인 해법으로 내려온 셈입니다.

용어의 생애주기 1막 — 트윗에서 공식 문서로

여기서 잠깐 곁가지를 짚고 가려 합니다. "context engineering"이라는 말 자체가 어떻게 공식 어휘가 됐는가입니다. 이 부분은 기술적 사실이라기보다 용어가 자리 잡는 경로에 대한 관찰이라, 근거의 성격을 분명히 해 두고 싶습니다.

이 표현은 2025년 6월 무렵 X(옛 트위터)에서 여러 사람이 쓰기 시작하며 눈에 띄었고, Andrej Karpathy의 게시물이 그중 자주 인용됩니다. 다만 이 글에서 그 게시물은 기술적 사실의 근거로 쓰지 않습니다. X 게시물은 공식 기술 문서가 아니고, 제가 확인할 수 있는 것은 "그런 발언이 존재한다"는 사실까지입니다. 누가 이 말을 가장 먼저 썼는지, 어떤 맥락에서 처음 나왔는지를 단정할 만한 공식 출처는 찾지 못했습니다. 그래서 여기서는 "2025년 중반에 개발자들 사이에서 이 표현이 돌기 시작했다" 정도로만 적고, 그 이상의 기원 주장은 하지 않겠습니다.

확인할 수 있는 사실은 그다음 단계입니다. 2025년 9월 29일, Anthropic이 Effective context engineering for AI agents라는 제목의 글을 공식 엔지니어링 블로그에 올리면서, 이 표현을 정의와 함께 공식 어휘로 채택했습니다. 비공식적으로 돌던 말이 약 3개월 뒤 공식 문서의 제목과 정의로 들어온 것입니다.

이 경로 자체가 흥미로운 관찰을 남깁니다. 기술 용어가 늘 논문이나 공식 문서에서 먼저 태어나 현장으로 내려오는 것은 아니라는 점입니다. 현장에서 먼저 말이 생기고, 그 말이 가리키는 문제가 충분히 또렷해진 뒤에 공식 문서가 정의를 입혀 거두어들이는 경로도 있습니다. 컨텍스트 엔지니어링은 후자에 가깝습니다. 이 관찰은 이 시리즈의 뒤쪽, 아직 공식 정의를 얻지 못한 용어를 다룰 때 다시 비교 대상으로 꺼낼 생각입니다. 같은 길의 더 이른 지점에 서 있는 말이 어떤 모습인지를 보기 위해서입니다.

마무리 — 토큰을 관리하는 시스템은 누가 만드나

이 글을 한 줄로 줄이면, 컨텍스트 엔지니어링은 "스스로 결정하는 멀티 턴 에이전트가 등장하면서, 설계의 대상이 사람이 적는 문장에서 추론 시점의 토큰 구성 전체로 넓어진 일"입니다. 그 배경에는 에이전트라는 단어의 의미 변화가 있었고, 컨텍스트가 윈도우 크기와 별개로 유한한 자원이라는 사실(context rot, 어텐션 예산)이 있었으며, 그 위에서 compaction·구조적 노트·서브에이전트라는 세 전략이 "쌓이는 것을 덜어 내는" 같은 문제를 각자 풀고 있었습니다.

개발자로서 이 내용을 정리하며 가장 오래 남은 생각은, 정작 이 전략들을 실행하는 주체가 모델 자신이 아니라는 점이었습니다. 대화가 한계에 가까워졌는지 판단해 요약을 띄우는 일, 메모를 어떤 파일에 어떤 형식으로 저장하고 언제 다시 불러올지 정하는 일, 서브에이전트에게 무엇을 위임하고 그 결과를 어떻게 메인 대화에 합칠지 정하는 일은 전부 모델 바깥의 코드가 합니다. 컨텍스트 엔지니어링의 정의가 "전략의 집합"이라고 적힌 것도 이 때문일 것입니다. 이것은 한 번의 추론을 잘 만드는 기법이라기보다, 추론을 둘러싸고 입력을 계속 손질하는 시스템의 설계에 가깝습니다.


그렇다면 자연스러운 다음 질문은 이렇게 됩니다. compaction을 언제 실행할지 정하고, 노트를 저장하고, 서브에이전트를 띄우는 그 바깥의 코드, 즉 모델을 둘러싼 시스템 자체는 어떻게 설계하는가. 이 시리즈의 다음 글에서 다룰 주제가 바로 그 자리에 있습니다. 컨텍스트 엔지니어링이 "입력을 무엇으로 채울까"를 물었다면, 그다음은 "그 입력을 채우고 모델을 호출하고 결과를 받아 다시 도는 구조를 무엇으로 짤까"를 묻게 됩니다. 비슷한 자리에서 쏟아지는 용어들의 계보를 정리해 보려는 분들에게 이 글이 한 칸의 참고가 되기를 바라며 마무리합니다.

참고한 공식 문서

용어 유래 참고 

'TECH AND AI' 카테고리의 다른 글

LLM 엔지니어링 용어의 계보 4편 - 프롬프트·컨텍스트·하네스·루프 — 네 용어의 계보를 한 글에 정리하기  (0) 2026.06.13
LLM 엔지니어링 용어의 계보 3편 - 하네스 엔지니어링 — 최고 모델도 혼자서는 장기 작업에 실패합니다  (1) 2026.06.13
LLM 엔지니어링 용어의 계보 1편 - 프롬프트 엔지니어링 — 문장 쓰기가 엔지니어링이 된 출발점  (1) 2026.06.13
LLM Agent는 왜 같은 Tool을 30번 호출했을까 2편: LLM Agent의 Tool Loop를 막는 3계층 방어 패턴  (1) 2026.03.20
LLM Agent는 왜 같은 Tool을 30번 호출했을까 1편: LangChain4j 기반 Agent의 Tool Loop 문제 발생과 근본 원인 분석  (1) 2026.03.20