MVP는 기능을 줄이는 것이 아니라 가설을 줄이는 과정이다
오늘은 여행, 데이트 코스, 장소 추천, 예약을 연결한 서비스를 구상했다. 아직 어떤 서비스를 만들지는 정하지 못했다. 대신 아이디어를 구체화하면서 기능보다 먼저 정해야 할 것이 있다는 점을 배웠다.
처음에는 사용자 취향에 맞는 장소를 추천하고, 여러 장소를 하나의 동선으로 연결한 뒤, 숙소나 체험 상품의 예약과 결제까지 이어지면 좋겠다고 생각했다. 각각만 보면 구현해 보고 싶은 기능이었다. 하지만 기능을 한곳에 모을수록 이 서비스가 어떤 문제를 먼저 해결하려는지는 오히려 흐려졌다.
이번 고민을 통해 MVP를 최종 서비스의 축소판으로만 이해하면 범위를 정하기 어렵다는 것을 알게 되었다. MVP는 만들고 싶은 기능을 조금씩 덜어 내는 버전보다, 가장 먼저 확인해야 할 가설 하나를 최소한의 기능으로 검증하는 버전에 가까웠다.
1. 여행 계획의 여러 불편을 한 번에 해결하고 싶었다
서비스를 떠올린 출발점은 여행이나 데이트 일정을 준비할 때 드는 수고였다. 갈 만한 장소를 검색하고 비교해야 하고, 여러 장소를 골랐다면 이동 시간을 고려해 방문 순서도 정해야 한다. 추천받은 장소가 괜찮아 보여도 실제 일정으로 연결하려면 다시 지도와 예약 사이트를 오가야 한다.
처음에는 이 과정을 하나의 서비스 안에서 이어 주면 편리하겠다고 생각했다. 장소 탐색부터 일정 생성, 예약, 결제까지 끊기지 않는 흐름을 만드는 것이었다.
이 생각에는 서로 다른 사용자 문제가 섞여 있었다.
- 갈 만한 장소를 직접 검색하고 비교하는 과정이 번거롭다.
- 여러 장소를 방문할 때 효율적인 순서를 정하기 어렵다.
- 추천받은 장소를 실제 일정으로 연결하기 어렵다.
- 일정과 관련 상품을 서로 다른 서비스에서 따로 확인해야 한다.
문제 하나하나는 이해할 수 있었지만, 아직 어떤 불편이 사용자에게 가장 크고 자주 발생하는지는 확인하지 못한 상태였다.
2. 처음 생각한 범위는 이미 하나의 서비스에 가까웠다
아이디어를 기능으로 옮기자 범위는 빠르게 커졌다.
- 사용자의 취향을 입력받고 분석한다.
- 취향에 맞는 장소를 추천한다.
- 선택한 여러 장소를 이동 동선으로 연결한다.
- 숙소, 체험, 입장권 같은 상품을 보여 준다.
- 상품을 예약하고 결제한다.
- 추천 결과와 실제 구매를 연결한다.
처음에는 이것들을 모두 갖춰야 아이디어의 가치가 드러난다고 생각했다. 추천만 제공하면 일정으로 이어지지 않고, 동선만 만들면 기존 지도 서비스와 차이가 약하며, 예약이 없으면 실제 행동까지 연결되지 않는다고 보았기 때문이다.
하지만 이 방식으로는 MVP를 정하는 것이 아니라 완성된 서비스의 기능 목록을 먼저 만드는 셈이었다. 각 기능을 어느 정도까지 줄일지만 고민했을 뿐, 무엇을 먼저 확인해야 하는지는 정하지 못했다.
3. 구현 가능성과 검증 가능성은 달랐다
기능을 구체적으로 살펴보면서 가장 먼저 부딪힌 문제는 데이터였다.
취향 기반 추천을 구현하려면 사용자의 선호를 표현할 정보와 장소 데이터가 필요하다. 추천 결과가 실제 취향에 맞는지 판단하려면 비교할 테스트 데이터나 사용자 반응도 있어야 한다. 데이터가 없는 상태에서 점수 계산이나 추천 로직을 정교하게 만들어도 그 결과가 좋은 추천인지 확인하기 어렵다.
예약도 비슷했다. 예약 화면과 API는 만들 수 있지만 실제 숙소나 체험 상품, 재고, 가격, 예약 가능 시간 같은 정보가 없다면 정상적인 예약 흐름을 검증하는 데 한계가 있다. 가짜 상품으로 성공 응답을 만드는 것과 실제 공급자의 상품이 예약 가능한 상태로 연결되는 것은 다른 문제였다.
지도, 장소 추천, 동선 생성, 예약, 결제를 모두 포함하면 외부 연동과 예외 상황도 함께 늘어난다. 구현 범위는 커지는데 정작 사용자가 이 조합을 원하는지는 확인하기 어려워진다.
여기서 구현할 수 있는 기능과 검증할 수 있는 기능은 다르다는 점이 분명해졌다. 기술적으로 만들 수 있다는 사실만으로 지금 MVP에 포함할 이유가 되지는 않았다.
4. 기능부터 정하니 서비스의 목적이 흐려졌다
기능을 먼저 나열했을 때는 각 기능이 모두 중요해 보였다. 장소 추천에는 취향 분석이 필요하고, 여행 계획에는 동선 생성이 필요하며, 실제 행동으로 이어지려면 예약과 결제가 필요하다고 생각했다.
그러나 이 목록만으로는 어떤 기능이 실패했을 때 서비스 아이디어를 바꿔야 하는지 판단하기 어려웠다. 추천 결과를 사용하지 않는 이유가 추천 품질 때문인지, 동선이 불편해서인지, 예약할 상품이 부족해서인지 구분할 수 없기 때문이다. 여러 가설을 동시에 넣으면 결과가 나와도 무엇이 맞았고 무엇이 틀렸는지 해석하기 어려워진다.
기능이 많다고 좋은 MVP가 되는 것은 아니었다. 오히려 기능이 늘어날수록 개발 시간과 연결 지점은 많아지고, 검증하려는 질문은 모호해졌다. 기능 자체가 서비스의 목적처럼 보이기 시작한 것도 문제였다.
이전에 Spring Boot 도전 기능 구현 과정에서 고민한 설계 포인트를 정리하면서도 기존 구조의 재사용이나 미래 확장보다 현재 기능의 목적과 책임을 먼저 살펴야 한다고 느꼈다. 이번에는 같은 기준이 코드 구조뿐 아니라 서비스 범위를 정할 때도 필요하다는 것을 알게 되었다.
5. 문제, 가설, 기능을 분리해서 보기
혼란을 줄이기 위해 문제, 가설, 기능을 따로 적어 보았다. 세 단어는 연결되어 있지만 같은 의미가 아니었다.
문제는 사용자가 실제로 겪는 불편이다. 예를 들면 여러 장소의 방문 순서를 정하기 어렵거나, 갈 만한 장소를 직접 검색하고 비교하는 과정이 번거로운 상황이다. 추천받은 장소를 실제 일정으로 옮기는 과정이 어렵다는 것도 문제가 될 수 있다.
가설은 그 문제를 해결할 수 있다고 예상하는 방법이다. 사용자가 선택한 장소를 기반으로 이동 동선을 자동 생성하면 일정 계획의 불편을 줄일 수 있다는 생각이 여기에 해당한다. 취향 정보를 입력받아 장소를 추천하면 검색 시간을 줄일 수 있다는 생각이나, 추천 결과에 체험 상품과 예약 기능을 연결하면 구매로 이어질 수 있다는 생각도 가설이다.
기능은 가설을 검증하기 위해 구현하는 수단이다. 지도 API를 이용한 장소 검색, 선택한 장소의 이동 순서 생성, 취향 설문, 장소 추천, 예약과 결제가 기능에 해당한다.
기능을 구현한 사실만으로 서비스의 가치가 확인되지는 않는다. 기능을 통해 얻은 결과로 가설을 판단해야 한다.
예를 들어 동선 생성을 서비스의 목적으로 두면 더 많은 지도 기능을 붙이는 방향으로 생각하기 쉽다. 반면 문제를 여러 장소의 방문 순서를 정하기 어렵다로 정의하고, 가설을 자동으로 만든 동선이 일정 계획의 불편을 줄인다로 두면 필요한 기능의 범위가 달라진다.
이 경우 장소를 검색하고 선택하는 기능, 이동 순서를 생성하는 기능, 결과를 확인하는 화면 정도로 먼저 구성할 수 있다. 핵심은 기능의 개수가 아니라 각 기능이 어떤 문제와 가설을 확인하기 위해 필요한지 설명할 수 있는가였다.
6. MVP는 기능이 아니라 가설의 수를 줄이는 과정이었다
처음에는 취향 분석, 장소 추천, 동선 생성, 숙소 예약, 체험 상품, 결제를 각각 간단하게 만들면 MVP가 된다고 생각했다. 하지만 모든 기능을 얕게 구현해도 여전히 여러 가설을 동시에 확인해야 한다.
- 취향 정보를 받으면 추천 품질이 좋아지는가?
- 추천이 장소 검색 시간을 줄이는가?
- 자동 동선이 일정 계획에 도움이 되는가?
- 추천과 예약을 연결하면 구매가 발생하는가?
질문이 네 개라면 필요한 데이터와 사용자 행동도 달라진다. 한 번의 MVP로 모두 답하려 하면 구현은 커지고 결과 해석은 어려워진다.
작은 MVP는 완성된 서비스의 모든 기능을 축소한 형태가 아니라, 하나의 질문에 답할 수 있도록 범위를 제한한 형태에 가깝다.
예를 들어 첫 가설을 사용자가 선택한 장소를 기반으로 동선을 생성하면 일정 계획의 불편을 줄일 수 있다로 정한다면, 초기 MVP는 다음 흐름에 집중할 수 있다.
- 사용자가 방문할 장소를 선택한다.
- 선택한 장소를 기반으로 이동 순서를 생성한다.
- 사용자가 생성된 결과를 확인한다.
이 범위에서도 동선 생성 방식과 결과를 어떤 기준으로 평가할지는 더 구체화해야 한다. 다만 취향 추천과 실제 예약을 동시에 다루는 것보다 무엇을 확인하려는지는 분명하다. 결과가 의미 있다면 다음 가설로 범위를 확장하고, 그렇지 않다면 추천이나 커머스 기능을 붙이기 전에 문제 정의부터 다시 살펴볼 수 있다.
7. 아직 최종 주제를 확정하지 않은 이유
오늘은 서비스 주제를 정하지 않았다. 여행 서비스, 데이트 코스 서비스, 장소 추천 서비스 중 하나를 고르기 전에 어떤 사용자 문제를 가장 먼저 다룰지 정하지 못했기 때문이다.
이 상태에서 주제부터 확정하면 이름에 맞는 기능을 채우는 방식으로 다시 돌아갈 가능성이 크다. 여행 서비스니까 숙소 예약이 필요하다, 추천 서비스니까 개인화가 필요하다처럼 서비스의 형태가 기능을 결정할 수 있다.
하지만 현재는 정교한 개인화 추천을 검증할 데이터가 없고, 실제 예약을 연결할 상품이나 공급자도 없다. 이 제약을 무시하고 주제를 정하면 구현은 할 수 있어도 핵심 가설을 확인하지 못하는 결과가 나올 수 있다.
그래서 주제를 정하지 못한 것을 단순히 결론을 내리지 못한 상태로 보지 않기로 했다. 무엇을 만들지보다 어떤 문제를 어떤 근거로 선택할지 먼저 정리하는 과정이 필요했다.
8. 다음에는 주제를 정하는 기준부터 세운다
다음 단계에서는 만들고 싶은 기능의 수보다 아래 질문을 기준으로 후보를 비교하려고 한다.
- 사용자가 겪는 문제를 한 문장으로 설명할 수 있는가?
- 그 문제가 실제로 존재하는지 확인할 방법이 있는가?
- 가장 먼저 검증할 가설을 하나로 정할 수 있는가?
- 현재 확보할 수 있는 데이터로 결과를 판단할 수 있는가?
- 외부 상품이나 공급자가 없어도 핵심 흐름을 확인할 수 있는가?
- 최소한의 기능으로 사용자 반응이나 행동을 관찰할 수 있는가?
- 첫 가설이 확인된 뒤 다음 기능을 단계적으로 확장할 수 있는가?
이 기준으로 보면 기술적으로 흥미로운 기능보다 지금 검증 가능한 가설이 우선된다. 개인화 추천이 최종 서비스에 필요하더라도 데이터가 부족한 초기 단계에서는 뒤로 미룰 수 있다. 예약과 결제도 상품 공급과 운영 정책을 준비할 수 있는 단계에서 별도 가설로 검증하는 편이 낫다.
최종 형태를 한 번에 만들기보다 하나의 가설을 확인하고, 그 결과를 바탕으로 다음 범위를 정하는 순서가 현재 상황에 더 맞아 보인다.
9. 오늘 배운 점
오늘 고민에서 가장 크게 달라진 것은 MVP를 바라보는 기준이다. 이전에는 최종 서비스에 필요해 보이는 기능을 모두 적고, 개발 기간에 맞춰 단순화하는 쪽으로 생각했다. 이제는 기능을 줄이기 전에 검증할 가설부터 줄여야 한다고 생각한다.
취향 분석, 추천, 동선, 예약, 결제는 모두 구현해 볼 수 있는 기능이다. 그러나 데이터와 외부 상품이 없는 상태에서는 각각의 품질과 가치를 충분히 확인하기 어렵다. 구현 완료가 곧 사용자 문제의 해결을 의미하지도 않는다.
MVP에서는 가장 중요한 사용자 문제와 하나의 핵심 가설을 먼저 선택해야 한다. 기능은 그 가설을 확인하는 데 필요한 만큼만 두고, 결과를 본 뒤 유지하거나 수정하거나 다음 단계로 확장해야 한다.
오늘은 서비스 주제를 확정한 날이 아니었다. 대신 주제를 정할 때 기능 목록보다 사용자 문제, 검증할 가설, 확인 가능한 근거를 먼저 봐야 한다는 기준을 세운 날이었다. 다음에는 만들고 싶은 기능부터 적기보다 사용자가 겪는 불편을 먼저 정의하고, 가장 먼저 답해야 할 질문 하나에서 MVP의 범위를 시작하려고 한다.