[번역][UE5] MotionMatching에서 MotionBrick으로

역자의 말: 오랜 시간 렌더링과 최적화만 봐왔던 탓에 모션매칭이나 테크애니쪽으로는 아는게 별로 없는것 같습니다. 콘솔게임 개발도 많이 활성화 되가고 있고 최근에 붉은사막 플레이 영상들만 봐도 확실히 콘솔이나 AAA 급에서 눈에 띄는 것은 모션처리와 행동트리 + 상태기계 등이 중요한 것 같습니다. 그래서 이쪽으로도 좀 저도 공부 할 겸 해서 번역글 공유 해 봅니다.

저자: Asuka.W ( 테크니컬 애니메이터 )

MotionBricks에 대해 이야기할 때, 우리는 무엇을 이야기하는가

얼마 전 NVIDIA의 새로운 애니메이션 기술인 MotionBricks를 보고, 첫 반응은 '경이로움'이었습니다. 이는 현재 게임 애니메이션 시스템, 특히 로코모션(locomotion) 시스템의 장기적인 딜레마에 대해 다시 생각하게 만들었습니다.

글을 시작하기 전에, 언리얼 엔진 5(UE5)에서 테스트해 본 mujoco 버전의 MotionBrick 영상을 먼저 첨부합니다.

「UE5」MotionBrick의 UE5 초기 시도, 어떤 애니메이션 블루프린트도 필요 없음_bilibili

---

1. 상태 머신(State Machine)의 딜레마

우리 모두 알고 있듯이, 유한 상태 머신(FSM)으로 애니메이션 시스템을 구축할 때 초기에는 매우 효율적입니다. 빠른 검증, 상태 분리, 애니메이션 연결 등은 FSM의 강점입니다.

하지만 프로젝트가 진행됨에 따라, 상태 머신은 점차 유지보수 비용이 극도로 높은 시스템으로 변해갑니다. 새로운 상태, 트랜지션, 예외 상황, 인터럽트, 오버레이, 우선순위 등이 추가되면서 그래프는 갈수록 복잡해집니다. 이 문제의 본질은 "상태 머신이 좋지 않다"는 것이 아니라, 우리가 유한한 열거(enum) 방식으로 거의 무한하게 연속적인 운동 공간을 커버하려 한다는 데 있습니다.

그래서 후반부로 갈수록 상태 머신은 복잡해지고, 유지보수가 어려워지며, 결과물이 항상 안정적이지도 않게 됩니다. 검증 단계에는 아주 적합하지만, 시스템이 대량의 정식 콘텐츠를 감당하기 시작하면 누구나 건드리기 싫어하는 복잡한 거미줄이 되기 쉽습니다.

여기서 하나의 의문이 생깁니다. 이상적인 캐릭터 애니메이션 시스템이 과연 이렇게까지 복잡해야 할까요? 아니면, 수동 예외 처리에 의존하는 것을 최소화하고 안정적이며 일관성 있고 재사용 가능한 시스템이 되어야 할까요?

---

2. Motion Matching의 한계

모션 매칭(Motion Matching)은 상태 머신의 딜레마에 대한 중요한 개선책입니다.

GASP를 예로 들면, 그 애니메이션 블루프린트에는 전통적인 복잡한 상태 머신과 같은 숨막히는 구조가 없습니다. 많은 복잡성이 모션 캡처 데이터, PoseSearchDatabase, PoseSearchSchema 및 쿼리 로직으로 이전되었습니다. 이는 보다 데이터 지향적인 애니메이션 시스템입니다.

하지만 MM에 한계가 없는 것은 아닙니다.

MM의 본질은 여전히 유한한 데이터베이스 내에서 현재의 자세, 미래의 궤적, 속도, 방향, 태그, 비용(cost) 가중치 등의 조건을 바탕으로 가장 적합한 기존 애니메이션 프레임을 찾는 것입니다. 이는 새로운 동작을 "생성"하는 것이 아니라, 기존 데이터에서 현재 요구에 가장 가까운 결과를 "선택"하는 것입니다.

이는 데이터베이스의 커버리지가 부족하거나, 스키마 표현이 충분하지 않거나, 비용 가중치가 현재 컨텍스트에 맞지 않을 때 여전히 문제가 발생한다는 것을 의미합니다.

