Ver2.5 CouchDB와 오프라인 퍼스트(Offline-first) 앱 아키텍처

들어가며: "연결이 끊겼습니다"라는 공포 😱

상상해보세요. 지하철에서 중요한 업무 메일을 확인하려는데 앱이 무한 로딩에 빠집니다. 터널에 진입하는 순간, 화면에는 "네트워크에 연결할 수 없습니다"라는 절망적인 메시지만 뜹니다. 혹은 와이파이가 불안정한 카페에서 팀 프로젝트 문서를 수정했는데, 잠시 후 확인해보니 변경 사항이 하나도 저장되지 않았습니다. 아, 생각만 해도 끔찍하죠?

우리는 알게 모르게 '인터넷 연결'이라는 보이지 않는 끈에 의존하는 디지털 세상을 살고 있습니다. 대부분의 애플리케이션은 서버와 실시간으로 데이터를 주고받아야만 정상적으로 작동합니다. 하지만 현실 세계의 네트워크는 완벽하지 않습니다. 불안정하고, 느리며, 때로는 완전히 끊어지기도 하죠.

이런 '연결 중심' 아키텍처의 한계는 사용자 경험(UX)에 치명적인 상처를 남깁니다. 사용자는 앱이 자신의 상황을 전혀 고려하지 않는다고 느끼며, 불만과 좌절감 속에서 앱을 떠나게 될지도 모릅니다. 개발자 입장에서도 문제입니다. 불안정한 네트워크 환경에서 데이터 유실을 막고 일관성을 유지하기 위해 복잡한 예외 처리 로직을 덕지덕지 붙여야 하니까요.

이 질문에 대한 해답이 바로 '오프라인 퍼스트(Offline-first)' 아키텍처입니다. 그리고 이 혁신적인 아키텍처를 현실로 만들어주는 가장 강력한 파트너 중 하나가 바로 오늘 우리가 깊이 파헤쳐 볼 CouchDB입니다. 이 글을 통해 우리는 왜 오프라인 퍼스트가 미래의 앱 개발 패러다임인지, 그리고 CouchDB가 어떻게 그 중심에서 마법 같은 데이터 동기화를 구현하는지 속속들이 알아보게 될 겁니다. 준비되셨나요? 이제 연결의 족쇄를 끊고 진정한 자유를 향한 여정을 시작해봅시다! ✨

1. 왜 '오프라인 퍼스트'에 열광하는가? 단순한 유행 그 이상!

'오프라인 퍼스트'라는 말을 들으면 단순히 '오프라인 모드'를 지원하는 기능 정도로 생각하기 쉽습니다. 하지만 둘은 근본부터 다릅니다. 오프라인 모드는 온라인 상태를 기본으로 하되, 연결이 끊겼을 때를 위한 '비상 대책'에 가깝습니다. 반면 오프라인 퍼스트는 앱의 설계 철학 자체를 뒤집습니다.

앱의 모든 데이터는 로컬(사용자 기기)에 저장되는 것을 기본으로 합니다.
사용자의 모든 행동(읽기, 쓰기, 수정, 삭제)은 일단 로컬 데이터베이스에 즉시 반영됩니다. 그리고 네트워크 연결이 가능해지면, 그동안 쌓인 변경사항을 알아서 서버와 '동기화(Sync)'하는 방식이죠. 즉, 앱의 핵심 기능은 인터넷 연결 여부와 완전히 독립적으로 작동합니다.

1.1. 비교 불가능한 사용자 경험 (UX) 🚀

오프라인 퍼스트가 제공하는 가장 큰 가치는 바로 '압도적으로 뛰어난 사용자 경험'입니다.

1) 미친 듯한 속도:
모든 데이터는 로컬 스토리지에서 직접 읽어옵니다. 네트워크 지연(latency)이라는 변수가 원천적으로 제거되죠. 사용자가 버튼을 누르는 즉시 화면이 반응합니다. 0.1초의 지연도 용납하지 못하는 현대 사용자들에게 '즉각적인 반응성'은 그 어떤 화려한 기능보다 강력한 무기가 됩니다.

2) 끊김 없는 사용성:
비행기 모드, 엘리베이터 안, 데이터가 터지지 않는 캠핑장... 어디서든 앱의 모든 기능을 완벽하게 사용할 수 있습니다. 사용자는 더 이상 네트워크 상태를 신경 쓸 필요가 없습니다. 앱이 '언제나 작동할 것'이라는 강력한 신뢰가 형성되죠. 이는 사용자의 충성도를 높이는 결정적인 요인이 됩니다.

1.2. 개발자와 비즈니스를 위한 실질적 이점 💸

오프라인 퍼스트는 사용자만 좋은 것이 아닙니다. 개발자와 비즈니스에도 엄청난 이점을 가져다줍니다.

