실시간 협업 엔진 & 싱크 2026 완벽 가이드 - Liveblocks · PartyKit · Yjs · Automerge · ElectricSQL · Replicache · Zero (Rocicorp) · Convex · Triplit · Jazz.tools · Loro 심층 분석

"10년 안에 모든 소프트웨어는 멀티플레이어가 될 것이다. 단일 사용자 앱은 화석이 될 것이다." — Martin Kleppmann, "Local-first software" (Ink & Switch, 2019)

Figma에서 동료의 커서가 흐르고, Notion 페이지의 글자가 동시에 차오르고, Linear 이슈가 새로 고침 없이 실시간으로 업데이트되는 경험은 2020년만 해도 "프리미엄 SaaS의 차별점"이었습니다. 2026년 현재, 이 멀티플레이어 UX는 모든 신규 B2B SaaS의 기본 요구사항이 되었고, "Figma 수준의 협업이 안 되면 안 팔린다"는 명제는 더 이상 농담이 아닙니다.

이 변화의 배후에는 CRDT(Conflict-free Replicated Data Type) 라는 30년 된 컴퓨터 과학 이론이 마침내 프로덕션에서 작동하기 시작한 사건, 그리고 그것을 SaaS로 포장한 Liveblocks · PartyKit · Convex 같은 신생 플랫폼의 부상이 있습니다. 동시에 Replicache 창업자 Aaron Boodman이 만든 Zero(2024년 후반 출시)는 "Postgres를 그대로 두고 클라이언트가 IndexedDB로 동기화"하는 새 패러다임을 제시했고, ElectricSQL · PowerSync · Triplit · Jazz.tools 같은 로컬 우선(Local-first) 진영도 폭발적으로 성장했습니다.

이 글은 2026년 5월 기준으로 실시간 협업 & 싱크 생태계 전체를 한 글에 정리합니다. Yjs · Automerge · Loro 같은 CRDT 코어 라이브러리부터, Liveblocks · PartyKit · Ably 같은 호스티드 SaaS, Replicache · Zero · ElectricSQL · Convex 같은 로컬 우선 엔진, tldraw · Excalidraw · Notion 같은 실전 적용 사례, 그리고 토스 · Naver Whale · Cybozu · Sansan 같은 한·일 사례까지 망라합니다.

1. 2026년 실시간 협업 지도 — 5개 카테고리로 나누기

실시간 협업 스택을 이해하는 가장 좋은 방법은 다섯 개 레이어로 분해하는 것입니다.

각 레이어는 독립적으로 선택할 수 있고, 한 제품이 여러 레이어를 묶어 제공하기도 합니다. Liveblocks는 Transport + CRDT(Yjs 위에 빌드) + Hosted SaaS + Application Pattern을 모두 묶어 팝니다. 반면 Yjs는 CRDT 코어만, PartyKit은 Transport + Hosted SaaS만, ElectricSQL은 Sync Engine만 제공합니다.

선택의 첫 분기점은 "내가 직접 운영할 의지가 있는가, 있으면 어디까지인가" 입니다. SaaS에 모두 맡기면 Liveblocks, 부분 자체 운영이면 Yjs + 자체 서버, 데이터 주권이 중요하면 Yjs + y-websocket 풀스택, 완전 로컬 우선이면 Automerge + Automerge-repo.

2. CRDT 기초 — Yjs, Automerge, Loro, Diamond Types

CRDT(Conflict-free Replicated Data Type)는 1980년대부터 분산 시스템 학계에서 연구되어온 자료 구조로, "여러 노드에서 동시에 편집해도 결국 같은 상태로 수렴(eventually consistent)" 하는 수학적 보장을 제공합니다. 두 큰 패밀리가 있습니다.

• State-based CRDT (CvRDT) — 노드들이 전체 상태를 주고받으며 병합(merge)합니다. 단순하지만 대역폭을 많이 씁니다.
• Operation-based CRDT (CmRDT) — 노드들이 연산(insert, delete) 자체를 전파합니다. 효율적이지만 신뢰성 있는 메시지 큐가 필요합니다.

Yjs(Kevin Jahns, 2015년 ~)는 가장 널리 쓰이는 CRDT 라이브러리입니다. YATA(Yet Another Transformation Approach) 알고리즘 기반으로, Operation-based + 효율적인 binary encoding(y-protocols)을 결합해 대형 문서에서도 빠르게 작동합니다. tldraw, Excalidraw, JupyterLab, Hocuspocus, Liveblocks가 모두 Yjs 위에 빌드되어 있습니다.

import * as Y from 'yjs'

const doc = new Y.Doc()

// Y.Text — 협업 텍스트 자료형
const yText = doc.getText('content')
yText.insert(0, 'Hello ')
yText.insert(6, 'world!')
console.log(yText.toString())  // "Hello world!"

// Y.Map / Y.Array — 협업 객체/리스트
const yMap = doc.getMap('user')
yMap.set('name', 'Alice')
yMap.set('cursor', { x: 10, y: 20 })

// 상태 동기화 — binary update vector
const update = Y.encodeStateAsUpdate(doc)
const doc2 = new Y.Doc()
Y.applyUpdate(doc2, update)
console.log(doc2.getText('content').toString())  // "Hello world!"

// 관측 — 변경 이벤트 구독
yText.observe((event) => {
  console.log('Text changed:', event.changes.delta)
})

Automerge(Martin Kleppmann + Ink & Switch, 2017년 ~)는 "JSON CRDT"로 시작했고, 2022년 발표된 Automerge 2는 Rust 코어 + WebAssembly 바인딩으로 재작성되어 100배 빠른 성능을 달성했습니다. 2024년 출시된 Automerge-repo는 동기화 프로토콜·저장소·네트워크 어댑터까지 묶은 풀스택 라이브러리입니다.

import * as Automerge from '@automerge/automerge'
import { Repo } from '@automerge/automerge-repo'
import { BrowserWebSocketClientAdapter } from '@automerge/automerge-repo-network-websocket'
import { IndexedDBStorageAdapter } from '@automerge/automerge-repo-storage-indexeddb'

const repo = new Repo({
  network: [new BrowserWebSocketClientAdapter('wss://sync.example.com')],
  storage: new IndexedDBStorageAdapter('my-app'),
})

interface Doc {
  title: string
  items: { id: string; text: string; done: boolean }[]
}

const handle = repo.create<Doc>({ title: 'My Tasks', items: [] })

handle.change((doc) => {
  doc.items.push({ id: 'a1', text: 'Buy milk', done: false })
})

