유료기능·TTS 업그레이드·AAB 빌드가 한 주에 수렴된 개발 마일스톤
목차
어제 STATUS.md를 갱신하면서 한 주의 개발 진행도를 정리했다. 유료기능 완결, TTS Chirp3-HD 적용, AAB 빌드 반영 — 세 가지 결과물이 한 번에 수렴되는 시점이었다.
유료기능이 완결되다
유료기능을 '완결'했다는 건 단순히 코드가 다 작성됐다는 뜻이 아니다.
이 프로젝트에서 유료기능은 핵심 서비스의 차별화 지점인데, 계획 단계부터 구현, 테스트, 그리고 배포까지의 전체 파이프라인이 일단락됐다는 신호다. 팀 관점으로는 이제 이 기능이 '변수'에서 '상수'로 바뀐다는 의미다. 더 이상 개발 우선순위를 바꿀 필요가 없고, 다음 주에는 이 기능을 기반으로 한 최적화나 사용자 피드백 반영에만 집중할 수 있다.
유료기능이 완결되면서 팀 내에서도 심리적 변화가 생긴다. 불확실성이 하나 줄어들었다는 느낌. 개발 멤버들도, 운영팀도, 기획팀도 이제 이 기능이 확정된 상태에서 다음 스텝을 계획할 수 있다.
TTS를 Chirp3-HD로 업그레이드하다
TTS(Text-to-Speech) 선택은 사용자 경험에 직결되는 의사결정이었다.
이전 버전에서 Chirp3-HD로 바꾼 건, 음성 품질 향상이 주된 이유겠지만, 실은 여러 트레이드오프가 있었을 거다:
- 음성 자연스러움 vs 응답 지연
- 비용 vs 품질
- 다국어 지원 vs 구현 복잡도
Chirp3-HD를 선택한다는 건 이런 트레이드오프에서 "자연스러운 사용자 경험"을 우선시하겠다는 팀의 우선순위 결정이다. 유료기능이 막 완결되는 시점에 TTS를 업그레이드하는 건 "이제 기능은 안정화했으니, 사용자가 실제로 마주치는 품질에 투자하자"는 신호다.
AAB 빌드로 배포를 준비하다
Android App Bundle(AAB)은 구글 플레이 스토어의 표준 배포 형식이다.
예전의 단순한 APK 빌드와 다르게, AAB는 사용자의 기기 환경(화면 크기, CPU 아키텍처, 언어 등)에 맞춰 최적화된 앱을 자동으로 생성해준다. 덕분에 앱 크기를 줄일 수 있고, 설치 속도도 빨라진다.
이 항목을 STATUS.md에 기록한다는 건:
- 내부 빌드 검증이 완료됐다
- 배포 환경에서의 호환성을 확인했다
- 이제 실제 스토어 배포로 넘어갈 준비가 됐다는 신호
상태 문서를 유지하는 이유
혼자 프로젝트를 한다면 STATUS.md 같은 문서는 필요 없을 수도 있다. 머릿속에 다 있으니까.
하지만 팀이 커지면서, 그리고 프로젝트가 복잡해지면서, 이런 상태 문서의 가치가 급격히 올라간다:
| 관점 | 역할 |
|---|---|
| 팀 동기부여 | 진행도를 명확히 보여줘서 '우리가 이 정도 왔구나'를 실감하게 함 |
| 의사결정 근거 | 어떤 기능이 완결됐는지, 다음에 뭘 할지를 판단할 데이터 |
| 온보딩 | 새로 들어온 멤버가 프로젝트의 현황을 빠르게 파악하는 진입점 |
| 회고 | 주 단위, 월 단위 회고에서 실제 한 일들을 정확히 기억할 수 있게 함 |
STATUS를 매일 갱신하는 습관이 생기면, 팀이 방향 감각을 잃지 않는다.
배운 것
이번 상태 갱신에서 느낀 건, 세 가지 다른 종류의 마일스톤(기능 완성, 기술 업그레이드, 배포 준비)이 한 시점에서 수렴한다는 것의 무게감이었다.
각각 담당자가 다르고, 일정도 달랐겠지만, 결과적으로 같은 날에 STATUS.md에 기록된다. 이런 수렴이 생기는 건 보통 두 가지다:
- 운이 좋아서 — 각자 일이 끝난 타이밍이 우연히 맞음
- 계획과 추적이 잘돼서 — 팀이 공통된 마일스톤을 향해 움직여서
아마도 둘 다겠지만, 더 중요한 건 (2)다. STATUS 문서가 있었기에 마일스톤들이 '우연의 일치'가 아니라 '일관된 진행'으로 보인다.
다음 주는 이 완결된 기능들이 실제 사용자에게 닿는 단계다. 그때도 STATUS를 계속 갱신하면서 팀의 속도를 놓치지 않을 예정이다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.