Pion을 쓰고 있음. 그런데 OpenAI의 접근이 정말 필요했는지 궁금함
음성 AI 구성에서 이미 빠른 축에 속하는 부분을 줄이려고 복잡도를 엄청 늘린 것처럼 보였음. 빠른 모델과 정확한 음성 활동 감지(VAD) 가 WebRTC 전송 시간을 미세 조정하는 것보다 훨씬 중요해 보임
책 전체를 온라인에 올려줘서 고마움
예전에 WebRTC 데이터 채널로 데이터베이스에서 브라우저 클라이언트로 CLI를 통해 데이터를 보내는 아이디어가 있어서 일부를 읽었는데, 내 용도에는 잘 맞지 않겠다는 걸 이해하게 됨. 결국 중앙화된 제어 평면과 WebSocket을 썼음
그래도 WebRTC 데이터 채널 + 복사 없는 Apache Arrow ArrayBuffer + duckdb WASM 조합으로 뭔가 재미있는 걸 할 수 있을 것 같은데, 아직 뭘 할지는 못 찾았음
약간 다른 얘기지만, 전체 코드베이스를 중첩된 src 폴더가 아니라 루트 디렉터리에 두는 이유가 뭔지 궁금함
README로 가기가 훨씬 어려워짐
낮은 지연 시간은 구현 방식상 장점이라기보다 고통에 가까움
가볍게 대화하려고 하면 사람은 자연스럽게 잠깐 멈추는데, GPT는 그걸 “말이 끝났다”고 받아들이고 바로 떠들기 시작함
나이가 들면서 원하는 단어를 찾는 데 시간이 더 걸리는데, 이런 빠른 음성 GPT는 도움보다 짜증이 더 큼. 말하기 전에 머릿속에서 문장 전체를 다 생각해 놓아야 해서 전혀 자연스럽지 않음
여기에는 서로 다른 두 층위의 지연 시간이 섞여 있음
글에서 말하는 지연은 오디오 스트림 자체의 전송 지연이고, 이 상황에서의 지연은 오디오 스트림 안에서 얼마나 빨리 응답을 시작하느냐에 가까움
나도 겪어봤고 정말 성가심
생각이 아직 끝나지 않았는데도 계속 말해야 한다는 압박이 생겨서 꽤 부자연스럽게 느껴짐. 적절한 단어를 찾는 중이라면 그걸 찾을 기회가 필요함
해결책은 더 높은 지연 시간의 프로토콜이 아니라 멈춤을 더 똑똑하게 처리하는 쪽이라고 봄. 지연이 낮으면 사용자가 끼어들었을 때 봇이 즉시 말을 멈출 수 있음
음성 대화에서는 특정 코드 워드를 쓰기 전까지는 아예 답하지 말거나 “알겠습니다”만 말하라고 시킴
완벽하진 않지만 덜 끼어듦
이건 글에서 말한 지연 시간보다 음성 활동 감지(VAD) 와 더 관련이 큼
어려운 문제임. 봇이 떠들지 못하게 하려고 나도 모르게 필러 표현을 덧붙이게 됨
또 대부분의 지능을 문제를 생각하는 데 쓰기보다 그럴듯하게 들리는 데 쓰는 것 같음. “네, 물론이죠. 왜 그렇게 원하시는지 이해합니다…” 같은 식임. 아마 시간 제한이 있고 음성 처리가 더 비싸서 그런 듯함. 텍스트 응답은 작업 자체에 더 많은 시간을 씀
“주간 활성 사용자 9억 명 이상”은 당연히 ChatGPT 전체 사용자 수를 말하는 것 같고, 그중 음성 기능을 쓰는 비율은 훨씬 작지 않을까 싶음
이런 수치는 문제에 어느 정도의 하드웨어와 소프트웨어 최적화를 투입할지 같은 사업 판단에 영향을 줌
맞음. 그래서 “reach”라는 표현을 쓴 듯함
실제 사용 여부와 무관하게 기능에 노출될 수 있는 전체 사용자 수를 뜻함
공유해 주는 건 정말 반갑지만, OpenAI의 실시간 오디오 모델은 아직 능력 면에서 4o 계열에 머물러 있다는 점을 기억해야 함
그래도 여전히 매우 유용하고, 이 분야에 실질적인 경쟁자가 없다는 게 아쉬움. 실제 대화 같은 경험은 아이디어와 개념을 표현하는 데 큰 도움이 됐음
출시 당시와 달리 지금은 최전선 모델이 아니라는 점은 염두에 둘 만함. Sam이 이걸 본다면 새 실시간 오디오 모델을 내줬으면 좋겠음
OpenAI의 realtime/voice mode에서 음성 부분은 훌륭하지만, 최신 모델에 비하면 꽤 멍청하고 종종 같은 말을 반복함
Google의 Gemini flash live 3.1이 더 낫고, 특히 API로 쓰면 좋음. 도구 호출도 가능하고, 직접 구성하면 더 똑똑한 다른 LLM에도 연결할 수 있으며, 추론 수준도 설정 가능함. 높은 추론 수준도 실시간에 충분히 가깝고, Google 검색 기반으로 답변을 보강할 수 있음. 양방향 음성을 좋아한다면 지금은 아마 최고의 선택지이고, AI Studio에서 시험해 볼 수 있음
Hacker News 의견들
OpenAI가 내가 작업하는 라이브러리 Pion 사용 사례를 공개해 줘서 매우 고마움
WebRTC를 잘 모른다면 꽤 재미있는 분야이고, 작동 방식을 설명하는 책 WebRTC for the Curious도 작업 중임
https://github.com/pion/webrtc
https://webrtcforthecurious.com
음성 AI 구성에서 이미 빠른 축에 속하는 부분을 줄이려고 복잡도를 엄청 늘린 것처럼 보였음. 빠른 모델과 정확한 음성 활동 감지(VAD) 가 WebRTC 전송 시간을 미세 조정하는 것보다 훨씬 중요해 보임
예전에 WebRTC 데이터 채널로 데이터베이스에서 브라우저 클라이언트로 CLI를 통해 데이터를 보내는 아이디어가 있어서 일부를 읽었는데, 내 용도에는 잘 맞지 않겠다는 걸 이해하게 됨. 결국 중앙화된 제어 평면과 WebSocket을 썼음
그래도 WebRTC 데이터 채널 + 복사 없는 Apache Arrow ArrayBuffer + duckdb WASM 조합으로 뭔가 재미있는 걸 할 수 있을 것 같은데, 아직 뭘 할지는 못 찾았음
src폴더가 아니라 루트 디렉터리에 두는 이유가 뭔지 궁금함README로 가기가 훨씬 어려워짐
낮은 지연 시간은 구현 방식상 장점이라기보다 고통에 가까움
가볍게 대화하려고 하면 사람은 자연스럽게 잠깐 멈추는데, GPT는 그걸 “말이 끝났다”고 받아들이고 바로 떠들기 시작함
나이가 들면서 원하는 단어를 찾는 데 시간이 더 걸리는데, 이런 빠른 음성 GPT는 도움보다 짜증이 더 큼. 말하기 전에 머릿속에서 문장 전체를 다 생각해 놓아야 해서 전혀 자연스럽지 않음
글에서 말하는 지연은 오디오 스트림 자체의 전송 지연이고, 이 상황에서의 지연은 오디오 스트림 안에서 얼마나 빨리 응답을 시작하느냐에 가까움
생각이 아직 끝나지 않았는데도 계속 말해야 한다는 압박이 생겨서 꽤 부자연스럽게 느껴짐. 적절한 단어를 찾는 중이라면 그걸 찾을 기회가 필요함
해결책은 더 높은 지연 시간의 프로토콜이 아니라 멈춤을 더 똑똑하게 처리하는 쪽이라고 봄. 지연이 낮으면 사용자가 끼어들었을 때 봇이 즉시 말을 멈출 수 있음
완벽하진 않지만 덜 끼어듦
또 대부분의 지능을 문제를 생각하는 데 쓰기보다 그럴듯하게 들리는 데 쓰는 것 같음. “네, 물론이죠. 왜 그렇게 원하시는지 이해합니다…” 같은 식임. 아마 시간 제한이 있고 음성 처리가 더 비싸서 그런 듯함. 텍스트 응답은 작업 자체에 더 많은 시간을 씀
“주간 활성 사용자 9억 명 이상”은 당연히 ChatGPT 전체 사용자 수를 말하는 것 같고, 그중 음성 기능을 쓰는 비율은 훨씬 작지 않을까 싶음
이런 수치는 문제에 어느 정도의 하드웨어와 소프트웨어 최적화를 투입할지 같은 사업 판단에 영향을 줌
실제 사용 여부와 무관하게 기능에 노출될 수 있는 전체 사용자 수를 뜻함
공유해 주는 건 정말 반갑지만, OpenAI의 실시간 오디오 모델은 아직 능력 면에서 4o 계열에 머물러 있다는 점을 기억해야 함
그래도 여전히 매우 유용하고, 이 분야에 실질적인 경쟁자가 없다는 게 아쉬움. 실제 대화 같은 경험은 아이디어와 개념을 표현하는 데 큰 도움이 됐음
출시 당시와 달리 지금은 최전선 모델이 아니라는 점은 염두에 둘 만함. Sam이 이걸 본다면 새 실시간 오디오 모델을 내줬으면 좋겠음
Google의 Gemini flash live 3.1이 더 낫고, 특히 API로 쓰면 좋음. 도구 호출도 가능하고, 직접 구성하면 더 똑똑한 다른 LLM에도 연결할 수 있으며, 추론 수준도 설정 가능함. 높은 추론 수준도 실시간에 충분히 가깝고, Google 검색 기반으로 답변을 보강할 수 있음. 양방향 음성을 좋아한다면 지금은 아마 최고의 선택지이고, AI Studio에서 시험해 볼 수 있음
이 분야에 들어오려는 사람이라면 pipecat이 좋은 오픈소스 저장소이자 커뮤니티임
https://github.com/pipecat-ai/pipecat
몇 주 전에야 알았고, Gemma 4 출시 이후 Gemma 4 + Kokoro TTS + Whisper로 완전히 로컬에서 도는 음성 비서를 처음부터 만들고 있음: https://github.com/pncnmnp/strawberry
Pipecat의 smart turn 모델은 음성 활동 감지(VAD) 에 정말 좋음: https://huggingface.co/pipecat-ai/smart-turn-v3
더 좋은 모델이 더 많이 생각한 뒤 답한다면 응답을 더 오래 기다려도 괜찮음
다만 끼어들기를 잘 지원하고, 1초 멈췄다고 바로 답하기 시작하지 않으며, 내가 말을 끝냈는지 똑똑하게 판단해야 함
이건 단순히 지연 시간만의 문제가 아닐 수도 있음
사용자를 음성 대화에 머물게 하면 텍스트로는 절대 얻지 못할 학습 데이터를 얻을 수 있음. 그래서 SFU보다 트랜시버 방식을 택하고 다자간 대화를 대부분 무시해도 괜찮았던 걸까 싶음
OpenAI가 이제 WebRTC/오디오에 LiveKit을 쓰지 않는다는 뜻으로 읽어도 되는 건가?
이 아키텍처에는 LiveKit 서버가 딱히 원하는 형태가 아닐 것 같음. 글의 SFU 논의에서도 사실상 그렇게 말하고 있음. 다만 클라이언트 SDK에는 유용한 것들이 많음
스트림 도중 트랜시버가 크래시하면 활성 세션은 어떻게 복구될까?
시스템이 새 WebRTC 세션에서 컨텍스트를 자동으로 다시 수립하나?
모든 WebRTC 상태를 저장하거나 일시 중지했다가 다음 프로세스에서 되살릴 수 있음
친구를 만들고 싶다면 어떤 형태로든 동호회나 모임에 들어가는 편이 더 낫다고 봄