// 다른 클라이언트의 변경도 자동으로 머지됩니다
handle.on('change', ({ doc }) => {
  console.log('Updated:', doc)
})

Loro(2023년 ~ , Rust 작성)는 Automerge보다 더 작은 wire format과 시간 여행(Time Travel) 을 1급으로 지원합니다. 모든 편집 이력이 효율적으로 보존되어 "10분 전 상태로 되돌리기"가 O(편집 수)가 아니라 O(log n)에 가깝게 동작합니다.

Diamond Types(Seph Gentle, 2022년 ~)는 텍스트 전용 CRDT로, "텍스트 CRDT의 메모리·CPU 오버헤드를 1배 미만으로"를 목표로 합니다. JS에서 Yjs와 비교 벤치마크에서 우위를 보이지만, Yjs의 거대한 생태계 때문에 채택률은 낮습니다.

Y-Sweet(Drifting in Space, 2023년 ~ )는 Yjs를 SaaS로 호스팅한 서비스로, 자체 호스팅 가능한 Rust 서버(y-sweet)를 함께 오픈소스화했습니다. Liveblocks의 경쟁자라기보다 "Yjs를 자체 운영하고 싶지만 서버는 관리하기 싫은" 팀을 타깃합니다.

3. CRDT vs OT vs Last-Write-Wins — 충돌 해결 전략

협업 자료 구조의 충돌 해결은 크게 네 가지 전략이 있습니다.

OT(Operational Transform) 는 1989년 Sun에서 처음 발표되어 Google Docs(2006), Microsoft Office Live가 채택한 전통적 방식입니다. 핵심은 "사용자 A가 인덱스 5에 'x'를 삽입했고, 동시에 사용자 B가 인덱스 3에 'y'를 삽입했다면, B의 연산이 도착했을 때 A의 인덱스 5를 6으로 변환(transform)한다"는 것입니다. 직관적이지만 중앙 서버(authority) 가 필수이고, 100명 이상 동시 편집에서 transform matrix가 폭발하는 한계가 있습니다.

CRDT 는 수학적으로 "모든 연산 쌍이 commutative(교환 가능)" 하도록 설계해 transform 없이 합쳐도 결국 같은 결과가 나오게 합니다. 분산 환경(P2P, 오프라인 우선)에 강하지만, 메타데이터 오버헤드(각 연산마다 UUID + lamport clock)가 크고, 위키피디아처럼 "삭제된 콘텐츠도 영구히 보존(tombstone)" 해야 하므로 메모리가 늘어납니다. Yjs · Automerge · Loro는 이 오버헤드를 줄이는 알고리즘 최적화에 집중합니다.

LWW(Last-Write-Wins) 는 가장 단순한 전략입니다. 타임스탬프가 늦은 쪽이 이깁니다. 충돌 가능성이 적은 도메인(예: 사용자 프로필 마지막 업데이트 시간)에는 잘 맞지만, 동시 편집 텍스트에는 데이터 손실이 발생합니다.

Application-level Merge 는 Git이 대표적입니다. 충돌이 생기면 사람이 푸는 모델. Jira·Asana 같은 비즈니스 앱도 본질적으로 이 방식이며, 일정 수준의 충돌이 있어도 도메인 로직(예: "더 늦은 댓글이 위로")으로 해결합니다.

선택 기준: 텍스트 동시 편집은 CRDT 또는 OT, 일정 관리·이슈 트래커는 Application-level, 단순 동기화는 LWW. Figma는 CRDT, Google Docs는 OT, Linear는 LWW + 도메인 머지 조합입니다.

4. Liveblocks — 멀티플레이어 SaaS의 리더

Liveblocks(liveblocks.io)는 2021년 프랑스에서 창업, 2024년 시리즈 A를 받은 회사로, 2026년 현재 멀티플레이어 SaaS 카테고리의 명실상부한 1위입니다. Notion 출신 엔지니어들이 만들어 "Notion이 자체 구축한 것을 SaaS로"라는 포지셔닝입니다.

핵심 가치는 React + Yjs 통합의 마찰 제거입니다. Yjs를 직접 쓰려면 y-websocket 서버를 운영하고, awareness 프로토콜을 구현하고, presence를 관리해야 하는데, Liveblocks는 이걸 모두 SDK 한 줄로 끝냅니다.

// React 멀티플레이어 컴포넌트 — Liveblocks
import { RoomProvider, useOthers, useUpdateMyPresence } from '@/liveblocks.config'
import { LiveblocksProvider } from '@liveblocks/react'

function App() {
  return (
    <LiveblocksProvider authEndpoint="/api/liveblocks-auth">
      <RoomProvider id="my-room" initialPresence={{ cursor: null }}>
        <CursorTracker />
        <OnlineUsers />
      </RoomProvider>
    </LiveblocksProvider>
  )
}

function CursorTracker() {
  const updateMyPresence = useUpdateMyPresence()
  return (
    <div
      onPointerMove={(e) => updateMyPresence({ cursor: { x: e.clientX, y: e.clientY } })}
      onPointerLeave={() => updateMyPresence({ cursor: null })}
      style={{ width: '100vw', height: '100vh' }}
    />
  )
}

function OnlineUsers() {
  const others = useOthers()
  return (
    <div>
      {others.length} 명이 함께 보고 있습니다
      {others.map(({ connectionId, presence }) => (
        presence.cursor && (
          <Cursor
            key={connectionId}
            x={presence.cursor.x}
            y={presence.cursor.y}
          />
        )
      ))}
    </div>
  )
}

Liveblocks는 2024년에 Comments(스레드형 댓글), 2025년에 Notifications(인앱 알림 + 이메일), 그리고 2025년 후반에 Liveblocks AI Copilots(AI 편집자가 협업자처럼 참여)를 추가했습니다. 가격은 월 활성 사용자(MAU) 단위로 시작 무료, 100 MAU부터 유료입니다.

오픈소스 대안은 Hocuspocus(tiptap.dev/hocuspocus)로, Yjs용 자체 호스팅 가능한 Node.js 서버입니다. TipTap 에디터를 만든 팀이 운영하며, Liveblocks의 코어 기능(persistence, auth, webhook)을 무료로 제공합니다.

5. PartyKit (Cloudflare 인수) — Durable Objects 기반

PartyKit(partykit.io)은 React 코어팀 출신 Sunil Pai가 2023년 창업했고, 2024년 4월 Cloudflare에 인수되었습니다. 2026년 현재 PartyKit은 Cloudflare Workers + Durable Objects 위에 빌드된 "프로그래밍 가능한 멀티플레이어 인프라"입니다.

