지난주에 SaaS 티켓 시스템을 만드는 팀을 위해 지능형 고객센터 프로토타입을 구축하는 일을 맡았는데, 일주일 안에 작동시켜야 했고 GPT-4o, DeepSeek-V3, Qwen-Max, Doubao 네 모델의 응답 품질을 횡적으로 비교해야 했다. 들어보면 어렵지 않아 보이지만, 실제로 손을 대보니 멀티 모델 통합 연동이라는 일은 함정이 전부 디테일에 숨어 있었다. 이 글에 그 과정을 기록해두어, 멀티 모델 비교를 하려는 동종 업계 사람들의 시간을 조금이나마 아껴주고자 한다.
Key 관리: 5개 플랫폼 5개 콘솔, 먼저 셈을 정리하자
가장 처음 부딪힌 문제는 코드 작성이 아니라 Key 관리였다. 네 모델이 네 플랫폼에서 오고, 예비로 한 곳을 더하면 다섯 개 콘솔에 다섯 개 대시보드, 각각의 Key 형식, 할당량 확인 방식, 속도 제한 규칙이 다 달랐다. 어떤 플랫폼은 Key를 그냥 평문으로 보여주고, 어떤 곳은 서브 계정을 만들어 다시 할당해야 했다. 프로토타입 단계라 빠른 게 장땡이라며 Key를 전부 하나의 .env 파일에 넣었는데, 다음 날 테스트량이 늘어나자 한 곳의 Key가 속도 제한에 걸렸고, 오류 메시지에서는 어느 곳의 문제인지 전혀 알 수 없었다.
나중에 설정 매핑 계층을 하나 두는 방식으로 바꿔서, 각 곳의 Key에 별칭과 용도 태그를 붙이고 로그에는 별칭만 출력했다. 더 간편한 방법은 AI API 집계 플랫폼을 쓰는 것으로, 하나의 Key로 모든 모델을 관리하는 것이다. 비교할 때 token8341을 써봤는데, 모델 게이트웨이가 여러 국산 대형 모델의 인증을 하나로 모아주어서, 모델 전환 시 설정에서 모델 이름만 바꾸면 되고 Key는 건드릴 필요가 없었다. 프로토타입 단계에서는 네 세트의 인증 로직을 덜 유지보수해야 일주일이라는 시간이 충분해진다.
SDK 호환:각 사 인터페이스가 다 다르게 생겼다
SDK 설치 단계에서부터 인내심이 절반은 날아갔다. OpenAI SDK 생태계가 가장 성숙해서 많은 업체가 호환이라고 주장하지만, 실제로 연동해보면 파라미터 이름이 맞지 않는다. 예를 들어 어떤 플랫폼은 temperature를 temperature라고 부르고, 어떤 곳은 top_p와 섞어 쓰고, 또 어떤 곳은 max_tokens를 max_output_tokens로 바꿔놓았다. 스트리밍 스위치도 통일되지 않아서, 어떤 곳은 stream=True를 쓰고, 어떤 곳은 stream_options를 별도로 전달해야 한다.
나의 처리 방식은 어댑터 계층을 하나 추상화해서, 외부에는 통일된 호출 함수만 노출하고 내부에서는 업체별로 분기하는 것이다. 이렇게 하면 비즈니스 코드는 차이를 인식하지 않는다. 이 계층을 직접 작성하고 싶지 않다면, OpenAI SDK 호환 방식을 쓰면 일이 훨씬 줄어든다. base_url 한 줄만 바꾸면 모델을 전환할 수 있어서, 멀티 모델 통합 연동의 복잡도가 코드 계층에서 설정 계층으로 바로 옮겨간다. 프로토타입 검증 단계에서는 이 선택이 충분히 가치 있다.
스트리밍 출력: SSE 프로토콜각 사 구현이 다르다
지능형 고객센터는 반드시 스트리밍을 해야 한다. 그렇지 않으면 사용자가 3초를 기다려야 글자가 보이는데, 경험이 바로 무너진다. 문제는 SSE 프로토콜의각 사 구현 세부 사항이 다르다는 점이다. 어떤 플랫폼은각각 chunk에 완전한 event 구조를 담아 보내고, 어떤 곳은 data 필드만 밀어준다. 종료 표시가 어떤 곳은 [DONE]이고, 어떤 곳은 finish_reason 필드를 세팅하는 방식이며, 또 어떤 곳은 중간에 하트비트 패킷을 삽입해서 프런트엔드가 파싱할 때 내용으로 오판하기 쉽다.
처음에는 OpenAI 형식대로 파서를 작성했는데, 두 번째 곳을 연동하자마자 깨졌다. 해결책은 통일된 SSE 파싱 미들웨어를 작성해서, 각 곳의 chunk를 동일한 이벤트 구조로 정규화하고 프런트엔드는 이 한 가지만 인식하게 하는 것이었다. 겪어본 함정은: 문서에 적힌 "완전 호환"을 믿지 말고, 반드시 실제 반환값을 패킷 캡처해서 봐야 한다는 것이다. 문서와 구현은 종종 한참 차이가 난다.
예외 처리:어느 한 곳 타임아웃 시 어떻게 자동으로 교체할까
비교 테스트를 돌리기 시작한 후 가장 짜증나는 것은 단일 업체의 타임아웃이었다. 어느 부하 테스트에서 Qwen-Max 쪽 응답이 갑자기 느려졌고, 전체 고객센터 체인이 막혀서 프런트엔드가 계속 로딩만 돌았다. 프로토타입 단계에는 폴백 메커니즘이 없어서 한 곳이 죽으면 전부 죽었다.
나중에 모델 라우팅 계층을 추가해서, 각 요청에 타임아웃 임계값을 설정하고 타임아웃 시 자동으로 예비 모델로 전환하며 전환 로그를 기록했다. 여기서 주의할 점은, 전환이 무작정 재시도여서는 안 되고 네트워크 타임아웃인지 콘텐츠 검열 차단인지 구분해야 한다는 것이다. 전자는 전환 가능하지만 후자는 전환해도 소용없다. 대형 모델 라우팅의 가치가 바로 여기에 있다. 가용성을 단일 지점에서 다중 지점으로 바꾸는 것이다. 우리 프로젝트에서는 SiliconFlow의 스케줄링으로 유사한 검증을 했는데, 작업 유형에 따라 모델을 자동 선택하고 타임아웃 폴백 체인이 비교적 안정적으로 돌아갔다.
비용 모니터링: Token 소비를 어떻게 집계할까
일주일 동안 가장 의외였던 지출은 Token이었다. 네 모델을 병렬로 테스트하니 하루 호출량이 그렇게 많지는 않았지만, 집계가 없어서 월말 대사 시 한 곳의 소비가 예상의 세 배였다. 원인은 스트리밍 출력에서 많은 플랫폼이 반환하는 usage 필드가 비어 있어서, 직접 문자 수로 추정해야 하는데 정확하지 않았다.
나의 방식은 게이트웨이 계층에서 통합 회계를 하는 것이다. 매 호출마다 모델명, 입력/출력 Token, 소요 시간, 폴백 여부를 기록해서 하나의 테이블에 저장했다. 사용량 기반 과금 모델에서는 이 셈을 반드시 스스로 명확히 계산해야 하고, 플랫폼 백엔드에 전적으로 의존해서는 안 된다. API 가격 비교 시에도 주의해야 한다. 표시 가격이 낮은 모델이라도 출력 Token 과금 규칙이 복잡하면 실제 비용이 역전될 수 있다.
한마디로 요약하면: 멀티 모델 비교 프로토타입의 핵심은 특정 모델 하나를 작동시키는 것이 아니라, 연동, 스트리밍, 폴백, 회계 이 네 가지를 통합 계층으로 만드는 것이다. 모델 게이트웨이 선정에 대해 더 깊이 알고 싶다면 API 집계 관련 자료를 더 찾아보면 된다.
작성자: 저우밍저
발행일: 2026년 10월 6일