2022년경부터, LLM의 「내부 지식」의 한계를 보완하기 위해 외부 데이터베이스에서 정보를 주입하는 RAG(검색 증강 생성)나1, 추론과 행동을 반복시키는 AI 에이전트의 메커니즘이 널리 실용화되어 왔다2. 하지만, 보다 복잡한 비즈니스 실무로의 적용이 진행됨에 따라, 이러한 기존 접근 방식의 구조적인 한계가 드러나기 시작했다.

정보를 잘게 나누어(Chunk) 부분적으로 검색·주입하는 RAG에서는, 문서 전체에 걸친 조망적인 트렌드 파악이나, 스토리·수식의 전후 관계(Coherence)를 유지한 고도의 추론이 매우 어렵다. 또한, 자율적으로 태스크를 반복하는 에이전트에서도, 사고 단계가 길어짐에 따라 과거의 기억이나 궤도 수정 지시(Context)가 파탄되어, 태스크의 미궁이나 비용의 무한 증식을 초래한다는 치명적인 과제를 안고 있었다.

이러한 기존 접근 방식의 「컨텍스트의 분단·망각」을 해결하기 위해, 2023년부터 2026년에 걸쳐, LLM이 한 번에 다룰 수 있는 컨텍스트 윈도우(Context Window)를 수십만에서 수백만 토큰으로 극적으로 대용량화하는 기술 혁신이 일어났다3. 이를 통해, 책 한 권이나 대규모 소스 코드, 수 시간의 영상 데이터를 있는 그대로 모델에 통째로 투입하는 접근이 가능해졌다.

하지만, 입력 용량의 확대(Long Context화)가 단순히 생 데이터를 채워 넣기만 하면 되는 것이 아니라는 점이 밝혀지는4 등의 새로운 과제가 인식되었다. 이에 따라 모델이 가장 효율적이고 정확하게 컨텍스트(문맥)를 이해·유지·처리할 수 있도록, 입력 공간 그 자체를 동적으로 최적화·제어해야 한다는 사상에 기반한 「컨텍스트 엔지니어링(Context Engineering)」이라는 접근 방식이 주목받게 된다.

본 기사에서는 컨텍스트 엔지니어링에 관한 기술을 정리하였다.

프롬프트나 대화 이력, RAG의 텍스트에는 방대한 「冗長性(중복성/낭비)」이 있다는 점에 착목하여, 작은 별도의 언어 모델(GPT-2나 LLaMA 등)의 퍼플렉서티(Perplexity)를 이용하여, 타겟 LLM의 추론에 영향을 주지 않는 불필요한 토큰을 검지·삭제하고, 최대 20배까지 프롬프트를 「압축」하는 기술. API 호출 직전에, 시스템 측에서 불필요한 토큰(자연어의 불필요한 수식어 등)을 후킹하여 물리적으로 깎아내어 빼는 수법에 관한 연구5.

시스템의 흐름은 다음과 같다.

• Distribution Alignment(분포 얼라이먼트 / 사전 준비)

• 작은 모델과 타겟 LLM의 언어 분포의 괴리를 메우기 위한 사전 튜닝.

• Budget Controller(예산 컨트롤러)

• 프롬프트의 각 요소에 동적으로 압축률을 할당.

• Iterative Token-level Prompt Compression(반복적 토큰 레벨 프롬프트 압축)

• 토큰 단위로 조건부 확률을 계산하여, 불필요한 토큰을 삭제.

• Compressed Prompt Execution(압축 프롬프트 실행)

• 실제로 압축된 프롬프트를 타겟 LLM에 투입하여 추론을 수행.

운영체제(OS)의 「가상 메모리(Paging)」 개념을 LLM에 도입하여, LLM의 컨텍스트 윈도우를 「주기억(물리 메모리)」, 외부의 벡터 DB나 로컬 로그 등을 「디스크(외부 스토리지)」로 간주한 아키텍처에 관한 연구6.

LLM 스스로 함수(Tool)를 실행하게 하여, 지금 필요하지 않은 기억을 컨텍스트에서 몰아내고(Evict), 필요할 때만 스토리지에서 로드하는 메커니즘을 구축하여, 컨텍스트를 단순한 「흘러나오는 이력 로그」로 만드는 것이 아니라, 시스템 측에서 깔끔하게 구조화하여 구분하고, 동적으로 넣고 빼는 방식.

