FIVO를 만들며 정한 것들, 플레이가 주고 관리는 부

 

FIVO(피보)를 만들기 시작한 건 10월 28일입니다.
오늘이 11월 1일이니 아직 나흘, 길게 봐야 닷새쯤 된 프로젝트예요.
그래서 이 글은 끝났다는 보고가 아니라 중간 기록입니다.

AI와 함께 작은 앱을 만들어 보니, 만드는 일 자체는 예전보다 훨씬 가벼워졌습니다.
대신 무엇을 만들고 무엇을 뺄지 결정하는 일이 기획자의 몫으로 더 크게 남더라고요.
앞서 읽은 글들, 그러니까 Harness Engineering 101 글이나 AI 네이티브 핸드북 글에서 본 이야기와도 닿아 있다고 느꼈어요.
도구가 많은 걸 대신해 줄수록, 사람이 정해야 하는 것의 무게는 오히려 커진다는 쪽으로요.

그런데 결정은 코드보다 더 빨리 잊힙니다.
화면은 남는데 이유는 남지 않아요.
그래서 지금까지 정한 것들과 그 이유를 한 번 적어 두려고 합니다.

 

FIVO는 운동을 플레이리스트처럼 조합해서 실행하는 앱입니다.
운동을 Block과 Step으로 쪼개 순서대로 이어 붙이고, 그대로 재생하는 구조예요.
슬로건은 "Your workout. Your rhythm."이고, 디자인은 흑백 미니멀로 갑니다.

Flutter로 만들고 있고, 개발 중에는 웹 화면으로 확인해요.
최종 목표는 Android Play Store 출시입니다.

지금까지 홈, 상세, 블록과 Step 편집, 설정, 플레이어와 실행 엔진, 음성 안내까지 한 번은 끝까지 만들었어요.
그런데 10월 30일쯤 구조를 크게 바꿨습니다.
한 번 끝까지 만들어 보고 나서야 "이 순서는 틀렸다"는 게 보였기 때문이에요.

 

결정 1. 플레이가 주고, 관리는 부

 

처음 만든 첫 화면은 루틴 목록, 그러니까 관리 화면이었어요.
앱을 열면 만들어 둔 루틴이 쭉 나열되는 흔한 구성입니다.

그런데 제가 쓰는 순간을 떠올려 보니 이상했습니다.
운동하려고 앱을 켰는데 먼저 보이는 게 목록이라면, 시작하기까지 단계가 하나 더 생기는 거예요.
제가 원한 건 "시작까지 최소 단계"였고, 요구를 한 줄로 줄이면 "플레이가 주, 생성과 관리는 부"였습니다.

그래서 하단 탭을 Play, Library, Settings로 정리했어요.
첫 화면인 Play는 타이머 대기 화면입니다.
선택한 루틴의 첫 Step이 링으로 보이고, 그 아래 큰 재생 버튼이 있어요.
다른 루틴으로 바꾸고 싶으면 시트를 열어서 고르면 됩니다.

만들기와 관리는 Library로 옮겼습니다.
Quick Create 시트에서 Tabata, HIIT, Strength, Custom 중에 고르면 바로 만들기 시작할 수 있어요.

편집 화면도 같은 기준으로 줄였습니다.
블록은 타입 칩을 한 번 누르면 추가되고, 이름을 입력하는 다이얼로그는 없앴어요.
이름을 바꾸고 싶으면 제목을 누르면 됩니다.
플레이어도 하단에 큰 메인 버튼을 두고, 링을 탭하면 일시정지가 되게 했어요.
남은 총 시간이 보이고, 영상은 숨길 수 있습니다.

기능을 더한 개편이 아니라, 사용하는 순간에 필요 없는 걸 치우는 개편이었어요.

이 판단은 예약 시스템을 기획할 때와 닮았습니다.
거기서도 사용하는 순간의 단계를 줄이는 결정이 정책 설계의 핵심에 가까웠어요.
단계를 하나 줄이려면 그 단계에 걸려 있던 규칙을 어디로 옮길지부터 정해야 했고, 그래서 화면 결정과 정책 결정은 늘 한 쌍으로 움직였습니다.
FIVO에서 관리 기능을 Library로 보낸 것도 같은 방식의 정리예요.

 

결정 2. 기기 TTS 대신 짧은 음성 클립

 

운동 앱에는 음성 안내가 필요합니다.
화면을 계속 볼 수 없는 상황이 많기 때문이에요.

처음에는 기기에 들어 있는 TTS를 쓰는 게 가장 쉬워 보였습니다.
하지만 기기마다 품질이 다르고, 제가 통제하기 어렵다는 점이 걸렸어요.
같은 "three, two, one"이 어떤 폰에서는 또렷하고 어떤 폰에서는 어색하다면, 그건 제가 만든 경험이라고 하기 어렵습니다.

그래서 TTS는 쓰지 않기로 했고, 짧은 음성 클립을 앱에 내장하는 쪽으로 갔어요.
클립은 three, two, one, start, rest, prepare, finish 이렇게 7개입니다.
목소리는 영어 여성 6종, 남성 6종, 한국어 1종으로 모두 13종이고, 기본값은 영어 여성 한 가지예요.

