2025년 MVP: 창업자가 만들 것, 흉내낼 것, 무시할 것

2025년의 MVP: 목표는 기능 출시가 아니라 학습입니다

2025년의 MVP는 “제품의 가장 작은 버전”이 아닙니다. 그것은 명확한 학습 결과를 산출할 수 있는 가장 작은 테스트입니다. 요점은 고객, 문제, 지불 의사, 채널 등에 대한 불확실성을 줄이는 것이지, 축소된 로드맵을 내는 것이 아닙니다.

만약 당신의 MVP가 특정 질문(예: “바쁜 클리닉 관리자들이 노쇼를 줄이기 위해 월 $99를 지불할까?”)에 답을 주지 못한다면, 그것은 아마도 MVP라는 라벨을 단 초기 제품 개발일 가능성이 큽니다.

MVP가 무엇인지(그리고 아닌지)

MVP다: 좁게 정의된 사용자를 위해 측정 가능한 수요와 행동을 얻을 수 있는 집중된 실험.\

MVP가 아니다: 미니 제품, 기능 체크리스트, 혹은 비밀스럽게 확장하려는 “v1”. 또한 테스트 중인 한 가지 항목의 품질에 대해 대충해도 된다는 변명도 아닙니다. 최소한으로 만들되 신뢰성은 유지해야 합니다.

MVP vs 프로토타입 vs 파일럿 vs 베타

• 프로토타입: 아이디어를 보여주기 위한 것(대개 실제 데이터나 실사용자 없이). 사용성 테스트와 이해 확인에 좋지만 수요 증명에는 약함.
• MVP: 핵심 결과를 엔드투엔드로 제공하여(일부가 수작업일지라도) 가치와 구매 행동을 테스트함.
• 파일럿: 특정 고객/그룹을 대상으로 한 통제된 도입. 높은 접점 지원과 명확한 성공 기준을 가짐.
• 베타: 거의 완성된 제품을 넓게 공개해 버그·엣지케이스·채택 마찰을 찾는 단계—문제가 중요한지 발견하려는 단계는 아님.

사전 기대치 설정

빠르게 움직되 신중하게:\

• 속도: 분 또는 몇 주를 목표로, 분기 단위가 아님.
• 집중: 한 사용자, 한 직무, 한 핵심 플로우.
• 측정 가능한 결과: 빌드 전에 “예”, “아니오”, “모르겠다”가 무엇인지 정의.

MVP를 학습 도구로 대하면 잡음은 줄고 각 반복은 더 날카로워집니다.

문제에서 시작하기: 대상과 그들의 변화

MVP는 특정 사람의 특정 문제에 초점을 맞출 때만 효과적입니다. 대상과 사용 후 그들의 하루에 어떤 변화가 있는지 말할 수 없다면, 당신은 MVP를 만드는 것이 아니라 기능을 모으고 있는 것입니다.

고객(및 긴급성) 식별하기

실제 고객 유형 하나를 묘사하는 것으로 시작하세요—“중소기업”이나 “창작자” 같은 포괄적 표현이 아니라 길에서 알아볼 수 있는 사람을 떠올릴 수 있어야 합니다.

물어볼 것들:

• 그들은 누구인가? 역할, 맥락, 제약(시간, 예산, 승인 등).
• 어떤 일을 끝내려 하는가? 그들이 해결책에 ‘고용’하는 결과.
• 왜 지금인가? 이번 주에 시급한 이유(마감, 수익 압박, 컴플라이언스, 이탈, 체면, 기회비용).

긴급성이 없으면 검증은 느리고 시끄러워집니다—사람들은 “관심 있다”고 말하지만 행동은 바뀌지 않습니다.

핵심 약속을 한 문장으로 적어라

고객 + 직무 + 결과를 연결하는 약속문을 쓰세요:

“For [특정 고객], we help you [직무 완료] so you can [측정 가능한 결과] without [주요 희생/리스크]”

이 문장은 필터 역할을 합니다. 이걸 강화하지 않는 것은 아마도 MVP 범위 밖입니다.

최소의 가치 순간(‘아하’) 정의하기

MVP는 사용자가 “된다”라고 생각하게 만드는 하나의 부정할 수 없는 순간을 제공해야 합니다.

‘아하’ 예시:

• 그들이 전에 추측하던 질문에 답하는 리포트
• 번거로운 주고받음 없이 확인된 예약
• 발송할 만큼 ‘충분히 괜찮은’ 초안 생성

관찰 가능하게 만드세요: 사용자가 무엇을 보고, 클릭하고, 받는가?

현재 사용하는 대안을 명명하라

당신의 경쟁자는 보통 우회 방법입니다:

• 스프레드시트, 받은편지함 검색, 템플릿, VA, 에이전시, 동료에게 묻기, 또는 아무 것도 하지 않기

대안을 알면 당신의 MVP가 명확해집니다: 완벽해지려는 것이 아니라 기존에 의존하던 것보다 더 나은 절충안을 제시하는 것입니다.

아이디어를 검증 가능한 가설과 결정으로 전환하기

MVP는 다음 행동을 바꿀 수 있는 특정 질문에 답할 때만 유용합니다. 화면을 설계하거나 코드를 쓰기 전에, 아이디어를 테스트 가능한 가설과 당신이 기꺼이 내릴 결정을 담은 문장으로 옮기세요.

실제로 테스트할 수 있는 2–3개의 가설로 시작하라

며칠 또는 몇 주 안에 증명하거나 반증할 수 있는 문장으로 쓰세요:

• 문제 가설: “[직무]를 관리하는 사람들이 현재 [우회 방법] 때문에 시간/돈을 잃고 있으며 주간 단위로 고통을 느낀다.”
• 지불 의사 가설: “자격 있는 잠재고객 Y명 중 최소 X명이 데모나 파일럿 제안을 본 후 $N/월(또는 선결제)에 동의한다.”
• 유지 요인 가설: “사용자가 첫 [시간창] 내에 [핵심 결과]를 달성하면 별도 알림 없이 [빈도]로 돌아온다.”

숫자를 명시하세요. 숫자가 없으면 측정할 수 없습니다.

먼저 답할 한 가지 주요 질문을 골라라

MVP는 가장 큰 불확실성을 우선시해야 합니다. 예:

• “그들이 아예 결제할까?”(가격 테스트/사전판매)
• “문제가 충분히 급해서 전환할까?”(컨시어지 워크플로)
• “결과를 일관되게 제공할 수 있을까?”(수작업 우선 파일럿)

하나를 선택하세요. 부차적 질문은 주요 테스트를 늦추지 않는 범위에서만 허용됩니다.

중단, 피벗, 확장 기준을 정의하라

결과가 무엇을 의미하는지 미리 정하세요:

• 중단: “타깃 고객 15명 중 2명 미만이 제안 후 두 번째 통화를 예약한다.”
• 피벗: “구매는 하지만 다른 세그먼트/다른 결과를 포함해야만 산다.”
• 확장: “2주 내에 5+ 고객이 선결제하거나 LOI에 서명하고 최소 3명이 온보딩을 완료한다.”

‘피드백 받기’ 같은 목표는 피하세요. 피드백은 결정을 촉발할 때만 가치가 있습니다.

무엇을 만들 것인가: 핵심 결과를 전달하는 하나의 플로우

MVP는 실제 사람에게 가치(결과)를 한 번 엔드투엔드로 제공해야 합니다. “제품의 대부분”이나 “데모”가 아니라, 사용자가 온 목적을 달성하는 하나의 완성된 여정이어야 합니다.

핵심 결과를 먼저 정의하라

질문: 누군가 이것을 사용할 때, 세션이 끝날 때 무엇이 변하는가? 그 변화가 당신의 결과입니다. MVP는 그 결과를 신뢰성 있게 만들어내는 가장 짧은 경로입니다.

반드시 현실로 만들어야 할 최소 요소들

결과를 한 번 제공하려면 보통 다음의 ‘실제’ 구성 요소 몇 개면 충분합니다:

• 단일 진입점(랜딩 페이지, 초대 링크, 간단 화면)으로 적절한 사용자를 플로우로 인도
• 사용자가 취하는 핵심 행동(생성/요청/예약/비교/제출)
• 결과를 생산하는 시스템의 응답(결과, 확인, 추천, 매칭된 리드, 생성된 계획)
• 사용자에게 결과를 전달하는 방법(앱 화면, 이메일, 다운로드 링크)

나머지는 추후에 해도 됩니다.

핵심 워크플로우 vs 지원 기능