1) 서버 부하 및 비용 감소:
기존의 채팅 앱을 생각해보세요. 메시지 하나 보낼 때마다 서버에 요청을 보냅니다. 하지만 오프라인 퍼스트 앱에서는 여러 개의 메시지를 로컬에 저장했다가 한 번의 동기화 요청으로 처리할 수 있습니다. 이는 서버 API 호출 횟수를 극적으로 줄여주며, 결과적으로 서버 인프라 비용과 트래픽 비용을 절감하는 효과로 이어집니다.

2) 개발 복잡도 감소 (의외의 사실!):
"로컬 DB 관리하고 동기화 로직까지 짜려면 더 복잡한 거 아니야?" 라고 생각할 수 있습니다. 하지만 잘 설계된 오프라인 퍼스트 프레임워크(바로 CouchDB와 PouchDB 같은!)를 사용하면 오히려 개발이 단순해집니다. 개발자는 더 이상 수많은 네트워크 예외 상황(타임아웃, 연결 실패, 재시도 로직 등)을 직접 처리할 필요가 없습니다. 그저 로컬 DB에 데이터를 넣고 빼는 것에만 집중하면, 복잡한 동기화는 프레임워크가 알아서 처리해주니까요.

3) 배터리 수명 연장:
스마트폰에서 가장 많은 배터리를 소모하는 부품 중 하나가 바로 통신 모듈(Wi-Fi, LTE)입니다. 네트워크 요청 횟수를 줄이는 것은 곧 기기의 배터리 수명을 연장하는 효과를 가져옵니다. 사소해 보이지만 사용자 만족도에 직접적인 영향을 미치는 부분이죠.

이처럼 오프라인 퍼스트는 단순히 '연결이 끊겨도 되는' 수준을 넘어, 더 빠르고, 더 안정적이며, 더 효율적인 애플리케이션을 만드는 현대적인 개발 패러다임입니다. 이제, 이 멋진 철학을 현실로 만들어 줄 우리의 주인공, CouchDB를 만나볼 시간입니다.

2. CouchDB, 넌 대체 누구니? 동기화에 진심인 NoSQL 데이터베이스

세상에는 수많은 데이터베이스가 있습니다. 관계형 데이터베이스의 강자 MySQL, PostgreSQL부터 NoSQL의 대표주자 MongoDB, Redis까지. 그런데 왜 하필 '오프라인 퍼스트'라는 주제에 CouchDB가 소환된 걸까요? 그 이유는 CouchDB가 태생부터 '분산 환경'과 '데이터 동기화'를 염두에 두고 설계되었기 때문입니다. 다른 데이터베이스들이 '동기화'를 부가 기능으로 여길 때, CouchDB는 이를 핵심 정체성으로 삼았습니다.

2.1. CouchDB의 핵심 특징 톺아보기

CouchDB의 매력을 이해하려면 몇 가지 핵심 개념을 알아야 합니다.

1) 문서 지향 (Document-Oriented) 데이터베이스:
CouchDB는 데이터를 JSON 문서 형태로 저장합니다. 개발자에게 매우 친숙한 형태죠. 정해진 스키마가 없어서 유연하게 데이터를 저장하고 변경할 수 있습니다. 각 문서는 고유한 ID(`_id`)를 가지며, 문서의 내용은 키-값 쌍으로 이루어진 객체입니다.

{
  "_id": "a1b2c3d4e5f6",
  "_rev": "1-abcdef123456",
  "type": "note",
  "title": "CouchDB 스터디",
  "content": "오프라인 퍼스트 아키텍처의 핵심!",
  "tags": ["database", "offline-first", "nosql"],
  "createdAt": "2023-10-27T10:00:00Z"
}
    

위 예시처럼 하나의 문서 안에 관련된 모든 정보를 담을 수 있어 직관적입니다.

2) RESTful API:
CouchDB와 소통하는 방법은 아주 간단합니다. 바로 HTTP 프로토콜을 사용하는 것이죠. 데이터베이스 생성, 문서 조회, 수정, 삭제 등 모든 작업을 표준 HTTP 메소드(GET, POST, PUT, DELETE)를 통해 수행할 수 있습니다. 이는 특정 언어나 드라이버에 종속되지 않고, 거의 모든 프로그래밍 환경에서 쉽게 CouchDB를 사용할 수 있다는 의미입니다. `curl` 명령어만으로도 데이터베이스를 완벽하게 제어할 수 있죠!

3) MVCC (Multi-Version Concurrency Control):
이것이 바로 CouchDB 동기화 마법의 핵심 재료입니다. '다중 버전 동시성 제어'라는 어려운 이름이지만, 개념은 간단합니다. CouchDB는 데이터를 수정할 때 기존 데이터를 덮어쓰는 것이 아니라, 새로운 버전을 추가합니다.

