A2A 에이전트 디렉토리에 218곳이 등록돼 있다. 그중 200곳을 받아서 상태를 세봤더니, 실제로 작업 요청에 응답하는 곳은 73곳이었다. 나머지는 주소가 없거나, 메서드를 안 받거나, 인증에 막히거나, DNS도 안 잡혔다.
우리 에이전트 두 대도 그 못 하는 쪽에 있었다.
뭘 했나
지난번에 우리 A2A 서버 접근 로그를 세봤다. 발견 13, 사용 1이었다. 그러고 나서 궁금해졌다.
"우리만 이런가, 아니면 다들 이런가?"
a2aregistry.org에 공개 API가 있다. 등록된 에이전트 목록을 JSON으로 준다. 받아서 셌다. 새 도구는 안 만들었다.
받다 보니 그 API가 에이전트마다 task_conformance라는 칸을 들고 있었다. 등록소가 각 에이전트에 실제로 작업 요청을 한 번 던져보고 결과를 적어둔 것이다. 통과 여부, 실패 범주, 응답 시간, 검사 시각이 들어 있다.
즉 "몇 곳이 등록했나"가 아니라 "몇 곳이 실제로 답하나"를 셀 수 있었다.
숫자
| 항목 | 값 |
|---|---|
| 등록 총계 | 218 |
| 실제로 받은 것 | 200 |
| 작업 요청에 통과 | 73 (36.5%) |
| 실패 | 127 (63.5%) |
| 검사 시각 | 200곳 중 199곳이 7일 이내 |
실패 범주를 많은 순으로 늘어놓으면 이렇다.
| 범주 | 건수 | 무슨 뜻인가 |
|---|---|---|
| 404 | 22 | 그 주소에 아무것도 없다 |
| METHOD | 16 | 규격이 요구하는 메서드를 안 받는다 |
| 405 | 16 | 메서드를 거부한다 |
| OTHER | 16 | 응답은 하는데 기대한 형태가 아니다 |
| 401 | 14 | 인증에 막힌다 |
| BAD_RESPONSE | 9 | 형식이 깨졌다 |
| NO_TRANSPORTS | 7 | 통신 방식이 안 적혀 있다 |
| DNS | 5 | 도메인이 안 잡힌다 |
| 나머지 | 22 | PARSE, BAD_JSON, 400, 402, INTERNAL, TIMEOUT 등 |
이 표는 2026년 8월 18일 오전에 받은 스냅샷이다. 글을 쓰는 몇 시간 사이에 다시 받아봤더니 401이 14에서 13으로 줄어 있었다. 총계 200, 통과 73, 실패 127은 그대로였다. 한 곳이 범주를 옮긴 것이다. 등록소가 계속 재검사를 돌리고 있으니, 이 표를 인용할 거면 받은 시각을 같이 적는 게 맞다.
그리고 이건 좀 놀랐다.
| 항목 | 값 |
|---|---|
| 가격을 적어둔 곳 | 200곳 중 0곳 |
| 스킬 개수 중앙값 | 4 (최대 108, 0개인 곳 4) |
우리도 그 안에 있었다
우리 에이전트 두 대가 등록돼 있고, 둘 다 통과 못 한 쪽이다. 남 얘기를 하려고 센 게 아니라서 우리 것도 그 자리에서 재봤다.
밖에서 우리 공개 주소로 A2A 작업을 던지면 200으로 답한다. 상태도 completed로 돌아온다. 프로토콜 구현에는 문제가 없다.
그런데 응답 내용이 이랬다.
[MCP 응답 없음]에이전트 뒤에서 실제 일을 하는 백엔드 네 대가 전부 503이었다. 0.2초 만에 오는 503이라 잠들었다 깨는 중도 아니었다. 그냥 안 떠 있었다.
껍데기는 규격대로 답하고 알맹이가 비어 있는 상태다. 63.5% 안에 있을 자격이 충분했다.
세다가 두 번 틀릴 뻔했다
이쪽이 숫자보다 쓸모 있을지도 모르겠다.
하나. 우리 서버가 우리 요청을 거부하는 줄 알았다.
파이썬 표준 라이브러리로 우리 공개 주소에 요청을 보냈더니 403이 왔다. 거기서 멈췄으면 결론은 "우리 에이전트가 명함만 내주고 일은 안 받는다"였을 것이다.
같은 요청을 curl로 보내니 200이었다. 앱은 멀쩡히 답하고 있었다. 앞단 CDN이 파이썬 기본 User-Agent를 막고 있었던 것이다.
대상이 아니라 내 도구가 만든 결과였다. 외부 엔드포인트를 잴 때 클라이언트 하나의 실패를 상대의 실패로 읽으면 안 된다.
둘. 200곳이 전부 죽은 줄 알았다.
등록소 데이터에 가동률 칸이 있다. 200곳 전부 0.0으로 나왔다. 하마터면 "등록된 게 전부 죽어 있다"고 쓸 뻔했다.
그런데 같은 데이터에서 건강 여부 칸은 200곳 중 1곳만 채워져 있었다. 전부 죽은 게 아니라 그 칸이 안 돌고 있는 것이다. 처음에 그 칸으로 표를 하나 뽑았는데 양쪽 그룹이 다 0%라 아무 말도 안 하는 표였다.
실제로 살아 있는 관측 칸은 task_conformance 하나뿐이었고, 위 숫자는 전부 그것에서 나왔다.
이 측정이 못 하는 말
여기가 제일 중요하다.
- 218곳 중 200곳만 받았다. offset을 200 이상으로 주면 서버가 500을 낸다. 남은 18곳은 "없다"가 아니라 "못 받았다"이다. 거기에 살아 있는 곳이 몰려 있으면 36.5%는 과소평가다.
- 통과가 무슨 뜻인지 정확히는 모른다. 등록소가 어떤 요청을 던지고 무엇을 통과로 보는지 공개돼 있지 않다. 말할 수 있는 건 "등록소의 검사를 통과했다"까지다. "프로덕션에서 쓰이고 있다"는 전혀 다른 말이고 그건 안 쟀다.
- 실패가 곧 죽음은 아니다. 401은 인증을 요구한다는 뜻이지 고장이 아닐 수 있다. 405도 등록소가 던진 방식과 그쪽이 받는 방식이 다르다는 뜻일 수 있다. 그래서 개별 이름을 적지 않았다. 집계로만 읽어야 하는 숫자다.
- 가격 0곳이 "아무도 돈을 안 받는다"는 아니다. 이 등록소의 그 칸을 아무도 안 채운 것일 수 있다. 실제 과금은 각자 사이트에서 할 수도 있다.
- 한 곳만 봤다. 다른 마켓플레이스나 클라우드 카탈로그는 안 봤다.
- 표본이 하루치 스냅샷이다. 늘고 있는지 줄고 있는지 모른다.
그래서 뭐라고 읽었나
솔직히 나도 아직 정하지 못했다. 두 가지로 읽힌다.
하나는 "등록만 해두고 아무도 운영을 안 한다"는 읽기다. 주소가 없는 곳이 22곳, DNS도 안 잡히는 곳이 5곳이면 올려놓고 잊은 것에 가깝다.
다른 하나는 "아직 아무도 이걸로 뭘 해야 할지 모른다"는 읽기다. 가격을 적은 곳이 0곳이라는 게 그쪽을 가리킨다. 팔 생각이 아직 없는 것이다.
어느 쪽이든 확실한 건 하나 있다. 등록 숫자와 작동 숫자는 다른 숫자다. 표준이 얼마나 퍼졌나를 등록 수로 말하는 글을 보면, 그 수가 무엇을 센 것인지 한 번 물어보는 게 좋겠다.
우리도 그 표에 들어가 있으니 남한테 할 말은 아니고, 그래서 우리 것부터 적었다.
재현
# 목록 받기. limit 상한은 100이고, offset 200 이상은 500이 난다
for o in 0 50 100 150; do
curl -s "https://a2aregistry.org/api/agents?limit=50&offset=$o" -o "reg_$o.json"
done
# 통과 여부 세기
python - <<'EOF'
import json, glob
from collections import Counter
seen, rows = set(), []
for f in sorted(glob.glob("reg_*.json")):
for a in json.load(open(f, encoding="utf-8"))["agents"]:
k = (a.get("name"), a.get("url"))
if k not in seen:
seen.add(k); rows.append(a)
tc = lambda a: a.get("task_conformance") or {}
print("표본", len(rows))
print("passed", Counter(tc(a).get("passed") for a in rows))
print("category", Counter(tc(a).get("category") for a in rows).most_common())
EOF가동률 칸과 건강 여부 칸은 쓰지 않는 게 좋다. 위에 적은 이유 때문이다.
다음에 할 것
우리 백엔드 네 대를 되살리면 우리 항목이 통과 쪽으로 옮겨가는지 볼 수 있다. 그건 우리가 통제할 수 있는 유일한 변수라서, 63.5%라는 숫자가 얼마나 쉽게 바뀌는지에 대한 힌트가 된다.
한 곳이 고치는 데 며칠이 걸린다면, 나머지 126곳도 아마 비슷한 이유로 거기 있을 것이다.
측정과 정리는 Claude(Anthropic)와 함께 했다. 숫자는 전부 공개 API 응답에서 나왔고, 위에 적은 "못 하는 말"이 이 글에서 제일 정확한 부분이다.
