AI 에이전트가 실제로 스킬을 구현하는 방법: 플랫폼 간 완전 비교

소개

모든 AI 에이전트 프레임워크는 동일한 근본적 질문에 직면합니다: LLM을 특정 분야에 능숙하게 만들려면 어떻게 해야 할까요? 모델 자체는 광범위한 일반 지식을 갖고 있지만, 코드 리뷰, 인프라 배포, 마인크래프트 탐색 등 특정 작업을 수행하려면 전문화된 지침, 도구 접근 권한, 도메인 컨텍스트가 필요합니다.

이것이 바로 스킬 주입 문제입니다. 그리고 주요 프레임워크마다 이를 다르게 해결합니다.

일부 플랫폼은 모든 것을 시스템 프롬프트에 사전 로드합니다. 다른 플랫폼은 지연 로딩을 사용하여 에이전트가 필요로 할 때만 기능을 공개합니다. 일부는 벡터 데이터베이스를 사용하여 시맨틱 유사성에 기반한 관련 스킬을 검색합니다. 이러한 차이는 학문적인 것이 아닙니다—토큰 비용, 에이전트 신뢰성, 에이전트가 현실적으로 다룰 수 있는 스킬 수에 직접적인 영향을 미칩니다.

우리는 11개 주요 AI 에이전트 플랫폼을 분석하여 스킬이 프롬프트에서 정확히 어디에 위치하는지, 언제 로드되는지, 토큰 비용은 얼마인지, 컨텍스트 윈도우가 가득 찼을 때 어떻게 생존하는지를 파악했습니다. 이것은 표면적인 기능 비교가 아닙니다. 소스 코드, 문서, 아키텍처 다이어그램을 분석하여 각 플랫폼의 정확한 주입 메커니즘을 매핑했습니다.

종합 비교 표

세부 내용에 들어가기 전에 전체 개요를 확인해 보겠습니다.

주입 메커니즘: 어디서, 언제, 어떻게

지속성, 토큰 비용, 상시 활성 동작

비즈니스 성장 준비가 되셨나요?

오늘 무료 평가판을 시작하고 며칠 내로 결과를 확인하세요.

데모 요청 로그인

“스킬 주입"이 실제로 의미하는 것

비교에 들어가기 전에 문제 영역을 정의해 보겠습니다. AI 에이전트의 컨텍스트 윈도우—각 호출에서 LLM이 보는 전체 텍스트—는 고정된 크기를 가집니다. 모든 지침, 대화 기록, 도구 정의, 검색된 데이터의 토큰이 해당 윈도우 내 공간을 놓고 경쟁합니다.

에이전트 맥락에서 “스킬"이란 에이전트의 행동 방식을 변경하는 모든 구조화된 전문성 패키지입니다. 여기에는 다음이 포함될 수 있습니다:

• 지침: 에이전트에게 특정 도메인에 접근하는 방법을 알려주는 것(코드 리뷰 가이드라인, 배포 체크리스트)
• 도구 정의: 에이전트에게 호출 가능한 함수를 제공하는 것(API 통합, 파일 작업)
• 퓨샷 예시: 에이전트에게 좋은 출력이 어떤 것인지 보여주는 것
• 검색된 지식: 벡터 데이터베이스나 외부 문서에서 가져온 것

주입 메커니즘—이 내용이 컨텍스트에 진입하는 위치와 시점—은 세 가지 핵심 속성을 결정합니다:

1. 토큰 효율성: 스킬이 얼마나 많은 토큰을 소비하며, 스킬이 필요하지 않을 때도 그 비용이 발생하는가?
2. 신뢰성: 에이전트가 관련이 있을 때 일관되게 스킬을 사용할 것인가, 아니면 신호를 놓칠 수 있는가?
3. 확장성: 컨텍스트 비대화가 성능을 저하시키기 전까지 에이전트가 몇 개의 스킬에 접근할 수 있는가?

모든 프레임워크는 이 세 가지 차원에서 서로 다른 트레이드오프를 만듭니다. 각각을 살펴보겠습니다.

주입 스펙트럼: 상시 활성에서 온디맨드까지

11개 플랫폼 전체에서 스킬 주입 접근 방식은 “모든 것을 사전에 로드"에서 “명시적으로 필요할 때까지 아무것도 로드하지 않음"까지의 스펙트럼을 따릅니다.

한쪽 끝에서는 CrewAI, SuperAGI, CAMEL-AI와 같은 플랫폼이 활성화된 모든 스킬의 전체 내용을 모든 LLM 호출에 주입합니다. 에이전트는 항상 완전한 전문성을 사용할 수 있습니다. 단순하고 신뢰할 수 있지만, 토큰 비용이 높습니다.

다른 쪽 끝에서는 Claude Code, LangChain Deep Agents, OpenAI의 Responses API가 점진적 공개를 사용합니다—에이전트는 시작 시 스킬 이름과 짧은 설명만 보고, 전체 내용은 온디맨드로 로드됩니다. 효율적이고 확장 가능하지만, 에이전트가 스킬이 필요한 시점을 인식해야 합니다.

중간에는 AutoGen Teachability와 Voyager가 시맨틱 검색을 사용하여 턴마다 가장 관련 있는 스킬만 주입하여 동적이고 컨텍스트에 민감한 주입 패턴을 만듭니다.

