솔직히 말씀드리면, 저도 처음엔 "그냥 Figma 쓰면 되지 않나?"라고 생각했습니다. 그런데 오픈소스 디자인 도구 외주를 진행하다 보니 커스텀 자유도 문제가 발목을 잡았고, 결국 Tldraw SDK를 직접 데모로 보여주는 방식으로 팀 합의를 끌어냈습니다. 도구 선택은 단순히 취향 문제가 아니라, 우리 도메인에 커스텀 셰이프가 실제로 필요한가라는 질문에 어떻게 답하느냐의 문제였습니다.
SDK 도입 전에 먼저 이 세 가지를 확인하셨습니까
Tldraw SDK를 도입하기로 결정했다면, 본격적인 개발에 들어가기 전에 반드시 점검해야 할 항목이 있습니다. 제가 직접 써봤는데, 이 단계를 건너뛰면 출시 후에 꽤 곤란한 상황이 생깁니다.
Tldraw는 캔버스 기반 협업 도구를 자체 구축할 수 있도록 설계된 오픈소스 SDK입니다. 여기서 SDK(Software Development Kit)란, 특정 플랫폼이나 서비스 위에 맞춤형 애플리케이션을 만들 수 있도록 제공되는 개발 도구 모음을 의미합니다. Figma처럼 완성된 SaaS 제품을 쓰는 게 아니라, 도구 자체를 직접 조립하는 방식이라고 보시면 됩니다.
문제는 이 자유도가 운영 부담을 그대로 개발자에게 넘긴다는 점입니다. 동기화, 인증, 저장 로직을 모두 자체 구현해야 하기 때문에, 클라이언트 합의 단계에서 이 부분을 명확하게 짚지 않으면 납품 후 유지보수 책임 소재가 흐릿해집니다. 제 경험상 이건 기술 문제가 아니라 계약 문제로 이어지는 경우가 많습니다.
도입 전 체크리스트로 제가 실제로 사용하는 항목은 다음과 같습니다.
- 클라이언트 도메인에 커스텀 셰이프(Custom Shape)가 실제로 필요한가. 커스텀 셰이프란 기본 도형 외에 도메인 특화 형태의 요소를 직접 정의해 캔버스에 올리는 기능입니다.
- 실시간 동기화(Real-time Sync) 구현 범위를 누가 맡는가. 실시간 동기화란 여러 사용자가 동시에 캔버스를 편집할 때 변경 사항이 즉시 반영되는 방식입니다.
- 인증 및 저장 레이어를 클라이언트 인프라에 붙일 수 있는가.
이 세 가지에 명확하게 답이 나와야 개발 일정과 운영 책임 매트릭스를 짤 수 있습니다. 일반적으로 SDK 도입은 기술 문서만 보고 결정하는 경우가 많은데, 저는 반드시 운영 시나리오를 먼저 그려보라고 권합니다.
운영 책임을 누가 지느냐가 출시 후를 가릅니다
저는 한 시간 만에 Tldraw SDK 데모를 만들어 팀 앞에서 보여줬습니다. "Figma로 가자"는 쪽과 "커스텀이 필요하다"는 쪽이 팽팽하게 맞서던 상황에서, 직접 동작하는 프로토타입을 보여주는 것이 말보다 훨씬 빠른 합의 방법이었습니다. 그 이후 6주 안에 클라이언트 전용 화이트보드 앱을 출시했습니다.
하지만 솔직히 이건 예상 밖이었습니다. 출시 자체보다 출시 이후가 훨씬 까다로웠습니다. Tldraw는 CRDT(Conflict-free Replicated Data Type) 기반 상태 동기화 구조를 사용합니다. 여기서 CRDT란 여러 사용자가 동시에 데이터를 수정하더라도 충돌 없이 최종 상태를 자동으로 병합해주는 분산 데이터 구조입니다. 이 덕분에 동기화 성능이 뛰어나지만, 그 동기화 서버를 운영하는 책임은 전적으로 개발사가 집니다.
그래서 저는 외주 계약 전에 반드시 운영 책임 분담 매트릭스를 작성합니다. 이 매트릭스는 개발자 측과 클라이언트 측이 각각 어떤 운영 항목을 담당하는지 명시한 표로, 나중에 생길 수 있는 책임 분쟁을 예방하는 가장 현실적인 방법입니다. 실제로 이 문서를 먼저 작성하고 계약한 외주 2건에서는 출시 후 분쟁이 없었습니다.
협업 도구 개발에서 운영 문서 표준화의 중요성은 업계에서도 지속적으로 강조되고 있습니다. 특히 소규모 팀이 SDK 기반 협업 도구를 직접 운영할 때는 초기 설계 단계에서 운영 범위를 명확히 정의하지 않으면 유지보수 비용이 급격히 증가한다는 점이 지적됩니다(출처: GitHub Open Source Survey).
동기화 모니터링, 분기마다 이렇게 측정하고 있습니다
30명 동시 사용자 환경에서 동기화 지연 80ms를 달성했습니다. 이 수치가 어느 정도 의미 있는지 감이 잘 안 오실 수 있는데, 일반적으로 실시간 협업 도구에서 동기화 지연(Sync Latency)이 100ms 이하면 사용자가 거의 지연을 인식하지 못하는 수준입니다. 여기서 동기화 지연이란 한 사용자의 편집 행위가 다른 사용자 화면에 반영되기까지 걸리는 시간을 의미합니다. 이 수치가 200ms를 넘어가면 체감 지연이 발생하고, 협업 흐름이 끊기는 느낌이 납니다.
제가 현재 분기마다 측정하는 항목은 다음과 같습니다.
- 동시 사용자 수 구간별(10명/20명/30명) 동기화 지연 평균
- 커스텀 셰이프 라이브러리 갱신 항목 및 적용 현황
- 사용자 만족도 설문 결과 요약
이 세 가지를 묶어서 클라이언트에게 분기 보고서로 공유합니다. 단순히 "잘 돌아가고 있습니다"라는 말 대신 수치로 증명하는 방식인데, 클라이언트 입장에서 신뢰도가 확연히 달라집니다.
실시간 협업 도구의 성능 지표와 관련해, 사용자 경험(UX) 측면에서 응답 속도가 생산성에 미치는 영향은 이미 여러 연구를 통해 검증된 바 있습니다(출처: Nielsen Norman Group).
분기 거버넌스를 이렇게 라이브러리 갱신, 사용자 만족도 측정, 클라이언트 정기 보고 세 가지로 묶어 운영하면, Tldraw SDK 도입이 단순한 도구 교체가 아니라 지속 가능한 디자인 자산으로 자리 잡습니다. 제 경험상 이 루틴을 갖추지 않으면 분기가 지날수록 라이브러리가 방치되고, 클라이언트와의 관계도 점점 느슨해집니다.
Tldraw SDK는 자유도가 높은 만큼 운영 준비가 갖춰진 팀에게 강력한 도구입니다. 도입을 고민 중이라면 기술 스펙보다 운영 범위를 먼저 정의하는 것, 그것이 출시 후를 가르는 핵심이라고 생각합니다. 사전 체크리스트와 책임 분담 매트릭스를 먼저 작성해 보시는 것을 권합니다. 도구는 그다음입니다.