계정, 설정, 역할, 관리자 대시보드, 알림, 선호도 관리, 통합, 완전한 분석 스위트 같은 일반적인 지원 기능과 핵심 워크플로를 분리하세요. 많은 MVP는 경량의 추적과 수작업 백오피스만으로 충분합니다.

하나의 해피 패스만 선택하고 엣지케이스는 미루기

단일 사용자 유형, 단일 시나리오, 단일 성공 정의를 고르세요. 이례적 입력, 복잡한 권한, 재시도, 취소, 다단계 커스터마이징, 희귀 오류 등은 나중에 처리하세요.

얇은 수직 단면(Thin vertical slice)을 생각하라

얇은 수직 단면은 전체 경험을 통과하는 좁은 엔드투엔드 경로를 의미합니다—UI, 로직, 전달까지 핵심만 만들어 한 번의 작업을 완수하게 합니다. 작지만 현실적이며 사용자가 실제로 무엇을 하는지 가르쳐줍니다.

무엇을 흉내낼 것인가: 학습을 유지하는 안전한 지름길

속도는 모든 곳에서 모서리를 깎는 것이 아니라 고객의 결정을 바꾸지 않는 지점에서 모서리를 깎는 것입니다. MVP에서 ‘흉내내기’의 목적은 약속한 결과를 빠르게 제공한 뒤 사람들이 다시 오거나 추천하거나 비용을 지불할 만큼 원하는지 배우는 것입니다.

컨시어지 전달: 단순 프런트엔드 뒤의 수작업 이행

컨시어지 MVP는 가치 테스트에 가장 빠른 방법인 경우가 많습니다: 당신이 수작업으로 일을 처리하고 고객은 결과를 경험합니다.

예를 들어 전체 매칭 알고리즘을 구축하는 대신 몇 가지 온보딩 질문을 묻고 직접 결과를 골라 줄 수 있습니다. 사용자는 여전히 핵심 결과를 얻고, 당신은 ‘좋음’이 무엇인지, 어떤 입력이 중요한지, 어떤 엣지케이스가 나타나는지를 배웁니다.

위저드-오브-오즈 UX: UI는 자동처럼 보이지만 사람이 작동

위저드-오브-오즈에서는 제품이 자동화된 것처럼 보이지만 실제로는 사람이 뒤에서 운영합니다. 자동화가 비용이 많이 들지만 상호작용 모델을 테스트해야 할 때 유용합니다.

실제로는 경험을 정직하게 유지하세요: 처리 시간에 대한 기대를 설정하고 실시간 자동화를 암시하지 마세요. 또한 수작업 단계를 문서화해 무엇을 먼저 자동화할지 결정할 근거를 만드세요.

안전한 곳에서 데이터 흉내내기(시드 콘텐츠, 데모 카탈로그, 시뮬레이션 히스토리)

시드된 콘텐츠는 빈 제품 문제를 막아줍니다. 마켓플레이스는 큐레이션된 카탈로그로 시작할 수 있고, 대시보드는 인사이트가 어떻게 보일지 보여주기 위해 시뮬레이션된 히스토리를 표시할 수 있습니다.

간단한 규칙:

• 가치를 설명하기 위해 시드 데이터를 사용하라, 트래픽을 속이기 위해 사용하지 마라.
• 신뢰에 영향을 줄 수 있는 경우 예제를 “샘플” 또는 “데모”로 표기하라.
• 고객 리뷰, 평점, 성과 주장을 날조하지 마라.

비차별화 요소는 템플릿과 노코드 사용

고객이 당신을 선택하지 않는 부분을 위해 커스텀 인프라를 만들지 마세요. 랜딩 페이지와 온보딩에 템플릿을, 내부 도구에 노코드를, 스케줄링·이메일·분석에는 기성 컴포넌트를 사용하세요. 엔지니어링 시간은 의미 있게 나아가게 하는 한 가지에 쓰세요.

절대 흉내내면 안 되는 것: 보안, 결제, 법적 문제

어떤 지름길은 돌이킬 수 없는 손상을 만듭니다:

• 보안 & 프라이버시: 민감한 데이터를 안전하지 않은 곳에 임시로 저장하지 마라.
• 결제: 정리할 수 없는 결제 플로우로 과금하지 마라; 환불과 약관을 명확히 하라.
• 법적/컴플라이언스: 규제 영역에서 테스트할 때는 적절한 제약을 두고 하라.

