컨텍스트 엔지니어링

쉽게 말하면, 컨텍스트 엔지니어링은 AI 모델이 일을 하기 직전에 눈앞에 놓이는 정보 묶음을 골라 짜 맞추는 실무다. 질문 한 줄을 잘 쓰는 데서 그치지 않고, 시스템 지침, 검색한 문서, 도구 결과, 대화 기록, 기억 가운데 무엇을 얼마나 넣을지 설계한다. 프롬프트 엔지니어링이 '무엇을 물을까'를 다룬다면, 컨텍스트 엔지니어링은 '모델이 무엇을 보고 일해야 하는가'를 다룬다.

1. 개요

컨텍스트 엔지니어링(Context engineering)은 추론 실행 시점에 대규모 언어 모델이 컨텍스트 창에서 받는 정보 전체를 설계, 구축, 최적화하는 실무다. 모델이 과업을 완수하는 데 정확히 필요한 것을 갖추게 하는 것이 목표다. 흔히 프롬프트 엔지니어링의 더 넓은 후속 개념으로 설명된다. 프롬프트 엔지니어링이 하나의 지시문이나 질의의 문장을 다듬는 데 초점을 둔다면, 컨텍스트 엔지니어링은 모델이 보는 모든 것을 조립, 선택, 압축, 관리하는 시스템 전체를 포괄한다. 여기에는 시스템 프롬프트와 지침, 동적으로 검색한 문서, 도구 정의와 도구 결과, 대화 기록, 메모리, 사용자 프로필, 퓨샷 예시가 포함된다.^2,3,4

이 용어는 2025년 중반에 널리 쓰이게 됐으며, 쇼피파이 CEO 토비 뤼트케(Tobi Lutke)와 AI 연구자 안드레이 카파시(Andrej Karpathy)가 이를 대중화했다. 뤼트케는 컨텍스트 엔지니어링을 LLM이 그 과업을 그럴듯하게 풀 수 있도록 과업에 필요한 컨텍스트를 모두 제공하는 기술로 설명했다. 카파시는 이 용어가 산업 수준의 LLM 응용이 실제로 필요로 하는 것을 더 잘 나타낸다고 보고 지지했다. 그는 다음 단계에 꼭 맞는 정보로 컨텍스트 창을 채우는 섬세한 기술이자 과학이라고 표현했다. 용어가 바뀐 것은 신뢰할 수 있는 AI 응용, 특히 RAG 시스템과 AI 에이전트를 만드는 일이 좋은 프롬프트 한 줄을 쓰는 것보다 훨씬 많은 일을 수반한다는 인식이 넓어졌음을 보여 준다.^2,3

2025년에 이르러 컨텍스트 엔지니어링은 자체 학술 서베이 문헌, 전용 프레임워크, 실서비스용 도구를 갖춘 분야로 인정받게 됐다. Anthropic은 2025년 9월 이 주제에 관한 포괄적인 가이드를 발표했다. Cognition AI의 월든 얀(Walden Yan)은 이를 AI 에이전트를 만드는 엔지니어의 사실상 1순위 업무라고 평했다. LangChain 팀은 2025년 6월 널리 인용된 블로그 글에서 이 용어를 정식화했고, 몇 주 만에 이 표현은 채용 공고, 학회 발표, 대부분의 주요 AI 연구소의 엔지니어링 문서로 퍼졌다.^4,6

이 항목은 컨텍스트 엔지니어링을 일반적인 실무로 다룬다. 에이전트의 맥락을 편집 가능한 자기 개선형 플레이북으로 다루는 특정 자동화 기법은 별도 항목인 에이전틱 컨텍스트 엔지니어링에서 다룬다.

2. 정의와 범위

컨텍스트 엔지니어링은 프롬프트 텍스트만이 아니라 LLM의 컨텍스트 창을 추론 실행 시점에 채우는 모든 것을 큐레이션하는 분야다. 실서비스 AI 응용에서 컨텍스트 창을 채우는 내용은 여러 출처에서 온다. 예를 들어 고객 지원 챗봇은 시스템 프롬프트, 고객 계정 정보, 검색 증강 생성(RAG)으로 찾은 지식 베이스 문서, 고객의 최근 주문 내역, 현재 대화 기록, 내부 시스템 API 호출의 도구 출력을 결합할 수 있다. 이 모든 요소를 관리하고, 무엇을 넣고 뺄지, 정보를 어떤 형식과 순서로 배치할지, 토큰 한도 안에 어떻게 맞출지 정하는 일을 컨텍스트 엔지니어링이 다룬다.⁷

Anthropic은 근본 문제를 제약 아래의 큐레이션으로 본다. 이 회사는 컨텍스트 엔지니어링을 끊임없이 변하는 가능한 정보의 우주에서 한정된 컨텍스트 창에 무엇을 넣을지 큐레이션하는 기술이자 과학이라고 설명한다. 이 분야는 컨텍스트 창을 희소하고 주의가 한정된 자원으로 보며, 어떤 토큰 구성이 원하는 모델 행동을 가장 잘 만들어 낼지 묻는다.⁴

3. 배경

3.1. 프롬프트 엔지니어링에서 컨텍스트 엔지니어링으로

프롬프트 엔지니어링은 2022~2023년경 ChatGPT와 다른 대화형 AI 시스템이 널리 쓰이기 시작한 직후 하나의 분야로 떠올랐다. 초기 프롬프트 엔지니어링은 효과적인 지시문을 쓰는 기법에 초점을 두었다. 구체적인 표현을 고르기, 예시를 주기(퓨샷 프롬프팅), 모델에 역할을 맡기기, 더 나은 출력을 끌어내도록 요청을 구조화하기가 그 예다. 이런 기법은 여전히 가치가 있지만, 실무자들은 곧 프롬프트 문구가 훨씬 큰 퍼즐의 한 조각일 뿐임을 알게 됐다.

차이는 간단히 요약할 수 있다. 프롬프트 엔지니어링은 올바른 말을 고르는 일이다. 컨텍스트 엔지니어링은 올바른 정보를 올바른 때에 전달하는 올바른 시스템을 만드는 일이다.

3.2. 2025년 대중화

'컨텍스트 엔지니어링'이라는 말은 2025년 이전에도 여기저기 쓰였지만, 2025년 6월 AI 담론의 주류로 들어섰다. 2025년 6월 19일 토비 뤼트케는 X(옛 트위터)에 글을 올려, 효과적인 AI 응용을 만드는 데 필요한 핵심 역량을 더 잘 설명한다며 '프롬프트 엔지니어링'보다 '컨텍스트 엔지니어링'이라는 말을 선호한다고 밝혔다. 며칠 뒤인 2025년 6월 25일 안드레이 카파시는 이에 응답해 지지를 표명했다. 그는 사람들이 프롬프트를 짧은 과업 설명과 연결해 떠올리지만, 산업용 응용은 여러 출처에서 가져온 컨텍스트를 신중하게 조립해야 한다고 덧붙였다.^2,3