Liveblocks가 "준비된 빌딩 블록"이라면 PartyKit은 "프로그래밍 가능한 캔버스"입니다. 각 "party"는 Durable Object 한 개이며, 사용자는 그 안에서 임의의 TypeScript 코드를 실행할 수 있습니다. 챗봇, 화이트보드, 게임 룸 등 임의의 stateful realtime 워크로드를 한 곳에 모을 수 있습니다.

// PartyKit 서버 — 단일 파일
import type * as Party from 'partykit/server'

export default class ChatServer implements Party.Server {
  constructor(readonly room: Party.Room) {}

  // 클라이언트가 연결될 때
  async onConnect(conn: Party.Connection, ctx: Party.ConnectionContext) {
    // 최근 메시지 100개 로딩 (Durable Object 내장 스토리지)
    const messages = (await this.room.storage.get<string[]>('messages')) ?? []
    conn.send(JSON.stringify({ type: 'history', messages }))
  }

  // 메시지 수신
  async onMessage(message: string, sender: Party.Connection) {
    const messages = (await this.room.storage.get<string[]>('messages')) ?? []
    messages.push(message)
    if (messages.length > 100) messages.shift()
    await this.room.storage.put('messages', messages)

    // 룸 내 모든 연결에 브로드캐스트
    this.room.broadcast(message, [sender.id])  // sender는 제외
  }
}

// 클라이언트
import PartySocket from 'partysocket'

const socket = new PartySocket({
  host: 'my-app.username.partykit.dev',
  room: 'lobby',
})
socket.addEventListener('message', (e) => console.log(e.data))
socket.send('Hello world!')

Cloudflare 인수 후 PartyKit은 Cloudflare의 전 세계 300+ 지역 데이터 센터에서 자동으로 실행되며, 에지에 가까운 곳에서 실행되는 Durable Object 라는 차별점이 더 명확해졌습니다. 2025년부터 PartyKit 코드는 Cloudflare Workers 코드와 호환되어, 별도 PartyKit 계정 없이 Cloudflare 대시보드에서 통합 관리할 수 있게 되었습니다.

PartyKit의 강점은 유연성, 약점은 빌딩 블록의 부족입니다. Liveblocks의 Comments·Notifications 같은 high-level 기능은 직접 구현해야 합니다.

6. Yjs 생태계 — y-websocket, y-protocols, awareness

Yjs는 라이브러리 자체뿐만 아니라 그 주변의 transport adapter, persistence adapter, awareness 프로토콜 생태계가 거대합니다.

y-websocket은 표준 transport 어댑터입니다. Node.js 기반 서버(y-websocket-server)와 브라우저 클라이언트(y-websocket)가 한 쌍을 이루며, WebSocket 위에 Yjs 업데이트를 효율적으로 전송합니다.

// 클라이언트
import * as Y from 'yjs'
import { WebsocketProvider } from 'y-websocket'

const ydoc = new Y.Doc()
const provider = new WebsocketProvider('wss://demos.yjs.dev', 'my-room', ydoc)

// awareness — 커서, 선택 영역, 사용자 색상
provider.awareness.setLocalStateField('user', {
  name: 'Alice',
  color: '#ff0000',
  cursor: { x: 10, y: 20 },
})

provider.awareness.on('change', (changes) => {
  for (const [clientId, state] of provider.awareness.getStates()) {
    console.log(clientId, state.user)
  }
})

y-indexeddb는 브라우저 로컬 저장소 어댑터. 오프라인에서도 편집한 내용을 IndexedDB에 보관했다가 온라인 복귀 시 동기화합니다.

y-protocols는 sync(상태 동기화), awareness(presence), auth(인증) 세 가지 wire protocol을 정의한 표준 패키지입니다.

y-monaco / y-prosemirror / y-codemirror.next 같은 에디터 바인딩이 풍부하게 존재합니다. tldraw가 Yjs를 채택한 이유는 다른 CRDT와 비교 불가능한 에디터 통합 생태계 때문입니다.

Hocuspocus(2022년 ~ )는 TipTap 팀이 만든 Yjs용 풀스택 서버로, persistence, webhook, auth, scaling을 한 번에 제공합니다. 자체 호스팅 가능하고 Postgres·Redis 백엔드를 지원하며, 2025년부터 Hocuspocus Cloud 호스티드 서비스도 출시되었습니다.

7. Replicache — 클라이언트 우선 동기화의 원조

Replicache(replicache.dev)는 Rocicorp(Aaron Boodman, 전 Roam·전 Google)가 2020년 출시한 클라이언트 우선 동기화 엔진입니다. Linear, Loom, Sentry, Productboard, Coalesce 등이 채택했습니다.

Replicache의 모델은 다음과 같습니다.

1. 클라이언트는 IndexedDB에 자체 데이터 사본을 가짐
2. 사용자 액션은 mutation(JS 함수)으로 정의되어 로컬에 즉시 적용
3. mutation은 백엔드의 같은 이름 핸들러로도 전달
4. 백엔드는 글로벌 진실(source of truth)을 업데이트하고 새로운 pull response를 만들어 클라이언트에 푸시
5. 클라이언트가 pull response를 적용하면 로컬 optimistic mutation은 폐기되고 서버 상태로 대체

// Replicache 클라이언트 설정
import { Replicache } from 'replicache'

type M = typeof mutators
const mutators = {
  async createTask(tx, args: { id: string; text: string }) {
    await tx.set(`task/${args.id}`, { text: args.text, done: false })
  },
  async toggleTask(tx, args: { id: string }) {
    const t = await tx.get<{ text: string; done: boolean }>(`task/${args.id}`)
    if (t) await tx.set(`task/${args.id}`, { ...t, done: !t.done })
  },
}

const rep = new Replicache<M>({
  licenseKey: process.env.NEXT_PUBLIC_REPLICACHE_LICENSE_KEY!,
  name: 'user-alice',
  pushURL: '/api/replicache/push',
  pullURL: '/api/replicache/pull',
  mutators,
})

// UI에서 호출 — 즉시 로컬 적용, 백그라운드에서 서버 동기화
await rep.mutate.createTask({ id: 'a1', text: 'Buy milk' })

// 반응형 쿼리
const tasks = rep.subscribe(
  async (tx) => {
    const entries = await tx.scan({ prefix: 'task/' }).entries().toArray()
    return entries.map(([k, v]) => ({ key: k, ...v }))
  },
  (tasks) => render(tasks)
)

