동시 협업 기술 리서치

Jay Kim·2022년 9월 15일

I. 동시 협업 기술 리서치

A. 동시 협업 기술이란?

1. 기본 개념

동시 협업 기술은 실시간으로 문서 뿐만 아니라, 스프레드시트 또는 코드 등 하나의 문서를 온라인을 통해 여러 사람과 동시에 수정하고 공유할 수 있도록 하는 기술로 실시간 협업 툴, 프로그램에 사용되는 기술이다.

이 기술의 핵심은 동시 협업 시 일어나는 충돌을 처리하는 것이며 각각의 종류마다 충돌 처리 방법을 포함한 방식의 차이점이 존재한다.

2. 종류

OT(Operational Transformation)

출시 년도 : 1989년

주 사용처 : Google Docs, Google Wave, MS Office

방식 : Operation이 이전 동작에 의해 바뀌어(순서에 따라) 다음 동작을 Transform 시켜준다.

Operation에 대해 History buffer의 기존 operation들과 비교하여 transform 진행
모든 변경사항 기록 → 서버에 모두 전송 → 순차적 실행(동작은 서버에서) → 클라이언트에게 전달

특징 :

각 객체에 대해 가변적인 인덱스 부여
Update operation을 지원하지 않는다.

문제점 :

(Red : Server / Gray : Client)

              (Red : Server / Gray : Client)

중앙 집중식 Server/DB가 필요하다. → 서버에 많은 트래픽이 몰리는 경우 과부화 발생 가능 → Transformation을 하는 주체인 서버가 있어야 하기 때문에 클라이언트가 서버에 변경사항을 보내면 다른 클라이언트들과 직접적으로 연동할 방법이 없다. ex) Google Docs 사용 중 ‘이 문서는 과부하 되어 편집이 불가능 합니다’의 경고 Lock
네트워크 상에 존재하는 클라이언트끼리 동시 협업 하는 상황에서도 멀리 떨어진 중계 서버로 operation 패킷이 전송된 후 응답을 받을 수 있어 응답 시간이 길다.

OT 오픈소스 :

	star	license
sharedb	5.3k	MIT license
rustpad	2.3k	MIT license
joshData/jot	323	GPL v3

오픈소스 특징

Sharedb : JSON 문서 협업을 위한 풀 스택 라이브러리
- DerbyJS 웹 애플리케이션 프레임워크를 위한 실시간 백엔드로 사용
Rustpad : OT 기반의 소스 협업 텍스트 편집기
- 브라우저에 코드를 쓰며 사용자들끼리 실시간 협업이 가능하며 DB는 불필요하다.
Jot
- node.js 및 브라우저에서 사용하기 위해 JavaScript로 작성된 JSON 데이터 모델에서 OT 구현
- 다른 오픈소스처럼 문자열 작업은 JSON에서 인코딩할 수 있는 모든 종류의 데이터에 대해 작업 가능

CRDT(Conflict-Free-Replicated Data Types)

출시 이유 :

Untitled

OT기술의 중앙 집중식 Server/DB가 필요하다는 문제점을 해결하기 위한 기술

→ 중앙 서버 없이도 동시성이 요구되는 클라이언트끼리만 데이터를 교환 가능 (P2P 통신)

→ 중앙 집중식 Server/DB가 필요 하지 않기 때문에 어떤 네트워크, 통신을 선택해도 무방하다.

⇒ OT기술보다 성능 및 확장성 면에서 우수 (서버 의존성/부하 ↓ , 반응 속도 향상 ↑)

출시 년도 : 2006년

주 사용처 : Figma(UX/UI 프로그램), ****Redis, Riak, 국내 협업 도구 Workie , Apple Notes

차별점(특징) :

No History Buffer
OT기술은 협업 Editing에만 관점을 두지만, CRDT는 분산 data structure를 제공하여 협업 일관성 유지
“CRDT는 어떤 변경사항을 받으면, 순서와 상관없이 변경사항만 같으면 같은 상태이다.” → OT는 서버에서 받은 변경사항을 순차적으로 실행한 반면, CRDT는 순서가 상관 없고 Operation만 같으면 어긋나더라도 같은 상태가 된다. (OP1 → OP2 = OP2 → OP1) ⇒ HOW? OT = 각 객체에 대해 가변적인 인덱스를 부여 (Integer index) CRDT = 각 객체에 대해 스트림 상의 유니크한 값을 부여 (Unique ID) ⇒ 따라서 동시 편집을 하더라도 각 객체에 대해 유니크한 값으로 판별하여 대소 비교 후 정렬하기 때문에 충돌이 발생하지 않고 서버의 응답을 기다리지 않아도 된다.

