처음 버전에 빼도 되는 것들
MVP, 처음 개발 버전의 범위를 정할 때 가장 어려운 지점은 무엇을 만들지보다, 무엇을 지금 만들지 않을지 결정하는 부분입니다. 기능 아이디어를 쭉 적어보면 다 중요해 보이기 쉽습니다. 타겟도 떠오르고, 쓰임새도 불분명하지 않죠. 그래서 결국 조금만 더 넣자는 선택을 반복하다 보면 첫 버전이 이상하게 무거워집니다. 개발 기간도 길어지고, 그만큼 비용이 나갑니다.
이번 글에서는 그 반대 방향에서 생각해 보려고 합니다. MVP에서 무엇을 더 넣을지가 아니라, 무엇을 당장 빼야할 지를 기준으로 봅니다. 그걸 어떻게 현실적으로 정리할 수 있을지 단계별로 살펴보겠습니다.
처음 100명이 반드시 경험해야 할 한 가지
MVP를 기능 목록에서 출발하면 범위가 거의 항상 과해집니다. 먼저 해야 할 일은, 기능 명세서가 아니라, 사용자 경험을 한 줄로 적는 것입니다. 이 서비스를 처음 써보는 100명이 반드시 한 번은 경험했으면 하는 장면이 무엇인가? 이걸 아주 구체적인 문장으로 적어보는 것이 좋습니다. 예를 들면,
- 퇴근 후 10분 동안, 내 상황에 맞는 자기계발 콘텐츠 하나를 보고
'오늘은 그래도 뭔가 했다' 라는 감각을 얻는 것 - 과외 학생 여러 명의 진도와 숙제를 한 화면에서 보고,
이번 주에 어떤 학생에게 무엇을 시켜야 할지 바로 파악하는 것 - 오늘 하루 쓴 돈을 모바일로 간단히 적어 넣고,
이번 달 지출 패턴을 대략이라도 눈으로 확인하는 것
이런 한 줄에 MVP의 기준점이 됩니다. 이 경험을 만들어 내는 데 직접적으로 필요한 기능만 MVP의 후보로 남겨두시면 됩니다. 이렇게 한 줄을 쓰실 때는 이런 것들을 의식하시면 좋습니다. 누가, 언제, 어디서, 무엇을 느끼는지 입니다.
- 실제 얼굴이 떠오르는 시람 한 명
- 서비스를 여는 구체적인 시간대와 상황
- 사용자가 마지막에 느끼는 감정
이 정도까지 구체화된 문장이 있고 나면, 그 다음부터는 '이 기능이 저 장면에 정말 기여하는가?' 를 기준으로 이야기할 수 있습니다.
흐름을 그리기
MVP를 정의할 때 기능 단위로 출발하면 거의 항상 모든 것이 필요할 것만 같습니다. 이것도 필요할 것 같고, 저것도 나중에 문제될 것 같다는 방향으로 흘러가기 쉽습니다.
조금 다르게, 우선은 사용자의 하루 속에서 이 서비스가 어떤 흐름으로 쓰이는지를 상상하는 편이 좋습니다. 예를 들어, 퇴근 후 10분 자기계발 서비스를 떠올려 보겠습니다. 사용자의 흐름을 아주 간단히 정리하면 대략 이 정도입니다.
퇴근하고 집에 들어와 잠깐 쉬다가, 습관처럼 유튜브를 켜기 전에 이 서비스를 한 번 열어봅니다. 오늘 에너지에 맞는 10분짜리 콘텐츠 하나를 선택해서 보고, 끝난 뒤에는 오늘 기억에 남는 한 줄 정도만 남깁니다. 그리고 '오늘도 수고했어요' 같은 가벼운 피드백을 확인하고, 앱이나 웹을 닫습니다. 이 흐름에서 정말 중요한 지점은 많지 않습니다. 서비스를 여는 계기, 콘텐츠 하나를 고르고 보는 행위, 오늘의 흔적을 남기는 마지막 동작, 오늘도 해냈다는 피드백, 이 정도면 일단 핵심 경험은 있습니다. 이렇게 흐름이 먼저 잡혀 있으면, 기능을 볼 때 관점이 달라집니다.
어떤 기능은 이 흐름의 중간 단계 자체를 만들어 주는 데 필요하고, 어떤 기능은 이 흐름은 조금 더 편하게 만들어 줄 뿐이며, 어떤 기능은 흐름과는 거의 관계없이 그냥 있으면 좋을 것 같은 것일 뿐입니다. MVP에서는 당연히 필요한 부분만 남겨야 합니다. 조금 더 편해지는 것들은 추후 버전으로 미루고, 있으면 좋을 것 같은 것들은 당분간 생각하지 않는 편이 낫습니다.
지금 꼭 필요한 질문만 남기기
실제 작업에서는 기능을 한 번은 쭉 나열해야 합니다. 업계에서는 IA, 정보구조도, 기능명세서 같은 용어로 부르는데요. 보통은 엑셀에서 테이블 형태로 기능 리스트가 한 줄씩 생깁니다. 이 때 필요한 것은 복잡한 프레임이 아니라, 각 기능 옆에 아주 간단한 질문 몇 개를 기준으로 우선순위를 정하는 것입니다. 질문의 핵심은 다음과 같습니다.
1.이 기능이 없으면 아까 정의한 그 한 장면이 아예 만들어지지 않는가?
- 이 질문에 YES 라고 답할 수 있는 기능만이 MVP가 될 수 있습니다.
- 그 장면이 조금 불편해지더라도 여전히 일어날 수 있다면 후순위입니다.
2. 이 기능을 지금 만들어두면, 나중에 구조를 바꾸기가 얼마나 어려운가?
- 데이터 구조를 바꾸거나, 여러 외부 서비스와 연동되거나, 권한 시스템과 깊게 엮이는 기능이라면,
한 번 도입하면 되돌리기가 쉽지 않습니다. - 이런 기능은 서비스의 방향성이 어느 정도 굳어진 뒤에 도입하는 편이 낫습니다.
3. 처음 100명이 이 서비스에 대해 이야기해 줄 때, 이 기능이 없어서 이야기를 못 할 정도인가?
- MVP의 목적이 완성된 제품을 자랑하는 것이 아니라,
사용자를 이해하고, 문제 정의와 해결 방향이 맞는지 검증하는 것이라면,
사용자가 핵심 경험에 대해 피드백을 줄 수 있는 정도면 충분합니다. - 세부 편의 기능까지 모두 갖춰져 있을 필요는 없습니다.
처음 버전에서 특히 조심해야 하는 기능들
어떤 기능들은 겉으로 보기에는 가벼워 보이지만, 실제로는 처음 버전에 넣었을 때 부담이 크게 늘어나는 것들입니다. 아래의 몇 개의 예시를 들어보겠습니다.
여러 개의 소셜 로그인
대표적인 사례입니다. 카카오, 구글, 애플, 네이버를 한 번에 다 넣고 싶어지는 순간이 많습니다. 하지만 각 로그인 방식마다 설정과 연동, 오류 케이스, 테스트 조합이 따로 생깁니다. MVP 단계에서 사람들이 이 문제를 해결하고 싶어 하는지를 검증하는 데에는, 로그인 방식 하나만 있어도 충분한 경우가 대부분입니다.
복잡한 권한 구조
관리자, 서브 관리자, 멘토, 멘티, B2B 파트너 등 역할을 처음부터 세분화해두면, 화면 하나를 만들 때마다 누가 볼 수 있는지, 누가 수정 가능한지, 모든 조합을 고려해야 합니다.
초기에는 보통 일반 사용자와 내부 관리자 두 단계만으로도 운영이 충분히 가능합니다. 이렇게 단순하게 시작할수록, 서비스가 어느 정도 자리 잡은 뒤 권한을 세분화하는 것이 훨씬 수월합니다.
실시간 기능
실시간 채팅, 실시간 알림, 실시간 동시 편집 같은 요소는 사용 경험 측면에서 매력적입니다. 하지만 인프라와 장애 대응, 테스트 부담이 매우 큽니다.
MVP에서 필요한 것은 실제로 사람들이 이 문제 해결을 원하는지이고, 반드시 실시간이어야 하는지는 조금 늦게 고민해도 되는 경우가 많습니다. 가능하다면 알림을 모아서 보내거나, 새로고침할 때 업데이트되는 형태처럼 비실시간 버전으로 먼저 설계할 수 있는지 고려해 보는 것이 좋습니다.
여러 개의 외부 연동
결제 수단을 여러 개 붙이거나, 여러 메시징 채널과 동시에 연동하거나, 스토리지 서비스를 여러 곳과 연동하면, 오류 포인트와 디버깅 범위가 기하급수적으로 늘어납니다. MVP 단계에서는 핵심 사용자가 실제로 쓸 법한 채널 하나만으로도 충분히 검증할 수 있습니다.
지나치게 정교한 통계 대시보드
마지막입니다. 여러 필터와 그래프를 동시에 보여주는 화면은 만드는 데도 복잡하고, 유지하는 데도 많은 비용이 듭니다.
하지만 MVP 단계에서 사람들이 실제로 이 서비스를 쓰고 있는지를 확인하기에는 서버 로그와 간단한 관리자용 리스트만으로도 충분합니다. 정말 자주 보는 패턴이 생겼을 때, 그때 그 패턴에 맞게 리포트를 설계하는 편이 덜 낭비입니다.
이 기능들이 쓸모없다는 뜻은 전혀 아닙니다. 단지, '처음 버전에서 꼭 있어야 하는가?'라는 질문을 던지면
대부분 '아직은 아니다' 라는 쪽에 더 가깝다는 것입니다.
결정 근거를 기록하자
범위를 줄이는 과정은 결국 선택의 역사입니다. 어떤 기능은 이번에 넣고, 어떤 기능은 다음으로 미루게 됩니다. 이때 감으로 그랬다는 수준에서 머물러 있으면 나중에 설명하기도 어렵고, 스스로 다시 돌아봐도 기준이 흔들립니다.
실제로는 매우 단순한 표 하나만 있어도 상황이 다릅니다. 엑셀이나 노션에 기능 목록을 쭉 적어놓고,
그 옆에 몇 가지 항목만 둡니다. 예를 들면, 이런 것들이 있습니다.
- 핵심 경험에 직접 필요 여부
- 복잡도
- 나중에 구조 변경 난이도
- 없어도 처음 사용자가 써볼 수 있는지
각 기능 옆에 체크나 짧은 메모로만 표시해 두어도, 시간이 지난 뒤에 다시 봤을 때 '왜 그때 이 기능을 빼고, 저 기능을 남겼는지'를 이해할 수 있습니다. 만약 제가 회사의 조직장이라면, 각 파트 리더에게 이 업무를 부탁할 것입니다. 그러면 사업, 기획, 디자인, 개발 팀원 대부분이 납득할 만한 우선순위가 나오게 될 것이라고 믿습니다. 또, 이 기능은 다음 버전으로 미루자고 말할 때 감정이 아니라 기준으로 이야기할 수 있습니다.
표의 완성도가 중요한 것은 아닙니다. 중요한 것은, MVP 범위가 그때그때 말 잘하는 사람이 이긴 결과가 아니라, 서비스 목표와 제약을 고려해서 의식적으로 선택된 결과라는 점을 서류 하나로라도 남겨 두는 것입니다.
MVP를 검증용 버전으로 생각해 봅니다
마지막으로 관점을 하나 정리하고 싶습니다. MVP를 대충 만든, 완성도가 떨어지는 버전 정도로 생각하면 기능을 뺄 때마다 마음이 불편해집니다. 이래도 되나? 하는 불안이 자연스럽게 따라오고요. 만약 내가 이 프로젝트로 커리어를 쌓고 싶은 사람이라면 마음이 조급해집니다.
MVP를 조금 다르게 정의하면 부담이 줄어듭니다. 이 문제 정의와 해결 방식, 타깃 설정이 실제 세상과 크게 어긋나지 않는지 확인하기 위한 검증용 버전, 이렇게 생각하면 중요한 질문이 바뀝니다. “이 기능까지 있어야 사람들이 좋아할까?”가 아니라, “이 정도만 있어도 사람들이 이 서비스가 무엇을 하려는지 이해하고, 문제와 해결 방식에 대해 솔직한 피드백을 줄 수 있을까?”로 바뀝니다.
MVP에서 필요한 것은 완벽한 모양이 아닌, 사용자와 대화를 시작할 수 있는 최소한의 형태입니다. 그 대화에서 얻은 피드백으로 방향을 조정하고, 그 다음 버전에서 부족한 기능을 보완해 나가는 편이 결국 더 멀리, 더 오래 가는 데 도움이 됩니다.
첨언, 사회 초년생 분들에게
이 글은 숙련된 분들보다는 경험이 적은 사회초년생이나, 사업을 처음 시작하는 분들이 주로 읽게 되실 거라고 생각하는데요. 특히 사회초년생에게 꼭 드리고 싶은 말씀이 있습니다.
내가 기획하고 개발한 기능이 MVP에 들어가지 못했다고 해서 너무 실망하지 않았으면 합니다. 시간과 비용은 한정되어 있고, 이익집단에 있다면 한정된 자원을 효율적으로 사용하기 위한 방법을 찾게 됩니다. 당장 이직을 준비하고 계신가요? 포트폴리오와 면접을 준비할 때, 생각의 방향을 조금만 바꿔 보세요. 내가 만든 기능이 MVP에 들어가지 않은 이유가 무엇인지 논리적으로 이야기해 보세요. 나에게 의사결정권이 있었다면 어떻게 했을지 생각해 보세요. 서비스 사용자들이 문제를 해결할 수 있도록 어떻게 피드백을 줬는지, 내가 했던 일을 잘 정리해 보세요.
출시하지 않았다고 해서, 내가 했던 일이 없어지는 것은 아닙니다. 모든 일을 모두 한번에 할 수 없다는 것을 모두가 알고 있습니다. 여러분에게는 나중에 같은 상황이 벌어졌을 때, 스펙을 줄여서 출시해야 할 때 상황을 대처할 무기가 있는 셈입니다. 멀리 보세요.
정리
MVP를 정할 때에는
1. 처음 100명이 반드시 경험해야 할 한 장면을 문장으로 먼저 적고
2. 그 장면 속에서 사용자의 흐름을 거칠게라도 머릿속에 그려본 뒤
3. 그 흐름을 만들기 위해 지금 꼭 필요한 것과 나중에 넣어도 되는 것을 차분히 가르는 작업이 필요합니다.
아이디어와 기능 목록이 조금 과하게 부풀었다고 느껴질 때, 무엇을 더 넣을지보다, 무엇을 이번 버전에서는 만들지 않을까? 를 먼저 떠올리는 습관을 들이면, 서비스의 본질에 더 집중하면서도 일정과 비용, 리스크를 훨씬 안정적으로 가져갈 수 있습니다.