로코모션에서 매우 흔한 예를 들어보겠습니다. 축 기반 이동 시스템을 만들고 walk / run / sprint 세 가지 보행 패턴과 45도, 90도, 135도, 180도 회전 애니메이션을 준비했다고 합시다. 디버깅 시, 같은 회전 각도라도 바깥쪽 발이 디딤발일 때는 아주 자연스럽지만, 안쪽 발이 디딤발이 될 때는 튀는 현상, 발 꼬임, 원치 않는 프레임 선택이 발생하거나 아예 원하는 결과를 재생하지 못하는 경우를 쉽게 발견할 수 있습니다.

최근 화제가 된 게임 《붉은 사막》을 예로 들어보겠습니다. 자체 개발 엔진이라는 점 외에도 이는 완벽한 예시를 보여줍니다. 세 가지 보행 패턴, 축 기반 MM 환경에서 어떤 모습을 보여주는지 살펴보죠.

먼저 바깥쪽 발을 디딤발로 삼아 90도 회전하는 애니메이션입니다.

애니메이션이 매끄럽고 자연스러운 것을 볼 수 있습니다.

빨간색 상자는 회전 시의 디딤발, 파란색 화살표는 박차고 나가는 발입니다.

그렇다면 안쪽 발로 90도 회전을 할 때는 어떨까요?

이제 디딤발과 박차고 나가는 발이 같은 발이 되었습니다.

눈에 띄게 튀거나 발이 꼬이는 현상을 볼 수 있습니다.

이것은 제가 예전에 상용 게임에서 겪었던 거의 똑같은 문제가 구체적으로 나타난 것입니다. 당시 저는 Transition이라는 스키마의 파라미터를 어떤 상황에서든 봐줄 만한 수준으로 맞추려 했으나, 결국 파라미터 조절에 엄청난 시간만 낭비하고 좋은 결과를 얻지 못했습니다.

이것은 단순히 파라미터 하나를 조절한다고 반드시 해결할 수 있는 문제가 아닙니다. "좌회전 90도"라는 것은 단일 상태가 아니며, 현재의 보행 패턴, 속도, 가속도, 몸의 방향, 발의 위상(phase), 디딤발, 현재 포즈(pose), 미래 궤적 등 일련의 컨텍스트를 포함하기 때문입니다. MM의 경우, 이 모든 정보가 결국 쿼리 스키마와 비용(cost) 안에 압축되어야 합니다.

물론, MM은 이런 문제들을 완화할 수 있는 많은 방법을 제공합니다. 더 풍부한 데이터, 더 세밀한 특징(feature), 더 나은 발 접촉/위상 특징, 태그(tags), 다중 데이터베이스, chooser, 모션 워핑(motion warping), inertialization 등입니다.

하지만 이러한 해결책들의 대가는 시스템의 복잡성이 다시 데이터 구성, 파라미터 튜닝, 규칙 유지보수 및 엣지 케이스 처리로 되돌아간다는 것입니다.

그래서 저는 MM의 한계가 "MM이 좋지 않다"가 아니라, 상태 머신 시대의 그래프 복잡성을 데이터베이스 커버리지와 쿼리 파라미터 튜닝의 복잡성으로 치환한 것이라고 생각합니다.

이는 여전히 현재로서 매우 신뢰할 수 있고, 제어 가능하며, 디버깅하기 쉬운 솔루션이지만, 로코모션의 종착지는 아닙니다.

---

3. 로코모션은 왜 이렇게 어려운가

로코모션은 가장 기초적인 것처럼 보이지만, 사실 잘 만들기 가장 어려운 부분 중 하나입니다.

입력에 반응하면서도 신체 움직임의 자연스러움을 유지해야 하고, 민첩해야 하지만 튀지 않아야 하며, 플레이어의 제어에 부합하면서도 발의 위상, 몸의 관성, 무게 중심의 이동, 그리고 운동의 리듬과 맞아떨어져야 하기 때문입니다.

캐릭터를 더 생동감 있게 만드는 핵심은 더 풍부하고 연속적인 움직임의 변화에 있습니다. 기본 이동으로 분해해 보면, 이는 더 섬세한 보행 패턴의 변화, 위상의 변화, 속도의 변화, 방향의 변화, 그리고 신체 협응의 변화입니다.

