즉시성 중심의 화면 타이머와 조건 충족 후 보장 실행되는 지속 작업을 목적에 맞게 나누는 기준을 설명합니다. 여러 선택지를 한 번에 적용하기보다 ‘앱 내부 타이머’부터 확인합니다. 화면의 카운트다운이나 짧은 폴링처럼 프로세스가 살아 있는 동안의 즉시성이 목적입니다. 앱이 중단되면 계속 실행된다고 가정하지 않습니다.
이 글의 범위
실제 경험이나 측정 결과를 가정하지 않고, 공식 문서로 확인 가능한 개념과 적용 순서를 일반 가이드로 설명합니다. 제품 버전과 서비스 정책은 바뀔 수 있으므로 적용 전 연결된 공식 문서를 다시 확인하세요.
처음 확인할 경계
앱 타이머는 살아 있는 화면의 시간 흐름을, WorkManager는 제약 속에서도 완료해야 하는 일을 다룹니다. ‘앱 내부 타이머’에서 시작해 ‘WorkManager’와의 경계를 정하면 구현할 범위와 실패했을 때 확인할 지점을 구분하기 쉬워집니다.
운영 단계에서 자주 생기는 오해
- setInterval이 백그라운드에서도 같은 주기로 실행된다고 믿기
- WorkManager로 초 단위 알람을 구현하기
- 재시도마다 같은 데이터를 중복 전송하기
- 작업 성공과 서버가 실제 반영한 결과를 구분하지 않기
 |
| WorkManager와 앱 내부 타이머를 구분해서 쓰는 방법 핵심 판단 흐름 설명용 개념도 |
그림 1. WorkManager와 앱 내부 타이머를 구분해서 쓰는 방법의 핵심 판단 순서를 정리한 설명용 개념도입니다. 실제 서비스 화면, 운영 로그 또는 측정 결과가 아닙니다.
작업 방식을 선택하는 순서
- 작업이 화면과 함께 끝나도 되는지 판단합니다.
- 정확한 시각과 최종 완료 중 무엇이 더 중요한지 구분합니다.
- 필요한 네트워크·전원 조건과 중복 실행 비용을 적습니다.
- 재실행 가능한 단위로 쪼개고 고유 작업 이름을 정합니다.
- 프로세스 종료와 네트워크 전환을 포함해 테스트합니다.
실행 목적부터 구분하는 기준
앱 내부 타이머
화면의 카운트다운이나 짧은 폴링처럼 프로세스가 살아 있는 동안의 즉시성이 목적입니다. 앱이 중단되면 계속 실행된다고 가정하지 않습니다.
WorkManager
앱이 종료되거나 기기가 재시작돼도 조건이 충족될 때 완료해야 하는 지속 작업에 사용합니다. 실행 시각의 초 단위 정확성을 보장하는 도구는 아닙니다.
제약 조건
네트워크, 충전, 저장 공간 같은 조건을 선언해 불가능한 상황에서 반복 실패하지 않게 합니다.
멱등성과 재시도
작업이 다시 실행돼도 같은 결과가 되게 설계하고 일시 오류에만 제한된 백오프를 적용합니다.
관찰 가능한 결과
작업 ID와 상태, 마지막 오류를 기록해 UI와 운영 로그에서 완료·실패·취소를 구분합니다.
실제 적용과 설명을 대조하기
| 확인 항목 | 질문 |
|---|---|
| 첫 기준: 앱 내부 타이머 | 변경 전에 전제와 목적을 확인했는가? |
| 분리 대상: WorkManager | 다른 책임과 섞이지 않게 경계를 정했는가? |
| 피할 패턴: setInterval이 백그라운드에서도 같은 주기로 실행된다고 믿기 | 본문에서 경고한 패턴이 남아 있지 않은가? |
| 오류와 복구 | 정상 경로뿐 아니라 실패와 되돌리기도 확인했는가? |
적용 순서 요약
앱 타이머는 살아 있는 화면의 시간 흐름을, WorkManager는 제약 속에서도 완료해야 하는 일을 다룹니다. 실행 정확도와 완료 보장, 재시도 비용을 먼저 구분하면 적절한 도구를 선택하고 실패를 추적하기 쉬워집니다.