Replicache는 데이터 모델을 강제하지 않습니다. KV 스토어 위에 임의의 자료 구조를 올릴 수 있고, mutation은 임의의 JS 함수이므로 모든 도메인에 맞춰 쓸 수 있습니다. 대신 서버 측 구현 부담이 큽니다. push endpoint와 pull endpoint를 직접 작성해야 하고, mutation을 SQL로 재구현해야 합니다.

가격은 MAU 단위로, 1,000 MAU까지 무료, 그 이상은 월 $1/MAU. 2024년부터 Rocicorp는 Replicache의 후속작 Zero 개발에 집중하기 시작했고, 신규 채택은 Zero로 권장합니다.

8. Zero (Rocicorp 2024) — 차세대 싱크 엔진

Zero(zero.rocicorp.dev)는 Replicache 창업자 Aaron Boodman이 2024년 11월에 발표한 차세대 싱크 엔진입니다. 핵심 아이디어는 "Replicache의 KV 모델을 버리고 관계형 쿼리 를 1급으로 지원"하는 것입니다.

Zero의 모델:

1. 백엔드는 보통의 Postgres
2. 클라이언트는 SQLite(또는 IndexedDB 기반 WASM SQLite)로 자체 사본 보관
3. 사용자가 z.query.issues.where('status', 'open').orderBy('updatedAt', 'desc').limit(10) 같은 쿼리를 작성
4. Zero는 쿼리에 영향을 줄 수 있는 데이터만 클라이언트로 동기화 (rolling subscription)
5. 쿼리는 IndexedDB에서 즉시 실행되어 zero latency 응답
6. 백엔드 변경은 WebSocket으로 푸시되어 자동으로 쿼리 결과 갱신

// Zero 사용 예 — Linear-style 이슈 트래커
import { Zero } from '@rocicorp/zero'
import { useQuery } from '@rocicorp/zero/react'

const z = new Zero({
  userID: currentUser.id,
  server: 'wss://zero.example.com',
  schema: mySchema,  // Postgres에서 자동 추출 가능
  kvStore: 'idb',
})

function IssueList() {
  const [issues] = useQuery(
    z.query.issues
      .where('status', '=', 'open')
      .related('assignee')
      .related('comments', (q) => q.orderBy('createdAt', 'desc'))
      .orderBy('priority', 'desc')
      .limit(50)
  )

  return (
    <ul>
      {issues.map((issue) => (
        <li key={issue.id}>
          {issue.title} - {issue.assignee?.name}
          <span>{issue.comments.length} comments</span>
        </li>
      ))}
    </ul>
  )
}

// 변형은 자동 optimistic — UI가 0ms에 업데이트되고 백그라운드에서 서버에 동기화
await z.mutate.issues.update({ id: 'iss_1', status: 'closed' })

Zero가 Replicache 대비 가져온 가장 큰 변화는 읽기 모델의 변화입니다. Replicache는 KV scan을 직접 작성해야 했지만, Zero는 ORM 같은 쿼리 빌더로 SQL과 비슷한 표현력을 제공합니다. JOIN과 nested relation도 지원하므로 Linear 같은 복잡한 도메인에서 훨씬 자연스럽습니다.

2025년 7월 Zero가 안정 버전을 발표했고, 2026년 현재 Linear가 자사 코어 동기화 엔진을 Replicache에서 Zero로 마이그레이션하는 중입니다(Linear 공식 블로그 2025-12 포스트 참고).

9. ElectricSQL — Postgres + SQLite 양방향 동기화

ElectricSQL(electric-sql.com)은 2022년 영국에서 창업한 회사로, "Postgres와 클라이언트 SQLite를 양방향 동기화"라는 명료한 미션을 가지고 있습니다. 2024년 후반에 큰 피벗 을 했는데, 기존의 CRDT 기반 접근을 버리고 Phoenix LiveView 스타일의 서버 권위(authority) + shape-based subscription 으로 재설계했습니다.

새 ElectricSQL 모델:

1. 백엔드는 Postgres + Electric sync service (Elixir로 작성)
2. 클라이언트는 PGlite(브라우저용 WASM Postgres) 또는 SQLite를 자체 사본으로 사용
3. 클라이언트가 shape(예: "내 회사의 직원 중 active=true 인 사람들")를 구독
4. Postgres logical replication 기반으로 shape에 영향을 주는 변경만 클라이언트에 푸시
5. 쓰기는 일반 HTTP API로 보내고, Postgres 트랜잭션이 커밋되면 자동 전파

import { Electric, electrify } from 'electric-sql/browser'
import { schema } from './generated/client'

// PGlite 또는 wa-sqlite를 자체 클라이언트 DB로
const electric = await electrify(database, schema, {
  url: 'wss://electric.example.com',
})

// shape 구독 — 회사 ID의 active 직원만
const shape = await electric.sync.subscribe({
  table: 'employees',
  where: 'company_id = $1 AND status = $2',
  bindings: [currentUser.companyId, 'active'],
  include: { manager: true },  // FK 자동 따라가기
})

await shape.synced

// 일반 SQL로 클라이언트 사본 조회 — 모두 IndexedDB에서 즉시
const employees = await electric.db.employees.findMany({
  where: { department: 'Engineering' },
})

// 변경은 HTTP POST — 백엔드 Postgres에 트랜잭션으로 적용
await fetch('/api/employees', {
  method: 'POST',
  body: JSON.stringify({ name: 'Alice', department: 'Engineering' }),
})
// 변경된 데이터는 자동으로 모든 구독자에게 전파

ElectricSQL의 강점은 Postgres를 그대로 둔다는 것입니다. 기존 Rails·Django·Next.js 백엔드를 거의 변경 없이 사용 가능하고, ORM도 그대로 씁니다. 약점은 새 모델에서는 클라이언트에서 직접 쓰기를 못 한다는 것(서버 권위 모델)으로, optimistic update를 원하면 별도 패턴(예: TanStack Query의 useMutation + onMutate)을 써야 합니다.

2025년부터 Vercel · Supabase · Neon 같은 Postgres 호스팅 업체와 통합을 강화해, Vercel Postgres + ElectricSQL 조합으로 별도 인프라 없이 로컬 우선 앱을 만들 수 있게 되었습니다.

10. PowerSync — 모바일 우선 동기화

PowerSync(powersync.com)는 2023년 출시된 동기화 엔진으로, 모바일 앱(iOS/Android/React Native/Flutter) 을 1급 타깃합니다. 백엔드는 Postgres·Supabase·Firebase 셋 다 지원합니다.

