Context Engineering: From Prompts to Corporate Multi-Agent Architecture

이 논문은 프롬프트 엔지니어링의 한계를 넘어 기업용 다중 에이전트 시스템의 성숙도를 위한 새로운 패러다임으로 '컨텍스트 엔지니어링'을 제안하고, 이를 의도 엔지니어링과 명세 엔지니어링과 함께 에이전트 엔지니어링의 피라미드 성숙도 모델로 정립합니다.

핵심

이 논문은 인공지능 (AI) 이 단순한 '대화가 가능한 챗봇'에서 스스로 일을 해내는 '자율 에이전트'로 변모하면서, 우리가 AI 를 다루는 방식이 어떻게 근본적으로 바뀌어야 하는지를 설명합니다.

저자 베라 비슈냐코바는 이 변화를 4 단계의 피라미드로 정리하며, 단순히 "좋은 질문을 하는 법"을 넘어선 새로운 공학 분야들이 필요하다고 주장합니다.

이 복잡한 내용을 일상적인 비유로 쉽게 풀어보겠습니다.

---

🏗️ 핵심 비유: AI 에이전트는 '자율주행 택시'입니다

과거의 AI(챗봇) 는 수동 조종기였습니다. 사용자가 "어디로 가?"라고 말하면 AI 가 길을 알려주고, 다음에 "차량 상태는 어때?"라고 물으면 대답했습니다. 하지만 새로운 AI 에이전트는 자율주행 택시입니다. 목적지만 말해주면, 스스로 경로를 짜고, 신호를 보고, 교통상황을 파악하며 목적지까지 가려고 합니다.

이런 자율주행 택시를 안전하게 운영하려면 단순히 "가자"라고 외치는 것만으로는 부족합니다. 논문의 4 단계 피라미드는 이 자율주행 시스템을 구축하는 4 가지 필수 단계입니다.

1 단계: 프롬프트 엔지니어링 (Prompt Engineering) = "명확한 출발지 입력"

• 과거의 방식: "여기서 저기까지 가줘"라고 말하면 됩니다.
• 비유: 택시 기사에게 "서울역으로 가줘"라고 명확하게 말하는 기술입니다.
• 한계: 이 기술은 여전히 중요하지만, 택시가 20 번의 복잡한 경유지를 거쳐야 하거나, 갑자기 도로가 막히면 우회해야 하는 상황에서는 부족합니다. 단순히 "가자"라고만 말해서는 복잡한 미션을 수행할 수 없습니다.

2 단계: 컨텍스트 엔지니어링 (Context Engineering) = "운전석의 정보 시스템 설계"

• 새로운 문제: 자율주행 택시가 100km 를 달리다 보면, 처음에 들었던 정보만으로는 길을 잃거나, 과거의 잘못된 기억 때문에 엉뚱한 길로 들어설 수 있습니다. (예: "어제 비가 왔으니 오늘도 비가 올 거야"라고 착각하는 것)
• 해결책: 컨텍스트 엔지니어링은 "택시 운전석에 어떤 정보가 들어갈지, 어떤 정보는 버릴지, 어떤 정보는 기억할지"를 설계하는 것입니다.
  • 관련성: 지금 필요한 정보만 보여줍니다. (불필요한 뉴스는 차단)
  • 격리: 다른 승객의 비밀은 다른 운전사에게 보이지 않게 합니다.
  • 경제성: 너무 많은 정보를 보여주면 연료 (비용) 가 많이 듭니다.
• 핵심: "무엇을 볼 것인가 (What the agent sees)"를 설계하는 것입니다.

3 단계: 인텐트 엔지니어링 (Intent Engineering) = "운전사의 가치관과 목표 설정"

• 새로운 문제: 정보가 완벽해도, 택시 기사가 "가장 빠른 길"만 쫓다가 승객의 안전을 해치거나, "가장 저렴한 길"만 쫓다가 승객이 원하는 고급 경로를 무시할 수 있습니다.
• 해결책: 인텐트 엔지니어링은 "무엇을 위해 운전하는가 (What the agent wants)"를 정의하는 것입니다.
  • "가장 빠른 것"보다 "안전한 것"이 중요할까요?
  • "비용 절감"이 최우선인가, "고객 만족"이 최우선인가?