그리고 독특한 접근 방식도 있습니다: DSPy는 최적화된 퓨샷 예시를 오프라인으로 컴파일하여 모듈 프롬프트에 영구적으로 내장합니다. MetaGPT는 특정 역할이 특정 액션으로 전환될 때만 활성화되는 액션 템플릿으로 스킬을 인코딩합니다.

각각을 자세히 살펴보겠습니다.

뉴스레터 가입

최신 팁, 트렌드 및 특가 정보를 무료로 받아보세요.

이메일 주소

구독

Claude Code: 3계층 점진적 공개

Claude Code는 인식과 토큰 효율성의 균형을 맞추는 3계층 점진적 공개 시스템을 사용하여 가장 정교한 스킬 주입 아키텍처 중 하나를 구현합니다.

1계층: 항상 컨텍스트에 존재

세션 시작 시, 사용 가능한 모든 스킬의 이름과 설명이 system-reminder 메시지—모델이 항상 보는 메타데이터 블록—에 주입됩니다. 이는 스킬당 약 250자의 비용이 들며, 모든 스킬 설명을 합해 컨텍스트 윈도우 예산의 약 1%를 소비합니다(폴백 예산으로 약 8K자, SLASH_COMMAND_TOOL_CHAR_BUDGET 환경 변수로 재정의 가능).

마찬가지로, 지연된 도구—전체 JSON 스키마가 아직 로드되지 않은 도구—는 system-reminder 블록에 이름만 있는 목록으로 표시됩니다. Claude Code v2.1.69 기준, Bash, Read, Edit, Write, Glob, Grep과 같은 내장 시스템 도구도 ToolSearch 뒤에 지연되어 시스템 도구 컨텍스트가 약 14-16K 토큰에서 약 968 토큰으로 줄어들었습니다.

에이전트는 전체 정의의 토큰 비용을 지불하지 않고도 무엇이 사용 가능한지 알 수 있을 만큼 충분히 봅니다.

2계층: 활성화 시

사용자가 슬래시 명령(예: /commit)을 입력하거나 모델이 설명을 기반으로 스킬을 자동 매칭하면, 전체 SKILL.md 본문이 Skill 도구를 통해 대화 메시지로 로드됩니다. 이 본문에는 완전한 지침이 포함되어 있으며—때로는 수천 토큰의 상세한 안내가 됩니다.

핵심 세부 사항: 쉘 전처리가 먼저 실행되고(스킬 파일의 모든 !command 지시문이 실행되어 그 출력으로 대체됨), 한번 로드되면 스킬 본문은 세션의 나머지 기간 동안 대화에 남아 있습니다.

3계층: 온디맨드

추가 리소스—참조 문서, 스크립트, 자산 파일—은 모델이 명시적으로 Read 도구를 사용하여 접근하기로 결정할 때만 로드됩니다. 자동으로 로드되지 않습니다.

컨텍스트 압축 동작

대화가 컨텍스트 한도에 접근하여 압축이 트리거되면, Claude Code는 스킬당 5K 토큰, 합산 최대 25K의 예산으로 가장 최근에 호출된 스킬을 재첨부합니다. 가장 최근에 호출된 스킬이 우선순위를 받습니다. 오래된 스킬은 완전히 삭제될 수 있습니다.

이 3계층 아키텍처는 20개 이상의 사용 가능한 스킬을 가진 에이전트가 최소한의 선불 비용을 지불하면서도 단일 턴 내에 어느 스킬의 전체 전문성에든 접근할 수 있음을 의미합니다.

CrewAI: 모든 태스크 프롬프트에 전체 주입

CrewAI는 점진적 공개와 반대되는 접근 방식을 취합니다. 에이전트에 대해 스킬이 활성화되면, 그 전체 내용이 에이전트가 실행하는 모든 태스크 프롬프트에 주입됩니다.

작동 방식

CrewAI의 스킬은 자체 포함된 디렉토리로, 각각 YAML 프론트매터(이름, 설명, 라이선스, 호환성, 허용된 도구)와 마크다운 본문이 포함된 SKILL.md 파일을 가지고 있습니다. 스킬 시스템은 스킬과 도구를 구분합니다: 스킬은 에이전트의 사고 방식을 형성하는 지침과 컨텍스트를 주입하고, 도구는 행동을 위한 호출 가능한 함수를 제공합니다.

에이전트 초기화 시, Agent.set_skills()가 discover_skills()를 호출하여 메타데이터 수준에서 스킬 디렉토리를 스캔한 다음, activate_skill()로 전체 스킬 본문을 읽습니다. 태스크 실행 시, _finalize_task_prompt()가 활성화된 각 스킬에 대해 format_skill_context()를 호출하고 포맷된 모든 스킬 내용을 태스크 프롬프트에 추가합니다.

LLM이 수신하는 내용: [시스템 메시지] + [태스크 프롬프트 + 모든 스킬 본문]

토큰 영향

CrewAI는 스킬당 50,000자에서 소프트 경고를 발행하지만 하드 리밋은 없습니다. 문서에서는 큰 프롬프트 주입이 모델의 주의력을 분산시키기 때문에 스킬을 집중적이고 간결하게 유지할 것을 권장합니다—컨텍스트 부식에 대한 연구를 고려하면 실질적인 우려입니다.