LangChain 공동창업자 해리슨 체이스(Harrison Chase)는 2025년 6월 23일 「The Rise of Context Engineering」을 발표하며, 컨텍스트 엔지니어링을 LLM이 과업을 그럴듯하게 수행할 수 있도록 적절한 정보와 도구를 적절한 형식으로 제공하는 동적 시스템을 구축하는 일로 정의했다. 개발자 커뮤니티에서 신뢰받는 사이먼 윌리슨(Simon Willison)은 이어 이 용어가 LLM 위에서 효과적인 응용을 만들 때 따르는 복잡성의 상당 부분을 완벽하게 담아낸다고 평가했다. 그는 이 말이 LLM에 필요한 모든 것을 주기 위해 필요한, 흔히 까다로운 시스템의 설계와 구축을 가리킨다고 썼다.^8,9

시점도 중요했다. 2025년 중반 AI 업계는 답만 하는 모델을 넘어, 도구, 메모리, 계획을 써서 여러 단계의 과업을 자율적으로 실행하는 에이전트 워크플로 쪽으로 빠르게 움직이고 있었다. 이런 흐름에서는 과제가 프롬프트 문구를 잘 쓰는 일보다 복잡한 정보 흐름을 조율하는 일에 가까웠기 때문에, '프롬프트 엔지니어링'이라는 틀의 한계가 두드러졌다.¹⁰

학술 정리도 빠르게 뒤따랐다. 「A Survey of Context Engineering for Large Language Models」(arXiv:2507.13334)는 2025년 7월 발표되어 검색, 처리, 관리, 다중 에이전트 통합에 걸친 분류 체계를 제시했다. 후속 논문 「Context Engineering 2.0」(arXiv:2510.26493)은 이 분야의 4단계 진화 모델을 제안했다.⁵

3.3. 주요 인물

2025년 컨텍스트 엔지니어링 담론을 형성한 인물은 여럿이다.

• 쇼피파이 CEO 토비 뤼트케는 프롬프트 엔지니어링을 대체하는 용어로 이 말을 처음 공개 지지한 주요 인물이었다. 2025년 6월 19일 글에서 그는 컨텍스트 엔지니어링을 AI를 다룰 때 가장 효과가 큰 역량이라고 설명했다. 대규모로 AI 응용을 만들 때 실무자가 실제로 하는 일을 이 말이 더 잘 나타낸다고 주장했다.
• 안드레이 카파시는 전 OpenAI 연구원이자 테슬라 AI 디렉터 출신으로, 이 개념을 증폭하고 정의를 다듬었다. 다음 단계에 꼭 맞는 정보로 컨텍스트 창을 채우는 섬세한 기술이자 과학이라는 표현이 이 개념을 가장 많이 인용되는 설명으로 만들었다. 카파시는 또 컨텍스트 엔지니어링이 개별 LLM 호출을 완전한 LLM 앱으로 묶는, 새롭게 두꺼워지는 비자명한 소프트웨어 계층의 작은 한 조각일 뿐이라고 말했다.
• 월든 얀은 Devin 코딩 에이전트를 만든 Cognition AI의 최고제품책임자(CPO)다. 그는 프롬프트 엔지니어링이 LLM 챗봇에 맞게 과업을 쓰는 노력을 가리키는 말이었다며, 컨텍스트 엔지니어링은 그 다음 단계로 이를 동적 시스템 안에서 자동으로 하는 일이라고 설명했다. 얀은 또 컨텍스트 엔지니어링이 Devin에 다중 에이전트 구조를 쓰지 않는 주된 이유라고 주장했다. 여러 에이전트에 걸쳐 컨텍스트를 안정적으로 공유하기가 근본적으로 어렵다는 것이다.
• 해리슨 체이스는 LangChain 공동창업자로서 개발자 커뮤니티에서 가장 실무적인 정의를 내놓았다. 그는 패턴과 예시를 모은 공개 GitHub 저장소로 이를 뒷받침했다.^3,6

4. 프롬프트 엔지니어링과의 차이

두 개념의 경계는 이론에서뿐 아니라 실무에서도 중요하다. 프롬프트 엔지니어링은 주로 텍스트 자체 수준에서 움직인다. 프롬프트 엔지니어는 어떤 문구, 구조, 예시가 모델을 더 잘 답하게 만들지 묻는다. 작업은 대체로 정적이다. 시스템 프롬프트를 쓰고, 시험하고, 다듬고, 배포한다. 프롬프트는 보통 모든 사용자에게 같다.

컨텍스트 엔지니어링은 시스템 수준에서 움직인다. 컨텍스트 엔지니어는 지금 모델이 무엇을 봐야 하며 그것을 어떻게 전달할지 묻는다. 작업은 동적이다. 호출마다 조립되는 컨텍스트가 달라질 수 있는데, 실시간 데이터베이스, 사용자 이력, 도구 출력, 진행 중인 에이전트 상태에서 정보를 가져오기 때문이다. 컨텍스트 엔지니어는 문장이 아니라 파이프라인을 만든다.

다른 말로 하면 프롬프트 엔지니어링은 필요하지만 충분하지 않다. 잘 쓴 시스템 프롬프트는 잘 설계된 컨텍스트의 한 구성 요소일 뿐이다. 컨텍스트 엔지니어는 어떤 검색 파이프라인이 관련 문서를 가져올지, 대화 기록이 너무 길어지면 어떻게 압축할지, 도구 결과를 전부 넣을지 요약할지, 사용자별 정보를 언제 주입할지도 결정한다.

카파시는 사람들이 컨텍스트 엔지니어링을 '프롬프팅'이라 부르며 가볍게 여긴다고 지적했는데, 이는 실무상의 우려를 짚은 것이다. 운영 중인 에이전트가 실패할 때 원인은 시스템 프롬프트의 단어를 잘못 골랐기 때문인 경우가 드물다. 대개 잘못된 정보가 들어 있었거나, 필요한 정보가 빠졌거나, 컨텍스트가 너무 커져 모델이 무엇이 중요한지 놓쳤기 때문이다.

5. 핵심 구성 요소

컨텍스트 엔지니어링은 함께 컨텍스트 창을 채우는 여러 종류의 정보를 관리하는 일을 포함한다.

시스템 프롬프트(또는 시스템 메시지)는 주어진 응용에서 모델의 행동, 페르소나, 제약, 출력 형식을 정한다. 컨텍스트 엔지니어링 틀에서 시스템 프롬프트는 유일한 초점이 아니라 여러 구성 요소 가운데 하나로 다룬다. 보통 모델의 역할을 정하고, 항상 출처를 밝힌다거나 내부 지침을 드러내지 않는다는 식의 기본 규칙을 세우며, 모든 상호작용에 적용되는 정적 지침을 준다.

Anthropic의 엔지니어링 블로그는 시스템 프롬프트를 극도로 명확하고 단순하며 직접적인 언어로 쓰라고 권한다. 적정 고도는 행동을 효과적으로 이끌 만큼 구체적이면서도, 모델에 강력한 판단 기준을 줄 만큼 유연한 수준이라고 한다. 잘 설계된 시스템 프롬프트는 간결하고 초점이 분명하다. 컨텍스트 창이 동적 내용으로 차오르면 긴 시스템 프롬프트는 검색 정보나 대화 기록에 쓸 토큰 예산을 잡아먹는다.⁴

