Context Engineering 2.0, Agent 2.0 Paradigm(with DeepAgent) 그리고 Claude Skills
1. 에이전트를 잘 활용하기 위한 컨텍스트 엔지니어링의 진화
현재 '에이전트'라는 존재가 "Context Engineering 2.0" 논문의 Era 2.0(주도적 에이전트)에서 Era 3.0(신뢰할 수 있는 협력자)으로 넘어가는 다리의 역할을 하고 있다라고 언급하고 있습니다.
Era 2.0 / Agents 1.0 (현재, Shallow Agents):
컨텍스트: 명령어 (Context as Instruction)
특징: RAG, 간단한 프롬프트, 단일 단계의 도구 사용(Tool Use)이 중심입니다. 모델이 수동적으로 컨텍스트를 받아(RAG) 응답하거나, 1회성 도구를 호출(예: 날씨 묻기)합니다.
한계점: "파리 여행 계획해 줘" 같은 복잡하고 장기적인 작업을 수행하지 못합니다. 단일 컨텍스트 창에 의존하며, 스스로 오류를 수정하거나 계획을 세우지 못합니다.
Era 2.5 / Agents 2.0 (전환기, Deep Agents):
컨텍스트: 시나리오 (Context as Scenario)의 시작
특징: '에이전트'가 진정한 의미를 갖기 시작합니다. 이는 다단계 추론(Multi-step Reasoning), 동적 도구 사용, 그리고 '자기-성찰(Self-Correction)'을 특징으로 합니다.
핵심: 에이전트는 더 이상 단일 명령어를 수행하는 봇이 아닙니다. 목표(Goal)를 받고, 그 목표를 달성하기 위한 계획(Plan)을 수립하며, 계획을 실행하다 실패하면 스스로 피드백하고 계획을 수정합니다.
Era 3.0 (미래, Reliable Collaborator):
컨텍스트: 시나리오 및 세계 (Context as Scenario/World)
특징: 사용자는 더 이상 프롬프트 엔지니어링을 고민할 필요가 없습니다. 에이전트는 인간의 의도를 완벽히 파악하고, 수십, 수백 단계의 작업을 자율적으로 수행하며, 인간과 같은 수준의 '협력자'가 됩니다.
물론 이 단계가 되려면 명시적으로 인간과의
2. Deep Agent (Era 2.0) 구현의 3가지 심층 기술
Agents 2.0 Paradigm 의 실질적 구현체인 'Deep Agent' 를 여러 계층으로 엮기 위한 컨텍스트 엔지니어링 기술은 CE2.0 논문에서 제시한 3가지 요소(수집, 관리, 활용)가 훨씬 더 동적이고 복잡한 형태로 진화해야 함을 의미하게 됩니다.
컨텍스트 수집: 수동적인 RAG Workflow 에서 능동적 인식(Active Perception) 방식으로
Agents 1.0 (과거): 사용자가 제공한 문서나 RAG를 통해 주어진 컨텍스트를 수집합니다.
Agents 2.0 (현재): 에이전트가 스스로 "지금 어떤 컨텍스트가 부족한가?"를 판단하도록 구성합니다.
특징: 에이전트가 자신의 계획을 바탕으로 "현재 날씨 정보가 없네,
get_weather스킬을 호출해야겠다" 또는 "이 주제에 대한 최신 정보가 부족하니,web_search스킬을 실행해야겠다"라고 능동적으로 컨텍스트 수집을 '실행'합니다. Agent 의 판단(Reasoning, Judgement) 또는 인식(Perception) 자체가 작업(Action)이 됩니다
컨텍스트 관리: 채팅 세션에서 동적 상태 메모리(Dynamic State Memory)로
Agents 1.0 (과거-현재): 컨텍스트 관리는 단순히 채팅 히스토리를 요약하거나, 조금 더 체계적으로 Vector DB에 저장하는 수준입니다.
Agents 2.0 (조금씩 나아가는 중): 이것이 Deep Agent 구성의 핵심.
에이전트는 2가지 유형의 메모리를 가집니다.
작업 메모리 (Working Memory/Scratchpad):
논문의 '컨텍스트 격리(Context Isolation)'가 극대화된 형태.
에이전트는 자신의 '현재 계획(Plan)', '방금 실행한 단계(Last Action)', '그 단계의 결과(Observation)', '다음 단계(Next Step)'를 저장하는 별도의 '스크래치-패드'를 가지고 있게 됩니다. (장-단기 메모리 개념이 아님)
이것이 없으면 에이전트는 2단계를 넘어가자마자 1단계에서 뭘 했는지 잊어버립니다.
자기-성찰 및 압축 (Self-Baking / Reflection):
논문의 'Self-Baking' 개념이 '학습'의 형태로 진화합니다.
에이전트는
(Observation)을 보고 "아, API가 404 에러를 반환했네. 플랜 B로search_backup_api를 호출하도록 '계획'을 수정해야겠다"라고 스스로의 작업 내역을 '반성(Reflect)'하고 '압축(Bake)'하여 다음 행동을 결정합니다.
컨텍스트 활용: '단일 도구'에서 '다단계 계획 및 실행(Planning & Execution)'으로
Agents 1.0 (현재): 모델이 LLM 추론과 도구 사용 중 하나를 선택합니다.
Agents 2.0 (미래): 모든 출력이 '계획'의 일부가 됩니다.
목표 분해 (Goal Decomposition): "파리 여행 계획"이라는 높은 엔트로피의 목표(굉장히 추상적인)를 "1. 항공권 검색", "2. 숙소 검색", "3. 일정 생성" 등 낮은 엔트로피의(굉장히 구체적인) 실행 가능한 하위 작업으로 분해합니다.
신뢰할 수 있는 실행 (Reliable Execution): 이 분해된 작업을 어떻게 신뢰하고 실행할 것인가?
이 지점에서 바로 Claude Skills가 그 고민에 대한 해법을 제공해줍니다.
3. Claude Skills: Context Engineering 에 최적화된 Agent 실행 기술
'Context as Instruction' (Era 2.0)을 기계가 가장 잘 이해할 수 있도록 '극도로 낮은 엔트로피(low-entropy)'로 압축시킨 정교한 기술 구현 방식입니다.
이 논문에서는 컨텍스트 엔지니어링을 "높은 엔트로피의 인간 의도를 낮은 엔트로피의 기계 표현으로 변환하는 노력"이라고 정의했습니다.
Claude Skills는 이러한 '노력'을 최소화하는 방법으로 꽤나 적절하게 구현된 기술이라 생각됩니다.
문제점: Agents 1.0 시대의 비효율적인 도구 컨텍스트
이전의 에이전트(Agents 1.0)는 어떻게 도구를 사용했을까요?
"이 API 문서를 읽고(RAG) 날씨 함수를 호출해 줘"처럼, 수십 페이지짜리 API 문서를 통째로 컨텍스트에 넣었습니다.
높은 엔트로피: API 문서는 그 자체로 설명도 부족하고 모호하며 내용이 깁니다.
높은 비용: 매번 수만 토큰의 API 문서를 Input Context(Prompt)에 넣어야 합니다. (비용, 속도 문제)
낮은 신뢰도: LLM이 API 문서를 잘못 해석하여 파라미터(parameter)를 누락하거나 잘못된 함수를 호출할 수 있습니다. (Hallucination)
해결책: Claude Skills가 이룬 3가지 Context Engineering 최적화
Claude Skills는 이 문제를 다음과 같은 '낮은 엔트로피' 방식으로 해결합니다.
구조화된 프로토콜 (Structured Protocol)
Claude Skills는 XML 태그
<tools>,<tool_description>)라는 엄격한 '스키마(Schema)'를 사용합니다.논문의 "고정 스키마를 사용한 핵심 사실 추출" 방식과 같습니다.
LLM에게 "자유롭게 API 문서를 읽어봐" (높은 엔트로피)라고 하는 대신, "이
tool_descriptionXML 스키마만 읽어" (극도로 낮은 엔트로피)라고 지시합니다.효과: 모델은 정확히 어떤 도구가 있는지, 각 도구가 어떤 파라미터를 받는지 100% 명확하게 인식합니다. 토큰 사용량이 획기적으로 줄고(비용/속도 증가), 환각이 사라집니다.
책임의 분리 (Separation of Concerns)
논문의 '컨텍스트 격리(Context Isolation)' 및 '서브 에이전트' 사상과 일치합니다.
LLM (특히 Claude) 잘하는 것:
1. 자연어 이해: 사용자의 의도("샌프란시스코 날씨 어때?")를 파악.
2. 구조화된 데이터 생성: 의도를 <function_calls> XML 태그(즉, {"tool_name": "get_weather", "location": "San Francisco"})로 변환.
외부 시스템 (User/Server)이 잘하는 것:
실제 실행:
get_weather함수를 실제로 실행(Execution).
효과: LLM은 '생각'과 '계획'만 담당하고, '실행'은 외부로 격리시켰습니다.
이는 에이전트의 안정성과 신뢰도를 극대화합니다.
약속된 상호작용 (Formalized Handshake)
Claude Skills는 에이전트(LLM)와 외부 세계(시스템) 간의 '컨텍스트 교환' 방식을 공식화했습니다.
1단계 (LLM → System): "이 작업을 실행해 줘."
Context = <function_calls><invoke>...</invoke></function_calls>
2단계 (System → LLM): "실행 결과는 이거야."
Context = <function_results><result>...</result></function_results>
효과: Formalized Handshake 은 Agents 2.0이 복잡한 수준의 다단계 추론을 하는 데 필수적인 '관찰(Observation)' 단계를 표준화합니다. 따라서 에이전트는 이 <function_results> 의 도구 실행 결과 컨텍스트를 받아서 자신의 '스크래치패드'에 기록하고, 다음 행동할 '계획'을 세울 수 있습니다.
4. 결론: 에이전트 Context Engineering 의 미래와 눈여겨 봐야할 Claude Skills
"Context Engineering 2.0" 논문이 에이전트 진화의 아키텍처적인 방향성을 제시했다면, Agents 2.0 (with Deep Agents) Paradigm 은 실질적인 아키텍처(계획, 메모리, 자기-성찰 등 기본적인 구성)를 제안합니다.
그리고 Claude Skills 는 그런 Agent 2.0 Paradigm 의 아키텍처 중 가장 기본이자 핵심 부품인, '신뢰할 수 있는 실행 레이어(Reliable Execution Layer)'를 제공합니다.
겨우 도구 사용 수준의 Agent 가 아닙니다. LLM을 '생각하는 뇌(Brain)'로 완전히 격리해두고, 외부 세계와의 상호작용을 MCP 처럼 표준화하면서, 실제 구현체인 Deep Agents가 복잡한 다단계 작업을 수행할 수 있도록 제시한 핵심적인 컨텍스트 엔지니어링 결과물입니다.
이러한 구현 기술이 있기에 신뢰할 수 있는 협력자(논문에서 언급하는 Era 3.0)로 나아갈 수 있을 것 같다고 저는 생각합니다.