⏰ 퀵라벨타이머 (QuickLabelTimer)
플랫폼·기술: iOS 앱, SwiftUI
앱 컨셉: 시간을 빠르게 설정할 수 있는 퀵 타이머에, ‘왜 맞췄는지’를 기록할 수 있는 라벨 기능을 결합한 타이머 앱
개발 목적: AI-Assisted Programming을 실제 서비스 개발에 적용하여 장단점을 살펴보고, 서비스 완성 및 운영 경험을 통해 설계 능력과 문제 해결 능력을 강화하고자 함
GitHub: https://github.com/data-sy/quick-label-timer
이번 주에 한 일
 |  |
|---|
이번 주는 삽질의 주였다.😭
앱의 핵심 기능인 알람 기능 구현에 도전했고, 지난주에 경험한 SRP 원칙을 적용해 보고자 클린 아키텍처 리팩토링을 진행했다.
[ 주요 작업 요약 ]
- 알람 기능 구현 시도
- 클린 아키텍처 적용 (TimerManager → Repository & Service 분리)
1. 알람 기능
알람 기능을 구현할 때 가장 중요한 건 무엇일까?
(간격 주는 용도의 짤. 넣을 예정)
바로 애플워치를 벗는 것이다!!
단위 테스트도 잘 통과하고 시뮬레이터에서도 문제없었는데, 정작 실기기에서 소리가 안 났다.
혹시 iOS 정책 때문인가 싶어 헤맸는데…원인은 단순했다. 내가 워치를 차고 있었던 것 😱
(워치를 착용하면 iPhone 알림은 Apple Watch로 라우팅 된다)
iOS에서 알람 기능을 만드신다면, local notification을 테스트할 때 아래 항목은 꼭 체크해 보시길…
- 애플워치를 벗었는지
- 무음 모드이진 않은지
- 소리 볼륨이 0은 아닌지
이제 실제 구현 과정을 회고하자면, 그야말로 삽질의 연속이었다.
처음엔 정책을 이렇게 정리했다.
- 시각적 신호: 로컬 알림
- 소리·진동: 오디오 세션
화면에는 로컬 알림이 배너로 뜨고, 소리와 진동은 오디오 세션을 통해 사용자가 확실히 인지할 때까지 울리도록 설계했다.
(이미지 위치 조절 예정)
단위 테스트도 잘 통과하고, 간단한 실기기 테스트에서도 정상적으로 동작했다.
“됐다!” 싶었던 순간…
타이머 시간을 조금 길게 설정하자, 소리·진동이 울리지 않았다.
원인은 바로 iOS의 Suspended 상태였다.
iOS는 앱이 사용되지 않으면 자동으로 Suspended 상태로 전환하고 개발자는 임의로 이 진입을 막을 수 없다. 애플이 허용한 일부 백그라운드 모드에서만 제한적으로 실행을 이어갈 수 있는데, 알람 어플은 해당 사항이 없다. 즉, 앱이 한 번 Suspended로 전환되면 실행이 완전히 멈추기 때문에, 오디오 세션을 실행시키는 함수가 호출 자체가 안 된 것이다.
어쩐지 구글링을 해도, 스택 오버플로우를 디깅해도 정보가 없더라니… “시중 앱에서 가능하니까 방법이 있겠지” 생각하고 넘긴 게 안일한 판단이었다.
눈물이 앞을 가리니 더 이상의 자세한 설명은 생략한다... 👉 삽질 기록은 여기... (추가 예정)
최종적으로, 사용자 기기 설정(무음 모드, 소리 볼륨 등)에 영향을 받지 않는 알람 앱을 만들기 위해
피할 수 없는 정책적/기술적 관문은 다음과 같다.
- iOS는 서드파티 알람 앱에 엄격하다. (2024.12)
- 백그라운드 유지 기법 없이는 사실상 구현이 어렵다.
- 실제로, 업계 1위 알람 앱도 백그라운드 유지 기법을 사용하는 것으로 보인다.
(Alarmy 대표님이 블로그 글에서 직접 언급한 바 있다.(2018) 현재도 앱을 강제 종료하면 “앱이 꺼지면 알람이 안 울려요”라는 로컬 알림이 뜨는 걸 보면, 이 방식은 여전히 유지되고 있는 것으로 추측된다.)
구현 방식 정리
| 방법 | 원리 | 장점 | 단점 | 대안 |
|---|---|---|---|---|
| 로컬 알림 | iOS가 예약·발송 | Suspended 상태에서도 알림 가능 | 기기 설정에 종속 | 무음 모드 시 울리지 않는다고 안내 |
| 오디오 세션 | 앱이 직접 제어 | 기기 설정과 상관없이 소리/진동 울림 | Suspended 상태에서 동작 안 함 | (iOS 정책 우회) 무음 사운드를 틀어 백그라운드 유지 |
이 제약을 고려해 떠올린 시나리오는 이랬다:
- 외부 푸시 알림으로 타이머 종료 시간 5분 전 앱을 깨우기
- 5분간 무음 사운드를 재생해 앱이 Suspended 상태가 되지 않도록 유지
- 타이머 종료 시점에 오디오 세션으로 알람 울리기
하지만 이 방식은 구현 과정에서 실패할 가능성이 있고, iOS 정책을 우회하는 방법이라 리젝 리스크가 있어 고민이 되었다. 이때, 지난주 회고에서 정리했던 말이 떠올랐다. 좋은 UX는 머릿속 상상이 아니라 실제 피드백으로 검증된다. 기능 구현도 마찬가지일 것이다. 이번에는 ‘완벽 대신 완성’을 모토로, 우선 로컬 알림 기반 MVP를 내기로 결정했다.
- 장점: iOS가 예약·발송하므로 Suspended 상태에서도 알림 가능
- 단점: 기기 설정에 종속 (무음모드, 소리볼륨 등)
- 대안: 무음 모드 시, 소리가 울리지 않는다고 사용자에게 안내
2. 클린 아키텍처 적용
지난주에 SRP의 중요성을 크게 느낀 뒤, 이번 주에는 아키텍처 개선을 시도했다.
TimerManager의 책임을 Repository와 Service로 분리- 파일 네이밍도 아키텍처 규칙에 맞는지 점검
완벽하게 원칙을 따르려면 더 작은 단위(엔진 등)까지 쪼갤 수 있었지만, 지난 2주 동안 경험했듯이 과도하게 깊이 파고들면 우선순위가 밀린다는 걸 알았다.
그래서 이번에는 Service/Repository 수준까지만 분리하고 마무리했다.
(이전 아키텍처 다이어그램 → 새로운 아키텍처 다이어그램 첨부 예정)
이번 개선 과정에서 클린 아키텍처를 공부하며 도움이 된 블로그 링크도 함께 남겨본다. [iOS] Clean Architecture + MVVM + Observable 사용해서 날씨앱 리팩토링하기
배운 점
- 핵심 기능은 초반에 직접 검증하자.
“시중 앱들이 다 되니까 나도 되겠지”라는 안일한 생각이 큰 삽질로 이어졌다.
이번 일을 통해 핵심 기능은 반드시 초기에 정확히 검증해야 한다는 걸 배웠다. 단순히 코드 로직뿐 아니라 기기나 환경까지(워치 착용, suspended 상태 등) 고려해야 한다는 것도 알게 되었다. - 디버깅 능력이 좋을수록 AI 활용의 질도 높아진다.
사운드 재생 이슈에서 AI가 처음에는 다소 범용적인 답만 내놓았다. 하지만 직접 함수 호출 시점을 하나씩 디버깅하며 원인을 좁혀가니 “세션 생성 위치를 바꿔야 하지 않을까?”라는 가설에 도달할 수 있었다. 그 가설을 AI에게 제시하자, 그제야 맞는 해결책이 나와 이슈를 풀 수 있었다.
결국 AI는 답을 대신 내주는 도구가 아니라, 내가 문제를 어떻게 정의하느냐에 따라 성과가 달라지는 도구라는 걸 체감했다.
다음 주에 할 일
- 로컬 알림을 사용한 알람 정책 설계 & 구현
- 자잘하게 쌓인 버그들 정리
