더 저렴한 모델이 더 저렴할 것이라 예상했지만, 8.6배 더 많은 비용이 들었습니다.

저는 동일한 한 단어짜리 프롬프트를 Claude Haiku와 Gemini 1.5 Flash에 보냈습니다. Flash가 토큰당 단가가 더 낮기 때문에, 이는 쉬운 승리가 되어야 했습니다. 하지만 그렇지 않았습니다. Flash는 사고하는 모델(thinking model)입니다. "Paris"라고 답변하기 전에 수십 개의 토큰을 추론(reasoning)에 사용했으며, 추론은 출력(output)으로 과금됩니다. Haiku는 4개의 토큰으로 답변했습니다. Flash는 약 28개의 토큰을 사용했습니다. 즉, 단위 가격은 더 낮지만 사용 단위가 훨씬 많아 요청당 비용이 약 8.6배 더 높았습니다. 제가 모든 호출에 대해 토큰, 비용, 지연 시간(latency)을 Postgres에 기록하도록 계측(instrumented)해 두었기에 이 사실을 발견할 수 있었습니다. 그리고 저는 모든 호출을 계측합니다. 결제 시스템의 정직함을 유지하는 일을 수년간 해온 사람이라면 당연히 그렇게 하기 때문입니다.

그 본능이 핵심입니다. 저는 2년 반 동안 NPCI에서 국가 간 실시간 결제 시스템을 구축했습니다. 반올림 오차(rounding error)가 사고가 되고, 하위 시스템(downstream)이 중단되는 것이 토요일 밤의 일상인 그런 시스템 말입니다. 올해 저는 LLM 게이트웨이(gateway)를 구축했고, 동일한 도구들을 계속해서 찾게 되었습니다. 이는 우연이 아닙니다.

AI 인프라(infrastructure)는 새로운 분야처럼 보입니다. 하지만 그 밑바닥에는 백엔드 엔지니어들이 항상 해왔던 시스템 작업이 있습니다. 모델 API는 하위 의존성(downstream dependency)입니다. 느리고, 가끔 다운되며, 속도 제한(rate-limit)을 걸고, 호출당 비용을 청구합니다. 여러분은 이와 정확히 똑같은 의존성, 즉 결제 프로세서(payment processor), KYC 제공업체, 파트너 은행 등을 이전에 통합해 본 적이 있습니다. 모델은 마법이 아닙니다. 그것은 비싸고 불안정한 새로운 종류의 하위 시스템(downstream)일 뿐이며, 신뢰성(reliability), 비용 제어(cost control), 장애 조치(failover)와 같은 어려운 부분들은 우리가 이미 해결했던 부분들입니다.

게이트웨이는 제공업체별로 회로 차단기(circuit breaker)가 필요했고, 저는 NPCI에서 정확히 그런 것을 구축했었습니다. 모든 파트너 통합이 다른 나라의 결제 플랫폼에 하위 흐름(downstream)이었고, 각 나라마다 자체적인 서비스 수준 협약(SLA)과 '정상 작동'에 대한 정의를 가지고 있었기 때문입니다. 저의 장애 허용(fault-tolerant) Go 프로세서는 이러한 파트너들을 회로 차단기와 속도 제한기(rate limiter)로 감쌌습니다. 그 이유는 다음과 같습니다. 파트너가 실패하기 시작했을 때, 최악의 행동은 계속해서 공격하는 것이고, 그렇게 하면 자체 워커 풀이 멈춘 호출들로 가득 차게 됩니다. 따라서 회로를 끊어 빠르게 실패하고, 복구를 위해 약간의 트래픽만 흘려보내 프로빙(probe)하게 해야 합니다. CLOSED, OPEN, HALF_OPEN. Anthropic과 Gemini 주변에 이 세 가지 상태를 연결하는 것 외에는 바뀐 것이 명사뿐이었습니다. 즉, '파트너 은행'이 '모델 제공업체'가 된 것입니다.