• 실제 사례 (클라르나): 한 기업이 AI 고객 상담을 도입했는데, 비용만 아끼려고 너무 무뚝뚝하게 대답해서 고객들이 화를 냈습니다. 정보는 충분했지만, '고객을 아끼는 마음 (의도)'이 설계되지 않았기 때문입니다.
• 핵심: "무엇을 추구할 것인가"를 설계하는 것입니다.

4 단계: 스펙시피케이션 엔지니어링 (Specification Engineering) = "전국 택시 회사의 운영 매뉴얼"

• 새로운 문제: 택시가 한 대만 있는 게 아니라, 전국에 1 만 대가 있다면? 각기 다른 운전사가 제멋대로 운전하면 회사가 망합니다.
• 해결책: 스펙시피케이션 엔지니어링은 "전국 모든 택시가 지켜야 할 법과 규칙"을 기계가 읽을 수 있는 언어로 만드는 것입니다.
  • PDF 로 된 회사 규정, 구두 약속을 모두 컴퓨터가 이해하는 '법전'으로 바꿉니다.
  • 모든 AI 에이전트가 같은 기준으로, 같은 가치를 가지고 행동하도록 만듭니다.
• 핵심: "전체 시스템이 어떻게 움직여야 하는지"를 법으로 만드는 것입니다.

---

💡 이 논문이 우리에게 주는 교훈

1. 질문하는 기술만으로는 부족합니다: 예전처럼 "좋은 질문"만 던진다고 해서 AI 가 복잡한 일을 잘해내는 시대가 지났습니다. 이제는 AI 가 어떤 정보를 보고, 어떤 가치를 가지고, 어떤 규칙 아래서 일할지 설계해야 합니다.
2. 통제권은 설계자에게 있습니다:
   • **정보 (컨텍스트)**를 통제하면 AI 의 행동을 통제할 수 있습니다.
   • **목표 (인텐트)**를 통제하면 AI 의 전략을 통제할 수 있습니다.
   • **규칙 (스펙)**을 통제하면 AI 의 규모를 통제할 수 있습니다.
3. 유혹을 경계하라: "노코드 (No-code)" 도구로 AI 를 쉽게 만들 수 있다고 해서, 설계 없이 막 만들어 쓰면 위험합니다. 마치 설계도 없이 지은 건물이 무너지듯, 의도나 규칙이 없는 AI 는 기업에 큰 재앙을 부를 수 있습니다.

📝 한 줄 요약

"AI 를 단순히 대화하는 친구로 보지 말고, 자율주행 택시처럼 생각하세요. 그리고 그 택시를 안전하게 운행하게 하려면, 운전석의 정보 (컨텍스트), 운전사의 가치관 (인텐트), 그리고 **전체 회사의 법규 (스펙)**를 꼼꼼하게 설계해야 합니다."

이 논문은 AI 시대의 성공이 "누가 더 좋은 질문을 하느냐"가 아니라, **"누가 더 잘 설계된 시스템을 만들느냐"**에 달려 있음을 알려줍니다.

기술 요약

이 논문은 2026 년 시점을 가정하여, AI 시스템이 상태 없는 (stateless) 챗봇에서 자율적 멀티 스텝 에이전트로 진화함에 따라 기존의 '프롬프트 엔지니어링 (Prompt Engineering, PE)'만으로는 부족하다는 문제를 제기하고, 이를 해결하기 위한 새로운 엔지니어링 패러다임을 제안합니다.

저자 Vera V. Vishnyakova 는 **컨텍스트 엔지니어링 (Context Engineering, CE)**을 독립적인 학문으로 정립하고, 이를 기반으로 **의도 엔지니어링 (Intent Engineering, IE)**과 **명세 엔지니어링 (Specification Engineering, SE)**을 추가한 4 단계 누적 성숙도 피라미드 (Cumulative Four-Level Pyramid) 모델을 제시합니다.

아래는 논문의 기술적 요약입니다.

---

1. 문제 정의 (Problem Statement)