검색 증강 생성(RAG)은 컨텍스트 엔지니어링의 기초 구성 요소다. RAG 시스템은 모델이 학습 중에 익힌 지식, 즉 파라메트릭 지식에만 기대지 않는다. 대신 외부 지식 베이스에서 관련 문서, 구절, 데이터를 찾아 질의 시점에 컨텍스트 창에 넣는다.

컨텍스트 엔지니어링의 관점에서 검색은 설계 결정이다. 주요 고려 사항은 검색 전략(밀집 검색, 희소 검색, 하이브리드 검색 가운데 무엇을 쓸지), 검색할 문서 수, 결과의 순위 매기기와 필터링, 검색 결과를 모델에 맞게 형식화하는 방법이다. 과도한 검색은 토큰을 낭비하고 모델을 혼란스럽게 할 수 있으며, 검색이 부족하면 모델에 결정적인 정보가 빠진다.¹¹

모든 컨텍스트 엔지니어링 시스템이 벡터 데이터베이스 기반 RAG를 쓰는 것은 아니다. Claude Code, Cursor, Devin은 정적 벡터 검색 대신 에이전틱 검색으로 뚜렷하게 수렴했다. Anthropic은 초기 버전의 Claude에 실제로 RAG를 써 봤지만, 결국 에이전틱 검색만 남겼고 그 방식이 모든 방식을 크게 앞섰다고 밝혔다. 이 패턴에서 에이전트는 grep 같은 검색, 파일 트리 확인, 표적 파일 읽기를 써서 필요한 것을 정확히 찾는다. 미리 색인한 임베딩에는 의존하지 않는다.¹²

에이전트 응용에서 모델은 함수 호출을 통해 외부 도구와 API를 부른다. 도구 호출의 결과는 이후 추론의 컨텍스트가 된다. 모델은 날씨 API, 데이터베이스 질의, 코드 해석기, 웹 검색 도구를 부를 수 있으며, 이 모든 호출의 출력이 컨텍스트 창에 쌓인다.

도구 결과는 신중하게 관리해야 한다. 어떤 결과는 크기 때문에(예: 데이터베이스 질의가 수천 행을 돌려줄 수 있다) 요약하거나 잘라야 한다. 다른 결과는 금방 낡으므로(예: 실시간 주가) 새로 고쳐야 할 수 있다. 도구 결과의 순서와 형식은 모델이 그것을 얼마나 잘 쓰는지에 영향을 준다.¹⁰

여러 차례 주고받는 상호작용에서는 대화 기록, 즉 사용자와 모델 사이의 이전 메시지가 컨텍스트 창에서 차지하는 몫이 점점 커진다. 관리하지 않으면 긴 대화가 시스템 프롬프트, 검색 지식, 그 밖의 중요한 맥락을 밀어낼 수 있다.

이를 다루는 기법에는 오래된 메시지를 더 짧은 요약으로 줄이는 대화 요약, 최근 N개 턴만 남기는 슬라이딩 윈도 방식, 현재 주제와 관련된 메시지만 남기는 선택적 보존이 있다. 2025년 실무계의 대체적인 합의는 성능이 눈에 띄게 떨어지기 전, 컨텍스트 사용량이 가용 예산의 70%를 넘으면 대화 압축을 시작하는 것이다.⁷

메모리 시스템은 AI 응용이 세션을 넘어 정보를 유지하게 한다. 단기 메모리는 현재 대화 컨텍스트에 해당하고, 장기 메모리는 별도의 상호작용 사이에서도 남는다. 장기 메모리에는 사용자 선호, 과거 결정, 학습된 사실, 이전 세션의 요약이 담길 수 있다.

메모리는 대화 기록과 달리 큐레이션되고 구조화되어 있다. 대화 전체를 그대로 두지 않고, 나중에 검색하기 좋은 형식으로 핵심 정보를 뽑아 저장한다. Mem0, Letta, Zep 같은 제품은 컨텍스트 엔지니어링의 메모리 계층을 다루기 위해 등장했다.¹³

사용자 프로필과 개인화도 컨텍스트에 포함될 수 있다. 선호, 역할, 권한, 과거 상호작용, 조직이나 인구통계 맥락 같은 사용자별 정보를 넣으면, 사용자가 매번 같은 내용을 반복하지 않아도 모델이 더 관련성 높고 적절한 답을 낼 수 있다.

6. 쓰기, 선택, 압축, 격리 틀

이 틀은 컨텍스트 엔지니어링 커뮤니티에서 널리 받아들여졌다. LangChain의 해리슨 체이스와 LangGraph 팀이 대중화했으며, 컨텍스트를 관리하는 네 가지 핵심 작업을 제시한다.^8,14

쓰기 전략은 정보를 컨텍스트 창 밖에 저장해 나중에 다시 쓰는 것이다. 가장 흔한 구현은 스크래치패드나 외부 메모리 방식이다. 에이전트는 작업 중에 메모를 남겨 진행 상황을 추적하고, 중간 결과를 저장하며, 여러 단계로 이어지는 과정에서 상태를 유지한다.

구체적으로는 도구 결과를 스크래치패드에 저장하고, 중간 발견 사항을 에이전트가 나중에 읽을 파일에 쓰고, 공유 상태 저장소를 갱신하고, Mem0 같은 장기 메모리에 추출한 사실을 기록하는 방식이 있다. 쓰기 작업은 과업 초반에 내린 결정을 여러 단계 뒤에도 참조해야 하는 장기 실행 과업에서 특히 중요하다.

선택 전략은 정보를 지능적으로 걸러 내는 것이다. 가용한 모든 정보를 넣는 대신, 각 상호작용에 가장 관련 있는 컨텍스트만 찾아 올린다. 시맨틱 검색, 관련성 점수, 메타데이터 필터링으로 현재 컨텍스트 창에 넣을 과거 정보를 정한다.

이 범주에는 RAG(지식 베이스 질의), 메모리 검색(Mem0나 Zep에서 과거 사실 가져오기), 동적 도구 선택(현재 컨텍스트에 노출할 도구 결정)이 포함된다. 목표는 잡음을 줄이면서 관련성을 최대화하는 것이다. 실서비스 에이전트는 긴 과업의 시작 시점뿐 아니라 매 단계마다 선택 작업을 적용하는 것이 일반적이다.

압축 전략은 본질적인 정보를 잃지 않으면서 컨텍스트의 토큰 수를 줄인다. 도구 결과, 검색 문서, 대화 턴이 쌓이면 큰 컨텍스트 창도 금방 포화되므로 압축이 필요하다. 기법에는 다음이 있다.

• 요약: 더 작은 모델로 긴 문서나 대화 구간을 줄인 뒤 주 모델의 컨텍스트에 넣는다.
• 추출식 압축: 검색된 내용에서 가장 관련 있는 문장이나 구절만 고른다.
• 토큰 가지치기: 군더더기 단어, 중복 정보, 관련성이 낮은 내용을 제거한다.
• 의미 중복 제거: 여러 검색 출처에서 정보가 겹치는 구절을 찾아 제거한다.
• 고정 반복 요약: 처음부터 다시 쓰지 않고 점진적으로 갱신되는 롤링 요약을 유지한다.

Zylos AI가 2026년 초에 수행한 연구에 따르면, 고정 반복 요약은 전체를 다시 쓰는 요약보다 정확도, 완결성, 연속성 점수가 높았다. 새 요약을 지속 상태에 병합하면 정보가 점차 표류하는 것을 막기 때문이라고 한다.

