오프라인 우선 앱 빌드
오프라인 우선 앱은 인터넷 연결 없이도 모든 기능 또는 중요한 핵심 기능을 실행할 수 있는 애플리케이션이다. 이는 비즈니스 로직의 일부 또는 전부를 오프라인에서도 실행할 수 있음을 의미한다.
오프라인 우선 앱을 빌드할 때는 애플리케이션 데이터와 비즈니스 로직에 대한 액세스를 제공하는 데이터 레이어를 고려해야 한다. 앱은 경우에 따라 기기 외부에 있는 소스의 이 데이터를 새로고침해야 할 수 있다. 이 과정에서 최신 정보를 가져오려면 네트워크 리소스를 호출해야 할 수 있다.
네트워크 가용성이 항상 보장되는 것은 아니다. 기기의 네트워크 연결이 불안정하거나 느린 경우가 종종 발생한다.
사용자는 다음과 같은 현상을 경험할 수 있다:
- 인터넷 대역폭 제한
- 일시적인 연결 장애(예: 엘리베이터에 탑승하거나 터널을 지나갈 때)
- 비정기적인 데이터 액세스(예: Wi-Fi 전용 태블릿)
앱은 이러한 상황에서 각종 이유로 인해 부적절하게 작동할 수 있다.
앱이 오프라인에서 올바르게 작동하려면 다음을 할 수 있어야 한다.
- 안정적인 네트워크 연결 없이도 사용 가능한 상태를 유지한다.
- 첫 번째 네트워크 호출이 완료되거나 실패할 때까지 기다리는 대신 사용자에게 즉시 로컬 데이터를 제공한다.
- 배터리 및 데이터 상태를 염두에 두고 데이터를 가져온다. 예를 들어, 충전 중이거나 Wi-Fi를 사용하고 있는 경우와 같이 최적의 조건에서만 데이터 가져오기를 요청할 수 있다.
위 기준을 충족하는 앱을 오프라인 우선 앱이라고 한다.
오프라인 우선 앱 설계하기
오프라인 우선 앱 설계 시 데이터 레이어와 앱 데이터를 대상으로 할 수 있는 기본 연산인 읽기와 쓰기를 고려해야 한다.
- 읽기: 앱의 다른 부분에서 사용할 데이터를 가져온다.
- 쓰기: 사용자 입력을 저장하여 나중에 가져올 수 있도록 한다.
오프라인 우선 앱에는 네트워크 액세스 없이도 데이터를 읽을 수 있는 로컬 데이터 소스가 필수적이다.
오프라인 우선 데이터 레이어
-
로컬 데이터 소스:
- 기기 내부에 저장된 데이터
- 인터넷 연결 없이 접근 가능
- 데이터 접근 속도가 빠르다.
-
네트워크 데이터 소스:
- 원격 서버에 저장된 데이터
- 인터넷 연결이 필요하다.
- 데이터 접근 속도가 상대적으로 느릴 수 있다.
Spotify 예시
-
로컬 데이터 소스 예시:
- 다운로드한 음악 파일
- 오프라인 재생 목록
- 사용자의 앱 설정 (음질 설정, 다크 모드 등)
- 최근 검색 기록
-
네트워크 데이터 소스 예시:
- 스트리밍 음악 파일
- 아티스트 정보 및 앨범 아트
- 실시간 차트 정보
- 친구의 재생 목록
로컬 데이터는 즉시 사용 가능하지만, 네트워크 데이터는 API 요청을 통해 가져와야 한다.
데이터 읽기와 쓰기
읽기
오프라인 우선 앱의 외부 계층은, 항상 먼저 로컬 데이터 소스에서 데이터를 읽어야 한다.
네트워크 상태와 관계없이 앱이 즉시 반응할 수 있게 하며, 필요한 경우에만 네트워크 요청을 수행하여 데이터를 업데이트한다.
External Layers(외부 계층):
앱의 아키텍처에서 사용자 인터페이스(UI)나 비즈니스 로직과 같은 상위 계층을 의미한다.
데이터를 직접 처리하거나 저장하지 않고, 데이터 소스로부터 정보를 받아 사용한다.
Local Data Source(로컬 데이터 소스):
기기 내부에 저장된 데이터를 의미한다.
앱의 데이터베이스, 캐시, 또는 파일 시스템 등이 여기에 해당한다.
쓰기
오프라인 우선 앱의 쓰기는 일반적으로 비동기 API를 사용하여 UI 스레드를 차단하지 않도록 한다. 쓰기 전략은 다음과 같이 나뉜다:
- 온라인 전용 쓰기: 네트워크를 통해 쓰기를 시도하며, 실패 시 예외를 발생시킨다.
- 큐에 추가된 쓰기: 쓰려는 데이터를 큐에 넣고, 온라인 상태가 되면 지수 백오프를 사용하여 처리한다.
- 지연 쓰기: 먼저 로컬 데이터 소스에 데이터를 저장한 후, 가능한 한 빨리 네트워크에 알리도록 한다.
예시
1. 온라인 전용 쓰기
Spotify에서 사용자가 새로 생성한 플레이리스트를 서버에 저장할 때 이 전략이 사용될 수 있다. 사용자가 플레이리스트를 만들고 "저장" 버튼을 누르면, 앱은 네트워크를 통해 서버에 직접 쓰기를 시도한다. 만약 서버에 연결이 실패하면, 사용자에게 오류 메시지를 표시하고 "재시도" 옵션을 제공한다. 이 경우 데이터는 로컬에 저장되지 않으며, 반드시 온라인 상태여야 한다.
2. 큐에 추가된 쓰기
사용자가 오프라인 상태에서 음악을 좋아요(좋아요 표시)를 클릭할 때 이 전략이 적용될 수 있다. 사용자는 좋아요를 누르지만 현재 네트워크에 연결되어 있지 않다면, 앱은 해당 좋아요 정보를 큐에 추가한다. 사용자가 다시 온라인 상태가 되면, 앱은 지수 백오프를 사용하여 서버에 좋아요를 보내고, 성공적으로 저장되면 큐에서 해당 작업을 제거한다. 만약 서버가 응답하지 않는 경우, 몇 초 후에 다시 시도하게 된다.
3. 지연 쓰기
사용자가 오프라인 상태에서 음악 재생 목록에 곡을 추가할 때 이 전략이 사용될 수 있다. 사용자가 곡을 추가하면, 그 곡의 정보는 즉시 로컬 데이터베이스에 저장된다. 이후 사용자가 온라인 상태가 되면, 앱은 백그라운드에서 자동으로 해당 정보를 서버에 전송하여 플레이리스트를 업데이트한다. 이 과정에서 데이터 충돌이 발생할 수 있으므로, 예를 들어 다른 기기에서 추가된 곡과의 일치 여부를 확인해야 한다.
동기화 및 충돌 해결
오프라인 우선 앱의 연결이 복원되면 로컬 데이터 소스의 데이터와 네트워크 데이터 소스의 데이터가 조정되어야 한다. 이 프로세스를 동기화라고 한다.
앱이 네트워크 데이터 소스와 데이터를 동기화하는 방법에는 두 가지가 있다.
- 풀 기반 동기화
- 푸시 기반 동기화
풀 기반 동기화
오프라인 앱이 온라인 상태가 되었을 때 서버로부터 데이터를 요청하고 받아온다.
사용자가 수동으로 동기화를 시작하거나, 앱이 주기적으로 또는 특정 조건(예: 네트워크 연결 감지)에 따라 동기화를 시도한다.
ex) 유튜브 뮤직
푸시 기반 동기화
서버에서 변경사항이 있을 때 앱에 알림을 보내고, 앱이 온라인 상태가 되면 즉시 동기화를 수행한다.
오프라인 상태에서는 푸시 알림을 받을 수 없지만, 온라인 상태가 되면 누적된 변경사항을 한 번에 받을 수 있다.
ex) 협업 도구
예: Slack, Microsoft Teams, Trello
새로운 메시지, 태스크 할당, 상태 변경 등이 실시간으로 푸시된다.
오프라인 상태에서 발생한 변경사항은 온라인 연결 시 즉시 동기화된다.
하이브리드 동기화
일부 앱에서는 데이터의 성격에 따라 풀 또는 푸시 기반 방법을 혼합해 사용하는 하이브리드 접근 방식을 채택하기도 한다. 예를 들어, 소셜 미디어 앱은 피드가 자주 업데이트되므로 풀 기반 동기화를 사용하고, 사용자 정보는 푸시 기반 동기화를 사용할 수 있다.
충돌 해결
오프라인 상태에서 로컬에 쓰인 데이터와 네트워크 데이터 소스 간에 충돌이 발생할 수 있다. 이 경우 충돌을 해결하기 위해 버전 관리가 필요하다. 변경 사항을 추적하기 위해 기록을 유지하고, 이를 기반으로 메타데이터를 네트워크 데이터 소스에 전달한다. 일반적인 충돌 해결 전략은 '마지막 쓰기 적용'이다.
마지막 쓰기 적용
이 방법에서는 기기가 네트워크에 쓴 데이터에 타임스탬프를 추가한다. 네트워크 데이터 소스는 수신된 데이터를 바탕으로 현재 상태보다 오래된 데이터는 삭제하고, 최신 데이터만 유지한다.
예시
두 기기가 모두 오프라인 상태에서 데이터를 작성하고, 온라인 상태로 전환되었을 때, 네트워크는 나중에 데이터를 쓴 기기의 정보를 유지한다.
