여러 사용자가 같은 문서를 동시에 편집할 때, 다른 사람의 연산이 먼저 적용됐다는 사실에 맞춰 내 연산을 변환(transform)해서 모두가 같은 결과에 이르게 하는 방식. 실시간 협업 편집기에서 오래 쓰여 왔다.
예
문서 ABCD에서 A는 위치 1에 X를, B는 위치 3에 Y를 동시에 넣는다. 서버가 A의 삽입을 먼저 적용하면 AXBCD가 되어 B가 노린 위치가 한 칸 밀린다. 그래서 B의 연산을 insert('Y', 3)에서 insert('Y', 4)로 바꿔 적용한다. 결과는 양쪽 모두 AXBCYD다.
sequenceDiagram
participant A
participant S as 서버
participant B
Note over A,B: 문서 ABCD
A->>S: insert('X', 1)
B->>S: insert('Y', 3)
Note over S: A를 먼저 적용 → AXBCD
Note over S: B의 연산을 insert('Y', 4)로 변환해 적용
S->>A: insert('Y', 4)
S->>B: insert('X', 1)
Note over A,B: 양쪽 모두 AXBCYD
특징
- 대개 중앙 서버가 순서를 정한다: 실무 구현(Google Docs 계열 등)은 어떤 연산이 먼저인지 서버가 결정하고 변환을 수행한다. 서버 없는 OT 알고리즘도 연구됐지만 정확하게 만들기가 훨씬 어렵다
- 변환 함수가 폭발한다: 연산 종류(삽입·삭제·서식…)의 조합마다 변환 규칙을 짜야 해서 종류가 N개면 대략 N²개의 규칙이 필요하고, 모든 경우에 정확하게 만들기 어렵다
- 메모리는 효율적이다: 문자마다 ID를 붙이지 않는다
- 수십 년의 연구와 실무 적용으로 검증된 방식이다
CRDT와 비교
| OT | CRDT | |
|---|---|---|
| 서버 | 대개 순서를 정할 중앙 서버 필요 | 서버 없이도 병합 가능 |
| 충돌 해결 | 연산을 변환해 보정 | 자료구조가 스스로 수렴 |
| 비용 | 변환 규칙의 복잡도 | ID·툼스톤 같은 메타데이터 |
| 오프라인 | 약함 | 강함 |
서버가 중재해야 하므로 오프라인에서 오래 따로 고친 뒤 합치는 로컬 퍼스트에는 CRDT가 더 자연스럽다. 반대로 항상 온라인인 협업 편집기라면 OT도 여전히 좋은 선택이다. 동시 수정 충돌이라는 같은 문제를 데이터베이스에서는 트랜잭션 격리(Transaction Isolation)와 락으로 푼다(ACID).