위 예시 코드의 `_rev` 필드를 보셨나요? 이것이 바로 '리비전(Revision) ID'입니다. 문서를 한 번 수정할 때마다 이 `_rev` 값이 바뀝니다. ("1-...", "2-...", "3-...") CouchDB는 문서의 모든 변경 이력을 이 리비전 트리(Revision Tree) 형태로 관리합니다. 덕분에 어떤 순서로 데이터가 변경되었는지 추적할 수 있고, 여러 클라이언트가 동시에 문서를 수정했을 때 발생하는 '충돌'을 감지해낼 수 있습니다. 잠금(Locking) 방식 없이도 데이터 일관성을 유지하는 매우 우아한 방법이죠.

4) MapReduce를 이용한 뷰(View):
SQL 데이터베이스처럼 `WHERE` 절로 동적으로 데이터를 필터링하는 것에 익숙하다면 CouchDB의 쿼리 방식은 조금 생소할 수 있습니다. CouchDB는 뷰(View)라는 것을 통해 데이터를 조회합니다. 뷰는 데이터베이스에 저장된 모든 문서를 스캔하여 개발자가 정의한 `Map` 함수를 적용, 원하는 데이터만 추출하여 인덱스(Index)를 미리 만들어두는 기능입니다.

`Map` 함수는 문서에서 필요한 키-값 쌍을 방출(emit)하고, 선택적으로 `Reduce` 함수를 통해 이 결과들을 집계(예: 합계, 평균, 개수 계산)할 수 있습니다. 이렇게 미리 생성된 인덱스 덕분에 대용량 데이터에서도 매우 빠른 조회가 가능합니다.

2.2. 그리고 대망의... 복제 프로토콜 (Replication Protocol) ✨

CouchDB를 특별하게 만드는 결정적인 기능, 바로 복제(Replication)입니다. CouchDB의 복제는 단순히 데이터를 복사해서 붙여넣는 수준이 아닙니다.

이 강력한 복제 프로토콜 덕분에 우리는 복잡한 동기화 로직을 직접 구현할 필요가 없습니다. 그저 "A 데이터베이스와 B 데이터베이스를 동기화해줘" 라고 명령만 내리면, 나머지는 CouchDB가 알아서 처리해줍니다. 이것이 바로 CouchDB가 오프라인 퍼스트 아키텍처의 '치트키'로 불리는 이유입니다.

자, 이제 이론은 충분히 알았습니다. 이 멋진 CouchDB를 웹 브라우저와 모바일 앱 안으로 가져와 줄 환상의 파트너, PouchDB를 만나러 가볼까요?

3. 환상의 짝꿍, PouchDB와 CouchDB로 만드는 오프라인 퍼스트 앱 🤝

CouchDB의 강력한 동기화 기능, 정말 매력적입니다. 하지만 한 가지 문제가 있죠. CouchDB는 서버에서 동작하는 데이터베이스입니다. 우리가 만들려는 앱은 사용자의 브라우저나 스마트폰, 즉 클라이언트 단에서 오프라인으로 작동해야 하는데요. 어떻게 서버에 있는 CouchDB의 능력을 클라이언트까지 가져올 수 있을까요?

여기에 바로 PouchDB가 등장합니다. PouchDB는 '주머니(Pouch)'라는 이름처럼, CouchDB를 주머니 속에 쏙 들어오는 작은 버전으로 만들었다고 생각하면 쉽습니다.

핵심은 PouchDB가 CouchDB와 완벽하게 동일한 API를 사용한다는 점입니다. 즉, PouchDB를 다루는 코드는 원격 CouchDB를 다루는 코드와 거의 100% 똑같습니다. 개발자는 로컬 DB를 다루는지, 원격 DB를 다루는지 신경 쓸 필요 없이 일관된 코드를 작성할 수 있습니다.

3.1. 오프라인 퍼스트 아키텍처의 완성

PouchDB와 CouchDB가 만나면 비로소 완벽한 오프라인 퍼스트 아키텍처가 완성됩니다. 그 구조를 한번 살펴볼까요?

1. 앱은 오직 로컬 PouchDB와 통신합니다.
사용자가 글을 쓰거나, 할 일을 추가하거나, 데이터를 조회하는 모든 행위는 원격 서버가 아닌 로컬 PouchDB를 대상으로 이루어집니다. 네트워크 상태와 상관없이 모든 작업이 즉시 처리되므로 앱은 항상 빠르고 부드럽게 반응합니다.

2. PouchDB가 알아서 동기화를 처리합니다.
개발자는 PouchDB에게 원격 CouchDB의 주소를 알려주고 "동기화 시작!"(`db.sync()`)이라는 간단한 명령만 내리면 됩니다. 그러면 PouchDB는 네트워크 연결을 감지하여 다음과 같은 일을 자동으로 수행합니다.

