REST API의 한계와 A2A(Agent-to-Agent) 표준의 등장
기업 내부 시스템에 AI 에이전트를 연결하려는 개발자는 API 규격 불일치라는 벽에 부딪힌다. 기존 시스템의 입출력 형식을 AI가 이해하도록 바꾸려면 방대한 양의 코드를 새로 짜야 하는 재개발 부담이 따르기 때문이다. 이를 해결하기 위해 등장한 A2A(Agent-to-Agent) 표준은 자율적인 AI 에이전트들이 서로를 발견하고 추론하며 협업할 수 있도록 돕는 통신 규격이다.
기존 기업 아키텍처의 중심인 REST API는 결정론적 통합을 지향한다. 클라이언트가 정해진 엔드포인트에 파라미터를 전달하면 서버가 예측 가능한 응답을 돌려주는 무상태(Stateless) 흐름을 따른다. HTTP 시맨틱 기반의 이 구조는 생성, 조회, 수정, 삭제와 같은 비즈니스 기능을 명확한 계약 하에 제공하며 운영 효율성이 높다.
반면 A2A는 자율 에이전트 간의 상호운용성에 최적화되어 있다. 에이전트들은 에이전트 카드(Agent Card, 기능과 특성을 정의한 메타데이터 문서)를 통해 서로의 능력을 발견하고 협상한다. 통신 방식은 JSON-RPC 기반의 구조화된 메시지를 교환하며, 단일 엔드포인트 호출에 집중하는 REST와 달리 추론 기반의 조정과 작업 중심 메시징을 통해 다단계 작업(Multi-step tasks)을 계획하고 위임한다.
REST API와 에이전트 시스템은 서로 다른 통신 방식과 설계 원칙을 가지고 있어 기존 서비스를 표준화된 에이전트 통신으로 옮기기가 어렵다. 표준 프로토콜을 적용하려면 핵심 로직을 다시 작성해야 하며, 이 과정에서 기존 기능이 정상 작동하는지 확인하는 회귀 테스트(Regression Test) 부담이라는 리스크를 떠안게 된다.
에이전틱 오버레이의 작동 방식과 메시지 변환 패턴
에이전틱 오버레이(Agentic Overlay)는 기존 REST API를 수정하지 않고도 A2A 통신이 가능한 형태로 변환하는 얇은 인터페이스 층이다. 개발자는 기존 비즈니스 로직을 유지하면서 시스템을 AI 에이전트 환경으로 빠르게 통합할 수 있다.
작동 구조는 동일한 호스트와 포트 내에서 기존의 `/api/v2/...` 경로와 새로운 `/a2a/...` 경로를 병행 운영하는 방식이다. A2A 메시지가 수신되면 이를 REST API 메시지로 변환해 기존 서비스에 전달하고, 결과값을 다시 A2A 형식으로 반환하는 메시지 변환 디자인 패턴을 사용한다. 이 과정에서 에이전트 카드와 메시지 엔드포인트, 기능(Capabilities), 기술(Skills), 상태 확인(Health) 등의 구성 요소가 추가되어 기존 서비스에 에이전트 기능을 부여한다.
구현 단계에서는 메시지 페이로드(Payload)를 추출하는 로직이 핵심이다. `extract_message_payload()` 함수를 통해 일반 메시지 전송인 `SendMessage`와 스트리밍 방식인 `SendStreamingMessage`를 모두 처리하여 일관된 데이터 흐름을 만든다.
def extract_message_payload(message):SendMessage와 SendStreamingMessage 모두에서 페이로드를 추출하여 처리
return message.get('payload')
처리 시간이 긴 보고서 생성이나 데이터 분석 작업에는 SSE(Server-Sent Events)를 적용해 스트리밍으로 결과를 전달한다. 즉각적인 결과가 나오는 계산기 서비스와 달리 장기 실행 작업은 SSE를 통해 증분 업데이트를 푸시하여 사용자 경험을 개선한다.
레거시 전환을 위한 세 가지 접근법 비교
AI 에이전트를 도입할 때 고려해야 할 핵심은 개발 비용과 유지보수 리스크다. 먼저 '분리 스택 방식'은 기존 시스템을 둔 채 REST와 A2A 스택을 각각 별도로 개발한다. 동일한 기능을 두 가지 경로로 제공해야 하므로 서버 자원이 이중으로 사용되고, 업데이트 시 두 경로를 모두 수정해야 하는 리소스 낭비가 발생한다.
'공유 로직 리팩토링 방식'은 비즈니스 로직을 공유 서비스로 추출해 REST와 A2A 인터페이스가 함께 호출하게 만든다. 하지만 내부 구조를 변경하면 기존과 다르게 동작하는 현상이 발생할 가능성이 크며, 이는 결국 전체 시스템에 대한 대규모 회귀 테스트 부담으로 이어져 전환 기간을 늘린다.
'에이전틱 오버레이'는 기존 REST 엔드포인트를 그대로 유지하며 A2A 인터페이스만 얇게 덧씌우는 래퍼 층을 추가한다. 핵심 비즈니스 로직을 전혀 수정하지 않으므로 기존의 빌드, 테스트, 릴리스, 롤백으로 이어지는 단일 배포 파이프라인을 그대로 사용할 수 있다. 인프라를 새로 구축하지 않고 기존 서비스를 에이전트로 재사용함으로써 관리 비용을 낮춘다.
세 가지 방식의 차이는 로직 수정 여부와 인프라 중복 정도에 있다. 분리 스택은 인프라 비용이 높고 리팩토링은 검증 비용이 높지만, 오버레이는 두 리스크를 모두 낮추며 안정적인 운영 경로를 제공한다.
인프라 효율성과 MCP(Model Context Protocol) 확장성
에이전틱 오버레이는 기존 서비스를 에이전트로 재사용해 AI 에이전트가 무분별하게 늘어나 관리 효율이 떨어지는 에이전트 확산(Agent Sprawl) 현상을 억제한다. 별도의 병렬 인프라를 구축하지 않고 기존 REST API를 활용해 에이전트 기능을 구현하기 때문이다.
또한 REST API를 MCP(Model Context Protocol, 모델이 외부 도구와 데이터를 표준화된 방식으로 주고받는 프로토콜)와 호환되는 도구로 노출해 확장성을 확보한다. 별도의 MCP 서버를 구축하지 않고도 에이전트 기술(Agent Skills)을 통해 에이전트 범위 내에서 요청을 직접 라우팅할 수 있다. 외부 서비스를 호출하기 위해 MCP 서버를 거치는 단계를 생략하고 보유한 모든 엔드포인트를 즉시 에이전트 기술로 노출함으로써 인프라 계층을 단순화하고 도구 호환성을 유지한다.
FastAPI 및 Starlette 애플리케이션을 위한 공식 A2A SDK(소프트웨어 개발 키트)가 제공되어 `/a2a/` 경로 추가 시 발생하는 복잡한 설정과 메시지 변환 과정을 추상화한다. Flask 애플리케이션에서도 A2A 라이브러리를 사용할 수 있으며, 공식 SDK는 프레임워크의 비동기 처리 특성을 활용해 메시지 변환 효율을 높인다. 개발자는 이를 통해 기존 웹 서비스에 에이전트 인터페이스를 빠르게 덧씌우고 표준화된 메시지 규격을 즉시 적용할 수 있다.
한국 기업의 레거시 시스템 현대화 실무 적용점
Flask 등으로 구축한 레거시 계산기 서비스나 기업 내부 관리 시스템처럼 오래된 모놀리식 시스템일수록 작은 수정이 전체 시스템의 장애로 이어질 위험이 크다. 이런 환경에서 에이전틱 오버레이는 비즈니스 로직을 건드리지 않고 인터페이스만 확장하므로 시스템 전체를 재설계하거나 데이터를 마이그레이션할 필요가 없다.
이 방식은 특히 기능 범위가 제한적이면서 사용자의 의도를 분류하는 의도 분류(Intent Classification)와 적절한 서비스로 연결하는 라우팅 중심의 슈퍼바이저 에이전트를 구축할 때 최적의 효율을 낸다. 복잡한 연산이나 데이터 처리는 기존 REST 서비스가 담당하고, 오버레이 층은 에이전트 간의 협업과 메시지 변환만 처리하기 때문이다.
결국 핵심은 비즈니스 로직의 안정성과 AI 확장성 사이의 균형을 잡는 것이다. 서비스 안정성이 최우선인 엔터프라이즈 환경에서는 검증된 REST API를 그대로 둔 채 A2A 기능을 덧씌우는 방식이 가장 현실적인 대안이 된다. 이는 불필요한 병렬 인프라 구축을 억제하고 기존 서비스의 활용도를 극대화하여 시스템 현대화 비용을 낮춘다.
비즈니스 로직을 수정하지 않고 인터페이스 층만 추가하는 방식은 개발 공수와 시스템 안정성 사이의 충돌을 해결하는 실질적인 대안이다. 기존 /api/v2/ 경로를 유지하며 /a2a/ 경로를 추가하는 설계는 레거시 시스템의 회귀 테스트 부담을 최소화하며 AI 환경으로의 전환 속도를 높인다.
결국 AI 에이전트 도입의 성패는 전체 시스템을 재구축하는 과감함이 아니라, 기존 자산을 얼마나 안전하게 래핑하여 리스크를 통제하느냐에 달려 있다. 현재 운영 중인 REST API의 수정 범위와 회귀 테스트 비용을 대조하여 오버레이 도입의 적절성을 판단하는 것이 가장 효율적인 시작점이다.
