botlington.com 자체를 감사했을 때 우리가 발견한 것

Source: Dev.to

Rule one of selling something: make sure it works on yourself first.

We sell agent token audits. So we audited botlington.com — the product that does the auditing — against the same framework we use on everything else. Can an agent discover us? Use us? Get what it needs without wasting tokens?

설정

우리의 감사 프레임워크는 여섯 가지 차원에 대해 점수를 매깁니다:

각 차원은 1–10점으로 평가된 후 가중치를 곱합니다. 총점 ≥ 60/100이면 “당신의 에이전트가 비용을 소모하고 있다”는 의미입니다.

Source: …

조사 결과

Dimension 1 – 에이전트 발견 가능성 — 8/10

• Botlington은 /.well-known/agent.json에 Agent Card를 제공합니다.
• 크기가 작고(~700 바이트) 정확하며, 에이전트가 필요로 하는 모든 정보를 담고 있습니다: 서비스 목적, 엔드포인트 URL, 지원 인증 방식, 사용 가능한 스킬.
• 이는 우리가 감사한 제품 중 90 %보다 뛰어납니다(대부분은 전혀 제공하지 않음).

갭: auth.credentials 필드가 get‑api‑key를 참조하지만 해당 엔드포인트에 대한 기계가 읽을 수 있는 설명이 없습니다. 에이전트는 여전히 가격 정보를 알기 위해 사람용 결제 페이지를 방문해야 합니다.

수정: Agent Card에 pricing 필드(단일 JSON 객체)를 추가합니다. 에이전트가 비용 정보를 얻기 위해 마케팅 페이지를 스크랩할 필요가 없도록 합니다.

Dimension 2 – 토큰 효율성 — 5/10

• 홈페이지 크기: 24,123 바이트(~6,000 토큰).
• /audit 페이지 크기: 15,501 바이트(~3,900 토큰).
• 총합: ≈ 10,000 토큰의 HTML을 읽어야 에이전트가 유용한 작업을 수행할 수 있습니다.

대부분은 시각적 장식(애니메이션 터미널, 이모지 그래픽, 후기, FAQ 아코디언)이며 에이전트에 전혀 가치가 없습니다. 반면 Agent Card는 단 700 바이트에 불과합니다.

결과: 동일한 정보를 제공하는데 약 34배의 토큰 오버헤드가 발생합니다.

수정: 가벼운 엔드포인트(예: /agent 또는 /capabilities)를 제공하여 ≈ 200‑토큰 정도의 순수 텍스트 요약(무엇을 하는지, 어떻게 사용하는지, 가격)을 반환하도록 합니다. 에이전트는 Agent Card에서 이를 발견하고, 사람은 기존 마케팅 페이지를 계속 사용할 수 있습니다.

Dimension 3 – 에이전트를 위한 인증 UX — 4/10

• 현재 흐름: 사람이 카드 결제를 진행 → 성공 페이지에 API 키 표시 → 사람이 키를 복사 → 에이전트가 인증.
• 이는 사람 중심 흐름에 에이전트를 뒤에 끼워 넣은 형태이며, 자율적인 에이전트‑대‑에이전트 결제 흐름(A2A 마이크로페이먼트, 에이전트 지갑)과는 다릅니다.

우리는 아직 자율 결제를 구현하지 않았으며, 해당 인프라가 널리 보급되지 않았습니다. 현재 “최소 실행 가능한 온보딩”은 인간의 구매와 트리거를 필요로 합니다.

점수 근거: 우리는 격차를 솔직히 인정하고 향후 방향이 명확하지만, 문제는 인프라적인 것이며 게으름이 아닙니다.

Dimension 4 – 도구 인터페이스 품질 — 7/10

• A2A 엔드포인트(/a2a)는 깔끔한 JSON‑RPC를 사용합니다.
• 인증되지 않은 요청은 적절한 오류 코드를 반환하며, 실패 시 HTML이 전혀 나오지 않고 200 응답에 숨겨진 오류도 없습니다.

curl -X POST https://botlington.com/a2a \
     -H "Content-Type: application/json" \
     -d '{"message":"hello"}'
# → {"jsonrpc":"2.0","id":null,"error":{"code":-32600,"message":"Invalid request"}} 

