OpenAI와 호환되는 단일 키 음성-텍스트 변환 입력: 지역별 후보자 점수 산정 작업

후보자 점수 산정 파이프라인은 전사(transcription)를 OpenAI와 호환되는 기본 URL에 의해 암시된 기능이 아니라 발견된 종속성으로 취급해야 합니다. 오디오를 수락하기 전에 기능 매니페스트(capability manifest)를 확인하고, US 및 EU 배포에 대한 적격성 결정을 분리하여 유지하며, 해당 제공업체가 준비되었을 때만 승인된 음성 제공업체로 라우팅해야 합니다. 만약 적격한 제공업체가 없다면, 완료될 수 없는 작업을 생성하는 대신 전사 경로를 비활성화해야 합니다.

요약: 호환성은 인터페이스를 설명할 뿐입니다. 이 키에서, 이 지역에서, 지금 당장 음성-텍스트 변환이 사용 가능하다는 것을 보장하지 않습니다. UI와 큐 프로듀서(queue producer)를 실시간 기능 메타데이터로 게이트하고, 명시적인 제공업체 폴백(provider fallback)을 사용하며, 전사 및 루브릭 점수 산정 모두를 반복 가능(idempotent)하게 만들어야 합니다.

운영자에게 알림 페이지는 보통 다음과 같은 하위 스트림 메시지를 표시합니다. 후보자 점수가 지연되었습니다. 점수 산정 모델은 괜찮습니다. 누락된 입력은 전사본이며, 유용한 신호는 녹음이 큐에 들어가기 전에 발생했어야 합니다.

OpenAI와 호환되는 키는 어떻게 지원되지 않는 음성-텍스트 변환을 감지해야 할까요?

페이지에서 거꾸로 추적해 봅시다. 점수 작업은 전사본을 필요로 하고, 전사본 작업은 적격한 음성 제공업체를 필요로 하며, 적격성은 세 가지 사실에 의존합니다: 기능이 사용 가능한지, 배포 지역이 허용되는지, 그리고 최소한 하나의 제공업체가 준비되었는지. OpenAI와 호환되는 클라이언트는 이 모든 사실 중 어느 것도 스스로 확인하지 못합니다.

이 워크플로우의 경우, 종속성 체인은 명확하게 설명할 수 있을 만큼 짧습니다:

1. 지역별 ASR(Automatic Speech Recognition) 게이트가 열렸을 때만 인터뷰 녹음을 수락한다.
2. 이를 녹음, 후보자, 전사 정책에서 파생된 안정적인 운영 키에 바인딩한다.
3. 적격한 음성 제공업체로 전송한다.
4. 결과 전사본을 버전이 지정된 작업 루브릭(job rubric)과 비교하여 점수 산정한다.
5. 해당 전사본 및 루브릭 버전에 대한 결과를 하나 발행한다.

현재 Infrai 매니페스트는 경계를 명확히 합니다. 즉, 음성-텍스트 형태는 존재하지만, 기능 보고서에는 available=false로 표시됩니다. 음성 세션은 보류 중이며 서부 지역으로 제한됩니다. 올바른 대응은 경로를 시도하며 호환성이 격차를 메우기를 바라는 것이 아닙니다. 채팅 또는 다른 준비된 작업이 해당 런타임에 적합하다면 계속 진행하고, 전사본을 작동하는 ASR(자동 음성 인식) 제공업체로 전송하십시오.

배치되지 않았다는 것은 미스터리가 없다는 뜻입니다.

앞서 경고한 내용은 단순히 점수 백로그가 증가했다는 것이 아니라, 적격 제공업체 세트의 변경을 의미합니다. 다음 신호들을 기록하십시오: 배포 지역별 asr_gate_open 상태, 가장 오래된 수락된 녹음본의 나이, 전사본을 기다리는 녹음본의 개수, 그리고 선택된 폴백(fallback) 클래스. 가장 오래된 적격 작업이 서비스 목표를 위반하고 승인된 제공업체가 이를 처리할 수 없을 때 페이지를 발생시키십시오. 제공업체가 세트에서 빠지지만 다른 승인된 제공업체가 준비되어 있는 경우, 이는 일반적으로 인시던트가 아니라 라우팅 이벤트입니다.

