PURPLEOCEAN 개발 노트

제주도에서 앱을 만들고 운영하다 보면, 중산간 지역이나 해안도로, 또는 사람이 갑자기 몰리는 축제장이나 지하 주차장 같은 곳에서 네트워크가 툭툭 끊긴다는 피드백을 자주 받습니다. 서버 API만 잘 연결해 두면 개발할 때는 아무 문제 없어 보이지만, 실제 현장에서는 네트워크 오류가 예외 상황이 아니라 아주 흔하게 일어나는 일상입니다. 그렇다고 모든 데이터를 무조건 로컬에 다 저장해 두면, 오래된 데이터(종료된 축제나 바뀐 영업시간 등) 때문에 사용자에게 잘못된 안내를 하게 되어 또 문제가 터집니다. 나중에 제가 다시 보면서 바로 적용하려고, Room 캐시와 WorkManager 백그라운드 동기화 구조를 어떻게 잡으면 되는지 실무 기준으로 정리해 둡니다. 내가 운영하며 겪은 주요 문제들 보통 오프라인 캐시 구조를 대충 잡으면 아래와 같은 상황에서 앱이 먹통이 되거나 컴플레인이 들어옵니다. 네트워크 좀 안 터진다고 관광지 목록 전체가 빈 화면으로 나오는 현상 장소 이름 같은 기본 정보와 실시간 혼잡도·운영 정보를 같은 만료 기간(TTL)으로 묶어서 저장해 버리는 실수 오래된 행사 일정이 캐시에 남아 있어서 이미 끝난 축제가 계속 노출되는 문제 사용자가 지금 보는 데이터가 언제 기준 데이터인지 알 수 없는 답답함 앱 켤 때마다 모든 데이터를 새로 동기화하느라 초기 진입이 엄청 느려지는 현상 오프라인 캐시는 단순히 "화면을 빠르게 보여주는 기능"이 아니라, "네트워크가 실패해도 앱의 최소 기능은 유지하게 만드는 설계"로 접근해야 운영할 때 고생을 안 합니다. 1. 데이터 성격별 캐시 기준 나누기 가장 먼저 데이터의 성격에 따라 캐시를 할지 말지, 갱신은 언제 할지 기준부터 나눠야 합니다. 전부 똑같은 주기로 갱신하면 데이터 신뢰도가 떨어집니다. 데이터 종류 예시 필드 캐시 적합도 갱신 및 만료 기준 장소 기본 정보 이름, 주소, 좌표, 카테고리 높음 앱 버전 업데이트 또는 주 단위 동기화 즐겨찾기 사용자가 저장한 장소 높음 로컬 우선...

앱을 개발하고 운영하다 보면 FCM(Firebase Cloud Messaging)을 연동할 일이 참 많습니다. 푸시 메시지가 올 때 단순히 알림만 띄우면 상관없는데, 메시지를 신호탄 삼아 서버에서 상세 데이터를 다시 긁어오거나 로컬 DB를 동기화해야 하는 경우가 꼭 생기더군요. 저의 경우도 처음에는 FirebaseMessagingService.onMessageReceived() 안에서 가볍게 네트워크 요청을 보냈다가, 앱이 백그라운드에 있을 때 작업이 툭 끊기거나 실패 시 재시도가 안 돼서 골치를 썩은 적이 있습니다. 자꾸 까먹기도 하고, 실무에서 실수하기 쉬운 부분이라 정돈해서 기록해 둡니다. 1. 운영하다 보면 자주 하는 실수 (내가 겪은 상황) FCM 수신 처리에서 문제가 생기는 코드는 보통 아래와 같은 상황을 간과할 때 발생합니다. onMessageReceived() 안에서 긴 네트워크 요청(API 호출)을 바로 실행함 실패하면 다시 시도해야 하는 작업을 일회성 처리로 대충 끝냄 앱이 백그라운드 상태일 때 OS 제약으로 작업이 중간에 강제 종료되는 상황을 고려 안 함 넘어온 data payload를 검증하지 않고 그대로 Worker 인풋으로 넘김 로그에 FCM 토큰, 서버 URL, 사용자 식별자(ID)를 그대로 남겨 보안 필터에 걸림 알림을 표시하는 UI 책임과 데이터 동기화 책임을 한 함수에서 모두 처리함 운영 관점에서는 FCM 수신 콜백을 "모든 작업을 수행하는 시작점"이 아니라, "작업을 분류하고 안전한 곳으로 위임하는 진입점"으로 보는 것이 좋습니다. 2. 해결 방법: 즉시 처리와 위임 처리 나누기 작업 성격에 따라 FCM 콜백에서 바로 끝낼지, WorkManager 로 넘길지 확실히 나눠야 유지보수가 편합니다. 제가 실무에서 잡은 기준은 이렇습니다. 작업 종류 처리 위치 이유 단순 알림 표시 onMessageReceived() 짧고 즉시 끝나는 작업입니다. payload 데이터 검증 onMessageRec...