게이트웨이는 모든 호출을 Postgres로 측정(meter)해야 했습니다. 이것은 감사 로그(audit log)이며, 결제는 감사 로그를 기반으로 작동합니다. 20개 이상의 Go 서비스 전반에 걸쳐 저는 모든 것을 **멱등성(idempotency)**에 맞춰 키워 재시도된 요청이 절대 이중 계산되지 않도록 했고, 비용 로그 역시 동일한 이유로 request_id를 기준으로 합니다. 그리고 돈은 항상 고정 소수점(fixed-precision)이었지, 부동 소수점(float)이 아니었습니다. 이것이 바로 cost_usd가 float이 아니라 NUMERIC인 이유입니다. 돈을 근사치로 계산하지 않고, 지출도 근사치로 계산하지 않습니다.

재시도와 차단기 — 일시적 실패 대 지속적 실패 — 는 근육 기억(muscle memory)과 같았습니다. 결제 분야에서 부주의한 재시도는 이중 인출이므로, 타임아웃 한 번은 멱등적인 재시도를 의미하며 절대 무분별하게 다시 제출하는 것이 아닙니다. 지속적인 실패는 전송을 중단한다는 것을 의미합니다. 저는 수년 동안 금융 워크플로우에 그 구분을 새겨왔습니다. 그것을 LLM 호출에 맞게 다시 작성했을 때, 잘못되었을 경우의 비용은 누군가의 돈에서 낭비된 토큰으로 떨어졌지만, 문제의 형태는 조금도 변하지 않았습니다.

모든 것이 익숙했다고 거짓말하지는 않겠습니다. 몇 가지 사항은 진정으로 새로운 것이었으며, 그 모두는 모델 자체에 관한 것이었습니다. 토큰 경제학 (Token economics)은 하나의 실제적인 학문 분야입니다. 앞서 언급한 8.6배의 놀라운 비용 상승은 제가 지금까지 청구해 온 그 어떤 데이터베이스에서도 존재하지 않았던 일입니다. 모델은 데이터 저장소 (Datastore)와는 다른 방식으로 비결정론적 (Non-deterministic)입니다. 동일한 입력이 다른 출력을 반환할 수 있기 때문에, 정확한 문자열을 단언할 수 없으며, "테스트 (Testing)"는 일치 여부 확인 대신 평가 (Evals) 및 분포 (Distributions)의 문제가 됩니다. 그리고 모델이 자신의 추론 (Reasoning)을 위해 사용자의 출력 예산 (Output budget)을 조용히 소모하는 현상은 결제 스위치 (Payment switch)에서는 찾아볼 수 없는 일입니다. 이것이 새로운 공격 표면 (Surface area)입니다. 하지만 이는 수년간 쌓아온 토대 위에 몇 주간의 새로운 경험이 더해진 것이지, 완전히 새로운 직업이 생긴 것은 아닙니다.

따라서 만약 당신이 분산 시스템 (Distributed-systems) 경험이 AI 분야로 전이될 수 있을지 궁금해하는 백엔드 엔지니어라면, 그것은 단순히 전이되는 수준을 넘어, 오히려 그 경험이 희소한 가치를 지니게 될 것입니다. 누구나 오후 한나절이면 LLM API를 호출할 수 있습니다. 하지만 제공업체의 성능이 저하될 때 그 호출을 신뢰할 수 있게 만들고, 토큰 계산 (Token math)이 불리하게 돌아갈 때 비용을 저렴하게 유지하며, 누군가 청구서를 설명해 달라고 요청할 때 관찰 가능하게 (Observable) 만드는 사람은 훨씬 적습니다. 그것은 AI 전문 지식이 아닙니다. 그것은 모델이 하나 붙었을 뿐, 당신이 이미 해오던 일입니다.

게이트웨이는 https://llm-gateway-python.onrender.com에서 확인할 수 있으며, 코드는 GitHub에 있습니다: https://github.com/Yogesh23012001/llm-gateway-python.