오프라인 퍼스트, hearth로 직접 구현한 이유
by DD
19시간 전
조회수 16
Linear와 같은 오프라인 퍼스트(Offline-First) 아키텍처를 채택하여 사용자 경험 향상 및 즉각적인 화면 반응성 확보를 목표함
기존 오픈소스 라이브러리 대신 사내 라이브러리 hearth를 직접 개발하여 자체 서버 환경에 최적화된 동기화 로직 구현
LWW(Last-Writer-Wins) 및 낙관적 쓰기(Optimistic Writes) 패턴을 적용하여 동시성 문제 해결 및 실시간 데이터 반영 구현
캐시 축출(Cache Eviction)과 동기화 기록의 결합으로 데이터 정합성(Data Consistency)을 강화하고, 향후 델타 동기화(Delta Sync) 도입을 계획함
오프라인 퍼스트(Offline-First) 아키텍처의 핵심 원리
오프라인 퍼스트 아키텍처는 로컬 데이터베이스(Local Database)를 화면 렌더링의 기준으로 삼고, 서버와의 동기화는 비동기적으로 처리하는 방식입니다.
즉각적인 UI 반응성: 사용자의 모든 조작은 로컬 DB에 먼저 기록되며, 서버 응답을 기다리지 않아 스피너(Spinner) 없는 즉각적인 화면 전환이 가능합니다.
오프라인 작업 지원: 네트워크 연결이 불안정하거나 끊긴 환경에서도 데이터 읽기 및 쓰기 작업이 가능하여 사용자 경험을 크게 향상시킵니다.
서버 동기화: 서버 변경 사항은 로컬 DB에 반영되고, 사용자의 로컬 변경 사항은 백그라운드에서 서버로 전송되어 최종 일관성(Eventual Consistency)을 유지합니다.
이 구조는 사용자 경험(User Experience)과 개발 편의성(Developer Convenience) 측면에서 큰 이점을 제공합니다.
hearth 직접 개발 결정의 배경
기존 오픈소스 라이브러리(WatermelonDB, RxDB) 대신 hearth를 직접 개발한 주된 이유는 자체 API 서버 환경과의 최적화 및 군더더기 없는 구조 확보입니다.
서버 동기화 구현 주체: 자체 API 서버를 사용하는 경우, 어떤 라이브러리를 선택하든 서버 측 동기화 로직 구현은 개발팀의 몫입니다.
추상화 계층의 불필요성: RxDB의 다양한 스토리지 지원을 위한 추상화 계층은 단일 자체 서버 환경에서는 오히려 불필요한 복잡성을 야기할 수 있습니다.
실전 검증된 코드 활용: 사내 프로젝트에서 이미 작동이 검증된 로컬 동기화 코드를 재사용하는 것이 효율적이라는 판단이 있었습니다.
hearth는 이러한 조건들을 고려하여 도메인 무지(Domain-Agnostic) 구조로 다듬어져 여러 제품에서 공유 가능한 라이브러리로 독립했습니다.
hearth의 충돌 해결 전략: LWW와 낙관적 쓰기
hearth는 동시성 문제를 해결하기 위해 LWW(Last-Writer-Wins)와 낙관적 쓰기(Optimistic Writes) 패턴을 채택했습니다.
LWW (Last-Writer-Wins): 여러 변경이 동시에 발생했을 때, 타임스탬프(Timestamp)를 기준으로 가장 최신 값을 승자로 결정합니다. 이는 서버가 부여하는 전역 순서(Global Order) 대신, 각 변경 건의 시각 정보를 활용하는 방식입니다.
낙관적 쓰기 보호: 사용자의 즉각적인 조작을 화면에 먼저 반영한 후, 서버 응답이 도착하기 전에 발생할 수 있는 데이터 덮어쓰기 문제를 방지합니다. hearth는 이를 컬럼(Field) 단위로 추적하여, 아직 서버 확인을 받지 않은 필드에 대한 서버 응답이 기존 변경을 덮어쓰지 못하도록 막습니다.
이러한 전략은 실시간 데이터 반영과 안정적인 사용자 경험을 보장하는 데 기여합니다.
데이터 정합성 강화를 위한 설계 개선
hearth는 캐시 축출(Cache Eviction)과 동기화 기록 관리에서 발생할 수 있는 데이터 정합성(Data Consistency) 문제를 해결하기 위해 설계를 개선했습니다.
과거 기록과 결과물의 결합: 기존에는 동기화 기록만 남고 실제 데이터가 캐시 축출로 사라지는 문제가 있었습니다. 이를 해결하기 위해 동기화 기록(Sync Record)을 데이터 행(Row) 자체에 포함시켜, 행이 삭제되면 기록도 함께 삭제되도록 변경했습니다.
신선도 기준 변경: 동기화 필요 여부 판단 기준을 과거 기록 조회에서 '행의 존재 여부와 신선도'로 변경하고, 이 로직을 라이브러리 내부로 회수하여 도메인 코드의 영향을 최소화했습니다.
오프라인 중 캐시 축출 금지: 데이터의 거짓 상태(Stale State)를 방지하기 위해 오프라인 중에는 캐시 축출을 금지하는 전제 조건으로 승격했습니다.
이러한 변경은 데이터 유실 방지 및 신뢰성 있는 동기화를 보장하는 데 중요합니다.
델타 동기화(Delta Sync)를 통한 구조 완성 계획
현재 hearth는 화면 진입 시 데이터를 전체 요청하지만, 향후 델타 동기화(Delta Sync) 도입을 통해 변경분만 주고받는 구조로 완성될 예정입니다.
필요성: 전체 데이터 재요청은 네트워크 부하를 줄이지 못하므로, 효율적인 데이터 전송을 위해 변경분 동기화가 필수적입니다.
기술적 과제: 단순한 마지막 동기화 시각(Last Sync Timestamp) 기반으로는 트랜잭션 시작 시점과 커밋 시점 간의 간격으로 인해 데이터 누락(Data Omission)이 발생할 수 있습니다.
서버 측 구현 필요: 안전한 델타 동기화를 위해서는 DB 커밋 로그(Commit Log) 또는 서버 발급 순서 값과 같은 백엔드 지원이 필수적입니다.
hearth는 클라이언트 측 로직 검증을 완료했으며, 이제 프론트엔드와 백엔드 협업을 통해 다음 단계인 델타 동기화 구현을 시작하려 합니다.
