제가 틀렸었어요. CRDT가 미래입니다.

구글 Wave 개발자가 얘기하는 Conflict-free Replicated Data Types 이야기
ㅤ→ CRDT : 실시간 협업도구에서 동시 편집을 지원하는 자료 구조
- Wave는 OT(Operational Transform) 기반 : 모든 변경에 대한 시간순 목록을 저장. 실시간 git-rebase 와 같음
- OT의 문제중 하나는 중앙 집중식 서버/DB가 필요하다는 것
ㅤ→ 구글 닥스(역시 OT기반) 문서에 사람이 몰릴 때 '이 문서는 과부하 되어 편집이 불가능 합니다' 가 나오는 이유가 아마도 이거일듯?
ㅤ→ 문서를 분할하거나 DB 트랜잭션에 재시도 루프를 통해서 회피는 가능 (Serialization문제를 DB로 이관해버림)
ㅤ→ 하지만 완벽하지 않음. Wave는 여러 사람이 동시에 편집했고 잘 동작은 했지만 버그가 많았음. 너무 복잡
- CRDT 의 부상
ㅤ→ Wave가 사용한 알고리즘은 1995년에 발명 된 것. 계속 OT가 잘 동작하도록 연구했지만, CRDT가 더 전도 유망
ㅤ→ CRDT는 다른 접근법을 취해서, 중앙DB없이 실시간 편집이 가능
ㅤ→ 예전에 문제라고 제기했던 속도/용량/기능/복잡도가 모두 개선 됨
ㅤㅤ* 속도 : 요즘의 CRDT (Automerge / RGA or y.js / YATA) 들은 log(n) 수준의 조회 가능
ㅤㅤ* 용량 : Martin 의 Columnar 인코딩은 문서 크기의 1.5~2배 크기 정도로 저장이 가능.
ㅤㅤ* 기능 : 이론적으로는 Rewinding 및 replaying이 가능. 물론 아직 구현한 사람은 없음
ㅤㅤ* 복잡도 : 구현체 크기가 OT보다 CRDT가 크긴 하겠지만 큰 차이 없음
ㅤ→ 위 개선 사항들은 Automerge 에서 곧 제공될 예정

- 실시간 편집에 있어서, 슬프지만 OT 와 관련 작업들은 더이상 필요없을 것
ㅤ→ OT의 모든 기능이 CRDT에 넣을 수 있지만, 반대는 불가능함
ㅤ→ OT의 장점은 중앙 집중식 소프트웨어에 적합하다는 거지만, 분산 알고리즘은 중앙 집중방식에서도 잘 작동함
ㅤ→ WASM에서 실행되는 고품질 CRDT가 JS의 OT 구현보다 빠를 것

- 이제는 가볍고 빠른 CRDT를 만들어야 할 시점.
ㅤ→ 학문적인 부분은 거의 완성되었고, 이제 훌륭한(kick-ass) 구현체가 필요한 시점