격리 전략은 컨텍스트를 여러 에이전트에 나눈다. 각 에이전트는 자기만의 집중된 컨텍스트 창을 가진다. 가장 구조적으로 발전된 기법이며, 다중 에이전트 시스템 설계와 가장 직접 이어진다.

모든 정보를 하나의 컨텍스트에 싣는 대신, 격리 패턴은 하위 과업을 전문 서브에이전트에 위임한다. 각 서브에이전트는 범위가 정해진 과업 설명과 과업 완료에 필요한 최소한의 컨텍스트를 받고, 구조화된 요약을 상위 에이전트에 돌려준다. 상위 에이전트는 서브에이전트가 탐색한 흔적은 보지 않고 결과만 본다. 이렇게 하면 메인 에이전트의 컨텍스트가 깨끗하게 유지되고 여러 서브에이전트가 병렬로 일할 수 있다.

Claude Code의 서브에이전트 모델이 이 패턴을 보여 준다. 서브에이전트는 새로 격리된 컨텍스트에서 동작하고, 상위 에이전트가 범위를 정한 과업 설명을 받아 독립적으로 실행한 뒤 구조화된 요약을 돌려준다. 상위 에이전트는 그 요약을 자기 작업 집합에 넣는다. Factory.ai의 연구는 넓은 코드베이스 검색이 필요한 과업에서 격리된 컨텍스트를 가진 다중 에이전트 시스템이 단일 에이전트 구조보다 나았다고 밝혔다. 주로 각 서브에이전트의 컨텍스트 창이 더 좁은 하위 과업에 배분되었기 때문이다.¹⁵

7. Anthropic의 컨텍스트 엔지니어링 틀

2025년 9월 Anthropic은 이 주제에 관한 가장 상세한 공개 논의인 「Effective Context Engineering for AI Agents」를 발표했다. Claude 엔지니어링 팀이 쓴 이 글은 컨텍스트 엔지니어링을 프롬프트 엔지니어링의 자연스러운 후속으로 규정했다. 언어 모델로 무언가를 만드는 일은 프롬프트의 정확한 단어를 찾는 것보다, 원하는 모델 행동을 가장 잘 이끌어 낼 컨텍스트 구성을 찾는 쪽으로 옮겨 가고 있다는 것이다.⁴

• 시스템 지침 우선: Anthropic이 권하는 배치는 컨텍스트 앞쪽에 시스템 지침을 두고, 그다음에 관련 메모리와 저장된 지식, 도구 정의, 마지막으로 대화 기록을 두는 것이다. 모델이 동적 내용보다 먼저 가장 안정적이고 우선순위가 높은 정보를 보게 하려는 것이다.
• 성장을 기다리기보다 선제적 압축: 컨텍스트가 한도에 닿을 때까지 쌓아 두지 않는다. Claude Code는 대화가 컨텍스트 예산의 약 70%에 이르면 요약 단계를 실행해 대화를 압축한다. 요약은 파일 경로, 결정, 현재 계획을 보존하고, 탐색 흔적과 중복된 도구 출력은 버린다.
• 장기 과업용 구조화된 메모: 여러 단계를 도는 에이전트는 현재 목표, 완료한 단계, 핵심 발견, 미해결 질문을 위한 전용 섹션이 있는 스크래치패드를 유지한다. 각 섹션이 체크리스트 역할을 하므로 구조가 점진적인 정보 손실을 막는다.
• 다중 에이전트 컨텍스트 규율: 모든 모델 호출과 서브에이전트가 과업에 필요한 최소한의 컨텍스트만 보게 한다. 에이전트는 기본값으로 정보를 많이 받는 대신, 도구를 통해 필요한 정보를 명시적으로 가져와야 한다.

이 가이드는 장기 실행 에이전트를 위한 효과적인 하네스 개념도 소개했다. 사람 엔지니어가 일을 넘겨줄 때 쓰는 방식, 즉 명확한 산출물, 간결한 인수인계 메모, 명시적인 범위 경계에서 영감을 얻었다.

8. 컨텍스트 엔지니어링이 중요한 이유

2023년부터 2026년 사이 컨텍스트 창은 크게 늘었다. 2023년 GPT-4의 8,192토큰 창 다음에는 2024년 GPT-4o의 128,000토큰 버전이 나왔다. 2025년에는 Gemini 1.5 Pro가 100만 토큰을 제공했고, Gemini 2.5는 이를 더 늘렸다. Claude 3은 200,000토큰 창을 도입했고, Qwen 3도 비슷한 길이에 도달했다.

창이 커졌다고 해서 컨텍스트 엔지니어링의 필요가 사라지지는 않는다. 연구들은 컨텍스트 길이가 늘수록 모델 성능이 떨어진다는 점을 일관되게 보여 왔다. 이 현상은 '중간에서 잃어버림(lost in the middle)' 문제로 불리며 arXiv:2307.03172에 기록되어 있고, 더 넓게는 컨텍스트 로트(context rot)라고 부른다. 컨텍스트가 많다고 자동으로 좋아지지 않으며, 모델이 무엇을 어디에서 보는지에 따라 성공 여부가 갈린다.

컨텍스트 로트는 컨텍스트 창이 거의 차지 않았을 때도, 입력 컨텍스트 길이가 늘어남에 따라 LLM 출력 품질이 측정 가능하게 떨어지는 현상이다. 이 용어는 Chroma의 2025년 7월 연구에서 공식화됐다. 이 연구는 GPT-4.1, Claude Opus 4, Gemini 2.5를 포함한 18개 최전선 모델을 시험했다. 연구는 시험한 모든 입력 길이 구간에서 예외 없이 모든 모델의 성능이 떨어졌다고 밝혔다.¹⁶

컨텍스트 로트를 만드는 기제는 세 가지가 겹쳐 작동한다.

• 중간 소실 효과: 트랜스포머의 어텐션은 긴 컨텍스트의 중간 부분에서 가장 약하다. 모델은 맥락의 앞과 끝에는 강하게, 그 사이에는 약하게 주의를 기울인다. 그래서 중간에 놓인 정보의 정확도가 30% 이상 떨어진다.
• 어텐션 희석: 트랜스포머 어텐션은 시퀀스 길이의 제곱에 비례해 늘어난다. 10만 토큰에서 모델은 약 100억 개의 쌍별 관계를 다뤄야 하며, 이것이 커질수록 특정 토큰이 내는 신호는 희석된다.
• 방해 요소 간섭: 의미상 비슷하지만 무관한 내용이 모델을 적극적으로 오도한다. Chroma 연구는 18개 모델 모두에서 논리적으로 일관된 건초더미(haystack)가 무작위로 섞인 것보다 성능이 나빴다고 밝혔다. 구조적 일관성이 방해 요소에 더 그럴듯한 관련성을 주었기 때문이다.¹⁷

코딩 에이전트에서 컨텍스트 로트는 주된 실패 양상이다. 에이전트는 탐색, 되돌아가기, 도구 출력 누적을 거치며 일상적으로 10만 토큰을 넘긴다. 완화 전략에는 검색을 서브에이전트로 격리하기, 파일 전체 대신 정확한 파일과 줄 범위 반환하기, 상위 에이전트에 넘기기 전에 탐색 흔적 버리기, 전체 파일 대신 압축된 diff 쓰기, 컨텍스트 한도를 기다리지 않고 선제적으로 압축하기가 있다.