주요 4가지 제어 컴포넌트(메커니즘)는 다음과 같다.

• Queue Manager

• LLM으로의 입력(사용자 발언이나 시스템 통지)을 「이벤트」로서 큐(Queue)로 관리하여, LLM의 컨텍스트 윈도우에 순차적으로 공급하는 제어 기구.

• 메시지가 넘칠 것 같아지면, 오래된 대화 이벤트를 자동으로 컨텍스트에서 밀어내고(Evict), 후술할 Recall Storage로 안전하게 퇴피시킨다. 이를 통해 컨텍스트의 파탄을 방지하면서, 항상 최신 상호작용을 LLM의 「주기억」에 유지한다.

• Function Executor (함수 실행기)

• LLM 스스로가 「지금 기억의 입출력이나 조작이 필요하다」라고 판단했을 때 발행하는 커맨드(Tool Call)를 감지하여, 실제로 시스템 측에서 처리를 실행한다.

• OS의 「시스템 콜 (System Call)」에 해당한다. LLM은 단순히 답변을 생성할 뿐만 아니라, 「edit_core_memory (기억 덮어쓰기)」나 「archival_memory_search (검색)」와 같은 함수를 자율적으로 호출한다. Function Executor가 이를 중개 및 실행하며, 그 결과를 다시 LLM의 컨텍스트 (Context)로 피드백한다.

• Archival Storage (아카이브 스토리지)

• 대규모 문서나 외부 지식 베이스 등, 읽기 전용 (Read-only)의 방대한 텍스트 데이터를 영구적으로 저장해 두는 외부 디스크.

• LLM이 Function Executor를 통해 「벡터 검색 (Vector Search)」 등의 쿼리를 던지는 대상이 되는 영역이다. 수만 행에 달하는 취급 설명서나 장대한 논문 등은 이곳에 배치되며, LLM의 요구에 따라 필요한 부분만 핀포인트로 컨텍스트로 로드된다.

• Recall Storage (리콜 스토리지)

• 과거에 Queue Manager를 통과한 모든 대화 이력이나 이벤트 로그를 시계열로 일원 관리 및 저장해 두는 외부 디스크.

• LLM이 「아까 말했던 그 건 말인데...」라며 과거의 문맥을 필요로 할 때, Function Executor를 통해 키워드나 시간 지정으로 검색을 수행하는 대상이 된다. 컨텍스트 (주기억)에서 밀려난 과거의 기억을 언제든 다시 불러올 수 있도록 하는, OS의 「스왑 공간 (Swap Space)」으로서의 역할을 가진다.

LLM의 컨텍스트 윈도우 (Context Window)가 수십만에서 200만 토큰으로 극적으로 거대해짐에 따라, 개발자는 RAG로 검색한 대량의 문서나 장대한 대화 이력, 코드베이스 전체를 프롬프트에 그대로 「너무 많이 포함시키는」 것이 가능해졌으나,

이로 인해 「입력 비용의 폭발」과, 거대한 프롬프트를 매번 처음부터 다시 계산함으로써 발생하는 「레이턴시 (Latency, TTFT)의 악화」라는 새로운 병목 현상이 발생했다.

이 「장대 컨텍스트의 편의성」과 「비용·속도」 사이의 트레이드오프 (Trade-off)를 해소하고, 거대한 컨텍스트 창의 잠재력을 활용하기 위해 Google, OpenAI, Anthropic 등을 필두로 도입된 것이 프롬프트 캐싱 (Prompt Caching)이다.

각 프로바이더 (Provider)는 장대 컨텍스트 처리라는 공통의 과제에 대해, 개발자의 구현 스타일과 유즈케이스 (Use Case)에 따른 서로 다른 접근 방식을 제시하고 있다789.

• 200만 토큰이라는 업계 최대급의 컨텍스트 윈도우 (Context Window)를 상정한 설계

• 대량의 영상·음성·PDF, 혹은 대규모 코드베이스를 API를 통해 사전에 명시적 (Explicit)으로 캐시 객체화하고, 이를 여러 요청 간에 견고하게 고정·재사용함으로써 입력 비용을 절감하는 메커니즘을 제공

