<aside> 📑

</aside>

들어가며

우리 팀은 자기소개서 작성자와 첨삭자가 실시간으로 협업할 수 있는 서비스를 개발하고 있습니다. 작성자가 자소서를 작성하는 동안, 첨삭자는 특정 부분을 드래그하여 피드백을 남길 수 있습니다. 이 과정에서 흥미로운 기술적 도전 과제가 발생했습니다.

핵심 문제

• 작성자가 텍스트를 실시간으로 수정할 수 있습니다
• 첨삭자가 동시에 특정 영역을 드래그하고 있을 수 있습니다
• 드래그 중인 영역이 작성자에 의해 수정되면, 드래그 영역도 함께 조정되어야 합니다
• 드래그 영역이 완전히 삭제되면 드래그를 취소해야 합니다

백엔드는 이미 OT 방식을 채택(OT 방식 )했고, 서버에는 "저의 <c1>성장 과정을</c1> 관통하는"와 같이 마크업 형태로 저장됩니다. 그렇다면 프론트엔드에서는 이 데이터를 어떤 구조로 관리해야 할까요?

왜 인덱스 기반이 불가피한가?

먼저 선택의 여지가 없는 부분을 명확히 해야 합니다. 백엔드가 OT 방식을 사용하고, 첨삭 등록 API는 다음과 같은 형태를 요구합니다.

POST /api/reviews
{
  startIdx: 3,
  endIdx: 8,
  editingText: "성장 과정",
  version: 1
}

서버는 인덱스를 기반으로 충돌을 해결합니다. 만약 프론트엔드에서 다른 데이터 구조(예: DOM 트리, UUID 기반 등)를 사용한다면, API 요청 시점에 인덱스로 변환하는 추가 작업이 필요합니다. 이는 불필요한 복잡도를 증가시키므로, 프론트엔드도 인덱스 기반으로 데이터를 관리하는 것이 자연스럽습니다.

하지만 "인덱스 기반"이라는 큰 틀 안에서도 여러 방식이 존재합니다. 이제부터 각 방식을 깊이 있게 살펴보겠습니다.

방식 1: 순수 인덱스 방식

개념