PURPLEOCEAN 개발 노트

타이머 앱을 만들고 운영하다 보면 백그라운드 처리 때문에 골치 아픈 일이 많습니다. 화면이 켜져 있을 때는 잘 돌다가도, 사용자가 홈 버튼을 누르고 다른 앱을 보거나 화면을 꺼버리면 타이머가 멈추거나 종료 알림이 안 오는 현상이 발생하곤 합니다. 처음에는 무조건 Foreground Service로 다 돌리면 해결될 줄 알았는데, 실제 서비스를 운영해 보니 배터리 소모나 구글 플레이 정책 측면에서 고려할 게 한두 가지가 아니었습니다. 자꾸 까먹어서 나중에도 바로 보고 적용할 수 있도록 실무 기준으로 정리해 둡니다. 백그라운드 타이머 운영 시 자주 겪는 문제 보통 처음 구현할 때 아래와 같은 지점에서 막히거나 실수를 많이 합니다. 화면이 꺼지면 타이머가 같이 멈춰버리는 현상 앱을 백그라운드로 보낸 뒤 타이머 종료 알림이 먹통이 되는 상황 모든 카운트다운을 무조건 Foreground Service로 처리해서 배터리를 낭비하는 구조 상단 알림창에 일시정지, 재개, 종료 같은 제어 버튼이 없는 불편함 알림 채널 중요도를 너무 높여서 사용자에게 과도한 피로감을 주는 경우 PendingIntent 나 로그에 사용자 ID나 민감한 데이터를 그대로 남기는 보안 실수 백그라운드 타이머를 작업할 때는 "코드를 백그라운드에서 계속 실행한다"가 아니라, "사용자가 인지할 수 있는 지속된 작업과 종료 알림을 조합한다"로 접근하는 것이 운영상 훨씬 안전합니다. 핵심 개념: 계산은 상태로, 표시는 알림으로 분리 타이머의 남은 시간은 매초 줄어드는 루프 코드가 아니라, 시작 기준 시각과 현재 시각의 차이 로 계산하는 것이 정석입니다. Foreground Service는 시간을 계산하는 주체가 아니라, 백그라운드에서도 사용자에게 "타이머가 돌고 있다"는 것을 보여주고 제어할 수 있게 돕는 창구일 뿐입니다. 저의 경우 아래와 같이 역할을 나누어 구조를 잡았습니다. 구성 요소 역할 주의할 점 TimerSession 시작 시각, 전체 시간, 일...

시험 타이머, 운동 타이머, 집중 타이머 같은 앱을 개발할 때 초보자가 가장 많이 하는 실수가 있습니다. 바로 화면에 보이는 카운트다운 숫자를 그대로 '타이머의 진짜 상태'라고 믿고 설계하는 것입니다. 저의 경우에도 처음에 CountDownTimer 나 코루틴 delay(1000) 를 사용해서 1초마다 숫자를 단순히 줄이는 방식으로 구현했었습니다. 하지만 이렇게 하면 앱이 백그라운드로 가거나, 화면이 회전되거나, 시스템에 의해 프로세스가 종료되었을 때 시간이 완전히 틀어지는 문제가 발생하더라고요. 타이머 앱을 안정적으로 운영하려면 "1초마다 숫자를 줄이는 방식"이 아니라 "언제 시작했고 언제 끝나야 하는지" 기준 시각을 저장하는 방식으로 접근해야 합니다. 나중에 제가 다시 개발할 때 참고하기 위해 핵심 설계 구조와 구현 코드를 정리해 둡니다. 1. 타이머 구현 시 자주 겪는 문제들 단순히 UI의 Tick 값만 믿고 개발하면 아래와 같은 실무 문제에 부딪히게 됩니다. CountDownTimer 가 돌던 중 화면을 회전하면 Activity가 재생성되면서 타이머가 처음부터 다시 시작됨 사용자가 홈 버튼을 눌러 앱이 백그라운드로 간 동안 코루틴이나 타이머가 멈춰서 시간이 안 감 기기 시스템 시각을 사용자가 수동으로 바꾸거나 해외 로밍 등으로 네트워크 시간이 동기화되면 남은 시간이 비정상적으로 계산됨 일시정지(Pause)와 재개(Resume)를 반복할 때 오차가 누적됨 결론부터 말씀드리면, 타이머는 단순한 UI 카운트다운 인터페이스가 아니라 '상태 머신'과 '시간 계산 로직'의 결합 으로 바라보고 설계해야 합니다. 2. 핵심 개념: '틱(Tick)'이 아니라 '기준 시각' 저장하기 타이머의 남은 시간은 저장된 고정 값이 아니라 "현재 시점 기준으로 매번 계산하는 결과"여야 합니다. 이를 위해 필요한 핵심 데이터 모델은 다음과 같습니다. 항목 의...