인사이트리포트

1. 전통적인 방식의 문서 동기화

클라우드 기반의 업무 환경이 정착되어 감에 따라 과거 전통적인 방식의 협업은 지속적으로 변화를 맞고 있다. 특히 최근 팬데믹 상황으로 인해 재택근무 등, 원격 업무가 일반화 되어 감에 따라 이러한 상황을 더욱 가속화시켰다.

전통적인 방식으로 동일 문서를 함께 작업하는 방식은 다음과 같다.

1.  문서의 오너십을 가진 사람이 문서의 파트를 쪼개서 각기 다른 이들에게 분배하여 작업한 후 수거하여 직접 수작업으로 취합하기 → 전체 문서 내용에 대한 이해도가 있는 매니저가 필요하며, 그 한 명에게 많은 부하가 집중 된다.

2.  클라우드 상에서 한 개의 문서를 여러 사람들이 시간차를 두고 작업하기 → 이전 순서의 작업자가 작업을 마칠 때까지 자신의 작업을 멈추고 대기하여야 한다.

3.  각자 문서 사본을 가져가서 편집하고, 시간차를 두고 각자 자신의 순서에 편집한 부분만을 골라 Copy & Paste와 같은 수작업으로 Merge 하기 → 대기 시간이 짧아지기에 다소나마 효율이 올라간다.

4.  각자 문서 사본을 가져가서 편집하고 Merge-tool을 이용하여 merge 하기 → Git과 같은 형상관리 툴을 이용한다.

이렇게 차례로 변화를 거듭해 갔다. 내용을 보면 짐직할 수 있듯이, 전통적인 방식의 문서 동기화는 비실시간이 기본이었다. 실시간성을 배제한다면 Git과 같은 Merge-tool을 이용한 동기화는 훌륭한 대안이 될 수 있다.

2. 동시편집 기술의 대두

비실시간 문서 동기화의 문제는 다른 이의 작업물은 Merge가 이루어지기 전까지는 전혀 알 수 없다는 점이다. 또한 일단 문서의 사본을 가져 온 상태에서 작업하기 때문에 그만큼 추가적인 저장 공간 및 작업 툴을 필요로 한다.

때문에 요즘은 온라인 상에서 동시 편집 기능을 제공해 주는 것이 대세가 되고 있다. 예를 들어 Google의 Docs와 같은 워드프로세서는 온라인 상에서 공유 된 사용자들끼리 한 개의 문서를 동시에 편집할 수 있으며, 이때 실시간으로 여러 유저의 편집 내용이 바로 각자의 편집 화면에 반영된다. Docs 외에도 Confluence와 같은 Wiki-like 툴은 물론, MS Office와 같은 상업용 오피스 제품들도 동시 편집 기능을 지원하고 있다.

단순 문서 외에도 개발용 IDE 환경에서도 이런 동시 편집 솔루션은 존재한다. 무료 솔루션으로 Atom의 경우엔 Teletype이, VSCode엔 LiveShare가 있고, 추가적인 서비스를 제공하는 유료 솔루션들도 존재한다.

이렇게 동시 편집은 협업을 위해 필수적으로 요구되는 기능이기에 많은 툴들이 이를 도입하려고 하지만, 불행히도 동시 편집은 인간의 눈에 직관적인 것과 달리, 내부적으로는 무척 복잡한 문제를 안고 있다. 분산 된 환경에서의 동시성은 언제나 모호함을 해결하기 위한 노력이 뒤따른다.

3. 원격 문서 편집

실제로 물리적인 종이 문서 하나를 사이에 두고 2명의 작업자가 직접 펜을 들고 가필 및 편집을 진행하고 있다고 가정해 보자. 이럴 때의 동시성은 정말 물리적인 동시성이라 문서의 내용이 꼬이는 등의 문제가 생길 일이 없다. 하지만 이것을 네트워크 상으로 옮기면 상황은 복잡해진다.

일반적인 문서의 편집은 메모리 상에 선형적으로 배열 된 스트림과 그걸 변경하기 위한 오퍼레이션으로 표현된다.

예를 들어, HAT라는 내용이 담긴 문서가 있고, 이를 CAT라는 내용으로 수정하고자 한다. 그리고 이걸 위해 먼저 맨 앞에 C를 입력하고 이후 H를 지우는 과정을 거쳐서 수정을 한다 가정하자. 그럼 메모리와 오퍼레이션은 다음과 같이 표현 될 것이다.

이렇게 스트림과 오퍼레이션으로 표현한다면 원격으로 이런 작업을 하더라도 동일한 결과가 나올 것이다. 유저의 오퍼레이션을 전달해 주는 중계(Relay) 서버가 이런 역할을 해 준다. 이를 도식화 하자면 다음과 같다.