여기에는 아직 열려 있는 문제가 하나 있습니다.
클립을 edge-tts로 만들었는데, 이건 비공식 API라서 출시 전에 라이선스 검토가 필요해요.
그래서 지금 클립은 언제든 교체할 수 있는 임시 자산이라고 생각하고 있습니다.
기획 관점에서 보면 "통제할 수 있게 만든 대신, 권리 문제는 내가 떠안은" 셈이에요.

AI 도구를 쓰면 이런 선택지가 순식간에 눈앞에 쌓입니다.
만들어 주는 건 도구가 하지만, 그중 무엇을 내 경험으로 삼고 어떤 부담을 지고 갈지는 제가 정해야 했어요.

 

결정 3. YouTube는 공식 임베드만

 

운동에는 음악이나 영상이 따라붙는 경우가 많습니다.
그래서 운동 내내 재생할 플레이리스트 링크를 걸 수 있게 했고, Step마다 영상을 바꾸는 것도 지원해요.

다만 선은 분명하게 그었습니다.
공식 임베드만 쓰고, 영상을 내려받거나 오디오를 따로 추출하는 일은 하지 않아요.
되는 방법이 더 있을 수 있어도, 정책에서 허용하지 않는 길이면 처음부터 기능 목록에 올리지 않기로 했습니다.

이걸 제약이라고만 보지 않으려고 해요.
정책을 기획 단계에서 받아들이면 나중에 출시 심사나 약관 문제로 기능을 통째로 걷어내는 일을 줄일 수 있기 때문입니다.

테넌트 구조의 예약 시스템을 기획할 때도 비슷한 감각이 필요했어요.
공통으로 지킬 것과 열어 둘 것의 선을 먼저 그어 두지 않으면, 나중에 예외가 쌓여서 구조 자체를 흔들게 됩니다.
선을 일찍 긋는 쪽이 길게 보면 비용이 적다는 건 두 곳에서 같았어요.

MVP에서 뺀 것도 함께 적어 둘게요.
로그인, 클라우드, AI 추천, 소셜, 결제, 워치 연동은 이번 범위에 넣지 않았습니다.
하나씩 다 매력적이지만, "플레이가 주"라는 기준 앞에서는 전부 뒤로 밀렸어요.
언어는 영어를 기본으로 두었는데, 처음부터 글로벌 사용자를 보고 만드는 앱이라서입니다.

 

결정 4. 문서 대신 화면으로 진행하기

 

이번에는 PRD 같은 문서를 따로 쓰지 않았어요.
대신 목업 4화면을 기준으로 삼고, 화면 단위로 동작하는 상태를 계속 유지하면서 진행하고 있습니다.
데이터는 처음에 기기 저장소(shared_preferences, JSON)로 시작했고, 나중에 DB로 바꿀 수 있게 열어 두었어요.

이 방식에는 제가 스팩브릿지로 풀고 싶은 문제가 겹쳐 있습니다.
Claude 같은 도구로 목업을 만들어 개발자와 이야기해 본 적이 있는데, 설명 없는 화면 때문에 소통이 꼬인 경험이 있었어요.
화면은 있는데 왜 그렇게 동작하는지, 어떤 정책이 붙는지가 화면 위에 없었던 겁니다.
스팩브릿지가 화면 위에 정책과 데이터, API 스펙을 연결하려는 것도 결국 이 빈칸을 메우기 위해서예요.

화면만 있으면 보는 사람마다 다르게 읽어요.
제가 지금 결정의 이유를 이렇게 글로 남기는 것도 그 경험 때문입니다.
혼자 만드는 프로젝트여도, 나중의 제가 "이 화면은 왜 이래?" 하고 묻는 상황이 올 테니까요.

 

 

테스트는 APK를 같은 와이파이에 있는 제 PC에서 서빙하고, QR을 찍어 설치해서 실기기로 확인하는 방식으로 하고 있어요.
웹 화면으로는 보이지 않던 것들이 실기기에서 드러날 거라고 기대합니다.

남은 일은 크게 둘입니다.
실기기 테스트가 첫째이고, 출시 준비가 둘째예요.
출시 준비에는 릴리스 키스토어를 만드는 일과 음성 클립을 라이선스 문제가 없는 것으로 바꾸는 일이 들어 있습니다.

아직 모르는 게 많아요.
첫 화면을 Play로 바꾼 판단이 실제로 운동하는 순간에도 맞을지는 직접 써 봐야 알 수 있습니다.
13종 목소리가 정말 필요한지도 쓰면서 걸러 낼 생각이에요.

이 나흘 동안 AI와 기획하며 얻은 것을 세 줄로 줄이면 이렇습니다.

1. 결정의 이유를 글로 남기기. 도구가 화면을 빨리 만들어 줄수록 이유는 더 빨리 사라지니까요.
2. 확인할 구간 정하기. 모든 걸 다 검증할 수 없으니, 실기기나 직접 사용처럼 제가 눈으로 봐야 할 구간을 미리 정해 둡니다.
3. 한 번에 하나만 바꾸기. 구조를 크게 바꾼 뒤라 더 와닿는데, 여러 개를 한꺼번에 바꾸면 무엇이 효과였는지 나중에 가를 수 없어요.

다음 글에서는 실기기에서 확인한 결과를 적어 보겠습니다.

정해 둔 것 중에 무엇이 그대로 남고 무엇이 바뀌었는지가 그 글의 중심이 될 것 같아요.