- 일주일의 목표는 사람들이 정말 원하는지에 대한 증거를 얻는 것입니다. 완성된 제품은 그다음 문제입니다.
- 믿을 만한 증거는 사람들이 전화번호를 남기거나, 계약금을 내거나, 상담 일정을 잡는 행동입니다. 아이디어가 좋다는 칭찬은 증거가 되지 못합니다.
- 아무도 관심이 없다는 결과가 나와도 성공입니다. 방금 수십만 바트(태국 바트)를 아낀 셈이기 때문입니다.
1. 7일의 목표는 완성도보다 증거
신제품을 낼 때 가장 큰 비용은 개발비보다 아무도 원하지 않는 제품을 만드느라 쓴 여섯 달입니다. 그래서 이 일주일은 무언가를 만들기 전에, 사람들이 정말 원하느냐는 한 가지 질문에 답하는 데 씁니다.
기존의 제품 개발은 아이디어 회의로 시작해 계획서를 쓰고, 예산을 짜고, 디자인하고, 생산한 뒤에야 고객을 만납니다. 문제는 비용이 가장 많이 드는 지점에서 회사가 가장 느리게 배운다는 것입니다. AI는 조사 시간을 줄이고, 선택지를 종합하고, 문구, 이미지, 프로토타입, 테스트 자료를 만들어 팀이 고객을 더 빨리 만나게 해 줍니다. 하지만 실제 고객을 대신해 수요를 확인해 줄 수는 없습니다.
스프린트(Sprint)를 시작하기 전에 가설을 한 문장으로 쓰십시오. "우리는 [어떤 고객층]이 [어떤 문제]를 겪고 있으며 [어떤 결과]를 얻기 위해 [돈을 내거나/가입하거나/써 볼] 의향이 있다고 믿는다." 고객이 그 문제에 관심이 없거나, 제안을 믿지 않거나, 가격이 맞지 않는 것처럼 가장 큰 위험 하나만 고른 뒤 답을 찾을 실험을 설계하십시오.
2. 1일 차: 문제와 고객을 충분히 좁히기
흔한 실수는 기회를 놓칠까 봐 고객층을 너무 넓게 잡는 것입니다. 고객층이 넓으면 제안이 밋밋해져서 누구도 자기 이야기라고 느끼지 못합니다.

영업 대화, 리뷰, 고객 문의 티켓, 검색어, 구매하지 않은 이유에서 고객의 목소리를 모으십시오. 분류와 반복 패턴 집계는 AI에 맡기되, 맥락을 잃지 않도록 팀이 원문 사례를 직접 읽어야 합니다. 자주 일어나고, 영향이 분명하며, 회사가 해결하는 데 유리한 문제를 고르십시오.
상황, 현재 업무 방식, 문제로 인한 비용, 지금 쓰는 해결책, 그 해결책이 부족한 이유를 담은 고객 스냅샷(Customer Snapshot)을 만드십시오. "30~50세 중소기업 대표" 같은 넓은 페르소나는 피하고, "한 달 주문이 1,000건이 넘고 주문 상태 문의에 답하는 운영 직원이 적어도 세 명 있는 온라인 쇼핑몰 대표"처럼 실제로 만날 수 있는 집단을 고르십시오.
- 한 문장짜리 가설
- 인구통계만이 아닌 행동으로 정의한 목표 고객
- 실제 고객에게서 모은 증거 적어도 20건
- 스프린트가 답해야 할 가장 위험한 질문
3. 2일 차: 그럴듯한 데이터에 휘둘리지 않고 빠르게 시장 조사하기
AI의 도움을 받아 경쟁사, 고객이 쓰는 대안, 가격, 기능, 판매 문구를 모으고, 출처와 날짜는 매번 확인하십시오. 50쪽짜리 시장 보고서를 만들 필요는 없습니다. 고객이 이미 누구에게 돈을 내고 있는지, 어떤 빈틈에 근거가 있는지, 회사가 무엇을 따라 하면 안 되는지 알아내면 됩니다.

