컨텍스트 엔지니어링이란 무엇인가 — 그리고 왜 단일 에이전트보다 오래 유지되는 메모리 레이어가 필요한가 (2026)

컨텍스트 엔지니어링은 언어 모델이 작업의 각 단계에서 필요한 정보(지침, 도구, 예시, 검색된 문서, 대화 기록 및 메모리)만 전달받고 불필요한 정보는 배제하도록 결정하는 실무입니다. 프롬프트 엔지니어링은 그 일부에 불과합니다. 작업이 여러 세션에 걸쳐 진행될 때 컨텍스트가 제공되는 원천이 바로 메모리입니다.

Anthropic의 엔지니어링 팀은 2025년 9월 포스트에서 가장 명확한 정의 중 하나를 내렸습니다. "Anthropic에서는 컨텍스트 엔지니어링을 프롬프트 엔지니어링의 자연스러운 진화로 봅니다." 그들의 설명에 따르면, 프롬프트 엔지니어링은 지침을 작성하고 구성하는 일입니다. 반면 컨텍스트 엔지니어링은 "LLM 추론 과정에서 프롬프트 외에 입력될 수 있는 다른 모든 정보를 포함하여, 최적의 토큰(정보) 세트를 선별하고 유지하기 위한 일련의 전략"을 의미합니다.

이러한 변화는 에이전트가 루프(loop) 형태로 작동하기 때문에 발생했습니다. 같은 포스트에서는 "루프 내에서 실행되는 에이전트는 다음 추론 단계에 관련될 수 있는 데이터를 점점 더 많이 생성하며, 이 정보는 주기적으로 정제되어야 한다"고 설명합니다. 이로 인해 작업이 지속적으로 이루어집니다. "컨텍스트 엔지니어링은 끊임없이 진화하는 잠재적 정보의 우주 속에서, 제한된 컨텍스트 창에 들어갈 내용을 선별하는 예술이자 과학입니다."

따라서 두 개념의 차이는 범위와 타이밍에 있습니다. 프롬프트 엔지니어링은 대화가 시작되기 전에 한 번 수행하는 작업입니다. 반면 컨텍스트 엔지니어링은 에이전트가 다음에 무엇을 참조할지 결정할 때마다 매번 발생합니다.

Anthropic은 에이전트가 작업하는 구성 요소를 다음과 같이 나열합니다. "시스템 지침, 도구, Model Context Protocol (MCP), 외부 데이터, 메시지 기록 등." 실제 환경에서 대부분의 에이전트는 다섯 가지 종류의 컨텍스트를 활용합니다.

지침(Instructions). 시스템 프롬프트와 코딩 에이전트가 세션 시작 시 로드하는 CLAUDE.md 또는 AGENTS.md와 같은 파일들입니다.

도구(Tools). 에이전트가 수행할 수 있는 작업의 정의로, 이 자체도 공간을 차지합니다. Anthropic은 "우리가 흔히 보는 가장 일반적인 실패 패턴 중 하나는 너무 많은 기능을 포함하거나 어떤 도구를 사용해야 할지 모호한 결정 지점을 만드는 비대해진 도구 세트"라고 경고합니다.

예시(Examples). 예외적인 케이스를 망라한 목록보다는 표준적인 예시의 소규모 세트가 좋습니다.

검색된 정보(Retrieved information). 필요할 때 가져오는 문서, 검색 결과 및 데이터입니다.

기록 및 메모리(History and memory). 이번 세션의 이전 단계에서 일어난 일과 이전 세션에서 학습한 내용입니다.

훌륭한 컨텍스트 엔지니어링은 주로 이들 사이의 균형을 맞추는 일입니다. Anthropic의 핵심 원칙은 "좋은 컨텍스트 엔지니어링이란 원하는 결과를 얻을 가능성을 극대화하는 가장 작고 신호가 강한 토큰 세트를 찾는 것"입니다.

컨텍스트 창이 커지면 이 모든 작업이 불필요해질 것이라고 생각하기 쉽습니다. 하지만 Anthropic은 그렇지 않다고 주장하며, 이를 컨텍스트 부패(context rot)라고 부릅니다. "컨텍스트 창의 토큰 수가 증가함에 따라, 해당 컨텍스트에서 정보를 정확하게 회상하는 모델의 능력이 저하됩니다." 그들의 결론은 "따라서 컨텍스트는 한계 효용이 체감하는 유한한 자원으로 취급되어야 한다"는 것입니다.

Claude 개발자 플랫폼의 컨텍스트 편집 관련 문서에서도 제품 관점에서 동일한 점을 지적합니다. "컨텍스트는 수익률이 체감하는 유한한 자원이며, 무관한 콘텐츠는 모델의 집중도를 떨어뜨립니다." 또한 Anthropic의 엔지니어링 포스트는 "예측 가능한 미래에는 모든 크기의 컨텍스트 창이 컨텍스트 오염 및 정보 관련성 문제의 영향을 받게 될 것"이라고 덧붙입니다.

