AI gateway 라는 추상 레이어

결제 파이프라인에 LLM이 들어오는 순간 생기는 구조적 문제

결제나 정산 시스템에 LLM을 처음 붙일 때는 결정이 단순하다. "영수증 텍스트를 파싱한다", "이상 거래 패턴을 설명한다" — 기능 하나에 SDK 하나를 import하고 끝낸다. 문제는 이 결정이 대개 3~6개월 뒤 발목을 잡는다는 점이다. 결제 시스템은 본질적으로 고빈도·저지연·고가용성을 동시에 요구한다. LLM 호출이 트랜잭션 경로 안에 있는 순간, 공급자 하나의 장애가 곧 서비스 전체 중단이 된다. 특정 모델을 SDK 호출로 하드코딩한 코드가 열 곳에 퍼져 있다면, 다른 모델로 전환하는 일은 기술 부채 상환과 다름없어진다.

HEDVION에서는 정산 자동화에 LLM을 붙이는 시점부터 "나중에 교체 가능한가"를 의식적으로 물었다. 영수증 파싱, 정산 이상 탐지, 고객 문의 자동 응답 — 이 세 태스크는 요구사항이 완전히 다르다. 파싱은 비용이 우선이고, 이상 탐지는 정확도가 우선이며, 고객 응답은 레이턴시가 우선이다. 단일 모델로 세 가지를 동시에 최적화하는 건 처음부터 불가능하다. 이 현실이 AI Gateway를 '좋으면 쓰는 것'이 아닌 운영 인프라로 만들었다.

추상 레이어의 핵심: 코드가 아닌 설정이 모델을 결정한다

AI Gateway의 가치는 "어떤 모델을 쓸지"가 코드가 아닌 설정의 문제가 된다는 점이다. 직접 호출 구조에서 모델을 바꾸려면 코드를 수정하고, PR을 올리고, 배포해야 한다. 이 사이클 자체가 "일단 지금 모델 그냥 쓰자"는 관성을 만든다. 실험을 해야 데이터가 생기고, 데이터가 있어야 결정을 내릴 수 있는데, 실험 비용이 너무 높으면 실험을 안 하게 된다.

게이트웨이를 두면 이 구조가 달라진다. 애플리케이션은 gateway.complete(task="receipt_parse", messages=[...]) 만 안다. 어떤 공급자의 어떤 모델을 쓸지는 YAML 설정 파일이 결정한다. 우리 팀 기준으로는 파일 한 줄을 수정하는 것으로 특정 태스크의 모델을 바꾸고, 운영 중에 즉시 반영할 수 있다. 배포 없이 실험이 가능하다는 건 소규모 팀에서 특히 의미가 크다. 실험 비용이 낮아지면 실험 횟수가 늘고, 데이터에 기반한 모델 결정이 가능해진다. 처음부터 LiteLLM이나 Portkey 같은 솔루션을 가져다 쓸 수도 있고, 우리처럼 경량 래퍼 클래스로 시작해서 인터페이스를 먼저 확정한 뒤 내부 구현을 교체할 수도 있다. 어느 쪽이든 핵심은 같다 — 애플리케이션 코드가 공급자를 모르도록 만드는 것.

수치로 본 트레이드오프: 비용, 레이턴시, 가용성

구체적인 숫자를 보자. 영수증 파싱 태스크 하나의 평균 토큰 사용량이 입력 600토큰, 출력 300토큰이라 가정하면, GPT-4o 기준 호출당 약 $0.0045, Claude 3 Haiku 기준 약 $0.0005다. 약 9배 차이다. 하루 처리 건수가 1만 건이라면 하루 $45 대 $5, 한 달 환산 시 $1,350 대 $150이다. 연간으로 보면 $14,400이 절감된다. 이 숫자를 놓고 "정산 정확도 요구사항이 높지 않은 1차 파싱 단계에는 Haiku를, 이상값이 감지된 건만 GPT-4o로 재검증하는 티어드 구조"를 설계하는 것이 합리적인 판단이다. 이걸 각 호출 지점의 코드로 관리하면 복잡도가 급격히 올라가지만, 게이트웨이 라우팅 규칙으로 표현하면 설정 수준의 문제가 된다.

레이턴시는 반대 방향의 트레이드오프가 있다. 게이트웨이가 동일 VPC 내에 있으면 추가 홉은 5ms 이내로 무시 가능하다. 그러나 외부 관리형 게이트웨이 서비스를 쓰면 네트워크 홉이 늘어난다. 서울 리전에서 외부 게이트웨이를 경유하면 실측 기준 30~60ms가 추가된다. 결제 확인 응답을 3초 이내에 줘야 하는 실시간 경로라면 이 수치가 작지 않다. 우리 팀의 결론은 실시간 결제 경로에서는 게이트웨이를 동일 인프라 안에서 운영하거나, 해당 경로만 직접 호출을 예외 처리로 남겨두는 것이다. 추상화가 100% 일관될 필요는 없다 — 예외를 설계하는 것도 설계다.

