[ blog · deep-dive ]7 min read

API는 왜 성공시에만 과금해야 하는가 — HTTP-200 과금론

Sarah Choy2026년 5월 3일 게시7분 분량

대부분의 API는 모든 과금 대상 호출에 요금을 매긴다. AI 에이전트는 불안정한 업스트림 서비스에 끊임없이 재시도한다 — 즉 레거시 '무조건 과금' 모델은 사실상 회복탄력성에 세금을 매긴다. HTTP 200에만 과금하자는 주장과, 그것이 에이전트 설계 방식에 무엇을 바꾸는지.

한눈에

•AI 에이전트는 일시적 실패(5xx, 타임아웃, 레이트 리밋)에 합리적으로 재시도한다. '무조건 과금' 과금에서는 모든 재시도가 실제 청구다 — 99.5% 가동률의 업스트림을, 그 나쁜 0.5% 동안 5× 비용 페널티로 바꿔놓는다.
•'HTTP 200에만 과금'은 제공자의 인센티브를 고객의 것과 정렬한다: 제공자는 불안정을 고치고, 고객은 그에 대해 지불하지 않는다.
•또한 '무조건 과금'이 금지적으로 비싸게 만드는 설계 패턴 — 적극적 재시도 예산, 낙관적 프리페치, 중복 호출 — 을 열어준다.
•대부분의 제공자가 이렇게 하지 않는 이유는 레거시 인프라가 미터링을 응답이 아니라 업스트림 호출에 묶기 때문이다. 그것은 정책으로 포장된 과금 시스템의 한계다.

우리가 장려하려는 행동

AI 에이전트는 새로운 종류의 API 클라이언트다. 그들은 오류 하나를 잡으면 온콜 엔지니어에게 이메일을 보내던 2015년의 조심스러운 엔터프라이즈 연동이 아니다. 그들은 무언가 실패하면 잠시 자고 다시 시도하는 — 때로는 다섯 번, 열 번 — 루프이며, 결과를 사람에게 전혀 노출하지 않는다. 루프의 핵심은 일시적 실패가 최종 사용자에게 보이지 않아야 한다는 것이다.

그것은 훌륭한 패턴이다. 회복탄력적인 제품을 만든다. 공개 인터넷의 지저분한 현실을 사용자로부터 숨긴다. 문제는 API 과금 모델이 재시도가 드물고, 기본적으로 단념시킬 만큼 비싸던 시대에 세워졌다는 점이다. 지금도 그렇게 작동한다. 모든 재시도가 과금 대상 호출이며, 무언가를 반환했는지와 무관하다.

구체적으로: 99.5% 가동률 API를 때리며 일시적 실패에 최대 다섯 번 재시도하는 에이전트는, 그 나쁜 0.5% 동안 최대 5×의 호출 — 그리고 5×의 청구서 — 를 만든다. 에이전트는 옳은 일을 했다. 고객이 업스트림의 불안정에 대해 지불한다.

더 단순한 대안

HTTP 200에만 과금하라. 구체적으로, 문서화된 응답 형태를 가진 성공 응답에만. 나머지 전부 — 호출자 오류 4xx, 우리 오류 5xx, 타임아웃, 레이트 리밋, 부분적이지만 잘못된 응답 — 는 무료다.

작은 변화처럼 들린다. 아니다. 양쪽 모두에서 경제적으로 합리적인 것을 바꾼다:

제공자는 이제 불안정을 고칠 직접적인 금전 인센티브를 갖는다. 불안정한 503 하나하나가 공짜 점심이 아니라 놓친 판매다. 우리는 성공시에만 과금을 채택한 것이, 신뢰성 작업을 로드맵 최상단으로 끌어올린 가장 큰 단일 힘이었음을 알게 됐다 — 그 호출들의 매출을 포기하고 있을 때 다운타임을 괜찮아 보이게 만드는 스프레드시트 트릭은 없다.
고객은 재시도 예산을 공격적으로 잡을 수 있다. 일시적 실패의 최악이 여섯 번(시도마다 하나씩 과금)이 아니라 한 번의 유료 호출(결국의 성공)일 때, 5회 지수 백오프 루프는 고민할 필요도 없다.
시장은 API를 시도당 달러가 아니라 성공 호출당 달러로 비교할 수 있다. 그것이 올바른 단위다. 두 API가 모두 '호출당 $0.001'을 내걸어도 하나는 99.9% 가동률, 다른 하나는 95%라면, 무조건 과금에서는 사용자가 보는 비용이 5× 차이 나고, 성공시에만 과금에서는 정확히 0% 차이다. 구매자가 무엇을 선호해야 할지는 명백하며 — 성공시에만 과금이 그것을 보이게 만든다.

