LLM Live 향후 릴리즈 구조
구현을 가장 단순하게 가져가려면 현재 PoC Broker를 버리지 않고 SK Live Gateway로 운영화하는 것이 적합하다.
권장 구조
A1 AI Agent <-> SK Live Gateway <-> Gemini Live
- A1 AI Agent는 Gateway 한 곳에만 WebSocket으로 연결한다.
- Gateway는 연결마다 Gemini Live upstream WebSocket을 하나 연다.
- Gemini API key, model, prompt와 클라우드 검색 tool은 Gateway에서만 관리한다.
- 제품 명령은 Gateway를 통과해 Agent로 돌아오며 기기에서만 실행한다.
- 세션 DB는 두지 않고 WebSocket 연결 수명을 Live 세션으로 사용한다.
이 구조에는 별도 /live/bootstrap, ephemeral token 발급과 기기의 Gemini 직접 인증이 없다.
왜 이 구조가 단순한가
현재 구현을 그대로 재사용할 수 있기 때문이다.
| 현재 코드 | 그대로 사용할 부분 | 필요한 변경 |
|---|---|---|
OkHttpGeminiLiveSessionManager |
Broker endpoint 연결, PCM·tool 송수신 | 운영 WSS 주소와 인증 header |
ForegroundService Live Runtime |
상태, Barge-in, 재생, 종료와 제품 명령 | Gateway 장애 처리 기준 정리 |
gemini/live_broker.py, gemini/live_rag.py |
1 device WSS : 1 Gemini WSS, setup 보정, frame 중계와 search_rag |
인증, 제한, 운영 로그와 배포 |
| 기존 REST Lambda | /llm/invoke와 기존 Cloud 기능 |
변경 없이 유지 |
기기가 Google protocol과 token 수명까지 소유하는 직접 연결안보다 온디바이스와 Cloud 양쪽의 신규 구현 범위가 작다.
세 구성요소
| 구성요소 | 책임 | 하지 않는 일 |
|---|---|---|
| A1 AI Agent | AudioRecord/AudioTrack, Barge-in, 세션 UI, tool 검증과 Device API | Gemini secret과 model 정책 관리 |
| SK Live Gateway | 기기 인증, Gemini 연결, model/prompt, protocol 중계, search_rag, quota와 관측 |
Device API 실행과 대화 기록 저장 |
| Gemini Live | 실시간 STT·LLM·TTS, VAD, 문맥과 tool 제안 | 제품 명령의 최종 실행 판단 |
연결 흐름
- A1 AI Agent가
wss://<live-gateway>/llm/live에 연결한다. - Gateway가 기존 기기 인증 수단으로 연결을 확인한다.
- Gateway가 서버 secret으로 Gemini Live upstream WSS를 연다.
- Agent와 Gemini 사이의 PCM·event를 양방향 중계한다.
- Gateway는
search_rag를 직접 처리하고 근거를 Gemini에 반환한다. - 제품 tool call은 Agent의
FunctionCallHandler가 검증한다. - Agent가 Device API를 정확히 한 번 실행하고 결과를 같은 연결로 반환한다.
- 한쪽 WebSocket이 닫히면 검색 task와 반대쪽 연결도 닫고 세션을 정리한다.
세션과 장애
릴리즈 v1은 연결 하나를 세션 하나로 본다.
| 상황 | 단순 처리 |
|---|---|
| 정상 종료 | device WSS와 Gemini WSS를 함께 종료 |
| Gateway 또는 Gemini 단절 | 현재 Live 세션 종료, 다음 SK_19 진입에서 새 연결 |
| Live 진입 실패 | 기존 REST 또는 로컬 경로로 한 번만 fallback |
| 제품 명령 처리 중 단절 | commandId 기준 Device API 재실행 금지 |
| 장시간 연결 | 최대 세션 시간에서 정상 종료 후 새 세션 |
세션 DB, 투명한 session resumption과 연결 이관은 v1에 넣지 않는다. 필요성이 확인되면 이후 단계에서 추가한다.
배포 구조
기존 REST Lambda는 그대로 두고 Live Gateway만 별도의 장시간 실행 서비스로 배포한다.
A1 AI Agent
-> WSS Load Balancer
-> Containerized SK Live Gateway
-> Gemini Live WSS
API Gateway WebSocket은 클라이언트 연결을 유지하지만 backend Lambda와의 연결은 message마다 호출되며 지속되지 않는다. 일반 Lambda 실행 시간도 최대 15분이다. Gemini upstream WSS를 같은 process에서 계속 유지하려면 ALB 뒤 ECS/Fargate 같은 container service가 더 단순하다.
최소 구현 변경
| 온디바이스 팀 | 클라우드 팀 |
|---|---|
| 운영 Gateway endpoint 적용 | live_broker.py container화 |
| 기존 기기 인증 token을 WSS header에 전달 | WSS handshake 인증과 연결 quota |
| Gateway 연결 실패·종료 UI 정리 | TLS, health/readiness, timeout과 backpressure |
| API key property 사용 금지 | secret manager, model/prompt와 kill switch |
| Release APK 회귀 시험 | PCM 원문을 남기지 않는 구조화 로그와 지표 |
| 클라우드 tool 응답은 실행하지 않고 표시·재생 | search_rag timeout, 취소, 출처와 권한 관리 |
단순화의 대가
| 장점 | 비용 |
|---|---|
| 현재 PoC 코드 재사용, 앱 변경 최소 | 모든 PCM이 SK Cloud를 통과 |
| API key와 Gemini protocol을 Cloud 한 곳에서 관리 | Cloud bandwidth와 동시 연결 비용 증가 |
| model·prompt·voice를 서버에서 즉시 통제 | Gateway 장애가 Live 전체 장애가 됨 |
| 기기별 Google token 발급 불필요 | 직접 연결보다 지연이 한 hop 증가 |
초기 릴리즈에서는 구현 안정성이 더 중요하므로 Gateway 구조를 권장한다. 트래픽 비용이나 지연이 목표를 넘을 때만 기기 직접 연결 구조를 v2 대안으로 검토한다.
TODO: 출시 게이트
- WSS 기기 인증과 권한 없는 연결 차단
- frame 크기, 연결 수, 전송률과 세션 시간 제한
- 느린 client에 대한 backpressure와 양쪽 task 정리
- 원본 PCM·전체 전사를 남기지 않는 로그 정책
- Gateway 장애·재기동·Gemini timeout 회귀 시험
- 50회 반복 세션과 동시 연결 부하 시험
- Barge-in 지연과 Gateway 추가 hop의 실기기 측정