트레이드오프는 간단합니다: 에이전트는 항상 전체 전문성을 사용할 수 있고(높은 신뢰성), 그러나 토큰 비용은 태스크당 스킬 수에 비례하여 선형적으로 증가합니다(낮은 효율성). 1-2개의 집중된 스킬을 가진 에이전트에게는 잘 작동합니다. 광범위한 기능 세트가 필요한 에이전트에게는 비용이 빠르게 증가합니다.

태스크 간 지속성 없음

각 태스크는 새로운 주입을 받습니다. 태스크 간에 스킬 내용이 누적되지 않습니다—이는 사실 버그가 아니라 기능입니다. 각 태스크가 깨끗한 컨텍스트로 시작하여 세션 기반 지속성이 만들 수 있는 노후화 문제를 피합니다.

LangChain Deep Agents: SkillsMiddleware를 통한 에이전트 제어 로딩

LangChain Deep Agents는 에이전트 자체가 전체 스킬 내용을 로드할 시점을 결정하는 정교한 미들웨어 기반 스킬 시스템을 구현합니다—에이전트가 활성화를 제어하는 진정한 점진적 공개 모델입니다.

3가지 티어

티어 1 (인덱스): SkillsMiddleware가 시작 시 모든 SKILL.md 프론트매터를 파싱하고 시스템 프롬프트에 가벼운 인덱스를 주입합니다. 이 인덱스는 이름과 설명만 포함하며, 전체 내용의 약 3,302 토큰 대비 스킬당 약 278 토큰의 비용이 듭니다.

티어 2 (전체 내용): 에이전트가 스킬이 관련 있다고 판단하면, 스킬의 SKILL.md 경로에 대해 read_file()을 호출합니다. 이는 일반 도구 호출입니다—프레임워크가 본문을 주입하는 것이 아니라, 에이전트가 의도적으로 로드를 결정합니다. 전체 내용은 도구 결과로 대화 기록에 진입합니다.

티어 3 (심층 분석): 보충 자료, 참조 문서, 스크립트는 에이전트가 명시적으로 읽을 때만 접근됩니다.

실제 토큰 효율성

12개 스킬의 경우, 점진적 공개는 컨텍스트를 약 30,000 토큰(모두 로드)에서 약 600 토큰(인덱스만)으로 줄이고, 특정 태스크에 관련 스킬이 로드되면 2,000-5,000으로 확장됩니다. 이는 스킬 관련 토큰 소비에서 잠재적으로 83-98% 감소입니다.

여러 스킬 소스를 계층화할 수 있으며, 이름이 충돌하면 마지막 소스가 우선합니다. 10MB 이상의 파일은 자동으로 건너뜁니다.

Claude Code와의 주요 차이점

Claude Code가 로딩을 트리거하기 위해 전용 Skill 도구를 사용하는 반면, Deep Agents는 에이전트의 기존 read_file 도구를 재활용합니다. 이는 로딩 메커니즘이 투명하다는 것을 의미합니다—에이전트는 다른 파일을 읽는 것과 같은 방식으로 스킬 파일을 읽습니다. 단점은 특별한 압축 동작이 없다는 것입니다: 대화 기록에 진입한 스킬 내용은 우선순위 처리 없이 표준 LangChain 메시지 트리밍의 대상이 됩니다.

OpenAI Responses API 및 Agents SDK: 플랫폼 관리 지연 로딩

OpenAI는 두 가지 별개이지만 철학적으로 일치하는 메커니즘을 통해 스킬 주입을 구현합니다: Responses API의 tool_search 도구 유형과 Agents SDK의 ToolSearchTool.

Responses API: tool_search

tool_search 도구 유형(GPT-5.4+에서 사용 가능)은 개발자가 대규모 도구 표면을 런타임까지 지연시킬 수 있게 합니다. 세 가지 지연 전략이 사용 가능합니다:

• 개별 함수 지연: @function_tool(defer_loading=True) — 모델이 함수 이름과 설명은 보지만 매개변수 스키마는 지연됩니다. 매개변수 수준 토큰을 절약합니다.
• 네임스페이스 지연: tool_namespace(name=..., description=..., tools=[...]) — 함수를 단일 네임스페이스 아래에 그룹화합니다. 모델은 네임스페이스 이름과 설명만 보므로 토큰을 훨씬 더 많이 절약합니다.
• MCP 서버 지연: HostedMCPTool(tool_config={..., "defer_loading": True}) — 전체 MCP 서버 도구 표면을 지연합니다.

모델이 특정 도구가 필요하다고 판단하면, tool_search 호출을 실행합니다. API가 3-5개의 관련 도구 정의를 반환하며, 프롬프트 캐싱을 보존하기 위해 컨텍스트 윈도우 끝에 주입됩니다.

Agents SDK: ToolSearchTool

Agents SDK는 프로그래밍 방식의 동등물을 제공합니다. 도구 네임스페이스가 등록되지만 로드되지는 않습니다:

crm_tools = tool_namespace(
    name="crm",
    description="CRM management tools",
    tools=[...]
)
agent = Agent(tools=[*crm_tools, ToolSearchTool()])

런타임에 에이전트는 네임스페이스 이름만 봅니다. ToolSearchTool("crm")을 호출하여 전체 스키마를 발견하고 로드한 다음, 해당 네임스페이스 내의 개별 도구를 호출할 수 있습니다.

