AI 에이전트 제품에서 가장 비싼 버그는 “틀린 답”이 아니라 “실패/에러/지연”이다. 유저는 한 번의 타임아웃, 한 번의 404, 한 번의 컨텍스트 유실로 ‘이 제품은 믿을 수 없다’고 학습한다. 그 순간 Activation은 꺾이고(첫 성공 경험 실패), 전환은 미뤄지고(유료 결제는 신뢰 뒤에 온다), 리텐션은 무너진다(D7에 남는 건 안정적으로 ‘일을 끝내주는’ 경험뿐). 그래서 에이전트 실패율은 품질 지표가 아니라 그로스 지표다.
dev.to의 PayArk 사례(“Designing APIs for AI Agents First…”)가 던지는 핵심은 간단하다. 사람을 위한 REST는 ‘문서를 읽는 소비자’를 전제로 하지만, 에이전트는 문서를 읽지 않고 툴 스키마+설명 문자열(description)을 패턴 매칭해 호출한다. 즉 API의 진짜 계약면(contract surface)이 바뀐다. 여기서 작은 모호성(필수 파라미터, 허용 값 범위, 페이지네이션 규칙)이 곧바로 잘못된 툴 호출 → 재시도 루프 → 지연/비용 폭증 → 사용자 이탈로 이어진다.
PayArk가 MCP(Model Context Protocol)로 재설계하며 잡은 3가지 원칙은 ‘실패율을 낮추는 제품 설계 체크리스트’로 읽어야 한다. (1) 조합성보다 원자성(atomicity): 에이전트는 여러 호출을 안정적으로 체인하지 못하고 중간 단계를 생략/환각할 수 있다. 그래서 “list → get details”를 분리하기보다 한 번에 결정적 결과를 반환하는 툴로 모호성을 제거한다. (2) 설명 문자열이 곧 API: “gets payments” 같은 설명은 문서가 아니라 장애의 씨앗이다. 긍정 범위뿐 아니라 “이 툴로 하면 안 되는 것(negative scope)”까지 못 박아야 잘못된 호출을 줄인다. (3) 에러를 추론 입력으로: 사람은 404를 보고 코드를 고치지만, 에이전트는 404를 보고 ‘자기 수정’을 시도한다. 따라서 에러 응답에 suggested_action 같은 복구 경로를 구조화해 넣으면, 환각 재시도(가짜 ID 생성 등)를 실질적으로 줄일 수 있다.
실패는 툴 호출에서만 터지지 않는다. OpenRouter 무료 모델 장애를 120줄 파이썬으로 막아낸 글(“Free LLMs on OpenRouter Keep Going 404…”)은 운영 관점의 교훈을 준다. 모델은 고정 자산이 아니라 변동하는 공급망이다. 하드코딩된 모델 리스트는 기술부채가 되고, 어느 날 404/429로 파이프라인이 ‘조용히’ 멈춘다. 이때 중요한 건 단순 HTTP 성공률이 아니라 parse_ok(구조 출력이 실제로 파싱 가능한지) 같은 ‘업무 성공률’이다. 에이전트 제품 관점으로 번역하면, “응답이 왔다”가 아니라 “작업이 끝났다”를 성공으로 정의하고, 이를 기준으로 자동 폴백/라우팅해야 한다.
그리고 가장 흔한 실패 시나리오는 아키텍처 착각에서 온다. 쿠버네티스에서 에이전트를 웹서버처럼 다뤘다가 10명 동시 사용에 붕괴한 사례(“Stop Treating AI Agents as Web Servers…”)는, 타임아웃이 UX 이슈를 넘어 고아 실행(orphan execution)을 만들며 비용과 실패를 증폭시킨다는 걸 보여준다. 유저는 실패했다고 다시 눌러 재실행을 만들고, 시스템은 백그라운드에서 계속 토큰을 태우며, HPA는 CPU가 낮아 스케일을 못 하고, 결국 상태가 날아가 ‘다음 대화’가 불가능해진다. 제품적으로는 “두 번째 시도에서 성공”이 아니라 “두 번째 시도 자체가 이탈 신호”가 된다.
시사점은 명확하다: 에이전트 그로스의 첫 레버는 기능 로드맵이 아니라 실패율 로드맵이다. 실행 순서로는 (A) MCP식으로 툴을 원자화하고, description을 런타임 계약으로 다듬고, 에러에 복구 경로를 구조화한다 → (B) 모델/툴/워크플로우를 ‘동적 발견+가용성 점수화’로 운영해 404/429/품질 저하를 자동 회피한다 → (C) 장시간 작업은 비동기 잡(queued)로 분리하고, 재시도/중복 실행을 idempotency key로 막고, 상태는 외부 저장소에 둔다. 이렇게 하면 Activation(첫 성공)과 Retention(반복 성공)이 같이 올라가고, 동시에 지원/장애 대응 비용이 내려가 LTV/CAC 비율이 개선된다.
전망: 앞으로 “에이전트 친화적 API”는 선택이 아니라 배포 조건이 된다. MCP가 강제한 엄격함(명확한 스코프, 결정적 출력, 구조화된 복구)은 인간 개발자 경험도 같이 개선한다는 점에서, 장기적으로는 표준화될 가능성이 높다. 승부는 모델 성능이 아니라 실패를 설계하고 측정하는 팀에서 갈린다. 결국 시장이 기억하는 제품은 ‘가끔 똑똑한’ 에이전트가 아니라, 대부분의 날에 끝까지 해내는 에이전트다—그 신뢰가 퍼널 전체를 들어 올린다.