1. 가장 먼저 줄여야 할 것은 「구현의 불확실성」이 아니다

AI 코딩 에이전트 (AI Coding Agent)를 사용하면 개인도 단기간에 프로덕트를 형태를 갖출 수 있습니다.

하지만 빠르게 만드는 것과 누군가가 원하는 것은 별개의 문제입니다.

오히려 구현이 빨라졌기 때문에, 수요가 없는 것까지 완성하기 쉬워졌습니다.

AI 시대의 개인 개발에서는 구현력보다 먼저 「무엇을 확인해야 하는가」를 설계해야 합니다.

개인 개발에는 적어도 다음의 세 가지 불확실성이 있습니다.

• 과제: 상정한 고민이 정말로 존재하는가
• 수요: 그 해결책에 시간이나 돈을 지불할 사람이 있는가
• 구현: 자신이 그 해결책을 만들 수 있는가

AI가 크게 줄여준 것은 주로 구현의 불확실성입니다.

과제와 수요의 유무는 AI에게 질문해도 확정할 수 없습니다.

따라서 다음 순서로 확인합니다.

중요한 점은 수요를 확인하지 못하면 구현으로 나아가지 않는다는 점입니다.

코드를 작성하지 않기로 하는 판단도 개인 개발에서는 중요한 성과가 됩니다.

전체 10단계는 전제 기사에 정리해 두었습니다.

본 기사는 구현 전의 검증을 중심으로, 그 이후의 MVP(Minimum Viable Product) 결정 방식과 철수 판단까지 다룹니다.

2. 과제를 찾는다

가장 먼저 찾는 것은 프로덕트의 아이디어가 아니라, 반복적으로 발생하고 있는 과제입니다.

예를 들어 「AI로 회의록을 만든다」부터 생각하기 시작하면 해결책이 먼저 결정되어 버립니다.

「회의 후 공유에 매번 30분이 걸린다」부터 시작하면, 회의록 이외의 해결책도 검토할 수 있습니다.

과제의 후보는 다음 장소에서 수집합니다.

• 자신이 일상적으로 번거롭다고 느끼는 작업
• 업무나 취미 커뮤니티에서 반복적으로 나오는 상담
• 기존 서비스의 리뷰에 적힌 불만
• 스프레드시트나 수작업으로 억지로 운용되고 있는 업무

AI는 게시물이나 메모의 분류, 유사한 불만의 집약, 질문안 작성에 사용할 수 있습니다.

단, 게시물 수의 많음만으로 과제의 강도를 판단해서는 안 됩니다.

후보를 찾았다면 실제로 곤란을 겪고 있는 사람에게 이야기를 듣습니다.

「이 기능이 있으면 사용하시겠습니까?」가 아니라, 현재의 행동을 질문합니다.

• 마지막으로 그 문제가 발생한 것은 언제인가
• 지금은 어떻게 대처하고 있는가
• 대처에 어느 정도의 시간이나 비용을 쓰고 있는가
• 해결하지 못하면 어떤 손실이 있는가

미래의 의지보다 이미 취하고 있는 행동이 더 강력한 증거가 됩니다.

이 사고방식은 서적 『The Mom Test』에서 이야기하는 질문법과 같은 방향입니다.

3. 수요를 확인한다

과제가 존재하더라도 자신의 해결책이 선택된다는 보장은 없습니다.

구현 전에 가능한 한 비용이 적게 드는 방법으로 반응을 측정합니다.

검증 방법은 얻을 수 있는 증거의 강도가 다릅니다.

| 검증 방법 | 확인할 수 있는 것 | 주의점 |
|---|---| |
| 사용자 인터뷰 (User Interview) | 과제의 빈도와 깊이 | 호의적인 발언을 수요로 오인하기 쉬움 |
| ... |
광고를 사용하는 경우에도 CTR(클릭률)이나 CPC(클릭당 비용)만으로 합격 여부를 결정하지 않습니다.

가격대, 대상자, 매체, 소구 내용에 따라 수치는 크게 달라지기 때문입니다.

먼저 결정해야 할 것은 보편적인 기준치가 아니라, 자신의 철수 조건입니다.

예를 들어 다음과 같이 정해 둡니다.

• 20명에게 말을 걸어도 이야기를 들을 수 있는 사람이 3명 미만이라면 대상자를 재검토한다
• 10건의 인터뷰에서 동일한 과제가 반복해서 나오지 않는다면 다른 과제를 찾는다
• LP(Landing Page)로의 유입은 있는데 등록되지 않는다면 소구 방식이나 대상자를 바꾼다

수치는 상품이나 고객 유입 경로에 맞춰 결정합니다.

중요한 것은 결과를 보고 나서 자신에게 유리하게 기준을 바꾸지 않는 것입니다.

4. 검증한 가치만을 MVP로 만든다

수요의 반응을 얻었다면 비로소 MVP(Minimum Viable Product)의 사양을 결정합니다.

여기서 말하는 MVP는 기능이 적은 완성품이 아닙니다.

검증하고 싶은 가설을 사용자가 체험할 수 있는 최소 단위입니다.

사양서에는 화면이나 API뿐만 아니라 다음 내용도 남깁니다.

• 누구의 어떤 과제를 해결하는가
• 사용자가 가치를 느끼는 최단 경로
• 이번에는 만들지 않는 기능
• 성공이라고 판단하는 행동
• 중지 또는 재검토 조건

