한동안 \"프롬프트 엔지니어링\"은 대형 언어 모델에서 좋은 결과를 얻는 기술을 가리키는 이름이었습니다. 초창기에는 그 이름이 타당했습니다. 대부분의 사람들이 단발성 상호작용을 사용하고 있었고, 주요 레버는 정말로 표현 방식처럼 느껴졌습니다. 더 명확하게 질문하고, 예시를 추가하고, 형식을 제한하면 모델이 더 잘 작동했습니다.
하지만 그 프레임은 이제 실제 문제를 담기에 너무 작아졌습니다.
AI 시스템이 프로덕션에서 실패할 때, 문제는 대개 모델이 시스템 프롬프트에 영리한 문장 하나를 더 필요로 했기 때문이 아닙니다. 문제는 모델이 올바른 정보를 보지 못했거나, 너무 많은 관련 없는 정보를 봤거나, 올바른 정보를 잘못된 형식으로 봤거나, 한 단계에서 다음 단계로 올바른 상태를 이어가지 못했기 때문입니다. 다시 말해, 문제는 프롬프트만이 아니었습니다. 문제는 전체 컨텍스트 파이프라인이었습니다.
그래서 컨텍스트 엔지니어링이라는 용어가 주목받게 되었습니다. 이 표현은 2025년 중반 Tobi Lütke와 Andrej Karpathy가 \"프롬프트 엔지니어링\"이 신뢰할 수 있는 LLM 시스템을 구축하는 데 실제로 필요한 작업을 과소평가한다고 주장하면서 AI 주류 논의에 등장했습니다.[1] 하지만 그 기저에 있는 학문은 이름보다 오래되었습니다. RAG, 도구 호출, 메모리 시스템, 요약, 또는 평가 루프를 구축해본 적이 있다면, 이미 컨텍스트 엔지니어링의 일부를 수행한 것입니다. 달라진 것은 마침내 전체 작업을 설명하는 이름이 생겼다는 점입니다.
가장 단순한 그림으로 표현하자면, 컨텍스트 엔지니어링은 외부 세계와 모델의 작업 메모리 사이에 있는 레이어입니다.
flowchart TD\n U[\"사용자 요청\"] --> CE[\"컨텍스트 엔진\"]\n\n I[\"지침 및 정책\"] --> CE\n R[\"검색된 지식\"] --> CE\n M[\"메모리 및 저장된 상태\"] --> CE\n T[\"도구 정의 및 결과\"] --> CE\n H[\"최근 대화 기록\"] --> CE\n\n CE --> W[\"모델 컨텍스트 윈도우\"]\n W --> L[\"LLM 추론 및 행동\"]\n L --> O[\"답변 또는 도구 호출\"]\n O --> S[\"새 메모리, 로그, 상태\"]\n S --> CE이것이 전부입니다.
모델은 추론 엔진입니다. 컨텍스트 엔진은 모델이 무엇을 추론할지 결정합니다.
이 용어가 공감을 얻는 이유 중 하나는 별도로 발전해온 여러 흐름을 하나로 묶기 때문입니다.
검색 증강 생성(RAG)은 모델이 추론 시점에 외부 지식에 접근해야 한다는 것을 가르쳐주었습니다.[2] ReAct는 모델이 도구를 호출하고, 결과를 관찰하고, 거기서 계속할 수 있을 때 추론과 행동이 더 잘 작동한다는 것을 보여주었습니다.[3] 메모리 연구는 장기 실행 어시스턴트에게 무한한 대화 기록 축적이 아닌 인덱싱, 검색, 읽기 전략이 필요하다는 것을 알려주었습니다.[4] 장문 컨텍스트 평가는 단순히 더 많은 토큰을 모델에 채워 넣는 것이 더 나은 작업 메모리를 제공하는 것과 같지 않다는 것을 보여주었습니다.[5][6][7]
이런 관점에서 보면, 컨텍스트 엔지니어링은 이러한 아이디어들을 대체하는 것이 아닙니다. 그것들을 아우르는 우산입니다.
그 우산이 중요한 이유는 현대 AI 시스템이 더 이상 고립된 프롬프트가 아니기 때문입니다. 다음 단계를 위한 임시 컨텍스트 윈도우에 지침, 문서, 구조화된 데이터, 도구 출력, 이전 상태를 조합하는 동적 시스템입니다. LangChain은 컨텍스트 엔지니어링을 LLM이 작업을 그럴듯하게 완료할 수 있도록 올바른 형식으로 올바른 정보와 도구를 제공하는 작업으로 정의하면서 이를 잘 설명했습니다.[8]
\"그럴듯하게 완료\"라는 표현이 많은 것을 담고 있습니다. 그것이 올바른 테스트입니다.
에이전트가 실패하면, 첫 번째 질문은 \"프롬프트를 어떻게 더 스마트하게 만들까?\"가 되어서는 안 됩니다.
첫 번째 질문은 \"실제로 모델이 성공하는 데 필요한 것을 제공했는가?\"여야 합니다.
프롬프트 엔지니어링은 여전히 중요합니다. 다만 더 큰 학문의 하위 집합이 되었을 뿐입니다.
예전 멘탈 모델은 이랬습니다:
| 프롬프트 엔지니어링 | 컨텍스트 엔지니어링 |
|---|---|
| 더 나은 지침 작성 | 전체 정보 환경 구축 |
| 단일 요청에 집중 | 다단계 시스템에 집중 |
| 주로 정적 | 동적이고 상태 유지 |
| 표현 최적화 | 선택, 구조, 메모리, 도구 최적화 |
| 단일 모델 호출 개선 | 전체 루프 개선 |
이 차이는 에이전트를 구축하는 순간 명확해집니다.
엔터프라이즈 소프트웨어를 위한 지원 에이전트를 구축한다고 가정해봅시다. 사용자가 \"왜 API 요청이 타임아웃되나요?\"라고 묻습니다.
프롬프트 관점에서만 생각한다면, 표현을 개선할 수 있습니다:
이것들은 괜찮은 개선입니다. 하지만 충분하지 않습니다.
실제 시스템 질문들은 더 어렵습니다:
이것이 컨텍스트 엔지니어링입니다.
프롬프트는 그 안의 한 항목일 뿐입니다.
실제로 컨텍스트는 눈에 보이는 프롬프트뿐만 아니라 추론 시점에 모델이 보는 모든 것을 포함합니다.[8][9]
일반적으로 다음을 의미합니다:
이것이 \"컨텍스트 윈도우 채우기\"라는 표현이 그토록 중심적이 된 이유입니다. 컨텍스트 윈도우는 단순히 텍스트가 들어가는 공간이 아닙니다. 모델의 임시 작업 메모리입니다. 그 안에 들어오는 모든 것이 주의를 두고 경쟁합니다.
그리고 경쟁이 핵심 단어입니다.
추가 토큰 하나하나는 단순히 추가 정보가 아닙니다. 추가적인 방해 요소이기도 합니다.
현재 AI 시장에서 가장 흔한 오해 중 하나는 더 큰 컨텍스트 윈도우가 컨텍스트 엔지니어링을 덜 중요하게 만들었다는 것입니다.
연구는 반대 방향을 가리킵니다.
Lost in the Middle은 모델이 종종 긴 컨텍스트를 불균등하게 사용하며, 관련 정보가 처음이나 끝 근처에 나타날 때 더 잘 수행하고 중간에 중요한 정보가 있을 때 더 나쁘게 수행한다는 것을 보여주었습니다.[5] Databricks의 장문 컨텍스트 RAG 연구는 더 많은 검색 문서를 추가하는 것이 도움이 될 수 있지만, 64k 토큰 이상에서 강력한 성능을 유지하는 최첨단 모델은 소수에 불과하다는 것을 발견했습니다.[6] Chroma의 Context Rot 보고서는 더 나아가 입력 길이가 늘어날수록, 특히 모호성과 방해 요소가 도입될 때 간단한 작업도 덜 신뢰할 수 있게 된다는 것을 보여주었습니다.[7]
이것이 많은 팀이 어렵게 배우는 부분입니다.
더 큰 윈도우는 선택의 필요성을 없애지 않습니다. 처음에는 잘못된 선택의 비용을 덜 명확하게 만들고, 나중에는 더 고통스럽게 만들 뿐입니다.
긴 프롬프트는 적어도 네 가지 다른 방식으로 실패할 수 있습니다:
이것이 컨텍스트 엔지니어링이 토큰을 최대화하는 것이 아닌 이유입니다. 컨텍스트 윈도우 내의 신호 밀도를 최대화하는 것입니다.
여기서 최근의 가장 좋은 아이디어 중 하나가 등장합니다.
Jason Liu는 고전적인 청크 기반 RAG 이후의 다음 단계가 \"가장 유사한 구절\"만 생각하는 것을 멈추고 검색 공간의 형태를 생각하기 시작하는 것이라고 주장했습니다.[10] 그의 프레임은 많은 팀이 이미 거치고 있는 진행 과정을 매핑하기 때문에 특히 유용합니다:
처음 세 가지는 검색되는 것의 개선입니다.
네 번째가 더 흥미롭습니다. 에이전트가 코퍼스 자체에 대해 배우는 것을 개선합니다.
패싯은 모델에게 주변 시야 같은 것을 제공합니다. 상위 몇 개의 청크만 반환하는 대신, 시스템은 집계된 메타데이터도 반환할 수 있습니다:
이것이 중요한 이유는 유사성 검색이 반드시 검사하기에 가장 중요한 것이 아닌 매칭하기 가장 쉬운 것에 편향되어 있기 때문입니다.[10] 검색 시스템은 잘 문서화된 해결된 인시던트를 과도하게 표면화하고 드물고 아직 열려 있는 인시던트를 과소 표면화할 수 있습니다. 법률 검색은 서명된 계약을 과도하게 표면화하고 실제로 주의가 필요한 서명되지 않은 계약을 숨길 수 있습니다. 패싯은 에이전트가 \"무엇이 매칭되었는지\"뿐만 아니라 \"근처에 무엇이 더 있는지\"를 볼 수 있도록 도와줍니다.
이것은 중요한 개념적 전환입니다.
RAG는 주로 검색에 관한 것이었습니다.
컨텍스트 엔지니어링은 점점 더 탐색에 관한 것이 되고 있습니다.
컨텍스트 엔지니어링을 구체적으로 만드는 가장 쉬운 방법은 실제로 수행하는 역할로 나누는 것입니다.
첫 번째 역할은 윈도우에 들어갈 자격이 있는 것을 결정하는 것입니다.
여기에는 검색, 순위 지정, 필터링, 소스 선택, 신선도 확인이 포함됩니다. 당연해 보이지만, 여전히 엄청난 양의 품질이 얻어지거나 잃어지는 곳입니다. BRIGHT 같은 벤치마크는 현실적인 검색이 표면적인 의미론적 매칭이 시사하는 것보다 훨씬 어렵다는 것을 보여줍니다.[11] 검색 품질이 약하면, 다운스트림 프롬프트 다듬기가 결과를 완전히 구할 수 없습니다.
선택은 단순히 \"관련 청크 찾기\"가 아닙니다. 다음을 의미합니다:
좋은 시스템은 종종 순진한 시스템보다 덜 검색하지만, 더 의도적으로 검색합니다.
두 번째 역할은 선택된 컨텍스트가 어떻게 표현되는지 결정하는 것입니다.
동일한 정보도 형식에 따라 도움이 되거나 쓸모없을 수 있습니다. Anthropic의 도구 사용 가이드는 이에 대해 명확합니다: 도구 설명과 인터페이스는 모델 동작을 강하게 형성합니다.[9] 장문 컨텍스트 프롬프팅 가이드는 XML 태깅, 소스 레이블링, 명확하게 분리된 문서 섹션에 대해 유사한 권장 사항을 제시합니다.[12]
실제로 구조는 다음을 의미합니다:
짧고 잘 레이블된 결과가 거대한 JSON 덩어리보다 종종 더 나은 성능을 보입니다.
세 번째 역할은 중요한 것을 파괴하지 않고 컨텍스트를 줄이는 것입니다.
여기서 많은 에이전트 시스템이 훨씬 더 좋아지거나 훨씬 더 나빠집니다.
압축은 다음을 의미할 수 있습니다:
OpenAI의 프롬프트 캐싱 문서는 프롬프트 순서가 경제적으로도 인지적으로도 중요하다는 것을 보여줍니다: 정적 공유 접두사는 캐시 히트가 정확한 접두사 재사용에 의존하기 때문에 앞에 배치될 때 더 저렴하고 빠릅니다.[13] OpenAI의 새로운 Responses API의 압축 작업은 장기 실행 에이전트 기록을 윈도우가 가득 차기 전에 더 토큰 효율적인 표현으로 압축해야 하는 것으로 처리함으로써 같은 아이디어를 더 발전시킵니다.[14]
압축은 선택 사항이 아닙니다. 유일한 질문은 의도적으로 할 것인지, 아니면 컨텍스트 윈도우가 스스로 저하되도록 내버려 둘 것인지입니다.
네 번째 역할은 현재 턴을 넘어 무엇이 지속되어야 하는지 결정하는 것입니다.
여기서 많은 팀이 같은 실수를 합니다: 메모리를 대화 기록 보존과 혼동합니다.
하지만 좋은 메모리는 \"모든 것을 영원히 유지\"가 아닙니다. LongMemEval은 장기 메모리를 세 단계 문제로 프레임화합니다: 인덱싱, 검색, 읽기.[4] 이것이 올바른 사고 방식입니다. 메모리 시스템은 모델이 완전한 과거에 빠지게 하는 것이 아니라 올바른 순간에 올바른 이전 사실을 복구하도록 도와야 합니다.
이것은 유용한 구분으로 이어집니다:
모든 것이 작업 메모리에 남아 있으면, 모델은 산만해집니다.
모든 것이 밀려나면, 모델은 연속성을 잃습니다.
컨텍스트 엔지니어링은 각 레이어에 무엇이 속하는지 결정합니다.
다섯 번째 역할은 도구를 모델이 이해할 수 있게 만드는 것입니다.
이것은 학문에서 과소평가된 부분입니다. 도구 표면은 단순히 소프트웨어 API 설계가 아닙니다. 컨텍스트 설계이기도 합니다.
모델은 다음을 이해해야 합니다:
이것이 도구 설명이 그토록 중요한 이유입니다.[9] Jason Liu의 도구 결과에 대한 강조가 중요한 이유이기도 합니다.[10] 도구의 출력은 단순히 현재 쿼리에 답하는 것이 아닙니다. 에이전트에게 다음 쿼리에 대해 어떻게 생각해야 하는지 가르칩니다.
도구 표면이 MCP 같은 프로토콜을 통해 표준화될 때, 이것은 더욱 중요해집니다. MCP는 도구, 리소스, 프롬프트를 LLM 애플리케이션에 연결하기 쉽게 만들지만, 어떤 정보가 표면화되어야 하는지, 어떻게 필터링되어야 하는지, 또는 얼마나 많은 것이 다음 모델 호출에 주입되어야 하는지는 결정하지 않습니다.[15] 프로토콜은 배관입니다. 컨텍스트 엔지니어링은 여전히 기술입니다.
여섯 번째 역할은 컨텍스트를 공유하지 않을 때를 결정하는 것입니다.
이것은 장난감 데모와 프로덕션 에이전트 사이의 가장 큰 차이 중 하나입니다.
때로는 올바른 답이 더 큰 공유 프롬프트가 아닙니다. 격리된 범위를 가진 여러 개의 더 작은 프롬프트입니다.
Anthropic의 멀티 에이전트 연구 시스템이 좋은 예입니다.[16] 그들의 서브에이전트는 별도의 컨텍스트 윈도우로 병렬로 실행되어, 모든 중간 세부 사항으로 서로를 오염시키지 않고 문제의 다른 분기를 탐색하는 데 도움이 됩니다. LangChain은 \"격리\"라는 유사한 패턴을 설명합니다: 때로는 에이전트 신뢰성을 향상시키는 가장 좋은 방법이 컨텍스트를 축적하는 것이 아니라 분할하는 것입니다.[17]
이것이 중요한 이유는 공유 컨텍스트에 숨겨진 비용이 있기 때문입니다. 경로 의존성을 만듭니다. 하나의 나쁜 분기가 다음 단계, 그 다음 단계, 그 다음 단계에 영향을 미칠 수 있습니다.
격리는 폭발 반경을 제한하는 방법입니다.
2025년에 컨텍스트 엔지니어링은 주로 사람들이 이미 느끼고 있던 문제에 대한 유용한 이름이었습니다. 2026년에는 아키텍처로 굳어지기 시작하고 있습니다.
첫 번째 큰 변화는 빌더들이 지속적인 상태를 원시 컨텍스트 윈도우 외부로 이동시키고 있다는 것입니다. Anthropic의 컨텍스트 편집 및 메모리 도구는 작업 윈도우에서 활성 상태로 유지되는 것과 세션 간에 지속되어야 하는 것을 명시적으로 분리합니다.[18] OpenAI의 2026년 1월 개인화 쿡북은 다른 형태로 같은 움직임을 보여줍니다: 실행 간에 지속되고 각 실행 시작 시 작업 메모리에 의도적으로 다시 주입되는 구조화된 상태 객체.[19] OpenAI의 Responses API는 장기 실행 에이전트 루프가 모든 팀이 처음부터 사용자 정의 요약 하위 시스템을 구축할 필요 없도록 네이티브 압축으로 이것을 한 단계 더 발전시킵니다.[14]
Anthropic의 Managed Agents는 기본 패턴을 특별히 명확하게 만듭니다: 세션은 모델의 컨텍스트 윈도우가 아닙니다.[20] 이것이 2026년의 중요한 아이디어입니다. 윈도우는 일시적인 작업 메모리입니다. 세션 로그는 지속적인 객체입니다. 하네스는 그 지속적인 컨텍스트를 다음 모델 호출에 어떻게 슬라이스하고, 압축하고, 재수화할지 결정합니다.
두 번째 변화는 검색이 더 적시에 이루어지고 더 인터페이스 네이티브가 되고 있다는 것입니다. 가능한 모든 관련 토큰을 앞에 로드하는 대신, 팀들은 에이전트에게 이미 작동 방법을 알고 있는 검색 표면을 제공하고 있습니다. Mintlify의 ChromaFs가 좋은 예입니다: 문서 검색을 위해 전체 샌드박스를 부팅하는 대신, `ls`, `cat`, `grep`으로 탐색 가능한 가상 파일시스템으로 문서를 제공하여 p90 세션 생성을 약 46초에서 약 100밀리초로 줄였습니다.[21] Turso의 AgentFS는 같은 직관을 일반 에이전트 실행으로 밀어붙입니다: 이식 가능한 단일 파일 스토리지와 내장 감사 기능을 갖춘 copy-on-write 파일시스템 추상화.[22]
세 번째 변화는 컨텍스트 그래프가 단순한 은유가 아닌 구현 방향이 되고 있다는 것입니다. Foundation Capital의 논문이 이 용어를 가시화했지만, 더 강력한 주장은 아키텍처적입니다: 에이전트가 실행 경로에 있을 때, 단순히 최종 출력을 내보내는 것이 아니라 결정 추적을 지속적인 아티팩트로 캡처할 수 있습니다.[26][27] Graphiti 같은 오픈 소스 시스템과 Zep 같은 상업 플랫폼은 이것을 유효성 윈도우, 출처 에피소드, 의미론, 키워드, 그래프 구조에 걸친 하이브리드 검색을 갖춘 시간적 컨텍스트 그래프로 운영화합니다.[23] TrustGraph는 컨텍스트를 버전화된 아티팩트로 처리하는 관련 접근 방식을 취합니다: 그래프, 임베딩, 증거, 정책이 빌드 출력처럼 승격되거나 롤백될 수 있는 이식 가능한 \"컨텍스트 코어\"로 번들됩니다.[24][25]
네 번째 변화는 컨텍스트 엔지니어링이 이제 플랫폼 블로그뿐만 아니라 실제 소프트웨어 실무에서 가시화되고 있다는 것입니다. 컨텍스트 엔지니어링에 관한 2026년 MSR 논문은 466개의 저장소를 연구하여 `AGENTS.md` 같은 AI 컨텍스트 파일이 확산되고 있지만 아직 안정적인 콘텐츠 구조가 없다는 것을 발견했습니다.[28] 이것이 중요한 이유는 이론에서 운영 아티팩트로의 이동을 표시하기 때문입니다. 컨텍스트는 더 이상 런타임에 추론되는 것만이 아닙니다. 소프트웨어 수명 주기의 일부로 작성되고, 버전화되고, 검토되고, 마이닝되고 있습니다.
2026년 멘탈 모델을 한 그림으로 표현하면 다음과 같습니다:
flowchart LR\n E[\"세션 로그 / 이벤트\"] --> A[\"컨텍스트 어셈블러\"]\n F[\"파일, 문서, 도구\"] --> A\n G[\"컨텍스트 그래프 / 메모리\"] --> A\n P[\"정책 및 AGENTS.md\"] --> A\n\n A --> W[\"작업 컨텍스트 윈도우\"]\n W --> X[\"에이전트 행동\"]\n\n X --> E\n X --> G이것은 \"프롬프트 + 벡터 검색\"과는 매우 다른 아키텍처입니다.
이 대화가 혼탁해지는 한 가지 이유는 사람들이 컨텍스트 엔지니어링과 컨텍스트 그래프를 같은 의미인 것처럼 사용하기 때문입니다. 그렇지 않습니다.
컨텍스트 엔지니어링은 더 넓은 학문입니다. 다음 컨텍스트 윈도우에 무엇이 들어가는지, 무엇이 제외되는지, 무엇이 압축되는지, 무엇이 필요에 따라 검색되는지를 결정하는 작업입니다.
컨텍스트 그래프는 그 더 큰 시스템 내의 하나의 가능한 장기 메모리 기판입니다.
이 구분이 중요한 이유는 모든 유용한 에이전트가 컨텍스트 그래프를 필요로 하지 않기 때문입니다. 대부분 정적인 콘텐츠에 대한 문서 어시스턴트는 좋은 검색, 도구 설계, 압축이 필요할 수 있지만 그래프는 필요하지 않을 수 있습니다. 코딩 에이전트는 저장소 지침, 지속적인 세션 로그, 파일시스템 추상화로 놀랍도록 멀리 갈 수 있습니다.[20][21][22][28]
컨텍스트 그래프는 문제가 네 가지 특성을 가질 때 매력적이 됩니다:
이것이 제 견해로는 컨텍스트 그래프의 가장 좋은 정의가 \"AI를 위한 그래프 데이터베이스\"가 아닌 이유입니다. 그것은 선례의 지속적인 표현입니다.
이것이 또한 결정 추적이 그토록 중요한 이유입니다. Foundation Capital의 프레임이 여기서 유용합니다: 규칙은 에이전트에게 일반적으로 무엇이 일어나야 하는지 알려줍니다; 결정 추적은 실제 제약과 실제 예외를 가진 특정 사례에서 무엇이 일어났는지 알려줍니다.[26] 그 추적이 엔티티와 시간에 걸쳐 연결되면, 일반적인 메모리보다 훨씬 더 가치 있는 것을 얻게 됩니다. 검색 가능한 판단을 얻게 됩니다.
오늘날 진지한 컨텍스트 엔지니어링 스택을 구축한다면, 그래프부터 시작하지 않을 것입니다. 인터페이스와 승격 규칙부터 시작할 것입니다.
모든 행동, 도구 결과, 관찰, 중요한 중간 아티팩트는 추가 전용 세션 로그 또는 이벤트 스토어에 저장되어야 합니다. 이것이 복구 가능한 컨텍스트 객체입니다.[14][20]
활성 컨텍스트 윈도우를 진실의 소스와 혼동하지 마십시오.
윈도우는 추론을 위한 것입니다.
세션은 복구, 재생, 디버깅, 선택적 재수화를 위한 것입니다.
어셈블러는 다음을 명시적으로 관리해야 합니다:
이것이 모델이 지금 무엇을 보는지 결정하는 레이어입니다. 관찰 가능하고, 테스트 가능하며, 변경하기 쉬워야 합니다.[18][19][14]
모델에게 먼저 가벼운 핸들을 제공하십시오: 파일 경로, 객체 ID, URL, 쿼리 템플릿, 티켓 ID, 인시던트 ID. 그런 다음 필요할 때만 세부 사항을 가져오도록 하십시오.[9][18][21]
여기서 파일시스템, MCP 도구, 검색 API, 구조화된 쿼리가 거대한 상위 K 덤프보다 더 가치 있게 됩니다.
모든 것이 메모리가 되어서는 안 됩니다.
네 가지 클래스의 아티팩트를 승격할 것입니다:
다른 모든 것은 승격을 받을 자격이 있다는 것이 증명될 때까지 세션 로그에 남아 있어야 합니다.
이것이 많은 팀이 역전시키는 부분입니다.
그래프는 그래프 형태의 원시 대화 기록이 되어서는 안 됩니다. 세션 위와 실시간 어셈블리 아래에 있는 큐레이션된 레이어여야 합니다:
승격 단계를 건너뛰면, 그래프는 쓰레기 더미가 됩니다.
승격을 올바르게 하면, 그래프는 조직이 실제로 추론하는 방식의 메모리가 됩니다.[23][26]
2026년까지, 가장 유망한 아이디어 중 하나는 컨텍스트를 버전화된 아티팩트로 처리하는 것입니다. 소프트웨어 프로젝트에서 이것은 `AGENTS.md` 및 기타 저장소별 컨텍스트 파일로 나타납니다.[28] 그래프 네이티브 시스템에서는 컨텍스트 코어로 나타납니다: 온톨로지, 그래프 구조, 임베딩, 출처, 검색 정책의 이식 가능한 번들.[24][25]
이것이 중요한 이유는 컨텍스트 변경이 코드 변경과 동일한 운영 규율이 필요하기 때문입니다:
컨텍스트가 아티팩트가 되면, 거버넌스가 가능해집니다.
둘 다 필요합니다:
이것들은 같은 것이 아닙니다.
다음을 알고 싶습니다:
이 질문들에 답할 수 없다면, 여전히 어둠 속에서 프롬프트를 디버깅하고 있는 것입니다.
자신의 시스템이 어디에 있는지 평가하려면, 이 성숙도 모델이 추상적인 정의보다 더 유용합니다.
시스템 프롬프트, 사용자 메시지, 그리고 아마도 몇 가지 예시가 있습니다.
좁은 작업에서는 놀랍도록 잘 작동할 수 있습니다. 작업이 새로운 지식, 지속성, 또는 도구를 필요로 할 때 빠르게 무너집니다.
런타임에 문서를 추가합니다.
많은 팀이 여기서 멈춥니다. 또한 많은 팀이 순진한 청킹, 순위 지정, 컨텍스트 팽창의 한계를 보기 시작하는 곳이기도 합니다.
이제 기록, 도구 결과, 메모리, 형식을 의도적으로 관리합니다.
시스템이 더 이상 단순히 프롬프트 플러스 검색이 아니라 여러 형태의 컨텍스트를 동적으로 조합하기 때문에, \"컨텍스트 엔지니어링\"이 유용한 용어가 되는 첫 번째 레벨입니다.
시스템은 작업에 따라 컨텍스트를 구축하는 방법을 변경합니다.
다음을 할 수 있습니다:
이 시점에서 컨텍스트 구성은 애플리케이션의 핵심 로직의 일부입니다.
시스템은 컨텍스트를 일급 엔지니어링 표면으로 처리합니다.
다음을 갖추고 있습니다:
이것이 가장 강력한 프로덕션 시스템이 향하고 있는 곳입니다.
전체 학문을 체크리스트로 줄여야 한다면, 다음과 같을 것입니다:
이 중 어느 것도 화려하지 않습니다. 그것이 바로 중요한 이유입니다.
프롬프트 엔지니어링은 지름길처럼 들렸기 때문에 인기를 얻었습니다.
컨텍스트 엔지니어링은 실제 작업을 설명하기 때문에 중요합니다.
AI의 중심이 이동하고 있습니다.
프론티어 질문은 한때 이랬습니다: 모델이 얼마나 스마트한가?
응용 질문은 점점 더 이렇게 되고 있습니다: 모델이 행동해야 하기 전에 무엇을 볼 수 있는가?
이것은 다른 엔지니어링 문제입니다. 단일 프롬프트보다 시스템 설계에 관한 것입니다. 표현보다 정보 흐름에 관한 것입니다. 단발성 출력 품질보다 에이전트가 시간이 지남에 따라 신뢰할 수 있는지에 관한 것입니다.
이것이 컨텍스트 엔지니어링이 학문으로서 계속 성장할 이유입니다. 모델이 더 좋아질수록, 남은 실패는 더 컨텍스트 실패처럼 보입니다. 누락된 상태. 잘못된 도구. 나쁜 검색. 부풀어 오른 기록. 나쁜 형식. 충돌하는 증거. 약한 메모리. 무한 루프.
아이러니는 이것이 AI 시스템을 고전적인 소프트웨어처럼 덜이 아니라 더 느끼게 만든다는 것입니다. 우리는 파이프라인, 인터페이스, 상태 기계, 메모리 계층, 캐시, 관찰 가능성 레이어를 구축하는 것으로 돌아왔습니다. 새로운 점은 이 모든 조각들이 이제 확률적 추론 엔진을 위해 존재한다는 것입니다.
이름은 새로울 수 있습니다. 방향은 그렇지 않습니다.
신뢰할 수 있는 AI 시스템은 컨텍스트를 일급 제품 표면으로 처리하는 팀에 의해 구축될 것입니다.
다른 모든 사람들은 계속해서 모델이 불안정하다고 말할 것입니다.
참고문헌:
[1] Simon Willison. (2025, June 27). Context engineering.
[2] Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.
[3] Yao, S. et al. (2023). ReAct: Synergizing Reasoning and Acting in Language Models.
[4] Wu, D. et al. (2025). LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory.
[5] Liu, N. F. et al. (2023). Lost in the Middle: How Language Models Use Long Contexts.
[6] Leng, Q. et al. (2024). Long Context RAG Performance of Large Language Models.
[8] LangChain. (2025, June 23). The rise of \"context engineering\".
[9] Anthropic. How to implement tool use.
[10] Jason Liu. (2025, August 27). Beyond Chunks: Why Context Engineering is the Future of RAG.
[12] Anthropic. Long context prompting tips.
[15] Model Context Protocol. What is the Model Context Protocol (MCP)?
[16] Anthropic. (2025, June 13). How we built our multi-agent research system.
[17] LangChain. (2025, July 2). Context Engineering.
[18] Anthropic. (2025, September 29). Managing context on the Claude Developer Platform.
[20] Anthropic. Scaling Managed Agents: Decoupling the brain from the hands.
[21] Mintlify. (2026, March 24). How we built a virtual filesystem for our Assistant.
[22] Turso. AgentFS.
[23] Zep. Graphiti: Build Real-Time Knowledge Graphs for AI Agents.
[24] TrustGraph. The context development platform.
[25] TrustGraph. Working with Context Cores.
[26] Gupta, J., and Garg, A. (2025, December 22). AI's trillion-dollar opportunity: Context graphs.
[27] Garg, A. (2026, January 16). Why context graphs are the missing layer for AI.
", "source_hash": "sha256:352e42d5b8ff71176c26e2e3f9853217033b811bae4f0beaef2cc91e2401caa9", "model": "claude-sonnet-4-6", "generated_at": "2026-04-23T20:56:46.301034+00:00" }