PowerSync의 모델은 ElectricSQL과 비슷하지만 모바일 SQLite를 1급으로 지원하고, bucket-based partitioning 으로 한 사용자가 봐야 할 데이터만 동기화합니다.

// React Native + PowerSync
import { PowerSyncDatabase } from '@powersync/react-native'
import { SupabaseConnector } from './supabase-connector'

const db = new PowerSyncDatabase({
  schema: AppSchema,
  database: { dbFilename: 'app.db' },
})

await db.connect(new SupabaseConnector())

// 데이터 조회 — 항상 로컬 SQLite, 즉시 응답
const issues = await db.getAll(
  'SELECT * FROM issues WHERE assignee = ? ORDER BY priority DESC',
  [currentUser.id]
)

// 변경 — 로컬에 즉시 적용, 백그라운드에서 Supabase로 푸시
await db.execute(
  'UPDATE issues SET status = ? WHERE id = ?',
  ['closed', 'iss_1']
)

PowerSync는 오프라인 우선(Offline-first) 시나리오에 강합니다. 지하철 안, 비행기 안, 산골짜기에서도 앱이 즉시 작동하고, 네트워크 복귀 시 자동 동기화. Field service · 의료 현장 · 농업 같은 오프라인 비중이 높은 B2B 모바일 앱에서 채택률이 높습니다.

2025년부터 PowerSync는 React/Next.js 같은 웹 환경도 지원하기 시작해, ElectricSQL과 직접 경쟁합니다.

11. Convex — 백엔드 전체를 묶은 reactive 풀스택

Convex(convex.dev)는 2021년 창업, 2024년 시리즈 B를 받은 회사로, "데이터베이스 + 함수 + 동기화를 한 묶음으로" 제공하는 풀스택 백엔드입니다. Firebase의 후속 세대로 자주 비유됩니다.

Convex의 차별점은 모든 쿼리가 자동으로 reactive 라는 것입니다. 클라이언트가 useQuery(api.tasks.list) 를 호출하면, 그 쿼리에 영향을 주는 mutation이 발생할 때마다 자동으로 재실행되어 UI가 업데이트됩니다.

// Convex — 서버 함수 정의
// convex/tasks.ts
import { query, mutation } from './_generated/server'
import { v } from 'convex/values'

export const list = query({
  args: { ownerId: v.id('users') },
  handler: async (ctx, args) => {
    return await ctx.db
      .query('tasks')
      .withIndex('by_owner', (q) => q.eq('ownerId', args.ownerId))
      .order('desc')
      .collect()
  },
})

export const create = mutation({
  args: { text: v.string() },
  handler: async (ctx, args) => {
    const userId = (await ctx.auth.getUserIdentity())!.subject as Id<'users'>
    return await ctx.db.insert('tasks', {
      text: args.text,
      ownerId: userId,
      done: false,
    })
  },
})

// Convex — 클라이언트 (React)
import { useQuery, useMutation } from 'convex/react'
import { api } from '../convex/_generated/api'

function TaskList() {
  const tasks = useQuery(api.tasks.list, { ownerId: currentUser._id })
  const createTask = useMutation(api.tasks.create)

  // 다른 사용자가 task를 추가하면 자동으로 다시 렌더링됨
  return (
    <div>
      <button onClick={() => createTask({ text: 'New task' })}>Add</button>
      {tasks?.map((t) => <div key={t._id}>{t.text}</div>)}
    </div>
  )
}

Convex의 강점은 마법 같은 DX입니다. WebSocket·subscription·invalidation을 직접 다루지 않아도 모든 쿼리가 자동으로 reactive. 데이터베이스, 함수, 파일 저장소(ctx.storage), 스케줄(ctx.scheduler), 외부 액션(ctx.runAction)이 모두 한 SDK에 묶여 있습니다.

약점은 벤더 종속과 온프레미스 불가(2026년 5월 기준). 다만 2025년 출시된 self-hosted Convex 베타가 일부 엔터프라이즈 고객에 한해 제공되기 시작했습니다.

12. Triplit — TypeScript-first 풀스택 sync

Triplit(triplit.dev)은 2023년 창업한 회사로, "End-to-end TypeScript 타입 안전성 + 로컬 우선 동기화"를 목표로 합니다. Convex보다 더 작고 단순한 API이며, 오픈소스(triplit-io/triplit)입니다.

import { TriplitClient, Schema as S } from '@triplit/client'

const schema = {
  collections: {
    todos: {
      schema: S.Schema({
        id: S.Id(),
        text: S.String(),
        completed: S.Boolean({ default: false }),
        createdAt: S.Date({ default: S.Default.now() }),
      }),
    },
  },
}

const client = new TriplitClient({
  serverUrl: 'https://triplit.example.com',
  schema,
})

// 쿼리 — 결과는 로컬에서 즉시, 서버 변경은 자동 푸시
const subscription = client.subscribe(
  client.query('todos').where('completed', '=', false).order('createdAt', 'DESC'),
  (results) => render(results)
)

// 트랜잭션 — optimistic + 자동 충돌 해결
await client.transact(async (tx) => {
  await tx.insert('todos', { text: 'Buy milk' })
})

Triplit의 강점은 schema-first 접근과 풀스택 타입 추론입니다. 서버 함수가 따로 없고, 권한 규칙(read/write/delete)을 schema 위에 선언적으로 정의합니다.

13. Jazz.tools — 분산 상태 프레임워크

Jazz.tools(jazz.tools)는 2023년 창업한 회사로, "Distributed state framework"이라는 독특한 포지셔닝입니다. 데이터베이스가 아니라 CRDT 객체를 클라이언트들끼리 P2P 또는 cloud sync로 공유하는 모델입니다.

import { co, CoMap, CoList } from 'jazz-tools'

class Task extends CoMap {
  text = co.string
  done = co.boolean
}

class TaskList extends CoList.Of(co.ref(Task)) {}

// 새 task list 생성 (CRDT 객체)
const list = TaskList.create([], { owner: me })

// 다른 사용자와 공유 (URL로)
const shareUrl = list.id
console.log(`Share: https://app.example.com/list/${shareUrl}`)

// 변경 — 모든 구독자에게 자동 전파
list.push(Task.create({ text: 'Buy milk', done: false }, { owner: me }))

Jazz.tools의 강점은 E2E 암호화 + P2P 옵션입니다. 모든 데이터가 클라이언트에서 암호화되어 서버는 암호문만 본다는 보안 모델을 제공합니다.