• 로컬 PouchDB에서 변경된 내용을 원격 CouchDB로 보냅니다.
• 원격 CouchDB에서 다른 사용자에 의해 변경된 내용을 로컬 PouchDB로 가져옵니다.
• 네트워크가 끊기면 동기화를 잠시 멈추고, 연결되면 중단된 부분부터 다시 시작합니다.

3. CouchDB는 데이터 허브 역할을 합니다.
서버의 CouchDB는 모든 클라이언트(사용자)로부터 온 변경사항들을 취합하는 중앙 데이터 저장소 역할을 합니다. 그리고 다시 다른 클라이언트들에게 변경사항을 전파하는 허브가 되죠.

3.2. 코드로 맛보는 PouchDB + CouchDB

백문이 불여일견! 실제 코드가 얼마나 간단한지 한번 볼까요? (JavaScript 기준)

// npm이나 yarn으로 pouchdb-browser 패키지를 설치합니다.
// import PouchDB from 'pouchdb-browser';

// 'mytodos'라는 이름의 로컬 데이터베이스 인스턴스를 생성합니다.
// 브라우저에 'mytodos'라는 IndexedDB가 없다면 새로 생성됩니다.
const localDB = new PouchDB('mytodos');
    

// 새로운 할 일 문서 생성
async function addTodo() {
  try {
    const response = await localDB.post({
      _id: `todo_${new Date().toISOString()}`, // ID는 직접 지정하거나 자동으로 생성되게 할 수 있습니다.
      title: 'PouchDB 공부하기',
      completed: false,
      createdAt: new Date().toISOString()
    });
    console.log('문서가 성공적으로 저장되었습니다!', response);
  } catch (err) {
    console.error('문서 저장 실패:', err);
  }
}

// 모든 할 일 문서 조회
async function showAllTodos() {
  try {
    const result = await localDB.allDocs({
      include_docs: true, // 문서의 전체 내용을 포함합니다.
      startkey: 'todo_', // 'todo_'로 시작하는 ID만 조회
      endkey: 'todo_\ufff0'
    });
    console.log('모든 할 일:', result.rows.map(row => row.doc));
  } catch (err) {
    console.error('문서 조회 실패:', err);
  }
}
    

여기까지는 인터넷 연결이 전혀 필요 없습니다. 모든 것이 브라우저 안에서 빛의 속도로 처리됩니다.

// 원격 CouchDB 데이터베이스 주소
const remoteDB = new PouchDB('https://your-couchdb-server.com/mytodos');

// 양방향 실시간 동기화 시작!
localDB.sync(remoteDB, {
  live: true,  // 실시간으로 변경사항을 감지하여 계속 동기화합니다.
  retry: true  // 네트워크가 끊겼을 때 자동으로 재시도합니다.
}).on('change', function (info) {
  // 다른 클라이언트로부터 새로운 변경사항이 동기화되었을 때 발생하는 이벤트
  console.log('새로운 변경사항이 동기화되었습니다!', info);
  // 여기서 UI를 업데이트하는 로직을 추가하면 됩니다.
}).on('paused', function (err) {
  // 동기화가 (네트워크 문제 등으로) 일시 중단되었을 때
  console.log('동기화가 일시 중단되었습니다.');
}).on('active', function () {
  // 중단되었던 동기화가 다시 활성화되었을 때
  console.log('동기화가 다시 시작되었습니다.');
}).on('error', function (err) {
  // 동기화 중 에러가 발생했을 때
  console.error('동기화 에러:', err);
});
    

어떤가요? `localDB.sync(remoteDB, ...)` 단 한 줄의 코드로 그 복잡하다는 데이터 동기화 로직이 해결되었습니다. 개발자는 이제 동기화의 상세 과정에 대해 걱정할 필요 없이, `change` 이벤트가 발생했을 때 화면을 어떻게 갱신할지에만 집중하면 됩니다. 이것이 바로 PouchDB와 CouchDB 콤비가 제공하는 강력함입니다.

하지만 세상에 완벽한 것은 없겠죠. 여러 사용자가 오프라인 상태에서 '같은' 문서를 동시에 수정했다면 어떻게 될까요? 이 까다로운 '데이터 충돌' 문제를 CouchDB는 어떻게 우아하게 해결하는지, 다음 장에서 자세히 알아보겠습니다.

4. 데이터 충돌! 피할 수 없다면 지배하라: CouchDB의 우아한 해결책 🤯

오프라인 퍼스트 아키텍처를 구현할 때 개발자들이 가장 골머리를 앓는 부분이 바로 '데이터 충돌(Conflict)' 문제입니다. 분산 시스템에서는 피할 수 없는 숙명과도 같죠.