Chroma 연구는 또 컨텍스트 로트가 트랜스포머 어텐션의 구조적 성질이며, 미래의 학습으로 간단히 없앨 수 있는 능력 격차가 아니라고 밝혔다. 따라서 기본 모델의 능력이 나아져도 컨텍스트 엔지니어링은 여전히 중요하다.

8.1. 토큰 예산 관리

실무자들은 대개 컨텍스트 창을 가능한 모든 것으로 채우기보다 짧고 초점이 분명한 컨텍스트가 더 나은 결과를 낸다고 본다. Anthropic의 가이드는 컨텍스트를 예산으로 다루라고 권한다. 각 구성 요소, 즉 시스템 프롬프트, 검색 문서, 대화 기록, 도구 결과에 몇 토큰을 줄지 미리 정하고, 그 한도를 명시적으로 강제하라는 것이다.

32,000토큰 창을 쓰는 고객 대면 에이전트에서 흔한 예산 배분은 다음 표와 같다.

9. 프리픽스 캐싱

컨텍스트 캐싱(프리픽스 캐싱 또는 프롬프트 캐싱이라고도 한다)은 트랜스포머 어텐션 계산에서 얻은 KV 캐시를 재사용해 같은 컨텍스트를 반복해서 처리하지 않게 한다. 여러 요청에서 프롬프트 앞부분이 같으면, 첫 번째 처리에서 계산한 키-값 쌍을 이후 요청에 재사용해 계산 시간과 비용을 함께 줄인다.

Anthropic은 2024년 8월 Claude에 프롬프트 캐싱을 도입했다. 캐시 읽기는 백만 토큰당 대략 0.30달러이고, 새로 계산할 때는 백만 토큰당 3.00달러다. 비용이 90% 줄어드는 셈이다. 긴 캐시 접두사에서는 지연 시간을 85% 이상 줄일 수 있다.¹⁸

프리픽스 캐싱은 컨텍스트 엔지니어링에 중요한 영향을 준다. 실용 규칙은 안정적인 내용을 컨텍스트 앞에, 동적인 내용을 뒤에 두는 것이다. 접두사 어디에서든 글자가 바뀌면 그 지점부터 캐시가 무효화된다. 시스템 프롬프트 첫 줄에 공백 하나만 더해도 모델은 KV 캐시 전체를 다시 계산해야 한다.

사내 지식 베이스처럼 모든 직원에게 매번 로드되는 공유 컨텍스트가 있는 고트래픽 응용에서는 요청 사이의 캐싱도 가능하다. 에이전트 루프, 멀티테넌트 SaaS, 장문 문서 워크플로에서는 적중률이 60~85%인 경우가 흔하며, 이때 호출당 비용은 5~12배 줄어든다.

캐시 활용을 극대화하는 모범 사례는 다음과 같다.

• 시스템 프롬프트와 참고 문서를 사용자 메시지보다 앞에 둔다.
• 같은 응용의 요청들에서 시스템 프롬프트 내용을 안정적으로 유지한다.
• 큰 정적 컨텍스트(정책 문서, 코드베이스, 참고 매뉴얼)는 매 턴 다시 넣지 말고 세션 시작 시 한 번 로드한다.
• 세션 단위 캐싱을 써서 매 턴마다 누적된 대화 기록을 다시 처리하지 않게 한다.

10. RAG와 컨텍스트 엔지니어링의 관계

검색 증강 생성(RAG)은 가장 오래되고 가장 널리 배포된 컨텍스트 엔지니어링 기법 가운데 하나다. 핵심 아이디어는 모델의 파라메트릭 지식, 즉 학습 중 가중치에 새겨진 지식이 불완전하고 낡았을 수 있으며 검증하기 어렵다는 것이다. RAG는 외부 출처에서 관련 정보를 찾아 질의 시점에 컨텍스트 창에 넣어 이를 보완한다.

컨텍스트 엔지니어링 관점에서 RAG는 선택(select) 작업이다. 검색 파이프라인이 어떤 문서나 구절을 넣을지 고른다. RAG 파이프라인의 공학적 결정은 모두 컨텍스트 엔지니어링의 결정이다. 검색 방식으로 밀집 벡터 유사도, 희소 BM25 키워드, 하이브리드 중 무엇을 쓸지, 몇 개를 검색하고 어떻게 순위를 매길지, 초기 검색 뒤에 재순위화로 정밀도를 높일지, 검색 구절에 출처나 메타데이터를 넣을지 뺄지, 넣기 전에 추출식 압축을 적용할지, 여러 출처의 상충 정보를 어떻게 다룰지가 여기에 해당한다.

코딩 맥락에서 RAG의 대안은 에이전틱 검색이다. 모델은 사전 색인된 벡터 저장소를 질의하는 대신 도구로 코드베이스를 직접 검색한다. Claude Code와 Devin 팀은 코드베이스 질의응답에서 에이전틱 검색이 RAG보다 낫다고 보고했다. 그 이유로는, 에이전트가 import 체인을 따라가고 관련 파일을 읽고 검색을 반복할 수 있어서 일회성 벡터 조회로는 할 수 없는 일을 하기 때문일 수 있다.

실서비스에서는 혼합 방식이 흔하다. 예를 들어 기업 비서는 정책과 인사 문서처럼 비교적 안정적이고 색인하기 쉬운 자료에는 RAG를 쓰고, 크고 빠르게 바뀌어 색인을 유지하기 어려운 회사 코드베이스에는 에이전틱 검색을 쓸 수 있다.

11. 메모리 시스템 통합

메모리 시스템은 컨텍스트 엔지니어링을 현재 세션 너머로 확장한다. 메모리가 없으면 모든 대화는 처음부터 시작한다. 메모리가 있으면 모델은 이전 결정, 사용자 선호, 과거의 오류, 어떤 단일 컨텍스트 창에도 들어가기 어려운 누적된 도메인 지식을 참조할 수 있다.

2025~2026년 메모리 시스템 지형은 세 주요 공급사와 성장하는 오픈소스 생태계를 중심으로 짜여 있다. 대표 제품은 Mem0, Letta, Zep이다.

Mem0는 프레임워크에 구애받지 않는 AI 에이전트 메모리 계층이다. 에이전트가 특정 오케스트레이션 시스템 안에서 돌 필요가 없다. 간단한 SDK를 제공해 mem0.add()로 메모리를 저장하고 mem0.search()로 검색한다. 추출, 중복 제거, 색인은 시스템이 내부에서 처리한다.

Mem0는 깃허브 스타 48,000개에 이르렀고 2025년 10월에 2,400만 달러를 조달했다. ECAI 2025에서 발표된 Mem0 팀의 벤치마크 논문은 긴 문맥의 대화 메모리 벤치마크인 LOCOMO 데이터셋을 대상으로 메모리 접근법 열 가지를 시험했다. 그 결과 벡터와 그래프를 결합한 하이브리드 메모리가 모든 단일 메커니즘 접근법보다 나았다.

