에이전트 협업, 그러니까 우리 회사의 대표 에이전트가 고객사의 대표 에이전트와 일을 주고받고, 그 과정에서 우리 팀 에이전트가 다시 세부 작업을 처리하는 그림. 처음 들었을 때는 조금 먼 이야기 같았다. 그런데 결론부터 말하면, 이 구조는 이미 조각조각 현실이 되고 있다. 사람이 일일이 붙지 않아도 에이전트끼리 서로를 찾고 일을 위임하는 구조가 표준의 형태로 자리를 잡는 중이다.
이 글에서는 두 가지를 나눠서 이야기한다. 하나는 컴퓨팅 초보자였던 내가 Claude로 서버 작업을 해내면서 미리 맛본 협업의 장면 3가지고, 다른 하나는 이 흐름이 왜 결국 “딸깍” 한 번으로 원하는 걸 구현하는 시대로 이어지는지다. 거창한 지식 없이도 강력한 결과를 만들어내는 경험은, 생각보다 이미 가까이 와 있었다.
에이전트 협업이란 무엇인가 — 대표 에이전트끼리 일하는 구조
에이전트 협업은 서로 다른 곳에서 만들어진 AI 에이전트들이 사람의 중간 개입 없이 서로를 발견하고, 일을 나누고, 결과를 주고받는 구조를 말한다. 지금까지 우리가 쓰던 AI는 대부분 “사람 ↔ AI” 1:1 대화였다. 이 협업은 여기서 한 층 위로 올라간다. 내 에이전트가 상대편 에이전트에게 직접 말을 거는 구조다.
이게 공상이 아니라는 근거가 있다. 구글이 2025년 공개하고 리눅스 재단이 맡아 운영 중인 A2A 프로토콜이 바로 이 “에이전트 ↔ 에이전트” 대화를 위한 공용 규격이다. 2026년 4월 기준으로 v1.0 정식 버전이 나왔고, 150곳이 넘는 조직이 참여하며 주요 클라우드 플랫폼에 실제로 올라갔다. 프레임워크나 벤더가 서로 달라도 에이전트끼리 태스크를 주고받게 만든다는 게 핵심이다.
여기서 자주 헷갈리는 게 MCP와의 차이다. 둘은 경쟁이 아니라 층이 다른 짝이다.
| 구분 | MCP | A2A |
|---|---|---|
| 연결 대상 | 에이전트 ↔ 도구·API | 에이전트 ↔ 에이전트 |
| 흔한 비유 | 도구를 꽂는 USB-C | 에이전트끼리 대화하는 HTTP |
| 하는 일 | 에이전트에게 도구·맥락을 붙여줌 | 서로를 발견하고 일을 위임·협업 |
| 거버넌스 | 리눅스 재단 산하 | 리눅스 재단 산하 |
정리하면 MCP는 한 에이전트에게 손발(도구)을 달아주고, A2A는 그 에이전트가 다른 에이전트와 말을 트게 한다. 실제 시스템은 이 둘을 같이 쓴다. 에이전트끼리의 협업은 이 두 층이 맞물릴 때 비로소 그림이 완성된다.
초보자가 Claude로 서버 작업을 하며 미리 겪은 에이전트 협업
솔직히 나는 컴퓨팅에 강한 사람이 아니었다. 서버에 접근해서 서버와 서버로 넘어가는 작업을 처리하는 건, 초심자에게는 결코 만만한 일이 아니다. 그런데 Claude를 붙여 이 작업을 해나가는 과정에서, 나는 지금 말하는 그 협업의 축소판을 이미 겪고 있었다는 걸 뒤늦게 알아챘다. 장면으로 나눠보면 이렇다.
장면 1 — 질문을 내가 아니라 내 에이전트가 먼저 던진다
시스템에 붙어 작업하려면 API 명세서를 읽어야 한다. 초보자에게 이 명세서는 벽이다. 그래서 나는 명세서를 직접 해독하는 대신, 내 쪽 에이전트에게 “이 시스템을 쓰려면 뭘 먼저 알아야 하냐”를 물었다. 정작 질문을 설계한 건 내가 아니라 내 에이전트였다. 이 감각은 좋은 질문이 결국 엔지니어링의 본질이라는 이야기와 정확히 맞닿아 있었다.
장면 2 — 시스템 안의 봇에게 물어보고, 그 답으로 다시 빌드한다
어떤 시스템에는 그 시스템 자체를 설명해주는 봇이 있었다. 나는 내 에이전트가 정리해준 선(先)질문을 그 봇에게 전달하고, 돌아온 답을 다시 내 쪽으로 가져와 다음 단계를 쌓아 올렸다. 여기서 이미 “내 대리인”과 “상대 시스템의 대리인”이 질문과 답을 주고받고 있었던 셈이다. 이게 조직 단위로 커지면 우리의 AI가 상대 조직의 AI와 협상하는 그림이 된다.
장면 3 — API로 직접 통신하게 해서 실물을 주고받는다
마지막 단계에서는 아예 API로 직접 통신하게 만들어, 요청과 응답이라는 실물을 주고받으며 막힌 지점을 하나씩 풀어갔다. 내가 한 일은 방향을 잡고 판단하는 것뿐, 실제 대화의 상당 부분은 에이전트가 대신했다. 이 세 장면을 겪고 나니, 이 협업이 먼 미래의 개념이 아니라 지금 내 작업 방식의 연장선이라는 확신이 들었다.
에이전트 협업이 진짜가 되는 3가지 신호
내 경험이 개인적 우연이 아니라 흐름이라는 걸, 최근 표준의 움직임이 뒷받침한다. 에이전트 협업이 실험실 밖으로 나오고 있다는 신호를 3가지로 추렸다.
| 신호 | 무엇이 바뀌었나 | 초보자에게 주는 의미 |
|---|---|---|
| 공용 표준 | 에이전트 간 대화 규격이 정식 버전으로 자리 잡음 | 특정 벤더에 묶이지 않고 갈아탈 수 있음 |
| 상호 발견 | 에이전트가 자기 능력을 명함처럼 공개해 서로를 찾음 | 내가 일일이 연결을 짜지 않아도 됨 |
| 자동 위임 | 태스크는 물론 결제까지 위임하는 확장이 등장 | 사람 개입 지점이 계속 줄어듦 |
특히 두 번째 “상호 발견”이 핵심이다. 에이전트가 자기가 뭘 할 수 있는지를 표준 형식으로 선언해두면, 다른 에이전트가 그걸 읽고 알아서 적임자를 찾아 일을 넘긴다. 사람으로 치면 서로 명함을 교환하고 “이 일은 저쪽이 전문이네” 하고 넘기는 것과 같다. 협업이 사람의 조율 없이 굴러가기 시작하는 지점이 바로 여기다.
딸깍 한 번의 시대 — 초보자에게 이게 왜 결정적인가
이 흐름에서 내가 가장 크게 느낀 건, 강력한 배경지식이 없어도 원하는 걸 만들 수 있게 된다는 점이다. 예전이라면 명세서를 다 읽고, 통신 규약을 이해하고, 코드를 짜야 했다. 지금은 방향을 정하고 판단하는 사람이 있고, 질문을 설계하고 대화를 대신 처리하는 에이전트가 있으면 된다. 결국 남는 인간의 역할은 “무엇을, 왜 만들 것인가”에 대한 좋은 질문과 판단이다.
에이전트 협업이 여기에 얹히면, 초보자도 여러 시스템을 가로지르는 작업을 손쉽게 해낼 수 있다. 내 에이전트가 상대 시스템의 에이전트에게 묻고, 필요한 도구를 붙이고, 결과를 가져오는 과정을 대신 밟아주기 때문이다. 지금은 그 과정을 내가 한 단계씩 지켜보지만, 이 단계들이 하나로 묶이는 순간이 이른바 “딸깍”의 시대다. 원하는 걸 말하면, 에이전트들이 알아서 협업해 구현해 오는 시대. 나는 그 문턱을 초보자의 눈으로 이미 살짝 넘어봤다고 생각한다.
핵심 요약
에이전트 협업은 서로 다른 에이전트가 사람 개입 없이 일을 주고받는 구조이며, MCP(도구 연결)와 A2A(에이전트 연결)라는 두 층이 맞물려 완성된다. 컴퓨팅 초보자였던 나는 Claude로 서버 작업을 하며 질문을 대신 던지고, 시스템 봇과 문답하고, API로 실물을 주고받는 세 장면에서 이 협업의 축소판을 미리 겪었다. 공용 표준·상호 발견·자동 위임이라는 신호가 이 흐름을 뒷받침하고, 그 끝에는 강력한 지식 없이도 딸깍 한 번으로 원하는 걸 구현하는 시대가 있다. 남는 것은 좋은 질문과 판단이라는 인간의 몫이다.
함께 읽으면 좋은 글
이 협업이 조직으로 확장되면 “누가 지금 무엇을 잡아야 하는가”가 다음 질문이 된다.
