프레임워크를 넘어: 멀티 에이전트 이식성(Portability)과 벤더 독립성을 위한 설계

대부분의 기업은 현재 "프레임워크 우선(framework-first)" 방식의 에이전트 시스템을 구축하고 있습니다. 이들은 인기 있는 오케스트레이션(orchestration) 라이브러리를 선택하고, 그 라이브러리의 독점적인 프리미티브(primitives)에 비즈니스 로직을 직접 구축하며, 하단의 LLM(대규모 언어 모델)만이 유일한 변수라고 가정합니다. 이는 실수입니다. 진정한 락인(lock-in)은 모델이 아니라, 비즈니스 로직을 특정 벤더의 사고방식에 결합시키는 상태 관리(state management), 오케스트레이션 로직, 그리고 도구 호출(tool-calling) 스키마에서 발생합니다.

만약 핵심 로직을 완전히 새로 작성하지 않고는 에이전트를 한 프레임워크에서 다른 프레임워크로 옮길 수 없다면, 당신은 에이전트 지적 재산권을 소유하고 있는 것이 아닙니다. 당신은 단지 그것의 특정 구현체를 임대하고 있을 뿐입니다.

에이전트 락인(Agentic Lock-in)의 구조

왜 우리는 10년 전 클라우드 제공업체들에게서 보았던 것과 동일한 락인 패턴에 계속해서 빠져드는 것일까요? 프레임워크 네이티브(framework-native) 기능이 약속하는 "개발 속도(developer velocity)"가 아키텍처 경계를 무시하게 만드는 강력한 유인책을 제공하기 때문입니다.

락인은 오케스트레이션 프레임워크를 인프라가 아닌 애플리케이션으로 취급할 때 발생합니다. 벤더의 독점적인 "메모리(memory)" 저장소를 사용할 때, 당신은 단순히 상태를 저장하는 것이 아니라 표준 형식으로 내보낼 수 없는 특정 그래프(graph)나 벡터(vector) 표현 방식을 채택하게 되는 것입니다. 만약 해당 벤더가 가격을 변경하거나 성능이 저하된다면, 단순히 데이터베이스를 "교체"하는 것만으로는 부족합니다. 에이전트의 인지 상태(cognitive state) 전체를 마이그레이션해야 합니다.

프레임워크의 내부 DSL(Domain Specific Language)에 프롬프트 템플릿을 하드코딩하는 것 또한 흔한 실패 사례입니다. 비즈니스 로직이 "시스템 프롬프트(system prompts)"나 "퓨샷 예시(few-shot examples)"를 처리하는 벤더 특유의 방식과 뒤엉키게 되면, 당신은 사실상 독점적인 언어로 코드를 작성하고 있는 것과 다름없습니다.

그리고 "자율적 (autonomic)" 기능들이 있습니다. 이러한 기능들은 "자동 도구 선택 (automatic tool selection)"이나 "자기 수정 루프 (self-correction loops)"와 같은 고수준의 추상화 (abstractions)로, POC (Proof of Concept) 단계에서는 마치 마법처럼 느껴집니다. 하지만 이러한 기능들은 투명한 API 대응책이 없는 경우가 많습니다. 만약 오류 복구 (error recovery)를 처리하기 위해 프레임워크의 내부 "블랙박스 (black box)"에 의존한다면, 당신은 신뢰성 로직 (reliability logic)을 제3자에게 외주 준 것이나 다름없습니다.

이는 장기적인 TCO (Total Cost of Ownership, 총 소유 비용)의 급격한 상승을 초래합니다. 복잡한 고객 지원 에이전트를 독점적인 프레임워크에서 오픈 소스 대안으로 마이그레이션하는 비용은 단순히 몇 주간의 리팩토링 (refactoring) 수준이 아니라, 에이전트의 행동 로직 (behavioral logic)을 완전히 새로 구축해야 하는 작업임을 알게 될 것입니다. 이것이 바로 우리가 agentic AI economics 분석에서 상세히 다루었던 프레임워크 우선 (framework-first) 접근 방식의 숨겨진 세금입니다.