컨텍스트 엔지니어링 관점에서 Mem0는 장기 메모리에 대한 쓰기와 선택 작업을 구현한다. 대화에서 중요한 사실을 메모리 저장소에 쓰고, 관련 사실을 골라 이후 컨텍스트 창에 주입한다.

Letta(이전 이름 MemGPT)는 다른 구조를 택한다. 메모리를 기존 오케스트레이터 위의 층으로 더하지 않고, 메모리를 일급 런타임 관심사로 다룬다. 에이전트는 Letta 런타임 안에서 돌며, 런타임은 인컨텍스트 메모리, 아카이벌 메모리, 리콜 메모리를 서로 구분되는 주소 지정 가능한 저장소로 관리한다.

MemGPT 논문(2023)은 LLM 컨텍스트 창을 운영체제의 가상 메모리처럼 다루는 개념을 도입했다. 가장 중요한 정보는 주 메모리인 컨텍스트 창에 두고, 덜 급한 정보는 아카이벌 저장소로 밀어냈다가 필요할 때 다시 가져온다. Letta는 이 모델을 실서비스에서 구현한다.

Zep은 대화형 메모리, 구조화된 사실 추출, 고객 대면 응용의 컨텍스트 보강에 초점을 둔다. 사용자 그래프와 세션 그래프를 유지하고, 대화에서 개체를 추출하며, 이후 모델 호출마다 풍부한 컨텍스트를 조립한다.

2026년 초에는 그래프 기반 메모리가 실험 단계에서 실서비스 단계로 넘어갔다. 그래프 메모리는 사실을 평면 벡터가 아니라 지식 그래프의 노드와 간선으로 저장한다. 다중 홉 추론에 특히 유용하며, 예를 들어 인증 시스템에 대해 내린 결정이 데이터베이스 마이그레이션 계획과 충돌하는지 묻는 과업에 적합하다. 벡터 검색은 의미상 비슷한 사실을 돌려주지만, 그래프 탐색은 명시적인 관계를 따라간다.

12. 지시 계층과 보안

컨텍스트가 여러 출처에서 올 때, 즉 시스템 프롬프트, 사용자 입력, 검색 문서, 도구 결과에서 올 때 충돌이 생길 수 있다. 지시 계층은 이런 충돌을 해결하는 우선순위를 정한다. 보통 시스템 수준 지침이 가장 높고, 개발자가 정한 제약이 다음이며, 사용자 입력이 그 뒤를 따른다.

OpenAI는 API에서 시스템, 개발자, 사용자 메시지 계층으로 이 개념을 공식화했으며, 시스템 메시지는 사용자 메시지로 덮어쓸 수 없다. Anthropic 문서도 Claude 에이전트의 신뢰 계층을 설명하며, 운영자(응용을 만든 개발자), 사용자(입력하는 사람), 외부 출처에서 검색된 콘텐츠를 구분한다.

컨텍스트가 외부 출처, 즉 검색 문서, 웹 페이지, 이메일, 도구 출력에서 조립될 때 한 출처의 악성 콘텐츠가 모델 행동을 조작할 위험이 있다. 이런 공격을 프롬프트 인젝션이라 부른다.

2025년에 위협의 규모가 크게 커졌다. 한 연구는 2026년 기업 프롬프트 인젝션 시도가 340% 늘었다고 집계했다. 문서, 웹 페이지, 데이터베이스 콘텐츠에 심겨 검색을 통해 컨텍스트로 들어오는 간접 인젝션은 문서화된 공격 시도의 80% 이상을 차지한다. 사용자가 직접 악성 프롬프트를 입력하는 직접 인젝션은 20% 미만이다.

컨텍스트 엔지니어링의 보안 실무에는 다음이 포함된다.

• 출처 태깅: 각 컨텍스트 조각에 출처를 표시해 모델이 적절한 신뢰 수준을 적용하게 한다.
• 콘텐츠 정화: 검색된 콘텐츠를 컨텍스트에 넣기 전에 흔한 인젝션 패턴을 걸러 낸다.
• 구조적 분리: 신뢰할 수 없는 검색 콘텐츠를 명확히 구분된 구획에 두고, 그 구획을 어떻게 다룰지 명시적으로 지시한다.
• 결정적 안전장치: 행동을 실행하기 전 모델 출력에 LLM이 아닌 검사를 적용해, 성공한 인젝션의 피해 범위를 줄인다.

2024년 말 에이전트가 외부 도구에 연결되는 방식을 표준화하려고 도입된 모델 컨텍스트 프로토콜(MCP)은 새로운 인젝션 경로를 만들었다. 도구 설명을 조작해 에이전트를 속이는 도구 포이즈닝을 포함한 MCP 보안 취약점은 2025년까지 활성 위협 범주로 확인됐다.

13. CLAUDE.md와 AGENTS.md

코딩 에이전트를 위한 가장 실용적인 컨텍스트 엔지니어링 수준에서는, 모든 세션 시작 시 지속 컨텍스트를 주입하는 두 파일 형식이 등장했다. 바로 CLAUDE.md와 AGENTS.md다.

CLAUDE.md는 프로젝트 루트(또는 사용자 수준 설정을 위한 ~/.claude/ 디렉터리)에 두는 마크다운 파일로, Claude Code가 매 세션 시작 시 자동으로 읽는다. 목적은 매 실행마다 모델에 다시 설명해야 할 안정적인 프로젝트 수준 컨텍스트를 주입하는 것이다.

전형적인 CLAUDE.md 내용은 다음과 같다.

• 아키텍처 개요와 핵심 설계 결정
• 코딩 표준, 선호 라이브러리, 피해야 할 패턴
• 환경 설정 지침과 빌드 명령
• 현재 프로젝트 상태와 알려진 문제
• 파일 이름, 테스트, 배포 관례
• 주요 문서 링크

잘 쓴 CLAUDE.md는 그 자체가 컨텍스트 엔지니어링이다. 가장 중요한 프로젝트 맥락을 모든 컨텍스트 창 맨 앞에 놓이는 간결하고 안정적인 문서로 정제한다. 정적 내용이 앞쪽에 있으므로 프리픽스 캐싱의 좋은 후보가 되며, 세션에서 한 번 사용한 뒤로는 사실상 비용이 들지 않는다.

모범 사례는 다음과 같다. 저장소의 모든 작업에 공통으로 적용되는 정보에 집중하고, 대부분의 경우 무관한 작업별 지침은 피한다. 산문보다 번호 목록이나 표 같은 구조화된 정보를 선호하고, 프로젝트 관례가 바뀌면 갱신한다.

Claude Code는 하위 디렉터리의 중첩 .claude/CLAUDE.md 파일도 지원한다. 이 파일들은 에이전트가 해당 디렉터리의 파일을 읽을 때만 로드되므로, 쓰지 않는 컨텍스트가 메인 세션의 토큰 예산을 차지하지 않는다.

AGENTS.md는 AI 코딩 에이전트에 저장소 수준 컨텍스트를 제공하는 개방형 도구 간 표준이다. 2025년 중반 Sourcegraph, OpenAI, Google, Cursor 등의 협업으로 등장했으며, Agentic AI Foundation(Linux Foundation) 산하에서 관리된다.

