한 줄로 말하면
Local-first database는 데이터를 중앙 서버에 먼저 보내야만 쓸 수 있는 구조가 아니라, 사용자의 기기에서 먼저 읽고 쓰고 나중에 다른 기기와 동기화하는 데이터베이스야. 서버가 잠깐 멈추거나 네트워크가 끊겨도 작업을 이어가는 것이 출발점이지.
이 개념의 핵심은 “서버가 없다”가 아니야. 각 기기에 데이터의 복제본을 두고, 연결이 돌아왔을 때 여러 복제본의 변경을 맞추는 방식으로 데이터의 주도권과 사용성을 배분하는 거야.
비유로 이해하기
여러 사람이 같은 노트를 한 권씩 들고 다닌다고 생각해 보자. 인터넷이 끊기면 모두 자기 노트에 계속 적을 수 있어. 다시 만났을 때 서로 달라진 부분을 비교해 노트를 맞춘다.
여기까지가 직관을 돕는 비유야. 실제 데이터베이스에서는 “누가 무엇을 언제 바꿨는가”를 기록하고, 같은 항목을 동시에 수정했을 때 어떤 결과를 채택할지 정해야 해. 노트를 단순히 이어 붙이는 것으로 끝나지 않아.
정확한 정의
전통적인 서버 중심 애플리케이션에서는 사용자의 입력이 서버에 도착하고, 서버 데이터베이스가 결과를 저장한 뒤, 다른 기기가 그 결과를 읽어. 이 구조에서는 서버와의 왕복 시간이 읽기·쓰기 경험의 일부가 돼.
Local-first database는 반대 순서를 택해. 각 노드가 전체 또는 작업에 필요한 데이터의 로컬 복제본을 가지고, 읽기와 쓰기를 우선 로컬에서 처리해. 연결이 없어도 애플리케이션이 동작하고, 연결이 생기면 다른 노드에 변경을 전파해 복제본을 수렴시킨다.1
따라서 이 구조는 세 가지 요소로 읽으면 돼.
- 로컬 복제본: 기기마다 데이터를 가까이 둔다.
- 비동기 동기화: 쓰기를 즉시 중앙 서버에 확정하지 않고, 연결이 가능할 때 다른 노드와 맞춘다.
- 충돌 해결: 여러 기기가 동시에 바꾼 결과를 일관된 규칙으로 수렴시킨다.
이때 “동기화”는 모든 기기가 항상 같은 순간에 같은 값을 본다는 뜻이 아니야. 연결이 끊긴 동안에는 서로 다른 상태가 존재할 수 있고, 목표는 변경 사항이 전달된 뒤 같은 규칙에 따라 같은 상태에 도달하는 거야.
왜 중요한가
네트워크가 불안정한 현장, 이동 중인 기기, 여러 사람이 동시에 편집하는 문서에서는 서버 왕복을 매번 기다리는 비용이 커져. Local-first 구조는 이 비용을 줄이는 대신, 데이터 복제와 충돌 해결이라는 어려운 문제를 애플리케이션 쪽으로 가져와.
그래서 이 개념을 볼 때는 “중앙 서버를 없앴나?”보다 다음을 확인하는 편이 정확해.
- 오프라인 상태에서 실제로 어떤 읽기·쓰기가 가능한가?
- 모든 데이터를 기기에 복제하는가, 필요한 일부만 복제하는가?
- 동시에 수정된 변경을 어떤 규칙으로 합치는가?
- 기기를 잃거나 오래 연결되지 않았을 때 복구할 수 있는가?
실제 예시
GuardianDB는 자신을 Rust로 만든 P2P 데이터베이스로 소개하면서, 각 노드가 전체 로컬 복제본을 보유하고 읽기·쓰기를 서버 왕복 없이 처리한다고 설명해. 연결이 회복되면 Iroh를 통해 피어 사이의 변경이 수렴하도록 설계했다는 게 이 제품 소개의 핵심이야.2
동시 수정은 CRDT와 인과 관계를 기록하는 구조로 다룬다고 소개돼. 구체적으로 Last-Write-Wins CRDT와 causal DAG를 사용해 여러 피어의 동시 편집이 자동으로 수렴한다고 주장한다.3 여기서 CRDT(Conflict-free Replicated Data Type)는 여러 복제본에서 독립적으로 변경해도 정해진 연산 규칙에 따라 같은 결과로 합쳐지도록 만든 자료 구조의 한 부류야. 다만 “충돌이 없다”는 표현을 모든 업무 규칙의 충돌이 사라진다는 뜻으로 읽으면 안 돼. 데이터 구조가 합쳐줄 수 있는 충돌과, 사람이 정책으로 결정해야 하는 충돌은 다르니까.
이 소개 페이지가 제시하는 저장소 종류는 이벤트 로그, 키-값 저장소, 문서 저장소야.4 예를 들어 설정값 같은 작은 데이터를 키와 값으로 저장하고, 변경을 피어에 복제하는 흐름을 보여준다.5 이 사례는 local-first database가 특정 화면 기능이 아니라 저장·복제·동기화의 기본 구조라는 점을 보여주는 데 의미가 있어.
헷갈리지 말아야 할 점
- local-first ≠ offline-only. 오프라인에서도 쓸 수 있다는 뜻이지, 네트워크나 서버가 전혀 필요 없다는 뜻은 아니야. 여러 기기의 변경을 전달하고 백업하려면 연결 경로가 필요할 수 있어.
- P2P ≠ 데이터가 자동으로 안전하다. 중앙 서버를 줄이면 한 곳의 장애에 덜 의존할 수 있지만, 기기 인증·암호화·복구·권한 관리는 여전히 별도로 설계해야 해. GuardianDB는 피어 신원과 종단 간 암호화를 기능으로 소개하지만, 이 페이지의 재료만으로 그 보안성을 독립적으로 평가할 수는 없어.6
- CRDT ≠ 모든 업무 충돌의 해결책. 자료 구조 수준의 병합 규칙은 정할 수 있어도, 재고 차감·좌석 예약처럼 동시에 둘 다 성립할 수 없는 업무 규칙은 별도의 권한과 정책이 필요해.
- 복제본이 많을수록 공짜로 확장되는 것은 아니야. 소개 페이지는 두 피어 사이에서 빠진 차이만 교환하는 방식을 설명하지만, 복제본 수·동기화 빈도·데이터 보존 기간에 따른 운영 비용은 별도로 검증해야 해.7
남은 질문들
- local-first를 표방하는 실제 애플리케이션은 오프라인 상태에서 어떤 기능까지 보장하나?
- CRDT의 병합 결과와 제품의 업무 규칙이 충돌할 때 사용자는 무엇을 보게 되나?
- 기기 분실·장기 오프라인·권한 회수 상황에서 복제본을 어떻게 폐기하거나 복구하나?
- 중앙 서버 중심 데이터베이스와 비교했을 때 저장·동기화·운영 비용은 어떤 조건에서 달라지나?
관련 문서
- 로컬 저장소의 자료 구조를 더 좁게 보는 문서: SQLite strict tables
- 여러 실행 단위를 연결하는 서버 측 자원 관리: connection pooler와 process fleet
댓글