밀접하게 결합된 아키텍처 vs. 추상화된 에이전트 아키텍처

에이전트 추상화 계층 (Agent Abstraction Layer): 의도와 실행의 분리

프레임워크에 구애받지 않는 (agnostic) 시스템을 실제로 구축할 수 있을까요? 네, 하지만 이는 "프레임워크 우선 (Framework-First)"에서 "추상화 우선 (Abstraction-First)" 아키텍처로의 전환을 필요로 합니다.

해결책은 에이전트 추상화 계층(Agent Abstraction Layer, AAL)입니다. AAL의 목표는 '의도(intent)' (에이전트가 달성해야 할 것)와 '실행(execution)' (프레임워크가 이를 어떻게 수행하는지)를 분리하는 것입니다. 이 모델에서 핵심 비즈니스 로직은 목표, 제약 조건, 그리고 필요한 도구를 정의합니다. AAL은 이러한 요구 사항을 기반 프레임워크가 필요로 하는 특정 API 호출로 번역합니다.

이는 OS의 하드웨어 추상화 계층(Hardware Abstraction Layer)과 같다고 생각해보세요. 애플리케이션은 NVMe 드라이브에 쓰는 것인지 SATA SSD에 쓰는 것인지는 신경 쓰지 않습니다. 그저 write()를 호출할 뿐입니다. 에이전트 로직 역시 독점적인 그래프 기반 오케스트레이터(graph-based orchestrator)에서 실행되는지 아니면 단순한 선형 체인(linear chain)에서 실행되는지는 알 필요가 없습니다.

하지만 함정이 있습니다. 추상화 계층을 추가할 때마다 지연 시간(latency)이 발생합니다. 에이전트가 연속으로 다섯 개의 도구를 호출할 수 있는 실시간 에이전틱 루프(agentic loop)에서, 번역 계층에 호출당 50ms의 오버헤드를 추가하는 것은 사용자 경험을 저하시킬 수 있습니다. 어디까지를 허용할지 결정해야 합니다.

대부분의 엔터프라이즈 사용 사례에서는 그 트레이드오프가 가치가 있습니다. 가격이 400% 인상되거나 치명적인 장애를 겪는 특정 벤더에 종속될 위험은 몇 밀리초(milliseconds)의 지연 시간보다 훨씬 큽니다.

AAL은 다음을 처리해야 합니다:

1. 상태 번역(State Translation): 프레임워크별 메모리 객체를 표준화된 JSON 상태로 매핑합니다.
2. 프롬프트 매핑(Prompt Mapping): '페르소나'와 '지침(instructions)'을 프레임워크의 템플릿 엔진으로부터 분리합니다.
3. 도구 디스패칭(Tool Dispatching): 도구 호출이 프레임워크 네이티브 바인딩(framework-native bindings)보다는 일반적인 레지스트리(generic registry)를 기반으로 라우팅되도록 보장합니다.

이러한 전환은 단일 봇 POC에서 엔터프라이즈 에이전트 패브릭으로 이동할 때 매우 중요합니다.

에이전트 포터빌리티 스택 (The Agent Portability Stack)

크로스 프레임워크 포터빌리티를 위한 툴체인 표준화

한 에이전트에서 작동하는 툴이 어떤 벤더에 관계없이 다른 에이전트에서도 작동하도록 어떻게 보장할 수 있을까요? 프레임워크별 툴 데코레이터를 사용하는 것을 중단하고 업계 표준 스키마를 사용하기 시작하면 됩니다.

OpenAPI 사양이나 JSON Schema를 사용하여 툴을 정의하면, 포터블한(portable) 기능을 갖게 됩니다. 툴은 단순히 입력과 출력을 가진 함수일 뿐입니다. 이를 표준 형식으로 정의하면, 툴 호출(tool-calling)을 지원하는 모든 LLM 또는 프레임워크가 이를 사용할 수 있습니다.