자동화를 흉내내되 책임은 흉내내지 마세요.

무시할 것: 수요를 증명하지 않는 시간 낭비 항목들

초기에는 “진짜 제품을 만드는 것”이 아니라 불확실성을 줄이는 것이 일입니다: 올바른 사람들이 이 문제를 가지고 있고, 그것을 해결하기 위해 행동(또는 지불)을 바꿀 것인가? 이 질문에 답하지 않는 것들은 보통 비싼 방해물입니다.

1) 기본 신뢰 수준을 넘는 과한 폴리싱과 브랜딩

깔끔한 UI는 도움이 되지만, 브랜드 시스템, 애니메이션, 일러스트 팩, 픽셀 단위 완성도에 몇 주를 쓰는 것은 핵심 신호를 바꾸지 않습니다.

신뢰를 전달하는 최소한만 하세요: 명확한 카피, 일관된 간격, 작동하는 폼, 명확한 연락/지원 방법. 사용자가 ‘괜찮아 보일 때’ 시도하지 않는다면 전체 리브랜딩이 그것을 살리지 못합니다.

2) 수요가 증명되기 전의 다중 플랫폼 빌드

웹 + iOS + Android를 동시에 만드는 것은 “사용자에게 도달”하는 것처럼 들리지만 실제로는 세 배의 코드베이스와 오류 표면적입니다.

대상 관습에 맞는 하나의 채널(대개 단순 웹 앱)을 선택하고 거기서 먼저 검증하세요. 반복 사용이나 유료 전환이 보일 때만 포팅하세요.

3) 복잡한 권한, 멀티테넌트 관리자, 완전한 현지화

역할 기반 접근, 관리자 패널, 국제화는 정당한 필요지만—Day 1의 필요는 아닙니다.

첫 고객이 명백히 엔터프라이즈나 글로벌 팀이 아닌 한, 단일 ‘소유자’ 역할과 수작업 우회로 시작하세요.

4) 수십만 사용자를 전제로 한 완벽한 확장성과 마이크로서비스

수십 명도 없는데 수백만 사용자를 위해 최적화하는 것은 고전적인 함정입니다.

실험을 위해 신뢰성 있는 단순한 아키텍처를 선택하세요. 당신은 실험을 위한 신뢰성만 필요할 뿐 분산 시스템은 아닙니다.

5) 핵심 지표를 모른 채 만든 고급 분석 대시보드

대시보드는 생산적인 느낌을 주지만 종종 중요한 것을 측정하지 않습니다.

가치의 지표(예: 반복 사용, 완료된 결과, 결제)를 한두 개 정의하고 단순하게 추적하세요—스프레드시트, 기본 이벤트, 수작업 로그로도 충분합니다.

실험 설계: 추측 없이 검증하는 방법

MVP는 그것을 둘러싼 실험만큼 유용합니다. 누구에게 말할지, 무엇을 물을지, 무엇이 당신의 판단을 바꿀지 결정하지 않으면 당신은 검증하는 것이 아니라 감정만 모으는 것입니다.

1) 현실적인 모집 계획 선택하기

이번 주에 실제로 실행할 수 있는 채널로 시작하세요:

• 웜 인트로: 과거 동료, 조언자, 친한 창업자—각각 2–3건의 특정 소개를 요청하세요.
• 커뮤니티: Slack/Discord, 서브레딧, 밋업—참여한 뒤 짧은 통화로 초대하세요.
• 아웃바운드: 좁은 리스트와 명확한 고통을 연결한 단순 메시지.

대상 세그먼트를 미리 정하세요(역할 + 맥락 + 트리거). “중소기업”은 세그먼트가 아닙니다; “미국 기반 웨딩 사진작가로 고객 후속에 주당 3시간 이상 쓰는 사람”은 세그먼트입니다.

2) 최소한의 믿을 만한 샘플 크기 정의

초기 단계 MVP에는 통계적 확실성이 아니라 패턴을 드러내는 샘플을 목표로 하세요.

실용 규칙: 일관된 세그먼트에서 8–12번의 대화로 반복되는 문제를 찾고, 그다음 5–10회의 구조화된 실험(데모/프로토타입/컨시어지)으로 사용자가 다음 단계로 나아가는지 보세요.

