GentleFast 만들기 — 같은 뼈대로 두 번째 앱을 짠다는 것

GentleDo를 만들고 나니, 같은 뼈대로 두 번째 앱을 만드는 건 다른 게임이었다.

첫 앱은 모든 게 처음이라서 어려웠다. Flutter도, Drift도, App Store 심사도. 그래서 막힐 때마다 "이건 원래 어려운 거니까"라고 스스로를 달랠 수 있었다. 그런데 GentleFast는 달랐다. 이미 한 번 풀어 본 문제들인데도, 두 번째라고 해서 그냥 복사-붙여넣기로 끝나지 않았다. 오히려 *"어디까지 재사용하고 어디서부터 새로 짜야 하나"*라는, 첫 앱에는 없던 종류의 고민이 생겼다.

왜 단식 트래커였나

GentleFast는 GentleLab 시리즈의 두 번째 앱이다. GentleDo가 에너지 기반 태스크 앱이었다면, GentleFast는 간헐적 단식 트래커다.

주제를 단식으로 정한 이유는 단순했다. 내가 매일 쓸 앱이어야 했고, GentleDo와 세계관이 겹쳐야 했다. "무리하지 않고, 내 리듬대로" — GentleLab의 톤은 부드러운 자기관리다. 화려한 스트릭 카운터로 사람을 몰아붙이는 게 아니라, 오늘 내 몸 상태를 가만히 기록하게 하는 쪽. 단식은 그 톤에 잘 맞았다. 16:8이든 OMAD든, 숫자를 채우는 게임이 아니라 내 창(window)을 지켜보는 일이니까.

전략적으로도, 한 브랜드 아래 여러 앱을 쌓는 건 3개 브랜드 전략에서 정리했던 방향과 같았다. GentleLab이라는 우산 아래 앱이 늘수록, 각 앱이 서로를 끌어준다는 가설이다. 그 가설을 처음으로 시험하는 게 GentleFast였다.

재사용한 것, 새로 짠 것

빌드를 시작하면서 가장 먼저 한 건, GentleDo의 뼈대 중 무엇이 GentleFast에도 그대로 유효한가를 가르는 일이었다.

그대로 가져온 것

• 단방향 의존성 구조 (app → features → shared → data → core)
• Drift 로컬 DB 셋업 패턴 — 서버 없음, Phase 1은 전부 기기 로컬
• Riverpod provider 설계 관습
• 알림(flutter_local_notifications) + 타임존 처리 — GentleDo에서 피 봤던 부분이라 검증된 코드를 옮겼다
• 디자인 토큰과 브랜드 색 주입 방식 — 이건 모노레포의 brand.config 분리와 같은 발상이었다. 코드는 공유, 정체성은 주입.

처음부터 새로 짠 것

• 단식 세션 도메인 — 시작/종료 시각, 목표 시간, 진행 중 상태 머신
• 진행 중인 단식을 실시간으로 보여주는 타이머 UI — GentleDo엔 없던 살아 움직이는 화면
• 단식 기록의 통계·캘린더 뷰

흥미로웠던 건, 재사용한 코드가 절반쯤인데도 체감 작업량은 첫 앱의 절반보다 훨씬 많았다는 점이다. 도메인이 다르면 데이터 모델이 다르고, 데이터 모델이 다르면 결국 위쪽 UI까지 다 새로 흐른다. "뼈대 재사용"이 곧 "작업 절반"은 아니라는 걸, 두 번째 앱에서 배웠다.

Claude Code로 빌드한 과정

GentleFast도 모든 코드를 Claude Code와 함께 썼다. 첫 앱에서 정리한 방식 — CLAUDE.md에 규칙을 명문화하고, 한 커밋당 파일을 적게 바꾸고, 가설을 먼저 정의하는 — 을 그대로 가져왔다.

달라진 건 내 역할의 무게중심이었다. 첫 앱에선 내가 *"이게 되긴 되나?"*를 끊임없이 확인했다면, 두 번째 앱에선 *"이 구조가 GentleDo와 일관적인가?"*를 더 자주 물었다. AI에게 "GentleDo에서 쓴 알림 패턴 그대로 적용해줘" 같은 기존 결정을 참조하는 지시가 늘었다. 첫 앱의 기록이 두 번째 앱의 사양서가 된 셈이다.

여기서 한 가지 분명해진 게 있다. 프로젝트 컨텍스트 문서가 잘 정리돼 있을수록, 두 번째 앱의 속도가 빨라진다. 첫 앱에서 CLAUDE.md를 공들여 써 둔 게, GentleFast에서 이자처럼 돌아왔다.

막힌 지점

순탄하지만은 않았다. 가장 오래 붙들린 건 진행 중인 단식의 상태 관리였다.

태스크는 완료/미완료라는 이산적 상태지만, 단식은 시작한 순간부터 계속 흐르는 연속 상태다. 앱을 껐다 켜도, 기기를 재부팅해도, 흘러간 시간이 정확히 복원돼야 한다. GentleDo에는 이런 *"백그라운드에서 계속 흘러야 하는 상태"*가 없었다. 그래서 이 부분만큼은 재사용할 코드가 없었고, 새 도메인 문제로 처음부터 풀어야 했다.

타이머를 기기 시각 기준 절대값으로 저장하느냐, 경과 시간 누적값으로 저장하느냐 — 이 선택 하나에서 한참 헤맸다. 결국 시작 시각 자체를 저장하고, 화면을 그릴 때마다 현재 시각과의 차를 계산하는 쪽으로 갔다. 앱이 죽어 있던 시간도 자동으로 반영되는, 가장 단순한 방식이었다. (여기까지 오는 데 몇 번을 갈아엎었는지는 굳이 적지 않겠다.)

출시 준비

지금은 출시 준비 단계다. GentleDo 개발기에서 적었던 App Store 심사의 함정들 — 암호화 선언, iPad 타깃, provisioning — 을 이번엔 미리 체크리스트로 들고 들어간다. 첫 앱에서 하루씩 잃었던 지점들을, 두 번째엔 알고 맞는다는 게 작지만 큰 차이다.

스크린샷, 앱 설명, 개인정보 라벨 — 코드 바깥의 일이 여전히 가장 손이 많이 간다. 이건 AI가 대신 못 해주는, 사람의 몫으로 남는 영역이다.

다음 계획

GentleFast를 올리고 나면, GentleLab 시리즈의 가설을 처음으로 데이터로 볼 수 있다. 한 브랜드의 두 앱이 정말 서로를 끌어주는가. 그 숫자가 어떻게 나오든, 다음 글에 정직하게 적을 생각이다.

그리고 두 번째 앱을 끝내고 나면, 더 큰 질문이 기다린다. 앱을 계속 늘릴 것인가, 하나에 집중할 것인가. 두 앱을 동시에 돌보는 지금의 피로가, 그 결정을 머리가 아니라 몸으로 가르쳐 주는 중이다.

관련 글

이 글의 앞 이야기는 모두 본문 안에 링크해 뒀다. 첫 앱을 짠 기록은 GentleDo 개발기, 한 브랜드 아래 여러 앱을 쌓는 그림은 3개 브랜드 전략, 그 코드를 공유하면서도 정체성은 가르는 방식은 Turborepo brand.config 글에서 이어진다.