문서의 위치가 로컬이든 원격지이든 적절한 스트림과 오퍼레이션만 정의한다면 동일한 결과를 나타낼 것이다.

4. 원격 문서 동기화 문제

원격 편집 기능 다음으로 생각해 볼 수 있는 것이 바로 편집자가 2명 이상일 경우이다. 물론 비실시간으로 편집을 진행한다면 이 역시 문제가 될 여지가 없다. 하지만 2명 이상의 유저가 동시에 같은 문서를 편집하려고 할 때는 상황이 조금 복잡해진다.

만약 2명의 유저가 원격으로 같은 문서를 대상으로 동시에 편집 작업을 진행하고 이 작업 진행 상황을 서로 동기화를 하려 한다면 어떻게 해야 할까? 직관적으로 생각했을 때, 2명의 유저가 각자 입력한 동작을 상대에게 전달해 주고, 그 오퍼레이션을 각자의 스트림에 적용하면 서로가 한 동작이 동일하게 재현되기에 결과적으로 문서 역시 동일한 결과물을 나타낼 거라 생각할 수 있다.

예를 들어, 위의 2개 동작을 2명의 유저가 각자 나눠서 수행했다고 가정해 보겠다. 그럼 각자 문서의 스트림을 갖고 있는 상태로 첫 번째 유저가 ‘C’ 문자를 입력하고 두 번째 유저가 첫 번째 문자를 지우는 동작을 수행할 것이고, 각각의 동작은 오퍼레이션으로써 릴레이 서버에 의해 서로 상대에게 전달되어 각자의 스트림에 적용 될 것이다.

실제로 이를 적용해 보면 서로 다른 문자열이 나타난다. 첫 번째 유저는 ‘C’를 입력하자마자 해당 문자가 삭제되어 원래의 “HAT”로 돌아갔고, 두 번째 유저는 H를 삭제하자 곧바로 그 위치에 ‘C’가 입력되어 “CAT”가 되었다. 즉, 결과적으로 서로 다른 스트림을 갖게 되는 것이다.

이번에는 또 다른 예를 들어 보겠다. 같은 문서에서 유저 2명이 각자 첫 번째 문자인 ‘H’를 지운다고 해 보자. 그럼 둘 다 모두 “AT” 라는 결과물이 나올 것으로 기대할 것이다. 하지만 실제로 적용하면 문자 하나가 아닌, 2개가 삭제되어 둘 다 “T” 라는 문서를 얻게 된다. 비록 결과적으로 두 유저가 같은 스트림을 얻었기에 동기화 자체는 되었다 생각할지 모르겠지만, 사실 원하는 결과물과는 거리가 있기에 이것도 적절한 동작은 아니라 할 수 있다.

이런 잘 못 된 결과가 나온 이유는 여러 유저의 오퍼레이션을 변화 없이 그대로 전달하기만 해서 그렇다. 전달 된 오퍼레이션은 아직 적용이 유예 된 오퍼레이션이라, 실제로 오퍼레이션이 수행되면 실시간으로 문서가 변경되는데, 오퍼레이션은 그 적용 이전의 문서를 대상으로 하기 때문에 불일치한 문서를 대상으로 적용하여 잘 못 된 결과가 나온 것이다.

이를 해결하기 위해서는 각 오퍼레이션을 그대로 전달하는 것이 아닌, 조금 더 지능적인 방식의 동기화 매커니즘이 필요하다. 이런 목적으로 만들어진 방식의 대표적인 것이 OT와 CRDT이다.

5. OT(Operational Transformation) 방식

OT 방식은 오퍼레이션을 릴레이 서버가 있는 그대로 다른 사용자에게 전달하는 것이 아닌, 오퍼레이션 적용 과정에서 일어나는 스트림의 변화를 고려해서 오퍼레이션을 적절히 변형시켜서 전달하는 방식이다. 이때 오퍼레이션이 수행 된 시간상의 순서를 고려해 이에 따라 오퍼레이션이 적용 될 우선 순위가 부여되고, 앞서 적용될 오퍼레이션이 미칠 영향이 후 순위의 오퍼레이션에 보정 정보로 작용한다.

실제로 OT를 적용하게 되면 앞서의 동작들은 다음과 같이 보정되게 된다.

유저1의 맨 앞에 ‘C’를 입력 한 오퍼레이션과 유저2의 첫 문자 삭제 오퍼레이션을 서버가 각각 수집한다. 다음으로 오퍼레이션이 수행 된 시간에 맞춰 정렬을 한다. 이때 ‘C’ 문자 입력 오퍼레이션이 첫째 문자 삭제 오퍼레이션보다 먼저 수행되었다고 가정하면, ‘C’ 문자 입력으로 인해 이후 문자들은 모두 1씩 인덱스가 뒤로 밀리게 된다. 결과적으로 첫 문자 삭제 오퍼레이션은 두 번째 문자 삭제로 인덱스가 보정되어 전달되게 된다. 그 결과 실제로 발생한 오퍼레이션과는 조금 달라진 보정 된 오퍼레이션이 각각의 유저에게 전달되어 스트림에 적용되게 된다.

