Hacker News 의견

• Eg-walker와 ShareJS의 저자는 실시간 협업 도구가 온라인에서 함께 작업할 때 유용하지만, 오프라인 편집이나 장기적인 브랜치에서는 충돌 마커를 추가하고 수동 검토를 할 수 있는 옵션이 필요하다고 언급함

  • Eg-walker 알고리즘은 모든 사용자로부터 문자별 편집 추적을 저장하고, 모든 변경이 발생한 시점을 저장하여 충돌 범위를 감지하고 표시할 수 있는 CRDT를 구축할 수 있는 가능성을 제시함
  • 이 문제는 흥미로운 문제이며, 아직 해결되지 않았으므로 더 많은 관심이 필요하다고 강조함

• CRDT를 사용하는 구현의 또 다른 문제는 인프라 부담임

  • CRDT를 사용할 경우 Redis나 MyRocks와 같은 것을 사용하는 것이 좋으며, RDBMS, 특히 Postgres로 백업하지 말 것을 권장함

• CRDT를 노트 작성 소프트웨어에 통합하는 작업을 하고 있는 사용자에게 감사의 인사를 전함

• 기계적 병합 알고리즘은 다양한 종류의 충돌에서 성능이 다를 수 있으며, CRDT는 병합된 텍스트가 사용자가 의도한 것인지 결정할 수 없음을 언급함

  • Upwelling 논문에서는 의미적 충돌과 구문적 충돌의 차이에 대해 자세히 설명함
  • 진지한 협업은 문서 검토 문제이며, 특히 저널리즘과 과학 출판에서 중요함

• 협업 텍스트 편집에 사용되는 알고리즘(CRDTs와 OT)은 편집 작업의 수행 및 상호작용에 대한 엄격한 대수적 요구사항이 있음

  • 서버가 UX 논리에 따라 작업을 처리하고, 클라이언트는 낙관적 편집을 허용하는 리베이스/예측 전략을 사용할 수 있음

• 수학적, 인과적, 엔트로피적 충돌 개념이 의미적 충돌과 혼동되었다고 언급함

  • CRDTs 중 충돌을 보존하는 클래스가 가장 유망하며, 사용자가 충돌을 시각적으로 확인할 수 있도록 해야 함

• AI를 사용하여 병합을 예측할 수 있는 가능성을 제시함

  • LLM이 저자의 변경 세트를 보고, 편집이 중복되는지 여부를 묻고, 변경 순서를 결정하여 90%의 좋은 결과를 얻을 수 있을 것이라고 언급함

• CRDTs는 분산 데이터 구조에 대한 훌륭한 공식 모델이지만, 모든 충돌을 자동으로 해결해야 한다는 개념에 문제가 있다고 언급함

  • 충돌을 구조적으로 표현하고 공유 및 협력적으로 해결할 수 있는 모델이 필요함
  • "Lazy Merging"이라는 구조적 충돌 표현 모델을 개발하여, 수학적 접근을 통해 간단한 개념적 모델을 제시함

• 여러 개체가 동시에 데이터에 대한 권한을 가지는 것은 해결할 수 없는 문제라고 언급함

  • 분산 시스템에서 배운 교훈이며, 문서의 분산 편집에서 명확히 드러남

• 2009년에는 Git이 자동으로 변경을 병합하는 알고리즘에 대한 논의가 많았으며, Torvalds는 자동 병합의 한계에 대해 회의적이었음을 언급함

  • 오프라인 편집은 UI/UX 문제이며, 오래된 솔루션을 답습하는 컴퓨팅의 문제와 관련됨
  • 텍스트 편집에서 오프라인 협업 병합은 프로세스의 중심이 되어야 하며, MacWrite와 같은 로컬 최대치에서 벗어나기 어렵다고 언급함