고객 5~8명을 인터뷰하되 과거의 행동을 물으십시오. "이런 제품이 있으면 사시겠습니까?"라고 묻지 마십시오. 사람들은 대개 예의 바르게 답하기 때문입니다. 그 일이 마지막으로 언제 있었는지, 어떻게 해결했는지, 시간과 돈이 얼마나 들었는지, 누가 승인했는지, 무엇 때문에 아직 바꾸지 않았는지를 물으십시오. 인터뷰 뒤 녹취와 요약은 AI에 맡겨도 되지만, 프로덕트 오너는 인터뷰에 직접 들어가 들어야 합니다.
| 알아야 할 것 | 강한 증거 | 약한 증거 |
|---|---|---|
| 문제가 중요합니까? | 고객이 실제로 돈, 시간, 기회를 잃고 있음 | 고객이 "흥미롭네요"라고 말함 |
| 예산이 있습니까? | 돈을 낸 적이 있거나 예산 책임자가 있음 | 예산을 받을 수 있을 것 같다고 생각함 |
| 바꿀 의향이 있습니까? | 만남, 시험 사용, 정보 남기기에 응함 | 설문 게시물에 좋아요를 누름 |
4. 3일 차: 제안과 대안 프로토타입 만들기
비용 절감, 속도 향상, 위험 감소처럼 서로 확실히 다른 가치 제안(Value Proposition)을 세 가지 만드십시오. 광고 문구를 조금씩 바꾼 정도로는 부족합니다. AI에게 결과, 기능, 예상 반론을 풀어 보게 하되, 선택은 1일 차와 2일 차의 데이터를 바탕으로 팀이 하십시오.