14. InstantDB, Evolu, Vlcn — 신생 진영

InstantDB(instantdb.com, 2023년 ~)는 Relay/Firebase 영감의 GraphQL-like 클라이언트 우선 DB입니다. 쿼리 결과가 자동으로 reactive하고, 트랜잭션이 optimistic. 2025년에 시리즈 A를 받았습니다.

Evolu(evolu.dev, 2024년 ~ )는 로컬 우선 + 종단간 암호화 를 핵심 가치로 둡니다. SQLite를 클라이언트에 두고 변경 사항만 암호화해 서버에 동기화. 비밀번호 같은 민감 정보를 다루는 앱에 적합합니다.

Vlcn / cr-sqlite(2023년 ~ )은 SQLite를 CRDT로 확장한 native extension 입니다. 일반 SQL을 그대로 쓰면서도 동기화·머지가 자동으로 작동합니다. Tantaman(Matt Wonlaw)이 만들었으며, Discord에서 일부 사용됩니다.

15. WebSocket vs WebRTC vs SSE vs WebTransport

협업의 transport 선택은 네 가지 옵션이 있습니다.

WebSocket은 사실상 표준입니다. 모든 브라우저가 지원하고, Node.js·Go·Rust·Python 모두 라이브러리가 풍부합니다. Liveblocks, PartyKit, Yjs, Convex가 모두 WebSocket을 씁니다. 한계는 한 연결 안에 메시지 큐가 하나라 head-of-line blocking이 발생한다는 점.

WebTransport는 HTTP/3(QUIC) 위에 빌드된 다중화 transport입니다. Chrome·Edge·Firefox는 2024년부터 지원, Safari는 2026년 베타에서 추가되었습니다. 한 연결 안에서 여러 stream을 동시에 보낼 수 있어 head-of-line blocking이 없습니다. 다만 백엔드 지원이 아직 부족(Go의 quic-go, Cloudflare Workers 정도).

WebRTC DataChannel은 P2P 직접 연결로, 서버를 거치지 않고 초저지연 메시지를 주고받을 수 있습니다. 단점은 NAT traversal(STUN/TURN 서버), signaling 채널이 별도로 필요하다는 것. Figma 멀티커서가 일부 WebRTC DataChannel을 활용한다고 알려져 있습니다.

SSE(Server-Sent Events) 는 HTTP 위 단방향 push로, 가장 간단합니다. ChatGPT 같은 LLM 스트리밍, 알림 전파에 자주 쓰이지만, 양방향 협업에는 부족합니다.

선택 기준: 일반 협업은 WebSocket, 초저지연 게임/멀티커서는 WebRTC, AI 스트리밍/알림은 SSE, 미래 지향이라면 WebTransport.

16. Ably / Pusher / Soketi / Centrifugo — 범용 realtime pub/sub

협업 앱에 직접 쓰는 것은 아니지만 backbone으로 자주 쓰이는 범용 realtime pub/sub 서비스들이 있습니다.

Pusher(pusher.com, 2010년 ~ , MessageBird 인수)는 가장 오래된 realtime SaaS로, "Pusher Channels"가 채팅·알림 백본의 사실상 표준이었습니다. 2026년 현재 모던 SaaS의 직접 채택은 줄었지만, 레거시 사용자가 많아 여전히 큰 비즈니스입니다.

Ably(ably.com, 2016년 ~ )는 Pusher의 후속 세대로 글로벌 분산 + 99.999% SLA + 메시지 순서 보장 을 가치 제안으로 합니다. Hubspot, Vercel, Splunk 등이 채택했습니다.

Soketi(soketi.app, 2022년 ~ )는 Pusher 프로토콜 호환 오픈소스 서버입니다. Pusher 코드를 그대로 두고 자체 호스팅으로 전환하고 싶을 때 씁니다. Laravel WebSockets의 후속 프로젝트.

Centrifugo(centrifugal.dev, 러시아 출신 오픈소스, 2016년 ~ )는 Go로 작성된 고성능 realtime 메시징 서버입니다. Avito, VK 같은 러시아 대형 서비스에서 검증된 백본으로, 단일 노드 100만 동시 연결을 처리합니다.

Supabase Realtime(supabase.com/realtime)은 Postgres의 LISTEN/NOTIFY + 자체 broadcast 채널을 결합한 오픈소스 realtime 서비스입니다. Elixir(Phoenix) 기반이라 Erlang OTP의 분산 처리 강점을 살립니다. Postgres와 같은 백엔드에서 협업 기능을 추가하기에 가장 마찰이 적습니다.

17. tldraw / Excalidraw — Yjs 기반 화이트보드 사례

tldraw(tldraw.com)는 Steve Ruiz가 만든 무료 무한 캔버스 화이트보드로, 2024년 시리즈 A를 받았습니다. tldraw의 협업 엔진은 처음에는 자체 구현이었다가, 2023년 후반부터 Yjs로 마이그레이션했습니다. tldraw가 Yjs를 선택한 이유는 자체 블로그 포스트("How tldraw's sync server works", 2024)에서 자세히 설명합니다.

Excalidraw(excalidraw.com)는 Christopher Chedeau(Vjeux, 전 Meta)가 만든 손글씨 스타일 화이트보드로, Excalidraw+ 유료 플랜이 있고, 오픈소스 무료 버전도 같은 협업 엔진을 씁니다. Yjs + y-websocket 표준 조합으로, 자체 호스팅 서버 코드(excalidraw/excalidraw-room)가 공개되어 있습니다.

두 제품 모두 현실 세계에서 Yjs가 작동한다 는 증거이며, 다른 화이트보드 제품(FigJam, Miro, Mural)이 따라가야 할 표준이 되었습니다.

18. Notion / Linear / Figma — 협업 UX의 정점

Notion은 자체 구축한 OT 기반 협업 엔진을 쓰는 것으로 알려져 있습니다(공식 발표는 없음). 2024년 Notion이 Anytype을 따라 Local-first 방향으로 일부 마이그레이션 중이라는 채용 공고가 발견되었습니다.

Linear는 Replicache를 일찍 채택했고, 2025년부터 Zero로 마이그레이션 중입니다. Linear의 즉각적인 UX는 "모든 작업이 로컬 IndexedDB에서 0ms에 실행되고 백그라운드에서 동기화"라는 패러다임의 가장 좋은 사례입니다.

