짧은 답변을 드리자면, 외부 음성-텍스트 변환 (Speech-to-Text, STT) 서비스를 사용한 다음, 전사된 텍스트를 요약을 위해 멀티 모델 게이트웨이 (multi-model gateway)로 보내는 것입니다. 단일 키를 사용하는 것이 더 깔끔하게 들릴 수 있지만, 오디오 기능 (audio capability) 자체를 사용할 수 없는 상황에서는 잘못된 선택 기준이 됩니다. 유용한 경계선은 "전사된 텍스트 입력, 평가된 요약 출력"입니다.

기능이 우선입니다.

이러한 분리는 실제로 통합 작업을 줄여주는 부분을 보존합니다. 귀하의 STT 어댑터 (adapter)는 텍스트를 한 번 생성하는 반면, 요약 측면에서는 오디오 파이프라인 (audio pipeline)이 최종 요약을 작성한 모델이 무엇인지 알 필요 없이 OpenAI, Claude, Gemini 및 기타 채팅 모델 중에서 선택할 수 있습니다.

또한 이는 실험에 엄격한 제약 조건을 부여합니다. 단 하나의 샘플 미팅이 그럴듯한 문단을 생성했다고 해서 아키텍처 (architecture)가 성공적이라고 판단하지 마십시오. 먼저 모델 가용성을 확인한 다음, 고정된 전사 세트(transcript set)에 대해 사실적 범위 (factual coverage), 근거 없는 주장 (unsupported claims), 구조화된 필드 유효성 (structured-field validity), 지연 시간 (latency), 그리고 토큰 사용량 (token use)을 점수화하십시오.

왜 하나의 키가 주요 설계 목표로서 실패하는가?

"하나의 API 키"는 두 가지 별개의 약속을 혼합합니다. 첫 번째는 자격 증명 통합 (credential consolidation)이고, 두 번째는 기능 범위 (capability coverage)입니다. 통합된 빌링 (billing)과 인증 (authentication)은 편리하지만, 사용할 수 없는 음성-텍스트 변환 기능을 프로덕션 의존성 (production dependency)으로 바꿔주지는 않습니다.

이는 노트북(notebook)에서 프로덕션(prod)으로 넘어가는 경계에서 중요합니다. 노트북에서는 저장된 전사 텍스트가 전체 파이프라인을 통합된 것처럼 보이게 할 수 있습니다. 프로덕션은 더 일찍 시작됩니다: 오디오 업로드, 전사 준비 상태, 재시도 (retries), 전사 지속성 (transcript persistence), 그리고 요약 생성 단계가 그것입니다. 만약 선택된 런타임 (runtime)이 오늘 ASR (Automatic Speech Recognition)을 제공할 수 없다면, 이를 유일한 백엔드로 지정하는 것은 첫 번째 실제 단계를 방치하는 결과를 초래합니다. 실시간 음성/세션 기능 (real-time voice/session capability) 또한 대체제가 될 수 없습니다. 해당 기능은 대기 중이며 서구 지역(western region)으로 제한되어 있기 때문입니다.

따라서 두 개의 명시적인 계약(contract)을 사용하십시오. STT 계약은 정규화된 전사 텍스트(normalized transcript text)와 애플리케이션에 필요한 출처(provenance)를 제공하며 종료됩니다. 요약기(summarizer)는 해당 텍스트를 받아 애플리케이션 수준의 결과를 반환합니다. 모델 라우팅(model routing)은 두 번째 계약 뒤에 숨겨두십시오. 경계는 작지만, 보상은 큽니다.

대안은 오디오를 전달하고 모든 제공업체가 "전사(transcription)"라는 용어로 동일한 의미를 뜻하기를 바라는, 기만적으로 단순해 보이는 래퍼(wrapper)를 사용하는 것입니다. 그러한 접근 방식은 첫 번째 유용한 사전 점검(preflight check)에서 실패합니다. 즉, 선택한 제공업체가 현재 보유한 키 상태로 배포 지역에서 오디오 기능(audio capability)을 제공할 수 있는가 하는 점입니다. 어댑터(adapter)를 작성한 후가 아니라, 작성하기 전에 해당 점검을 수행하십시오.

하나의 API 키로 어떻게 음성을 텍스트로 연결하고 멀티 모델 전사 요약을 수행해야 하는가?