에이전트를 만드는 방식이 무엇이 바뀌나

1. 재시도 예산이 공짜가 된다

무조건 과금에서 일시적 실패 핸들러의 올바른 재시도 예산은 대략 1~2회다 — 그 이상은 반복 실패 비용이 중요해지기 시작한다. 성공시에만 과금에서는 예산이 '사용자가 기다릴 수 있는 만큼'이다. 우리는 레거시 과금에서라면 무모했을 5회, 지수 백오프, 지터를 적용한 에이전트 루프를 일상적으로 본다.

2. 낙관적 프리페치가 싸진다

무조건 과금에서 금지적으로 비싼 패턴: 사용자가 아직 타이핑 중일 때, 예측한 쿼리가 맞을 경우를 대비해 검색 호출을 투기적으로 띄우는 것. 예측이 틀리면 결과를 버린다. 성공시에만 과금에서는 이것이 싸다. 취소된 / 쓰이지 않은 호출은 성공을 반환하지만 당신이 응답을 버리기 때문이다 — 그러니 예측 가능성과 지연을 위해 작은 프리미엄만 낸다. 무조건 과금에서는 틀린 예측 하나하나가 유료 호출이라, 그 휴리스틱은 출시하기엔 너무 비싸진다.

3. 중복 호출이 신뢰성 도구가 된다

때로 가장 싼 신뢰성 전략은 서로 다른 두 API에 두 요청을 띄우고, 먼저 반환하는 쪽을 취하고 느린 쪽을 버리는 것이다. 무조건 과금에서는 그것이 청구서를 두 배로 만든다. 성공시에만 과금에서는 버려진 호출이 공짜다(응답을 쓰지 않았으니 지불하지 않았다). 갑자기, 비싼 추상이던 헤징 전략이 실용적이 된다.

'성공'이 무엇을 의미해야 하나

이 모델은 '성공'이 모호하지 않을 때만 작동한다. 우리는 그것을 빡빡하게 정의한다:

문서화된 응답 스키마를 가진 HTTP 200 — 과금 대상.
응답 본문에 오류가 감싸인 HTTP 200 — 과금 대상 아님(이것이 모델 전체를 깨뜨릴 허점이 될 것이다).
HTTP 4xx — 과금 대상 아님. 401(인증), 402(크레딧 부족), 422(검증), 404(일부 맥락에서 not found)를 포함한다.
HTTP 5xx — 과금 대상 아님.
HTTP 429(레이트 리밋) — 과금 대상 아님.
우리 엣지 이전의 네트워크 오류 / 타임아웃 — 과금 대상 아님.

배치 엔드포인트(예: 한 호출에 25개 URL이 들어가는 URL Extract)의 경우, URL이 하나라도 성공하면 호출 전체가 하나의 HTTP 200이며 URL당 요율로 과금된다. URL별 status 필드가 어떤 URL이 실패했는지 호출자에게 알려준다. 작업은 수행됐으니 과금 대상이다.

왜 대부분의 제공자는 이렇게 하지 않나

각자가 얼마나 중요한지 순서대로, 세 가지 이유:

과금 인프라. 표준 패턴은 응답을 알기 전, API 게이트웨이에서 미터링하는 것이다. 게이트웨이가 과금 이벤트를 Kafka로 내보내고, 과금 시스템이 집계하고, 청구서가 발송된다. 업스트림 서비스가 상태 코드로 응답한 이후에 미터링이 발화하도록 다시 배선하려면 (a) 게이트웨이를 백엔드 헬스에 결합하거나(새 실패 모드 생성), (b) 실패한 호출을 사후적으로 환급하는 정산 파이프라인을 작성해야 한다. 둘 다 실제 엔지니어링 작업이다.
습관. 그 패턴은 안정적인 백엔드 — Twilio, AWS, Stripe — 가 세웠다. 업스트림이 99.99% 가동률일 때는 잘 작동한다. LLM을 감싸거나, 웹을 스크레이핑하거나, 느린 데이터 파트너를 호출하는 API는 훨씬 덜 안정적이지만, 과금 패턴은 안정적이던 시대에서 물려받았고 갱신된 적이 없다.
매출. 무조건 과금은 그냥 돈이 더 된다. 대부분의 고객이 에이전트 트래픽이 아니었기에 대부분의 제공자는 이 차원에서 경쟁할 필요가 없었고, 동기식 인간 사용자는 가끔의 실패를 과금 모델을 읽는 것보다 더 잘 견딘다.

첫째는 실제 엔지니어링이다. 둘째와 셋째는 관성이다. 둘 다 에이전트 트래픽이 API 소비의 다수가 되면 무너질 것이며 — 추세선이 말하는 바로는 대부분의 공개 API에 대해 18개월 안에 일어나는 일이다.