CLAUDE.md가 Claude Code 전용인 반면 AGENTS.md는 도구에 구애받지 않는다. 같은 파일을 Claude Code, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Aider 등 이 표준을 채택한 에이전트가 함께 쓴다. 도구마다 별도의 컨텍스트 파일을 관리할 필요를 없앤다.

2025년 연구 논문(arXiv:2602.11988)은 여러 저장소 말뭉치에서 AGENTS.md 파일을 실증적으로 평가했다. 잘 쓴 컨텍스트 파일이 에이전트의 과업 성공률을 크게 높였으며, 특히 에이전트가 프로젝트 구조를 탐색하느라 많은 단계를 쓰는 낯선 코드베이스에서 효과가 컸다고 밝혔다.¹⁹

AGENTS.md 표준은 계층 구조를 정한다. 저장소 루트의 기본 AGENTS.md는 모든 과업에 적용되는 컨텍스트를 준다. 하위 디렉터리의 AGENTS.md는 그 부분의 코드베이스에 특화된 컨텍스트를 준다. 세션 컨텍스트는 일시적이고 과업에 특정한 정보를 담고, 누적된 세션 메모리는 에이전트가 시간이 지나며 배운 것을 담는다.

14. 코딩 에이전트의 컨텍스트 엔지니어링

코딩 에이전트는 컨텍스트 엔지니어링에서 가장 까다로운 응용 중 하나다. 자명하지 않은 소프트웨어 변경은 여러 파일, 과거 결정, 테스트 인프라, 배포 제약에 걸친 이해가 필요하지만, 코드베이스 전체를 컨텍스트에 싣는 것은 보통 비현실적이고 역효과를 낸다. Claude Code, Cursor, Devin 같은 도구는 서로 다르지만 수렴하는 접근법을 발전시켜 왔다.

코딩 에이전트는 모든 파일을 미리 색인하는 대신 에이전틱 검색을 쓴다. 에이전트는 grep, 파일 트리 확인, 표적 파일 읽기, import 체인 탐색으로 필요한 코드를 필요할 때 찾는다. Anthropic은 이 접근법이 초기 RAG 실험보다 크게 나았다고 보고했다. 에이전트는 찾은 결과에 따라 검색 전략을 조정하고, 참조를 따라가며, 파일 전체가 아니라 필요한 줄만 정확히 읽을 수 있다.

코딩 에이전트는 결과를 정확히 반환해 컨텍스트를 관리한다. 파일 전체 대신 파일과 줄 범위를, 파일 내용을 되풀이하는 대신 압축된 diff를, 원시 출력 대신 검색 결과의 구조화된 요약을 돌려준다. 흔한 경험칙은 같은 변경을 10줄의 diff로 전달할 수 있다면 파일 전체 내용을 컨텍스트에 넣지 않는다는 것이다.

대형 코드베이스나 탐색이 필요한 과업에서 코딩 에이전트는 격리된 컨텍스트 창을 가진 서브에이전트를 쓴다. 예를 들어 폐기 예정 함수의 모든 사용처를 찾는 서브에이전트는 자기 컨텍스트에서 코드베이스를 검색한 뒤 구조화된 보고서를 상위 에이전트에 돌려준다. 상위 에이전트는 검색 흔적을 쌓지 않는다. 이 패턴은 메인 에이전트의 컨텍스트를 검색 과정이 아니라 과업에 집중하게 한다.

Claude Code는 Task 도구로 서브에이전트를 띄워 이 패턴을 구현한다. 각 서브에이전트는 과업 설명과 최소한의 필요 정보만 담은 새 컨텍스트를 받는다. 서브에이전트의 생명주기와 결과 주입은 모델이 아니라 하네스가 관리한다.

LMCache 팀의 2025년 분석은 코딩 에이전트의 KV 캐시 재사용률이 매우 높다고 밝혔다. 한 연구는 ReAct 기반 서브에이전트 루프에서 92%의 프리픽스 재사용을 보고했다. 같은 시스템 프롬프트, 프로젝트 문서, 초기 컨텍스트가 거의 모든 모델 호출 앞에 붙기 때문이다. 이 때문에 프리픽스 캐싱은 코딩 에이전트 배포에서 가장 효과가 큰 비용 최적화 중 하나가 된다.²⁰

15. 서브에이전트 컨텍스트 패턴

코딩 에이전트를 넘어, 서브에이전트 컨텍스트 패턴은 장기 실행 에이전트 과업 전반에 쓰이는 일반적인 틀이 됐다. 이 원칙은 Anthropic의 가이드에서 가져왔으며, Cognition, LangChain, Factory.ai의 실무자들이 검증했다.

최소 실행 가능 컨텍스트. 모든 서브에이전트는 특정 과업을 완료하는 데 필요한 정보만 받는다. 토큰 비용을 줄이고, 컨텍스트 로트 위험을 낮추고, 서브에이전트의 행동을 더 예측할 수 있게 만든다.

범위가 정해진 과업 설명. 상위 에이전트는 작업 컨텍스트 전체를 서브에이전트에 넘기지 않는다. 목표, 관련 제약, 필요한 배경을 담은 과업 설명을 짜며, 보통 수백 토큰 안팎이다.

구조화된 반환값. 서브에이전트는 원시 출력 대신 구조화된 요약을 돌려준다. 예를 들어 파일 검색 서브에이전트는 읽은 모든 파일의 내용이 아니라 관련 파일 경로와 줄 번호 목록을 반환한다. 상위 에이전트는 구조화 출력을 보고 무엇을 불러올지 고른다.

상위 컨텍스트에 탐색 흔적을 남기지 않는다. 서브에이전트가 문제를 탐색하는 과정, 즉 파일 읽기, 접근 시도, 되돌아가기는 상위 컨텍스트에 나타나지 않고 결과만 위로 전달된다. 이것이 서브에이전트 패턴이 컨텍스트 누적을 막는 핵심 장치다.

병렬성. 여러 서브에이전트가 각자의 컨텍스트 창으로 문제의 다른 측면을 동시에 탐색할 수 있고, 상위 에이전트가 결과를 종합한다. 이 패턴은 속도와 컨텍스트 효율을 함께 높일 수 있다.

월든 얀은 다중 에이전트 시스템이 에이전트 사이에서 컨텍스트를 안정적으로 공유할 수 없어 흔히 깨지기 쉽다고 주장했다. 그의 결론은 Devin이 다중 에이전트 조율 대신 공격적인 컨텍스트 관리를 하는 단일 에이전트 구조를 쓴다는 것이다. 대부분의 과업에서는 여러 에이전트를 공유 컨텍스트에 맞춰 두는 엔지니어링 비용이 병렬성의 이점보다 크다는 이유다.⁶

16. 에이전틱 컨텍스트 엔지니어링

에이전틱 컨텍스트 엔지니어링(ACE)은 위에서 설명한 일반적 실무와 구분되는 특정 방법이다. 이 방법에서 컨텍스트 자체는 사람이 쓴 정적 텍스트가 아니라, 에이전트가 시간이 지나며 개선하는 편집 가능한 플레이북으로 다뤄진다. 스탠퍼드, SambaNova, UC 버클리의 2025년 연구 논문에서 소개됐다. ACE는 컨텍스트를 항목화된 전략의 모음으로 구성하고, 생성기, 반영기, 큐레이터로 이어지는 루프를 돌려 실행 피드백에 근거해 항목을 추가하고 개선하고 정리한다. 목표는 에이전트가 모델을 재학습하지 않고도 어렵게 얻은 교훈을 축적하고 재사용하게 하는 것이다.