• 코드 변경이 전혀 필요 없는 「완전 자동 판정 (인메모리형)」 채택

• 1,024 토큰 이상의 프롬프트에 대해, 맨 앞부분부터 가장 길게 일치하는 접두사 (Prefix)를 128 토큰 단위로 자동 감지하여, 인프라 측에서 투명하게 캐시를 히트 (Hit)시키고 자동으로 50%의 비용 할인을 적용

• 개발자가 명시적으로 브레이크포인트 (Breakpoint)를 지정하거나, 대화의 진행에 맞춰 자동으로 추종하게 하는 하이브리드 제어 모델 제공

• RAG의 문맥 탈락을 방지하는 「Contextual Retrieval」처럼, 각 청크 (Chunk)에 설명적 문맥을 부여하는 전처리 과정에서 베이스가 되는 수만~수십만 토큰의 부모 문서를 캐시에 고정하여 계산을 효율화하는 접근 방식을 제창하고 있으며, 비용을 최대 90%, 레이턴시를 2배 이상 개선

LLM의 처리 능력이 확대되고 멀티 턴 (Multi-turn) 대화나 지식 집약형의 복잡한 태스크에 대한 요구가 높아지는 가운데, 최적화되지 않은 장문 컨텍스트에서는 정보가 중간에 묻혔을 때 모델의 정밀도가 최대 20% 저하되는 문제가 입증되었다. 이는 단순한 입력문 조절만으로는 장대한 대화 이력이나 외부 데이터의 통합에 대응할 수 없으며, 시스템 운영 비용의 폭발이나 레이턴시 악화, 사실 오인 (Hallucination)을 방지할 수 없다는 인프라 및 실무상의 한계에 직면했음을 의미한다. 이에 따라 컨텍스트 엔지니어링 (Context Engineering)이 다음과 같이 제안되었다10.

• 정의

• 프롬프트 엔지니어링 (Prompt Engineering)과 같은 임시방편적인 입력 조정 수준을 넘어, LLM이 액세스하는 정보 환경 전체를 포괄적이고 프로액티브 (Proactive)하게 관리 및 최적화하는 시스템 설계 프레임워크

• 핵심 구성 요소 (Key components)

• 입력의 기점이 되는 프롬프트 (Prompts)

• 일관성을 유지하기 위한 대화 기록 (Conversational History)

• 외부 리소스 (External Resources, 문서나 DB 기인 데이터. RAG를 통하는 경우가 있음)

• API나 계산기 등의 도구 통합 (Tool Integration)

• 모델의 토큰 제한에 따른 컨텍스트 윈도우 최적화 (Context Windows Optimization)

• 프롬프트 엔지니어링 (Prompt Engineering)과의 차이

• 프롬프트 엔지니어링이 특정 응답을 이끌어내기 위해 "최근의 입력문을 시행착오(Hack)적으로 디자인하는" 한정적인 접근 방식인 반면, 컨텍스트 엔지니어링은 외부 데이터나 도구, 메모리 상한까지 포함하여 "시스템 전체를 구조적으로 설계하는" 접근 방식

• 규모의 유연성과 실무에서의 재현성 (스케일러빌리티와 적응성) 측면에서 결정적인 차이

Claude의 개발사인 Anthropic이 공개한 기술 블로그 "Effective context engineering for AI agents"는 프롬프트 엔지니어링 시대에서 "컨텍스트 엔지니어링"으로의 전환을 시사했다.

프롬프트를 작성하는 개별적인 작업과 대조적으로, 컨텍스트 엔지니어링은 반복적(Iterative)이며 모델에 무엇을 전달할지 결정할 때마다 큐레이션 단계가 발생한다.11

자율형 AI 에이전트를 루프(Loop) 처리로 동작시킬 때, 최대의 문제가 되는 것이 "컨텍스트의 비대화"와 그에 따른 모델의 미궁 현상이다. Anthropic은 이 현상을 "Context Rot (문맥의 부패)"라고 명명했다. 컨텍스트 윈도우가 아무리 확대되더라도, 토큰량이 늘어날수록 모델의 주의력(Attention)이 분산되어 정보의 정확한 회상이나 장거리 추론의 정밀도가 저하된다 (이른바 Needle-in-a-haystack 현상의 악화).

