에이전트끼리 일을 나눈다 — A2A 프로토콜이 외주 개발 구조를 바꾸는 방식

한줄 요약

A2A 프로토콜은 AI 에이전트가 서로 역할을 나누고 작업을 위임하는 표준으로, 소프트웨어 설계 방식 전체를 바꾸고 있다.

본문

에이전트 간 통신(A2A, Agent-to-Agent)은 AI끼리 자연어로 대화하는 기능이 아니라, 서로 다른 실행 주체가 역할을 나누고 작업 결과를 주고받는 아키텍처 표준이다. 이 표준이 production 수준으로 자리 잡으면서, 소프트웨어를 어떻게 만들어야 하는지에 대한 질문이 근본부터 달라지고 있다.

에이전트가 '도구'에서 '실행 주체'로 바뀌면 무엇이 달라지나

기존 AI 연동 방식은 단순했다. 하나의 에이전트가 API를 호출하고, 파일을 읽고, 정해진 도구를 쓰는 구조였다. 사람이 버튼을 누르는 대신 에이전트가 누르는 형태에 가까웠다.

A2A가 가져오는 변화는 그 위 계층에 있다. 에이전트 하나가 전부 처리하는 게 아니라, 작업 성격에 따라 적합한 에이전트를 찾고 그쪽에 일을 넘긴다. 법무 검토는 법무 에이전트에게, 수치 검증은 회계 에이전트에게, 코드 수정은 개발 에이전트에게 위임하는 식이다. 이때 "어떤 에이전트가 무엇을 할 수 있고, 어떻게 호출하며, 결과는 어떤 형태로 돌아오는가"를 정의하는 것이 핵심이다.

이 구조에서는 작업 하나가 생성되고, 진행되고, 실패하거나 완료되는 전체 수명 주기를 추적하는 능력이 에이전트의 대화 능력보다 훨씬 중요해진다.

외주 개발 의뢰서에 'AI 연동'만 써도 될까

많은 기업이 개발 외주를 맡길 때 "AI 기능 추가"를 요구 사항에 넣는다. 그런데 지금 시점에서 그 요구가 무엇을 의미하는지 더 구체적으로 짚어볼 필요가 있다.

에이전트가 화면 위에서 클릭하고 입력하는 방식은 UI 구조가 바뀌면 바로 깨진다. 유지 보수 비용이 높고, 안정성도 낮다. 반면 에이전트가 직접 읽고 호출할 수 있는 API, 구조화된 엔드포인트, 명확한 인증 흐름을 갖춘 시스템은 훨씬 견고하다.

이것이 "에이전트를 1급 사용자로 두고 설계한 소프트웨어"와 "나중에 AI를 붙인 소프트웨어"의 차이다. 처음부터 에이전트가 가입하고, 인증받고, 기능을 호출하고, 결과를 가져갈 수 있도록 설계된 시스템은 구조 자체가 다르다. 외주 개발을 의뢰하는 시점에 이 설계 방향을 명확히 하지 않으면, 나중에 전면 재설계가 필요할 수 있다.

MCP와 A2A, 개발 범위가 어떻게 달라지나

외주 개발사 입장에서 두 프로토콜을 혼동하면 범위 산정이 틀어진다.

MCP(Model Context Protocol)는 에이전트가 데이터베이스, 외부 API, 파일 시스템 같은 하위 도구와 연결되는 방식을 정의한다. 에이전트가 무엇을 쓸 수 있는지에 관한 계층이다.

A2A는 그 위에 있다. 에이전트가 다른 에이전트에게 일을 맡기고, 진행 상태를 확인하고, 결과를 받아 검증하는 계층이다. 여러 에이전트가 협업하는 워크플로를 구성할 때 A2A가 필요해진다.

두 계층을 구분하지 않으면 범위가 뭉뚱그려진다. "에이전트 연동"이라는 한 줄짜리 요구 사항이 실제로는 도구 연결인지, 에이전트 간 협업 흐름 구현인지에 따라 개발 공수와 아키텍처 설계가 완전히 달라진다.

---

멀티 에이전트 구조, 무조건 복잡하게 짤 필요 없다

에이전트가 여러 개 연결되는 구조가 항상 더 좋은 건 아니다. 에이전트가 늘수록 작업 인계 지점이 늘고, 맥락이 잘리고, 응답 속도가 느려지고, 문제가 생겼을 때 원인을 찾기도 어려워진다.

멀티 에이전트 구조가 실제로 유리한 경우는 따로 있다. 도메인별로 전문성과 권한 경계가 명확히 나뉘어야 하거나, 한 에이전트의 결과를 다른 에이전트가 독립적으로 검증해야 하거나, 오래 걸리는 작업을 병렬로 처리해야 할 때다. 반대로 작업이 단순하고 짧으며 맥락을 하나로 유지해야 한다면 단일 에이전트가 더 나은 선택이다.

외주 개발을 의뢰하거나 수행할 때, "멀티 에이전트니까 더 고도화된 것"이라는 전제는 위험하다. 구조의 복잡도는 실제 문제의 성격에서 나와야 한다.

에이전트 통신 시스템을 운영한다는 것의 의미

에이전트끼리 연결되는 시스템을 프로덕션에 올리면, 프로토콜 설계보다 운영 설계가 더 까다롭다.

어떤 에이전트가 누구의 권한으로 작업을 실행했는지, 중간에 실패했을 때 어디서 끊겼는지, 민감한 데이터가 어느 에이전트에게까지 전달됐는지를 추적할 수 있어야 한다. 호출마다 인증을 검증하고, 권한 범위를 제한하고, 결과와 실패 이력을 로그로 남기는 구조가 없으면 장애 대응도, 감사도 불가능하다.

에이전트 카드가 위조되거나, 권한이 연쇄적으로 넘겨지는 과정에서 범위가 의도치 않게 확장되거나, 프롬프트 인젝션이 에이전트를 타고 전파되는 문제는 연결이 늘어날수록 실제로 발생한다. 이런 요소는 기능 구현 이후에 붙이는 게 아니라, 아키텍처 설계 단계에서 함께 다뤄야 한다.

개발 외주를 맡길 때 "AI 에이전트 연동"을 요구한다면, 운영 관점에서의 로그 설계, 권한 전파 정책, 장애 처리 흐름이 범위에 포함되어 있는지 함께 확인해야 한다.