앱 MVP Android WorkManager: 즉시 처리·조건·중복 작업을 나누는 5가지 기준

앱에서 “나중에 서버에 올리면 되는 일”을 전부 같은 백그라운드 처리로 묶으면, 사용자가 화면을 떠난 뒤 누락되거나 같은 요청이 여러 번 쌓인 이유를 설명하기 어려워집니다. 반대로 사용자가 지금 결과를 기다리는 작업까지 지연 실행으로 넘기면, 실제 화면의 반응이 늦어집니다.

Android MVP의 WorkManager는 단순히 작업을 등록하는 도구가 아니라, 언제 실행되어야 하는지·무엇이 한 번만 실행돼야 하는지·어디서 완료를 확인할지를 분리해 기록하는 장치로 쓰는 편이 안전합니다.

이 글은 Android 앱에서 나중에 재시도해도 되는 동기화·업로드·정리 작업을 대상으로 합니다. 사용자가 보면서 즉시 끝나야 하는 화면 계산, 지속적인 위치 기록처럼 중단되면 안 되는 작업, 특정 시각을 보장해야 하는 알림은 같은 선택지가 아닐 수 있습니다. Android 공식 문서도 작업의 성격에 따라 비동기 처리·작업 스케줄링·포그라운드 서비스를 구분해 보라고 안내합니다.

먼저 “지금 끝나야 하는 일”과 “나중에 끝나도 되는 일”을 가릅니다

Android Developers는 앱이 백그라운드가 된 뒤에도 이어져야 하는 작업에는 보통 WorkManager를 우선 검토하되, 작업 종류에 따라 다른 API가 더 맞을 수 있다고 설명합니다. 화면이 살아 있는 동안만 필요한 짧은 계산은 일반 비동기 처리로 충분할 수 있습니다.

사용자가 결과를 기다리며 중단되면 안 되는 작업은 별도 사용자 가시성·제약을 검토해야 합니다. 즉 “백그라운드”라는 단어 하나로 구현을 결정하지 말고, 화면 이탈 뒤 지속성·지연 허용·사용자 가시성을 먼저 적습니다.

결정 기록 예시: “영수증 이미지 업로드는 네트워크가 돌아온 뒤 재시도해도 되며, 같은 영수증 ID의 중복 저장은 서버가 거절한다. 사용자는 전송 대기 상태를 볼 수 있다.” 이는 제품 설계 예시이며, 실제 정책과 데이터 구조는 서비스마다 다릅니다.

작업 자체와 실행 조건을 서로 다른 필드로 둡니다

Worker는 수행할 단위를, WorkRequest는 언제·어떤 조건에서 실행할지를 표현합니다. 공식 시작 가이드에 따르면 doWork()의 결과는 성공·실패·나중 재시도 여부를 WorkManager에 알립니다. 여기서 중요한 것은 “재시도”를 오류 문구로만 남기지 않는 것입니다. 어떤 오류가 재시도 대상인지, 사용자 입력이 다시 필요한지, 서버가 이미 처리했는지를 별도 상태로 둬야 같은 작업이 계속 반복되는 것을 막을 수 있습니다.

1. 업무 키: 사진, 주문, 동기화 묶음처럼 사용자 행동과 연결되는 식별자

2. 실행 조건: 네트워크·충전 등 실제로 필요한 조건만 선택

3. 입력 스냅샷: 실행 시점에 바뀌어도 되는 값과 고정해야 하는 값을 구분

4. 재시도 판단: 일시적 네트워크 오류와 잘못된 입력을 같은 실패로 처리하지 않기

5. 서버 완료 증거: HTTP 성공만이 아니라 해당 업무 키가 처리됐는지 확인

WorkManager의 실제 실행 시각은 요청의 제약 조건과 시스템 최적화에 따라 달라질 수 있습니다. 따라서 “매일 오전 9시에 반드시 처리됨” 같은 제품 약속을 Worker 등록만으로 만들지 않는 편이 좋습니다. 사용자의 약속 시간, 서버 마감, 알림처럼 시간 정확도가 핵심인 경우는 요구사항을 다시 분류하고 실제 완료 확인 경로를 설계해야 합니다.