다음으로 유저1과 유저2가 똑같은 위치의 문자를 삭제했을 경우에도 보정 결과 삭제 오퍼레이션을 무시해 버릴 수 있게 된다.

이런 OT 방식은 꽤 직관적이고 언뜻 보기에 구현도 어려워 보이지 않을 것 같아 보인다. 때문에 초기의 동시편집 기능이 도입 될 당시엔 무척 인기가 있었다. 우리가 흔히 사용하고 있는 Google의 Wave 에디터가 바로 OT 방식으로 구현 된 대표적인 예이다. Google Docs나 Microsoft Office 역시도 OT 방식을 채택하고 있다.

OT 방식의 가장 큰 특징은 바로 중앙집중적인 처리 방식이다. Google의 경우엔 클라우드 스토리지를 기반의 서비스를 제공하고 있기에 어차피 문서가 존재하는 곳으로 데이터가 모일 거라 가정하여 그곳에서 교통 정리를 해 주면 된다. Microsoft Office 역시도 OneDrive 기반의 클라우드 서비스 이용자에 한해서 동시 편집 기능을 제공해 주고 있다.

6. OT 방식의 문제

OT의 장점은 곧 단점과 연결된다. 동시 편집을 위한 머지 작업이 한곳에서 이루어지기 때문에 트래픽이 증가하며 서버의 부하가 가중된다는 것이다. 실질적으로 저장을 하는 순간 외엔 굳이 스토리지가 있는 곳으로 데이터가 전송 될 필요가 없음에도 동시 편집을 위해 매번 스토리지가 있는 곳으로 데이터가 전송되는 것이다. 그냥 동시 편집 작업자끼리만 서로 데이터를 교환하면 충분한데도 말이다. 트래픽 증가는 곧 서버 비용 증가로 이어진다.

서버 입장뿐 아니라 사용자 입장에서도 불편함을 느낄 수 있다. 이를테면 같은 네트워크 상에 존재하는 사용자끼리 동시 편집을 하는 상황에서조차 멀리 떨어진 중계 서버로 일단 오퍼레이션 패킷이 전송되어 응답을 받아야 하기 때문이다. 이는 응답 시간이 추가적으로 발생해서 사용에 지장을 주게 된다.

7. CRDT(Conflict-Free-Replicatied Data Types) 방식

2006년 이전까지는 OT가 주류였으나 최근엔 CRDT 방식이 더 각광을 받고 있다. CRDT의 장점은 동시성이 요구되는 당사자끼리만 데이터를 교환하면 된다는 것이다. 이는 서버에 대한 의존성과 부하를 줄이는 효과가 있으며, 각 유저들의 편집 작업 시 반응 속도 향상에도 도움이 된다.

OT 방식이 편집 시간과 인덱스를 기반으로 오퍼레이션을 정의하는 반해, CRDT는 이를 무시하고 스트림 상의 각 문자에 고유한 ID를 부여하고, 이를 기반으로 오퍼레이션을 정의한다는 차이가 있다.

간단히 문자열 스트림에 순서대로 1, 2, 3과 같이 숫자를 부여하고, 새롭게 문자를 삽입하면 삽입 된 위치에 맞춰 각 숫자 사이의 값을 새로 부여한다고 가정해 보자. 그럼 앞서 예를 들었던 상황이 다음과 같이 표현되게 된다.

“HAT” 문자열은 각각 1, 2, 3의 ID 값이 부여되었고, 맨 앞에 ‘C’ 문자를 삽입하면 기존의 문자들의 인덱스가 한 칸씩 뒤로 밀렸던 이전 방식과 달리, ID 값은 변하지 않고 대신 새로 입력 된 ‘C’ 문자가 삽입 된 위치의 ID 값인 1보다 더 작은 값인 0.5가 부여 된 것을 알 수 있다. 그리고 삭제 오퍼레이션 역시 인덱스 값이 아니라 ID 값을 대상으로 한다.

이제 유저 2명이 앞서 예로 든 상황처럼, 각자 이 오퍼레이션을 나눠서 수행한다고 하면 어떻게 될까?

CRDT는 각 유저끼리 직접 오퍼레이션을 주고 받기에, 중간에 오퍼레이션을 조율하여 가공하는 별도의 엔진이 필요가 없다. 즉, 해당 오퍼레이션은 수정 없이 바로 다른 유저의 문서에 적용된다. 이때 위치가 아닌, 특정 ID 1의 위치에 ID 0.5인 문자 ‘C’가 삽입되기에 적용 순서와 상관 없이 정확한 위치에 해당 문자가 삽입되게 된다.

