요즘 개인 프로젝트로 FIVO(피보)라는 운동 앱을 구상하고 있어요.
아직 만들기 시작하기 전이고, 머릿속과 목업에만 있는 단계입니다.
그래서 이 글은 완성된 앱의 소개가 아니라, 무엇을 왜 이렇게 만들어 볼 생각인지를 먼저 적어 두는 구상 노트예요.
이 앱을 구상하게 된 배경에는 요즘 AI 기획 환경이 있습니다.
AI로 만드는 비용이 낮아지면서 기획자도 작은 앱 하나쯤은 직접 만들어 볼 수 있게 됐다고 느껴요.
스팩브릿지를 만들면서는 화면만으로는 의도가 전해지지 않는다는 문제를 계속 붙들고 있습니다.
2022년 9월 이후 예약 시스템을 기획하면서는 정책과 예외가 구조를 좌우한다는 걸 여러 번 겪었어요.
그래서 작은 앱을 처음부터 끝까지 직접 기획하고 만들어 보며 판단 근거를 쌓아 보고 싶었습니다.
머리로 아는 것과 손으로 해 보고 아는 것은 다를 테니까요.
나중에 생각이 바뀌더라도 처음 생각을 남겨 두면 비교할 수 있을 것 같아서 이 글을 씁니다.
FIVO를 한 줄로 말하면 운동을 플레이리스트처럼 Block과 Step으로 조합해서 바로 실행하는 앱입니다.
슬로건은 "Your workout. Your rhythm."으로 잡았어요.
운동 타이머 앱은 이미 많습니다.
그래서 처음에는 또 하나를 만들 이유가 있을까 하는 생각이 먼저 들었어요.
그런데 운동하는 장면을 떠올려 보면 필요한 흐름은 단순합니다.
내 루틴을 내 방식대로 조합하고, 그걸 바로 실행하고, 하는 동안에는 음악과 소리 안내가 흐름을 잡아 주는 것이에요.
타이머와 루틴 짜기와 음악이 따로 노는 게 아니라 하나의 흐름으로 이어졌으면 했습니다.
플레이리스트라는 비유를 고른 이유도 여기에 있어요.
음악 플레이리스트는 곡을 골라 순서대로 쌓아 두면 누르는 순간 재생됩니다.
운동도 동작과 휴식을 순서대로 쌓아 두면 누르는 순간 시작되면 좋겠다고 생각했어요.
써 본 앱을 평가하려는 게 아니라, 이런 불편이 있을 수 있겠다는 가정을 적어 보는 거예요.
- 운동과 휴식을 반복하는 구성을 매번 처음부터 다시 맞춰야 할 수도 있다.
- 저장한 루틴의 일부만 고치고 싶은데 수정이 번거로울 수 있다.
- 타이머와 음악을 오가느라 운동 흐름이 끊길 수 있다.
- 마지막 세트가 끝났는데도 쉬는 시간이 한 번 더 돌아서 어색할 수 있다.
이 가정들을 한 문장으로 모으면 문제 정의는 이렇게 됩니다.
"운동 루틴을 내 방식대로 조합해서, 고민 없이 바로 시작하고 끝까지 따라갈 수 있게 한다."
문제를 한 문장으로 못 쓰면 기능이 계속 늘어나는 경향이 있었어요.
앞으로 어떤 기능을 넣을지 말지 정할 때 이 문장이 기준이 되어 줄 거라고 생각합니다.
구조는 세 층으로 생각하고 있습니다.
- Playlist: 하나의 루틴입니다.
- Block: Playlist 안에 들어가는 묶음이고, 반복(Repeat) 횟수를 가집니다.
- Step: Block 안에 쌓이는 가장 작은 단위로, 운동 시간이나 휴식 시간입니다.
운동 Step 하나와 휴식 Step 하나를 묶어 Block으로 만들고 반복 횟수만 정하면, 같은 패턴을 여러 번 입력하지 않아도 돼요.
Block에는 마지막 휴식을 건너뛰는(Skip final rest) 옵션도 넣어 볼 생각입니다.
반복이 끝난 뒤에 붙는 휴식은 다음으로 넘어갈 때 필요 없는 경우가 있기 때문이에요.
이런 예외를 처음부터 구조 안에 넣어 두려는 건, 예약 시스템을 기획하며 예외를 나중에 붙이면 구조가 꼬인다는 걸 여러 번 느꼈기 때문입니다.
빠른 생성도 아이디어로 갖고 있어요.
Tabata, HIIT, Strength, Custom 같은 템플릿을 고르면 기본 구성이 채워지고, 사용자는 고치기만 하는 방식입니다.
빈 화면에서 시작하는 부담을 줄이려는 의도예요.
플레이어에는 원형 타이머와 다음 단계 안내(Next), 이전과 다음 버튼, 진행바를 두려고 합니다.
운동 중에는 화면을 오래 볼 수 없으니 한눈에 읽히는 것이 가장 중요하다고 생각해요.
음악은 운동 내내 재생할 플레이리스트 링크를 붙이는 방식으로 생각하고 있어요.
Step마다 다른 영상으로 전환할 수 있게 하는 것도 구상에 들어 있습니다.
다만 선은 먼저 그어 두었어요.
YouTube 공식 임베드만 사용하고, 영상을 내려받거나 오디오를 추출하는 일은 하지 않는다는 선입니다.
음성 안내는 3, 2, 1, 시작, 휴식 같은 짧은 클립으로 생각하고 있습니다.
화면을 계속 보지 않아도 지금 어디쯤인지 알 수 있게 하는 장치예요.
디자인은 흑백 모노크롬의 미니멀한 방향입니다.
색으로 구분하지 않으니 크기와 굵기와 배치로 위계를 만들어야 하는데, 오히려 그 제약이 화면을 단순하게 만들어 줄 거라고 기대하고 있어요.
기준은 목업 네 화면으로 삼으려 합니다.
홈, 상세, 블록 편집, 플레이어예요.
처음 버전에서는 이런 것들을 일부러 뺍니다.
- 로그인
- 클라우드
- AI 추천
- 소셜
- 결제
- 워치 연동
로그인과 클라우드는 첫 실행까지의 길을 늘리고, 관리해야 할 것도 늘립니다.
먼저 한 기기 안에서 루틴을 만들고 실행하는 핵심 흐름이 통하는지부터 보고 싶어요.
AI 추천은 조합과 실행 흐름이 단단해진 뒤에야 추천할 재료가 생긴다고 생각해서 뒤로 미뤘습니다.
소셜과 결제는 사용자가 쌓인 뒤에 필요해지는 문제이고, 워치 연동은 화면 설계가 다른 앱을 하나 더 만드는 일에 가까워요.
AI와 함께 만들지만 앱 안에는 AI를 넣지 않는다는 점이 재미있다고 느꼈습니다.
뺀다는 건 영영 안 한다는 뜻이 아니라, 지금 검증할 질문이 아니라는 뜻이에요.
이 목록을 글로 적어 두면 나중에 욕심이 생길 때 돌아올 자리가 됩니다.
만드는 방식은 단순하게 잡았어요.
Flutter로 프로젝트 하나를 만들고, 웹 화면을 보면서 AI와 함께 바로바로 고쳐 가는 방식입니다.
여기에는 지난 경험이 영향을 줬어요.
Claude 같은 도구로 목업을 기획해 본 적이 있는데, 설명 없는 목업만 건넸다가 개발자와 소통이 어긋난 일이 있었습니다.
화면만 보고는 의도가 전해지지 않는다는 걸 그때 배웠어요.
스팩브릿지가 화면 위에 정책과 데이터와 API 스펙을 연결하려는 도구인 것도 같은 맥락이라고 느낍니다.
아직 구상 단계라서 아래는 확정된 규칙이 아니라 이렇게 해 보려 하는 원칙입니다.
- 문서보다 화면 단위로 진행해 보려 한다.
PRD를 길게 쓰는 대신 화면 하나씩 동작하는 모습을 먼저 확인할 생각이에요. - 결정의 이유를 짧게 남겨 보려 한다.
화면마다 이 화면이 무엇을 위한 것인지 한두 문장으로 먼저 적고 시작하려고 합니다. - 확인할 구간을 미리 정해 두려 한다.
AI가 만든 결과를 통째로 믿지 않고, 첫 실행 흐름처럼 내가 직접 눌러 볼 구간을 먼저 정해 둘 생각이에요. - 한 번에 하나만 바꾸려 한다.
여러 가지를 한꺼번에 고치면 무엇이 결과를 바꿨는지 알 수 없으니 하나씩 요청하고 확인해 보려 합니다.
개발자 없이 AI와 둘이 만들면 소통 문제가 사라지는 대신, 내 의도를 내가 얼마나 정확히 말하는지가 곧 결과물의 품질이 될 것 같아요.
기획자가 직접 만들 때 조심할 점도 있습니다.
만들 수 있으니 계속 붙이고 싶어지는 마음이에요.
그래서 앞에서 적은 문제 한 문장과 제외 목록이 더 중요하다고 생각해요.
아직 숫자로 된 목표는 정하지 않았습니다.
대신 어떤 질문으로 판단할지를 먼저 적어 둡니다.
- 앱을 처음 열고 첫 타이머가 돌기까지 몇 번 누르는가.
- 한 번 만든 루틴을 다시 열어 실행하기까지 몇 번 누르는가.
- 루틴 일부를 고칠 때 처음부터 다시 만들지 않아도 되는가.
- 운동 중에 화면을 계속 보지 않고도 흐름을 따라갈 수 있는가.
이 중에서도 첫 실행까지 누르는 횟수를 가장 먼저 세어 볼 생각이에요.
실제로 눌러 보면서 기준 숫자를 정하려고 해요.
타깃은 영어를 기본으로 하는 글로벌 사용자이고, 최종 목표는 Android Play Store 출시입니다.
남은 질문도 몇 가지 있습니다.
Step마다 영상을 바꾸는 기능이 정말 필요한지, 복잡함만 더하는 건 아닌지.
템플릿의 기본값을 어디까지 채워 줄지.
이 질문들은 화면을 만들어 보며 답을 찾아볼 생각이에요.
11월 초에 처음 구상과 달라진 점을 정리한 중간 기록을 남겨 볼 생각입니다.

'Planning · PM > 서비스 기획' 카테고리의 다른 글
| FIVO를 만들며 정한 것들, 플레이가 주고 관리는 부 (0) | 2026.11.01 |
|---|---|
| 테넌트 온보딩 설계, 가입부터 첫 예약까지의 길 (0) | 2026.10.04 |
| 예약 시스템의 정산과 환불 정책, 테넌트에게 돈이 흐르는 길 (0) | 2024.04.07 |
| 예약 데이터에서 놓치기 쉬운 것, 시간대·중복 예약·동시성 (0) | 2023.10.07 |
| 예약 알림 설계, 알림톡·문자·푸시 선택 기준 (0) | 2023.08.14 |