저는 몇 주 전에 마틴 클레프만의 CRDT와의 실시간 편집 접근법에 대한 강연을 보았고, 저는 깊은 절망감을 느꼈습니다. 아마도 지난 10년 동안 제가 해왔던 모든 일이 결국 미래의 일부가 되지 못할 것입니다. 왜냐하면 마틴의 작품이 그 일을 대신할 것이기 때문입니다. 진짜 멋있어요.
2010년경에 저는 구글 웨이브에서 일했습니다. Wave는 전자 메일, Google 문서, 웹 포럼, 인스턴트 메시징 및 기타 수백 개의 작은 단일 목적 응용프로그램을 대체할 수 있는 공동 편집 가능한 공간을 만들기 위한 시도입니다. 웨이브에는 어디에서도 보지 못한, 제가 좋아하는 도구인데요: 일반적인 용도의 매체입니다. 다른 많은 도구와 달리 워크플로우를 강제하지는 않습니다. 여러분은 이걸을 휴가 계획부터, 위키 만들기, 친구들과 D&D하기, 회의 일정 짜기 등에 사용할 수 있습니다.
내부적으로 Wave의 협업 편집은 OT(Operational Transform) 위에 구축되었습니다. OT는 예전부터 존재해 왔습니다 - 우리가 사용했던 알고리즘은 1995년의 목성(주 : 논문 이름이 '쥬피터 콜라보레이션 시스템입니다.) 논문에 기초했습니다. 각 문서에 모든 변경사항에 대한 시간별 목록을 저장하여 작동합니다. "위치 0에 H를 입력합니다." "위치 1에 i를 입력합니다." 등등. 대부분의 경우 사용자는 문서의 최신 버전을 편집하고 있으며 작업 로그는 모든 변경사항의 목록일 뿐입니다. 그러나 사용자가 공동으로 편집하는 경우 동시 편집권을 가지게 됩니다. 이 경우 서버에 도착하는 첫 번째 편집은 평소와 같이 기록됩니다. 두 번째 편집이 만료된 경우 작업 로그를 참조로 사용하여 사용자의 실제 의도를 파악합니다. 일반적으로 이건 문자 위치를 업데이트하는 것을 의미합니다. 그런 다음 사용자가 처음부터 의미했던 것을 추축하고 새로운 (편집된) 작업을 추가합니다. 실시간 git-rebase 같죠.
Wave가 죽자 ShareJS에서 OT 모델을 다시 만들었습니다. 노드가 새롭고 이상했을 때입니다. npm이 출시되기 전에 ShareJS를 작업한 것 같아요. 간단한 협업 편집기를 작동시키는 데 약 1000줄의 코드만 필요했고, 처음 데모를 할 때 브라우저와 기본 응용프로그램에서 문서를 공동 편집했습니다.
그 중심에는 문자 오프셋을 업데이트하기 위한 일부 도우미 기능이 있는 for() 루프를 위해 OT가 미화되었습니다. 실제로, 매우 효과적입니다. OT는 간단하고 이해할 수 있습니다. 구현 속도도 빠르고요. (최적화되지 않은 자바스크립트의 경우 초당 10k-100k 작업, 최적화된 C의 경우 1-20M ops/초). 유일한 스토리지 오버헤드는 작업 로그이며, 원하는 경우 해당 로그를 트리밍할 수 있습니다. 전 세계적으로 작업을 받으려면 중앙 집중식 서버가 필요하지만, 대부분의 시스템에는 중앙 집중식 서버/데이터베이스가 있으니까 상관 없죠. 안그래요?
OT의 큰 문제는 중앙 집중식 서버에 의존한다는 것입니다. 소셜 미디어에 문서를 공유할 때 Google 워드프로세스가 사용자에게 "이 문서는 오버로드되어 편집이 비활성화됩니다"라는 이상한 내용을 보여주는 이유를 생각해 본 적이 있습니까? 그 이유(제 생각엔)는 구글 문서를 열면 편집이 모두 실행되는 컴퓨터로 하나의 서버가 선택되기 때문입니다. 유저들이 몰려들 때, 구글은 컴퓨터가 압도되지 않도록 많은 속임수를 빼내야 합니다.
이 문제를 해결하기 위해 그들이 사용할 수 있는 몇 가지 해결책이 있습니다. 문서(예: Google 문서)를 기준으로 편집하는 것 외에도 데이터베이스 트랜잭션에 대한 재시도 루프를 통해 편집할 수 있습니다. 이렇게 하면 직렬화 문제가 데이터베이스로 이동합니다. (Firepad 및 ShareDB는 이러한 방식으로 작동합니다.)
완벽하지는 않지만요. 우리는 웨이브가 이메일을 대체하길 원했어요. 이메일이 되는거죠. 전자 메일 스레드는 여러 회사에 걸쳐 있을 수 있으며 모든 것이 제대로 작동합니다. 그리고 페이스북 메신저와 달리, 이메일은 '참조된' 회사에만 보내집니다. 직장 동료에게 이메일을 보내면 제 이메일이 건물을 떠나지 않습니다. Wave가 이메일을 대체하기 위해서는 동일한 기능이 필요했습니다. 하지만 어떻게 OT 위에서 작동될 수 있을까요? 작동하게 만들었지만 복잡하고 빡빡했어요. 우리는 결국 모든 웨이브가 웨이브 서버 트리를 배열하고 그 트리를 위아래로 넘기는 계획을 세웠습니다. 하지만 실제로 효과가 있었던 적은 없었습니다. 저는 10년 전 Wave Protocol Summit에서 네트워크 접속 방법을 설명하는 연설을 했는데요. 저는 그 강연을 연습했고, 충분히 연습했습니다. 말 그대로 그날 차근차근 따라갔는데 제가 라이브로 만든 버전은 작동하지 않았어요. 왜 그런지 아직도 모르겠어요. 버그가 무엇이든 오픈소스 버전으로 고친 적은 없는 것 같아요. 너무 복잡했어요.
기억하세요, Wave가 사용한 알고리즘은 1995년에 발명되었습니다. 그건 꽤 오래 전 일이에요. 1995년에는 집에 인터넷도 없었던 것 같아요. 그 이후로, 연구원들은 OT가 더 잘 작동하도록 하기 위해 분주해졌습니다. 가장 유망한 작업은 CRDT(Conflict-Free Replicated Data type)를 사용합니다. CRDT는 문제의 핵심 출처가 필요 없이 실시간으로 편집할 수 있도록 약간 다르게 접근합니다. 마틴은 그들이 어떻게 일하는지를 저보다 더 잘 설명해주기 때문에 자세한 건 생략하겠습니다.
사람들은 수년 동안 제가 그들을 어떻게 생각하느냐고 물었고, 제 대답은 항상 이런 것이었습니다.
깔끔하고, 사람들이 그걸 작업하고 있는 게 기쁜데요. 하지만 :
나는 그 모든 비판들을 했고 CRDT들을 일축했습니다. 하지만 그렇게 하면서 저는 문헌을 추적하는 것을 그만두었습니다. 그리고-짜잔! CRDTs는 조용히 나아졌습니다. 마틴의 연설은 (볼 가치가 충분히 있어요) 요점을 다루었습니다 :