“이런 서비스가 있으면 좋을 것 같은데.”

좋은 아이디어는 종종 이 한 문장에서 시작합니다.문제는 그다음입니다. 어떤 사람을 위한 서비스인지, 어떤 기능부터 만들어야 하는지, 어디까지가 첫 번째 버전인지 정하지 못한 채 AI에게 바로 제작을 요청하면 생각보다 일이 복잡해집니다.

처음에는 간단했던 아이디어에 기능이 계속 붙고, 화면은 많아지고, 수정할수록 기존 기능이 흔들립니다. 결국 많은 시간과 노력을 들이고도 누구에게 왜 필요한 서비스인지 설명하기 어려운 결과물이 남기도 합니다.

이번 4주 공개 파일럿에서는 사용자가 제출한 아이디어 중 하나의 대표 사례를 선정해, 막연한 아이디어가 실제로 구현하고 검증할 수 있는 MVP로 바뀌는 전 과정을 보여드립니다.

4주 동안 문제정의, 사용자 흐름, 기능 범위와 AI 실행 구조를 차례로 살펴봅니다. 4주 과정이 끝나면 확정된 결정을 AI 개발 도구에 전달할 수 있는 PRD Lite로 통합합니다.

마지막에는 그달의 사례에서 특히 어려웠던 판단을 다른 아이디어에도 적용할 수 있도록 사례 맞춤형 보조 챗봇과 활용 가이드를 별도 콘텐츠로 제공합니다.

완성된 정답만 보여드리는 것이 아닙니다. 어떤 질문을 던지고, 무엇을 선택하며, 무엇을 제외했는지 그 판단 과정을 함께 살펴봅니다.

영희의 아이디어는 왜 점점 커졌을까요?

작은 공방을 운영하는 영희가 있습니다. 영희는 주말마다 원데이 클래스를 엽니다. 신청은 인스타그램 메시지와 카카오톡으로 받고 있습니다. 어느 날 철수가 메시지를 보냅니다.

“이번 토요일 도자기 클래스 두 명 신청할 수 있을까요?”

영희는 가능한 시간을 알려주고, 이름과 연락처를 다시 묻습니다. 철수는 준비물이 필요한지 물어봅니다. 영희는 위치와 준비물을 다시 안내합니다. 신청자가 많아지자 문제가 생기기 시작합니다.

누가 어느 날짜에 신청했는지, 몇 명이 오는지, 준비물 안내를 확인했는지 알아보기 위해 여러 대화창을 다시 열어봐야 합니다. 수업 전날이면 같은 안내를 사람마다 반복해서 보내야 합니다. 그래서 영희는 생각합니다.

“원데이 클래스 예약 앱을 만들면 되겠다.”

좋은 생각처럼 보입니다. 그런데 예약 앱을 떠올리자 필요한 것들이 계속 생깁니다. 결제도 있어야 할 것 같고, 취소와 환불도 필요해 보입니다. 후기, 할인 쿠폰, 채팅, 출석 관리, 매출 통계까지 넣고 싶어집니다. 처음에는 작은 불편 하나를 해결하려고 했는데, 어느새 대형 예약 플랫폼을 만들고 있습니다.

이번 파일럿에서는 영희의 아이디어가 길을 잃지 않도록, 4주 동안 한 단계씩 범위를 좁혀봅니다.

1주차. 만들고 싶은 기능보다 해결할 문제를 먼저 찾습니다

영희는 처음에 ‘예약 앱’이 필요하다고 생각했습니다. 하지만 예약 앱이라는 해결책부터 정하면, 무엇이 가장 중요한 문제인지 알기 어렵습니다. 결제 기능을 먼저 만들어야 할지, 일정 선택이 필요한지, 회원가입부터 있어야 하는지 판단할 기준도 없습니다.

⚠️ 문제를 먼저 정의하지 않으면

• 필요해 보이는 기능이 계속 늘어납니다.

• 다른 예약 서비스에 있는 기능을 무작정 따라 하게 됩니다.

• 많은 기능을 만들고도 영희의 실제 업무는 편해지지 않을 수 있습니다.

• AI도 부족한 내용을 임의로 추측해 불필요한 기능을 제안합니다.

그래서 1주차에는 ‘무엇을 만들까?’보다 먼저 영희가 실제로 불편을 겪는 순간을 살펴봅니다. 영희에게 가장 힘든 것은 예약을 받는 일 자체가 아니었습니다. 현재 자료에서 가장 강하게 보이는 문제 후보는 다음과 같았습니다.

