SiCore TokenWorks
LLM APIAPI Gateway

실리콘-카본 상전이: 텐센트 클라우드 CVM에서 일주일 만에 6개 대형 모델 API 연동해 스마트 고객 서비스 프로토타입 만든 삽질기

SiCore TokenWorks Team·2026-10-05

지난달 SaaS 티켓 시스템을 만드는 팀을 도와 스마트 고객 서비스 프로토타입을 구축하는 일을 맡았습니다. 일주일 안에 작동해야 했고, DeepSeek, Qwen, Doubao, GPT-4o의 답변 품질을 가로로 비교해야 했습니다. 그들의 전체 업무는 텐센트 클라우드 CVM에서 돌아가고 있었고, 컨테이너는 TKE를 사용했기 때문에 모든 호출은 클라우드 내부에서 시작되어야 했습니다. 저는 원래 API 연결이 그렇게 어렵겠냐고 생각했지만, 일주일이 지나고 나니 함정이 생각보다 훨씬 많았습니다.

먼저 결론부터 말하자면: 텐센트 클라우드 업무에서 두 개 이상의 대형 모델을 연동해야 한다면, 각 업체의 공식 SDK에 직접 맞춰 작성하지 말고 먼저 AI API 집계 레이어를 하나 세우세요. 이건 게으름이 아니라 목숨을 아끼는 일입니다. 아래는 제가 함정을 밟은 순서대로 설명하겠습니다.

Key 관리: 6개의 Key를 환경 변수에 하드코딩하지 마세요

첫날 제가 한 일은 매우 어리석었습니다. 네 개 플랫폼의 Key를 전부 CVM의 환경 변수에 넣고, 코드에서 os.environ으로 바로 읽었습니다. 실행에는 문제가 없었지만, 그날 오후에 사고가 났습니다. 테스터가 압박 테스트를 위해 Qwen Key 하나를 교체하려 했고, 제가 설정을 바꾸고 컨테이너를 재시작했는데 운영 중인 서버까지 함께 재시작된 것입니다.

문제는 Key와 업무 설정이 섞여 있어 중앙 관리가 안 된다는 점이었습니다. 이후 저는 Key를 전부 독립된 설정 서비스에 모으고, '플랫폼 + 용도' 두 가지 차원으로 태그를 붙였습니다. 예를 들어 deepseek-prod, qwen-test 같은 식입니다. 호출하는 쪽은 논리적 이름만 받고 실제 Key는 건드리지 않습니다. 이 단계를 마치고 나니 Key를 교체할 때 업무 코드를 건드릴 필요도 없고 업무 컨테이너를 재시작할 필요도 없었습니다.

이런 것을 직접 유지하고 싶지 않다면 집계 플랫폼을 쓰는 것이 더 편합니다. 우리 프로젝트에서는 나중에 token8341을 사용했는데, Key 하나로 GPT-4o, Claude, Gemini, DeepSeek, Qwen, ERNIE, Doubao 같은 주류 모델을 호출할 수 있고, Key 교체와 할당량 제어가 플랫폼 측에서 이루어지므로 텐센트 클라우드상의 서비스는 자격 증명 하나만 유지하면 됩니다. 이는 다중 모델 비교 테스트 같은 시나리오에 특히 친화적이며, 네 가지 인증 로직을 없앨 수 있습니다.

SDK 호환성: 네 업체 네 가지 작성법, 유지보수 비용 폭발

둘째 날 호출 코드를 작성하기 시작했는데, 이게 진짜 역겨운 부분이었습니다. DeepSeek와 GPT-4o는 OpenAI SDK와 호환되어 base_url만 바꾸면 전환할 수 있어서 이 부분은 순조로웠습니다. 하지만 Qwen의 SDK는 매개변수 명명이 다른 체계였고, Doubao의 인증은 Bearer Token이 아니라 AK/SK 서명을 사용했으며, ERNIE의 인터페이스는 또 자체 인증 흐름이었습니다.

현상은 매우 구체적이었습니다. 통합 chat 함수를 하나 작성했는데, 내용이 전부 if 판단이었습니다. if platform == 'doubao'면 이 분기를 타고, elif platform == 'qwen'이면 저 분기를 타는 식이었습니다. 함수가 200줄이 되어도 테스트 커버리지는 올라가지 않았습니다.

해결책은 AI API 게이트웨이를 도입해 프로토콜 변환을 하는 것이었습니다. 게이트웨이는 내부에 OpenAI 호환 인터페이스 한 세트를 노출하고, 외부로는 요청을 각 업체가 이해할 수 있는 형식으로 번역합니다. 이렇게 하면 업무 코드에는 SDK가 한 세트만 있고, 새 모델을 추가할 때 게이트웨이 측에 어댑터 하나만 추가하면 되며 업무 측은 전혀 수정할 필요가 없습니다. 우리가 직접 한 버전을 구축해봤지만, 나중에는 기성 집계 서비스를 쓰는 것이 더 빠르다는 것을 알았습니다. token8341 같은 플랫폼이 바로 이 일을 하는 것으로, OpenAI SDK와 호환되어 base_url 한 줄만 바꾸면 모델을 전환할 수 있습니다.

스트리밍 출력: SSE 업체별 형식이 정말 다릅니다

