‘빨리 만든 MVP’와 ‘대충 만든 MVP’의 차이는 출시 시점에 보이지 않습니다. 둘 다 첫 화면은 멀쩡하기 때문입니다. 차이는 6개월 뒤, 두 번째 기능을 붙이려고 할 때 드러납니다. 한쪽은 그 위에 얹으면 되고, 다른 한쪽은 처음부터 다시 짭니다.
MVP를 만들 때 “일단 빨리 띄우자”는 말이 자주 나옵니다. 맞는 말이지만, 이 한 문장이 두 가지 다른 작업을 같은 이름으로 부르게 만듭니다. 하나는 범위를 줄여서 빨리 만든 MVP, 다른 하나는 기준을 줄여서 빨리 만든 MVP입니다. 외관은 비슷하지만 6개월 뒤 결과가 완전히 다릅니다.
전자는 다음 기능을 그 위에 얹을 수 있습니다. 후자는 두 번째 기능을 추가하려고 하면 “이건 다시 짜야 해요”라는 결론에 도달합니다. 단지 ‘속도’만 가지고는 두 MVP를 구분하지 못합니다.
빨리 만들 수 있는 이유는 두 가지뿐입니다.
이 둘은 결정적으로 다릅니다. 첫 번째는 다음 단계에 자연스럽게 확장됩니다. 두 번째는 다음 단계에서 무조건 만나는 기술 부채가 됩니다. 같은 ‘출시까지 4주’라도 어느 쪽이었느냐에 따라 6개월 뒤가 달라집니다.
SL:IT은 MVP 시작 시점에 두 줄로 정리합니다. 지금 좁혀도 되는 것과 지금 좁히면 다음에 비싸지는 것입니다.
| 좁혀도 되는 것 | 화면 수, 사용자 시나리오, 통계/대시보드, 디자인 디테일, 다국어, 결제 방식 다양화 |
|---|---|
| 좁히면 안 되는 것 | 도메인 모델, 데이터 저장 구조, 권한 체계, 에러 처리 흐름, 로그/감사 자리 |
위쪽은 나중에 ‘추가’하면 되는 것들이고, 아래쪽은 나중에 추가하려면 ‘뜯어고쳐야’ 하는 것들입니다. 같은 ‘나중’이지만 비용이 한 자릿수 차이입니다.
“그럼 처음부터 마이크로서비스로 가자”는 의미는 아닙니다. 오히려 그 반대입니다. 초기에는 한 저장소, 한 서비스로 시작하되 도메인·저장·실행 계층만 함수 수준에서 나눕니다.
이 구분이 있으면 다음 단계에 어떤 부분을 빼서 다른 서비스로 옮기든, 외부 시스템에 넣든, 모델을 갈아끼우든 비용이 작습니다. 구분이 없으면 같은 작업이 “재구축”이 됩니다.
속도와 안전성을 같이 잡는 가장 단순한 방법은 이미 검증된 조합을 기본값으로 쓰는 것입니다. SL:IT은 React·Next.js·Supabase·OpenAI·Playwright 같은 조합을 기본값으로 제안합니다. 새 프로젝트마다 스택을 처음부터 정하지 않습니다.
이유는 단순합니다. 검증된 조합은 누가 만들어도 비슷한 품질이 나오고, 운영 시점에 발견되는 문제 패턴이 이미 알려져 있고, 다음 사람에게 인수인계하기 쉽습니다. 새로운 스택은 그 자체가 리스크입니다. MVP 단계에서 만지작거릴 부분이 아닙니다.
MVP를 잘못 만들었다는 신호는 거의 정해져 있습니다. 다음 중 셋 이상이 보이면 두 번째 기능 추가 전에 한 번 점검하는 편이 낫습니다.
SL:IT은 MVP를 시작할 때 “좁혀도 되는 것”과 “좁히면 안 되는 것”을 먼저 정리합니다. 그 다음 검증된 조합 위에서 도메인·저장·실행 계층을 분리한 뼈대를 잡고, 첫 사용자 흐름 한 개를 그 위에 올립니다.
그래서 SL:IT의 MVP는 출시 시점에 가벼우면서도, 두 번째·세 번째 기능을 추가할 때 “다시 짜자”는 말이 안 나오는 구조를 갖습니다. 빨리 만드는 것과 대충 만드는 것은 출시까지 걸리는 시간이 같아 보일 수 있어도, 그 이후가 다릅니다.