3) 스크립트 작성: 질문, 관찰, 측정

스크립트에는 다음이 포함되어야 합니다:

• 질문: 현재 워크플로, 문제가 마지막으로 발생한 때, 시도해본 것, 현재 비용 지불하는 것
• 관찰: 머뭇거리는 곳, 무시하는 것, 지시 없이 하는 행동
• 측정: 약속(예약된 시간, 공유한 데이터, 파일럿 시작, 결제 시도)

4) 시간 제한 설정 및 다음 단계 정의

실험은 며칠 또는 1–2주 단위로 운영하세요. 시작하기 전에 다음을 적으세요:

• 통과/실패 임계값(예: “유료 파일럿 3건” 또는 “사용자 6명이 도움 없이 플로우 완료”)
• 다음에 내릴 결정: 반복, 세그먼트 좁히기, 오퍼 변경, 중단

이렇게 하면 MVP가 학습에 집중하고 끝없는 빌드를 피할 수 있습니다.

중요한 지표: “좋다고 했다”보다 강한 신호들

초기 MVP 피드백은 공손함과 호기심 때문에 노이즈가 많습니다. 목표는 사용자에게 시간, 노력, 평판, 혹은 돈 같은 대가를 요구하는 행동을 측정하는 것입니다. 거래를 강요하지 않는 지표는 수요를 예측하지 못합니다.

활성화: “가치 획득” 순간

활성화는 사용자가 핵심 결과를 실제로 받았다는 첫 행동입니다—앱을 둘러본 것이 아니라.

예: “첫 리포트를 생성해 공유했다”, “첫 약속을 예약했다”, “처음 워크플로를 엔드투엔드로 완료했다.” 각 획득 경로별 활성화율을 추적하세요.

유지: 현실적인 창으로 본 반복 행동

유지는 단순히 앱을 다시 열었는지가 아닙니다. 문제에 맞는 주기로 핵심 행동을 반복하는지입니다.

일간/주간/월간 등 현실에 맞는 창을 정하고 묻세요: 활성화된 사용자가 별도 알림 없이 핵심 행동을 반복하는가? 반복에 지속적 추적이 필요하다면 서비스로 보이거나 가치가 아직 충분치 않을 수 있습니다.

수익 신호: 칭찬보다 돈(또는 준돈)이 강하다

강한 신호는 사전 주문, 보증금, 유료 파일럿, 유료 온보딩입니다. LOI는 도움되지만 구체적 범위·일정·결제 경로가 포함되지 않으면 약한 신호로 취급하세요.

지불하려 하지 않으면 가격 페이지, 체크아웃 플로우, ‘송장 요청’ 단계로 지불 의사를 테스트하고 왜 멈췄는지 추적하세요.

정성적 증거: 고통, 긴급성, 당김(Pull)

대화에서 일관성을 찾으세요:

• 그들 스스로 같은 문제를 반복해서 말하는가
• 명확한 “왜 지금인가”(마감, 위험, 손실 수익)
• 팀원을 소개하거나 “언제 사용할 수 있나요?”라고 묻는가

활성화·유지·결제 의사가 함께 움직이면 단순한 흥미가 아니라 실제 수요를 보고 있는 것입니다.

MVP에서의 AI: 불확실성을 숨기지 말고 학습을 앞당기기

AI는 학습 주기를 단축할 때 힘을 배가시킬 수 있습니다. 함정은 “AI 기반”이라는 문구로 요구사항 모호성, 약한 데이터, 흐릿한 가치 제안을 가리려 하는 것입니다. MVP는 불확실성을 보이게 해야지 묻어두면 안 됩니다.

AI가 진짜 도움이 되는 곳

피드백 주기를 단축할 때 AI를 사용하세요:

• 속도: 회신 초안, 인터뷰 요약, 인바운드 분류, 메시지 변형 생성
• 개인화: 사용자의 맥락에 따라 온보딩 문구/추천/후속을 조정(경계 명확히)
• 자동화: 잡무를 제거해 ‘가치 순간’을 더 빨리 관찰

AI가 결과를 보는 경로를 단축하지 못한다면 범위를 줄여야 합니다.

신뢰할 수 없는 출력 위에 사업을 세우지 마라