전통적인 애니메이션 시스템은 주로 상태와 규칙을 통해 이러한 변화를 묘사합니다. 반면 MM은 데이터베이스와 특징(feature) 쿼리를 통해 이를 묘사합니다. 이 둘은 사실 같은 질문에 답하려 하고 있습니다.

"현재 이 캐릭터는, 이 운동 컨텍스트에서 다음 프레임에 어떤 모습이어야 하는가?"

차이점이라면, 상태 머신은 수동적인 열거를 통해 답하고, MM은 데이터 쿼리를 통해 답한다는 것뿐입니다.

그리고 신경망 기반 모션 시스템(neural motion system)은 또 다른 형태의 답을 시도하기 시작했습니다. 방대한 데이터에서 운동 법칙을 학습한 뒤, 제어 조건에 따라 결과를 생성하는 것입니다.

---

4. PFNN에서 DeepPhase까지: 운동 표상 학습하기

Neural animation은 갑자기 나타난 것이 아닙니다.

PFNN은 매우 중요한 기점입니다. 그 의의는 일찍이 로코모션을 "상태 전환"에서 "조건부 생성"의 영역으로 밀어붙였다는 점입니다. 미래 궤적, 속도, 보행 패턴, 지형 등의 제어 신호를 입력하면, 네트워크가 다음 자세를 예측합니다.

이는 neural animation이 단순한 오프라인 생성 도구가 아니라 실시간 캐릭터 제어에도 서비스될 수 있음을 보여줍니다.

하지만 PFNN은 여전히 '위상(phase)'이라는 매우 중요한 수동 설계 개념에 의존합니다.

위상은 중요합니다. 왜냐하면 로코모션은 본질적으로 주기성을 띠기 때문입니다. 걷기, 뛰기, 돌기, 멈추기는 고립된 동작이 아니라, 신체 리듬과 발 위상의 연속적인 변화의 결과입니다.

문제는 전통적인 위상이 대개 인위적으로 정의된다는 것입니다. 단순한 걷기와 뛰기 정도라면 괜찮지만, 움직임이 복잡해지고 특히 다양한 보행 패턴, 방향 변화, 스타일 변화, 비주기적 동작이 더해지면 단일 위상만으로는 전체 운동 상태를 묘사하기 어려워집니다.

DeepPhase의 의의가 바로 여기에 있습니다.

그것은 단순히 "우리가 MM을 대체하겠다"고 말하는 것이 아니라, 로코모션의 많은 핵심 변수들이 수동으로 열거하기에 적합하지 않다는 것을 설명합니다. 보행 위상, 리듬, 신체 협응 관계는 본질적으로 연속적이고 다채널(multi-channel)입니다. 수동으로 고정된 위상을 설계하는 것보다, 데이터에서 쿼리, 매칭 및 생성에 더 적합한 위상 매니폴드(phase manifold)를 학습하는 것이 낫습니다.

이 맥락은 매우 중요합니다.

애니메이션 시스템의 진화가 단순히 FSM에서 MM으로, 혹은 MM에서 neural로 넘어가는 것이 아니라, 인공적인 규칙에서 점차 학습 기반의 표상(representation)으로 나아가고 있음을 보여주기 때문입니다.

---

5. Control Operators: 제어 인터페이스의 변화

주목할 만한 또 다른 방향은 Control Operators, 혹은 좀 더 넓은 의미에서의 구조화된 제어 인터페이스입니다.

기저(bottom-level)가 MM이든 neural motion system이든, 상위 레벨에서는 사실 동일한 질문에 답해야 합니다. "캐릭터에게 무엇을 시킬 것인가?"를 어떻게 표현할 것인가?

전통적인 상태 머신에서 이 의도는 보통 상태(state)와 조건(condition)으로 분해됩니다.

MM에서 이 의도는 보통 trajectory, tags, query features, cost로 변환됩니다.

Neural system에서 이 의도는 tensor, keyframes, latent condition, 또는 policy input이 될 수 있습니다.

Control Operators나 Smart Primitives의 가치는 그것들이 애니메이션을 직접 생성하는 데 있는 것이 아니라, 목표, 제약 조건, 스타일, 상호작용 의도를 구조화된 제어 신호로 변환한다는 점에 있습니다.

예를 들어:

캐릭터가 어디로 이동해야 하는가.

어느 방향을 바라봐야 하는가.

어떤 속도를 유지해야 하는가.

어떤 스타일을 사용해야 하는가.

어떤 물체와 상호작용해야 하는가.

어느 손이나 발이 어느 목표 지점에 도달해야 하는가.

이 목표가 강한 제약(hard constraint)인가 부드러운 유도(soft guide)인가.

MM의 관점에서 볼 때, 이러한 제어 정보는 trajectory, tags, query weights 또는 추가적인 특징으로 컴파일될 수 있습니다.

Neural motion system의 관점에서는 생성 과정에 조건부 입력으로 직접 참여할 수 있습니다.

따라서 Control Operators는 통일된 제어 언어의 계층에 더 가깝습니다. 그것은 MM의 핵심 알고리즘도, neural의 완벽한 정답도 아니지만, MM과 neural이 공유하는 상위 인터페이스로 아주 적합합니다.

제가 Control Operators와 MotionBricks의 Smart Primitives 사이에 깊은 연관성이 있다고 느끼는 이유가 바로 이것입니다. 진정한 트렌드는 단순히 "애니메이션 노드를 교체하는 것"이 아니라, 제어 의도가 점차 구조화되고, 데이터화되며, 조합 가능해지는 것에 있습니다.

---

6. 쿼리 생성 vs 잠재 생성(Latent Generation)

이 점이 바로 MotionBricks가 제 흥미를 끄는 이유입니다.

전통적인 Motion Matching은 "쿼리 생성(Query Generation)"에 더 가깝습니다:

시스템이 데이터베이스에서 현재 요구사항에 가장 가까운 애니메이션 클립을 찾습니다.

MotionBricks는 "잠재 공간 생성(Latent Space Generation)"에 더 가깝습니다:

시스템이 대규모 모션 데이터로부터 연속적인 운동 표현을 먼저 학습한 후, 컨텍스트, 목표 키프레임 및 제어 조건에 따라 다음 움직임을 생성합니다.

거칠게 비유하자면 다음과 같습니다:

Motion Matching은 도서관에서 가장 적합한 페이지를 찾는 것과 같습니다.

MotionBricks는 수많은 책을 읽은 뒤 현재의 요구에 맞게 새로운 내용을 써 내려가는 것과 같습니다.

물론, 이 비유를 MotionBricks가 무에서 유를 창조한다고 오해해서는 안 됩니다. 이 역시 대규모 모션 데이터에 의존합니다. 진짜 차이는 MM은 런타임에 데이터베이스를 조회하는 반면, MotionBricks는 훈련을 통해 운동 규칙을 잠재 모델(latent model)에 압축해 두고 런타임에 제약 조건에 맞춰 생성한다는 점입니다.

이는 한 가지 핵심적인 변화를 가져옵니다. 시스템이 더 이상 "이미 존재하는 특정 프레임"만을 선택해야 하는 것이 아니라, 연속적인 공간에서 현재의 컨텍스트에 더 부합하는 움직임을 생성할 기회를 얻게 된다는 것입니다.

MotionBricks 논문의 벤치마크에 따르면, in-betweening 작업에서 15,000 FPS, 2ms 지연 속도를 달성했으며, target reaching success 등의 지표에서도 여러 생성형 베이스라인(baseline)을 눈에 띄게 능가했습니다. 이 결과를 "MotionBricks가 이미 Motion Matching을 전면적으로 대체했다"고 단순 해석해서는 안 됩니다. 벤치마크 환경과 실제 프로덕션 환경은 다르기 때문입니다. 하지만 적어도 과거에 우리가 neural animation에 대해 가졌던 핵심적인 우려, 즉 실시간성(real-time latency) 문제가 뚜렷하게 약화되고 있음을 보여줍니다.

---

7. MotionBricks의 세 가지 역할

MotionBricks는 크게 세 가지 핵심 부분으로 나눌 수 있습니다.

첫째는 Tokenizer입니다.

복잡한 스켈레톤 애니메이션을 더 컴팩트한 잠재 토큰(latent token)으로 압축합니다. 원본 스켈레톤 데이터는 차원이 너무 높아 직접 처리하는 데 큰 비용이 듭니다. 압축된 토큰은 모델이 학습하고 생성하기에 더 적합합니다.