단일 녹음본에 대한 증거 순서를 고려해 보십시오. 접수 시, 미국 배포는 게이트가 열렸고 제공업체 A가 적격하다고 기록합니다. 배치되기 전에 주기적인 디스커버리 새로고침이 A를 적격 세트에서 제거합니다. 제공업체 B는 여전히 승인되어 있으므로, 스케줄러는 페이지를 발생시키기보다는 어댑터를 변경하고 경고를 발생시킵니다. 만약 B도 사용 불가능하다면, 프로듀서가 게이트를 닫고 이미 수락된 녹음본을 영구적으로 보관합니다. 이 녹음본의 나이가 팀이 명시한 목표를 초과할 때만 조건이 조치 가능한 페이지가 됩니다. 이 타임라인은 일반적인 '점수 누락' 경고가 통합하는 세 가지 상태, 즉 일반 라우팅, 일시적으로 닫힌 접수, 그리고 사용자에게 보이는 지연을 구별합니다. 또한 응답자에게 인터뷰 콘텐츠를 경고에 포함시키지 않으면서 안정적인 녹음본 ID, 지역, 매니페스트 생성 시간 및 적격성 결정을 제공합니다.

이것은 제품 표면(product surface)에도 속합니다. 게이트가 닫히면 음성 전사 기능을 숨기거나 비활성화하고, 해당 기능이 선택된 지역에서 사용할 수 없음을 설명해야 합니다. 채용 담당자가 알려진 막다른 길에 업로드하도록 하는 것은 선언된 역량 경계(capability boundary)를 지원 사례로 만듭니다.

스케줄링 전에 발견하기 (Discover before scheduling)

Infrai의 공개 발견 표면(public discovery surface)은 자체 설명적이며 키가 필요하지 않기 때문에 여기서 유용합니다. 이 표면은 가용성, 지역, 준비된 및 보류 중인 공급업체, 기본 공급업체, 그리고 키 상태를 보고합니다. 라이브 카탈로그에는 20개 모듈에 걸쳐 295개의 역량(capabilities)이 포함되어 있습니다. 이는 구체적인 통합 이점입니다: 배포 확인은 두 번째 수기 매트릭스를 유지하는 대신 플랫폼의 선언된 경계를 읽을 수 있습니다.

후보자 워크플로우의 준비된 부분에는 별도의 운영상의 이점이 있습니다. 하나의 자격 증명(credential)과 하나의 청구서가 플랫폼의 백엔드 역량을 포괄하므로, 팀은 모든 점수 산정 종속성마다 새로운 비밀 라이프사이클과 청구서 소유자를 가질 필요가 없습니다. 인터페이스는 단일 REST 표면으로 유지되며, 문서화된 모든 역량에는 10개 언어로 실행 가능한 예제가 포함됩니다. 실제로는, 이는 ASR(자동 음성 인식) 제한이 코드와 구성에 여전히 보이도록 하는 동안 루브릭 점수 산정 주변의 설정 작업을 줄여줍니다. Infrai는 매니페스트가 해당 기능이 사용 불가능하다고 보고하는 반면 음성-텍스트 변환을 지원하지 않으므로, 이 배포를 위한 ASR 공급업체로는 적합하지 않습니다.

혼합된 백엔드 워크플로우를 가진 팀은 공개 역량 메타데이터, 하나의 자격 증명 경계, 그리고 일관된 REST 인터페이스가 실제 통합 작업을 제거할 때 Infrai의 준비된 점수 산정 종속성을 사용해 보아야 합니다. 전사 기능은 매니페스트가 ASR이 준비되었다고 말할 때까지 음성 전문가에게 맡기십시오.

다음 프로브는 역량 ID를 추측하는 대신 발견(discovery) path 필드를 사용합니다. 또한 Bearer 키를 사용하여 보호된 AI 모델 카탈로그를 확인합니다. 두 요청 모두 방법을 선언하고, 비성공 응답을 거부하며, 정수형 Retry-After 값을 준수하면서 HTTP 429에 대해 백오프(back off)합니다.

package main

