에이전트는 서로를 어떻게 찾는가 — 발견, 그리고 에이전트의 '명함'

사람 사이의 협업은 대개 명함 한 장에서 시작한다. 이름, 하는 일, 연락처가 적혀 있어서 "이 사람에게 무엇을 부탁할 수 있는지"를 만나자마자 안다. AI 에이전트에게도 이런 명함이 있다 — Agent Card다. A2A(Agent2Agent)와 ACP(Agent Communication Protocol) 계열 프로토콜이 협업을 시작하는 방식이 이 명함을 주고받는 것이다.

그런데 명함 이야기부터 꺼내면 순서가 뒤집힌다. 명함을 받으려면 상대가 어디 있는지부터 알아야 하기 때문이다. 사람도 명함을 받기 전에 "그런 일을 하는 사람이 어디 있는지"를 먼저 수소문한다. 에이전트도 똑같다. 그래서 이 글은 명함이 아니라 발견(discovery)에서 출발한다. 상대를 찾고, 확인하고, 그제야 명함을 펼친다.

발견 — 당사자에게 묻는가, 아닌가

발견 방식은 여러 갈래인데, 갈래를 가르는 기준은 결국 하나다. 그 명함을 당사자에게서 직접 받았는가, 아니면 제3자나 사본에서 얻었는가.

다이어그램 설명. "한→영 기술번역을 해 줄 에이전트가 필요하다"는 하나의 요구가 두 갈래로 갈리고, 각 갈래가 다시 구체적인 방식으로 나뉜다. 위쪽 갈래는 상대와 한 마디도 나누지 않고 알아내는 방법들이고, 아래쪽 갈래는 살아 있는 상대를 직접 때리는 방법들이다. 각 방식 아래 화살표로 붙인 한 줄이 이 그림의 핵심이다 — 같은 "발견"이라는 말을 쓰지만, 어떤 건 진짜 찾는 것이고 어떤 건 이미 아는 상대를 확인하는 것에 불과하다. 아래에서 하나씩 짚는다.

참고로 ACP 스펙은 이 두 갈래를 "오프라인 발견"과 "온라인 발견"이라 부른다. 스펙을 읽을 때 마주칠 이름이니 알아 둘 필요는 있지만, 솔직히 좋은 이름은 아니다. "오프라인"이라고 하면 네트워크를 안 탄다는 뜻으로 읽히는데, 명함첩 서버에 질의하는 것도 엄연히 네트워크 통신이다. 이 이름이 나온 건 ACP가 관심을 둔 상황(외부 망이 끊긴 폐쇄망, 평소엔 꺼 두는 에이전트) 때문인데, 그건 결과지 기준이 아니다. 당사자에게 안 물으니까 상대가 꺼져 있어도 되는 것이지, 그 반대가 아니다. 이 글은 원인 쪽 이름으로 부르겠다.

당사자에게 묻지 않는 발견 — 제3자와 사본에서

카탈로그(레지스트리) — 진짜 '찾기'는 여기서 일어난다

명함첩 역할을 하는 중개 서버가 여러 에이전트의 명함을 모아 둔다. 클라이언트는 "한→영 기술번역 가능한 에이전트 있나?"처럼 능력을 조건으로 질의해 후보 목록을 받는다. 기업 내부 마켓플레이스나 공개 에이전트 디렉터리가 이 모양이다.

다섯 방식 중 이것만이 "상대를 모르는 상태에서 시작"할 수 있다. 나머지는 전부 상대를 이미 어느 정도 지목한 상태를 전제한다. 그런 의미에서 진짜 발견은 레지스트리에서만 일어난다. 당사자가 꺼져 있어도 되는 이유는 명함첩이 명함 사본을 들고 있기 때문이다 — 사람을 만나지 않고도 명함첩만 넘겨 보면 되는 것과 같다.

그런데 여기 함정이 있다. A2A는 아직 레지스트리 API를 표준화하지 않았다. 명함의 형식은 표준인데, 그 명함을 모아 두는 명함첩을 어떻게 검색할지는 각자 알아서다. 가장 중요한 조각이 가장 덜 표준화돼 있는 셈인데, 이 이야기는 마지막에 다시 하겠다.