AI 코딩 에이전트에게는 이 사양서를 구현의 입력값으로 전달합니다.

모호한 요구사항을 대화로 채워가며 만드는 것보다 재작업(rework)을 줄이기 쉽습니다.

단, AI가 제안한 추가 기능을 안이하게 채택하면 MVP는 금방 비대해집니다.

「그 기능이 없어도 가설을 검증할 수 있는가」를 추가 판단 기준으로 삼습니다.

5. 만드는 것과 전달하는 것을 병행한다

마케팅은 완성 후에 시작하는 공정이 아닙니다.

인터뷰, LP(Landing Page), 사전 등록 단계에서 이미 전달하는 활동은 시작되고 있습니다.

MVP (Minimum Viable Product) 개발 중에도 반응을 보여준 사람들에게 진행 상황을 공유합니다.

완성되면 불특정 다수에게 공지하기 전에, 그 사람들에게 먼저 사용해 보도록 합니다.

초기 사용자에게는 조작 방법뿐만 아니라 다음 사항들을 확인합니다.

• 사용하기 전에 무엇을 기대했는가
• 어디에서 가치를 느꼈는가
• 어디에서 멈췄는가
• 사용하지 않아도 불편함이 없는 기능은 무엇인가
• 지속적인 이용이나 결제를 망설이는 이유는 무엇인가

AI는 행동 로그나 인터뷰 기록의 요약에 유용합니다.

다만, 요약본만 보면 소수 의견이나 문맥을 놓칠 수 있습니다.

중요한 판단을 내릴 때는 반드시 원본 기록까지 확인합니다.

6. 개선을 계속할지 철수할지를 판단한다

릴리스(Release)는 골(Goal)이 아니라, 가설을 업데이트하는 타이밍입니다.

봐야 할 지표는 프로덕트에 따라 다르지만, 처음에는 다음 세 가지로 압축합니다.

모두 AARRR 모델에서 사용되는 지표입니다.

• Activation (활성화): 첫 이용 시 가치에 도달한 비율
• Retention (유지): 일정 기간 후에도 이용을 지속한 비율
• Revenue (수익): 결제 또는 결제로 이어지는 행동

이용자 수만 늘어날 뿐, 가치에 도달하지 못하고 지속되지 않는다면 광고를 늘릴 단계가 아닙니다.

먼저 누가 어떤 상황에서 가치를 느꼈는지를 확인합니다.

개선을 계속할 조건과 철수할 조건도 사전에 결정해 둡니다.

개인 개발에서는 시간 또한 중요한 투자입니다.

반응이 없는 프로덕트를 계속 유지하기보다, 배움을 다음 가설로 옮기는 것이 더 나은 경우도 있습니다.

7. AI에게 맡길 것과 스스로 담당할 것

AI가 잘하는 것은 후보를 늘리고, 정리하고, 구현을 빠르게 하는 것입니다.

반면, 현실의 반응을 수집하고 어떤 증거를 믿을지 결정하는 것은 개발자의 역할입니다.

AI를 사용하더라도 수요 검증 그 자체를 자동화할 수는 없습니다.

이 비대칭성을 이해해 두면, 구현만 앞서 나가는 상태를 피하기 쉬워집니다.

8. 30일 동안 시도한다면

첫 한 달은 완성품을 만드는 기간이 아니라, 가설을 좁히는 기간으로 삼습니다.

8.1 1주 차: 과제를 수집한다

• 자신이나 주변 사람의 고민거리를 20건 적어본다
• 빈도, 심각도, 현재의 대체 수단으로 압축한다
• 상위 3건에 대해 대상자를 찾는다

8.2 2주 차: 이야기를 듣는다

• 5~10명에게 인터뷰를 한다
• 발언이 아니라 과거의 행동을 기록한다
• 반복해서 나타나는 과제를 하나 선택한다

8.3 3주 차: 해결책에 대한 반응을 측정한다

• LP 또는 수동 서비스(Manual Service)를 준비한다
• 대상자에게 직접 전달한다
• 등록, 예약, 결제 의사 등을 관측한다

8.4 4주 차: 만들지 말지를 결정한다

• 사전에 결정한 기준과 결과를 비교한다
• 반응이 있다면 MVP의 사양을 작성한다
• 반응이 약하다면 대상자나 과제를 재검토한다

30일 후에 코드가 없더라도, 만들지 않는 이유를 설명할 수 있다면 전진한 것입니다.

9. 마치며

AI 시대의 개인 개발에서 부족해지기 쉬운 것은 구현 속도가 아니라, 현실에서 증거를 수집하는 공정입니다.

먼저 과제를 확인하고, 다음으로 수요를 측정하며, 그 후에 최소한의 구현으로 나아갑니다.

이 순서를 따른다면 수요가 없는 프로덕트를 빠르게 완성해 버리는 리스크를 줄일 수 있습니다.

필자도 이 로드맵에 따라 하나의 프로덕트를 기획합니다.

속편에서는 인터뷰 수나 반응률뿐만 아니라, 철수 조건을 어떻게 결정했는지, 실제로 무엇을 버렸는지도 기록하겠습니다.

전체 맵으로 돌아가고 싶다면 전제 기사를 참조해 주세요.

Discussion