일반적인 컨텍스트 엔지니어링은 사람이나 결정적 파이프라인이 창에 무엇을 넣을지 정한다. 에이전틱 컨텍스트 엔지니어링은 시스템이 학습하면서 스스로 컨텍스트를 다시 써서 그 큐레이션을 자동화한다. ACE는 RAG, 메모리 시스템, 쓰기, 선택, 압축, 격리 작업과 함께 넓은 컨텍스트 엔지니어링 아래 묶이는 여러 기법 가운데 하나다.

17. 도구와 프레임워크

여러 도구와 프레임워크가 컨텍스트 엔지니어링 실무를 지원한다.

18. 실무 예시

프롬프트 엔지니어링과 컨텍스트 엔지니어링이 어떻게 다른지 보기 위해, AI 기반 고객 지원 에이전트를 만든다고 하자.

프롬프트 엔지니어링 접근은 상세한 시스템 프롬프트를 쓰는 데 초점을 둘 수 있다. 예를 들면 'Acme Corp의 도움이 되는 고객 지원 상담원이다. 예의 바르고 간결하게 답한다. 답을 모르면 모른다고 말한다.' 같은 지시문이다.

컨텍스트 엔지니어링 접근은 시스템 전체를 설계한다. 구성은 다음과 같다.

• 시스템 프롬프트: 행동 지침과 제약을 간결하게 모은 것(200~300토큰)으로, 프리픽스 캐싱을 위해 앞쪽에 둔다.
• 사용자 프로필 검색: 매 요청마다 CRM에서 고객의 계정 세부 정보, 구독 등급, 최근 지원 이력을 가져온다(200~500토큰).
• 지식 베이스 검색: RAG로 고객 질문과 관련된 지원 문서를 찾고(500~2,000토큰), 추출식 압축으로 상투적 문구를 뺀다.
• 최근 주문 조회: 질문이 주문과 관련되면 API를 호출해 고객의 최근 주문 5건을 가져온다(100~300토큰).
• 대화 기록 관리: 최근 메시지 10개는 전체를 유지하고, 이전 메시지는 200토큰짜리 롤링 요약으로 줄인다.
• 메모리 확인: Mem0를 통해 이전 세션에서 저장된 이 고객에 대한 메모를 가져온다(100~200토큰).
• 지시 계층: '500달러를 넘는 환불은 에스컬레이션 없이 발급하지 않는다' 같은 시스템 제약을 사용자 메시지가 덮어쓰지 못하게 한다.
• 인젝션 방어: 외부 출처에서 온 콘텐츠를 명확히 태그된 구획에 두고, 잠재적으로 신뢰할 수 없는 데이터로 다루라는 모델 지침을 함께 준다.

이 접근은 여러 출처에서 동적으로 조립되고, 토큰 한도 안에 맞도록 예산이 짜이며, 프리픽스 캐시 적중을 최대화하도록 구조화되고, 관측할 수 있도록 계측된 컨텍스트 창을 만든다.

19. 컨텍스트 엔지니어링의 활용 분야

20. 현재 상황(2025~2026)

2026년 중반 기준 컨텍스트 엔지니어링은 AI 엔지니어링 안에서 인정받는 하위 분야가 됐다. 채용 공고에서 필수 역량으로 언급하는 경우가 늘고 있다. 커뮤니티의 합의는 실서비스급 AI 응용, 특히 에이전트형 응용은 모델 선택만으로보다 효과적인 컨텍스트 엔지니어링에 더 달려 있다는 것이다.

주요 흐름은 다음과 같다.

• 컨텍스트 엔지니어링 패턴이 LangChain, LlamaIndex, Semantic Kernel, Google ADK 같은 주류 프레임워크에 통합되고 있다.
• Mem0, Letta, Zep, LMCache 같은 전용 메모리와 캐싱 인프라가 발전하고 있다.
• 서베이 논문, 벤치마크 데이터셋, 형식적 프레임워크를 담은 학술 문헌이 arXiv에 늘고 있다.
• 컨텍스트 로트가 공식 연구 문제로 떠올랐으며, Chroma의 2025년 7월 연구가 가장 많이 인용되는 체계적 다룸이다.
• AGENTS.md 표준이 저장소 수준의 지속 컨텍스트를 주입하는 도구 간 방식을 제공한다.
• Anthropic, OpenAI, Google이 모두 에이전트를 위한 컨텍스트 엔지니어링 가이드를 발간하고 있다.
• 공급사가 제공하는 압축 API(OpenAI Compaction, Claude의 자동 압축)가 플랫폼의 일급 기능으로 등장하고 있다.

분야는 빠르게 진화하고 있다. 모델이 더 유능해지고 컨텍스트 창이 커질수록 과제는 정보를 창에 욱여넣는 것이 아니라, 모든 토큰이 모델 성능 향상에 기여하도록 지능적으로 채우는 것이다. 컨텍스트 로트 연구는 대형 컨텍스트 창을 무분별하게 채우면 성능이 떨어질 수 있음을 시사한다. 따라서 창이 커질수록 컨텍스트 엔지니어링은 덜 중요해지는 것이 아니라 더 중요해진다.

21. 한계

컨텍스트 엔지니어링 시스템을 디버깅하는 일은 정적 프롬프트보다 어렵다. 모델이 나쁜 응답을 내면 원인은 검색, 압축, 메모리 시스템, 도구 호출, 구성 요소 사이의 상호작용 중 어디에든 있을 수 있다. 단계마다 조립된 컨텍스트를 들여다보는 관측 도구는 아직 성숙 중이다. LangSmith 같은 제품은 추적을 제공하지만 자동 진단은 부족하다.

캐시나 사전 계산된 출처에서 조립된 컨텍스트는 낡을 수 있다. 고객의 주문 상태는 캐싱된 시점과 모델이 응답하는 시점 사이에 바뀔 수 있으므로, 컨텍스트 엔지니어링 시스템에는 명시적인 무효화와 갱신 장치가 필요하다.

컨텍스트를 압축하면 정보를 잃을 위험이 있다. 요약 모델은 핵심 세부 사항, 특히 수치 사실과 고유명사를 빠뜨릴 수 있다. 추출식 압축은 관련성이 낮다고 평가한 구절에서 중요한 맥락을 놓칠 수 있다. 이 위험은 압축 단계가 많은 긴 과업에서 누적된다.

컨텍스트 엔지니어링이 넓힌 공격 표면, 즉 RAG 파이프라인, 도구 호출 출력, 외부 API 결과는 정적 프롬프트 시스템보다 많은 인젝션 경로를 만든다. 기존 어떤 방어도 모든 간접 인젝션 공격에 대해 믿을 만한 보호를 제공하지 못한다.

잘 설계된 컨텍스트 시스템은 흔히 여러 모델 호출(검색, 요약, 압축), 데이터베이스 조회, 외부 API 호출을 포함한다. 컨텍스트를 조립하는 데 드는 인프라 비용과 지연이 최종 추론 단계의 비용을 넘어설 수 있다. 프리픽스 캐싱이 일부를 상쇄하지만 전부는 아니다.