요청 간 지속성 없음

각 API 요청은 독립적입니다. 발견된 도구는 호출 간에 지속되지 않습니다. 이것은 비교 중 가장 상태 비저장 방식입니다—깔끔하고 예측 가능하지만, 도구가 변경되면 매 요청마다 재발견이 필요합니다.

AutoGen Teachability: 턴별 시맨틱 검색

AutoGen의 Teachability 기능은 이 비교에서 다른 모든 프레임워크와 근본적으로 다른 접근 방식을 취합니다. 정적 스킬 내용을 주입하는 대신, 매 턴마다 ChromaDB 벡터 데이터베이스에서 관련 “메모"를 동적으로 검색합니다.

턴별 검색 루프

Teachability는 에이전트가 처리하기 전 모든 수신 사용자 메시지를 가로채는 process_last_received_message 훅을 등록합니다:

1. TextAnalyzerAgent가 수신 메시지에서 핵심 개념을 추출합니다
2. 이러한 개념이 ChromaDB 쿼리에 사용됩니다(기본적으로 Sentence Transformer 임베딩 사용)
3. 가장 관련 있는 상위 K개 메모가 검색됩니다(max_num_retrievals로 설정 가능, 기본값 10)
4. 검색된 메모가 에이전트가 보기 전 메시지 텍스트에 추가됩니다

중요한 점은, 수정된 메시지는 저장된 대화 기록에 전파되지 않습니다—원본 메시지만 저장됩니다. 이는 메모 내용이 턴 간에 복합되는 것을 방지합니다.

학습 루프

LLM이 응답한 후, 두 번째 훅이 응답에서 새로운 학습 내용을 분석합니다:

1. TextAnalyzerAgent가 응답에서 새로운 지식을 식별합니다
2. 새 메모가 키-값 쌍으로 추출됩니다(입력 텍스트 → 출력 텍스트)
3. 이러한 메모는 ChromaDB에 저장되어 향후 턴과 세션에서 사용 가능합니다

이는 에이전트가 시간이 지남에 따라 전문성을 축적하는 진정한 학습 루프를 만듭니다.

교차 세션 지속성

AutoGen Teachability는 비교에서 세션 간 스킬이 지속되는 세 가지 플랫폼(Voyager, DSPy와 함께) 중 하나입니다. ChromaDB 데이터베이스는 디스크에 존재하며, 에이전트가 월요일 상호작용에서 학습한 내용을 금요일에 적용할 수 있습니다.

recall_threshold 매개변수(기본값 1.5)는 메시지가 저장된 메모와 얼마나 유사해야 검색되는지를 제어하며, reset_db는 필요시 전체 메모리를 초기화할 수 있습니다.

토큰 효율성

턴마다 관련 메모만 주입되므로(일반적으로 3-5개), 메모 데이터베이스가 얼마나 커지든 토큰 비용은 자연스럽게 제한됩니다. 10,000개의 저장된 메모를 가진 에이전트도 현재 턴에 가장 관련 있는 소수의 메모에 대해서만 비용을 지불합니다.

Semantic Kernel: 상시 존재하는 도구 정의로서의 플러그인 스키마

Microsoft의 Semantic Kernel은 간단한 접근 방식을 취합니다: 플러그인은 Kernel에 등록된 KernelFunction 객체의 모음이며, 해당 스키마는 LLM에 함수 호출 도구 정의로 노출됩니다.

두 가지 주입 경로

함수 호출: ToolCallBehavior.AutoInvokeKernelFunctions가 설정되면, 모든 등록된 함수가 모든 API 요청에서 사용 가능한 도구로 LLM에 전송됩니다. LLM이 호출할 함수를 결정하고, Semantic Kernel이 호출과 결과 라우팅을 처리합니다.

프롬프트 템플릿: Semantic Kernel의 템플릿 구문({{plugin.function}}, Handlebars, 또는 Liquid)은 프롬프트 렌더링 중에 함수를 인라인으로 호출할 수 있게 합니다. 결과는 LLM에 도달하기 전에 프롬프트 텍스트에 직접 포함됩니다—지연 도구 호출이 아닌 즉시 평가의 한 형태입니다.

점진적 공개 없음

모든 등록된 플러그인의 스키마가 모든 API 호출에 포함됩니다. 내장된 지연 로딩, 네임스페이스 그룹화 또는 온디맨드 활성화가 없습니다. 문서에서는 토큰 소비와 오호출을 줄이기 위해 특정 시나리오에 필요한 플러그인만 가져올 것을 명시적으로 권장합니다.

이로 인해 Semantic Kernel은 가장 예측 가능한 플랫폼 중 하나가 됩니다—에이전트가 접근할 수 있는 것을 항상 정확히 알 수 있습니다—그러나 확장성을 제한합니다. 50개의 등록된 함수를 가진 에이전트는 모든 단일 호출에서 전체 스키마 비용을 지불합니다.

지속성

플러그인 등록은 Kernel 인스턴스별이며 인메모리입니다. 교차 세션 스킬 지속성을 위한 내장 메커니즘이 없습니다.

MetaGPT: 역할 기반 SOP 내의 액션 템플릿