"신청 정보가 여러 대화창에 흩어져 있고, 같은 안내를 신청자마다 반복해서 전달해야 한다."

다만 아직은 영희의 경험을 바탕으로 세운 가설입니다. 실제로 같은 문제가 반복되는지, 다른 공방 운영자도 비슷한 불편을 겪는지는 추가로 확인해야 합니다. 그러자 아이디어가 달라집니다.

💡 처음 아이디어

원데이 클래스 예약 앱

👍 문제를 다시 살펴본 뒤

소규모 클래스 운영자가 신청자 정보와 준비물 안내 상태를 한곳에서 확인할 수 있는 서비스

⭐️ 문제를 먼저 정의하면 좋은 점

• 무엇을 만들어야 하는지가 선명해집니다.

• 결제, 후기, 쿠폰처럼 지금 해결하려는 문제와 직접 관련이 없는 기능을 굳이 만들지 않아도 됩니다.

• AI에게도 “예약 앱을 만들어줘”라고 말하는 대신, 누구의 어떤 문제를 해결해야 하는지 정확히 전달할 수 있습니다.

📌 1주차에 정리하는 내용

• 핵심 사용자

• 문제가 발생하는 구체적인 상황

• 사용자가 현재 문제를 해결하는 방식

• 현재 방식의 불편

• 해결해야 할 핵심 문제

• 문제 중심으로 다시 정의한 아이디어

2주차. 사용자가 서비스를 이용하는 순간을 이야기로 그립니다

문제를 찾았다고 바로 화면부터 만들면 또 다른 문제가 생깁니다. 신청자에게 처음부터 너무 많은 정보를 요구하거나, 회원가입부터 시킬 수 있습니다. 운영자와 신청자 중 누구를 중심으로 설계해야 할지도 흔들릴 수 있습니다.

기능은 있는데 사용자가 어디서 시작해야 하는지 모르는 서비스가 되기도 합니다.

⚠️ 사용 흐름을 먼저 그리지 않으면

• 화면을 만든 뒤에야 빠진 단계가 발견됩니다.

• 같은 정보를 여러 번 입력하게 될 수 있습니다.

• 사용자가 원하는 결과를 얻기까지 과정이 길어집니다.

• 운영자에게 필요한 기능과 신청자에게 필요한 기능이 뒤섞입니다.

✍🏻 그래서 2주차에는 영희와 철수가 서비스를 사용하는 장면을 짧은 이야기로 그려봅니다.

1. 철수는 영희가 보내준 신청 링크를 엽니다.

2. 원하는 클래스 날짜를 확인한 뒤 이름, 연락처, 참여 인원을 입력합니다.

3. 신청을 완료하자 공방 위치와 준비물이 나타납니다.

4. 영희의 화면에는 새로운 신청자가 추가됩니다. 영희는 날짜별 신청자 목록과 철수가 안내 내용을 확인했는지 바로 볼 수 있습니다.

여기서 중요한 것은 화려한 예약 화면이 아닙니다.

✅ 영희가 느껴야 하는 핵심 가치는 다음과 같습니다.

“누가 신청했고, 누가 준비물 안내를 확인했는지 한눈에 보인다.”

✅ 철수가 느껴야 하는 핵심 가치는 다음과 같습니다.

“운영자에게 여러 번 질문하지 않아도 필요한 내용을 바로 확인할 수 있다.”

⭐️ 사용 흐름을 먼저 그리면 좋은 점

• 사용자가 어떤 순서로 행동해야 하는지 보이기 시작합니다.

• 화면의 개수보다 사용자가 가장 빠르게 가치를 느끼는 순간에 집중할 수 있습니다.

• 필요 없는 입력과 중간 단계를 만들기 전에 제거할 수도 있습니다.

📌 2주차에 정리하는 내용

• 사용자가 서비스를 찾는 상황

• 신청자가 거치는 행동 흐름

• 운영자가 거치는 행동 흐름

• 각 사용자가 가장 먼저 얻어야 할 결과

• 사용자가 가치를 느끼는 핵심 순간

• 줄이거나 제거해야 할 단계

3주차. 하고 싶은 기능과 지금 필요한 기능을 구분합니다

사용 흐름이 보이기 시작하면 다시 기능 욕심이 생깁니다. 영희는 결제, 자동 환불, 리뷰, 쿠폰, 채팅, 출석 관리, 재고 관리, 매출 통계까지 모두 있으면 좋겠다고 생각합니다. 물론 있으면 편리한 기능입니다. 하지만 이 기능을 모두 넣으면 더 이상 작은 MVP가 아닙니다.

