구글 독스는 어떻게 같은 문서를 동시에 작업을 할 수 있을까?

발표를 준비하던 민호는 팀원에게 구글 독스 링크를 보냈습니다.

민호가 제목을 고치는 동안 팀원은 첫번째 문단에 내용을 추가했습니다. 서로 다른 색의 커서가 움직였지만, 파일을 주고받거나 합치는 과정은 없었습니다.

두 사람이 같은 순간에 같은 문장을 고치면, 문서는 어떻게 자동으로 업데이트 되는 걸까요?

1. 완성된 파일 대신 편집 내용을 주고받습니다

문서를 이메일로 주고받으면 ‘최종’, ‘진짜 최종’ 같은 파일이 생기기 쉽습니다. 각자 다른 사본을 수정하기 때문입니다. 공동 편집에서는 같은 문서를 열고, 사람들이 만든 변경을 계속 나누는 방식으로 이 문제를 줄입니다. 화면을 띄우는 브라우저는 클라이언트, 여러 참여자의 편집을 연결하는 쪽은 서버라고 생각할 수 있습니다.

예를 들어 ‘안녕하세요’ 뒤에 느낌표를 넣는다면, 문서 전체를 새 파일로 전달하는 대신 어느 위치에 무엇을 넣었는지 전달할 수 있습니다. 이는 공동 편집의 원리를 이해하기 위한 예입니다. 구글은 2010년 새 문서 편집기를 소개하면서, 공동 작업자의 변경을 글자 단위로 볼 수 있게 된 경험을 설명했습니다.

참고 : Google의 공동 편집 소개

2. 동시에 고치면 글자의 위치부터 다시 맞춰야 합니다

문제는 다른 사람의 편집이 내가 보고 있던 위치를 바꾼다는 점입니다. ‘오늘 회의’에서 민호가 문장 앞에 ‘팀 ’을 넣는 동안, 팀원이 원래 문장 끝에 느낌표를 추가한다고 해 보겠습니다. 앞에 글자가 늘었으므로 끝의 위치도 달라집니다. 입력을 받은 순서대로 원래 위치에만 적용하면 엉뚱한 곳에 들어갈 수 있습니다.

구글이 2010년 공개한 설명에는 작업 변환, 즉 OT(Operational Transformation)가 등장합니다. 함께 일어난 편집을 고려해 작업을 조정하는 방식입니다. 앞의 예에서는 문장 앞에 추가된 길이를 고려해 끝에 넣을 글자의 위치를 맞추는 식으로 이해할 수 있습니다. 이 예는 공개된 원리를 단순화한 것으로, 현재 구글 독스의 전체 구현을 뜻하지는 않습니다.

참고 : Google의 편집기 구조 설명

3. 글자가 같아지는 일과 의견이 같아지는 일은 다릅니다

공동 편집 시스템이 해결하는 것은 여러 화면의 문서 상태를 맞추는 문제입니다. 민호는 ‘다음 주 출시’라고 쓰고 팀원은 ‘출시 일정 미정’이라고 고친다면, 어느 표현이 업무적으로 맞는지까지 시스템이 판단하지는 못합니다. 내용에 대한 합의는 여전히 사람의 일입니다.

이때 도움이 되는 기능이 댓글과 제안입니다. 본문을 직접 바꾸기 전에 의견을 남기거나 변경안을 검토할 수 있습니다. 또한 문서 링크를 알고 있다는 것과 편집 권한이 있다는 것은 다릅니다. 구글 독스는 뷰어, 댓글 작성자, 편집자처럼 공유 권한을 나눕니다. 누가 무엇을 할 수 있는지 정하는 접근 제어가 공동 작업의 경계를 만듭니다.

참고 : Google의 파일 공유 권한 안내

4. 변경 기록은 문서가 지나온 길을 남깁니다

여러 사람이 고치다 보면 어제의 표현이 더 나았다고 느끼는 순간도 생깁니다. 버전 관리는 이런 변경의 이력을 다루는 개념입니다. 구글 독스의 버전 기록에서는 이전 상태와 변경한 사람을 확인하고, 필요한 버전으로 복원하거나 버전에 이름을 붙일 수 있습니다.

참고 : Google의 버전 기록 안내

민호와 팀원이 같은 문서를 다룰 수 있는 것은 단순히 파일이 인터넷에 있기 때문만은 아닙니다. 편집 내용을 전달하고, 겹친 변경을 조정하고, 권한과 기록을 관리하는 일이 함께 이루어집니다. 화면에 움직이는 작은 커서 뒤에는 서로 다른 입력을 하나의 문서로 맞추는 과정이 있습니다.