패키지 동봉 — 배포물 안에 명함을 구워 넣는다

ACP가 특히 공들인 방식이다. 에이전트를 배포할 때 컨테이너 이미지 라벨이나 번들 메타데이터 파일에 명함을 아예 박아 넣는다. 그러면 에이전트를 설치하거나 실행하기 전에 능력을 훑어볼 수 있다. 앱을 설치하기 전에 스토어에서 소개를 읽어 보는 것과 같은 이치다.

이게 왜 중요한가. 두 가지 상황에서 결정적이다. 하나는 망이 끊긴 환경 — 외부 네트워크가 차단된 폐쇄망에서도 손에 쥔 배포물만으로 "이게 뭘 하는 물건인지" 알 수 있다. 다른 하나는 평소엔 꺼 두는 에이전트다. 요청이 올 때만 켜졌다가 다시 잠드는 식으로 운영하면 비용이 크게 줄지만, 꺼져 있는 동안에는 아무도 그 에이전트를 발견할 수 없다는 문제가 생긴다. 명함을 배포물에 미리 구워 두면 이 딜레마가 풀린다.

덤으로 따라오는 이점도 있다. 빌드 시점에 명함을 박으면 명함과 실제 구현이 어긋날 수가 없다. 코드를 고쳤는데 명함 갱신을 깜빡해 "할 수 있다고 광고했지만 못 하는" 사태가 구조적으로 막힌다. 사본을 쓰면서도 사본이 낡지 않게 만드는 영리한 수다 — 이게 왜 영리한지는 바로 다음 절에서 드러난다.

직접 설정 — 애초에 찾을 게 없는 경우

설정 파일이나 환경변수에 상대 주소를 박아 두는 것이다. 소박해 보이지만 현실에서 압도적으로 많이 쓰이고, 상대가 고정된 사내 시스템에서는 이게 정답이기도 하다. 발견이랄 것도 없이 그냥 아는 것이다. 다만 "서로 다른 회사가 만든 에이전트가 사전 약속 없이 협업한다"는 프로토콜의 원래 야심과는 정반대에 서 있다.

사본에는 대가가 따른다

세 방식의 공통점을 짚고 넘어가자. 전부 당사자가 아닌 곳에서 명함을 얻는다 — 명함첩에서, 배포물에서, 내 설정 파일에서. 그래서 상대가 꺼져 있어도 되고, 상대를 몰라도 시작할 수 있다.

대가는 그 사본이 낡았을 수 있다는 것이다. 명함첩에 등록된 뒤 에이전트가 능력을 늘렸거나, 엔드포인트 주소를 옮겼거나, 아예 서비스를 접었을 수도 있다. 그런데 명함첩은 여전히 옛 명함을 내민다. 사람으로 치면 몇 년 전 받아 서랍에 넣어 둔 명함으로 전화를 거는 것과 같다 — 그 사람은 이미 이직했을지 모른다. 앞 절에서 본 "빌드 시점에 명함을 구워 넣기"가 영리한 이유가 여기 있다. 사본을 쓰되, 사본과 실물이 같은 순간에 태어나게 해서 낡을 여지를 원천 차단하는 것이다.

당사자에게 직접 묻는 발견

공개 명함 확인 — '찾기'가 아니라 '확인'

웹에는 오래된 관습이 하나 있다. 도메인 아래 예측 가능한 고정 경로에 메타 정보를 두는 것이다. 인증서 발급 시 서버 소유권을 증명하는 경로, 보안 담당자 연락처를 적어 두는 파일 같은 것들이 전부 이 관습을 따른다. RFC 8615가 표준화한 /.well-known/ 경로 접두어다.

A2A도 이걸 그대로 빌려, /.well-known/agent-card.json을 명함의 표준 자리로 삼는다. 도메인만 알면 명함이 있는 경로를 곧바로 유추해 가져올 수 있다. 당사자의 서버에서 직접 받아 오는 것이니 낡은 사본 문제가 없다 — 앞 절의 대가를 치르지 않는 대신, 상대가 켜져 있어야 한다는 조건이 붙는다.

