도입
오늘날 많은 SaaS와 클라우드 앱은 협업과 멀티 디바이스 접근성에서는 강하지만, 데이터의 최종 권위를 서버에 두기 때문에 사용자는 네트워크, 서비스 제공자, 요금제, 계정 상태에 크게 의존하게 됩니다.
Local-First는 이 관계를 뒤집습니다. 사용자의 노트북, 태블릿, 모바일 같은 로컬 장치 안의 데이터 사본을 기본으로 두고, 서버는 있더라도 주로 동기화와 백업을 돕는 보조 역할로 밀어냅니다.
그래서 Local-First를 이해한다는 것은 단순히 오프라인 지원 기능을 아는 것이 아니라, 데이터 권위와 소프트웨어의 책임 위치를 어디에 둘 것인지 다시 생각하는 일에 가깝습니다.
필요성
Ink & Switch가 제안한 Local-First는 클라우드 앱의 장점과 전통적인 로컬 파일 기반 소프트웨어의 장점을 동시에 가지려는 시도입니다. 즉 협업과 접근성은 유지하되, 사용자의 데이터가 서비스 제공자에게 종속되지 않도록 하자는 방향입니다.
이 관점에서는 느린 네트워크나 일시적인 서버 장애가 곧바로 작업 중단으로 이어져서는 안 됩니다. 사용자는 네트워크가 불안정해도 계속 일할 수 있어야 하고, 서버가 사라져도 자신의 데이터 자체는 여전히 읽고 쓸 수 있어야 합니다.
즉 Local-First의 핵심 가치는 성능, 협업, 백업, 개인정보 보호, 장기 보존, 사용자 통제를 하나의 아키텍처 원리로 동시에 다루는 데 있습니다.
- 네트워크가 불안정해도 사용자가 즉시 작업을 계속해야 하는 경우
- 한 사용자가 여러 디바이스에서 같은 데이터를 자연스럽게 이어서 써야 하는 경우
- 여러 사용자가 동시에 편집하거나 협업해야 하는 경우
- 서비스 제공자에 종속되지 않는 데이터 보존과 이동성이 중요한 경우
정의
이 정의에서 가장 중요한 표현은 “로컬 사본이 1차 권위다”라는 점입니다. 기존 클라우드 앱에서는 서버 사본이 진짜이고 클라이언트는 캐시에 가깝지만, Local-First에서는 이 관계가 반대로 뒤집힙니다.
따라서 네트워크가 끊겼다고 해서 데이터 변경이 “실패한 것”으로 취급되어서는 안 됩니다. 사용자는 로컬에서 계속 읽고 쓰고 편집할 수 있어야 하며, 동기화는 백그라운드에서 늦게 일어나도 됩니다.
또 Local-First는 반드시 서버가 없어야 한다는 뜻은 아닙니다. 서버는 충분히 사용할 수 있지만, 그 역할은 권위의 중심이 아니라 동기화·중계·백업 쪽으로 더 가깝습니다.
"로컬 퍼스트의 본질은 오프라인 기능 추가가 아니라
데이터 권위를 서버에서 사용자 장치 쪽으로 되돌리는 아키텍처 선택에 가깝습니다."
핵심 원리
Local-First에서 사용자의 입력은 서버 왕복 성공 이후에 확정되는 것이 아니라, 먼저 로컬에 반영됩니다. 이 덕분에 앱은 더 빠르게 반응하고, 네트워크가 약하거나 끊겨 있어도 작업이 이어집니다.
그다음에 필요한 것은 동기화입니다. 여러 장치와 여러 사용자 사이에서 나중에 변경분을 교환하고 병합해야 하므로, Local-First는 자연스럽게 분산 복제와 충돌 해석 문제를 함께 안게 됩니다.
이 때문에 CRDT 같은 기술이 자주 함께 등장합니다. 다만 Local-First 자체가 CRDT의 다른 이름은 아닙니다. Local-First는 더 넓은 제품 철학과 아키텍처 원리이고, CRDT는 이를 구현하는 유력한 기반 기술 중 하나에 가깝습니다.
즉 Local-First는 “어디를 1차 권위로 둘 것인가”에 대한 원칙이고, CRDT는 “그 상태를 어떻게 병합할 것인가”에 대한 기술이라고 이해하면 구분이 더 쉽습니다.
Local-First Flow
1) 사용자가 로컬에서 데이터를 읽고 수정한다
2) 변경은 즉시 로컬 상태에 반영된다
3) 네트워크가 가능해지면 다른 장치/사용자/서버와 동기화한다
4) 충돌이 있으면 자료형 또는 동기화 엔진 규칙으로 병합한다
5) 각 복제본은 최종적으로 같은 상태로 수렴한다핵심 이상
| 이상 | 의미 | 실무 해석 |
|---|---|---|
| No spinners | 입력에 즉시 반응 | 서버 왕복을 기다리지 않고 로컬에서 곧바로 작업 반영 |
| Not trapped on one device | 여러 장치에서 이어서 작업 | 노트북, 태블릿, 모바일 간 동기화가 자연스러워야 함 |
| The network is optional | 오프라인에서도 사용 가능 | 읽기뿐 아니라 쓰기까지 로컬에서 계속 가능해야 함 |
| Seamless collaboration | 협업을 기본 지원 | 여러 사용자의 동시 편집과 동기화가 자연스러워야 함 |
| The Long Now | 장기 보존과 지속 가능성 | 서비스 종료 후에도 데이터 접근성과 이식성이 남아야 함 |
| Security and privacy by default | 프라이버시와 보안 강화 | 중앙 집중 저장소 의존을 줄여 노출 면적을 낮춤 |
| User ownership and control | 사용자 통제권 유지 | 데이터는 서비스 제공자보다 사용자 쪽에 더 가까워야 함 |
즉 Local-First를 오프라인 퍼스트와 동일하게 보면 범위를 너무 좁게 잡는 셈입니다. 오프라인 지원은 일곱 가지 이상 중 하나일 뿐이고, 나머지 축에는 멀티 디바이스, 협업, 장기 보존, 프라이버시, 데이터 통제권이 함께 들어갑니다.
기본 구조
local-first-app/
├── local database
│ ├── document state
│ ├── change history
│ └── pending sync queue
├── sync engine
│ ├── merge rules
│ ├── conflict resolution semantics
│ └── replication protocol
├── optional server
│ ├── relay
│ ├── backup
│ └── discovery / authentication support
└── UI
├── reads from local state
└── writes to local state first여기서 가장 중요한 것은 UI가 로컬 상태를 중심으로 읽고 쓴다는 점입니다. 서버는 존재할 수 있지만, 사용자의 입력이 먼저 서버로 가서 승인받아야만 반영되는 구조와는 철학이 다릅니다.
기본 구현
Traditional Cloud App
User Action
-> request to server
-> server writes authoritative state
-> response returns
-> client updates UI
Local-First App
User Action
-> write local authoritative copy
-> UI updates immediately
-> background sync starts
-> other replicas converge later패턴 1. 오프라인 우선보다 더 넓은 개념
오프라인 지원만 놓고 보면 Local-First와 비슷해 보일 수 있습니다. 하지만 원 제안은 오프라인만을 말하지 않고, 여러 장치에서의 자연스러운 연속 작업, 협업, 장기적인 데이터 접근 가능성, 보안과 프라이버시, 사용자 통제까지 한 묶음으로 봅니다.
즉 비행기 안에서도 동작하는 앱을 만드는 것만으로 Local-First라고 부르기는 어렵습니다. 로컬 저장이 있더라도 데이터가 특정 서비스 안에 갇혀 있고, 사용자가 소유권과 이동성을 갖지 못한다면 철학적으로는 여전히 거리가 있습니다.
패턴 2. 서버는 사라지는 것이 아니라 역할이 바뀐다
이 지점이 많이 오해됩니다. 로컬 퍼스트는 반드시 완전한 P2P만 허용하는 개념이 아닙니다. 실제 문헌과 구현은 서버를 사용할 수 있다고 전제합니다.
다만 서버가 모든 write의 단일 승인자이자 최종 진실의 원천이 되는 구조에서 벗어나, 더 단순하고 대체 가능하며 보조적인 역할로 물러나는 것이 핵심입니다. 서버는 relay, backup, discovery, 인증 보조, 중간 저장소가 될 수 있지만, 사용자 데이터의 존재 자체를 서비스가 독점해서는 안 됩니다.
Possible Server Roles
- sync relay
- backup storage
- peer discovery
- auth support
- history transport
Not the only authoritative place where data "really" exists패턴 3. CRDT와 sync engine은 구현 축이다
Automerge 같은 구현은 Local-First를 실현하기 위해 CRDT를 사용합니다. CRDT는 여러 복제본의 동시 변경을 자동 병합하는 데 강하므로, 로컬 우선 + 배경 동기화 구조와 잘 맞습니다.
하지만 Local-First 전체가 CRDT만으로 끝나는 것은 아닙니다. 문헌에서도 인증, 접근 제어, 검색과 인덱싱, 스키마 진화, 사용자에게 버전 이력을 어떻게 보여 줄지 같은 문제가 남아 있다고 설명합니다.
즉 CRDT는 핵심 엔진일 수 있지만, Local-First 제품을 완성하려면 데이터 모델, 동기화 UX, 백업, 내보내기, 이식성, 보안, 접근 제어를 함께 설계해야 합니다.
한계와 주의점
원 논문도 로컬 퍼스트를 주로 문서·파일·노트·캘린더·비밀번호 관리 같은 개인 또는 협업 데이터 도구 쪽에서 설명합니다. 반대로 은행, 전자상거래, 소셜 네트워크, 차량 호출 같은 서비스는 중앙 집중형 시스템이 더 자연스러운 경우가 많다고 선을 긋습니다.
또 PushPin 논문이 지적하듯이 실제 제품 수준에서는 인증과 접근 제어, 검색과 인덱싱, 스키마 진화, 프라이버시, 일부 장치만 동기화된 상태에서의 사용성 같은 문제가 크게 남아 있습니다.
즉 Local-First는 강한 철학이지만, 모든 문제를 우아하게 해결하는 만능 공식은 아닙니다. 특히 전역적으로 단일 사실을 강제해야 하는 도메인이라면, 일부 구간은 여전히 중앙 조정과 서버 권위가 필요할 수 있습니다.
- Local-First는 모든 도메인에 자동으로 맞는 정답이 아님
- CRDT만 넣는다고 제품이 곧바로 Local-First가 되는 것은 아님
- 인증·권한·검색·인덱싱·스키마 진화는 별도의 제품 과제임
- 중앙 권위가 반드시 필요한 업무 규칙은 여전히 따로 다뤄야 할 수 있음
자주 하는 실수
- Local-First = 오프라인 퍼스트로만 이해함
- Local-First = 서버가 절대 없어야 한다고 생각함
- Local-First = CRDT와 같은 말로 단순화함
- 캐시가 있으면 곧바로 로컬 퍼스트라고 오해함
- 데이터 소유권과 내보내기 가능성, 장기 보존을 설계에서 빼먹음
- 동기화 UX와 버전 이력, 충돌 가시화를 너무 늦게 고려함
실무 루틴
- 먼저 어떤 데이터가 로컬에서 권위 사본 으로 남아야 하는지 정한다.
- 네트워크가 완전히 끊긴 상태에서도 읽기와 쓰기 가 어떻게 동작해야 하는지 먼저 설계한다.
- 동기화는 서버 의존형인지, 서버 보조형인지, P2P까지 필요한지 구분한다.
- CRDT, 로그 기반 sync, 버전 이력, 병합 규칙 중 무엇이 맞는지 데이터 타입별로 고른다.
- 내보내기, 백업, 복원, 장기 보존 경로를 제품의 일부로 설계한다.
- 인증·권한·검색·스키마 진화는 별도 축으로 초기에 함께 검토한다.
검토
점검 체크리스트
- 지금 데이터의 1차 권위는 어디에 있는가
- 네트워크 없이도 읽기와 쓰기가 가능한가
- 서버가 사라져도 사용자의 기존 데이터는 남는가
- 멀티 디바이스/협업 병합 결과가 자연스러운가
- export / backup / restore 가 실제로 가능한가
- auth / access control / search / schema evolution 은 어떻게 해결하는가요약
- ✅ Local-First는 로컬 사본을 1차 권위로 두는 설계 철학이다.
- ✅ 오프라인 지원은 일부일 뿐이고, 멀티 디바이스·협업·장기 보존·프라이버시·사용자 통제까지 함께 본다.
- ✅ 서버는 없어도 되지만, 있어도 주 역할은 권위보다는 동기화·백업에 가깝다.
- ✅ CRDT는 Local-First를 구현하는 핵심 기술로 자주 쓰이지만 개념 전체와 동일하지는 않다.
- ✅ 캐시 중심 앱과 로컬 퍼스트 앱의 차이는 데이터 권위가 어디에 있느냐에 있다.
- ✅ 문서·노트·캘린더·개인 데이터 도구와 협업 앱에 특히 잘 맞는다.
- ✅ 인증·권한·검색·인덱싱·스키마 진화는 여전히 어려운 제품 과제다.
- ✅ 좋은 Local-First 제품은 사용자가 네트워크와 서비스 상태를 크게 의식하지 않게 만든다.