이러한 "유한한 주의력 예산 (Attention budget)"의 제약 하에서, 에이전트를 24시간 혹은 수 시간에 걸친 장기 태스크 (Long-horizon tasks)에서 안정적으로 가동하기 위해, 시스템 측에서 백그라운드로서 철저히 수행해야 할 구체적인 컨텍스트 관리 기법이 명문화되어 있다.

• Compaction (문맥 압축)

• 메커니즘: 메시지 기록이 컨텍스트 윈도우의 한계에 도달했을 때, 전체 기록을 한 번 LLM 자신에게 입력하여 중요한 의사결정이나 미해결 버그, 구현 상세와 같은 "고신호 정보 (High-signal information)"만을 고밀도로 요약 및 추출한다.

• 제어 기법: 추출이 완료된 시점에서, 중복되는 도구의 생출력(Raw output)이나 과거의 대화 내용(생 로그)을 컨텍스트에서 완전히 폐기하고, 생성된 요약과 최근의 몇 개 메시지만으로 새로운 컨텍스트 윈도우를 깨끗하게 재구성(Resession)한다.

• Tool-result clearing (도구 결과 삭제)

• 메커니즘: 에이전트가 실행한 도구(코드 실행, 데이터베이스 쿼리 등)가 반환한 수만 토큰에 달하는 "거대한 생 응답 (Raw response)"을 처리하기 위한 가장 경량화되고 안전한 컴팩션 기법이다.

• 제어 기법: 도구 실행 직후의 턴에서 LLM이 생출력을 읽고 필요한 분석을 마친 단계에서, 시스템 측이 메시지 기록을 스캔하여 해당 거대한 미가공 데이터를 컨텍스트에서 말소한다. "왜 에이전트가 과거의 생출력을 몇 번이고 다시 확인할 필요가 있는가?"라는 사상에 기반하여, 생 로그를 몇 글자의 플레이스홀더("도구 실행 성공" 등의 최소한의 식별자)로 대체함으로써 컨텍스트 오염을 미연에 방지한다.

• Structured note-taking (구조화된 노트 테이킹 / 에이전트 메모리)

• 메커니즘: 컨텍스트 윈도우 외부에 독립적인 "외부 메모리 파일 (NOTES.md나 태스크 리스트 등)"을 시스템 측에서 영속화(Persistence)해 두는 기법.

• 제어 기법: 에이전트는 태스크 진행 상황이나 현재 위치, 획득한 변수의 상태 등을 이 외부 파일에 정기적으로 기록한다. 컨텍스트의 강제 리셋이나 컴팩션이 실행된 후에도, 에이전트는 자신이 남긴 노트만을 다시 읽음으로써 수천 단계에 이르는 장기 태스크를 미궁에 빠지지 않고 심리스(Seamless)하게 지속할 수 있다.

• Sub-agent architectures (서브 에이전트 구조에 의한 컨텍스트 격리)

• 메커니즘: 하나의 메인 에이전트가 모든 탐색 로그를 떠안는 것이 아니라, 특정 좁은 태스크에 특화된 개별 서브 에이전트를 병렬로 실행하는 아키텍처.

• 제어 기법: 서브 에이전트 측에서 수만수십만 토큰을 소비하며 지저분한 데이터 탐색이나 기술적 검증을 수행하고, 메인 에이전트에는 그 결과를 1,0002,000 토큰 정도로 「증류·농축된 요약(Summary)」만을 반환한다. 이를 통해 상세한 탐색 프로세스에 수반되는 방대한 쓰레기 토큰(컨텍스트 오염)을 서브 에이전트 측에 완전히 격리하고, 총괄 측의 깨끗한 문맥 환경을 유지한다.

컨텍스트 엔지니어링(Context Engineering)의 움직임은 가속화되고 있으며, 「수동적인 궁리」에서 「시스템에 의한 자동 제어·강화학습 (RL)에 의한 최적화」로 극적인 진화를 거듭하고 있다.