같은 업무가 겹치지 않게 고유 작업 이름을 먼저 정합니다

한 사용자가 버튼을 두 번 누르거나, 화면 재진입·앱 재시작·푸시 수신이 겹치면 같은 요청이 여러 번 enqueue될 수 있습니다. Android Developers의 WorkManager 관리 가이드는 이런 중복을 피하기 위해 사람이 읽을 수 있는 이름의 고유 작업을 사용하라고 설명합니다. 일회성 작업에는 enqueueUniqueWork(), 반복 작업에는 enqueueUniquePeriodicWork()가 쓰입니다.

이름은 기능명이 아니라 “중복을 막을 범위”를 표현합니다

예를 들어 모든 업로드를 하나로 막고 싶다면 upload-all처럼 넓은 이름을, 한 영수증의 중복만 막고 싶다면 receipt-upload:<receipt-id>처럼 업무 키를 포함한 이름을 검토할 수 있습니다. 어느 쪽이 맞는지는 기술 선호가 아니라 동시 실행이 사용자·서버에 어떤 영향을 주는지에 달려 있습니다. 이름 규칙과 업무 키를 문서에 같이 남겨야 운영 중 WorkInfo를 조회할 때 무엇을 찾는지 알 수 있습니다.

충돌 정책도 사용자 경험의 일부입니다. KEEP은 이미 대기·실행 중인 작업을 두고 새 요청을 무시합니다. REPLACE는 기존 작업을 취소하고 새 요청으로 바꿉니다. APPEND는 기존 작업 뒤에 연결하지만, 앞선 작업이 취소되거나 실패하면 뒤 작업도 영향을 받을 수 있습니다.

실패와 무관하게 뒤 작업을 이어야 한다면 공식 문서에 소개된 APPEND_OR_REPLACE의 의미를 검토할 수 있습니다. 정책 이름만 보고 고르지 말고, 기존 결과가 남은 상태에서 새 입력이 들어왔을 때의 화면·서버 상태를 한 문장으로 먼저 써보세요.

앱의 업로드·동기화·재시도 흐름을 실제 제품 요구사항에 맞게 줄이고 싶다면, 유인어스와 함께 기능 우선순위와 완료 기준을 정리해 볼 수 있습니다. MVP 범위 상담하기

완료는 enqueue가 아니라 WorkInfo와 업무 결과를 함께 확인합니다

enqueue()가 성공했다는 것은 실행 요청이 전달됐다는 뜻이지, 사용자 업무가 끝났다는 뜻은 아닙니다. WorkManager는 ID·고유 작업 이름·태그로 상태를 조회할 수 있고, WorkInfo에는 현재 상태와 출력 데이터가 담길 수 있습니다. MVP 화면에서는 “전송 요청됨”, “대기 중”, “재시도 예정”, “처리 완료”, “사용자 조치 필요”처럼 제품 언어로 해석할 기준을 정해 두는 편이 낫습니다.

• 앱 내부 관찰: 고유 작업 이름, WorkInfo 상태, 마지막 전환 시각

• 서버 관찰: 업무 키별 수신·중복 처리·최종 결과

• 사용자 화면: 지금 무엇을 기다리는지와 다시 시도할 수 있는지

• 운영 점검: 실패·취소·반복 대기 상태가 쌓이는지

이 네 기록은 서로 대체되지 않습니다. 앱의 상태가 SUCCEEDED여도 서버 업무 규칙이 원하는 완료를 뜻하는지 별도 확인이 필요하고, 서버가 처리했어도 사용자의 화면이 갱신되지 않았을 수 있습니다. 반대로 단순히 “백그라운드 처리됨”이라는 분석 이벤트만으로 실제 업로드 완료를 주장해서도 안 됩니다.

중단·취소·재시도는 예외가 아니라 사전 설계 항목입니다