MetaGPT는 스킬을 독립적인 패키지가 아니라 역할 행동을 관리하는 표준 운영 절차(SOP) 내에 포함된 액션 템플릿으로 인코딩합니다.

역할과 액션 아키텍처

MetaGPT의 각 Role은 프롬프트에 주입되는 페르소나 접두사와 Action 클래스 세트를 가지고 있습니다. 각 Action은 자연어 프롬프트 템플릿을 사용하여 LLM 호출을 구조화하는 aask()를 통해 호출되는 LLM 프록시를 포함합니다.

Role._act()가 실행될 때, 세 가지 반응 모드를 지원합니다:

• "react": LLM이 사고-행동 루프에서 동적으로 액션을 선택
• "by_order": 미리 정해진 순서로 액션이 순차 실행
• "plan_and_act": 에이전트가 먼저 계획한 다음 계획에 따라 액션 실행

좁은 주입 윈도우

주어진 시점에서 현재 Action의 프롬프트 템플릿만 활성화됩니다. 에이전트는 다른 액션의 템플릿을 보지 않습니다—역할 접두사와 특정 액션의 컨텍스트만 봅니다. 이것은 우리가 조사한 프레임워크 중 가장 좁은 주입 윈도우입니다.

Action 클래스 내의 컨텍스트 파싱 함수가 입력에서 관련 정보를 추출하므로, 각 액션은 전체 대화 기록이 아닌 사용 가능한 컨텍스트의 큐레이팅된 하위 집합을 받습니다.

단일 턴 지속성

템플릿은 각 액션 실행에 대해 새롭게 렌더링됩니다. 누적이나 교차 세션 지속성이 없습니다. 이는 각 액션을 집중시키지만 에이전트가 단일 워크플로 내에서 이전에 로드된 스킬 내용을 기반으로 구축할 수 없음을 의미합니다.

Voyager: 평생 학습을 위한 임베딩 기반 스킬 검색

NVIDIA와 Caltech의 마인크래프트 탐험 에이전트인 Voyager는 임베딩 유사성으로 검색되는 검증된 프로그램의 성장하는 라이브러리라는 가장 우아한 스킬 주입 아키텍처 중 하나를 구현합니다.

스킬 라이브러리

Voyager가 자체 검증을 통과한 코드를 작성하면(생성된 Mineflayer JavaScript가 실제로 게임에서 작동), 코드와 해당 문서 문자열이 벡터 데이터베이스에 저장됩니다. 문서 문자열 임베딩이 검색 키가 됩니다.

태스크별 검색

자동 커리큘럼이 제안한 각 새 태스크에서:

1. 태스크 설명과 환경 피드백이 임베딩됩니다
2. 저장된 모든 스킬 임베딩에 대해 코사인 유사성 검색
3. 가장 관련 있는 상위 5개 스킬이 검색됩니다
4. 검색된 스킬 코드가 액션 에이전트의 프롬프트에 퓨샷 예시로 포함됩니다

프롬프트는 다음과 같습니다:

You are a Minecraft bot. Here are some relevant skills you've learned:

// Skill: mineWoodLog
async function mineWoodLog(bot) { ... }

// Skill: craftPlanks
async function craftPlanks(bot) { ... }

Now write code to: build a wooden pickaxe

생성된 코드는 검색된 스킬을 이름으로 호출할 수 있어 조합적 스킬 구축이 가능합니다—더 간단하고 검증된 기본 요소로부터 복잡한 행동을 구성합니다.

평생 지속성

스킬 라이브러리는 핵심 “평생 학습” 메커니즘입니다. 에이전트의 전체 수명에 걸쳐 성장하며, 새 스킬은 이전 스킬을 기반으로 구축됩니다. 대부분의 프레임워크에서 스킬이 인간에 의해 작성되는 것과 달리, Voyager의 스킬은 에이전트 자체에 의해 생성, 검증, 저장됩니다.

토큰 비용은 자연스럽게 제한됩니다: 라이브러리에 50개가 있든 5,000개가 있든, 각 태스크는 가장 관련 있는 5개의 검색에 대해서만 비용을 지불합니다.

DSPy: 고정된 스킬로서의 컴파일된 퓨샷 예시

DSPy는 다른 모든 프레임워크와 근본적으로 다른 접근 방식을 취합니다. 런타임에 스킬을 주입하는 대신, DSPy는 최적의 퓨샷 시연을 오프라인으로 컴파일하여 모듈 프롬프트에 영구적으로 내장합니다.

컴파일 프로세스

두 가지 주요 옵티마이저가 컴파일을 처리합니다:

BootstrapFewShot: 교사 모듈을 사용하여 프로그램을 통한 추적을 생성합니다. 사용자 정의 메트릭을 통과한 추적은 시연으로 유지됩니다. 프로그램 내의 각 dspy.Predict 모듈은 자체 큐레이팅된 시연 세트를 받습니다.

MIPROv2 (Multi-prompt Instruction Proposal Optimizer v2): 3단계 프로세스:

1. 부트스트랩: 후보 시연 세트 생성
2. 제안: 데이터 분포와 시연 모두를 인식하는 후보 지시 텍스트 생성
3. 검색: 모든 모듈에 걸쳐 지시 x 시연의 결합된 공간에 대한 베이지안 최적화

max_bootstrapped_demos(생성된 예시)와 max_labeled_demos(훈련 데이터에서) 같은 매개변수가 각 모듈의 프롬프트에 포함되는 예시 수를 제어합니다.