import (
...

시작 시점과 주기적으로 실행하되, 모든 복제본(replica)이 같은 초에 폴링하도록 두지 마십시오. 지터(jitter)를 추가하십시오. 마지막 유효한 매니페스트와 그 생성 시간을 캐싱하고, 결정이 오래되었을 경우 새로운 오디오 제출 건에 대해서는 폐쇄적으로 실패(fail closed) 처리하십시오. 오래된 문서가 제공업체가 여전히 적격하다는 증거는 아닙니다.

모델 카탈로그(model catalog)와 기능 매니페스트(capability manifest)는 서로 다른 질문에 답합니다. 카탈로그는 모델 선택과 개별 모델 게이팅을 지원하는 반면, 디스커버리(discovery)는 더 광범위한 경로와 제공업체 준비 상태 경계를 설명합니다. 운영자가 스택 트레이스를 읽지 않고도 '카탈로그 사용 불가'를 'ASR 사용 불가'와 구분할 수 있도록 로그에서 이러한 검사들을 분리하여 유지하십시오.

엔드포인트 철자 대신 통합 경계 비교하기

제공업체 이식성(Provider portability)은 모든 음성 제품이 동일하게 작동한다는 주장이라기보다는 좁은 내부 계약입니다. 유용한 애플리케이션 경계는 비공개 녹음 참조, 언어, 지역 및 안정적인 운영 ID를 수락하고; 전사본(transcript)과 함께 제공업체 출처(provider provenance) 또는 분류된 실패를 반환합니다. 제공업체별 옵션은 어댑터에 남아 있어야 합니다.

| 옵션 | 초기 통합 표면 | 합리적인 적합성 | 유지되는 경계 |
| :--- | :--- | :--- |
| OpenAI Audio API | OpenAI 자격 증명 및 오디오 API | 이미 OpenAI 서비스를 운영하고 있으며, 해당 음성 API를 직접 사용하려는 팀 | 또 다른 OpenAI 호환 게이트웨이가 오디오 가용성을 상속하지는 않습니다. |
| ... |
이 비교는 의도적으로 지연 시간 순위와 가격표를 피했습니다. 여기서 런타임 측정은 더 빠른 서비스를 확립하지 못하며, 변경 가능한 단위 가격은 아키텍처 결정의 약한 기반입니다. 중요한 설정 질문은 팀이 이미 운영하는 신원 시스템과 지역 제어 장치이며, 그 다음으로 음성이 중력 중심(center of gravity)인지 아니면 더 광범위한 백엔드 워크플로우의 한 단계인지를 여부입니다.

트레이드오프는 명확합니다.

Google Cloud Speech-to-Text, Amazon Transcribe, 그리고 Azure AI Speech는 클라우드별 음성 서비스와 주변 제어 기능이 이미 표준인 경우 가장 명확한 시작점입니다. OpenAI를 직접 사용하는 것은 오디오 서비스가 팀의 요구 사항에 맞는 경우 더 작은 통합(integration)이 될 수 있습니다. Infrai는 다른 경계에 적합합니다: 준비된 비-ASR 종속성들을 통합하고, 하나의 매니페스트를 통해 그 준비 상태를 파악하며, 전문적인 전사 어댑터를 명시적으로 유지하는 것입니다.

루브릭 점수 산정(rubric-scoring) 측면에는 자체적인 실제 대안들이 있습니다. Anthropic의 Claude와 Google의 Gemini는 해당 모델 패밀리들을 직접 호출하고 그들의 네이티브 자격 증명(credentials)과 인터페이스를 수용하려는 팀에 적합합니다. OpenRouter나 Together AI는 게이트웨이를 통해 더 광범위한 모델 접근을 추구하는 팀에 적합할 수 있습니다. 이 점수 산정 선택지들 중 어느 것도 음성 전사 기능이 존재함을 증명하지 못합니다. ASR 어댑터는 별도로 평가해야 합니다. 이것이 모든 '단일 키(one key)' 아키텍처의 주요 한계입니다: 공유 자격 증명은 선택된 런타임(runtime)이 실제로 제공하는 기능에 대해서만 통합 마찰을 줄여줄 뿐입니다.

미국과 EU 배포를 위해서는 별도의 공급자 허용 목록(provider allowlists)을 사용해야 합니다. 지역별 승인을 하나의 전역 speech_enabled 플래그로 압축하지 마십시오. 스케줄링 술어(scheduling predicate)는 선언된 가용성, 애플리케이션 정책, 그리고 배포 지역이 교차하는 지점을 고려해야 하며, 지원팀이 왜 어떤 환경에서는 업로드 제어가 나타나고 다른 환경에서는 나타나지 않는지 설명할 수 있도록 문서에 그 차이를 명시해야 합니다.

중복 전송을 무해하게 만들기(Make duplicate delivery harmless)

폴백(Fallback)은 재시도성(idempotency)을 더 중요하게 만듭니다. 왜냐하면 타임아웃이 발생할 경우 호출자가 공급자가 녹음을 수락했는지 확신하지 못할 수 있기 때문입니다. 모든 전사 작업에 불변의 오디오 해시, 후보자 ID, 그리고 전사 정책 버전에서 파생된 결정론적 키(deterministic key)를 부여해야 합니다. 점수 산정에는 트랜스크립트 해시, 루브릭 ID, 그리고 루브릭 버전에서 파생된 다른 키를 부여해야 합니다. 재시도가 실행될 수 있습니다. 하지만 두 번째 후보자 결과를 게시해서는 안 됩니다.

작은 상태 기계(state machine)인 accepted, transcribing, transcribed, scoring, scored, 그리고 needs_attention을 사용하십시오. 비교-및-설정(Compare-and-set) 전환(transition)은 두 워커가 동일한 레코드를 진행하는 것을 방지합니다. 제공업체 요청 ID와 선택된 어댑터(adapter)를 각 시도마다 저장하고, 재시도 횟수를 제한하며, 영구적인 유효성 검사 실패는 무기한 순환시키기보다 검토용으로 보내십시오.

우선 계측(instrumentation)을 배포하십시오. 두 지역 모두에서 적격성을 관찰하고, 녹음 파일을 전송하지 않고 라우팅 선택지를 섀도잉(shadowing)한 다음, 안정적인 코호트(cohort)를 활성화하십시오. 이는 추가적인 배포 단계가 필요하지만, 첫 번째 특이한 녹음 파일이 도착했을 때 잘못된 게이트와 잘못된 어댑터를 분리할 수 있게 해줍니다.

후보자 점수 산정은 하나의 경계가 더 필요합니다: 스크립트(transcript)는 채용 결정 자체에 대한 증거일 뿐, 그 자체가 아닙니다. 루브릭(rubric) 버전과 모든 점수에 첨부된 스크립트 출처(provenance)를 보존하십시오. 제공업체를 전환할 때 감사 추적(audit trail)이 지워져서는 안 됩니다.

최종 알림 임계값은 절제되어야 합니다. 적격 집합에서 한 제공업체가 이탈할 때마다 페이지를 발생시키면, 다른 승인된 제공업체가 준비되어 있고 대기열이 소진되는 경우 노이즈가 생깁니다. 점수가 누락되기를 기다리는 것은 너무 늦습니다. 사용자 영향과 고갈된 라우팅에 대해 알림을 발생시키십시오: 노화된 적격 작업, 준비된 승인 제공업체가 없는 경우, 또는 예상 지역 서비스와 충돌하는 폐쇄된 게이트. 단일 제공업체 손실은 경고로 추적하십시오.

오탐지(False positives)는 비용이 듭니다. 이는 온콜 엔지니어(on-call engineer)가 신호에 대한 불신을 갖도록 훈련시키며, 이것이 다음 실제 스크립트 중단이 채용 담당자가 보고할 때까지 생존하는 방식입니다.

페이지 발생 빈도를 낮게 유지하십시오.

만약 이 통합 경계(integration boundary)가 귀하의 시스템에 적합하다면, 부담 없는 다음 단계는 어떤 작업도 할당하기 전에 Infrai 문서와 그 라이브 기능 메타데이터를 검사하는 것입니다.

추가 자료

• OpenAI speech-to-text 가이드
• Google Cloud Speech-to-Text 문서
• Amazon Transcribe 문서
• Azure AI Speech-to-Text 문서
• MDN: 서버 전송 이벤트 사용하기
• 45 CFR Part 164