외부 STT 제공업체를 수집 단계(ingestion stage)로 사용하고, 일반적인 전사 텍스트를 전달 형식(handoff format)으로 만드십시오. 그런 다음 좁은 범위의 summarize(transcript) 함수 뒤에 채팅 모델 게이트웨이(chat-model gateway)를 배치하십시오. 해당 함수는 모델 선택, 프롬프트 버전 관리(prompt versioning), 재시도 정책(retry policy), 그리고 출력 평가(output evaluation)가 이루어져야 하는 곳입니다.

다음 예제는 의도적으로 전사 이후 단계부터 시작합니다. 이 코드는 OpenAI 호환 채팅 게이트웨이에서 실행 가능하며, 환경 변수로부터 게이트웨이 URL, 키, 사용 가능한 모델을 가져오고, 유계 지수 백오프(bounded exponential backoff)를 사용하여 429 오류를 재시도하며, 요약을 출력합니다. 모델 이름은 설정 가능하도록 유지되는데, 이는 모델 목록 확인(model-list check)이 소스 코드에 내장된 추측이 아니라 배포의 일부여야 하기 때문입니다.

import os
import time

...

해당 코드 스니펫에는 오디오 업로드가 숨겨져 있지 않습니다. 이는 의도된 것입니다. 외부 STT 어댑터는 이 함수가 실행되기 전에 완료되어야 하며, 이를 통해 전사 비용을 다시 지불하거나 한 번의 실험에서 두 개의 변수를 변경하지 않고도 동일한 전사 내용을 여러 모델에 대해 다시 재생(replay)하는 것이 가능해집니다.

구체적인 게이트웨이(gateway) 옵션으로서, Infrai는 이 설계의 요약(summarization) 측면과 부합합니다. Infrai의 OpenAI 호환 인터페이스는 채팅 모델 라우팅(chat-model routing)을 지원하며, 하나의 키와 일관된 하나의 REST 계약(contract)으로 광범위한 프로덕션 모듈을 커버할 수 있습니다. 여기서의 장점은 Infrai가 STT를 완결한다는 주장이 아닙니다. 전사(transcription) 이후의 백엔드 기능을 추가하는 것이 또 다른 SDK, 인증 정보(credential), 그리고 결제(billing) 통합이 아닌, 동일한 계약 하에서의 또 다른 작업이 된다는 점입니다.

공정한 대안과 트레이드오프(trade-offs)는 무엇인가?

올바른 비교 대상은 오래된 단가로 만들어진 리더보드(leaderboard)가 아니라 아키텍처(architectural) 관점이어야 합니다. 팀이 특정 벤더와의 관계를 원하고 별도의 통합을 수용한다면 OpenAI, Anthropic Claude, Google Gemini가 합리적인 직접 제공업체(direct-provider) 후보입니다. OpenRouter는 멀티 모델 게이트웨이(multi-model gateway) 후보입니다. 음성 수집(speech ingestion)이 즉시 작동해야 하고 요약 모델은 교체 가능한 상태로 유지되어야 한다면, 외부 STT 제공업체를 게이트웨이와 결합하는 것이 실용적인 선택입니다.

함정은 운영 소유권(operational ownership)에 있습니다. 두 개의 제공업체는 두 세트의 속도 제한(rate limits), 인증 정보, 요청 ID(request IDs), 그리고 비용 기록을 의미합니다. 하나의 Python 함수 뒤에 이 사실을 숨긴다고 해서 문제가 사라지는 것은 아닙니다. 반면에, ASR(자동 음성 인식)을 사용할 수 없을 때 단일 제공업체 설계를 강제하는 것은 기능 커버리지 측면에서 훨씬 더 큰 실패를 초래합니다.

팀이 이미 특정 모델 제품군(model family)을 사용하기로 결정했고, 해당 모델의 네이티브 기능(native features)이 이식성(portability)보다 더 중요하며, 두 번째 요약 제공업체를 추가하는 것이 평가 점수(eval score)를 개선하지 못한 채 절차적 번거로움(ceremony)만 더할 뿐이라면 OpenAI, Claude 또는 Gemini와의 직접적인 통합을 유지하십시오. 반면, 동일한 전사(transcript)를 여러 모델에 걸쳐 다시 실행(replaying)하는 것이 릴리스 검증(release qualification)의 일부이거나, 요약 이후에 태깅(tagging) 및 구조화된 추출(structured extraction)이 이어질 가능성이 높다면 멀티 모델 게이트웨이(multi-model gateway)를 선택하십시오. 모델의 품질은 전사 언어, 길이, STT에서 전파된 노이즈, 그리고 출력 루브릭(output rubric)에 따라 달라지므로 브랜드 비교만으로는 이러한 변수들을 해결할 수 없으며, 결과는 상황에 따라 다를 수 있습니다.

