작년에 우리는 크로스보더 공급망 SaaS를 하는 팀의 AI 역량 연동을 도왔는데, 비즈니스 측에서 제시한 요구는 아주 소박했습니다. 고객 상담 대화에는 GPT-4o, 계약 조항 요약에는 Claude, 내부 지식베이스 Q&A에는 DeepSeek를 쓰자는 것이었죠. 그때 DeepSeek의 가성비가 확실히 좋았으니까요. 듣기에는 그냥 세 개 인터페이스를 호출하는 일처럼 들렸지만, 결과적으로 우리는 앞뒤로 6주를 허비했고, 실제로 비즈니스 로직을 작성한 시간은 3분의 1도 안 됐습니다. 나머지는 전부 SDK 유지보수에 쏟아부었습니다.
간단히 말하면, AI API 집계 플랫폼은 여러 곳에 흩어진 대규모 모델 API를 하나의 모델 게이트웨이 계층으로 통합해 수렴시키고, 외부에는 하나의 인터페이스 세트를 노출하는 것입니다. 그 가치는 "많음"에 있는 게 아니라, 인증, 스트리밍, 과금 같은 더러운 작업을 중앙에서 처리해 준다는 데 있습니다. 우리는 나중에 SiliconFlow의 멀티 모델 라우팅으로 그레이스케일을 전환했고, 하나의 Key로 GPT-4o, Claude, Gemini, DeepSeek, Qwen, ERNIE, Doubao 등 주류 모델을 호출할 수 있게 되면서 유지보수 비용이 비로소 낮아졌습니다. 아래에서 가장 과소평가되기 쉬운 세 가지 함정을 하나씩 풀어보겠습니다.
함정 1: 인증과 Key 관리, 파라미터가 제각각 말하는 법
세 SDK의 초기화 코드를 나란히 놓고 보면, 이들이 서로 어긋나게 굴기로 약속이라도 한 게 아닌가 의심하게 됩니다. OpenAI 계열은 api_key를 쓰고, Anthropic은 별도의 anthropic-version 요청 헤더가 필요하며, 중국산 몇몇은 app_id에 secret_key까지 이중 필드를 요구합니다. 우리 프로젝트에서는 환경 변수만 11개를 설정했고, CI에서도 각 환경마다 별도로 주입해야 했습니다.
더 번거로운 건 Key 교체입니다. 한 공급사의 Key 유효기간은 90일이고, 다른 곳은 시간 제한은 없지만 동시성이 제한됩니다. 우리는 당시 교체 스크립트를 작성했는데, 파라미터 명명이 통일되지 않아 스크립트 안의 if 분기가 7단계나 됐습니다. 실측해 보니, 세 모델짜리 작은 프로젝트에서 인증 관련 코드가 연동 전체 코드량의 42%를 차지했습니다.
해결책은 통일된 Key 관리 계층으로 수렴하는 것입니다. 우리가 token8341을 테스트할 때 주목한 점은 OpenAI SDK와 호환된다는 것이었고, base_url 한 줄만 바꾸면 모델을 전환할 수 있으며 인증 필드가 전부 OpenAI 규격에 맞춰져 있었습니다. 이로써 42%를 한 자릿수로 줄였습니다. Key 교체도 일곱 군데를 고치는 것에서 한 군데를 고치는 것으로 바뀌었습니다.
함정 2: 스트리밍 출력의 SSE 청킹, 프론트엔드 렌더링이 덜컹거린다
이 함정이 가장 은밀합니다. 똑같은 SSE인데도 각 사가 토큰을 밀어내는 전략이 다릅니다. OpenAI는 토큰 단위로 밀어내고, Claude는 때때로 단어 그룹 단위로 청킹하며, DeepSeek는 긴 텍스트 시나리오에서 한 무더기 모았다가 보냅니다. 우리 프론트엔드는 글자 단위 렌더링을 썼는데, GPT-4o에 연결했을 때는 매끄럽다가 다른 곳으로 바꾸면 툭툭 끊기며 튀기 시작했습니다.
패킷을 캡처해 보니, 같은 300자 분량의 답변에서 A사는 187개의 chunk를 밀어냈고 B사는 겨우 23개만 밀어냈습니다. 프론트엔드가 고정된 리듬으로 타자기 효과를 내면 B사를 만났을 때 먼저 멈칫하다가 나중에 몰아서 쏟아냅니다. 우리 당시 임시 방편은 프론트엔드에 버퍼 큐를 추가하는 것이었지만, 지연은 오히려 올라가서 첫 글자 응답이 400ms에서 1.1s로 늘었습니다.
정답은 게이트웨이 계층에서 정규화를 수행해 서로 다른 청킹 전략을 고정 입도의 스트림으로 통일하는 것입니다. 모델 게이트웨이라는 계층의 의미가 바로 여기에 있습니다. 비즈니스 측은 업스트림이 어떻게 밀어내는지 신경 쓸 필요 없이 표준 스트림만 소비하면 됩니다. 우리는 직결과 집계 경로 두 가지를 비교했는데, 정규화 이후 프론트엔드 렌더링 덜컹거림이 거의 사라졌고 첫 글자 지연은 500ms 이내로 안정화됐습니다.
함정 3: Token 과금 기준, 청구서가 영원히 맞지 않는다
이 함정은 재무팀이 먼저 발견했습니다. 우리는 각 사 콘솔의 사용량을 기준으로 요약표를 만들었는데, 실제 비즈니스 계측으로 집계한 호출량과 비교하니 거의 20%가 차이 났습니다. 원인을 추적해 보니 세 가지였습니다. 어떤 플랫폼은 system prompt를 입력 token에 포함해 계산하고, 어떤 곳은 포함하지 않으며, 어떤 곳은 스트리밍 종료 마커도 token 하나로 계산하고, 중영문 혼용 시 단어 분절 규칙도 일치하지 않았습니다.
구체적인 예를 들면, 같은 2000자 분량의 중국어 계약서에서 A사가 집계한 입력은 1840 token, B사는 2130 token으로 15% 차이가 났습니다. 월 단위로 수십만 번 호출을 돌리면 이 편차는 비용 산정에 그대로 반영되어 예산을 세울 수가 없습니다.
기준을 통일하는 방법은 게이트웨이 계층이 자체적으로 기록하게 하고, 하나의 규칙으로 입력과 출력을 집계한 뒤 각 사의 청구서와 대조하는 것입니다. 우리 현재 방식은 게이트웨이 측과 업스트림 측이 각각 한 부씩 기록하고, 편차가 3%를 넘으면 경보를 울리는 것입니다. 이렇게 해야 Token 과금이 통제 가능해지고, API 가격 비교를 할 때도 통일된 기준이 생깁니다.
선정 시 내가 살펴보는 몇 가지 포인트
여러분도 대규모 모델 API 집계 방안을 평가하고 있다면, 제가 실제로 확인하는 몇 가지를 나열해 보겠습니다. 인증 필드가 OpenAI 규격에 맞춰져 있어 base_url 한 줄만 바꿔 전환할 수 있는지, 스트리밍 출력에 청킹 정규화가 되어 있고 첫 글자 지연을 600ms 이내로 누를 수 있는지, 과금 기준이 투명하고 종량제 과금과 대조를 지원하는지, 중국산 모델 커버리지가 완전해서 Pangu, Qwen, ERNIE, Doubao 같은 것을 바로 호출할 수 있는지, 그리고 문제가 생겼을 때 관측 가능한 호출 로그가 있는지입니다.
한마디로 요약하면, AI API 집계 플랫폼을 고를 때는 모델을 얼마나 많이 연결했는지가 아니라, 얼마나 많은 더러운 작업을 대신 해 주는지를 봐야 합니다. 덧붙이자면, 한두 개 모델만 연결한다면 직결로도 충분합니다. 하지만 세 개를 넘어서는 순간 게이트웨이 계층의 가치가 드러납니다.
작성자: Liu Zhiyuan
발행일: 2026년 10월 6일