실시간 음성 AI 설계 시 반드시 마주하게 되는 두 가지 선택지가 있다. 모든 트래픽이 자체 서버를 통하는 WebSocket 중계인가, 브라우저가 OpenAI로 직접 연결하는 WebRTC 직접 연결인가. 비교표를 작성하는 것은 간단하지만, 정답 확인은 실측으로만 가능하다. 그래서 양쪽 모두 구현하여 UI에서 전환할 수 있도록 만들고, 동일한 질문을 던져보았다.

2가지 방식의 구조

WebRTC 직접 연결이라 해도 서버가 할 일이 없는 것은 아니다. 임시 키 발행, 검색 실행 대행, 이력 수신(브라우저로부터의 자기 신고) 등의 역할이 남는다. '음성의 통로'를 포기하더라도 '두뇌의 위치'는 선택할 수 있다.

실측: 고유명사라는 지옥

주제는 블루스(Brewers)의 강력한 루키 '제이콥 미시오로우스키(Jacob Misiorowski)'. 자음의 연속이 음성 인식에 까다롭다. 동일한 마이크, 동일한 방에서 두 회선에 같은 질문을 던진 결과:

WebRTC: "제이콥 미시오로우스키와 누가 더 강해, 오타니 쇼헤이는" → 거의 완벽하게 인식 -
WebSocket: "헤이구니 우마키토 오타니 마사키와 다세이 성적을 조사해줘" → 워드 샐러드(Word Salad). AI는 요청하지도 않은 배우의 출연 작품을 조사하기 시작했다

정확도는 WebRTC의 압승이다. 이유는 구조적이다. WebSocket 입력은 24kHz PCM 고정인 반면, WebRTC는 Opus 48kHz 상태 그대로 전달된다. 두 배의 대역폭과 Google이 10년간 연마한 음성 파이프라인(AEC·노이즈 억제 일체형)의 차이다.

나타난 버그 2마리

첫 번째: WebSocket 측만 저하되는 '신선도' 문제. WebRTC는 연결할 때마다 마이크를 다시 잡는 반면, WebSocket은 녹음 체인(Recording Chain)을 페이지를 닫을 때까지 재사용하고 있었다. 회선을 A/B로 전환하면 WebSocket 측만 몇 세션 전의 디바이스 상태 그대로 계속 말을 한다. "연결할 때마다 녹음 체인을 다시 만든다"는 수정으로 해결했다.

두 번째: 데그로움(Degrom) 융합 사건. 정확도가 높아진 후, "미시오로우스키와 오타니 중 누가 더 뛰어난가?"라고 물었더니, AI가 "제이콥 데그로움(본명 제이콥 미시오로우스키)"이라고 대답했다. 실존하는 두 투수를 융합하여, 가공의 본명 관계까지 발명해낸 것이다.

원인은 질문이 '의견'의 형태를 띠고 있었기 때문에 "사실을 물으면 검색한다"라는 규칙을 빠져나갔기 때문이다. 모델은 모르는 이름을 가장 유사한 기지의 투수로 명칭을 통합(Entity Resolution)했다. 이는 엔티티 융합(Entity Fusion)이라 불리는 유형인데, 까다로운 점은 모델이 "모르는 것을 모른다"는 점이다. "확신이 없는 고유명사는 의견이나 비교를 요구받더라도 대답하기 전에 검색한다"를 규칙에 추가하자, 데그로움은 다시는 나타나지 않았다.

결론

정확도의 WebRTC, 감사의 WebSocket. 개인 이용이라면 WebRTC를 기본으로 하고, 모든 대화의 기록·개입·감사가 필요한 용도에서는 중계를 선택한다. 양쪽을 모두 갖춰두면, 용도가 선택해 줄 것이다.

상세 버전(가짜 마이크를 이용한 E2E 검증 수법 등)과 개발기의 전체 내용은 원문 블로그에서 확인하세요:

Discussion