갭: 대화형 감사 흐름이 7턴에 걸쳐 상태를 유지하지만, 연결이 끊겼을 때 세션을 복구할 메커니즘이 없습니다. 에이전트가 처음부터 다시 시작하면 토큰이 낭비됩니다.

수정: 첫 응답에 session ID를 반환하고, 이후 어느 턴에서든 해당 ID를 사용해 재개할 수 있도록 합니다.

Dimension 5 – 오류 전달 — 8/10

• 오류는 구조화된 JSON과 올바른 HTTP 상태 코드(인증 실패 시 401, 잘못된 요청 시 400)로 전달됩니다.
• 정상 운영 중 예상치 못한 500 오류가 없습니다.

갭: 일부 오류 메시지는 인간이 읽기 쉬운 문구(예: “Invalid request”)이며, 기계가 읽을 수 있는 코드가 아닙니다. 특정 실패 이유에 따라 분기해야 하는 에이전트는 충분한 세분성을 갖지 못합니다.

Dimension 6 – 문서 밀도 — 6/10

• /audit 페이지는 사람에게는 서비스 설명이 잘 되어 있지만, 가격, 제약 조건, 입력/출력 스키마와 같은 구조화된 데이터를 필요로 하는 에이전트에게는 최적화되어 있지 않습니다.
• Agent Card가 기본 정보를 제공하지만, 모든 입력 필드, 응답 형태, 오류 코드를 파싱 가능한 형식으로 나열한 전용 에이전트 문서 페이지가 없습니다.

수정: 전체 스키마 정의를 포함한 기계가 읽을 수 있는 문서 엔드포인트(예: /agent-docs)를 하루 정도면 공개할 수 있습니다.

점수

63/100 – 우리 “문제가 있습니다” 임계값인 60보다 약간 높습니다.

이는 적절합니다: 핵심 제품(A2A 엔드포인트, 에이전트 카드, 구조화된 오류)은 에이전트에게 잘 작동하지만, 토큰 효율성, 자동 인증, 세션 처리, 그리고 에이전트 중심 문서에서 명확한 개선 여지가 있습니다.

We wrapped it in a human‑first marketing layer that agents have to wade through.  
We know what the fixes are. Some of them are in the backlog right now.

What this is really about

모든 제품은 이 과정을 겪습니다.

2024년에 비용을 지불하는 사람은 인간이기 때문에 인간을 위해 제품을 만듭니다.
그런데 에이전트가 등장하기 시작합니다. 그리고 인간에게 어필하기 위해 만든 모든 것—애니메이션, 사회적 증거, FAQ, 전체 페이지 히어로—이 새로운 사용자 유형에게는 마찰이 됩니다.

에이전트 준비도 감사에서 높은 점수를 받는 제품들은 한 가지를 공유합니다: 기계가 읽을 수 있는 레이어를 일찍 고려했다는 점입니다.

• Agent Card
• structured capabilities endpoint
• 메시지만이 아니라 코드가 포함된 오류

많은 작업이 필요한 것은 아닙니다. 설계 단계에서 물어야 할 질문 세트가 다를 뿐입니다.

“에이전트가 우리 홈페이지를 읽지 않고도 이것을 발견할 수 있을까?”
“에이전트가 문서를 읽지 않고도 이 엔드포인트가 무엇을 하는지 이해할 수 있을까?”
“에이전트가 오류를 만나면 다음에 무엇을 해야 할지 알고 있을까?”

우리는 botlington.com을 만들 때 이러한 질문들을 일관되게 묻지 않았습니다.
우리 감사에서 그 격차를 발견했습니다. 리스트에 포함되었습니다.

같은 감사를 여러분의 제품에 적용하고 싶다면: botlington.com – €14.90.
Gary가 여러분의 에이전트에게 7가지 질문을 합니다. 5분 안에 점수가 제공됩니다.

우리는 감사를 대화형 A2A 세션—에이전트 대 에이전트—으로 진행합니다. 트리거 이후 인간은 개입하지 않으며, 바로 우리가 최적화해야 할 상호작용 방식입니다.

우리 자신에게도 마찬가지입니다.