단기 — MP4 전환 개선
talking 비디오를 미리 마운트하고 opacity만 바꾸며, 상태 변경마다 랜덤 재선택하지 않는다.
구현은 가볍지만 발화-입모양 일치 문제 자체는 해결되지 않는다.
아바타 입모양 개선 검토
마지막 업데이트 2026-07-22
TL;DR
현재 핑퐁이 아바타는 AI 발화 오디오와 입모양이 맞지 않아, 아동에게 "AI 같다 / 부자연스럽다"는 인상을 준다.
외부 서비스(sync.so, simli)는 각각 실시간 미지원·한국어 미지원으로 실시간 수업에는 부적합하다.
가장 현실적인 1차 개선안은 base MP4 위에 mouth overlay를 얹고, AI 출력 오디오의 RMS 값으로 입 모양을 바꾸는 자체 방식이다.
1. 문서 목적
핑퐁이 AI 세션에서 AI의 발화 오디오와 아바타 영상의 입모양이 일치하지 않는다. 입모양이 실제 발화의 리듬·강세·무음 구간과 무관하게 움직이기 때문에, 사용자(특히 아동)는 "AI 같다", "부자연스럽다"고 느낀다.
이는 또래 대화 연습이라는 핑퐁이의 핵심 가치(실제와 같은 대화 경험)를 직접적으로 훼손한다.
이 문서는 발화에 맞춰 아바타 입모양이 자연스럽게 움직이도록 만들 수 있는 방법을 검토한다. 자체 구현과 외부 서비스 활용을 모두 비교하고, 핑퐁이의 실시간 대화 흐름에 적용 가능한 현실적 개선안을 도출한다.
2. 현재 구조
output_audio_buffer.started→ AI 발화 상태trueoutput_audio_buffer.stopped/cleared→ AI 발화 상태false- 게스트 세션은
isPeerTalking값에 따라idle/talking상태 설정 - 렌더링은 idle MP4 위에 talking MP4를 겹치고 opacity로 표시 상태 전환
3. 한계 — 왜 입모양이 발화와 어긋나는가
output_audio_buffer.* 이벤트는 립싱크 이벤트가 아니다. "AI가 말하는 중"이라는 거시 상태만 전달한다.
그 결과:
- talking MP4는 하나의 loop 영상이라, 실제 발화의 음량·리듬·무음·모음/자음 변화와 무관하게 재생된다.
- 발화가 짧아도 길어도 같은 loop가 돌며, 시작 프레임/랜덤 선택에 따라 어색함이 커진다.
- 사용자는 "입은 움직이는데 말과 안 맞는다"는 부조화를 명확히 인지한다 → AI스러움 증가.
핵심. 입모양은 말한다/안 한다 라는 거시 상태가 아니라, 오디오의 미시 신호(음량·음소)에 따라 움직여야 한다.
샘플 MP4
| 파일 | 해상도 | FPS | 길이 | 크기 |
|---|---|---|---|---|
avatar_tiki09_taerin_idle_0.mp4 |
1920×1072 | 30 | 약 10.07초 | 약 16MB |
avatar_tiki09_taerin_talking_0.mp4 |
1920×1072 | 30 | 약 10.07초 | 약 18MB |
두 영상은 구도와 인물 위치가 거의 고정되어 있어, 입 영역만 따로 추출/합성하는 오프라인 전처리에 적합하다.
4. 개선 방향 분류
| 단계 | 방식 | 동기화 정확도 | 구현 난이도 | 실시간 적합 |
|---|---|---|---|---|
| 단기 | MP4 전환 최적화 | 낮음 | 매우 낮음 | O |
| 중기 (권장) | base MP4 + RMS 기반 mouth overlay | 중간 | 중간 | O |
| 장기 | viseme/phoneme 기반 정밀 립싱크 | 높음 | 높음 | △ |
| 외부 | 외부 립싱크 서비스 | 서비스별 | 낮음~중간 | 서비스별 |
중기 (권장) — 자체 RMS
base MP4 위에 입 레이어를 얹고, AI 출력 오디오의 RMS/volume에 따라 입 모양을 교체한다.
발화 음량 변화에 입이 반응하므로, 사용자가 인지하는 부조화를 가장 큰 폭으로 줄일 수 있다.
장기 — viseme lip-sync
음소·viseme 타임라인을 생성해 입모양을 정확히 동기화한다.
품질은 최고지만 별도 파이프라인과 비용 부담이 크다.
5. 자체 RMS 기반 mouth overlay 설계안
전체 idle/talking MP4를 통째로 스위칭하는 대신, idle은 기본 영상으로 두고 talking에서 입 주변 변화만 추출해 별도 레이어로 사용한다.
idle_base.mp4
ㄴ 전체 아바타 배경/몸/얼굴 기본 움직임
mouth_overlay (.webm 또는 sprite .webp/.png)
ㄴ talking 영상에서 입 주변 변화만 추출한 레이어
runtime
1. idle_base.mp4 재생
2. AI audio RMS 분석 (AudioContext + AnalyserNode)
3. RMS 값에 따라 closed / small / medium / open 프레임 선택
4. 입 위치에 overlay추출 방식 선택지
입 crop sprite — talking 영상에서 입 주변만 crop해 closed/small/medium/open 이미지로 분류.
구현·런타임 성능이 좋다. 다만 아바타별 입 좌표 설정이 필요하다.
difference mask — talking·idle 프레임 차이를 계산해 입 주변 변화만 alpha layer로 추출.
원본 영상 질감 유지에 유리하다. 다만 눈 깜빡임·머리 미세 움직임이 노이즈로 잡힐 수 있다.
landmark 기반 — 얼굴 랜드마크에서 입 좌표를 추적하고 별도 그래픽 입을 렌더링.
제어력이 가장 좋다. 다만 기존 MP4의 입 질감을 그대로 쓰지는 못한다.
권장 구현 순서
- 관리자/전처리 단계에서 아바타별 mouth asset (closed / small / medium / open) 생성
- 런타임에서
idle_base.mp4재생 - AI 오디오 출력을
AudioContext+AnalyserNode로 받아 RMS 계산 - RMS 임계값에 따라 mouth frame 선택
- 입 레이어를 absolute overlay로 기존 아바타 영상 위에 합성
핵심 제약
base 영상에 원래의 입 움직임이 남아 있으면 overlay와 충돌해 이중 입처럼 보일 수 있다. → base는 입이 거의 움직이지 않는 중립 영상이어야 한다.
- 브라우저에서 MP4 입부분을 즉석 추출하는 것은 비추천. 전처리로 mouth asset을 미리 생성한다.
- RMS 기반은 "음량에 반응하는" 수준까지다. 정확한 음소 동기화(예: ㅁ/ㅂ/ㅍ에서 입 닫힘)는 불가능 → 그 수준이 필요하면 viseme 단계로 이동한다.
6. 외부 립싱크 서비스 검토
외부 서비스는 크게 두 가지로 나뉜다.
- 배치 생성형 — 녹음된 오디오를 업로드하면 립싱크된 결과 영상을 반환
- 실시간 스트리밍형 — 입력 음성을 실시간으로 받아 립싱크 영상 스트림 반환
핑퐁이는 OpenAI Realtime 기반 실시간 대화이므로, 배치형은 실시간 수업 화면에 원천적으로 적용 불가다.
검토 진행 현황
| 서비스 | 분류 | 상태 | 결론 |
|---|---|---|---|
| sync.so (Sync Labs) | 배치 생성형 | 검토 완료 | 실시간 부적합 → 탈락 |
| simli.com | 실시간 스트리밍형 | 검토 완료 | 품질·언어 제약으로 부적합 |
| NavTalk | 실시간 스트리밍형 | 검토 완료 | Simli보다 자연스러우나 여전히 부자연 |
| (추가 후보) | — | 예정 | — |
sync.so (2026-05 검토)
- 실시간 미지원. 녹음 오디오 파일을 업로드하면 립싱크 결과 영상을 반환하는 배치 처리 방식이다.
- 핑퐁이처럼 발화가 매번 새로 생성되는 실시간 흐름에는 지연이 누적되어 사용 불가능하다.
- 녹화본·비동기 콘텐츠·관리자 검수 PoC 용도로는 품질 레퍼런스 가치만 있다.
판단. 실시간 수업 화면에는 적용 불가. 후순위.
simli.com (2026-05 검토)
- Voice Provider가 ElevenLabs로 한정되며, 선택 가능한 언어 모델이 사실상 영어(en)뿐이다.
- 핑퐁이는 한국어 아동 발화 대상이라 voice 라인업 자체가 맞지 않는다.
- 자체 TTS / OpenAI Realtime 음성을 그대로 흘려보낼 수 없어 파이프라인 분리가 강제된다.
- 대화 영상이 부자연스럽다. 몸은 정지된 상태에서 얼굴(특히 입 주변)만 별도로 움직여, 신체-표정이 따로 노는 느낌이 강하다.
- 말투가 기계음에 가깝다. ElevenLabs voice를 써도 톤·억양이 부자연스러워 아동 대상 캐릭터 발화로는 쓰기 어렵다.
판단. 실시간 스트리밍은 장점이지만, 한국어 미지원·품질 이슈로 핑퐁이 적용 부적합. 후순위.
NavTalk (2026-05 검토)
https://console.navtalk.ai/realtime-talk
- 실시간 스트리밍형 talking avatar 서비스.
realtime-talk콘솔에서 실시간 대화 데모 확인. - Simli보다 전반적으로 자연스럽다. 단순히 입 주변만 움직이는 것이 아니라,
- 눈 깜빡임(blink)이 들어간다.
- 입 모양 움직임이 발화에 맞춰 동작한다.
- 몸도 약간씩 흔들려(idle body motion) 신체-표정이 따로 노는 느낌이 줄어든다.
- 다만 여전히 부자연스러움은 남아 있다. 사람이 보기에 "AI 생성 영상"임을 인지할 수 있는 어색함이 존재한다.
판단. Simli 대비 자연스러움(눈 깜빡임·몸 움직임 포함)에서 우위. 다만 잔여 부자연스러움으로 핑퐁이 실시간 적용은 추가 검증 필요. 실시간 외부 서비스 후보 중 상대적 우선 검토 대상.
추가 검토 예정 후보
이전 조사 후보군 중 추가 PoC 또는 정보 확인 대상이다.
fal.ai LatentSync — video_url + audio_url 입력. 개발자 친화 API. 사람형 얼굴 최적화 여부 검증 필요. 실시간보다는 비동기.
DomoAI — video/image + audio 또는 TTS. anime/cartoon/CGI 캐릭터 지원 명시. 자동화·API 운영성 별도 확인 필요.
Kling Avatar / Kling Lip Sync — portrait/image/video + audio. 캐릭터 이미지 기반 talking video 생성에 강점. 기존 MP4 편집보다는 신규 생성에 적합.
AKOOL — talking photo image + audio. 정면 얼굴 캐릭터 기반. 결과 URL 보존 등 운영 제약 확인 필요.
Runway — image/video + audio/text. 일반 Lip Sync는 human face 제약 강함. 우선순위 낮음.
7. 종합 판단
실시간 수업 화면 (/main/meet, /guest)
- 외부 배치형 서비스는 부적합 — sync.so 검토로 재확인
- 외부 실시간 서비스(simli)도 현 시점 부적합 — 한국어 미지원, 품질, 자연스러움 모두 핑퐁이 요구 수준 미달
- NavTalk은 Simli보다 자연스럽지만(눈 깜빡임·입 모양·몸 움직임) 잔여 부자연스러움이 남아 추가 검증 필요 — 실시간 후보 중 상대적 우선 검토 대상
결론. 자체 base MP4 + mouth overlay + AudioContext RMS 분석 방식이 발화-입모양 불일치 문제를 해결하는 가장 현실적인 1차 개선안이다.
비실시간 사용처 (녹화본·리플레이·비동기 학습 콘텐츠)
- fal.ai LatentSync, sync.so 같은 배치 API로 PoC 가능
- DomoAI / Kling / AKOOL은 캐릭터 이미지 기반 신규 영상 생성 실험용
데이터·프라이버시
아동 음성, 식별 가능한 인물 이미지, 내부 캐릭터 자산을 외부 API에 전송할 경우 개인정보·동의·보관기간·학습 사용 여부를 사전 검토해야 한다.
8. 다음 단계
A. 자체 RMS PoC (실시간 트랙) — 최우선
avatar_tiki09_taerin_talking_0.mp4기준 입 crop 좌표 산출- closed / small / medium / open 4단계 mouth sprite 추출
AudioContext+AnalyserNode로 OpenAI Realtime 출력 RMS 측정 → 임계값 매핑- 기존 idle MP4 위 absolute overlay로 합성 테스트
검증 지표
- 발화 시작/중단/무음 구간에서 입 모양이 실제 음량 변화를 따라가는가
- 사용자 체감 부조화가 감소했는가
B. 추가 외부 서비스 후보 PoC (비실시간 트랙)
- fal.ai LatentSync API 연동 난이도·비용 확인
- DomoAI / Kling Avatar / AKOOL 캐릭터 적합성 비교
C. 장기 — viseme 기반 립싱크
- OpenAI Realtime 텍스트 토큰 → viseme 매핑 파이프라인 가능성 별도 조사
- RMS 방식 적용 후에도 음소 단위 부조화가 남는 경우 진행