둘째는 Pose Module입니다.

이 토큰들 이면에 있는 운동 법칙을 학습합니다. 단순히 각 프레임을 기억하는 것이 아니라, 다양한 컨텍스트, 목표, 제약 조건 하에서 합리적인 움직임이 어떻게 진화해야 하는지를 배웁니다.

셋째는 Decoder입니다.

잠재 토큰과 제어 조건을 다시 구체적인 스켈레톤 자세로 복원하여 연속적인 애니메이션을 생성합니다.

Motion Matching이 "데이터베이스에서 한 구간을 선택하는 것"이라면, MotionBricks는 "운동 분포(motion distribution)에서 한 구간을 생성하는 것"에 더 가깝습니다.

이것이 바로 전통적인 MM과의 가장 본질적인 차이점입니다.

---

8. 기술 진화의 맥락

이러한 여러 기술의 갈래를 한데 모아보면 대략 다음과 같이 이해할 수 있습니다:

기술	핵심 사상	해결한 문제	여전히 남은 문제
FSM	상태와 전환의 수동 열거	빠른 검증, 명확한 로직	상태 폭발, 유지보수의 어려움
Motion Matching	데이터베이스에서 최적 프레임 조회	상태 그래프의 복잡도 감소, 자연스러운 결과	데이터 커버리지 및 쿼리/비용 파라미터 튜닝에 의존
PFNN	궤적, 보행 패턴, 지형 등의 조건에 따른 동작 예측	neural locomotion의 실시간 제어 가능성 입증	표현력 및 확장성의 한계
DeepPhase	데이터에서 연속적인 위상(phase) 표현 학습	위상, 리듬, 매칭 및 생성 표현의 개선	표상 계층에 치우쳐 있어 완전한 프로덕션 시스템이 아님
Control Operators	제어 의도의 구조화	상위 레벨 제어 언어의 통일	구체적인 백엔드 실행 시스템 필요
MotionBricks	잠재 생성 모델 + smart primitives	대규모 생성, 제약, 상호작용의 통합	툴체인, 디버깅, 훈련 및 프로덕션 검증 등 성숙도 문제

따라서 이 기술 진화는 단순히 "누가 누구를 대체하느냐"의 문제가 아닙니다.

FSM은 사라지지 않았습니다.

MM 역시 당장 사라지지 않을 것입니다.

PFNN, DeepPhase, Control Operators, MotionBricks는 각기 다른 측면에서 애니메이션 시스템의 변화를 주도하고 있는 것에 가깝습니다.

진정한 트렌드는, 운동 시스템이 갈수록 데이터화되고, 연속화되며, 조건화된다는 것입니다.

상태 머신은 수동 열거입니다.

MM은 데이터 조회입니다.

PFNN은 조건 예측입니다.

DeepPhase는 운동 표상의 학습입니다.

Control Operators는 구조화된 제어 의도입니다.

MotionBricks는 대규모 잠재 운동 공간에서 제약 조건에 따라 움직임을 생성하는 것입니다.

이들은 모두 '캐릭터 애니메이션'이라는 거대한 동일한 문제의 각기 다른 부분들을 해결하고 있습니다.

---

9. MotionBricks의 의의

제가 생각하는 MotionBricks의 진정한 중요성은 "또 하나의 신경망 애니메이션 솔루션이 나왔다"는 점에 그치지 않고, 과거에 흩어져 있던 몇 가지 문제들을 하나로 통합하려 한다는 데 있습니다:

기본 이동

스타일 전환

목표 지점 도달

사물과의 상호작용

키프레임 제약

런타임 경로 재계획

이전에는 이를 완성하기 위해 상태 머신, 애니메이션 블루프린트, Motion Matching, Motion Warping, IK, 상호작용 포인트, 각종 규칙들이 함께 맞물려 작동해야 했습니다. 반면 MotionBricks는 하나의 통합된 neural backbone과 smart primitives를 사용해 이를 처리하고자 합니다.

이것이 제가 그 이름(MotionBricks)이 참 잘 지어졌다고 생각하는 이유이기도 합니다.

캐릭터의 기본 이동은 원래 벽돌(brick)처럼 안정적이어야 합니다. 언제나 복잡한 거미줄처럼 얽혀 있는 것이 아니라, 재사용 가능하고, 조합할 수 있으며, 대체 가능한 기반 모듈이어야 합니다.