데이터 거주지 요구 사항 때문에 주요 LLM 제공업체를 교체해야 하는 보안 팀을 가정해 봅시다. 만약 그들의 툴 호출 로직이 특정 벤더의 SDK에 하드 코딩되어 있다면, 그들은 갇히게 됩니다. 하지만 중앙 집중식 툴 레지스트리(Tool Registry)를 사용한다면 전환은 사소합니다. 이 레지스트리는 OpenAPI 사양을 보유하고 있으며, AAL이 해당 사양을 새로운 LLM이 기대하는 형식으로 변환합니다.

{
 "tool_id": "get_customer_lifetime_value",
 "description": "Retrieves the total revenue generated by a customer",
...

툴을 독립적인 자산으로 취급함으로써, 힘의 중심을 프레임워크에서 데이터 계층(data layer)으로 되돌릴 수 있습니다.

그리고 통신(communication)에 대해서도 이야기해야 합니다. 여러 에이전트를 실행하는 경우, 독점적인 메시지 형식(proprietary message formats)에 의존할 수 없습니다. Agent Protocol과 같은 표준화된 프로토콜(standardized protocols)은 에이전트가 자신의 상태를 전달하거나, 도움을 요청하거나, 작업을 인계(hand off)하기 위한 공통 언어를 제공합니다. 이는 Vendor A의 "최고 수준(best-of-breed)" 에이전트와 Vendor B의 "최고 수준(best-of-breed)" 에이전트를 통합할 때 발생하는 마찰을 줄여줍니다.

이기종 에이전트 생태계의 오케스트레이션 (Orchestrating Heterogeneous Agent Ecosystems)

기업 내의 모든 에이전트를 단일 벤더가 제어하기를 진정으로 원하시나요? 아마 아닐 것입니다. 아마도 한 벤더의 합성(synthesis) 능력이 세계 최고 수준인 "연구 에이전트(Research Agent)"와, 다른 벤더의 API 통합 능력이 더 뛰어난 "실행 에이전트(Execution Agent)"를 함께 사용하게 될 가능성이 높습니다.

여기서의 과제는 상태 유지 인계(stateful hand-off)입니다. 연구 에이전트가 원래 요청의 컨텍스트(context)를 잃지 않으면서 어떻게 자신의 조사 결과를 실행 에이전트에게 전달할 수 있을까요?

정답은 공통 통신 버스(common communication bus)입니다. 에이전트들이 독점적인 API를 통해 서로 직접 대화하는 대신, 프레임워크에 구애받지 않는(framework-agnostic) 공유 버스에 상태 업데이트를 게시(publish)하는 방식입니다. 이 버스는 대화의 "신뢰할 수 있는 단일 원천(source of truth)" 역할을 합니다.

연구 에이전트가 작업을 완료하면 실행 에이전트를 "호출(call)"하는 것이 아닙니다. 대신 task_completed 이벤트를 통해 공유 상태를 업데이트하고, 표준화된 JSON 형식으로 합성된 데이터를 첨부합니다. 버스를 모니터링하고 있는 실행 에이전트는 해당 이벤트를 확인하고 작업을 이어받습니다.

하지만 주의해야 합니다. 여기에는 위험 요소가 있습니다: 바로 "최저 공통 분모(lowest common denominator)"의 함정입니다. 만약 벤더의 고유하고 가치 있는 기능을 사용할 수 없을 정도로 모든 것을 추상화한다면, 애초에 해당 벤더를 구매했던 이유 자체를 무력화하는 셈이 됩니다.

목표는 벤더의 기능을 무시하는 것이 아니라, 이를 격리하는 것입니다. 실행(execution)을 위해서는 벤더의 "마법(magic)"을 사용하되, 오케스트레이션(orchestration)과 상태 관리(state management)는 자체적인 이식 가능한 레이어(portable layer)에 유지하십시오. 이를 통해 특정 프레임워크의 고급 기능을 사용하면서도, 해당 벤더가 실패할 경우를 대비한 마이그레이션 경로(migration path)를 유지할 수 있습니다. 이것이 멀티 에이전트 오케스트레이션 패턴 (multi-agent orchestration patterns)의 핵심입니다.

교차 벤더 에이전트 핸드오프 시퀀스 (Cross-Vendor Agent Handoff Sequence)