문제점 :

OT 방식보다 많은 메모리를 소모한다. → 문자열 스트림, Unique ID 저장하는 메모리와 이를 Tree 구조로 관리하기 위한 메모리 등
항상 P2P 통신이 가능한 것은 아니다.
- 보안이 강화되면서 방화벽 등에 의해 Peer 간의 직접 접속이 힘든 상황 증가 → 해결하기 위해 결국 패킷 전송을 중계하는 서버를 이용할 수 밖에 없어 결국 특정 서버에 부하가 증가하게 된다. → CRDT의 중앙 서버가 없다는 핵심 장점이 무색해진다.
시간 순이 아닌 고유 ID를 기반으로 한 merge 과정에서 의도하지 않은 결과물이 나올 수 있다. (인터리빙 문제) → 위의 예시와 같이 동시에 두 단어를 입력하여 merge 했을 때, 랜덤하게 부여된 고유한 인덱스를 갖는 각각의 알파벳이 섞이게 되어 의도하지 않은 결과가 나올 수 있다.

⇒ 문제를 보완하기 위해 지속적으로 다양한 알고리즘 기법이 나오고 있다. (Logoot, RGA, WOOT 등)

알고리즘	설명

| WOOT
(2006) | - 요소의 위치가 이웃 요소와 관계에 의해 결정되므로 완전히 삭제하기가 어려워서 tombstone을 사용 (*tombstone = 다른 프로그램의 활성화 등으로 인해 프로그램이 일시적으로 종료되는 것)

매우 복잡하고 처리 비용이 크며 메타데이터의 오버헤드로 인해 실용적이지 않음. |
| Logoot
(2009) | - 어휘 순서를 사용해서 문서의 요소의 순서 설정
새로운 요소 삽입을 위해서는 배열의 shift 발생
Woot 알고리즘보다 메모리 성능이 뛰어나지만 인터리빙 발생 가능성 존재 |
| RGA
(2011) | - 가장 빠른 CRDT 구현 중 하나로 모든 요소는 특정 요소 뒤에 추가
ins(predecessor, id, char)
문자 간의 종속성 체인 정보를 보존하여 인터리빙 문제 해결
그러나 리스트의 선두에 삽입하거나 후임 요소가 없는 케이스에는 인터리빙 발생 가능성 있음 |
| YATA | -RGA와 똑같이 선행 ID 유지하고 후임 ID까지 저장 ins(left, right, id, char) |

Untitled

CRDT 오픈소스:

	star	license	algorithm
automerge	13.8k	MIT license	RGA
yjs	8.7k	MIT license	YATA
yorkie	461	Apache License 2.0	RGA

오픈 소스 특징

Automerge
- 문서가 커질수록 내부의 트리 기반 데이터 구조가 커지고 느려진다.
- Immutablejs를 많이 사용하여 메모리 사용량이 증가하고 성능이 저하된다.
- 삽입된 각 문자를 별도의 항목으로 처리
  
  ⇒ Automerge는 속도가 느리다.
Yjs
- Automerge와 똑같이 트리 구조를 사용하지만 모든 항목을 단일 플랫 목록에 넣어 데이터 구조를 개선하였다.
  
  ⇒ 속도 개선
- 문서 기반 협업 도구를 만든다면 성능이 좋고, 메모리 사용량이 적은 “Yjs”을 추천
Yorkie
- AutoMerge나 Yjs와 같은 라이브러리와 달리 SDK, Server, DB를 포함하여 공동 편집 기능을 쉽게 구현할 수 있도록 한다.
- JSON과 유사한 Document API 제공

Fluid Framework

Microsoft에서 구축한 분산된 실시간 협업 웹 응용 프로그램을 구축하기 위한 라이브러리이다.

출시 이유 : MS 측에서 Office 및 타사 응용 프로그램의 사용자 간의 실시간 협업을 허용하기 위해서

출시 년도 : 2020년

주 사용처 : Office 365 및 Teams

특징 :