Figma는 자체 구축 CRDT를 쓰며, 2019년 Evan Wallace(공동창업자, 현 Figma CTO 아님)의 "How Figma's multiplayer technology works" 블로그 포스트가 공개되어 있습니다. 핵심은 "각 객체의 각 속성에 LWW + 부모-자식 트리 변형(반드시 한 부모만)을 위한 자체 CRDT"입니다.

19. Code editor 실시간 — VS Code Live Share, Replit, CodeSandbox

VS Code Live Share(Microsoft, 2017년 ~)는 동료의 IDE에 직접 참가해 함께 코드 편집·디버깅 세션을 공유하는 기능입니다. Microsoft의 자체 서비스(Visual Studio Live Share Service)를 통해 작동하며, 무료입니다.

CodeSandbox / CodeSandbox Live(codesandbox.io)는 브라우저 IDE로 시작했고, 2024년 마이크로 VM(Firecracker) 기반 cloud development environments로 피벗했습니다. Live 모드에서 여러 사람이 같은 브라우저 IDE에서 동시 편집합니다.

Replit Multiplayer는 Replit IDE에서 동시 편집 + 음성/비디오 호출까지 제공합니다. 교육용 사용 비중이 높습니다.

CodeTogether(codetogether.com)는 IntelliJ · Eclipse · VS Code 멀티 IDE에서 동시 편집을 가능하게 하는 플러그인 기반 서비스입니다.

20. 게임 상태 동기화 — Colyseus, Photon, Hathora

게임 멀티플레이는 협업과 다른 transport · 일관성 요구사항을 가집니다.

Colyseus(colyseus.io)는 Node.js 기반 멀티플레이어 게임 프레임워크로, 룸 기반 모델 + 자체 schema sync를 제공합니다. .io 게임 · 모바일 게임에서 인기.

Photon Engine(photonengine.com)은 Unity·Unreal 게임 개발에 사실상 표준인 멀티플레이 SaaS입니다. PUN(Photon Unity Networking), Photon Fusion 같은 세대별 SDK가 있습니다.

Hathora(hathora.dev)는 게임 서버 호스팅 + 매치메이킹 SaaS로, 클라우드 게임 서버를 글로벌 분산으로 운영하는 부담을 줄여줍니다.

PlayCanvas Engine(playcanvas.com)은 브라우저 기반 3D 게임 엔진으로, 멀티플레이를 내장 지원합니다.

협업 SaaS와의 차이점은 틱 레이트(60fps 기준 16.67ms 주기) , 클라이언트 사이드 예측(client prediction) + 서버 권위 reconciliation, dead reckoning 같은 게임 특화 패턴입니다.

21. 사례 패턴 — 커서, 댓글, 알림, Activity Feed

실시간 협업 UX는 거의 모두 다음 네 가지 패턴의 조합입니다.

1) Cursors + Presence — "누가 지금 어디를 보고 있는가". Liveblocks Presence, Yjs awareness, PartyKit connection 모두 같은 개념을 다른 이름으로 부릅니다. Cursor 위치, 선택 영역, 사용자 아바타가 핵심 데이터입니다.

// Liveblocks Presence 예
import { useUpdateMyPresence, useOthers } from '@/liveblocks.config'

function CursorLayer() {
  const updateMyPresence = useUpdateMyPresence()
  const others = useOthers()

  return (
    <div
      onPointerMove={(e) => updateMyPresence({ cursor: [e.clientX, e.clientY] })}
    >
      {others.map(({ connectionId, presence }) => (
        presence.cursor && (
          <RemoteCursor key={connectionId} x={presence.cursor[0]} y={presence.cursor[1]} />
        )
      ))}
    </div>
  )
}

2) Live Multiplayer Editing — 동시 텍스트/도형 편집. Yjs · Automerge · OT 같은 CRDT/OT 엔진의 본업.

3) Comments + Threads — 페이지 안의 특정 영역에 댓글 스레드. 어려운 점은 앵커(anchor) 안정성입니다. 사용자가 "Hello world"의 "world"에 댓글을 달았는데, 다른 사람이 "Hello cruel world"로 편집하면 앵커가 어디로 가야 하는가. Yjs는 Y.RelativePosition 으로 이 문제를 해결합니다.

4) Notifications + Activity Feed — "당신을 멘션한 댓글이 달렸습니다", "이슈가 닫혔습니다". Liveblocks Notifications, Knock, Courier 같은 SaaS가 이 영역을 다룹니다.

22. 한국 사례 — 토스 / Naver Whale / Kakao Workspace

토스 워크스페이스(Toss Workspace) — 토스의 내부 협업 도구는 자체 구축으로 알려져 있으며, 실시간 동기화는 Yjs 기반이라고 2024년 토스 SLASH 컨퍼런스에서 일부 공개되었습니다. 특이점은 금융 규제 대응을 위해 모든 협업 이벤트가 5년 감사 로그로 남는다는 것입니다.

Naver Whale 협업 / Naver Office — 네이버 오피스(Naver Docs, Slides)는 OT 기반 자체 협업 엔진을 사용하며, Naver Whale 브라우저 안에서 동작합니다. 2025년 발표된 "Whale Spaces"는 PartyKit과 유사한 임의 도메인의 실시간 협업 컴포넌트를 제공합니다.

Kakao Workspace / Kakao Agit — 카카오의 사내 협업 도구는 자체 구축이며, 자세한 아키텍처는 공개되지 않았습니다.

NetFunnel — STCLab의 NetFunnel은 실시간 협업 자체보다 대규모 동시 접속 트래픽 제어(가상 대기실)에 특화되어 있지만, 다수 사용자가 같은 리소스를 동시에 접근하는 시나리오라는 점에서 협업과 인접한 카테고리입니다.

라인 Note / Worktile Korea — 라인의 내부 협업 도구는 일본 본사와 공유하며 자세한 공개 자료는 적습니다.

23. 일본 사례 — Cybozu kintone, Sansan, Backlog (Nulab), JaaS

Cybozu kintone — Cybozu는 일본 최대 협업 SaaS 기업으로, kintone(2011~)은 노코드 업무 앱 빌더이면서 동시 편집을 지원합니다. 자체 구축 OT 기반이며, 2024년 일부 모듈을 Yjs로 마이그레이션 중이라는 발표가 있었습니다.

Sansan Bill One — 청구서 관리 SaaS인 Bill One은 다수 사용자가 동시에 청구서를 검토하는 시나리오를 위해 자체 협업 엔진을 구축했습니다. 2025년 Sansan Tech Conf에서 일부 공개.