「에이전트를 실행하는 거대 LLM」과는 별개로, 「문맥을 청소·관리하기 위한 전용 시스템이나 별도의 모델을 배치한다」는 분리·공생형 접근 방식이 주류가 되고 있다.

프롬프트 엔지니어링(Prompt Engineering)은 「태스크를 모델에게 어떻게 설명할 것인가(지시나 출력 형식 등)」에 초점을 맞추어 왔으나, 이는 많은 경우 일회성 인시던트(임시 결과물)로서 처리되어 리포지토리에 남지 않는다는 과제가 있다12.

이와 대조적으로, 컨텍스트 엔지니어링은 「모델에게 태스크 관련 정보를 어떻게 구조화하여 제공할 것인가(규약, 구성, 코드 단편 등)」에 초점이 맞춰져 있다. AI 에이전트의 자율성이 높아짐에 따라, 개발 현장에서는 컨텍스트를 「코드와 마찬가지로 버전 관리·구조화하여 영속화한다」는 실무 구현으로 이행하고 있다. 이 접근 방식을 통해 개발 팀 전체가 일관된 AI의 동작을 보장하는 것이 가능해진다.

위와 같은 흐름에 따라, 아래와 같이 AI 에이전트에게 프로젝트의 문맥이나 규칙을 자율적으로 읽히기 위한 전용 머신 리더블(Machine-readable) 파일이 배치되기 시작했다.

CLAUDE.md
: Anthropic (Claude Code의 기본 탐색 파일) -
copilot-instructions.md
: GitHub Copilot -
AGENTS.md
: 도구에 의존하지 않는 오픈 표준 규약 (Agentic AI Foundation 프로젝트)

12의 조사에서, 특히 오픈 공통 규격인 AGENTS.md의 섹션 구조를 분석한 결과, 실무자가 AI에게 읽히고 있는 기술 카테고리의 우선순위는 다음과 같았다.

• CONVENTIONS (코딩 규약·베스트 프랙티스): AI가 가장 준수해야 할, 코드의 일관성을 유지하기 위한 규칙.
• CONTRIBUTION GUIDELINES (기여 규칙): 브랜치 전략이나 CI (지속적 통합) 요구 사항, 풀 리퀘스트(Pull Request) 작성 절차.
• ARCHITECTURE / STRUCTURE (아키텍처·프로젝트 구조): 디렉토리 구성, 모듈 간의 관계 설명.
• BUILD COMMANDS & TEST EXECUTION (빌드·테스트 실행 명령): 로컬 환경이나 CI 환경에서 프로젝트를 구동하기 위한 구체적인 명령 리스트.

현대의 소프트웨어 개발자는 「인간을 위한 문서(README 등)」뿐만 아니라, 「기계를 위한 문서」도 설계하고 유지하는 시대에 돌입했다고 할 수 있다.

기존의 프롬프트 최적화 기법이 안고 있던, 지시가 너무 일반적이고 짧아지는 「간결성에 대한 편향 (Brevity Bias)」이나, 반복적인 재작성으로 인해 상세한 지식이 소실되는 「컨텍스트 붕괴 (Context Collapse)」라는 두 가지 한계를 해소하기 위해,

컨텍스트(시스템 프롬프트나 메모리 등)를 자기 진화시키는 새로운 컨텍스트 최적화 프레임워크인 ACE (Agentic Context Engineering)가 제안되었다13.

주요 구성 요소는 세 가지 전문 에이전트이다.

• Generator

• 주어진 컨텍스트(플레이북)를 참조하면서, 태스크를 실행하기 위한 추론 단계나 코드(실행 궤적)를 생성

• Reflector

• Generator의 실행 궤적(성패, API 이용 로그, 에러 피드백 등)을 정밀 조사·비판하여, 성공 요인이나 구체적인 실패 원인으로부터 「구체적인 교훈이나 도메인 지식 (통찰)」을 추출

• Curator

• Reflector가 추출한 교훈을, 구조화된 컴팩트한 「델타 (차분) 컨텍스트 항목」으로 합성

이력을 그대로 축적하는 방식은 이력의 증가에 따라 컨텍스트가 급격히 팽창하여, 주의 희석 (Attention Dilution)이나 추론의 저하를 유발한다.