(사소하지만 실전에서 아픈 함정 하나 — 이 파일명은 A2A v0.3에서 agent.json에서 agent-card.json으로 바뀌었다. 옛 튜토리얼을 그대로 베끼면 클라이언트가 찾는 경로에 아무것도 없어서, 에러도 없이 조용히 발견에 실패한다. 발견이라는 게 얼마나 얇은 약속 위에 서 있는지 보여주는 장면이다.)

편리하지만 냉정하게 보면 이건 발견이 아니라 확인이다. "번역 에이전트를 찾아라"에 답하는 게 아니라, "translate.example.com이라는 데가 있다던데, 거기가 번역을 할 줄 아나 확인해 봐라"에 답한다. 도메인을 어떻게 알았는지는 이 방식이 답해 주지 않는다. 앞서 본 명함첩이 알려줬거나, 사람이 어디서 주워듣고 설정에 박아 뒀거나 — 어느 쪽이든 이 단계 이전에 이미 풀려 있어야 한다. 당사자에게 물으려면 당사자가 누구인지부터 알아야 하니, 당연한 귀결이다.

인증된 확장 명함 — 아무나 못 보는 능력

공개 명함에는 한계가 있다. 누구나 볼 수 있으니 민감한 능력이나 내부용 기능을 적어 둘 수 없다. 그래서 A2A는 신원을 증명한 상대에게만 더 자세한 명함을 내주는 장치를 뒀다. 공개 명함에 "나는 확장 명함도 제공한다"는 표시를 해 두면, 클라이언트가 토큰을 들고 다시 요청해 공개 명함에는 없던 능력까지 담긴 판본을 받는다.

이 방식은 당사자에게 묻는 것 말고는 방법이 없다. 상대가 내 신원을 검사하고 그에 맞춰 다른 답을 주는 것이므로, 명함첩에 사본을 떠 둘 수가 없다. 누구에게 보여줄 판본인지가 요청하는 쪽에 따라 달라지기 때문이다. 사람으로 치면 명함을 받은 뒤 "사실 저희가 이런 것도 합니다"라는 이야기를 신뢰가 생긴 다음에야 듣는 것과 같다.

그래서 손에 쥔 명함에는 무엇이 적혀 있나

이제 발견을 통과해 명함을 손에 쥐었다. 여기에 무엇이 적혀 있길래 협업을 시작할 수 있는가. Agent Card는 에이전트가 자기 자신을 기계가 읽을 수 있는 형태(주로 JSON — 데이터를 이름:값 쌍으로 적는 텍스트 형식)로 소개하는 문서다.

다이어그램 설명. 하나의 "Agent Card"가 다섯 갈래 정보로 펼쳐지는 그림이다. "이름 · 설명"은 사람이 읽는 소개이고, 나머지 넷은 기계가 협업을 결정하는 데 쓴다. 가장 중요한 항목은 "능력 목록"이다 — "번역"처럼 뭉뚱그린 게 아니라 "한→영 기술문서 번역", "영→한 계약서 번역" 식으로 구체적인 기술(skill)을 나열해, 상대가 "내가 지금 필요한 그 일을 이 에이전트가 정말 할 수 있는지"를 판별하게 한다. 앞서 본 명함첩이 능력으로 검색할 수 있는 것도 바로 이 항목 덕분이다. "엔드포인트 주소"는 실제로 작업 요청을 보낼 URL이고, "입출력 형식"은 텍스트만 받는지 이미지도 받는지를 미리 알려 헛걸음을 막는다. "인증 방식"은 아무나 부를 수 있는지, 토큰이 필요한지를 명시한다. 즉 이 한 장이면 협업에 필요한 판단을 실제 요청을 보내기 전에 끝낼 수 있다.

발견에서 위임까지 — 실제 순서

지금까지 본 조각을 하나로 꿰어 보자. 명함첩으로 시작하는 경우다 — 상대를 미리 지목해 두지 않은, 가장 야심 찬 시나리오이기 때문이다.