상황을 가정해봅시다.
- 사용자 A와 사용자 B는 '프로젝트 제안서'라는 공유 문서를 보고 있습니다. 둘 다 현재 문서 버전은 `rev-1`입니다.
- 갑자기 둘 다 인터넷이 끊깁니다. (오프라인 상태)
- 사용자 A는 문서 제목을 "최종 제안서"로 수정하고 로컬에 저장합니다. 로컬 PouchDB에서 이 문서는 `rev-2A`가 됩니다.
- 거의 동시에, 사용자 B는 문서 내용에 "예산 항목 추가"라는 내용을 넣고 로컬에 저장합니다. 로컬 PouchDB에서 이 문서는 `rev-2B`가 됩니다.
- 잠시 후, 두 사람 모두 인터넷에 다시 연결되고 각자의 PouchDB가 서버 CouchDB와 동기화를 시도합니다.

서버 입장에서는 난감합니다. `rev-1`을 부모로 하는 두 개의 다른 자식(`rev-2A`, `rev-2B`)이 동시에 나타났습니다. 누구의 변경사항을 최종본으로 인정해야 할까요?

4.1. CouchDB는 데이터를 버리지 않는다

CouchDB는 이런 무책임한 방식을 사용하지 않습니다. MVCC 덕분에 CouchDB는 이 상황을 '충돌'로 명확하게 인지합니다. 그리고 다음과 같이 행동합니다.

1. 일단 둘 다 받는다: CouchDB는 `rev-2A`와 `rev-2B`를 모두 거부하지 않고 받아들입니다. 2. 승자(Winner)를 결정한다: 내부적인 결정 알고리즘(일반적으로 더 많은 수정 이력을 가진 쪽이나, 리비전 ID 해시값이 큰 쪽)에 따라 일단 하나의 리비전을 '승자'로 정합니다. 이 승자 리비전이 해당 문서의 기본값이 됩니다. 예를 들어 `rev-2B`가 승자가 되었다고 가정합시다. 3. 패자(Loser)를 기록한다: 가장 중요한 부분입니다. CouchDB는 패자인 `rev-2A`를 삭제하지 않습니다. 대신, 승자 문서(`rev-2B`) 안에 `_conflicts`라는 특별한 필드를 추가하여 패자 리비전의 ID를 기록해 둡니다.

이제 `GET /db/프로젝트_제안서?conflicts=true` 와 같이 API를 호출하면 다음과 비슷한 응답을 받게 됩니다.

{
  "_id": "프로젝트_제안서",
  "_rev": "2-b4b... (rev-2B)",
  "title": "프로젝트 제안서",
  "content": "기존 내용... 예산 항목 추가",
  "_conflicts": [
    "2-a1a... (rev-2A)"
  ]
}
    

CouchDB는 우리에게 "이봐, 지금 이 문서의 기본 버전은 B가 수정한 거지만, A가 수정한 또 다른 버전도 있으니 확인해봐!" 라고 친절하게 알려주는 셈입니다. 데이터는 절대 유실되지 않았습니다.

4.2. 충돌 해결 전략: 이제 당신 차례입니다

CouchDB는 충돌을 '감지'하고 '기록'해줄 뿐, '해결'해주지는 않습니다. 왜냐하면 어떤 데이터가 더 중요한지, 두 변경사항을 어떻게 합쳐야 하는지는 데이터베이스가 아닌 애플리케이션의 비즈니스 로직만이 알 수 있기 때문입니다.

이제 개발자인 우리가 나설 차례입니다. 충돌을 해결하는 몇 가지 일반적인 전략이 있습니다.

1) 자동 병합 (Automated Merge):
가장 이상적인 방법입니다. 애플리케이션이 충돌된 두 버전의 문서를 모두 가져와서, 정해진 규칙에 따라 하나의 새로운 버전으로 합치는 것입니다.
- 예를 들어, 위의 '프로젝트 제안서' 경우, 사용자 A가 수정한 `title` 필드와 사용자 B가 수정한 `content` 필드를 합쳐서 새로운 문서를 만들 수 있습니다.
- 만약 두 사용자 모두 `content` 필드를 수정했다면, diff 알고리즘을 사용해 두 텍스트의 차이점을 비교하고 합칠 수도 있습니다. (마치 Git이 코드를 병합하는 것처럼요!)

2) 사용자에게 선택권 부여 (User-driven Resolution):
자동 병합이 불가능한 복잡한 충돌의 경우, 사용자에게 직접 해결하도록 요청하는 방법입니다.
- "문서에 충돌이 발생했습니다. A 버전과 B 버전 중 어떤 것을 선택하시겠습니까?" 와 같은 UI를 보여줍니다.
- 또는 Google Docs처럼 두 버전의 변경사항을 나란히 보여주고 사용자가 직접 내용을 수정하여 최종 버전을 만들게 할 수도 있습니다.

