멀티플레이어 브라우저를 만들며 배운 것들 — 협업 도구의 진짜 어려움

브라우저를 같이 쓴다는 게 무슨 말이죠?

구글 독스에서 다른 사람 커서가 움직이는 거 보신 적 있죠? 같은 문서에 여러 명이 동시에 들어가서 글을 쓰고, 누가 어디에 있는지 실시간으로 보이는 그 경험이요. 요즘은 이 개념이 문서를 넘어 브라우저 자체로 확장되고 있어요. 즉, 웹사이트를 여러 명이 같이 열어서 같이 스크롤하고, 같이 클릭하고, 같이 양식을 채우는 도구들이 등장하고 있다는 얘기예요. 멀티플레이어 브라우저(Multiplayer Browser)라고 불리는 새로운 카테고리예요.

이런 도구는 왜 필요할까요? 원격 페어 프로그래밍, 고객 지원(상담사가 고객 화면을 같이 보면서 안내), QA 협업, 디자인 리뷰, 영업 데모 등등 의외로 쓸 곳이 많아요. 화면 공유로도 비슷한 걸 할 수 있지만, 양쪽이 직접 조작할 수 있다는 게 결정적 차이예요. Browserbase, Hyperbeam, Multi 같은 스타트업들이 이 영역에서 경쟁하고 있고요. 이번 글의 저자는 직접 이런 시스템을 빌드하면서 마주친 함정들을 솔직하게 풀어놨어요.

진짜 어려운 건 "누가 누구의 진실을 보고 있느냐"

저자가 가장 강조하는 건 상태 동기화의 본질적 어려움이에요. 멀티플레이어 시스템에서 "실시간"이라는 단어는 함정이 많거든요. 사용자 A가 버튼을 클릭한 시점과 사용자 B의 화면에 그 클릭이 반영되는 시점 사이엔 항상 지연(latency)이 있어요. 100ms든 500ms든, 그 사이에 B가 다른 동작을 했다면? 두 동작은 어떤 순서로 처리돼야 할까요?

이걸 다루는 고전적인 방법이 CRDT(Conflict-free Replicated Data Type)나 OT(Operational Transformation)예요. 이게 뭐냐면, 여러 사용자가 동시에 같은 데이터를 수정해도 결국엔 모두 같은 결과로 수렴되도록 보장하는 자료구조 / 알고리즘이에요. 구글 독스가 OT 기반이고, Figma나 Linear는 CRDT를 쓰는 걸로 알려져 있죠. 그런데 이게 DOM(웹페이지의 구조) 같은 복잡한 트리 구조에 적용될 때는 얘기가 달라져요. 텍스트 한 줄 동기화하는 것보다 훨씬 어렵거든요.

저자는 "순수 CRDT만으로는 부족했다"고 고백해요. 결국 권위 있는 서버(authoritative server) 모델로 일부 회귀했다고 해요. 게임 서버처럼, 모든 입력은 서버를 한 번 거쳐서 정렬된 다음에야 클라이언트로 뿌려지는 방식이죠. 이렇게 하면 일관성은 좋아지는데 지연 시간이 늘어나요. 그래서 로컬 예측(client-side prediction)과 서버 검증 후 롤백(rollback)을 조합하는 게임 개발의 기법을 가져다 썼다고 해요. FPS 게임에서 내 캐릭터가 즉시 움직이지만 서버가 "아니야, 그쪽으로 못 가" 하면 살짝 튕겨 돌아오는 그 매커니즘이요.

브라우저 그 자체가 적이 되는 순간

또 하나 흥미로운 교훈은 브라우저가 멀티플레이어를 위해 설계되지 않았다는 점이에요. iframe 격리, CORS, 쿠키 정책, 자동 재생 차단 등등 보안과 사용자 보호를 위한 모든 정책이 "여러 명이 한 브라우저를 공유한다"는 시나리오와 충돌해요. 그래서 대부분의 멀티플레이어 브라우저는 클라우드에서 실제 브라우저(주로 Chromium)를 띄우고, 그 화면을 비디오 스트리밍으로 전송하는 방식을 써요. WebRTC로 화면을 보내고, 마우스/키보드 입력은 반대 방향으로 전송하는 구조죠.

그런데 이 방식에도 함정이 있어요. 입력 지연이 그것이에요. 클릭이 클라우드 브라우저까지 갔다가, 그 결과 화면이 다시 비디오로 인코딩되어 돌아오는 왕복 시간이 너무 길면 사용자는 "느리다"고 느껴요. 저자는 GPU 인코딩, 저지연 코덱(H.264 대신 AV1이나 커스텀 코덱), 지역별 엣지 서버 배치 등으로 이걸 깎아냈다고 해요. 20ms 차이가 사용성을 가른다는 표현이 인상적이었어요.

비슷한 영역의 다른 시도들

이 분야는 의외로 경쟁이 치열해요. Browserbase는 AI 에이전트가 브라우저를 조작하는 인프라에 집중하고, Hyperbeam은 임베드 가능한 가상 브라우저 SDK를 제공해요. Tuple, Coscreen 같은 화면 공유 도구도 비슷한 영역을 다른 방향에서 접근하고 있어요. 그리고 최근엔 OpenAI의 Operator나 Anthropic의 Computer Use처럼 AI가 브라우저를 사람 대신 조작하는 시나리오가 떠오르면서, 이 인프라의 가치가 한층 높아졌어요.

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

협업 SaaS를 만드는 분이라면 이 글의 교훈은 매우 직접적이에요. "실시간 협업"을 표면적으로 넣는 건 어렵지 않지만, 실제로 쓸 만한 수준으로 만들려면 게임 서버 수준의 설계가 필요하다는 점을 인지해야 해요. CRDT 라이브러리(Yjs, Automerge) 하나 붙인다고 끝나는 게 아니라, 네트워크, 입력 처리, 충돌 해결, UX 피드백까지 통째로 다시 생각해야 한다는 거죠.

또 한국에는 화상 회의나 원격 지원 시장이 큰데, 멀티플레이어 브라우저 형태의 도구는 아직 비어 있는 영역이에요. 고객 상담사가 고객의 화면 "위에" 함께 들어가서 양식을 같이 채워주는 그런 경험은, 시니어 사용자가 많은 한국 시장에서 특히 가치가 클 수 있어요.

마무리

실시간 협업은 "WebSocket 붙이면 되는 거 아닌가요" 수준의 문제가 아니에요. 그 뒤엔 분산 시스템의 거의 모든 난제가 숨어 있어요. 그래도 이 영역은 지금 한참 성숙해 가는 중이고, 새로운 제품이 나올 여지도 많아요.

여러분은 실시간 협업 기능을 구현해본 경험이 있으신가요? CRDT를 직접 써보셨다면 어떤 점이 가장 까다로웠는지 들어보고 싶어요.