물론, 이는 MotionBricks가 당장 기존의 모든 애니메이션 시스템을 대체할 수 있다는 의미는 아닙니다. 프로덕션 툴체인, 디버깅의 투명성, 훈련 비용, 데이터 준비, 리타기팅(retargeting), 기획자의 통제 가능성 등 여전히 많은 과제가 남아있습니다. 하지만 이 기술은 매우 명확한 방향을 제시합니다. 미래의 애니메이션 시스템의 복잡성은 "상태 그래프와 수동 파라미터 튜닝"에서 "데이터, 모델, 제어 인터페이스, 그리고 검증 도구" 쪽으로 이동할 가능성이 큽니다.

---

10. 결점 감추기(藏拙)의 시대는 끝날 것인가?

예전에 누군가 게임 개발의 비결 중 상당 부분은 "결점을 잘 감추는 것(藏拙)"에 있다고 말한 적이 있습니다. 저 역시 깊이 동의합니다.

많은 경우, 게임은 모든 것을 완벽하게 해내는 것이 아니라 어디를 드러내고 어디를 가려야 할지 아는 것입니다. 로코모션 역시 마찬가지입니다. 아주 기초적인 것처럼 보이지만 실제로 잘 구현하기란 매우 어렵습니다. 대부분의 플레이어는 "여기서 회전할 때 디딤발이 틀렸어"라고 명확히 지적하지 않습니다. 그저 캐릭터가 부자연스럽고, 부드럽지 못하며, 퀄리티가 낮다고 느낄 뿐입니다.

과거에 이러한 문제들이 오랫동안 근본적으로 해결되지 못했던 것은 개발자들이 이를 몰라서가 아니라, 해결 비용이 너무 높았기 때문입니다.

기본 이동을 잘 만들기 위해서는 애니메이터, 프로그래머, TA, 기획자가 끊임없이 디버깅해야 하고 엄청난 양의 엣지 케이스를 커버해야 합니다. 많은 프로젝트가 결국 이를 가리거나, 우회하거나, 어느 정도의 부자연스러움을 수용하는 쪽을 선택할 수밖에 없었습니다.

하지만 AI와 신경망 기반 모션 시스템의 등장은 이 상황을 바꿀지도 모릅니다.

기본 이동, 스타일 전환, 상호작용 트랜지션 같은 기저의 문제들이 더 안정적이고 자동화된다면, 개발자들은 진짜 차별화되는 요소들에 더 많은 에너지를 쏟을 수 있게 됩니다.

슈팅 게임이라면 애니메이션 TA가 총기 조작과 1인칭 표현에 더 집중할 수 있습니다.

액션 게임이라면 팀이 피격, 처형, 적의 반응, 전투 피드백에 더 몰두할 수 있습니다.

오픈 월드 게임이라면 수많은 로코모션 엣지 케이스에서 오는 유지보수 비용을 크게 줄일 수 있습니다.

그래서 저는 MotionBricks의 의의가 "MM은 죽었다"가 아니라고 생각합니다. 오히려 그것은 우리에게 기본 애니메이션 시스템이 마침내 장기간 결점을 감춰야 했던 복잡한 엔지니어링에서 벗어나, 훨씬 더 견고하고 재사용 가능하며 인프라에 가까운 무언가로 변모할 기회를 얻었음을 보여줍니다.

단기적으로는 MM이 여전히 가장 안정적이고, 통제 가능하며, 도입하기 쉬운 로코모션의 베이스라인이 될 것입니다.

중기적으로는 MM과 neural motion system이 오랫동안 공존할 가능성이 높습니다.

장기적으로 보았을 때 진정 중요한 것은 우리가 MM을 택하느냐 MotionBricks를 택하느냐가 아니라, 단일한 캐릭터 운동 시스템에 여러 백엔드가 서비스될 수 있도록 '통일된 제어 인터페이스'를 구축할 수 있느냐일 것입니다.

결점을 감추던 시대가 당장 끝나는 것은 아닐지도 모릅니다.

---

원문

https://zhuanlan.zhihu.com/p/2033641452836745984?share_code=T7B8tVt6gv0N&utm_psn=2041814874976695569