⏰ 퀵라벨타이머 (Quick Label Timer)
- 플랫폼·기술: iOS 앱, SwiftUI
- 앱 컨셉: 시간을 빠르게 설정할 수 있는 퀵 타이머에, ‘왜 맞췄는지’를 기록할 수 있는 라벨 기능을 결합한 타이머 앱
- 개발 목적: AI-Assisted Programming을 실제 서비스 개발에 적용하여 장단점을 살펴보고, 서비스 완성 및 운영 경험을 통해 설계 능력과 문제 해결 능력을 강화하고자 함
- GitHub: https://github.com/data-sy/quick-label-timer
이번 주에 한 일
 |  |
|---|
이번 주는 구조 리팩토링의 주였다. 정책이 변경될 때마다 기존 코드를 수정하는 일이 잦아지면서 구조의 한계가 느껴졌다. 이런 불편함을 느끼는 시점이 딱 리팩토링 할 시기라는 판단이 들었다. 출시가 좀 늦어지더라도, 이번 개발은 학습 목적도 크기 때문에 구조 설계를 고민하고 개선하는 시간을 가졌다.
[ 주요 작업 요약 ]
- 타이머 라이프사이클 정책 변경 (기본값: 보관→삭제)
- 완료 시 n초 후 자동 삭제
- 필요시 ‘즐겨찾기’로 보관 가능
- 단일 화면 → 복합 화면 전환
- MVVM 패턴·핸들러를 적용하여 유지보수성 향상
앱의 USP(차별 포인트) — “퀵”, “라벨”— 을 살리기 위해 세워둔 원칙은 이것이었다.
- 타이머 생성을 첫 화면에 둘 것
- 타이머 완료 후 확인 버튼 없이 앱 진입만으로 꺼질 것
그중 2번, 앱 진입만으로 타이머를 종료시키려다 보니 완료된 타이머를 어디로 보낼지가 고민이었다. 기존 정책은 '완료된 타이머는 자동으로 보관 목록으로 이동'이었다. 하지만 확인 버튼도 없는데 보관까지 자동으로 되면 사용자가 헷갈릴 것 같았다. 그래서 완료 시 n초 후 ‘자동 삭제’로 바꾸고, 남기고 싶은 타이머만 사용자가 직접 ‘즐겨찾기’로 보관하도록 했다. 이렇게 해서 “즐겨찾기에 추가하지 않으면 사라진다”는 흐름이 자연스럽게 전달되고, UX도 간결해졌다!!
기존의 정책에서는 ‘보관 목록으로 이동’이 보여야 해서 화면 분리가 어려웠지만, 이제는 즐겨찾기를 별도 화면으로 옮길 수 있게 되었다. 덕분에 단일 화면을 복합 화면으로 전환할 수 있었다.
정책 변경에 맞춰 리팩토링을 진행하면서 유지보수성이 왜 중요한지 뼈저리게 느꼈다. 😂😂
View에 섞여 있던 로직을 ViewModel로 분리하고, 타이머와 관련된 모든 기능을 담당하던 TimerManager에서 ‘완료 후 처리’만 따로 분리해서 Handler로 만들었다. 유지보수의 어려움을 직접 경험하고 나니 SRP(단일 책임 원칙)의미와 필요성이 확실히 와닿았다.
배운 점
-
좋은 UX는 사용자의 피드백에서 나온다.
회고를 쓰면서 이번 주를 돌아보니, 혼자 머릿속에서만 ‘완벽한 UX가 뭘까’를 오래 고민했다는 생각이 들었다. 사실 좋은 UX는 사용자의 실제 피드백을 통해 개선해 가는 것인데 말이다. 다음부터는 완벽하게 만들겠다는 생각에 너무 오래 붙잡히지 말고, 적당한 시점에서 구현해보고 검증하는 흐름을 가져가야겠다. -
하나의 클래스, 모듈은 한 가지 역할만 수행하도록 하자.
SRP(단일 책임 원칙)는 하나의 클래스나 모듈이 한 가지 역할만 수행하도록 하는 설계 원칙인데, 이번 리팩토링을 통해 유지보수 과정에서 그 필요성을 몸소 체감했다.
다음 주에 할 일
- 알림 기능 만들기
4주 차 동안 리팩토링에 많은 시간을 들였지만, 그 과정에서 아키텍처 패턴을 적용하는 이유와 SRP를 지키면 좋은 점을 확실히 이해할 수 있었다. 이번 리팩토링 덕분에 다음 주 알림 기능 개발이 한층 수월해지지 않을까 기대된다.