⚠️ 기능을 좁히지 않으면

• 구현해야 할 화면과 데이터가 빠르게 늘어납니다.

• 한 기능을 수정할 때 다른 기능이 깨질 가능성이 커집니다.

• 완성까지 걸리는 시간이 길어집니다.

• 핵심 기능을 검증하기 전에 지칠 수 있습니다.

• 사용자가 정말 이 서비스를 필요로 하는지 확인하지 못한 채 큰 서비스를 만들게 됩니다.

그래서 3주차에서는 모든 기능을 세 가지로 나눕니다.

✅ 지금 반드시 필요한 기능

• 클래스 일정 확인

• 신청 정보 입력

• 신청 완료 안내

• 위치와 준비물 확인

• 운영자의 신청자 목록 확인

• 안내 확인 상태 표시

⭕️ 나중에 추가할 수 있는 기능

• 신청 취소

• 자동 알림

• 참석 완료 처리

• 기존 클래스 복제

❌ 첫 번째 MVP에서 제외할 기능

• 온라인 결제

• 자동 환불

• 후기

• 쿠폰

• 채팅

• 회원권

• 매출 분석

판단 기준은 간단합니다. 이 기능이 없어도 신청 정보와 안내 상태를 한곳에서 관리할 수 있는가? 답이 ‘그렇다’면 첫 번째 버전에서는 제외할 수 있습니다.

⭐️ 범위를 좁히면 좋은 점

첫 번째 버전을 실제로 완성할 가능성이 높아집니다.

🙋‍♀️ 확인해야 할 질문도 명확해집니다.

• 영희가 신청자 정보를 찾는 시간이 줄어드는가?

• 같은 안내를 반복해서 보내는 일이 줄어드는가?

• 철수가 준비물을 놓치는 일이 줄어드는가?

기능이 얼마나 많은지가 아니라, 처음 정의한 문제가 실제로 해결되는지를 확인할 수 있습니다.

📌 3주차에 정리하는 내용

• 반드시 필요한 기능

• 나중에 추가할 기능

• 첫 번째 버전에서 제외할 기능

• 최소 사용자 흐름

• 필요한 화면과 정보 구조

• 구현 우선순위

• MVP를 통해 확인할 핵심 가설

4주차. 사람이 결정한 방향을 AI와 함께 실행할 수 있는 구조로 바꿉니다

문제와 사용자 흐름, 기능 범위를 정했더라도 AI 개발 도구에 이렇게만 요청하면 결과가 흔들릴 수 있습니다. “원데이 클래스 예약 앱을 만들어줘.” AI는 어떤 사용자를 위한 서비스인지 알 수 없습니다. 결제를 포함해야 하는지, 운영자 화면과 신청자 화면이 모두 필요한지, 어떤 정보를 저장해야 하는지도 알 수 없습니다. 비어 있는 부분은 AI가 임의로 채웁니다.

⚠️ 방향을 정리하지 않고 AI에게 요청하면

• 요청하지 않은 기능이 추가될 수 있습니다.

• 중요한 사용자 흐름이 빠질 수 있습니다.

• 수정할 때마다 화면 구조가 달라질 수 있습니다.

• 보기에는 그럴듯하지만 실제 문제와 맞지 않는 결과가 나올 수 있습니다.

• AI가 만든 결과를 평가할 기준이 없어집니다.

그래서 4주차에는 앞에서 사람이 결정한 내용을 AI가 이해할 수 있는 구조로 바꿉니다.

✅ 이렇게 바꿉니다

• AI에게 바로 “앱을 만들어줘”라고 말하지 않습니다.

• 먼저 다음 내용을 정리합니다.

• 누구를 위한 서비스인지

• 어떤 문제를 해결하는지

• 사용자가 어떤 순서로 이용하는지

• 첫 번째 버전에 포함할 기능은 무엇인지

• 이번에는 제외할 기능은 무엇인지

• 어떤 화면이 필요한지

• 결과물을 어떤 기준으로 확인할지

• 그리고 이달의 대표 사례에 맞춰 필요한 보조 챗봇의 역할도 함께 설계합니다.

🤖 보조 챗봇은 매달 고정된 하나의 챗봇이 아닙니다.

• 이번 사례에서 반복적으로 어려웠던 판단 하나를 골라, 별도의 보조 챗봇 후보를 정합니다.