질문에 답할 수 있는 가장 낮은 수준의 프로토타입을 만드십시오. 메시지를 시험하려면 랜딩 페이지를, 사용 절차를 시험하려면 클릭할 수 있는 화면 이미지를 쓰십시오. 결과를 시험하려면 팀이 뒤에서 수작업으로 서비스를 제공하고 겉으로는 자동화된 시스템처럼 내보내십시오. 이런 컨시어지(Concierge) 방식으로 기술을 본격적으로 만들기 전에 가치를 입증할 수 있습니다.
5. 4일 차: 시험용 제품을 만들고 범위 정하기
"시험에 꼭 필요한 것"과 "아직 하지 않을 것" 목록을 분명하게 쓰십시오. 시험용 제품은 핵심 경로 하나를 처음부터 끝까지 완료할 수 있으면 됩니다. 사용자 계정, 대시보드, 많은 설정 항목, 모든 시스템과의 연동은 필요 없습니다. 시험 기간에 팀이 일부 단계를 손으로 처리할 수 있다면 그렇게 해서 속도를 얻으십시오.
AI로 UI 문구, FAQ, 체험 가이드, 샘플 데이터 세트, 테스트 케이스를 만드십시오. 실물 제품이라면 렌더링 이미지, 포장 목업, 초기 배합이나 사양, 소량 생산 계획을 활용합니다. 건강, 금융, 안전 관련 규제가 적용된다면 전문가의 검토를 받아야 하며, AI를 인증 주체로 삼아서는 안 됩니다.
고객에게 보여 주기 전에 지표를 정하십시오. 양식 작성률, 상담 예약률, 사전 주문 수, 고객이 받아들인 가격, 시험 사용자가 다시 쓰러 돌아오기까지 걸린 시간 등을 지표로 삼을 수 있습니다. 기준이 없으면 팀은 어떤 피드백이든 원래 아이디어를 지지하는 쪽으로 해석하게 됩니다.
6. 5일 차: 관심도를 실제로 측정하는 판매 페이지 만들기
판매 페이지는 다섯 가지 질문에 답해야 합니다. 누구를 위한 것인지, 어떤 문제를 푸는지, 어떤 결과를 주는지, 어떻게 작동하는지, 다음에 무엇을 하면 되는지입니다. 실제 고객이 쓰는 말을 쓰고, 전후 비교 사례나 결과를 보여 주십시오. 고객이 기술 때문에 사는 것이 아니라면 AI라는 단어로 시작하지 마십시오.
고객의 준비 정도에 맞는 수준의 실제 행동(Commitment)을 요구하는 CTA(Call to Action)를 만드십시오. 상담 예약, 샘플을 받기 위한 정보 남기기, 계약금 결제, 사전 주문이 그 예입니다. 무료로 이메일 주소만 받는 것은 사업 정보를 내주거나 돈을 내게 하는 것보다 약한 신호입니다. 전환 수는 적어도 증거의 질은 더 높습니다.
AI는 세그먼트별 메시지, 초대 이메일, 영업 스크립트를 빠르게 만들어 주지만, 그 안의 주장은 통제해야 합니다. 근거 없는 고객 수나 성과를 만들어 내지 말고, 약속한 것을 실제로 제공할 수 있는지 대표가 확인해야 합니다.
7. 6일 차: 자연 유입(Organic Traffic)을 기다리지 말고 제안을 들고 고객을 찾아가기
기존 고객, 인맥, 파트너, 연락 동의를 받은 명단을 통해 목표 고객층에 직접 연락하십시오. 문제를 짚고 행동을 요청하는 짧은 메시지를 보내고, 긴 글이나 기술에 대한 장황한 설명은 빼십시오. 사람들이 프로토타입을 보고 결정하게 만드는 것이 목표입니다.
시험할 때마다 대상 그룹, 메시지, 채널, 행동, 거절 이유를 기록하십시오. AI가 그날그날 패턴을 요약해 주면 다음 회차를 조정할 수 있습니다. 다만 여러 변수를 한꺼번에 바꾸면 무엇이 효과가 있었는지 알 수 없습니다. 관심을 보인 사람들이 제안을 거듭 잘못 이해한다면 기능을 더하기 전에 메시지부터 고치십시오.
8. 7일 차: 아이디어와 사랑에 빠지지 않고 결정하기
행동과 발언을 모아 피드백을 문제, 제안, 가격, 신뢰, 장애 요인으로 나누십시오. 미리 정해 둔 평가표(Scorecard)를 쓰고, 칭찬의 수를 수요로 착각하지 마십시오. 관심은 보이는데 다음 단계로 넘어가지 않는다면 문제가 급하지 않거나 요구한 행동(Commitment)의 문턱이 너무 높기 때문일 수 있습니다. 어느 쪽인지 가리려면 따로 실험해야 합니다.
결정은 세 가지 중 하나입니다. 계속 진행은 행동으로 드러난 증거가 있고 실제로 제공할 수 있을 때, 조정은 문제는 분명하지만 제안이나 고객층이 맞지 않을 때, 중단은 문제가 중요하지 않거나, 예산이 없거나, 회사에 유리한 점이 없을 때입니다. 7일 안에 멈추면 몇 달 치 투자를 아끼므로 그것도 성공입니다.
계속 진행한다면 다음 스프린트에서 입증할 것들을 적으십시오. 고객이 다시 쓰는지, 제공 비용이 충분히 낮은지, 품질이 일정한지 같은 것입니다. 사전 주문 몇 건을 받았다고 완성된 시스템을 만드는 단계로 건너뛰지 마십시오.
9. 빠른 출시를 회사의 일상적인 체계로 만들기
출처가 달린 고객 목소리 자료실, 가설 템플릿, 검토를 거친 프롬프트 모음, 랜딩 페이지 형식, 실험 대시보드를 만드십시오. 책임자와 작은 테스트 예산을 갖춘 월간 제품 스프린트(Product Sprint)를 정하십시오. 누가 제안했든 모든 아이디어는 같은 수준의 증거를 통과해야 합니다.
회사가 새로운 것을 빨리 만들 수 있느냐는 AI를 얼마나 잘 쓰느냐보다, 고객 데이터가 준비되어 있고, 빨리 결정하고, 실험 범위를 작게 유지하고, 증거 없는 아이디어를 멈춘 팀을 탓하지 않는 데 달려 있습니다. AI는 매 회차를 더 싸고 빠르게 만들고, 실험하는 문화는 그 속도가 일거리만 늘리는 대신 혁신으로 이어지게 합니다.
요약: 7일 안에 AI는 데이터에서 인사이트로, 인사이트에서 프로토타입으로, 프로토타입에서 테스트 자료로 가는 시간을 줄여 줍니다. 하지만 최종 답은 고객의 행동에서 나와야 합니다. 좁은 가설로 시작해 꼭 필요한 만큼만 만들고, 실제 행동(Commitment)을 요청하고, 기준에 따라 결정하십시오. 그러면 회사는 아이디어마다 예산을 걸지 않고도 새로운 아이디어를 많이 시도할 수 있습니다.
자신 있게 결정할 수 있을 만큼 빨리 수요의 증거를 만듭니다
고객을 이해하고 사업성을 판단하는 힘은 이미 회사의 팀에 있습니다. 실험을 느리게 만드는 것은 대개 웹페이지, 양식, 데이터 수집, 성과 측정을 매번 처음부터 다시 만들어야 한다는 점입니다. DNA Maker는 다시 쓸 수 있는 도구 세트를 갖춰 이 고정비를 줄이고, 연락처 입력, 계약금 결제, 상담 예약처럼 실제로 셀 수 있는 수요 신호가 무엇인지 함께 정의합니다. 페이지 방문 수만으로는 수요 신호로 치지 않습니다.
일주일 안에 실험할 수 있게 해 주는 도구
저희가 전달하는 것은 대개 빠르게 고칠 수 있는 시험용 웹페이지, 처음부터 올바르게 설정한 리드(잠재 고객) 수집과 이벤트 추적(Event Tracking), 아이디어끼리 비교하는 보고서입니다. 시간을 줄이기 위해 AI로 콘텐츠 초안을 쓰고, 화면을 디자인하고, 첫 코드를 작성하며, 공개 전에는 엔지니어가 검토합니다. 일주일 동안 얻으려는 것은 완성된 제품보다 계속할지 멈출지를 마음 편히 결정할 수 있게 해 주는 증거입니다. 아무도 선뜻 투자하지 못해 묵혀 둔 아이디어가 있다면 수요 테스트부터 시작해 볼 수 있습니다.
SOFTWARE ENGINEERING GLOSSARY
소프트웨어 엔지니어링 용어집
아이디어를 시험하고 시장의 관심을 측정하는 일과 관련된 용어입니다.
| 용어 | 의미 | 쉬운 예시 | 개발팀에 물어봐야 할 질문 |
|---|---|---|---|
| Landing Page | 제안을 시험하고 반응을 측정하도록 만든 단일 웹페이지 | 가입 버튼이 있는 새 서비스 소개 페이지 | 이 페이지에서 무엇을 측정하고, 어느 수준이면 통과로 봅니까? |
| Event Tracking | 실제 행동을 측정하기 위해 사용자가 화면에서 무엇을 했는지 기록하는 일 | 견적 요청 버튼을 누른 사람 수 세기 | 어떤 이벤트를 추적하고, 개인정보도 수집합니까? |
| Validation | 실제 사용자에게서 얻은 증거로 가설을 입증하는 일 | 고객 12명이 계약금을 냄 | 어떤 증거를 정말 믿을 만하다고 봅니까? |
| Iteration | 측정한 결과를 바탕으로 짧은 주기마다 개선하는 일 | 제안을 고쳐 다음 주에 다시 시험함 | 개선 주기는 얼마나 짧습니까? |
| Sandbox | 실제 시스템과 분리되어 사용자에게 영향을 주지 않고 시험할 수 있는 환경 | 가상 데이터로 새 기능 시험 | 샌드박스의 데이터는 실제 데이터입니까, 가상 데이터입니까? |