사용자 정의 서버 코드가 필요 없는 데이터 지속성을 갖춘 클라이언트 중심
React, Angular, Vue 같은 다른 프레임워크와도 연동하여 사용 가능
분산 데이터 구조
매우 짧은 대기 시간
****참조 시퀀스 번호 부여 (+최소 시퀀스 번호) → 특정 순서로 적용 (Total Order Broadcast 사용)

사용 이점 :

기존 방식) 협업 앱을 구축하려면 로직을 추가하고 관리하는 서비스가 필요
- Hub 및 Cache, WebSocket
Fluid Framework 사용하는 경우) 로직을 추가하지 않아도 Fluid가 아키텍처의 핵심 부분을 대체하여 성능 ↑ & 엔지니어링 비용 ↓

좌) 기존 방식 / 우) Fluid Framework 방식

                                   좌) 기존 방식 / 우) Fluid Framework 방식

핵심 비전 :

협업을 위한 설계 분산 애플리케이션 모델을 활용하여 웹 및 문서 컨텐츠에 대한 공동 작업을 업계 최고의 속도와 규모로 수행
플랫폼으로서의 웹 모든 기기, 플랫폼 및 앱에서 경험을 제공하는 웹 기반 프레임워크 지원을 비롯한 웹 에코시스템의 통합

오픈소스 :

	star	license
MS/FluidFramework	4k	MIT license

오픈소스 특징 :

서버 로직을 최대한 단순하게 → 낮은 서버 비용으로 클라이언트 간에 즉각적인 동기화를 보장하는데 도움
서버를 단순하게 유지하기 위해 각 클라이언트는 자체 상태를 담당
- 이전 시스템) 서버에 정보 소스를 유지
- Fluid 서비스) 데이터 작업을 수행하고 작업 순서를 지정, 순서가 지정된 작업을 클라이언트에 반환 ⇒ 클라이언트는 해당 시퀀스를 사용하여 작업을 수신하는 순서에 관계없이 현재 상태를 독립적이고 정확하게 생성 가능

노션의 공동 편집 기술 조사

안타깝게도… Dependency Walker 사용 결과 Notion.exe가 웹 기반으로 이루어져 있기 때문에 어떤 공동 편집 기술을 사용하는지 분석이 되지 않았습니다.😓

노션 기술 센터에 어떤 공동 편집 기술을 사용하는지 문의한 결과 OT, CRDT, Fluid Framework 중 어떤 것도 사용하지 않고 단지 클라이언트가 마지막으로 업데이트를 전송하면 한 번에 모두 업데이트를 한다고 답변 받았습니다.

노션 문의 내용 캡쳐본

                        노션 문의 내용 캡쳐본

코드 동시 편집 기술

무료)

Atom의 Teletype (https://teletype.atom.io/) : 공식 문서에 시연 영상 포함되어 있습니다.
처음에 클라이언트들이 하나의 서버에 접속한 후에는 P2P 방식으로 클라이언트들끼리 서로 코드를 직접 공유하는 방식입니다.
VSCode 및 Visual Studio 2017 이상의 LiveShare (https://visualstudio.microsoft.com/ko/services/live-share/) : 공식 문서에 시연 영상 포함되어 있습니다.
게스트들이 읽기만 가능하게 할지, 읽고 쓰기 권한을 줄 지 셋팅 가능
메신저로 공동 작업 세션 URL 링크를 수신하면 링크를 탭하여 웹브라우저를 통해서 Live Share 참여 가능하고
혹은 설치된 APP을 통해 오픈할 수 있습니다.

그 외 유료 솔루션들도 존재

추가로 클라우드 통합 개발 환경 구름IDE는 별도의 개발용 IDE 환경 설치 없이 웹 브라우저에서 다양한 언어로 코드 편집 및 빌드, 실행, 디버깅 + 실시간 동시 코드 편집 기능, 컨테이너 공유 및 다양한 기능이 있습니다.
팀 생성 후 채팅 기능도 있어 팀원들과 프로젝트 진행 시 매우 편리할 것 같아요.
컨테이너별 프로젝트 관리 가능
삼성, 삼성sds, 카카오, NHN 등 기업에서 사용한다고 하네요. 개발한 회사는 10년차 스타트업 회사로 판교에 있네요
(구름IDE 공식 사이트 :https://ide.goorm.io/)

참고자료