▲

GN⁺: 협업 편집에 대한 거짓말, 1부: 오프라인 편집을 위한 알고리듬

 (moment.dev)
2P by neo 19일전 | favorite | 댓글 1개
  • 2024년 초, Moment의 핵심 텍스트 편집기에 사용할 협업 편집 시스템을 조사하기 시작함. 현재 여러 알고리듬이 온라인 및 오프라인 편집 문제를 해결한다고 주장하고 있음. 그러나 실제로는 오프라인 편집 경험이 좋지 않다는 것을 발견함.
  • 오프라인 편집의 문제점
    • CRDTs와 OT 같은 인기 있는 알고리듬은 직접적인 편집 충돌을 비직관적으로 해결하여 사용자들이 데이터 손상으로 인식하게 만듦.
    • 오프라인 편집은 직접 충돌의 가능성을 높이며, 이 알고리듬들은 오프라인 편집에 적합하지 않음.
  • 예시: 사소한 편집 충돌
    • Alice와 Bob이 오프라인 상태에서 문서를 편집함. Bob은 'Color'를 'Colour'로 바꾸고, Alice는 모든 텍스트를 삭제함. 이후 온라인 상태가 되었을 때, 이 충돌을 해결해야 함.
    • 이러한 충돌은 흔하며, 결과적으로 사용자들은 데이터가 손상되었다고 인식함.
  • 알고리듬의 한계
    • Yjs, ShareJS, Peritext 같은 프로젝트는 오프라인 편집을 지원한다고 주장하지만, 실제로는 빈번한 오류가 발생함.
    • 알고리듬은 사용자 의도를 알 수 없으며, 문자 단위로 작동하여 결과에 대한 보장이 부족함.
  • UI/UX 문제로의 전환
    • 알고리듬만으로는 문제를 완전히 해결할 수 없으며, UI/UX 문제로 접근해야 함.
    • git과 같은 문서 병합 UI가 이미 존재하며, 이를 더 접근 가능하고 자동화할 수 있는 방법을 연구해야 함.
    • 일부 연구자들은 이 문제를 UI/UX 문제로 집중하고 있으며, Ink & Switch의 협업 역사 연구가 그 예임.
▲
neo 19일전  [-]
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와 같은 로컬 최대치에서 벗어나기 어렵다고 언급함
답변달기