3) 최신 데이터 우선 (Last Write Wins - 의도적으로):
가장 간단하지만 신중하게 사용해야 하는 방법입니다. 비즈니스 로직상 무조건 최신 데이터가 중요하다면, 타임스탬프 등을 비교하여 더 나중에 수정된 버전으로 덮어쓰는 로직을 구현할 수 있습니다. (CouchDB의 기본 LWW와는 다르게, 우리가 직접 제어하는 방식입니다.)

async function resolveConflict(docId) {
  // 1. 충돌이 발생한 문서를 가져옵니다. (_conflicts 포함)
  const doc = await db.get(docId, { conflicts: true });

  if (!doc._conflicts) {
    // 충돌이 없으면 아무것도 하지 않습니다.
    return;
  }

  console.log(`'${docId}' 문서에서 충돌 발견! 해결을 시작합니다.`);

  // 2. 충돌된 모든 리비전의 내용을 가져옵니다.
  const revisions = [doc, ...await Promise.all(doc._conflicts.map(rev => db.get(docId, { rev })))];
  
  // --- 여기서부터 비즈니스 로직! ---
  // 3. 병합 로직을 적용하여 최종 문서를 만듭니다.
  // 예시: 간단하게 title은 A, content는 B에서 가져오기
  const winner = revisions[0]; // 현재 승자
  const loser = revisions[1];  // 현재 패자
  
  const mergedDoc = {
    ...winner, // 승자 버전을 기반으로
    title: loser.title || winner.title, // 패자에게 title이 있으면 그것을 사용
    // ... 더 복잡한 병합 로직 ...
  };
  
  // 4. 병합된 새 문서를 저장합니다.
  // 이 때, 삭제할 충돌 리비전 목록(_deletions)을 함께 전달합니다.
  delete mergedDoc._conflicts; // _conflicts 필드는 제거
  await db.put({
      ...mergedDoc,
      _deletions: doc._conflicts // 패자 리비전을 삭제하라고 알려줌
  });

  console.log('충돌이 성공적으로 해결되었습니다!');
}
    

충돌 해결은 오프라인 퍼스트 앱 설계에서 가장 도전적인 부분이지만, CouchDB의 접근 방식은 우리에게 데이터를 잃지 않고 문제를 해결할 수 있는 완전한 통제권을 줍니다. 이는 "일단 터지고 보자" 식의 다른 시스템과 차별화되는 매우 성숙하고 안정적인 방식입니다.

5. 이런 앱에 딱! 오프라인 퍼스트 아키텍처 실전 적용 사례 🎯

"이론은 잘 알겠는데, 그래서 이걸로 뭘 만들 수 있죠?" 라는 질문이 나올 때가 됐습니다. 오프라인 퍼스트 아키텍처는 특정 분야에만 국한된 기술이 아닙니다. 사용자 경험과 데이터 안정성이 중요한 거의 모든 종류의 애플리케이션에 적용될 수 있습니다. 몇 가지 대표적인 사례를 살펴볼까요?

5.1. 생산성 및 협업 도구

- 노트 앱 (Evernote, Notion, Obsidian):
아이디어가 떠올랐을 때, 인터넷 연결을 기다릴 순 없죠. 사용자는 언제 어디서든 노트를 작성하고 수정할 수 있어야 합니다. 오프라인 퍼스트는 노트 앱의 기본 소양과도 같습니다. 로컬에 먼저 저장하고 나중에 동기화하는 방식은 완벽한 해결책입니다.

- 할 일 관리 앱 (Todoist, TickTick):
지하철에서 오늘 할 일을 확인하고 완료 체크를 해야 합니다. 오프라인 상태에서 변경한 내용이 나중에 사무실 컴퓨터에도 자동으로 반영되어야 하죠. CouchDB의 양방향 동기화는 여러 기기 간의 데이터를 일관성 있게 유지하는 데 탁월합니다.

- 협업 문서 편집기 (Google Docs, Figma):
여러 사람이 동시에 하나의 문서를 편집하는 상황은 충돌이 발생하기 가장 좋은 환경입니다. CouchDB의 충돌 감지 및 해결 메커니즘은 누가 어떤 부분을 수정했는지 추적하고, 병합 로직을 통해 데이터 손실 없이 협업을 가능하게 하는 강력한 기반을 제공합니다.

5.2. 현장 업무 및 특수 환경용 앱

- 현장 서비스 관리 앱:
전기, 수도, 가스 등을 점검하는 기술자들은 통신이 원활하지 않은 지하실이나 외딴 지역에서 작업하는 경우가 많습니다. 이들은 오프라인 상태에서 작업 매뉴얼을 조회하고, 점검 결과를 사진과 함께 기록하고, 작업 완료 보고서를 작성할 수 있어야 합니다. 작업이 끝난 후 통신 가능 지역으로 돌아오면 모든 데이터가 자동으로 서버에 동기화되어야 합니다.

