Hacker News 2026.03.23 31

Rec Room은 멀티플레이어 스크립팅 에디터의 동시 편집을 어떻게 구현했나

여러 사람이 동시에 코드를 편집한다는 것

구글 독스에서 동료와 동시에 문서를 편집해본 경험이 있을 것이다. 커서가 실시간으로 움직이고, 상대방이 타이핑하는 내용이 즉시 반영된다. 이런 실시간 협업 편집은 텍스트 문서에서는 이미 일상이 되었지만, 코드 에디터, 특히 게임 내 비주얼 스크립팅 시스템에서 이를 구현하는 것은 완전히 다른 차원의 문제다.

Rec Room은 VR 및 크로스 플랫폼 소셜 게임으로, 사용자들이 직접 게임 내 공간을 만들고 로직을 설계할 수 있는 스크립팅 시스템을 제공한다. 문제는 Rec Room의 특성상 여러 플레이어가 같은 공간에서 동시에 스크립트를 편집할 수 있어야 한다는 점이다. 이 글에서는 Rec Room 팀이 이 멀티플레이어 동시 편집 문제를 어떻게 해결했는지를 살펴본다.

동시 편집의 핵심 난제: 충돌 해결

동시 편집에서 가장 어려운 문제는 충돌(conflict)이다. 두 사용자가 동시에 같은 부분을 수정하면 어떻게 될까? 단순하게 "마지막 쓰기가 이긴다(last write wins)" 방식을 쓰면 한쪽의 작업이 사라진다. 이런 문제를 해결하기 위해 업계에서는 크게 두 가지 접근법이 발전해왔다.

첫 번째는 OT(Operational Transformation)다. 구글 독스가 사용하는 방식으로, 각 편집 작업을 "연산(operation)"으로 표현하고, 동시에 발생한 연산들을 서로의 맥락에 맞게 변환(transform)하여 적용한다. 예를 들어, A가 3번 위치에 문자를 삽입하고 B가 1번 위치에 문자를 삽입하면, A의 연산은 B의 삽입을 반영하여 4번 위치로 조정된다. OT는 중앙 서버가 연산의 순서를 결정하는 구조라 구현이 비교적 예측 가능하지만, 연산 유형이 다양해지면 변환 함수의 조합이 폭발적으로 늘어난다는 단점이 있다.

두 번째는 CRDT(Conflict-free Replicated Data Type)다. 각 요소에 고유한 ID를 부여하고, 어떤 순서로 연산이 도착하든 최종 결과가 동일하도록 데이터 구조 자체를 설계하는 방식이다. Figma가 CRDT 기반 접근을 사용하는 것으로 알려져 있고, Yjs나 Automerge 같은 오픈소스 라이브러리가 대표적이다. 서버 없이도 동작할 수 있어 P2P 환경에 적합하지만, 메모리 오버헤드가 크고 구현 복잡도가 높다.

Rec Room의 선택: 비주얼 스크립팅에 맞는 설계

Rec Room의 스크립팅 시스템은 일반적인 텍스트 에디터와 다르다. 노드 기반의 비주얼 스크립팅 환경이라, 편집 대상이 텍스트가 아니라 노드와 연결선(edge)이다. 노드를 추가하거나 삭제하고, 노드 간 연결을 변경하고, 노드의 속성값을 수정하는 것이 주요 연산이다.

이런 그래프 구조의 동시 편집은 텍스트 동시 편집과는 충돌의 성격이 다르다. 텍스트에서는 위치(인덱스)가 핵심이지만, 그래프에서는 구조적 무결성이 핵심이다. 예를 들어, A가 특정 노드를 삭제하는 동시에 B가 그 노드에 새로운 연결을 추가하면 어떻게 될까? 삭제된 노드를 가리키는 연결이 남아 있으면 시스템이 깨진다.

Rec Room 팀은 이 문제를 해결하기 위해 서버 권위(server-authoritative) 모델을 채택했다. 모든 편집 연산은 서버로 전송되고, 서버가 최종적인 상태를 결정한다. 클라이언트는 낙관적으로(optimistically) 자신의 편집을 즉시 로컬에 반영하되, 서버에서 확정된 상태가 돌아오면 그에 맞춰 조정한다. 게임 네트워킹에서 흔히 사용하는 클라이언트 사이드 예측(client-side prediction)과 유사한 패턴이다.

이 접근의 장점은 충돌 해결 로직을 서버 한 곳에 집중시킬 수 있다는 것이다. 서버는 모든 연산의 전역 순서를 결정하고, 구조적 무결성을 검증한 후 확정된 상태를 모든 클라이언트에 브로드캐스트한다. 클라이언트 간 직접 통신이 필요 없으므로 네트워크 토폴로지도 단순해진다.

실시간성과 일관성 사이의 트레이드오프

실시간 동시 편집에서는 항상 응답성(responsiveness)과 일관성(consistency) 사이의 트레이드오프가 존재한다. 서버 확인을 기다린 후 편집을 반영하면 일관성은 보장되지만 사용자 경험이 나빠진다. 반대로 로컬에서 즉시 반영하면 빠릿빠릿하지만 서버 상태와 충돌할 수 있다.

Rec Room은 게임이라는 특성상 응답성이 극도로 중요하다. VR 환경에서 손 동작으로 노드를 드래그하는데 지연이 느껴지면 몰입이 깨진다. 그래서 로컬 예측을 적극 활용하면서도, 충돌이 발생했을 때 사용자에게 자연스럽게 보이는 방식으로 상태를 보정하는 전략을 택했다. 예를 들어, 내가 옮기려던 노드를 다른 사람이 이미 삭제했다면, 드래그 도중 노드가 사라지는 것이 아니라 드래그를 놓는 시점에 "이 노드는 삭제되었습니다"라고 알려주는 식이다.

한국 개발자에게 주는 시사점

실시간 협업 편집은 게임뿐 아니라 다양한 분야에서 수요가 증가하고 있다. 디자인 도구(Figma), 문서 편집(Notion), 화이트보드(Miro) 등이 모두 동시 편집을 지원하며, 한국에서도 협업 도구를 만드는 팀이라면 반드시 마주치는 기술적 과제다.

Rec Room의 사례가 특히 참고할 만한 이유는, 텍스트가 아닌 구조화된 데이터의 동시 편집을 다루기 때문이다. 노드 그래프, 스프레드시트, 칸반 보드 등 비텍스트 데이터를 다루는 협업 도구를 만든다면, OT/CRDT의 텍스트 중심 접근보다 이런 서버 권위 모델이 더 적합할 수 있다.

또한 게임 네트워킹의 패턴(클라이언트 사이드 예측, 서버 reconciliation)이 협업 도구 개발에도 적용될 수 있다는 점은 흥미롭다. 게임 개발 경험이 있는 개발자라면 이미 익숙한 개념들을 새로운 영역에 활용할 수 있을 것이다.