AI VIDEO BRIEFING

제미나이 라이브 번역 API와 LiveKit으로 실시간 다국어 통역 방송 앱 만드는 법

구글 개발자 채널이 제미나이 라이브 번역 모델과 LiveKit, 클라우드 런으로 청중이 각자 언어로 듣는 통역 방송 앱을 만드는 과정을 공개 예제로 시연했습니다. 언어당 세션 하나만 여는 설계와 확장 한계도 함께 짚습니다.

제미나이 라이브 API와 LiveKit으로 실시간 다국어 통역 방송 앱 만들기 영상 대표 이미지

핵심 메시지

  • 제미나이 API로 제공되는 실시간 번역 모델을 쓰면 발표자의 말을 여러 언어로 동시에 중계하는 앱을 만들 수 있다.
  • 핵심 설계는 요청된 언어당 번역 세션을 하나만 열고, 같은 언어를 원하는 청취자는 기존 방송에 붙이는 것이다.
  • 마지막 청취자가 떠나면 해당 언어의 웹소켓 세션을 닫아 불필요한 연결과 비용을 정리한다.
  • 오디오는 WebRTC로, 자막 텍스트는 데이터 채널로 전달하며 중간 자막과 확정 자막을 구분해 보낸다.
  • 데모는 번역 상태를 메모리에 두기 때문에 인스턴스 하나로 제한되고, 동시 언어 15~20개 수준이 현실적인 한계다.

쉽게 이해하기

구글 개발자 채널이 제미나이 API에 새로 추가된 실시간 번역 모델을 이용해 다국어 중계 앱을 만드는 과정을 공개했다. 발표자는 자신이 독일어로 말한 문장이 그대로 번역돼 나오는 장면으로 시작해, 같은 기능을 자기 애플리케이션 안에 넣는 방법을 보여준다. 구성은 제미나이 라이브 번역 모델과 실시간 통신 오픈소스인 LiveKit, 그리고 구글 클라우드 런 배포의 조합이고 예제 코드는 깃허브에 공개돼 있다.

동작 방식은 단순하다. 방송 페이지에서 이벤트 아이디를 만들면 그것이 곧 LiveKit의 방이 되고, 발표자는 마이크나 브라우저 탭의 소리를 그 방으로 흘려보낸다. 방 안에는 번역 브리지가 있어서 청취자가 특정 언어를 고를 때마다 그 언어의 번역 세션을 새로 연다. 시연에서는 한 사람이 중국어를, 두 사람이 프랑스어를 선택하는 상황을 보여주는데, 두 번째 프랑스어 청취자는 새 세션을 만들지 않고 이미 열려 있는 방송에 곧바로 붙는다.

정리 로직도 함께 다룬다. 청취자가 탭을 닫으면 서버가 웹소켓 종료 이벤트를 받고, 그 언어를 듣는 사람이 아무도 남지 않았을 때만 해당 세션을 닫는다. 결과적으로 요청된 언어 하나당 최대 한 개의 세션만 유지된다. 발표자는 실제 행사에서 이 구조를 써봤다며, 청중이 QR 코드를 찍고 이어폰을 꽂아 각자 원하는 언어로 듣는 경험이 반응이 좋았다고 전했다.

코드 쪽에서는 번역 세션 관리자가 요청된 언어의 브리지가 이미 있는지 확인하고 없으면 제미나이 라이브 API로 웹소켓을 연다. 방송 페이지에서 들어온 원시 오디오를 그대로 흘려보내고, 모델이 만든 번역 오디오와 함께 출력 텍스트도 받아 참가자들에게 내보낸다. 자막은 아직 확정되지 않은 중간 결과와 문단으로 굳어진 확정 결과를 구분해, 대상 언어와 구간 식별자를 붙여 해당 언어를 듣는 참가자에게만 전달한다.

배포는 도커 파일로 의존성 설치와 빌드를 정의한 뒤 클라우드 런에 올리는 방식이고, API 키와 LiveKit 자격 증명은 시크릿 매니저로 관리한다. 최소 인스턴스를 0으로 두어 트래픽이 없을 때는 완전히 내려가도록 했다. 로컬 개발에서는 LiveKit을 도커로 직접 띄울 수도 있지만, 처음 시작한다면 무료로 쓸 수 있는 관리형 서비스에 API 키와 웹소켓 주소를 받아 붙이는 쪽이 간편하다고 권한다.

주요 인사이트

  • 이 데모의 핵심 절약 지점은 모델 호출을 청취자 수가 아니라 언어 수에 비례시킨 것이다. 같은 언어를 듣는 사람이 100명이어도 번역 세션은 하나면 되고, 나머지는 이미 만들어진 오디오 스트림을 구독하기만 하면 된다.
  • 장수명 웹소켓을 클라우드 런 위에서 그대로 유지할 수 있다는 점이 구조를 단순하게 만든다. 별도의 상시 서버를 두지 않고도 실시간 세션을 다룰 수 있고, 트래픽이 없으면 인스턴스가 완전히 내려가 비용이 발생하지 않는다.
  • 다만 이 단순함은 상태를 메모리에 두는 데서 나온다. 한 이벤트의 번역 브리지 정보가 프로세스 안에 있기 때문에 인스턴스를 하나로 묶어야 하고, 더 키우려면 상태 관리를 데이터베이스로 빼내야 한다고 발표자도 분명히 밝힌다.
  • 실질적인 한계선은 동시에 열리는 언어 수다. 언어마다 장수명 웹소켓이 하나씩 붙기 때문에 15~20개를 넘어서면 CPU 한계에 부딪히고, 그 이상으로 늘리려면 언어별로 방을 쪼개는 설계가 필요하다.
  • 같은 기능이 이미 번역 앱 형태로도 제공되지만, 이 예제의 의미는 그 기능을 자기 서비스의 흐름 안으로 가져오는 통합 경로를 코드 수준에서 보여준다는 데 있다.

자주 묻는 질문

청취자가 늘어나면 번역 세션도 그만큼 늘어나나요?

아닙니다. 세션은 요청된 언어당 하나만 열립니다. 같은 언어를 원하는 청취자가 새로 들어오면 이미 열려 있는 번역 방송을 구독하고, 그 언어를 듣는 사람이 모두 나가면 해당 웹소켓 세션이 닫힙니다.

자막은 어떻게 전달되나요?

오디오는 WebRTC로 전송되고 자막 텍스트는 데이터 채널로 전달됩니다. 아직 확정되지 않은 중간 자막은 바로 보여주고, 확정되면 완성된 문단 형태로 굳어지도록 구간 식별자와 대상 언어를 함께 실어 보냅니다.

이 데모를 대규모 행사에 그대로 쓸 수 있나요?

그대로는 어렵습니다. 번역 브리지 상태를 메모리에 두는 구조라 인스턴스가 하나로 제한되고, 동시 언어가 15~20개를 넘으면 CPU 한계에 부딪힙니다. 더 키우려면 상태를 데이터베이스로 옮기거나 언어별로 방을 분리해야 합니다.

원문과 출처

이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.

YouTube 원본 영상 보기 ↗

관련 AI 소식