- 재고 관리 및 물류 앱:
거대한 물류 창고는 와이파이 신호가 닿지 않는 음영 구역이 많습니다. 작업자들은 바코드 스캐너가 달린 모바일 기기로 입고, 출고, 재고 실사 작업을 끊김 없이 수행해야 합니다. 모든 데이터는 로컬에 기록되고, 주기적으로 중앙 서버와 동기화되어 실시간 재고 현황을 업데이트합니다.

- 의료 정보 시스템 (EMR/EHR):
병원 내부, 특히 수술실이나 응급실은 네트워크가 불안정할 수 있습니다. 의사와 간호사는 환자의 차트를 오프라인으로 조회하고, 처방이나 진료 기록을 즉시 입력할 수 있어야 합니다. 환자의 생명과 직결된 데이터이므로, 안정적인 데이터 저장과 동기화는 필수적입니다.

5.3. 콘텐츠 소비 및 소셜 미디어 앱

- 뉴스 및 블로그 앱 (Medium):
사용자가 와이파이에 연결되어 있을 때 미리 여러 기사를 다운로드(동기화)해 둡니다. 그러면 사용자는 비행기나 지하철 안에서도 끊김 없이 기사를 읽을 수 있습니다. 읽은 위치나 북마크 정보도 로컬에 저장했다가 나중에 동기화할 수 있습니다.

- 팟캐스트 및 음악 스트리밍 앱 (Spotify '오프라인 저장' 기능의 확장판):
단순히 파일을 다운로드하는 것을 넘어, 재생 목록, 좋아요, 재생 기록 등의 메타데이터까지 모두 로컬에서 관리하고 동기화하여 완벽한 오프라인 경험을 제공할 수 있습니다.

이처럼 오프라인 퍼스트는 더 이상 '있으면 좋은' 기능이 아니라, 사용자의 기대를 충족시키고 경쟁력을 확보하기 위한 '필수' 아키텍처로 자리 잡고 있습니다. 당신이 만들고 싶은 다음 애플리케이션은 어떤 종류인가요? 아마 그 앱도 오프라인 퍼스트를 통해 훨씬 더 나은 경험을 제공할 수 있을 겁니다.

6. 고수들의 오프라인 퍼스트: 알아두면 쓸데 있는 심화 스킬 🛡️

CouchDB와 PouchDB로 기본적인 오프라인 퍼스트 앱을 구축하는 것은 생각보다 간단합니다. 하지만 실제 프로덕션 환경에서는 몇 가지 더 고려해야 할 고급 주제들이 있습니다. 이 문제들을 어떻게 다루느냐에 따라 앱의 완성도와 보안 수준이 달라집니다.

6.1. 인증과 보안: 내 데이터를 지켜라!

오프라인 퍼스트 환경에서 인증은 조금 더 까다롭습니다. 사용자가 오프라인일 때도 로그인이 유지되어야 하고, 자신의 데이터에만 접근할 수 있어야 하니까요.

- 토큰 기반 인증 (JWT):
가장 일반적인 접근 방식입니다. 사용자가 온라인일 때 로그인하면 서버는 JWT(JSON Web Token) 같은 인증 토큰을 발급합니다. 클라이언트는 이 토큰을 로컬 스토리지(안전한 곳에!)에 저장합니다. 오프라인 상태에서는 이 토큰의 유효성을 자체적으로 검사하여 로그인 상태를 유지할 수 있습니다. 서버와 동기화할 때는 모든 요청에 이 토큰을 포함하여 보내 인증을 받습니다.

- CouchDB의 사용자 관리 및 보안 규칙:
CouchDB는 자체적으로 사용자 계정(`_users` 데이터베이스)과 역할(Role) 기반의 권한 관리 기능을 내장하고 있습니다. 이를 활용하면 데이터베이스별, 문서별로 읽기/쓰기 권한을 세밀하게 제어할 수 있습니다.
예를 들어, '사용자 A는 `user_a` 데이터베이스에만 접근할 수 있다' 또는 '이 문서는 작성자와 관리자 역할(admin role)을 가진 사람만 수정할 수 있다'와 같은 규칙을 설정할 수 있습니다.

- 로컬 데이터 암호화:
PouchDB에 저장된 데이터는 기본적으로 암호화되지 않습니다. 민감한 정보를 다룬다면 `pouchdb-crypto`와 같은 플러그인을 사용하여 로컬 데이터베이스 자체를 암호화하는 것을 고려해야 합니다. 이렇게 하면 기기를 분실하더라도 데이터 유출의 위험을 줄일 수 있습니다.

6.2. 필터링된 복제: 필요한 것만 동기화하기