Alibaba 역시 기업 관점에서 동일한 결론에 도달했습니다. Yunqi 기조연설에서는 회사의 데이터를 에이전트에 무작정 밀어 넣는다고 해서 작동하는 것이 아니며, 창을 과부하시키면 에이전트가 작업을 수행하는 데 필요한 공간을 낭비하게 되므로 데이터를 먼저 레이어로 압축해야 한다고 주장했습니다.

이것이 바로 짧은 프롬프트만으로는 비용이나 품질 문제를 해결할 수 없는 이유이기도 하며, 이 점은 짧은 프롬프트가 충분하지 않은 이유에서 자세히 다루었습니다. 핵심은 얼마나 적게 보내느냐가 아니라, 보내는 내용이 올바른 내용인가 하는 점입니다.

장기 작업의 경우, Anthropic은 세 가지 접근 방식을 설명합니다. 바로 "압축(compaction), 구조화된 노트 작성(structured note-taking), 그리고 멀티 에이전트 아키텍처(multi-agent architectures)"입니다.

압축(Compaction). "압축은 컨텍스트 창 한계에 도달한 대화를 가져와 그 내용을 요약하고, 해당 요약본으로 새로운 컨텍스트 창을 다시 시작하는 실무입니다." 이는 작업을 계속 진행할 수 있게 해주지만, 알려진 위험이 있습니다. "지나치게 공격적인 압축은 나중에야 그 중요성이 드러나는 미묘하지만 중요한 컨텍스트의 손실을 초래할 수 있습니다."

구조화된 노트 작성(Structured note-taking). "구조화된 노트 작성, 즉 에이전트 메모리(agentic memory)는 에이전트가 컨텍스트 창 외부의 메모리에 영구 보존되는 노트를 정기적으로 작성하는 기술입니다. 이 노트들은 나중에 다시 컨텍스트 창으로 불러옵니다." 할 일 목록이나 NOTES.md 파일이 가장 단순한 형태입니다.

하위 에이전트(Sub-agents). "전문화된 하위 에이전트는 깨끗한 컨텍스트 창을 가지고 집중적인 작업을 처리"할 수 있으며, 메인 에이전트에게는 압축된 결과만 반환합니다.

이 세 가지 모두를 관통하는 검색(retrieval) 패턴도 있습니다. 에이전트는 처음부터 모든 것을 로드하는 대신 "가벼운 식별자(파일 경로, 저장된 쿼리, 웹 링크 등)를 유지하고, 이러한 참조를 사용하여 런타임에 도구를 통해 컨텍스트로 데이터를 동적으로 로드"합니다. Claude Code는 Anthropic 자체의 하이브리드 예시입니다. "CLAUDE.md 파일은 처음에 컨텍스트에 그대로 주입되는 반면, glob 및 grep과 같은 기본 명령어를 통해 환경을 탐색하고 적시에 파일을 검색할 수 있습니다."

검색은 메모리와 동일하지 않지만, 두 개념은 종종 혼동됩니다. AI 메모리 대 RAG에서 그 차이를 자세히 다룹니다.

2026년 9월, 컨텍스트 엔지니어링은 엔지니어링 블로그를 넘어 기업 전략으로 자리 잡았습니다. Alibaba Cloud는 자사의 에이전트 클라우드가 "모델, 하네스(harness), 컨텍스트라는 세 가지 핵심 시나리오를 중심으로 구축되었다"고 설명하며, "AI 에이전트에게 실시간 컨텍스트와 장기 메모리를 제공하는" Agent Context 서비스를 출시했습니다. Qianwen Office는 기업 전체로 범위를 넓혔을 때 AI 에이전트를 위한 컨텍스트 레이어가 어떤 모습인지를 보여주는 Enterprise Context라는 동반 제품을 출시했습니다.

Qianwen Office의 기조연설은 기업형 문제의 버전을 세 가지로 구성했습니다. 비즈니스를 모르는 에이전트, 개인에게만 머물러 있는 유용한 노하우, 그리고 데이터 보안에 대한 주저함입니다. 제안된 해답은 회사 데이터를 연결하고, 이해하며, 재사용 가능하게 만드는 것이었으며, 그 중심에는 압축이 있었습니다.

가장 흥미로운 대목은 이후 진행된 인터뷰에서 나왔습니다. Qianwen Office의 부사장인 Shu Junliang은 컨텍스트가 "최종적으로 사용하는 에이전트와 분리(decoupled)되어 있다"며, 기업의 컨텍스트는 "반드시 해당 기업의 소유여야 한다"고 말했습니다. 그는 또한 이 인프라가 "아직 데이터베이스처럼 표준화되지 않았다"고 덧붙였습니다.