• 보조 챗봇은 매달 같은 도구로 고정되지 않습니다. 사례가 달라지면 어려운 판단도 달라지기 때문입니다.

• 4주차에서는 어떤 판단을 돕는 챗봇이 필요한지만 짧게 소개합니다. 완성된 챗봇 링크와 판단 기준, 사용 방법과 예시는 월말 PRD 이후 별도 콘텐츠에서 제공합니다.

👍 이렇게 하면 좋은 점

• AI가 불필요한 기능을 임의로 추가하는 일을 줄일 수 있습니다.

• 무엇을 먼저 만들고, 어떤 기준으로 결과를 확인해야 하는지도 분명해집니다.

• AI가 만든 결과가 목적과 다를 때도 “마음에 들지 않는다”가 아니라, 문제정의와 사용자 흐름을 기준으로 구체적으로 수정할 수 있습니다.

• 또한 보조 챗봇을 고정된 도구로 받아들이는 것이 아니라, 아이디어마다 필요한 질문과 판단 기준을 설계하는 방법을 익힐 수 있습니다.

• AI는 이 서비스의 핵심 기능이 아닙니다.

• 영희와 철수가 사용하는 서비스의 핵심은 신청 정보와 안내 상태를 한곳에서 관리하는 것입니다.

• AI는 사람이 정한 문제와 방향을 실제 화면과 기능으로 빠르게 옮기거나, 생각을 정리하는 과정에서 질문을 도와주는 도구로 활용합니다.

📌 4주차에 제공되는 내용

• AI가 이해할 수 있는 서비스 설명

• 핵심 사용자와 해결할 문제

• 사용자의 핵심 행동 흐름

• 포함할 기능과 제외할 기능

• 화면별 한 가지 핵심 목적

• 주요 행동과 보조 행동

• 필요한 화면 상태와 시스템 반응

• 구현 순서와 완료 기준을 정하는 방법

• AI가 임의로 추가하면 안 되는 범위

• 이번 사례에 필요한 보조 챗봇의 짧은 예고

4주차에서는 요구사항을 어떤 구조로 전달해야 하는지 살펴봅니다. 구체적인 화면·데이터·동작 규칙은 다음 최종 브리프에서 하나의 PRD Lite로 통합합니다.

월말 최종. 흩어진 판단을 AI 개발 도구용 PRD Lite로 완성합니다

4주가 끝나면 영희의 처음 아이디어는 다음과 같이 달라집니다.

⚠️ 처음 아이디어

“원데이 클래스 예약 앱을 만들고 싶다.”

🗓️ 4주 후

인스타그램과 카카오톡으로 신청을 받는 소규모 클래스 운영자가 신청자 정보와 준비물 안내 여부를 한곳에서 관리할 수 있는 서비스

📌 최종 PRD Lite에는 다음 내용이 하나의 실행 문서로 정리됩니다.

• 누구의 어떤 문제를 해결하는지

• 어떤 상황에서 문제가 발생하는지

• 현재 해결 방식이 왜 불편한지

• 신청자와 운영자의 핵심 행동 흐름

• 사용자가 가치를 느끼는 순간

• 첫 번째 버전에 포함할 기능

• 이번에는 제외할 기능

• 필요한 화면과 화면별 한 가지 목적

• 주요 행동과 보조 행동

• 기본·빈 화면·오류·완료 등 필요한 화면 상태

• 저장할 정보와 핵심 동작 규칙

• 단계별 구현 순서

• 완료·검수 기준

• MVP를 통해 확인할 행동 가설

• 제외·변경 금지 범위

• AI 개발 도구가 먼저 검토할 실행 요구사항

막연했던 생각이 실제로 구현하고 검증할 수 있는 서비스 구조로 바뀝니다.

별도 콘텐츠. 이번 달의 판단을 내 아이디어에도 적용합니다

최종 PRD Lite까지 완성한 뒤에는 이번 사례에서 반복적으로 어려웠던 판단 하나를 다른 아이디어에도 적용할 수 있는 보조 챗봇을 소개합니다. 보조 챗봇은 매달 같은 기능을 제공하는 고정된 제작봇이 아닙니다. 그달의 사례에서 문제를 좁히거나 사용자 흐름을 나누고, 기능을 넣고 뺄 때 특히 어려웠던 판단에 맞춰 달라집니다.

📌 보조 챗봇 별도 콘텐츠에서는 다음 내용을 제공합니다.

• 완성된 챗봇 실행 링크