• 프롬프트 엔지니어링의 한계: 기존 PE 는 "질문 - 응답"의 단일 사이클에는 효과적이지만, 외부 API 를 호출하고 20~50 단계에 걸친 작업을 자율적으로 수행하는 에이전트 (Agent) 환경에서는 설계되지 않았습니다.
• 에이전트 아키텍처의 복잡성: LLM 은 단순히 지능형 엔진일 뿐이며, 실제 에이전트는 오케스트레이터, 도구 (Tools), 메모리, 정책 (Policies) 으로 구성된 외부 시스템입니다. 이 환경에서 단일 프롬프트로는 에이전트의 의사결정 환경을 통제할 수 없습니다.
• 주요 기술적 결함:
  • 장기적 성능 저하 (Degradation): 긴 작업 흐름에서 컨텍스트 창이 불필요한 데이터로 채워지며 모델이 핵심 정보에서 이탈함 (Lost-in-the-middle).
  • 컨텍스트 오염 (Contamination): 이전 단계의 도구 출력이나 다른 에이전트의 정보가 다음 단계의 결정에 불필요하게 유입됨.
  • 비용의 기하급수적 증가: 컨텍스트가 누적될수록 토큰 비용과 지연 시간이 비선형적으로 증가하여 생산성 확보가 어려움.
  • 의도 부재 (Intent Deficit): 에이전트가 모든 데이터를 정확히 파악하더라도 기업의 전략적 목표 (예: 비용 절감 vs 고객 충성도) 를 최적화하지 못해 브랜드 가치를 훼손하는 사례 발생 (Klarna 사례).

2. 방법론 및 프레임워크 (Methodology & Framework)

저자는 다양한 벤더 아키텍처 (Google ADK, Anthropic, LangChain), 학술 연구 (ACE 프레임워크, Tomašev et al.), 그리고 Deloitte/KPMG 의 기업 조사 데이터를 종합하여 에이전트 엔지니어링의 4 단계 성숙도 피라미드를 제안합니다. 각 단계는 이전 단계를 대체하는 것이 아니라, 하부 기반으로서 누적됩니다.

4 단계 피라미드 모델

1. 프롬프트 엔지니어링 (Prompt Engineering, PE):
   • 역할: 단일 쿼리 작성 및 모델 응답 최적화.
   • 특징: "어떻게 질문할 것인가"에 집중. 에이전트 환경에서는 기초 기술로 남지만, 자율 에이전트 운영을 위한 충분 조건은 아님.
2. 컨텍스트 엔지니어링 (Context Engineering, CE):
   • 역할: 에이전트의 **정보적 환경 (Operating System)**을 설계, 구조화, 관리.
   • 핵심: 에이전트가 행동하는 순간 "무엇을 알고, 무엇을 보고, 무엇을 기억하는가"를 제어.
   • 기술적 접근: JIT(Just-In-Time) 지식 물류, 컨텍스트 파이프라인 (저장 → 처리 → 컴파일), 메모리 관리.
3. 의도 엔지니어링 (Intent Engineering, IE):
   • 역할: 조직의 목표, 가치, 트레이드오프 계층 구조를 에이전트 인프라에 인코딩.
   • 핵심: "에이전트가 무엇을 추구해야 하는가"를 정의.
   • 기술적 접근: 보상 해킹 (Reward Hacking) 방지, 주 - 대리인 문제 해결, 전략적 정렬.
4. 명세 엔지니어링 (Specification Engineering, SE):
   • 역할: 기업 전체의 정책, 품질 표준, 운영 절차를 기계 판독 가능한 형식으로 변환.
   • 핵심: "기업이 규모 확장 시 무엇을 요구하는가"를 정의.
   • 기술적 접근: 에이전트 헌법 (Constitutional AI), ERP 수준의 프로세스 표준화, 대규모 멀티 에이전트 시스템 (MAS) 의 일관성 유지.

3. 주요 기여 및 기술적 발견 (Key Contributions)

A. 컨텍스트 엔지니어링의 5 가지 품질 기준

생산 수준의 에이전트 컨텍스트가 충족해야 할 5 가지 기준을 제시했습니다.

1. 관련성 (Relevance): 현재 단계에 필요한 최소한의 정보만 제공 (과도한 컨텍스트는 성능 저하 유발).
2. 충분성 (Sufficiency): 추측 없이 결정을 내릴 수 있는 모든 데이터 포함 (할루시네이션 방지).
3. 격리 (Isolation): 멀티 에이전트 시스템에서 하위 에이전트 간 정보 누출 방지 (권한 축소 원칙 적용).
4. 경제성 (Economy): 토큰 비용과 지연 시간을 최소화하기 위한 압축, 캐싱, 선택적 로딩.
5. 추적 가능성 (Provenance): 모든 컨텍스트 요소의 출처, 신뢰도, 타임스탬프 추적 (감사 및 디버깅 가능).

B. 컨텍스트 부패 (Context Rot) 분류

Breunig(2025) 의 연구를 인용하여 컨텍스트가 어떻게 붕괴하는지 4 가지 모드로 분류했습니다.