다음으로 유저1과 유저2가 똑같은 위치의 문자를 삭제했을 경우에도 위치가 아닌 ID를 기반으로 삭제하기에 이미 삭제 된 ID는 더 이상 존재하지 않기 때문에 중복 삭제 문제도 발생하지 않는다.

이렇게 위치 기반이 아닌, ID 기반으로 동기화 할 경우엔 굳이 OT 방식과 같이 중간에 오퍼레이션을 보정해 줄 필요 없이 바로 각자의 문서에 다른 유저의 오퍼레이션이 적용이 가능하다는 것을 알 수 있다.

8. CRDT 방식의 문제

CRDT도 OT에 비교해 단점들이 있다. 첫째는 OT 방식보다 많은 메모리를 소모한다는 것이다. 문자열 스트림 외에도 추가적으로 고유 값을 저장하는 메모리와 이를 Tree 구조로 관리하기 위한 메모리를 필요로 한다. 일반적으로 많이 사용되는 CRDT 알고리즘들은 대체로 문서 용량의 2~3배에 달하는 메모리를 필요로 한다.

다음으로는 좀 더 심각한 문제이다. 바로Peer-to-Peer 통신이 항상 가능하지 않다는 점이다. 보안의 중요성이 날로 고조되어 가는 상황에서, 기업들뿐 아니라 개인들 역시 점점 가정 내 개인 PC의 네트워크 보안에도 신경을 쓰는 상황에서, 방화벽 등에 의해 Peer 간 직접 접속이 점점 힘들어지고 있는 상황이다. 이는 NAT 환경에서의 Peer-to-Peer 통신 문제와는 차원이 다른 문제로, 근본적으로 Peer 간 접속이 불가능한 환경이 늘어가고 있다는 것이 핵심이다. OT의 중앙 집중 방식의 장점이 곧 단점으로 변모했듯이, CRDT 역시 Peer 간 직접 통신이라는 장점이 단점으로 작용하는 아이러니가 발생한 것이다. 물론 이런 상황을 해결하기 위한 방법은 존재한다. 하지만 이 방법은 결국 패킷 전송을 중계하는 서버를 이용할 수밖에 없는데, 결국 특정 서버에 부하가 증가하게 되어 CRDT의 핵심 장점이 무색해져 버리는 셈이다.

다음은 CRDT가 시간을 기반으로 하는 것이 아닌 고유 ID를 기반으로 하기에 이것의 merge 과정에서 실시간성이 모호해진다는 점이며, 이로 인해 동기화 결과 문자열이 섞여 의도하지 않은 결과물이 나온다는 문제 등이 있다. 이 모호함을 해결하기 위해 CRDT는 OT보다 더 복잡한 구현을 필요로 하며, 어떤 케이스는 사실상 근본적인 해결이 힘들기도 하다. 그럼에도 지속적으로 문제를 보안하기 위한 노력이 이어지고 있고, 유용한 다양한 알고리즘 기법들이 나오고 있다(Logoot, LSEQ, RGA, Treedoc, WOOT, Astrong 등).

9. 동시 편집 기술의 전망

OT든 CRDT든, 현재까지 완벽한 알고리즘이 존재한다고 말하기는 힘들다. 둘 다 다소간의 문제점들을 갖고 있고, 둘 다 지속적으로 개선을 위한 노력이 지속되고 있다. 현재로선 OT가 더 안정적인 동작을 하고 있긴 하지만, 이는 OT가 더 우수해서라기보다는 중앙집중식 처리라는 환경적인 요인이 더 크게 작용한다. Peer-to-Peer에 비해 발생할만한 문제 상황이 덜 복잡하기 때문이다. 하지만 이는 양날의 검으로, 중앙집중식 처리의 근본적인 한계가 존재할 수밖에 없다. 때문에 지금으로선 OT보다 CRDT가 더 전망이 밝아 보인다.

일반적으로 클라우드 기반의 툴들이 동시 편집은 강력한 기능으로, 효율성을 극대화시켰으며, 이에 따라 기존의 전통적인 툴들도 협업을 위한 속속 동시편집 솔루션을 도입하려 노력하고 있다.

협업을 위한 시스템을 구축할 때, 동시편집 기능을 탑재한다면 훨씬 경쟁력 있는 시스템이 될 것임은 자명하다. 때문에 앞으로는 이런 시스템을 위한 솔루션을 개발할 때는, 설계 단계부터 CRDT를 적용하는 것을 고려해 보는 것도 경쟁력 있는 개발자로서의 필수 소양이 될 것이라 생각한다.