이것이 바로 모든 컨텍스트 엔지니어가 결국 마주하게 되는 원칙의 기업형 형태입니다. 컨텍스트는 단계별로 조립되지만, 그것이 조립되는 기반이 되는 지식에는 소유자가 있으며, 그 소유자는 에이전트인 경우가 거의 없습니다.

컨텍스트 엔지니어링은 창에 무엇이 들어갈지 결정합니다. 메모리는 작업이 여러 세션에 걸쳐 진행될 때 그 내용의 상당 부분이 흘러나오는 원천입니다. 일부 필자들은 이제 이 후반부를 메모리 엔지니어링(memory engineering)이라고 부릅니다. 컨텍스트 엔지니어링은 추론 시점에 작동하고, 메모리는 시간에 걸쳐 작동합니다.

문제는 오늘날 대부분의 메모리 메커니즘이 하나의 도구나 하나의 장소에 종속되어 있다는 점입니다.

Claude Code의 자동 메모리는 명확한 경계를 가진 합리적인 설계의 좋은 예시입니다. "자동 메모리는 머신 로컬(machine-local) 방식"이며, "파일은 머신이나 클라우드 환경 간에 공유되지 않습니다." 개발자를 위한 Anthropic의 메모리 도구는 사용자가 직접 제어할 수 있도록 한 걸음 더 나아갑니다. "메모리 도구는 클라이언트 측에서 작동합니다. Claude가 파일 작업을 요청하면 애플리케이션이 이를 실행합니다. 사용자는 자체 인프라를 통해 데이터가 저장되는 위치와 방식을 제어합니다." 같은 페이지에서 이 경계는 명확하게 명시되어 있습니다. "메모리는 전적으로 애플리케이션 내에 존재합니다." Anthropic의 관리형 저장소 접근 방식은 Claude 에이전트 메모리 저장소 설명에서 다룹니다.

소비자용 도구들 역시 나름의 선을 긋고 있습니다. 예를 들어 ChatGPT에서 공유 프로젝트는 "프로젝트 외부의 개별 멤버의 컨텍스트, 맞춤형 지침 또는 메모리에 액세스할 수 없습니다."

이 중 어느 것도 결함은 아닙니다. 각 경계는 프라이버시, 범위, 예측 가능성 등 무언가를 보호합니다. 하지만 이로 인해 에이전트가 필요로 하는 지식이 사용하는 도구의 수만큼 여러 곳에 흩어지게 된다는 것을 의미합니다. 세 개의 에이전트를 실행하는 팀은 각 제품의 규칙에 따라 형성된 세 개의 부분적인 메모리를 갖게 됩니다.

이것이 바로 Alibaba 인터뷰에서 지적한 공백입니다. 컨텍스트가 에이전트와 분리되어야 한다면, 컨텍스트가 끌어오는 메모리 역시 분리되어야 합니다. 어떤 종류의 메모리가 중요한지는 그 자체로 별도의 주제이며, AI 메모리의 6가지 유형에 정리되어 있습니다. 여기서 실무적인 핵심은 그것들이 어디에 존재하는가입니다.

시작하기 위해 프레임워크가 필요하지는 않습니다. 세 가지 단계만으로도 대부분의 가치를 얻을 수 있습니다.

1단계: 상시 컨텍스트와 작업 컨텍스트 분리하기

모든 세션이 시작할 때 포함해야 할 사항을 나열하세요. 작업 대상이 누구인지, 컨벤션, 확정된 결정 사항, 모델이 추측할 수 없는 정의 등이 이에 해당합니다. 이것이 상시 컨텍스트(standing context)입니다. 그런 다음 작업이 진행되면서 끌어오는 파일, 검색 결과, 최근 기록 등을 나열하세요. 이것이 작업 컨텍스트(working context)입니다.

상시 컨텍스트는 지침과 메모리에 속합니다. 작업 컨텍스트는 적시에 검색되어야 합니다. 이 둘을 혼용하는 것은 에이전트가 핵심 사실을 놓치거나 무관한 사실에 파묻히는 가장 흔한 이유입니다.

2단계: 상시 컨텍스트를 레이어로 압축하기

먼저 짧은 인덱스를 작성한 다음, 프로젝트, 결정 또는 프로세스당 하나의 압축된 항목을 작성하고, 그 뒤에 소스 문서를 배치하세요. 새로운 결정이 이전 결정을 명확히 대체할 수 있도록 항목에 날짜를 기재하세요. 예시는 망라하기보다 표준적인 형태로 유지하세요.