WorkManager 작업은 명시 취소, 고유 작업의 교체 정책, 제약 조건 변화, 시스템의 중단 지시 등으로 멈출 수 있습니다. 공식 관리 가이드는 실행 중인 Worker가 중단될 때 정리 처리를 하고, 반복·긴 작업에서는 중단 신호를 확인하라고 안내합니다. 따라서 Worker 안에서 파일·DB 핸들을 정리할 책임, 부분 업로드를 다시 시작할 기준, 서버가 같은 업무 키를 다시 받았을 때의 처리 방식을 분리해 두어야 합니다.

특히 “재시도”는 무조건 다시 보내는 버튼이 아닙니다. 네트워크처럼 일시적인 조건, 인증 만료처럼 사용자 재로그인이 필요한 조건, 잘못된 파일처럼 수정이 필요한 조건은 다른 다음 행동을 가져야 합니다. 이 구분이 없으면 사용자는 완료 화면을 봤지만 실제로는 대기 중인 상태가 남고, 팀은 같은 오류를 여러 번 처리하게 됩니다.

출시 전에는 작업 하나를 끝까지 추적하는 QA를 합니다

처음에는 대표 작업 하나만 골라 앱 화면·WorkManager·서버·재시도 화면을 끝까지 따라가면 됩니다. 네트워크를 끊었다가 되돌리고, 같은 버튼을 연속으로 누르고, 앱을 종료한 뒤 다시 열고, 같은 업무 키를 다시 보내는 시나리오를 별도로 기록하세요. 목적은 모든 기기에서 같은 실행 시각을 약속하는 것이 아니라, 중복·대기·취소가 발생했을 때 제품이 어떤 상태를 보여 주고 서버가 무엇을 보존하는지 확인하는 것입니다.

배터리 조건과 작업 실행을 함께 검토해야 한다면 앱 MVP 배터리 사용: 갱신·조건·중단·관찰을 나누는 5가지 기준도 이어서 참고할 수 있습니다. 이번 글의 핵심은 단순합니다. Worker를 추가하기 전에 작업의 완료 정의를 쓰고, 고유 이름으로 중복 범위를 정하고, enqueue 이후의 상태와 서버 결과를 같이 확인하세요.

지금 앱의 업로드·동기화·알림 작업 중 무엇을 WorkManager로 남길지 판단이 필요하다면, 사용자 흐름과 출시 제약을 기준으로 MVP 범위를 함께 정리해 보세요. 유인어스에 MVP 범위 문의하기

공식 원문

구현 전에는 현재 사용하는 AndroidX 버전과 배포 조건도 함께 확인하세요. 이 글의 기술 사실은 Android background tasks overview, Getting started with WorkManager, Managing work를 직접 읽어 정리했습니다.

자주 묻는 질문

WorkManager에 등록하면 정확한 시각에 실행되나요?

아닙니다. 공식 문서상 실제 실행 시각은 설정한 제약 조건과 시스템 최적화의 영향을 받습니다. 정확한 시각 자체가 제품 약속이라면 요구사항과 적합한 API를 별도로 검토해야 합니다.

고유 작업 이름은 항상 하나만 쓰면 되나요?

아닙니다. 무엇의 중복을 막을지에 따라 범위가 달라집니다. 전체 동기화 하나만 허용할지, 사용자·문서·주문 같은 업무 키별로 하나씩 허용할지를 먼저 정해야 합니다.

WorkInfo가 성공이면 서버 처리도 완료된 건가요?

앱 작업의 성공 상태와 서비스 업무의 완료 기준은 분리해서 봐야 합니다. 서버가 업무 키를 처리했는지, 사용자 화면에 반영됐는지를 함께 확인해야 합니다.

실패하면 모두 Result.retry()로 처리하면 되나요?

아닙니다. 일시적인 오류와 사용자 조치가 필요한 오류는 다음 행동이 다릅니다. 재시도 전에 입력·인증·서버 중복 처리 기준을 구분하는 편이 안전합니다.