2단계에서 배포까지 마쳤다면, 이제 화면에 뭘 채울지 정할 차례입니다. 이 단계에서 가장 흔히 실패하는 이유는 기술이 부족해서가 아니라, 이것저것 다 넣고 싶은 욕심을 못 참아서입니다. MVP(최소 기능 제품)는 '부실한 버전'이 아니라, 1단계에서 찾은 니즈 하나를 정확히 해결하는 데 필요한 만큼만 남긴 버전입니다.
반면교사: 위젯 16개짜리 홈페이지
늑구맵 초기 버전은 워드프레스(Elementor) 기반이었는데, 홈페이지 한 장에 애니메이션 지도 위젯, 뉴스 모음, 팩트체크, FAQ 같은 위젯이 16개나 붙어 있었습니다. 방문자 입장에선 볼 게 많아 보일 수 있지만, 로직 대부분이 Elementor의 Custom HTML 위젯 안에 통짜 HTML+CSS+JS로 박혀 있어서 나중에 손대기가 극도로 어려운 구조였습니다. 결국 전면 재구축을 해야 했습니다. 처음부터 스코프를 좁혔다면 겪지 않아도 될 비용이었습니다.
스코프를 좁히는 질문
이 기능이 없으면 니즈가 해결이 안 되는가
늑구맵이 실제로 반드시 필요했던 건 "언론 보도와 수색 당국 발표를 바탕으로 정리한 이동 경로와 가장 최근 포착 지점", 딱 이거 하나였습니다. SBTI 성격유형 테스트나 굿즈 투표 같은 부가 콘텐츠는 니즈 해결과 무관한 팬 서비스였고, 나중에 애드센스가 '낮은 가치 콘텐츠'로 판단한 원인 중 하나가 되기도 했습니다. 재밌어 보인다는 이유로 넣은 기능은 한 번 더 의심해야 합니다.
이 데이터가 지금 있는가, 만들어야 하는가
이미 존재하는 정보(뉴스, 공공 발표, 후기)를 정리해서 보여주는 것과, 사용자가 직접 입력해야 채워지는 구조는 난이도가 다릅니다. 처음 MVP는 되도록 '지금 있는 데이터를 정리해서 보여주는' 쪽으로 좁히고, 사용자 입력 구조는 다음 단계에서 다룹니다.
오늘 안에 만들 수 있는가
MVP의 기준은 '완성도'가 아니라 '속도'입니다. 거지맵은 이틀, 늑구맵은 이슈가 터진 당일에 만들기 시작했습니다. 오늘 안에 만들 수 없는 범위라면, 그 기능은 지금 스코프에서 빼고 나중 버전으로 미루는 게 맞습니다.
MVP에 남길 것 / 뺄 것
남긴다
- 니즈를 직접 해결하는 화면 하나 (지도, 목록, 검색 등 핵심 기능)
- 그 화면이 의존하는 데이터 (정적 JSON이어도 충분)
- 사용자가 다음에 뭘 해야 할지 알 수 있는 최소한의 안내
뺀다
- '있으면 재밌을 것 같은' 부가 콘텐츠 (퀴즈, 투표, 이벤트성 위젯)
- 아직 쓸 사람이 없는 회원가입/로그인
- 데이터가 몇 개뿐인데 만드는 관리자 페이지
MVP 체크리스트
늑구맵의 생각
스코프를 좁히는 건 기능을 포기하는 게 아니라 순서를 정하는 것입니다. 빼기로 한 기능은 니즈가 검증된 뒤에 다시 넣으면 됩니다. 반대로 처음부터 다 넣고 시작하면, 나중에 뭘 빼야 할지 판단할 기준 자체가 없어집니다. 다음 단계에서는 이 MVP에 실제 데이터와 API를 연결하는 방법을 다룹니다.