그리고 수동적인 압축·요약(Compression/Summarization)을 수행하는 방식은 컨텍스트 길이를 억제하는 데는 유효하지만, 정적인 결과물로서 처리되기 때문에 초기 오류나 오래된 가정, 부적절한 강조 사항이 요약에 계속 남아 있어 나중에 수정하기가 어려워진다.

이러한 현상으로 인한 컨텍스트 부패 (Context Rot)를 방지하기 위해, 장기간의 탐색이나 심층 조사 (Deep Search)를 수행하는 LLM 에이전트를 위한 능동적·리플렉션 구동형 (Reflection-driven) 컨텍스트 관리 프레임워크로서 ARC (Active and Reflection-driven Context)가 제안되었다14.

ARC는 다음과 같은 2부 구성의 에이전트 아키텍처를 채택하고 있다.

• Actor
• Context Manager

현재 상황에서도 이미 나타나고 있는 컨텍스트 엔지니어링(CE) 사례들이 몇 가지 존재한다.

LLM에게 컨텍스트의 「유지·삭제·요약」 판단을 맡기면, 태스크의 단계가 진행됨에 따라 본래 도메인 특화적으로 유지해야 할 미세한 제약 사항이나 전제 조건(사용자의 세밀한 뉘앙스나 코딩 규약 등)이 「불필요한 노이즈」로 오판되어, 추상화의 파도에 휩쓸려 깎여 나가게 된다.

최적화 (동적 압축)를 수행한 결과, 1만 토큰 이상의 컨텍스트가 불과 100토큰 남짓으로 과도하게 압축되어 태스크의 정답률이 베이스라인 이하로 급락하는 현상이 확인되었다13.

또한, LLM이 원래의 로우 데이터 (Raw data)를 직접 분석하기보다, CE에 의해 생성된 「친절하게 정리된 요약층」에 과도하게 끌려가 (over index), 모델이 깊은 추론을 포기하고 요약층의 뉘앙스에 휘둘리는 얕은 오인을 일으키는 현상도 문제로 지적되고 있다15.

범용 LLM은 주로 1차원 텍스트 스트림 (one-dimensional text streams) 상에서 동작한다는 성질 그 자체가, 다차원적인 구조 메타데이터와 충돌(Conflict)을 일으킨다는 문제도 지적되고 있다16.

시스템 아키텍처, 복잡한 소스 코드의 의존성 그래프(Dependency graph), 혹은 2차원 스프레드시트나 문서 레이아웃 등은 본질적으로 「다차원 네트워크/그래프 구조」를 가지고 있다. CE 측에서 아무리 「프롬프트 순서를 변경하기」, 「섹션 구분 명시하기」, 「XML 스타일의 메타 태그로 감싸기」와 같은 선형적인 정리·엔지니어링을 수행하더라도, LLM의 입력으로 변환하는 단계에서 「1차원 문자열」로 플래트화 (Flatten/Serialize)할 수밖에 없다. 이 직렬화 (Serialization) 과정에서 그래프의 토폴로지 (Topology, 공간적 배치나 다방향 연결 관계)가 반드시 파괴되거나 현저히 희석되기 때문에, 모델은 복잡한 구조적 토폴로지를 정확하게 복원하거나 추론할 수 없게 된다.

Understanding the Impact of Increasing LLM Context Windows ↩ ↩

2 -
LLMLingua: Compressing Prompts for Accelerated Inference of Large Language Models ↩ ↩

2 -
Gemini 1.5 Pro 2M context window, code execution capabilities, and Gemma 2 are available today ↩

Context Engineering: Enhancing Large Language Model Performance Through Comprehensive Contextual Management ↩

Context Engineering: Enhancing Large Language Model Performance Through Comprehensive Contextual Management ↩

Context Engineering for AI Agents in Open-Source Software ↩ ↩

2 -
Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models ↩ ↩

2↩3 -
ARC: Active and Reflection-driven Context Management for Long-Horizon Information Seeking Agents ↩ ↩

2 - Evaluating AGENTS.md: 저장소 수준의 컨텍스트 파일이 코딩 에이전트에게 도움이 될까요?

• BabelDOC: 중간 표현(Intermediate Representation)을 통한 레이아웃 보존 PDF 번역 개선