• 중독 (Poisoning): 오류가 컨텍스트에 유입되어 후속 단계에서 재생산됨.
• 산만 (Distraction): 컨텍스트가 과도하게 커져 모델이 훈련된 지식이 아닌 과거 패턴에 의존함.
• 혼란 (Confusion): 관련 없는 정보가 응답 품질을 저하시킴.
• 충돌 (Clash): 대화 중 서로 모순되는 데이터가 축적되어 논리적 오류 발생.

C. 메모리 아키텍처의 재정의

에이전트 메모리를 단순한 저장소가 아닌 설계 대상 (Design Object) 으로 재정의했습니다.

• 4 가지 메모리 유형: 작업 메모리 (Working), 일화적 메모리 (Episodic), 의미적 메모리 (Semantic), 절차적 메모리 (Procedural).
• 하이브리드 아키텍처: 클라우드 LLM(오케스트레이터) 과 엣지 SLM(실행) 간의 메모리 분할 및 데이터 주권 (Data Sovereignty) 문제 해결.

D. Klarna 사례 분석 (Dual Deficit)

Klarna 의 AI 에이전트 실패 사례를 컨텍스트 결핍과 의도 결핍의 이중적 관점에서 분석했습니다.

• 기술적으로 정확한 데이터 (컨텍스트) 를 제공받았으나, 기업 의도 (고객 충성도 vs 비용 절감) 가 인코딩되지 않아 전략적 실패를 겪음.
• 이는 "에이전트의 컨텍스트를 통제하는 자가 행동을 통제하고, 의도를 통제하는 자가 전략을 통제한다"는 결론으로 이어짐.

4. 결과 및 시사점 (Results & Implications)

• 기업 거버넌스 격차: Deloitte(2026) 조사에 따르면 75% 의 기업이 에이전트 AI 도입을 계획하지만, 84% 는 AI 에 따른 역할 재설계를 하지 않았으며 21% 만 성숙한 거버넌스 모델을 보유함. 이는 기술 도입 속도가 거버넌스 (특히 명세 엔지니어링) 를 따라가지 못함을 의미.
• 경제적 타당성: 컨텍스트 엔지니어링은 단순 부가 기능이 아닌, 에이전트 시스템의 단위 경제 (Unit Economics) 를 결정하는 핵심 요소임. (압축 및 캐싱을 통해 5~10 배의 비용 절감 가능).
• 인간 역할의 변화: 사용자는 단순한 프롬프트 작성자에서 에이전트의 메모리 관리자이자 의도 설계자로 역할이 이동. "질문하는 기술"에서 "에이전트가 무엇을 알고 있는지 추적하고 통제하는 기술"로 전환 필요.
• 규모 확장 (Scale): 개별 에이전트 수준을 넘어 기업 전체의 멀티 에이전트 시스템을 운영하려면, 암묵적 지식을 명시적 명세 (Specification) 로 변환하는 과정이 필수적임.

5. 의의 (Significance)

이 논문은 AI 에이전트 개발을 단순한 프롬프트 작성의 예술 (Art) 에서 체계적인 **시스템 엔지니어링 (Engineering)**으로 격상시켰습니다.

1. 학문적 기여: 프롬프트 엔지니어링을 대체하는 것이 아니라, 이를 하부 기반으로 포함하는 **누적 성숙도 모델 (Pyramid)**을 정립하여 에이전트 엔지니어링의 표준화된 프레임워크를 제시했습니다.
2. 실무적 기여: 기업이 에이전트를 생산 환경에 도입할 때 직면하는 '컨텍스트 오염', '비용 폭증', '전략적 불일치' 문제를 해결하기 위한 구체적인 엔지니어링 기준 (5 가지 품질 기준, 4 단계 메모리 관리 등) 을 제공했습니다.
3. 거버넌스 제언: 기술적 아키텍처와 기업 전략 (의도, 명세) 의 통합 없이는 대규모 에이전트 시스템이 실패할 수밖에 없음을 경고하며, 명세 엔지니어링을 기업 차원의 핵심 역량으로 강조했습니다.

결론적으로, 이 논문은 "누가 에이전트의 컨텍스트를 통제하느냐가 행동을 결정하고, 의도를 통제하느냐가 전략을 결정하며, 명세를 통제하느냐가 규모를 결정한다"는 핵심 명제를 통해, 2026 년 이후의 AI 에이전트 생태계에서 기업이 나아가야 할 기술적·전략적 방향을 제시합니다.