앱의 규모가 커지면 서버의 전체 데이터베이스를 모든 클라이언트에 동기화하는 것은 비효율적이고 보안에도 좋지 않습니다. 예를 들어, Todoist 앱 사용자가 다른 모든 사용자의 할 일 목록까지 자신의 폰에 다운로드할 필요는 없겠죠.

이때 사용하는 것이 필터링된 복제(Filtered Replication)입니다. 동기화를 할 때 특정 조건에 맞는 문서만 주고받도록 필터를 거는 기능입니다.

- Selector 기반 필터링 (Mango Query):
CouchDB 2.0 이상부터 지원되는 강력한 기능입니다. MongoDB와 유사한 JSON 기반 쿼리 문법을 사용하여 동기화할 문서를 선택할 수 있습니다.

// 'userId' 필드가 'user123'인 문서만 동기화하도록 설정
localDB.sync(remoteDB, {
  live: true,
  retry: true,
  selector: {
    'userId': 'user123'
  }
});
    

- 데이터베이스-퍼-유저 (Database-per-user) 패턴:
아예 사용자마다 별도의 데이터베이스를 할당하는 아키텍처입니다. 각 사용자는 자신의 데이터베이스에 대한 전체 접근 권한을 가지며, 이 데이터베이스를 자신의 클라이언트와 통째로 동기화합니다. 사용자 간 데이터 공유가 필요할 때는 별도의 '공유' 데이터베이스를 두고, 특정 문서에 대한 접근 권한을 부여하는 방식으로 구현할 수 있습니다. 이 패턴은 사용자 데이터가 완벽하게 격리되어 보안과 관리가 매우 용이하다는 장점이 있습니다.

6.3. 데이터 유효성 검사: 서버는 아무거나 믿지 않는다

클라이언트(PouchDB)는 오프라인 상태에서 자유롭게 데이터를 수정할 수 있습니다. 하지만 악의적인 사용자나 버그로 인해 잘못된 형식의 데이터(예: `email` 필드에 일반 텍스트를 넣거나, `price` 필드에 음수를 넣는 등)가 서버로 동기화될 수 있습니다.

이를 방지하기 위해 서버 CouchDB에는 `validate_doc_update` 함수를 설정할 수 있습니다. 이 함수는 새로운 문서나 수정된 문서가 데이터베이스에 저장되기 직전에 실행되는 자바스크립트 함수입니다. 여기서 데이터의 형식, 값의 범위, 필수 필드 존재 여부, 사용자 권한 등을 검사하여 유효하지 않은 데이터가 저장되는 것을 원천적으로 차단할 수 있습니다.

이러한 심화 주제들을 잘 이해하고 적용한다면, 단순히 '작동하는' 앱을 넘어 '안정적이고, 안전하며, 확장 가능한' 전문가 수준의 오프라인 퍼스트 애플리케이션을 구축할 수 있을 것입니다.

마치며: 연결이 아닌 경험을 중심으로 🌐➡️💖

지금까지 우리는 '오프라인 퍼스트'라는 패러다임의 중요성부터, 그 중심에서 활약하는 CouchDB와 PouchDB의 기술적인 깊이까지 꽤 긴 여정을 함께했습니다. 처음에는 그저 '인터넷이 끊겨도 되는 앱' 정도로 시작했지만, 이제는 그것이 훨씬 더 깊은 철학을 담고 있음을 알게 되셨을 겁니다.

오프라인 퍼스트는 기술적인 선택 이전에 사용자를 최우선으로 생각하는 디자인 철학입니다. 사용자가 어떤 환경에 있든, 어떤 기기를 사용하든, 그들의 경험이 네트워크라는 외부 요인에 의해 방해받아서는 안 된다는 선언과도 같습니다. 우리는 더 이상 사용자에게 "연결 상태를 확인하고 다시 시도하세요"라는 메시지를 보여주며 책임을 떠넘기는 대신, "걱정 마세요, 모든 것이 잘 처리되고 있습니다"라는 안정감을 주어야 합니다.

CouchDB는 이러한 철학을 현실로 만들어주는 놀라운 도구입니다. 그 핵심에 있는 MVCC와 복제 프로토콜은 수십 년간 연구된 분산 시스템 이론의 정수가 담겨있습니다. 덕분에 개발자들은 데이터 동기화라는 복잡한 괴물과 직접 씨름하는 대신, 애플리케이션의 본질적인 가치를 만드는 데 더 집중할 수 있게 되었습니다.

우리가 만들어야 할 미래의 애플리케이션은 '인터넷에 연결된' 앱이 아니라, 사용자의 삶에 '연결된' 앱입니다. 오프라인 퍼스트는 그 미래를 향한 가장 확실하고 올바른 첫걸음입니다. 이제, 연결의 제약에서 벗어나 진정으로 자유롭고 강력한 애플리케이션을 만들어나갈 준비가 되셨기를 바랍니다.