구매자로서 무엇을 봐야 하나

에이전트 워크로드를 위해 데이터 API를 평가한다면, 세 가지 명시적 질문:

'HTTP 200에만 과금합니까, 아니면 과금 대상 시도마다 과금합니까?' — 직답을 요구하라. '보통은'이나 '요금제에 따라'를 받아들이지 말라.
'HTTP 207 / 부분 성공은 어떻게 과금됩니까?' — 허점 답변을 끄집어낸다.
'공개된 가동률은 얼마이고, 못 지켰을 때 SLA 환급 메커니즘은 무엇입니까?' — 성공시에만 과금은 강한 신호지만 실제 SLA의 대체물은 아니다. 둘 다 있어야 한다.

이것이 가리키는 변화

AI 에이전트는 그들이 건드리는 모든 API의 단위 경제를 바꾼다. 에이전트 시대를 위해 설계된 API는 다르게 생겼고 — 더 단순한 형태, 예측 가능한 스키마, 기계 친화적 인증, 투명한 가격 — 그 과금 모델도 다르게 생겼다. 성공시에만 과금은 더 단순한 변화 중 하나다. 더 어려운 것은, 아직 우리 앞에 남아 있는데, 어느 한 당사자도 전체 경로를 소유하지 않을 때 다단계 에이전트 워크플로가 제공자 간에 어떻게 가격이 매겨지는지 알아내는 일이다.

지금으로서는, 가능한 제공자에게 성공시에만 과금을 요구하라. 그것을 활용하는 에이전트를 만들어라. 그리고 API를 쇼핑할 때, 시도당 달러가 아니라 성공 호출당 달러로 계산하라.

자주 묻는 질문

'성공시에만'이 제공자가 성공을 실패로 오분류하도록 부추기지 않나?

이론상은 그렇지만, 반대 압력이 더 강하다: 개발자는 API를 실세계 '유용한 호출당 달러'로 비교하며, 그것이 바로 성공시에만 과금이 측정하는 값이다. 성공을 슬그머니 실패로 재분류하는 제공자는 며칠 안에 성난 지원 큐와 공개 리뷰 흔적을 마주하게 된다. 시장이 충분히 작아서 이것은 자기 교정된다.

호출이 부분적으로만 성공하면 어떻게 되나 — 예를 들어 배치 추출에서 25개 URL 중 2개가 실패하면?

두 가지 합리적인 모델이 있다. (a) URL이 하나라도 성공하면 전체 호출은 HTTP 200이고, URL별 실패는 URL별 상태에 보고된다. 작업이 일어났으니 과금 대상이다. (b) 부분 성공에는 HTTP 207(multi-status) — 각 URL이 개별 과금된다. 우리는 (a)를 택했다. 가격이 예측 가능해지기 때문이다: 에이전트는 HTTP 200 성공이 최악의 경우 공지된 크레딧 비용임을 안다. (b)가 더 '공정'하지만 예산을 잡기는 더 어렵다.

무엇이 실패로 간주되나?

우리 규칙: 명백히 호출자 잘못인 HTTP 4xx(잘못된 본문, 인증 누락, 크레딧 부족)는 과금하지 않는다. HTTP 5xx는 절대 과금하지 않는다 — 우리 문제다. 우리 쪽 네트워크 오류와 타임아웃은 절대 과금하지 않는다. 레이트 리밋(429)도 절대 과금하지 않는다. 과금되는 유일한 것은 공지된 응답 형태를 가진 HTTP 200이다.

왜 대부분의 제공자는 모든 호출에 과금하나?

대체로 역사적인 이유 셋이다. (1) 레거시 과금 시스템은 응답을 알기 전, API 게이트웨이에서 미터링한다. 응답 상태에 따라 사후적으로 과금을 발화하도록 배선하는 것은 간단치 않다. (2) 그 패턴은 안정적인 백엔드 시대에 Twilio와 AWS가 세운 것이다. LLM을 감싸거나 웹을 스크레이핑하는 API는 훨씬 덜 안정적이라 그 전제가 무너진다. (3) 돈이 더 된다. 앞의 둘은 핑계고, 셋째가 진실이다.

'무조건 과금'이 말이 되는 경우도 있나?

결과와 무관하게 매 호출이 진짜로 고정 비용을 소비할 때 — 예를 들어 하드웨어 콜아웃(SMS 발송), 경계에서 원자적인 변경(DNS 갱신), 혹은 백엔드가 '시도했지만 실패'와 '했는데 당신이 못 알아챘다'를 구분할 수 없는 서비스. 읽기 스타일 데이터 API와 검색 API에는 그 모델이 맞지 않는다.