컴파일 후 고정

컴파일되면, 시연은 각 Predict 모듈의 demos 속성에 저장되고 모든 LLM 호출에서 프롬프트에 포맷됩니다. 런타임에 변경되지 않습니다—“스킬"이 고정됩니다.

이는 DSPy 스킬이 비교에서 가장 예측 가능하다는 것을 의미합니다: 토큰 비용은 컴파일 후 알려지고, 턴 간 변동이 없으며, 에이전트는 항상 동일한 시연을 봅니다. 단점은 유연성 부족입니다—스킬을 변경하려면 재컴파일해야 합니다.

지속성

컴파일된 프로그램은 모든 시연을 포함하여 JSON으로 직렬화됩니다. 세션 간 완전히 지속적이며 로드 가능하여, DSPy는 가장 내구성 있는 스킬 저장 메커니즘 중 하나입니다.

SuperAGI: 툴킷 기반 사전 등록

SuperAGI는 에이전트 초기화 시 모든 도구가 등록되는 전통적인 툴킷 패턴을 사용합니다.

각 툴킷은 다음을 포함하여 BaseToolkit을 확장합니다:

• name과 description 속성
• BaseTool 인스턴스 목록을 반환하는 get_tools() 메서드
• 필요한 환경 변수를 위한 get_env_keys()

툴킷은 SuperAGI의 도구 관리자를 통해 GitHub 리포지토리에서 설치됩니다. 에이전트 초기화 시, BaseToolkit.get_tools()가 모든 도구를 반환하고, 전체 스키마가 함수 호출 정의로 LLM에 노출됩니다.

지연 로딩, 점진적 공개, 턴별 필터링이 없습니다. 모든 등록된 도구의 스키마가 모든 호출에 존재합니다. 이것은 가장 단순한 주입 모델이며 집중적이고 작은 도구 세트를 가진 에이전트에게는 잘 작동하지만, 수십 개의 기능이 필요한 에이전트에게는 확장되지 않습니다.

CAMEL-AI: ChatAgent 도구 등록

CAMEL-AI는 유사한 사전 등록 패턴을 따릅니다. 다양한 툴킷(예: MathToolkit, SearchToolkit)의 도구가 초기화 시 ChatAgent(tools=[...])에 목록으로 전달됩니다.

프레임워크는 모델이 사용법을 이해할 수 있도록 사용자 정의 함수에 명확한 인자 이름과 포괄적인 독스트링이 필요하다고 강조합니다—도구 스키마가 모델이 보는 유일한 “스킬” 내용입니다. 별도의 지침 주입 메커니즘이 없습니다.

최근 추가된 기능으로 MCPToolkit을 통한 MCP(Model Context Protocol) 지원이 있어, ChatAgent가 MCP 서버에 연결하고 외부 도구를 등록할 수 있습니다. 이는 사용 가능한 도구 표면을 확장하지만 주입 모델을 변경하지는 않습니다—발견된 모든 MCP 도구는 여전히 사전에 등록됩니다.

플랫폼 간 비교

스킬 주입 시점

지속성 모델

컨텍스트 압축 생존

점진적 공개 패턴

이러한 플랫폼 전반에서 가장 중요한 아키텍처 트렌드는 점진적 공개의 채택입니다—필요에 따라 정보를 점진적으로 공개하는 UI 디자인에서 차용한 개념입니다.

점진적 공개가 중요한 이유

스킬 주입에 대한 순진한 접근 방식—모든 것을 사전에 로드—은 두 가지 문제를 만듭니다:

1. 토큰 낭비: 대부분의 스킬은 대부분의 턴에 관련이 없습니다. 턴당 1-2개만 필요할 때 20개의 전체 스킬 본문을 로드하면 스킬 관련 토큰의 90% 이상이 낭비됩니다.
2. 주의력 희석: 컨텍스트 부식에 대한 연구에 따르면 LLM은 컨텍스트에 대량의 무관한 정보가 포함되어 있을 때 성능이 저하됩니다. 컨텍스트에 더 많은 스킬이 있으면 실제로 스킬 적용 품질이 저하될 수 있습니다.

점진적 공개는 사용 가능한 스킬의 가벼운 인덱스를 유지하면서 필요할 때만 전체 내용을 로드하여 두 문제를 모두 해결합니다.

구현 변형

Claude Code는 전용 시스템을 사용합니다: system-reminder 메시지의 스킬 메타데이터, 활성화를 위한 Skill 도구, 지연된 도구 스키마를 위한 ToolSearch. 프레임워크가 우선순위 기반 압축으로 주입을 자동 관리합니다.

LangChain Deep Agents는 에이전트의 기존 파일 읽기 기능을 사용합니다: SkillsMiddleware가 인덱스를 주입하고, 에이전트가 read_file()을 통해 전체 내용을 로드합니다. 이는 더 투명하지만 프레임워크 수준 최적화가 적습니다.

OpenAI Responses API는 플랫폼 관리 검색을 통한 네임스페이스 기반 그룹화를 사용합니다: 도구 네임스페이스가 상위 수준 설명을 제공하고, tool_search가 관련 스키마를 반환합니다. 플랫폼이 검색 로직을 전적으로 처리합니다.