HEDVION 실전 시나리오: 40분 장애가 바꾼 폴백 설계

2024년 말, 정산 이상 탐지 파이프라인이 OpenAI API에 직접 의존하던 시절에 있었던 일이다. OpenAI가 약 40분간 간헐적 5xx 오류를 냈고, 그 40분 동안 이상 탐지 결과가 누락되었다. 파이프라인이 직접 호출 구조였기 때문에 폴백 경로 자체가 없었고, 후처리에서 수작업으로 복구해야 했다. 시간으로 치면 두 시간, 비용으로 치면 측정하기 싫은 숫자였다.

이후 게이트웨이를 도입하면서 이 파이프라인에 3단 폴백 체인을 구성했다. 기본은 GPT-4o, 타임아웃이나 오류 시 Claude Sonnet으로 자동 전환, 둘 다 실패하면 로컬 규칙 기반 탐지로 degraded mode 처리하는 구조다. 완전한 대체는 아니지만 서비스 중단이 데이터 누락으로 이어지는 상황을 막는다. 이 폴백 로직을 직접 호출 구조에서 구현하려면 각 호출 지점마다 try/except와 재시도 로직을 중복으로 작성해야 한다. 게이트웨이는 이걸 설정으로 추상화한다. 고객 문의 자동 응답 파이프라인에서는 다른 교훈을 얻었다. 동일 유형 질문(환불 정책, 정산 일정)이 반복 유입되는 특성 덕분에 게이트웨이의 시맨틱 캐싱을 적용했더니, 전체 LLM 호출의 약 38%가 캐시에서 응답되었다. 해당 비용은 0이 되었고, 평균 응답 레이턴시는 1.2초에서 80ms 이하로 떨어졌다.

추상화의 대가: 우리가 실제로 포기한 것들

AI Gateway가 해결하는 문제만큼, 포기하는 것도 솔직하게 짚어야 한다. 가장 현실적인 비용은 모델 고유 기능의 접근성이다. Anthropic의 extended thinking, OpenAI의 strict mode structured outputs — 이런 기능들은 각 공급자 SDK를 직접 써야 최대로 활용 가능하다. 게이트웨이의 공통 인터페이스는 최대공약수 수준에 머무른다. 정산 검증처럼 정확도가 중요한 태스크에 extended thinking을 실험할 때, 우리 팀은 그 경로만 게이트웨이를 우회해서 Anthropic SDK를 직접 호출하는 예외를 허용하고 있다. 추상화가 완벽할 필요는 없다 — 어디에 구멍을 낼지를 의식적으로 결정하는 것이 설계다.

두 번째는 게이트웨이 자체가 단일 장애점이 될 수 있다는 점이다. HEDVION에서는 게이트웨이에 헬스체크와 자동 재시작을 걸고, 게이트웨이 장애 시 critical path에서 특정 공급자로 직접 폴백하는 회로 차단기 패턴을 추가했다. 추상 레이어가 실패할 때의 탈출구를 미리 설계해두는 것이 핵심이다. 게이트웨이를 도입하는 것과 게이트웨이에 완전히 종속되는 것은 다른 이야기다.

지금 당장 쓸 수 있는 4가지 시사점

1. LLM 기능이 두 개 이상이거나 비용 추적이 필요해진 순간 게이트웨이를 고려하라. 단일 기능에 단일 모델이라면 오버엔지니어링이다. 그러나 "파싱용 모델"과 "응답용 모델"이 나뉘는 순간, 설정으로 관리하지 않으면 복잡도는 코드에 쌓인다.

2. 경량 래퍼 클래스로 시작해서 인터페이스를 먼저 확정하라. 오픈소스 솔루션 도입 전에 인터페이스 계층을 직접 설계해두면, 나중에 내부 구현을 교체할 때 애플리케이션 코드는 건드리지 않아도 된다. 인터페이스 안정성이 이식성을 만든다.

3. 실시간 결제 경로와 배치 정산 경로를 분리해서 게이트웨이 적용 범위를 다르게 가져가라. 레이턴시 예산이 타이트한 실시간 경로에서는 게이트웨이 홉을 실측하고 허용 범위를 확인한 뒤 결정하라. 배치 파이프라인은 레이턴시 허용 범위가 훨씬 넓어서 게이트웨이의 이점을 온전히 누릴 수 있다.

4. 태스크별 비용 추적을 게이트웨이 도입과 동시에 켜라. "LLM 비용이 얼마인지 모른다"는 상태는 볼륨이 작을 때는 괜찮지만, 트랜잭션이 늘면 통제 불가능한 비용 구조로 이어진다. 게이트웨이가 있으면 태스크별·공급자별·모델별 토큰 사용량 집계가 설정 수준의 문제다. 이 데이터가 있어야 "어떤 태스크를 더 저렴한 모델로 내릴 수 있는가"를 감이 아닌 데이터로 결정할 수 있다.