Surface Union — U(AB) editing context 설계
FlowChart에서 두 Surface를 나란히 붙여 한 번에 편집하고 싶을 때가 있습니다. 그런데 "붙인다"는 게 정말 두 문서를 합치는 걸까요? 우리는 합치지 않기로 했습니다.
문제: 두 Surface를 한 화면에
FlowChart에서 두 개의 Canvas Surface를 골라 "함께 편집"하고 싶습니다. 두 시퀀스의 컷을 나란히 놓고 한 번에 정리하는 식이죠. 가장 단순한 구현은 두 Surface를 실제로 하나로 병합하는 것입니다. 하지만 그렇게 하면 소유권이 무너집니다.
Surface A의 객체와 Surface B의 객체가 같은 통에 섞이면, 나중에 "이건 원래 어디 거였지?"를 풀 수 없습니다. 동기화, 권한, 되돌리기가 전부 꼬입니다.
해법: U(AB)는 editing context다
그래서 우리는 합치지 않습니다. 대신 U(AB)라는 임시 editing context를 만듭니다. A와 B는 각자 그대로 있고, U(AB)는 "지금 이 둘을 같이 본다"는 뷰일 뿐입니다.
- 소유권은 원본에 — 모든 객체는 여전히 A 또는 B에 속합니다. U(AB)는 아무것도 소유하지 않습니다.
- 편집은 라우팅된다 — U(AB)에서 A의 객체를 옮기면, 그 변경은 A에 기록됩니다. B의 객체는 B에.
- 닫으면 사라진다 — editing context는 임시입니다. 닫아도 A와 B는 각자 깔끔하게 남습니다.
경계가 명확해야 협업이 산다
이 설계의 진짜 이득은 협업에서 드러납니다. 누군가 A를 편집하고 다른 사람이 U(AB)를 보고 있어도, 변경은 항상 올바른 원본으로 흘러갑니다. CRDT 동기화는 A와 B 각각에서 일어나고, U(AB)는 그 결과를 비출 뿐입니다.
"실제로 합치지 않는다"는 절제가, 오히려 더 강력한 동시 편집을 가능하게 합니다. 경계를 흐리지 않는 것 — 그게 LUTable이 복잡한 구조에서도 무너지지 않는 이유입니다.
일반화
이 패턴은 두 개에 한정되지 않습니다. U(A, B, C, …) 어떤 조합도 editing context로 다룰 수 있습니다. 그리고 같은 원리가 Collection Row를 Surface로 여는 경우, 셀이 여러 Player를 동시에 다루는 경우에도 적용됩니다. 소유권은 원본에, 뷰는 임시로.