실제 토큰 절약

수치는 설득력이 있습니다. 12개 스킬의 경우:

• 상시 활성 주입 (CrewAI/SuperAGI 방식): ~30,000 토큰
• 점진적 공개 인덱스만: ~600 토큰
• 인덱스 + 2개 활성화된 스킬: ~2,000-5,000 토큰

이는 턴당 스킬 관련 토큰 소비에서 83-98% 감소입니다. 수백 턴의 긴 세션에서 절약 효과는 극적으로 복합됩니다.

아키텍처 패턴과 트레이드오프

11개 플랫폼 전체를 살펴보면, 네 가지 뚜렷한 아키텍처 패턴이 나타납니다:

패턴 1: 상시 활성 주입

사용: CrewAI, SuperAGI, CAMEL-AI, Semantic Kernel

작동 방식: 전체 스킬 내용 또는 도구 스키마가 모든 LLM 호출에 존재합니다.

장점:

• 최대 신뢰성—에이전트가 항상 전체 전문성을 사용할 수 있음
• 가장 간단한 구현—활성화 로직 불필요
• 예측 가능한 토큰 비용—매 턴 동일

단점:

• 토큰 비용이 스킬 수에 비례하여 선형 증가
• 많은 스킬에서 주의력 희석
• 에이전트당 ~5-10개 스킬 이상으로 확장 불가

최적 용도: 항상 관련 있는 1-3개 핵심 스킬을 가진 집중된 에이전트.

패턴 2: 점진적 공개

사용: Claude Code, LangChain Deep Agents, OpenAI Responses API/Agents SDK

작동 방식: 가벼운 메타데이터가 항상 존재; 전체 내용은 온디맨드로 로드.

장점:

• 수십 또는 수백 개의 사용 가능한 스킬로 확장
• 스킬이 필요하지 않을 때 최소 토큰 비용
• 전체 스키마가 끝에 추가될 때 프롬프트 캐시 보존

단점:

• 에이전트가 관련 스킬 활성화 신호를 놓칠 수 있음
• 활성화 단계의 추가 지연
• 더 복잡한 프레임워크 구현

최적 용도: 많은 기능에 접근해야 하지만 태스크당 소수만 사용하는 범용 에이전트.

패턴 3: 시맨틱 검색

사용: AutoGen Teachability, Voyager

작동 방식: 벡터 데이터베이스 쿼리가 현재 컨텍스트와의 시맨틱 유사성에 기반하여 관련 스킬/지식을 표면화.

장점:

• 라이브러리 크기에 관계없이 자연스럽게 제한된 토큰 비용
• 라이브러리가 성장함에 따라 내용 관련성이 시간이 지남에 따라 향상
• 교차 세션 학습과 축적
• 명시적 활성화 불필요—관련성이 자동 계산

단점:

• 검색 품질이 임베딩 모델 품질에 의존
• 오래되거나 미묘하게 잘못된 정보를 검색할 위험
• 벡터 데이터베이스 인프라 필요
• 예측 불가—턴마다 다른 내용 로드

최적 용도: 경험에서 배우고 시간이 지남에 따라 도메인 지식을 축적해야 하는 에이전트.

패턴 4: 컴파일/정적 주입

사용: DSPy, MetaGPT

작동 방식: 스킬이 고정된 프롬프트 내용(DSPy)으로 컴파일되거나 엄격한 액션 템플릿(MetaGPT)을 통해 활성화.

장점:

• 가장 예측 가능한 동작—매번 동일한 내용
• 오프라인 최적화 가능(DSPy의 컴파일)
• 스킬 선택을 위한 런타임 오버헤드 없음
• 잘 정의된 반복 가능한 태스크에 대해 효과 입증

단점:

• 유연성 부족—스킬 변경 시 재컴파일(DSPy) 또는 코드 변경(MetaGPT) 필요
• 컴파일된 예시 외의 새로운 상황에 적응 불가
• DSPy의 컴파일 프로세스 자체에 많은 LLM 호출 필요

최적 용도: 유연성보다 신뢰성이 중요한 잘 정의된 태스크를 가진 프로덕션 파이프라인.

에이전트 빌더를 위한 실용적 시사점

올바른 패턴 선택

올바른 스킬 주입 아키텍처는 에이전트의 프로필에 따라 달라집니다:

에이전트가 좁고 잘 정의된 역할을 가진 경우 (예: 코드 리뷰 봇, 특정 제품의 고객 지원 에이전트), 상시 활성 주입(CrewAI/SuperAGI 패턴)이 가장 간단하고 신뢰할 수 있습니다. 2-3개 상시 존재하는 스킬의 토큰 비용은 관리 가능하며, 활성화 로직의 복잡성을 피할 수 있습니다.

에이전트가 광범위한 기능이 필요하지만 상호작용당 소수만 사용하는 경우 (예: 개발자 어시스턴트, 범용 자동화 에이전트), 점진적 공개(Claude Code/Deep Agents 패턴)가 확실한 승자입니다. 대규모에서의 83-98% 토큰 절약은 무시하기에 너무 큽니다.

에이전트가 상호작용에서 학습하고 개선해야 하는 경우 (예: 개인 어시스턴트, 지식을 축적하는 도메인 전문가), 시맨틱 검색(AutoGen Teachability 패턴)이 다른 패턴에 없는 학습 루프를 제공합니다. 지식 기반에 진입하는 내용에 대한 품질 관리만 확보하면 됩니다.

