TECH 으로 돌아가기
TECH HACKER NEWS 오늘 6분 읽기 36 READS

충돌 없이 머지됐는데 결과가 이상해요 — CRDT 연구의 다음 질문, '수렴만으로는 부족하다'

충돌 없이 머지됐는데 결과가 이상해요 — CRDT 연구의 다음 질문, '수렴만으로는 부족하다'
SOURCE IMAGE · HACKER NEWS
충돌 없이 머지됐는데 결과가 이상해요 — CRDT 연구의 다음 질문, '수렴만으로는 부족하다'

협업 도구의 심장, CRDT 이야기

피그마에서 여러 명이 동시에 디자인을 만지고, 노션에서 팀원들이 같은 문서를 편집하는 게 이제는 당연한 일상이 됐잖아요. 이런 실시간 협업의 뒤에는 '여러 사람이 각자 수정한 내용을 어떻게 하나로 합칠 것인가'라는 오래된 난제가 있는데요. 이 분야에서 가장 유명한 답이 CRDT라는 기술이에요. 이게 뭐냐면, Conflict-free Replicated Data Type의 약자로, 여러 기기에서 각자 데이터를 수정해도 나중에 합치면 모두가 자동으로 똑같은 상태에 도달하도록 수학적으로 설계된 자료구조거든요. 서버 없이도, 오프라인에서도 동작한다는 게 매력이라 '로컬 퍼스트' 소프트웨어 운동의 핵심 기술로 자리 잡았죠. 그런데 이 분야를 이끌어온 연구소 Ink & Switch가 최근 연구 노트에서 도발적인 질문을 던졌어요. '수렴만으로 정말 충분한가?'라고요.

같은 상태에 도달한다는 것과 말이 되는 상태에 도달한다는 것

CRDT가 보장하는 '수렴(convergence)'이 뭔지부터 짚어볼게요. 모든 참여자가 같은 수정 사항들을 받고 나면, 받은 순서와 상관없이 전원이 똑같은 최종 상태를 보게 된다는 뜻이에요. 분산 시스템에서 이건 정말 대단한 성질이고, 이걸 수학적으로 보장하는 게 CRDT의 업적이죠. 그런데 함정이 있어요. '모두가 같은 상태를 본다'는 것과 '그 상태가 의미 있는 상태다'는 건 전혀 다른 얘기거든요.

개발자라면 다들 겪어본 상황으로 비유해볼게요. git에서 두 브랜치를 머지했는데 충돌이 하나도 없이 깔끔하게 합쳐졌어요. 그런데 빌드를 돌리니 컴파일 에러가 나요. 한 사람은 함수 이름을 바꿨고, 다른 사람은 옛 이름으로 그 함수를 호출하는 코드를 추가했던 거죠. 텍스트 수준에서는 충돌이 없었지만 의미 수준에서는 완전히 깨진 거예요. CRDT에서도 똑같은 일이 벌어져요. 두 사람의 수정이 각자 보면 멀쩡한데, 자동으로 합쳐진 결과는 아무도 의도하지 않은, 심지어 애플리케이션의 규칙을 어기는 상태가 될 수 있거든요. 예를 들어 두 사람이 각자 일정을 옮겼는데 합치고 나니 회의 두 개가 같은 시간에 겹쳐버리는 식이죠. 시스템 입장에서는 수렴에 성공했지만, 사용자 입장에서는 데이터가 망가진 거예요.

그래서 뭐가 더 필요하다는 걸까요

Ink & Switch가 탐구하는 방향은 크게 세 갈래예요. 첫째, 병합이 자료구조 수준이 아니라 의도 수준에서 이뤄져야 한다는 것. 사용자가 '왜' 그 수정을 했는지에 가까운 정보를 보존해야 좋은 병합이 가능하다는 거죠. 둘째, 애플리케이션마다 지켜야 할 불변식(invariant), 그러니까 '항상 참이어야 하는 규칙'을 병합 과정이 알아야 한다는 것. 셋째, 애매한 상황에서는 충돌을 조용히 삼키지 말고 사용자에게 보여주고 선택하게 하자는 것. 사실 git이 충돌 마커를 보여주는 게 불편하긴 해도, 조용히 잘못 합쳐버리는 것보다는 훨씬 정직한 방식이라는 걸 우리는 경험으로 알잖아요.

업계는 이 문제를 어떻게 다루고 있나요

흥미롭게도 실전 제품들은 저마다 다른 타협을 했어요. 피그마는 순수 CRDT 대신 서버가 최종 결정권을 갖는 단순화된 방식을 쓰고, Linear 같은 툴은 자체 동기화 엔진에서 도메인 규칙을 함께 검사해요. 오픈소스 쪽에서는 Automerge와 Yjs가 CRDT 라이브러리의 양대 산맥인데, 이들도 결국 '자료구조는 합쳐드립니다, 의미는 앱이 챙기세요'라는 선까지만 책임지거든요. 이번 연구는 바로 그 공백, 자료구조와 의미 사이의 간극을 정면으로 다루는 거예요.

협업 기능을 만들 때 기억할 것

동시 편집이나 오프라인 동기화 기능을 만들 계획이 있다면, 이 관점은 설계 단계에서 큰 차이를 만들어요. 'CRDT 라이브러리 붙였으니 끝'이 아니라, 우리 도메인의 불변식이 뭔지 목록으로 뽑고, 병합 후에 그걸 검증하는 계층을 두고, 규칙이 깨졌을 때 사용자에게 어떻게 보여줄지까지 설계해야 하거든요. 충돌 UI는 실패가 아니라 기능이라는 발상의 전환이 필요한 거죠.

정리하면, 자동 병합의 진짜 어려움은 '같아지는 것'이 아니라 '말이 되는 것'이에요. 여러분이 만드는 서비스에서 자동으로 합치면 안 되는, 반드시 사람이 판단해야 하는 데이터는 뭐가 있을까요?


🔗 출처: Hacker News

SOURCE · HACKER NEWS
원문 전체 보기 → https://www.inkandswitch.com/livelymerge/notebook/lm-02/
SHARE
처리 중...