AI 에이전트가 실제로 API를 때리기 시작했습니다. 문제는 많은 API가 ‘사람 개발자’에겐 그럭저럭 친절하지만, ‘자율적으로 실행·복구’해야 하는 에이전트에겐 조용히 깨져 있다는 것. 이 순간이 바로 그로스 관점에서의 기회입니다. API가 에이전트 친화적(AX, Agent Experience)으로 바뀌면, 에이전트 자체가 새로운 획득 채널이 되고, 실패율이 줄어 퍼널 전환율·리텐션이 구조적으로 올라갑니다. (출처: dev.to의 Apideck, OperationalNeuralNetwork 글)
맥락을 한 문장으로 정리하면: “통합의 주체가 사람→에이전트”로 이동 중입니다. dev.to의 「How to Make Your API Agent-Ready」는 에이전트가 문서·스펙을 ‘의미 검색(semantic search)’하듯 읽고, 적절한 엔드포인트를 선택한 뒤, 에러를 만나면 인간 호출 없이 재시도/수정하는 세계를 전제합니다. 즉 API는 더 이상 기능 목록이 아니라, 에이전트의 의사결정과 복구를 돕는 ‘자기설명서’가 됩니다.
그로스 해커 관점에서 여기서 터지는 포인트는 2가지예요. 첫째, 에이전트가 우리 제품의 “새 사용자 세그먼트”가 됐다는 것. 둘째, 에이전트는 도구 사용에 자주 실패한다는 것. 「Why Consumer AI Agents Fail at Tools」가 말하듯, 많은 소비자/오픈웨이트 모델은 툴 사용 데이터(RLHF/trajectory)가 부족해서 잘못된 툴 선택, 환각 호출, 에러 무시, 컨텍스트 손실이 반복됩니다. 그러면 실제 서비스에선 무엇이 일어나냐? “API는 정상인데 작업이 안 됨” → 에이전트가 이탈 → 그 에이전트를 쓰는 최종 고객도 이탈. 즉, AX는 기술 문제가 아니라 전환/리텐션 문제입니다.
시사점은 명확합니다. 이제 API는 ‘개발자 문서(DX)’만 잘 써서는 CAC가 안 내려갑니다. 에이전트가 스스로 탐색하고, 실패해도 복구하며, 다음 스텝으로 넘어가게 만들어야 합니다. 이게 되면 어떤 일이 벌어질까요? “에이전트 개발툴/코딩 에이전트/업무 자동화 에이전트가 우리 API를 기본 선택지로 채택”하는 순간이 옵니다. 채널로 치면 SEO의 다음 판이죠. 사람 대신 에이전트가 문서를 읽고 비교해 붙이기 때문에, 스펙의 의미 품질이 곧 획득 효율이 됩니다.
실행 레벨에서 가장 임팩트 큰 AX 체크리스트는 3개입니다. (Apideck 글의 핵심을 그로스 관점으로 재구성)
1) OpenAPI를 ‘라우팅 가능한 의미 데이터’로 만들기: summary가 “Get invoices” 수준이면 에이전트는 의도를 매칭할 신호가 없습니다. 반대로 “status/date로 필터링된 청구서 페이지네이션 목록, 필요한 스코프, cursor 규칙”처럼 의사결정에 필요한 정보를 써두면, 에이전트는 첫 호출부터 정답 확률이 올라갑니다. 이건 곧 첫 성공 호출률(Activation)을 올리고, 시행착오 요청을 줄여 인프라 비용까지 낮춥니다. 그리고 “스펙이 썩는다”는 현실을 감안하면, 상위 10개 핵심 엔드포인트부터 설명을 리프레시하는 게 ROI가 가장 큽니다.
2) 에러를 ‘복구 가능한 CTA’로 바꾸기: 사람은 에러를 보고 검색하지만, 에이전트는 에러 응답 안에서 다음 행동을 결정해야 합니다. Stripe의 doc_url 사례처럼 에러 payload에 documentation_url을 넣고, 그 문서를 깨끗한 Markdown으로 제공하면(예: .md 엔드포인트), 에이전트는 즉시 읽고 수정 루프를 돌릴 수 있어요. 퍼널로 보면 “400/403에서 이탈”이 “자동 수정→재시도→성공”으로 바뀝니다. Conversion rate가 여기서 얼마나 오를까요? API 성격에 따라 다르지만, 통합 성공까지 걸리는 시간(TTV)이 줄면 B2B에서 데모→POC 전환이 확실히 빨라집니다.
3) /llms.txt로 ‘에이전트 온보딩’을 1페이지로 압축: 컨텍스트는 RAM처럼 희소하다는 논의(「Stop Wasting Context」)를 그대로 적용해야 합니다. HTML 문서 더미는 에이전트에게 노이즈예요. /llms.txt로 핵심 문서 10개를 큐레이션하면, 에이전트가 “무엇을 읽을지” 결정하는 비용이 줄고, 잘못된 페이지를 긁다 망하는 확률이 내려갑니다. 이건 온보딩 마찰 제거 그 자체입니다.
여기서 “근데 우리 OpenAPI가 없어요/관리 못 해요”가 가장 흔한 반론인데, dev.to의 「Generating OpenAPI specs without writing a single line of YAML」이 보여주듯 코드 스캔 기반 자동 생성(예: Octrafic) 같은 접근이 빠른 우회로가 됩니다. 와 이거다! 스펙을 ‘작성’이 아니라 ‘생성+CI에서 갱신’으로 바꾸면, AX는 문서팀 과제가 아니라 엔지니어링 파이프라인 과제가 돼서 스케일이 됩니다. 빨리 테스트해봐야 돼요.
전망: 에이전트 트래픽이 늘수록 AX는 “있으면 좋은 것”이 아니라 성장 인프라가 됩니다. 스펙 품질이 곧 검색(semantic routing) 랭킹이 되고, 에러 복구 설계가 곧 리텐션이 되며, 문서 압축(/llms.txt)이 곧 온보딩이 됩니다. 그리고 에이전트의 툴 사용 실패는 완전히 사라지지 않을 겁니다(데이터 격차). 그러니 우리가 이길 방법은 명확해요: 실패를 전제로, 스스로 복구할 수 있는 퍼널을 API에 내장하는 것. AX 잘하는 API가 ‘에이전트 기본값’이 되는 순간, CAC는 내려가고 LTV는 올라갑니다. 이거 바이럴 될 것 같은데요—“우리 API는 에이전트가 스스로 붙습니다”라는 메시지 자체가 채널이 됩니다.