에이전트가 잘 정의된 파이프라인을 실행하는 경우 (예: 데이터 처리, 보고서 생성, 표준화된 워크플로), 컴파일 주입(DSPy 패턴)이 가장 예측 가능하고 최적화된 동작을 제공합니다.

하이브리드 접근 방식

에이전트가 즉시 작동해야 하는 프로덕션 에이전트 팀의 경우, 하이브리드 접근 방식을 권장합니다:

핵심 스킬 (에이전트당 1-2개, 주요 도메인 전문성 정의): CrewAI 방식으로 시스템 프롬프트에 항상 주입. 에이전트가 매 턴 필요로 하는 협상 불가능한 기능입니다.

확장 스킬 (에이전트가 필요로 할 수 있는 추가 기능): Deep Agents 방식으로 시스템 프롬프트에 메타데이터만, 필요시 검색/로드 메커니즘을 통해 로드. 관련 없을 때 토큰 비용을 지불하지 않으면서 에이전트의 기능 세트를 확장합니다.

학습된 지식 (축적된 도메인 전문성): AutoGen 방식으로 벡터 데이터베이스에 저장하고 턴마다 시맨틱으로 검색. 수동 스킬 작성 없이 에이전트가 시간이 지남에 따라 개선될 수 있게 합니다.

이 계층화된 아키텍처는 시스템 프롬프트가 구축되는 방식에 자연스럽게 매핑됩니다: 날짜 → 페르소나 → 시스템 지침 → 핵심 스킬 → 스킬 인덱스 → 역할/팀 컨텍스트. 핵심 스킬과 인덱스는 예측 가능하고 관리 가능한 토큰 비용을 추가하며, 전체 스킬 본문은 필요할 때만 나타납니다.

프레임워크 간 토큰 예산 모범 사례

어떤 주입 패턴을 사용하든, 이러한 토큰 관리 전략은 보편적으로 적용됩니다:

캐시 친화적 정렬

변경되지 않는 컨텍스트(시스템 지침, 도구 스키마)를 프롬프트 앞부분에 배치하세요. 프롬프트 캐싱을 지원하는 제공자에서 캐시된 토큰은 75% 저렴합니다. Claude Code와 OpenAI 모두 정적 접두사에 대한 캐시 히트를 보존하기 위해 발견된 도구 스키마를 컨텍스트 끝에 특별히 주입합니다.

오프로딩

전체 결과를 컨텍스트에 유지하는 대신 도구 응답을 요약하세요. 에이전트가 온디맨드로 읽을 수 있는 외부 참조에 전체 데이터를 저장하세요. 이는 세션당 많은 도구 호출을 하는 에이전트에게 특히 중요합니다.

축소

요약을 통해 대화 기록을 압축하세요. 긴 교환에서 핵심 사실을 압축된 표현으로 추출하세요. 세션 기반 지속성을 가진 모든 프레임워크는 적극적인 기록 관리의 혜택을 받습니다.

사전 로딩보다 검색

모든 것을 사전에 로드하는 대신 런타임에 관련 정보를 동적으로 가져오세요. 이는 스킬, 지식 기반, 심지어 대화 기록에도 적용됩니다. 연구에 따르면 이를 통해 프롬프트 크기를 최대 70%까지 줄일 수 있습니다.

격리

각 에이전트의 컨텍스트가 집중되도록 특정 태스크에 서브 에이전트를 사용하세요. 하나의 에이전트에 20개의 스킬을 부여하는 대신, 각각 4개의 스킬을 가진 5개의 에이전트 팀을 만드세요. 각 에이전트는 간결한 컨텍스트 윈도우를 유지하고, 팀이 전체적으로 전체 기능 세트를 커버합니다.

결론

AI 에이전트 프레임워크가 스킬을 컨텍스트에 주입하는 방식은 에이전트 설계에서 가장 중대한 아키텍처 결정 중 하나입니다—그러나 이 수준의 세부 사항으로 논의되는 경우는 거의 없습니다.

이 분야는 범용 에이전트를 위한 선호 패턴으로 점진적 공개에 명확히 수렴하고 있으며, Claude Code, LangChain Deep Agents, OpenAI 모두 독립적으로 유사한 3계층 아키텍처에 도달했습니다. 한편, 시맨틱 검색(AutoGen, Voyager)과 컴파일 주입(DSPy) 같은 특화된 패턴은 점진적 공개만으로는 해결할 수 없는 중요한 틈새를 채우고 있습니다.

오늘날 에이전트 시스템을 구축하는 실무자에게 핵심 통찰은 스킬 주입이 만능 솔루션이 아니라는 것입니다. 올바른 접근 방식은 에이전트의 역할, 필요한 스킬 수, 시간이 지남에 따라 학습해야 하는지 여부, 토큰 비용 대 신뢰성 트레이드오프에 대한 허용 범위에 따라 달라집니다.

가장 강력한 프로덕션 시스템은 여러 패턴을 결합할 것입니다—핵심 기능을 위한 상시 활성, 확장 스킬을 위한 점진적 공개, 축적된 지식을 위한 시맨틱 검색—효율적이면서도 전문적인 에이전트를 만들어냅니다.