모든 것을 저장하려는 충동을 억제하세요. 더 많은 메모리가 에이전트에게 실제로 도움이 되는지 여부는 여전히 논쟁 중인 질문이며, AI 에이전트에게 얼마나 많은 메모리를 주어야 하는가에서 검토하고 있습니다.

3단계: 모든 에이전트가 접근할 수 있는 곳에 상시 컨텍스트 저장하기

이 단계는 대부분의 설정에서 건너뛰는 단계입니다. 상시 컨텍스트가 하나의 도구 메모리에만 존재한다면, 다른 모든 에이전트는 그것 없이 시작하게 됩니다. 단일 제품 외부의 레이어에 이를 유지하고, 두 개의 서로 다른 에이전트에게 작업에 대해 동일한 질문을 던져 테스트해 보세요. 한 에이전트만 답을 알고 있다면, 컨텍스트가 해당 도구 내에 갇혀 있는 것입니다.

3단계는 에이전트가 아닌 사용자 본인에게 속한 메모리 레이어를 설명합니다. MemoryLake는 바로 이 작업을 위해 구축되었습니다. 단일 도구 외부에 존재하는 AI 에이전트용 장기 메모리로, 한 번 엔지니어링한 상시 컨텍스트를 사용하는 모든 어시스턴트가 사용할 수 있도록 합니다.

사용자는 자신의 언어로 직접 항목을 작성합니다. Claude Code의 메모리 디렉터리, 에이전트 자체 저장소 또는 벤더의 저장소에서 데이터를 읽거나 쓰거나 삭제하지 않습니다.

1단계: API 키 생성하기

로그인한 후 대시보드에서 키를 생성합니다. 이 키는 단일 에이전트나 모델과 무관하게 메모리 레이어의 워크스페이스에 귀속됩니다.

2단계: 첫 번째 메모리 업로드하기

1단계의 상시 컨텍스트와 2단계의 레이어드 항목(정의, 확정된 결정, 컨벤션)으로 시작하세요. 항목당 하나의 사실을 날짜와 함께 기록합니다.

3단계: AI 및 에이전트 연결하기

사용 중인 어시스턴트와 에이전트를 연결하세요. 그러면 각 에이전트가 동일한 상시 컨텍스트를 활용할 수 있으며, 이는 설계상 분리 테스트를 통과하게 됩니다.

컨텍스트를 예산으로 취급하세요. 모든 토큰은 모델의 주의를 끌기 위해 경쟁합니다. 제 자리를 차지할 가치가 있는 것만 포함하세요.

도구는 소수로 유지하고 명확히 구분하세요. 중복되는 도구는 에이전트에게 모호한 선택을 유발합니다.

작업 컨텍스트는 적시에 검색하세요. 처음부터 로드하지 말고 작업에 필요할 때 파일과 데이터를 로드하세요.

신중하게 압축하세요. 요약은 작업을 계속 진행하게 해주지만, 나중에 중요해질 수 있는 세부 정보를 누락시킬 수 있습니다.

창 외부에 노트를 작성하세요. 구조화된 노트를 사용하면 에이전트가 중단된 부분부터 다시 시작할 수 있습니다.

상시 컨텍스트는 특정 도구에 종속되지 않도록 유지하세요. 하나의 제품 내에 존재하는 메모리는 해당 제품에만 도움이 됩니다. 에이전트가 말한 것과 행동한 것의 차이는 AI 에이전트를 위한 일화적 메모리에서 다루고 있으며, 무엇을 저장할지 결정할 때 염두에 둘 가치가 있습니다.

컨텍스트 엔지니어링은 프롬프트 엔지니어링의 자연스러운 후계자입니다. 크지만 유한한 창 내에서 에이전트가 각 단계에서 무엇을 볼지 결정하는 지속적인 작업입니다. Anthropic의 원칙이 이를 요약해 줍니다. "원하는 결과를 얻을 가능성을 극대화하는 가장 작고 신호가 강한 토큰 세트"를 찾는 것입니다.

압축, 구조화된 노트, 하위 에이전트 및 적시 검색과 같은 기술은 잘 알려져 있습니다. 아직 덜 정립된 부분은 이 모든 것의 이면에 있는 지식이 어디에 존재해야 하는가입니다. Alibaba의 "Context is All You Need"라는 문구는 컨텍스트 인프라가 아직 표준화되지 않았다는 인정과 함께 나옵니다.

표준화되기 전까지 실무적인 규칙은 간단합니다. 단계별로 컨텍스트를 엔지니어링하되, 그것이 끌어오는 상시 지식은 사용자가 소유하고 사용하는 모든 에이전트가 접근할 수 있는 한 곳에 보관하는 것입니다. 이 레이어에 대한 더 넓은 소개는 AI 메모리란 무엇인가를 참조하세요.