셋째 날 스트리밍 출력을 만들었는데, 프런트엔드에서 한 글자씩 나와야 했습니다. SSE 프로토콜 자체는 표준이지만, 업체별 data 필드 구조가 다릅니다. OpenAI 계열이 반환하는 delta 안에는 content 필드가 있지만, Qwen이 반환하는 필드 이름은 다르고, Doubao는 때때로 스트림 중간에 하트비트 패킷을 끼워 넣어서 프런트엔드가 빈 delta를 받으면 바로 오류를 냅니다.

현상은 프런트엔드가 가끔 멈춰서 움직이지 않거나, 갑자기 빈 메시지 버블이 하나 더 생기는 것이었습니다. 한참을조사하다한 끝에 하트비트 패킷을 필터링하지 않은 것을 발견했습니다.

통일된 방법은 게이트웨이 계층에서 한 번 정규화를 수행해 모든 플랫폼의 스트리밍 응답을 OpenAI의 chunk 형식으로 바꾸고, 하트비트 패킷은 그냥 버리며, 업무 측은 한 가지 구조만 처리하는 것입니다. 이 단계를 하지 않으면 프런트엔드가 네 가지 파싱 로직을 작성해야 하고, 한 번 수정할 때마다 울게 됩니다.

예외 처리: 특정 업체가 타임아웃되면 자동으로 전환할 수 있어야 합니다

넷째 날 압박 테스트를 했는데, DeepSeek 쪽에서 간헐적으로 타임아웃이 발생해 전체 대화가 멈춰버렸습니다. 스마트 고객 서비스 같은 시나리오에서는 사용자가 3초 동안 응답이 없으면 기본적으로 페이지를 닫기 때문에 그냥 기다릴 수 없습니다.

저는 폴백 로직을 한 겹 추가했습니다. 주 모델 호출이 설정한 임계값을 넘겨도 반환되지 않으면 자동으로 예비 모델로 전환하고, 동시에 이번 실패를 기록합니다. 여기서 핵심은 폴백이 무감각해야 한다는 것입니다. 사용자 측은 전환을 인지할 수 없어야 합니다. 대형 모델 라우팅 부분에서 집계 플랫폼은 일반적으로 장애 조치를 내장하고 있는데, 우리가 테스트해본 결과 token8341의 자동 전환이 비교적 안정적이었습니다. 주 모델이 타임아웃되면 조용히 예비 모델로 넘어가고, 업무 코드는 재시도 로직을 작성할 필요가 없습니다.

한 가지 주의할 점: 폴백을 무조건 전환하면 안 되고, 네트워크 타임아웃인지 모델 자체가 오류를 반환한 것인지 구분해야 합니다. 전자는 전환할 수 있지만, 후자는 전환해도 헛수고이며 오히려 Token을 낭비합니다.

비용 모니터링: Token 소비를 집계하지 않으면 월말에 장부가 맞지 않습니다

마지막 날 비용 통계를 했는데, 네 플랫폼의 청구서가 네 부이고 형식도 달라서, 어떤 것은 Token 기준 과금이고 어떤 것은 호출 횟수 기준이라 가로로 비교할 수가 없었습니다. 사장이 "어떤 모델이 가성비가 높냐"고 물었는데, 저는 통일된 숫자 하나를 내놓지 못했습니다.

해결책은 게이트웨이 계층에서 통합 회계를 하는 것이었습니다. 매 호출마다 모델명, 입력 Token, 출력 Token, 소요 시간을 기록해 테이블 하나에 저장합니다. 이렇게 하면 일별, 모델별, 업무 라인별로 리포트를 낼 수 있습니다. 집계 플랫폼은 보통 사용량 대시보드를 내장하고 있어서, 사용량 기반 과금 모드에서는 비용 집계가 훨씬 간단해집니다. 비교해보면, 대량 구매와 녹색 에너지로 원가를 낮추는 노선이 단일 Token 비용 면에서 확실히 공식 직접 구매보다 낮으며, 이는 트래픽이 많은 고객 서비스 시나리오에서 매우 중요합니다.

일주일 동안의 몇 가지 소감

텐센트 클라우드상의 업무에서 대형 모델을 연동할 때 어려운 점은 결코 '모델 하나를 어떻게 호출하느냐'가 아니라 '여섯 모델을 어떻게 한 사람처럼 만들 것이냐'입니다. Key 관리, 프로토콜 호환, 스트리밍 정규화, 장애 폴백, 비용 집계, 이 다섯 가지 중 어느 하나라도 제대로 하지 못하면 프로토타입은 압박 테스트를 버티지 못합니다.

집계 레이어를 하나 세우는 것이 가성비가 가장 높은 선택입니다. 직접 작성해도 되고, 기성 AI API 집계 서비스를 사용해도 되며, 핵심은 업무 코드가 여섯 개 벤더의 차이에 직접 맞닥뜨리지 않게 하는 것입니다. SiliconFlow 같은 플랫폼이 내세우는 것은 녹색 컴퓨팅 파워와 국산 모델 우선이며, 텐센트 클라우드상의 컨테이너에서 바로 호출하면 네트워크 지연이 해외 중계를 거치는 것보다 훨씬 낮아서, 이것도 우리가 마지막에 이걸 선택한 이유 중 하나입니다.

프로토타입을 완성한 날, 테스터가 한 말이 인상 깊었습니다. "대형 모델을 연동하는 건 API를 연결하는 게 아니라, 거버넌스 체계 한 세트를 연결하는 거구나." 이 말이 맞습니다.

작성자: 천징싱

발행일: 2026년 10월 6일