• 어떤 상황에서 사용하는지

• 사용 전에 준비할 정보

• 챗봇이 확인하는 판단 기준

• 결과를 해석하는 방법

• 실제 사례를 적용한 사용 예시

• 자신의 아이디어에 이어서 적용하는 방법

챗봇은 정답을 대신 결정하는 도구가 아닙니다. 사용자가 자신의 문제와 흐름을 기준으로 더 분명한 판단을 내리도록 돕는 사고 보조 도구입니다.

도구는 바뀌어도, 방향을 정하는 과정은 남습니다

AI 도구는 빠르게 변합니다. 지금 사용하는 도구보다 더 쉽고 더 강력한 AI가 등장할 수도 있습니다. 오늘 배운 버튼의 위치나 명령어는 몇 달 뒤 달라질 수 있습니다.

⭐️ 하지만 다음 질문은 어떤 도구를 사용하더라도 계속 필요합니다.

• 누구의 어떤 문제를 해결할 것인가?

• 사용자는 어떤 상황에서 이 서비스를 필요로 하는가?

• 사용자가 가장 먼저 얻어야 할 가치는 무엇인가?

• 첫 번째 버전에는 무엇을 넣고 무엇을 제외할 것인가?

• AI가 만든 결과가 목적에 맞는지 어떤 기준으로 판단할 것인가?

AI는 앞으로 더 많은 분석과 선택지를 제안할 수 있을 것입니다. 하지만 여러 선택지 중 어떤 문제를 먼저 해결할지 정하고, 어디까지 만들지 선택하며, 결과에 책임지는 역할은 사람에게 남습니다.

AI가 발전할수록 사람의 역할은 모든 것을 직접 만드는 사람에서, 문제의 방향을 설정하고 중요한 선택을 내리며 결과의 품질을 판단하는 사람으로 달라집니다.

이번 파일럿에서 익히는 것은 특정 도구의 사용법만이 아닙니다.

도구가 바뀌더라도 자신의 아이디어를 문제정의, 사용자 흐름, MVP 범위, 실행 구조로 좁혀갈 수 있는 사고방식입니다.

이번 파일럿에서는 무엇을 얻게 되나요?

이번 공개 파일럿에서는 하나의 대표 사례가 4주 동안 문제와 흐름, 기능 범위와 실행 구조로 좁혀집니다. 이후 확정된 결정은 AI 개발 도구에 전달할 PRD Lite로 통합되고, 마지막에는 같은 판단을 자신의 아이디어에도 적용할 수 있는 보조 챗봇 콘텐츠가 제공됩니다. 정규 멤버십에서는 매월 새로운 회원 아이디어 하나를 선정해 같은 과정을 반복합니다.

📌 사용자는 사례의 결과만 보는 것이 아니라 다음 판단 과정을 함께 살펴봅니다.

• 기능 뒤에 숨은 사용자 문제를 찾는 방법

• 사용자가 가치를 느끼는 핵심 경험을 정의하는 방법

• 필요한 기능과 욕심에서 나온 기능을 구분하는 방법

• 작은 범위로 실제 완성 가능한 MVP를 설계하는 방법

• 정리한 기획을 AI가 실행할 수 있는 PRD로 전달하는 방법

• 화면 상태와 시스템 반응까지 포함해 결과를 검수하는 방법

• 사례에서 배운 판단 기준을 자신의 아이디어에 적용하는 방법

• AI의 결과를 문제와 사용자 흐름에 따라 검토하는 방법

사례가 쌓일수록 자신의 아이디어를 바라보는 기준도 함께 쌓입니다.

💖 좋은 MVP는 기능을 많이 넣는 데서 시작하지 않습니다.

무엇을 더 만들지 고민하기 전에, 누구의 어떤 문제를 가장 먼저 해결할지 결정하는 것에서 시작합니다. 이번 4주 공개 파일럿에서는 하나의 대표 사례를 선정해 문제정의부터 최종 MVP 브리프까지 발전하는 과정을 보여드립니다.

정규 멤버십이 시작되면 같은 방식으로 매월 새로운 회원 아이디어 하나를 선정해 분석합니다. 4주 과정이 끝나면 AI 개발 도구에 전달할 PRD Lite와, 해당 사례에서 어려웠던 판단을 다른 아이디어에도 적용하도록 돕는 사례 맞춤형 보조 챗봇 및 활용 가이드를 제공합니다.

이제 여러분의 아이디어를 들려주세요. 😊