다이어그램 설명. 위임 한 건이 일곱 단계로 진행되는 순서도다. 등장인물이 셋이라는 게 흔히 그려지는 그림과 다른 점 — "나의 에이전트"와 "번역 에이전트" 사이에 "레지스트리"가 끼어 있다.

여기엔 성격이 다른 두 번의 질문이 있다. 앞의 두 단계는 "그런 일을 할 줄 아는 상대가 어디 있나"를 제3자인 명함첩에 묻는다. 이 단계가 없으면 "나의 에이전트"는 애초에 누구에게 말을 걸어야 할지조차 모른다. 그 다음 두 단계가 "당신이 정말 그 일을 할 줄 아나, 어떻게 인증하나"를 당사자에게 직접 묻는 것이고, 여기서 비로소 진짜 명함이 오간다. 명함첩이 준 건 사본이었지만, 이제 본인에게 확인받은 것이다.

이 분리가 왜 중요한가. 낯선 에이전트에게 무턱대고 일을 던지는 실패를 두 겹으로 막아 주기 때문이다. 명함첩 질의는 "애초에 후보가 아닌 상대"를 걸러 내고, 당사자 확인은 "명함첩 정보가 낡아서 이미 안 맞게 된 상대"까지 걸러 낸다. 사람으로 치면 소개를 받아 사람을 찾고, 만나서 명함을 직접 받아 보고, 그제야 일 이야기를 꺼내는 순서와 똑같다.

정리 — 표준화된 건 명함이지, 명함첩이 아니다

에이전트 협업이라고 하면 흔히 "어떻게 호출하느냐"를 먼저 떠올리지만, 그 앞에 반드시 발견이 온다. 그리고 그 발견은 다시 위치를 찾는 일과 능력을 확인하는 일로 나뉜다. 지금까지 본 다섯 가지 방식 중 진짜로 "찾는" 것은 명함첩 하나뿐이었다. 공개 명함 확인은 도메인을 이미 알아야 했고, 패키지 동봉은 배포물을 이미 손에 쥐고 있어야 했고, 직접 설정은 아예 찾을 필요가 없는 경우였다. 당사자에게 물으려면 당사자가 누구인지부터 알아야 하니, 결국 제3자만이 "모르는 상대를 찾아 주는" 일을 할 수 있다.

그런데 바로 그 제3자가 아직 표준화되지 않았다. 명함의 형식은 합의됐다. 명함을 당사자의 어느 자리에 걸어 둘지도 합의됐다. 하지만 "세상에 존재하는 명함들을 어떻게 모아 두고 검색할 것인가"는 각자 알아서다. 그래서 실무의 에이전트 연동은 결국 가장 소박한 경로 — 설정 파일에 주소를 박아 두는 방식 — 으로 수렴한다. 프로토콜의 야심은 "사전 약속 없는 협업"인데, 현실은 여전히 사전 약속 위에서 돌아가고 있는 셈이다.

그러니 내가 에이전트 시스템을 설계한다면 질문이 둘이다. 하나는 "내 에이전트의 명함에 무엇을 적을 것인가"이고, 다른 하나는 — 이쪽이 더 답하기 어려운데 — "내 에이전트는 그 명함을 누구에게서 받아 올 것인가"다. 첫 번째 질문은 스펙이 답을 준다. 두 번째는 아직 각자가 답해야 한다.

---

참고한 공개 자료:

• Agent Discovery — A2A Protocol (https://a2a-protocol.org/latest/topics/agent-discovery/)
• Agent2Agent (A2A) Protocol Specification (https://a2a-protocol.org/latest/specification/)
• Agent Discovery — Agent Communication Protocol (https://agentcommunicationprotocol.dev/core-concepts/agent-discovery)
• RFC 8615: Well-Known Uniform Resource Identifiers (https://datatracker.ietf.org/doc/html/rfc8615)
• ACP Joins Forces with A2A Under the Linux Foundation — LF AI & Data (https://lfaidata.foundation/communityblog/2025/08/29/acp-joins-forces-with-a2a-under-the-linux-foundations-lf-ai-data/)

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.