장면 중간에 두 얼굴이 바뀌는 현상 방지: AI 뮤직 비디오에서의 정체성 보존
요약
AI 뮤직 비디오에서 여러 인물의 얼굴이 시간 경과에 따라 바뀌는 '정체성 표류(identity drift)' 문제를 다룹니다. 이 글은 두 명 이상의 인물이 등장하는 영상에서 각 개인의 정체성과 동작을 안정적으로 유지하기 위한 엔지니어링적 해결책들을 제시합니다.
핵심 포인트
- 두 얼굴이 함께할 때, 움직임 할당(motion attribution)은 어려운 제약 조건이다.
- 정체성 임베딩은 사람별로 명시적이며 공간적으로 고정되어야 한다.
- 단순 픽셀 정보 외에 포즈나 레이아웃 사전 정보를 활용하는 것이 중요하다.
아무도 경고해주지 않는 문제점
두 장의 사진을 짧은 뮤직 비디오로 변환하는 모델을 훈련시킵니다. 처음 3초는 정말 멋져 보입니다. 그러다가 5초쯤 되자 왼쪽 남자가 갑자기 다른 사람의 턱선을 갖게 됩니다. 8초가 되자 그들의 얼굴이 완전히 자리를 바꿉니다.
만약 여러분이 어떤 종류의 face-to-video 파이프라인을 구축해 본 적이 있다면, 이 실패 모드를 잘 알고 있을 것입니다. 이것에는 이름이 있습니다: identity drift(정체성 표류). 그리고 두 사람이 함께하는 퍼포먼스 비디오—랩 듀엣, 듀엣 커버, 서로 노래하는 친구들—에 있어서는 가장 구현하기 어려운 문제입니다.
이 글은 왜 identity drift가 발생하는지, 그리고 전체 클립에 걸쳐 두 얼굴을 안정적으로 유지하기 위해 취할 수 있는 엔지니어링 결정들에 대해 다룹니다. 이것은 제품 홍보가 아닙니다. 실패 모드와 해결책(levers)들을 살펴보는 과정입니다.
한 얼굴만으로도 이미 어려운 이유
단일 주제의 face video는 어느 정도 해결된 문제에 가깝습니다. 왜냐하면 파이프라인이 강력한 사전 지식(priors)에 의존할 수 있기 때문입니다. 얼굴을 감지하고, 정체성 임베딩(identity embedding)을 추출하며, 생성되는 모든 프레임을 이 임베딩으로 조건화하여 사람이 동일하게 유지되도록 합니다. insightface 같은 도구는 빠르고 안정적이어서 프레임별로 실행할 수 있는 face detector와 embedding extractor를 제공하고, inswapper 같은 모델이 실제로 얼굴 교체를 수행합니다.
정체성 임베딩은 핵심적인 요소입니다. 이것은
- 어느 얼굴이 누구의 것인가. 두 사람이 프레임에 모두 등장할 때, 파이프라인은 머리가 돌아가거나 카메라가 움직이는 경우에도 매 프레임마다 '왼쪽 사람'과 '오른쪽 사람'을 올바른 임베딩(embeddings)에 연결해야 합니다.
- 누구의 동작이 누구에게 속하는가. 랩 듀엣에서는 두 공연자가 파트를 주고받고, 마이크 쪽으로 몸을 기울이며 프레임에서 겹칩니다. 모델은 각 사람의 제스처를 그들 자신의 정체성에 붙여두어야 하며, 한 사람의 움직임이 다른 사람에게 번지는 현상(bleed movement)을 막아야 합니다.
- 시간에 걸쳐 유지하는 것. 30초는 수백 개의 프레임을 의미합니다. 아주 작은 프레임별 오류가 누적됩니다. 결국에는 두 사람이 하나의 평균화된 얼굴로 수렴하게 되어 — 전형적인 '합쳐진(merged)' 아티팩트가 발생할 수 있습니다.
만약 한 명의 사람에 대한 파이프라인을 구축했다면, 2번 항목이 가장 놀라울 것입니다. 얼굴이 하나일 때는 동작이 기본적으로 자유롭습니다. 어떤 제스처든 자동으로 '그 사람의 것'이 되기 때문입니다. 하지만 두 개의 얼굴일 경우, 동작 할당(motion attribution)은 자유로운 것이 아니라 어려운 제약 조건(hard constraint)이 됩니다.
실제로 중요한 핵심 요소들 (The levers that actually matter)
이를 구축하고 디버깅하는 과정을 통해, 몇 가지 결정들이 가장 큰 차이를 만들었습니다. 이들은 여러분이 구축할 순서가 아니라 영향력의 크기 순으로 대략 나열되어 있습니다.
1. 정체성 조건화(Identity conditioning)는 사람별로 명시적이어야 한다
단일 '이미지'를 생성기(generator)에 전달하고 두 사람이 있다는 것을 스스로 파악하기를 기대해서는 안 됩니다. 대신, 분리되고 명확하게 태그가 지정된 두 개의 정체성 임베딩을 전달하고, 프레임 구성이 허용하는 한 공간적으로 고정(spatially anchored)해야 합니다. 카메라 구도가 바뀔 때는 모델에게 추측하게 맡기지 말고 재고정(re-anchor)해야 합니다.
2. 단순히 픽셀뿐만 아니라 포즈 또는 레이아웃 사전 정보(pose or layout prior)를 사용하라
공연 영상의 경우, 두 사람은 서로에 대해 짜여진 관계가 있습니다 — 한 명은 '말하고' 다른 한 명은 '반응합니다'. 이러한 구조를 포즈나 레이아웃 신호(키포인트 또는 깊이/분할 레이아웃)로 인코딩하면, 모델이 그럴듯하지만 틀린 상호작용을 만들어내는 것을 막을 수 있습니다. 프레임별 얼굴 감지 + 키포인트 패스는 비용 효율적이며, 전체 클래스의 스왑 아티팩트(swap artifacts)를 제거합니다.
3. 시각적 스타일을 제한하라. 왜냐하면 스타일 드리프트가 정체성 드리프트를 유발하기 때문이다.
이것은 직관적이지 않은 문제입니다. 만약 장면의 스타일이 자유롭게 변동하도록 허용된다면 — 조명이 바뀌거나, 카메라 각도가 방황하거나, 배경이 이동한다면 — 얼굴 모델은 더 나쁜 신호를 받게 되고, 정체성 드리프트(identity drift)는 더욱 심해집니다. 스타일을 강하게 고정하는 것(전체 클립에 걸쳐 동일한 색상 팔레트, 동일한 조명, 동일한 프레이밍 유지)은 단순한 미적 선택이 아닙니다. 그것은 정체성을 보존하는 기술입니다. 이것이 바로 고정되고 양식화된 '무대' 같은 모습이 자유로운 영화적 장면보다 일관되게 유지하기가 훨씬 쉬운 이유 중 하나입니다.
4. 비용과 일관성 사이의 교환(trade)을 받아들여라
긴 클립에 걸친 완전한 정체성 일관성은 비용이 많이 듭니다. 모델이 저렴할수록 얼굴은 더 빨리 드리프트하기 시작합니다. 만약 사용자가 프롬프트나 타임라인을 건드릴 필요가 없는, '설정하고 잊어버릴' 경험을 원한다면 — 사진 두 장만 넣으면 클립 하나를 얻는다는 것은 암묵적으로 거래를 하는 것입니다: 사용자가 애쓰지 않도록 정체성 고정(identity anchoring)에 더 많은 컴퓨팅 자원을 투입하는 것이죠. 이러한 교환이 어디에 위치하는지 아는 것이, 3초 동안 인상적인 데모와 전체 비디오를 버텨내는 제품 사이의 차이를 만듭니다.
'충분히 좋다(good enough)'는 것이 무엇을 의미하는가
당신의 파이프라인이 한계를 넘었는지 알게 되는 순간은, 전체 클립을 보면서 얼굴에 대해 단 한 번도 생각하지 않을 수 있을 때입니다. 그것이 진정한 수용 테스트입니다. 그저 존재할 뿐입니다 — 두 명의 뚜렷한 인물들이 첫 프레임부터 마지막까지 분명히 자신답게 존재하며, 심지어 대사를 주고받거나, 화면으로 기대거나, 함께 노래를 부를 때조차도 말이죠.
이 지점에 도달하는 것은 어떤 단일 모델에 관한 것이라기보다는, 그 주변을 둘러싼 구조(scaffolding)에 관한 것입니다: 명시적인 개인별 임베딩(per-person embeddings), 레이아웃 사전(layout prior), 고정된 스타일, 그리고 의도적인 비용/일관성 트레이드오프입니다.
코드와는 아무 관련이 없는 한 가지
이 기능을 사용해 재미있는 것을 만들기에 앞서 간단히 당부드립니다. 만약 실제 인물의 얼굴을 생성된 비디오에 넣는 경우(친구, 파트너, 유명인 등 누구라도 상관없습니다)에는 반드시 그 사람의 동의를 먼저 얻어야 합니다. 페이스 스왑(Face-swap) 및 정체성 보존 기술은 강력하며, 뮤직비디오에서 두 얼굴을 안정적으로 유지하는 것과 동일한 파이프라인이 원치 않는 영상에 누군가를 넣는 데에도 똑같이 쉽게 사용될 수 있습니다. 기술적인 숙련도는 쉬운 부분입니다. 책임은 사용자에게 달려있습니다.
혹시 '두 사람이 한 사람으로 합쳐지는' 버그를 겪어보셨나요? 어떻게 해결하셨는지 — 더 나은 임베딩(embeddings), 포즈 사전(pose prior) 또는 다른 방법이었나요? 여러분의 파이프라인에서 어떤 것이 효과가 있었는지 듣고 싶습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기