70 lines
4.2 KiB
Markdown
70 lines
4.2 KiB
Markdown
---
|
|
id: 최소 기능 제품 (MVP) 20260320
|
|
created: 2026-03-20 14:00
|
|
tags:
|
|
---
|
|
**M**inimum **V**iable **P**roduct , 최소 기능 제품
|
|
![[MVP(Minimum Viable Product)#📑 개념]]
|
|
|
|
### MVP의 핵심: "완벽함보다 실행"
|
|
|
|
저자는 개발자가 빠지기 쉬운 가장 큰 함정이 **모든 기능을 다 갖춰야 출시할 수 있다**는 생각이라고 지적합니다.
|
|
|
|
- **MVP의 정의:** 고객에게 가치를 전달할 수 있는 **최소한의 핵심 기능**만 담은 제품입니다.
|
|
|
|
- **개발자 버전 MVP:** 복잡한 아키텍처나 부가 기능(로깅, 화려한 UI, 상세 설정 등)을 다 붙이기 전에, **비즈니스 로직의 핵심**이 돌아가는 가장 단순한 형태의 코드를 먼저 완성하는 것입니다.
|
|
|
|
### 왜 MVP가 클린 코드와 연결될까요?
|
|
|
|
단순히 빨리 만드는 게 목적이 아닙니다. MVP 방식으로 개발하면 다음과 같은 이점이 있습니다.
|
|
|
|
- **복잡성 제어:** 처음부터 거대한 시스템을 설계하면 복잡도가 기하급수적으로 늘어납니다. 작은 단위(MVP)로 시작하면 코드가 단순하게 유지됩니다.
|
|
|
|
- **피드백 기반 개선:** 핵심 로직을 먼저 짜서 돌려봐야 어디가 진짜 병목인지, 어디에 스케일업이 필요한지 데이터로 확인할 수 있습니다. 추측에 근거한 과잉 엔지니어링을 막아줍니다.
|
|
|
|
- **YAGNI 실천:** "이 기능도 필요하겠지?"라는 가설을 버리고, "이게 없으면 프로그램이 안 돌아간다"는 기능만 넣게 됩니다.
|
|
|
|
### MVP를 만드는 3단계 사고법
|
|
|
|
책에서 제안하는 실천 방안은 다음과 같습니다.
|
|
|
|
1. **핵심 가치 식별:** 이 프로그램이 존재해야 하는 단 하나의 이유(20%의 핵심)는 무엇인가?
|
|
|
|
2. **군더더기 제거:** 그 가치를 구현하는 데 당장 필요 없는 모든 기능(80%)을 목록에서 지운다.
|
|
|
|
3. **반복 개선:** 최소한의 기능을 구현해 배포한 뒤, 실제 사용자나 시스템의 반응을 보고 살을 붙인다.
|
|
|
|
[[파레토의 법칙]], [[80대20 원칙(The Pareto Principle)]]
|
|
|
|
#### "MVP는 '덜 만든 제품'이 아니라, '가장 핵심적인 가치만 담은 가장 단순한 제품'이다."
|
|
|
|
> [!question]
|
|
> Q. 왜 여기서 갑자기 MVP에 대한 설명이 나온거야?
|
|
> A. 2장의 파레토 법칙이 어디에 집중할지 알려주는 **전략**이었다면, 3장은 그 전략을 실행하는 **전술**에 가깝습니다.
|
|
|
|
- 어떻게 20%에 집중할 것인가? 에 대한 해답이라는 것
|
|
- 완벽하게 만들려다 복잡해지는 것보다, 단순하게 만들어 피드백을 받는 것이 더 빠르다.
|
|
|
|
|
|
## MVP를 만드는 이유
|
|
### 1. 피드백 루프의 단축
|
|
MVP를 만드는 가장 큰 이유 중 하나는 **실제 데이터**를 빨리 얻기 위함입니다.
|
|
- 머릿속으로 성능이나 확장성을 고민하기보다, 최소 기능을 배포해보고 **어디서 진짜 병목이 발생하는지** 확인하라는 것입니다.
|
|
|
|
- 추측에 근거한 설계보다 **측정된 데이터에 근거한 개선**이 훨씬 강력한 단순함을 만듭니다.
|
|
|
|
### 2. 기능의 범위를 제한하는 법 (Scope Creep 방지)
|
|
프로젝트를 하다 보면 자꾸 기능이 추가되는 현상을 경계하라고 조언합니다.
|
|
|
|
- **우선순위 재정의:** 새로운 기능 요청이 들어올 때마다 **이 기능이 핵심 가치(20%)에 포함되는가?** 를 끊임없이 질문해야 합니다.
|
|
|
|
- **거절의 미학:** 단순함을 유지하기 위해 핵심이 아닌 기능은 과감히 목록에서 제외하거나 다음 버전으로 미루는 과정이 3장에서 중요하게 다뤄집니다.
|
|
|
|
> [!note] 요약
|
|
> - **엄격한 MVP 유지:** "이 기능이 없으면 제품이 안 돌아가는가?"라는 질문에 '아니오'라면 다음 버전으로 미룹니다.
|
|
>
|
|
> - **20%에 집중:** 핵심 가치를 만드는 20%의 기능 외에는 모두 **잠재적인 소음**으로 간주하고 경계합니다.
|
|
>
|
|
> - **문서화와 소통:** 추가 요청이 들어오면 "좋은 아이디어지만, 이번 MVP 범위에는 포함되지 않습니다. 다음 단계에 검토합시다"라고 선을 긋는 것이 중요합니다.
|
|
|