Backlog (Nulab) — 후쿠오카 기반 Nulab의 Backlog는 이슈 트래커 + Git + Wiki를 묶은 협업 도구로, 실시간 동시 편집은 Wiki에 한정되며 자체 OT 기반입니다.

JaaS (Jitsi as a Service) 일본 리전 — 8x8의 JaaS는 도쿄 리전을 통해 일본 기업에 영상 회의 + 화이트보드를 제공합니다. 화이트보드 모듈은 Excalidraw(Yjs) 기반.

Notion 일본 — Notion 일본은 2023년 정식 진출했고, 일본어 UI · 결제 · 지원 + 일본 기업 협업 사용 사례가 빠르게 늘었습니다. Mercari, freee, Cyberagent 등이 채택했습니다.

24. 운영 함정 — Awareness flooding, sync storms, conflict spikes

대규모 협업 시 자주 만나는 운영 함정 세 가지를 미리 알아두면 좋습니다.

1) Awareness flooding — 사용자가 커서를 빠르게 움직이면 100ms마다 awareness 업데이트가 발생하고, 룸에 50명이 있으면 초당 25,000건의 작은 메시지가 오갑니다. 해결책은 throttling(예: 60ms마다 1회) + delta encoding(이전 값과의 차이만 전송).

2) Sync storms — 새 사용자가 룸에 들어올 때 전체 문서를 동기화하므로, 대형 문서(예: 500KB Yjs document)는 한 번에 50명이 들어오면 25MB 대역폭을 씁니다. 해결책은 rate limiting + CDN 캐싱(처음 sync는 정적 스냅샷에서).

3) Conflict spikes — 다수 사용자가 같은 셀에 동시 입력하면 머지 비용이 폭발합니다. UX 레벨에서 soft lock (사용자가 셀에 들어가면 자물쇠 아이콘) + optimistic write 의 균형이 중요합니다.

25. 비용 — Liveblocks vs Yjs 자체 호스팅의 손익분기점

대략적인 비용 비교(2026년 5월 기준):

• Liveblocks — 100 MAU 무료, 1,000 MAU 월 $99, 10,000 MAU 월$499, 100,000 MAU 월 약 $4,000.
• PartyKit — Cloudflare Workers 가격, 1M 요청/일 무료, 그 위는 요청당 $0.30/1M + Durable Object 시간$0.50/M GB-s.
• Yjs + y-websocket 자체 호스팅 — 작은 룸 100개를 1대 t3.medium($30/월)으로 충분히 처리, 1,000개 룸이면 c6i.xlarge($120/월) + Postgres.
• Hocuspocus Cloud — 1,000 동시 연결 월 $99.

손익분기점은 대략 10,000~50,000 MAU 사이입니다. 그 아래는 Liveblocks가 압도적으로 저렴하고, 그 위로 가면 자체 호스팅이 경제적입니다. 다만 자체 호스팅은 SRE 인건비가 들어가므로 단순 인프라 비용 비교만으로는 부족합니다.

26. 2026년 트렌드 — Local-first의 르네상스, AI Copilot의 도래

세 가지 큰 트렌드가 보입니다.

Local-first의 르네상스 — Linear · Notion · Figma 같은 선두 SaaS가 모두 "더 빠른 UX"의 답으로 로컬 우선을 택했습니다. 2024~2025년에 Zero · ElectricSQL · Triplit · Jazz.tools 같은 신생 진영이 폭발적으로 늘었고, 2026년에는 "신규 SaaS의 default가 local-first"가 될 전망입니다.

AI Copilot의 도래 — Liveblocks AI Copilots(2025) 처럼, AI 에이전트가 사람처럼 협업 룸에 참가해 문서를 함께 편집하는 모델이 부상하고 있습니다. Cursor, Continue, Aide 같은 AI 코딩 도구도 같은 방향. CRDT의 강점("non-human agent도 같은 자료 구조 공유")이 마침내 빛을 발하고 있습니다.

WebTransport 확산 — Safari가 2026년 베타에서 WebTransport를 지원하면서, "다음 세대 transport"의 채택이 가속될 것입니다. PartyKit · Liveblocks가 WebTransport 백본으로 옮기는 작업이 진행 중입니다.

27. 참고 / References

• Yjs documentation — https://docs.yjs.dev/
• Yjs GitHub — https://github.com/yjs/yjs
• Automerge — https://automerge.org/
• Automerge-repo — https://github.com/automerge/automerge-repo
• Loro CRDT — https://www.loro.dev/
• Diamond Types — https://github.com/josephg/diamond-types
• Liveblocks documentation — https://liveblocks.io/docs
• PartyKit documentation — https://docs.partykit.io/
• Hocuspocus (TipTap) — https://tiptap.dev/docs/hocuspocus
• Replicache — https://replicache.dev/
• Zero (Rocicorp) — https://zero.rocicorp.dev/
• ElectricSQL — https://electric-sql.com/
• PowerSync — https://www.powersync.com/
• Convex — https://docs.convex.dev/
• Triplit — https://triplit.dev/
• Jazz.tools — https://jazz.tools/
• InstantDB — https://www.instantdb.com/
• Evolu — https://www.evolu.dev/
• cr-sqlite (Vlcn) — https://github.com/vlcn-io/cr-sqlite
• Ably documentation — https://ably.com/docs
• Pusher documentation — https://pusher.com/docs
• Soketi — https://soketi.app/
• Centrifugo — https://centrifugal.dev/
• Supabase Realtime — https://supabase.com/docs/guides/realtime
• Colyseus — https://docs.colyseus.io/
• Photon Engine — https://www.photonengine.com/
• Hathora — https://hathora.dev/docs
• tldraw sync — https://tldraw.dev/docs/sync
• Excalidraw — https://github.com/excalidraw/excalidraw
• VS Code Live Share — https://visualstudio.microsoft.com/services/live-share/
• Local-first software (Ink & Switch) — https://www.inkandswitch.com/local-first/
• How Figma's multiplayer technology works — https://www.figma.com/blog/how-figmas-multiplayer-technology-works/
• Standard Webhooks — https://www.standardwebhooks.com/
• WebTransport explainer — https://web.dev/articles/webtransport
• WebRTC DataChannel — https://developer.mozilla.org/en-US/docs/Web/API/RTCDataChannel
• 토스 SLASH conference — https://toss.tech/slash
• Cybozu kintone developer — https://cybozu.dev/
• Sansan Tech Blog — https://buildersbox.corp-sansan.com/
• Backlog (Nulab) — https://backlog.com/