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