언급할 가치가 있는 또 다른 경계선이 있습니다. 채팅 모델(chat model)과 제한된 스키마(constrained schema)를 결합하면 텍스트 또는 이미지 검토 워크플로우를 지원할 수 있지만, 이 런타임(runtime)에는 전용 모더레이션 엔드포인트(moderation endpoint)가 없습니다. 이미지 업스케일링(Image upscaling)은 Lanczos로 제한됩니다. 이러한 사실들이 회의 요약 서비스에는 무관할 수 있지만

그다음, 작지만 까다로운 전사(transcript) 코퍼스(corpus)를 고정하십시오. 짧은 통화, 긴 회의, 말을 끊는 화자, 모호한 소유자, 명시적인 마감일, 그리고 불확실한 세부 사항을 생략하는 것이 정답인 구절 등이 포함되어야 합니다. 하나의 평가 고정 장치(eval fixture)는 아주 작을 수 있지만 많은 것을 드러낼 수 있습니다. 예를 들어, 전사 내용에 “Maya가 금요일까지 데이터셋을 보낼 것입니다”라고 되어 있고, 나중에 Jon이 프롬프트 변경 권한을 가졌다고 언급하며, 소유자를 지정하지 않은 채 실시간 자막(realtime captions)을 명시적으로 연기한다고 가정해 봅시다. 좋은 결과물은 Maya, 금요일, 그리고 Jon의 개별 작업을 보존해야 합니다. “금요일”을 허구의 날짜로 바꾸거나, 자막 작업을 Jon에게 할당하거나, 자막이 승인되었다고 주장해서는 안 됩니다. 이제 반복되는 문장과 화자의 중단(interruption)을 넣어 전사를 교란(perturb)한 뒤, 결과가 결정을 바꾸는지 확인하십시오. 이는 검토자에게 문장이 “보기 좋은지” 묻는 것보다 훨씬 유용합니다. 이는 그럴듯한 언어를 실패할 수 있는 필드(fields)와 주장(claims)으로 변환하기 때문입니다. 모든 후보 모델을 동일한 전사와 프롬프트 버전에 대해 실행하십시오. 저는 적어도 사실적 범위(factual coverage), 환각된 주장(hallucinated claims), 놓친 결정(missed decisions), 소유자/마감일 정확도, 애플리케이션이 구조를 기대하는 경우의 파싱 성공 여부, 엔드투엔드 지연 시간(end-to-end latency), 입출력 토큰(input/output tokens), 그리고 재시도 횟수(retry count)를 기록할 것입니다. 429 오류(Too Many Requests)가 발생하면 재시도 횟수를 증가시키고 백오프(back off)해야 하며, 조용히 두 번째 논리적 작업(logical job)을 생성해서는 안 됩니다. 느낌(vibes)에 의존하지 마십시오.

요약 토큰 비용을 단독으로 최적화하지 마십시오. 더 짧은 출력이 더 저렴할 수는 있지만 품질은 더 나쁠 수 있습니다. 소유자를 빈번하게 놓치는 모델은 수동 검토 비용을 API 대시보드 외부로 밀어낼 수 있습니다. 먼저 최소 품질 임계값(minimum quality threshold)을 설정하고, 그다음 적격 모델을 비교한 뒤, 그제야 라우팅 정책(routing policy)을 고려하십시오. 이러한 결과 없이는 특정 코퍼스에서 어떤 모델이 승리할지 확신할 수 없으며, 제공업체 매트릭스(provider matrix)나 데모 전사만으로는 그 불확실성을 해결할 수 없습니다.

마지막으로, 경계(boundary) 자체를 테스트하십시오. 저장된 동일한 전사(transcript)를 모든 요약기(summarizer)에 입력하여, STT 제공업체(STT-provider)의 변경이 채팅 요청 규약(chat request contract)을 변경하지 않는지 확인하고, 429 오류(429 error) 발생 시 무한 루프에 빠지는 대신 백오프(back off)가 작동하는지 확인하십시오. 모델 변경이 지루하게 느껴지고, 평가 실패가 릴리스를 차단하며, 전사 분석(transcript analysis)을 다시 작성하지 않고도 오디오 단계(audio stage)를 발전시킬 수 있을 때, 비로소 아키텍처(architecture)가 준비된 것입니다.

References

• https://openrouter.ai/docs
• https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events