모델 출력은 확률적입니다. MVP에서는 오류가 발생할 수 있고 그 오류는 학습 전에 신뢰를 무너뜨릴 수 있습니다. “완전 자동화”를 주장하지 마세요—품질을 신뢰할 수 있고 실패에서 복구할 방법이 있어야 합니다.

실용적인 안전장치:

• 신뢰도 임계값을 두고 낮은 신뢰도는 대체 플로우로 보낸다.
• 중요한 결정은 사람 검토 루프(자신, 계약자, 사용자)를 둔다.
• 입력/출력을 로깅해 사용자가 실제로 무슨 경험을 했는지 디버깅한다.

기대치를 설정하고 차별화를 설계하라

AI가 무엇을 하고 무엇을 못 하는지, 그리고 수정 방법을 사용자에게 알려라. 간단한 “검토 및 승인” 단계가 신뢰를 보호하고 유용한 학습 데이터를 만들어줍니다.

마지막으로, 모델 자체를 moat(우위)로 삼지 마세요. 독점 데이터, 일상적으로 사용되는 워크플로우, 일관되게 도달할 수 있는 유통 채널으로 차별화하세요. MVP 목표는 그 조합이 반복 가능한 가치를 창출하는지 증명하는 것입니다.

속도 위한 기술 선택: 완벽이 아니라 변경에 대비하라

MVP의 기술 스택은 임시 의사결정 체계입니다. 최선의 선택은 영원히 확장되는 것이 아니라 마음을 바꾸기 쉽고 모든 것을 망가뜨리지 않는 선택입니다.

반복을 지원하는 가장 단순한 아키텍처로 시작하라

“지루한” 기본을 선호하세요: 한 앱, 한 DB, 한 큐(또는 없음), UI와 핵심 로직의 명확한 분리. 마이크로서비스, 이벤트 중심 아키텍처, 무거운 내부 도구는 워크플로가 유지할 가치가 증명될 때까지 피하세요.

규칙: 어떤 컴포넌트가 학습 시간을 줄이지 못하면 아마 늘이고 있는 것입니다.

통합 마찰을 줄이는 도구를 선택하라

전체 카테고리의 작업을 제거해주는 공급자를 고르세요:

• 인증: 관리형 인증(패스워드리스, OAuth, 팀 계정)
• 결제: 호스팅 체크아웃 + 고객 포털로 가격 실험을 백엔드 변경 없이 수행
• 이메일: 템플릿, 전송 보장, 웹훅을 가진 트랜잭셔널 이메일 서비스

이러면 MVP는 배관이 아니라 핵심 제품 결정에 집중할 수 있습니다.

바이브-코딩 플랫폼이 MVP 타임라인을 압축하는 경우

검증된 플로우를 작동하는 수직 단면으로 바꾸는 것이 병목이라면, 바이브-코딩 플랫폼(예: Koder.ai)이 처음 엔드투엔드 경로를 스펙에서 사용 가능한 앱으로 빠르게 옮기는 데 도움을 줄 수 있습니다.

Koder.ai는 채팅 인터페이스로 웹 앱(React)과 백엔드(Go + PostgreSQL)를 빌드하고 플래닝 모드, 소스 코드 내보내기, 배포/호스팅, 스냅샷/롤백을 지원하므로 핵심 플로우를 빠르게 반복할 수 있습니다. 핵심은 그 속도를 더 많은 실험을 돌리는 데 쓰고 범위를 확장하는 데 쓰지 않는 것입니다.

기본적 비협상 조건 설정

속도가 무책임을 뜻하지는 않습니다. 최소 기준:

• 프라이버시: 필요한 최소한의 데이터만 수집하고, 무엇을 저장하는지 문서화하며, 고객 데이터를 무작위 도구에 복사하지 마라.
• 백업: 자동화된 DB 백업과 정기 복구 테스트.
• 접근 제어: 관리자 역할과 사용자 역할 분리; 중요 행동 로깅.

가벼운 ‘재구축 트리거’ 로드맵 만들기

언제 재작성할지 추측하지 말고 트리거를 정의하세요: 예: “주간 배포 3회 이상 아키텍처로 막힘”, “핵심 워크플로를 2번 이상 바꿈”, “지원 시간 X시간/주 초과로 데이터 모델 한계”. 트리거가 발생하면 한 레이어씩 재구축하세요—제품 전체를 한꺼번에가 아니라.