⏰ 퀵라벨타이머 (Quick Label Timer)
- 플랫폼·기술: iOS 앱, SwiftUI
- 앱 컨셉: 시간을 빠르게 설정할 수 있는 퀵 타이머에, ‘왜 맞췄는지’를 기록할 수 있는 라벨 기능을 결합한 타이머 앱
- 개발 목적: AI-Assisted Programming을 실제 서비스 개발에 적용하여 장단점을 살펴보고, 서비스 완성 및 운영 경험을 통해 설계 능력과 문제 해결 능력을 강화하고자 함
- GitHub: https://github.com/data-sy/quick-label-timer
이번 주에 한 일
 |  |
|---|
이번 주에는 타이머 수정 화면과 설정 화면을 구현했다.
그리고 그 과정에서 알림/진동 설정의 책임을 Model로 이관하는 리팩토링도 진행했다.
타이머 수정 화면 구현은 생각보다 금방 끝났다.
이전에 사용자 입력 화면을 컴포넌트 단위로 만들어 둔 덕분에, 그것들을 가져다 조립만 하면 되었다. 컴포넌트화의 효용을 몸소 체감했다. 나중에 디자인을 수정하거나 기능을 추가할 때, 입력 화면과 수정 화면을 각각 손대지 않아도 될 테니 유지보수에도 좋을 것 같다.
반면, 설정 화면 구현은 예상보다 시간이 많이 들었다.
중요도에 비해 신경 써야 할 것이 많았기 때문이다. 또 보태보태병(?)에 걸려 ‘이 기능도, 저 기능도 필요하지 않을까’하는 욕심에 계속 손이 가게 됐다. 지금 생각하면, 오히려 출시 후에 추가해도 됐겠다는 아쉬움이 남는다. 하지만, 설정의 기본 사운드 기능을 만드는 과정에서 설계 리팩토링 지점을 발견했으니 럭키비키자나~🍀
기본 사운드 설정 기능을 구현하는 과정에서, 기존처럼 별도의 UserSettings 모델을 만드는 게 맞는지 의문이 생겼다. 소리/진동의 on·off는 각 타이머가 가지는 속성이기 때문이다. 그래서 설정 관리 책임을 TimerData 모델로 이관하는 리팩토링을 진행했다. 이 과정에서 AI-Assisted Programming의 한계를 체감했다. AI가 짜주는 대로만 따라가면 세부 설계까지 챙겨주지 않기 때문에 내가 직접 설계를 고민하고, 필요한 리팩토링을 주도해야 한다는 점을 확실히 느꼈다.
배운 점
-
컴포넌트화의 힘
초반에 컴포넌트 단위로 만들어둔 덕분에, 새 화면을 추가할 때 빠르게 조립하고, 일관된 디자인을 유지할 수 있었다. 앞으로도 재사용성을 신경 써서 개발해야겠다. -
설정 화면의 함정(?)
눈에 보이지 않는 기능이라도, 구현에 들어가는 리소스가 의외로 많을 수 있다. 앞으로는 “금방 만들 것 같다”는 이유만으로 우선순위를 올리지 않고, 정말 필요한 기능부터 차근차근 추가하는 습관을 들여야겠다. -
설계는 내가, 코드는 AI가
AI의 도움으로 코드 작성은 빨라졌지만, 도메인을 이해하고 서비스 구조를 설계하는 일은 개발자의 몫이다. 이 주도권을 놓치지 않아야 한다는 점을 다시 한번 느꼈다.
다음 주에 할 일
- 타이머 상태 변화에 따른 UI/UX/기능의 빈틈을 개선할 예정이다.
- 예) 타이머 종료 후 언제까지 실행 중 목록에 둘 것인지 등
- ‘실행 중 목록‘과 ’타이머 목록‘을 컨테이너를 사용해 레이아웃을 통일하려 한다.
- AS-IS : 완료된 타이머에 깜빡임 기능을 주기 위해, 실행중 목록은 Vstack을 사용 (타이머 목록은 List)
- TO-BE : ‘n초 후 삭제’ UX 도입으로 Vstack을 고집할 필요가 없어짐. 삭제 스와이프를 일관되게 적용하기 위해 모두 List로 변경
- 이를 통해 유지보수가 더 쉬워질 것이다.
