[기획/PM] 개발전에 먼저 검증하는 프롬프트 프로토타이핑

AI튜터랩
개발 전에 먼저 검증하는 PM의 비밀, ‘프롬프트 프로토타이핑’
[이미지 삽입: 왼쪽에는 개발 요청서와 와이어프레임을 쌓아두고 고민하는 PM, 오른쪽에는 AI 채팅창에서 기능을 빠르게 테스트하는 PM의 대비 이미지]
“이 기능, 개발하면 정말 사용자가 좋아할까요?”
기획자와 PM이라면 새로운 기능을 설계할 때마다 이런 고민을 하게 됩니다.
아이디어는 좋아 보이지만 실제로 개발하려면 디자이너, 개발자, 데이터 담당자와 협의해야 하고, 짧게는 몇 주에서 길게는 몇 달이 걸립니다.
문제는 그렇게 어렵게 만든 기능이 사용자의 기대와 다를 수도 있다는 점입니다.
회의에서는 모두가 괜찮다고 했지만, 막상 출시해 보면 사용자는 기능을 이해하지 못하거나 전혀 다른 방식으로 사용하는 경우도 많습니다.
우리가 진짜 해결해야 하는 문제는 ‘개발 속도’가 아닙니다.
개발하기 전에 아이디어의 가치와 사용성을 얼마나 빠르게 검증할 수 있느냐가 핵심입니다.
❌ 화면만 그리는 프로토타입으로는 부족합니다
많은 기획자가 새로운 AI 기능을 기획할 때 가장 먼저 와이어프레임이나 화면 설계서를 만듭니다.
예를 들어 사용자가 입력창에 질문을 작성하고, 버튼을 누르면 AI가 답변을 생성하는 화면을 설계합니다.
화면의 구조는 확인할 수 있지만, 정작 가장 중요한 것은 확인하기 어렵습니다.
AI가 어떤 답변을 내놓는지, 사용자가 그 답변을 유용하다고 느끼는지는 화면만으로 알 수 없기 때문입니다.
기존 방식에는 세 가지 문제가 있습니다.
❌ 결과물의 품질을 확인하기 어렵습니다.
화면은 그럴듯하지만, 실제 AI 답변이 사용자의 기대에 맞는지는 알 수 없습니다.
❌ 개발 이후에야 문제를 발견합니다.
프롬프트와 답변 구조가 잘못되어도 기능이 구현된 이후에 수정하게 됩니다.
❌ 기획 논의가 추상적으로 흘러갑니다.
“조금 더 똑똑하게 답변해야 합니다”처럼 사람마다 다르게 해석할 수 있는 표현만 남습니다.
방향성과 평가 기준 없이 AI 기능을 개발하면, 개발이 끝난 뒤에도 계속 프롬프트를 수정하게 됩니다.
[이미지 삽입: ‘화면 중심 프로토타입’과 ‘실제 AI 응답 중심 프로토타입’을 비교한 도식]
💡 해결책은 ‘프롬프트 프로토타이핑’입니다
프롬프트 프로토타이핑은 개발 전에 프롬프트와 실제 사용자 입력을 활용해 AI 기능의 핵심 경험을 먼저 만들어보는 방법입니다.
쉽게 말하면 화면을 만들기 전에, AI가 어떤 역할을 수행하고 어떤 결과를 제공해야 하는지 대화형으로 먼저 실험하는 것입니다.
예를 들어 ‘회의록 요약 기능’을 기획한다고 가정해 보겠습니다.
기존 방식이라면 먼저 업로드 화면, 요약 버튼, 결과 화면을 설계합니다.
프롬프트 프로토타이핑에서는 실제 회의록을 AI에 입력하고 다음과 같은 항목을 먼저 검증합니다.
어떤 형식으로 요약해야 읽기 쉬운가?
결정 사항과 할 일을 구분해야 하는가?
담당자와 마감일을 자동으로 추출할 수 있는가?
정보가 부족할 때 AI는 어떻게 안내해야 하는가?
사용자가 결과를 수정하거나 다시 요청할 수 있는가?
이 과정을 통해 개발 전에 기능의 핵심 가치와 예상되는 실패 상황을 확인할 수 있습니다.
프롬프트는 단순한 명령어가 아닙니다.
AI 서비스에서는 프롬프트 자체가 정책이자 기능 명세서이며, 사용자가 경험하게 될 서비스의 핵심 로직입니다.
기획자와 PM을 위한 프롬프트 프로토타이핑 4단계
STEP 1. 기능이 아니라 ‘사용자의 작업’을 정의하세요
가장 먼저 해야 할 일은 AI가 제공할 기능을 나열하는 것이 아닙니다.
사용자가 어떤 상황에서 무엇을 해결하려고 하는지 한 문장으로 정의해야 합니다.
예를 들어 다음과 같이 정의할 수 있습니다.
사용자는 한 시간 분량의 회의록을 다시 읽지 않고도 결정 사항과 본인의 할 일을 빠르게 확인하고 싶다.
이 문장에는 사용자, 상황, 해결해야 할 작업이 모두 포함되어 있습니다.
반면 아래와 같은 정의는 너무 추상적입니다.
AI가 회의록을 자동으로 요약한다.
두 문장은 비슷해 보이지만 기획 방향은 완전히 다릅니다.
첫 번째 문장은 사용자가 원하는 결과를 설명하고, 두 번째 문장은 시스템이 제공할 기능만 설명합니다.
💡 프롬프트를 작성하기 전에 다음 문장을 먼저 완성해 보세요.
사용자는
[상황]에서[불편함]을 줄이고,[원하는 결과]를 얻고 싶다.
STEP 2. 좋은 결과물의 기준을 먼저 만드세요
AI에게 “잘 요약해 줘”라고 요청하면 결과를 평가하기 어렵습니다.
무엇이 좋은 요약인지 기준이 없기 때문입니다.
기획자는 프롬프트를 만들기 전에 결과물의 합격 기준을 정의해야 합니다.
회의록 요약 기능이라면 다음과 같은 기준을 만들 수 있습니다.
✅ 핵심 논의 내용을 5줄 이내로 정리한다.
✅ 최종 결정 사항을 별도로 구분한다.
✅ 담당자가 언급된 할 일을 추출한다.
✅ 마감일이 없는 경우 임의로 추측하지 않는다.
✅ 정보가 부족하면 확인이 필요하다고 안내한다.
이 기준은 이후 개발자와 협업할 때도 중요한 기능 명세가 됩니다.
또한 결과 품질을 평가하는 테스트 기준으로도 활용할 수 있습니다.
좋은 프롬프트는 문장이 긴 프롬프트가 아닙니다.
좋은 결과와 나쁜 결과를 구분할 수 있는 기준이 포함된 프롬프트입니다.
[이미지 삽입: ‘좋은 답변의 체크리스트’를 카드 형태로 정리한 이미지]
STEP 3. 실제 사용자 입력으로 반복 테스트하세요
프롬프트를 한 번 작성하고 끝내면 안 됩니다.
실제 사용자 입력은 기획자가 예상한 것보다 훨씬 다양하기 때문입니다.
다음과 같은 테스트 데이터를 준비해 보세요.
정보가 잘 정리된 정상적인 입력
문장이 길고 중복이 많은 입력
중요한 정보가 빠진 입력
오타와 축약어가 포함된 입력
서로 충돌하는 내용이 포함된 입력
서비스와 전혀 관계없는 입력
예를 들어 회의록 요약 기능이라면 다음과 같은 상황을 테스트할 수 있습니다.
“담당자는 언급되었지만 마감일이 없는 경우”
“여러 사람이 서로 다른 일정을 이야기한 경우”
“결정된 내용과 단순 의견이 섞여 있는 경우”
“회의 내용이 아닌 개인 메모가 포함된 경우”
이 과정을 거치면 단순히 잘 작동하는 사례뿐 아니라 AI가 실패할 수 있는 경계 조건을 발견할 수 있습니다.
💡 기획 단계에서는 성공 사례보다 실패 사례를 많이 찾는 것이 중요합니다.
성공 사례는 데모를 멋지게 만들지만, 실패 사례는 실제 서비스를 안정적으로 만듭니다.
STEP 4. 프롬프트를 기능 명세서로 정리하세요
프로토타이핑이 끝났다면 결과를 단순한 채팅 기록으로 남겨서는 안 됩니다.
개발팀이 구현하고 운영팀이 관리할 수 있는 형태로 정리해야 합니다.
다음 항목을 포함한 프롬프트 명세서를 만들어 보세요.
1. AI의 역할
AI가 어떤 전문가 또는 도우미처럼 행동해야 하는지 정의합니다.
예시:
너는 업무 회의 내용을 구조화하는 프로젝트 매니저다.
2. 입력 정보
사용자가 제공하는 정보와 시스템에서 함께 전달하는 정보를 구분합니다.
예시:
사용자 입력: 회의록 원문
시스템 정보: 사용자 이름, 프로젝트명, 작성 날짜
3. 처리 규칙
AI가 반드시 따라야 하는 규칙을 정의합니다.
예시:
회의에서 직접 언급되지 않은 내용은 추측하지 않는다.
결정 사항과 의견을 구분한다.
담당자가 불명확하면 ‘담당자 확인 필요’라고 표시한다.
4. 출력 형식
결과가 어떤 구조로 제공되어야 하는지 정의합니다.
예시:
회의 요약
결정 사항
할 일
담당자
마감일
추가 확인 사항
5. 예외 처리
정보 부족, 부적절한 입력, 잘못된 요청에 어떻게 대응할지 정의합니다.
이렇게 정리하면 프롬프트는 단순한 문장이 아니라 개발 가능한 수준의 기획 문서가 됩니다.
[이미지 삽입: 역할, 입력, 규칙, 출력, 예외 처리로 구성된 프롬프트 명세서 구조도]
프롬프트 프로토타이핑 예시
아래는 기획자가 회의록 요약 기능을 검증할 때 사용할 수 있는 간단한 예시입니다.
너는 업무 회의 내용을 정리하는 프로젝트 매니저다.
사용자가 제공한 회의록을 읽고 다음 내용을 구분해 정리하라.
핵심 논의 내용
최종 결정 사항
실행해야 할 업무
업무 담당자
마감일
추가 확인이 필요한 내용
회의에서 직접 언급되지 않은 내용은 추측하지 않는다.
담당자나 마감일이 명확하지 않으면 ‘확인 필요’라고 표시한다.
결과는 빠르게 읽을 수 있도록 표와 짧은 문장으로 작성한다.
이 프롬프트에 여러 종류의 회의록을 입력해 보면, 개발 전에 다음 내용을 확인할 수 있습니다.
결과 구조가 실제 업무에 도움이 되는가?
사용자가 추가로 원하는 정보는 무엇인가?
AI가 자주 실수하는 부분은 무엇인가?
별도의 수정 기능이 필요한가?
사람이 반드시 검토해야 하는 영역은 무엇인가?
☑ 프롬프트 프로토타이핑을 적용하면 이렇게 달라집니다
🕒 개발 전 검증 속도가 빨라집니다.
화면과 서버를 구현하기 전에 핵심 기능을 직접 테스트할 수 있습니다.
🎯 기능 요구사항이 구체적으로 바뀝니다.
“잘 요약해 주세요”가 아니라 출력 구조, 금지 조건, 예외 처리 기준을 명확하게 정의할 수 있습니다.
🤝 개발자와의 커뮤니케이션이 쉬워집니다.
추상적인 설명 대신 실제 입력과 출력 예시를 기준으로 논의할 수 있습니다.
💸 불필요한 개발 비용을 줄일 수 있습니다.
사용자에게 필요하지 않은 기능이나 잘못된 방향을 개발 전에 발견할 수 있습니다.
📈 AI 품질을 지속적으로 개선할 수 있습니다.
프로토타입에서 사용한 테스트 데이터를 이후 품질 평가 자료로 활용할 수 있습니다.
프롬프트를 작성하는 것이 아니라, 서비스를 설계하세요
AI 서비스에서 프롬프트는 개발 마지막 단계에 추가하는 문구가 아닙니다.
사용자의 입력을 어떻게 해석하고, 어떤 정보를 참고하며, 어떤 결과를 제공할지 결정하는 핵심 설계 요소입니다.
따라서 기획자와 PM도 프롬프트를 직접 설계하고 테스트할 수 있어야 합니다.
코드를 작성하지 못해도 괜찮습니다.
먼저 실제 사용자 상황을 정의하고, 좋은 결과의 기준을 만들고, 여러 입력을 반복해서 테스트해 보세요.
개발 전에 프롬프트로 기능을 검증하는 것만으로도 수많은 시행착오를 줄일 수 있습니다.
👉 지금 바로 적용해 보세요
현재 기획 중인 AI 기능 하나를 선택해 다음 세 문장을 작성해 보세요.
사용자는 어떤 상황에서 이 기능을 사용하는가?
사용자가 최종적으로 얻고 싶은 결과는 무엇인가?
AI가 절대로 하면 안 되는 행동은 무엇인가?
이 세 가지가 정리되었다면, 이미 첫 번째 프롬프트 프로토타입을 만들 준비가 끝난 것입니다.
화면 설계서를 열기 전에 먼저 AI 채팅창을 열어보세요.
개발하기 전에 검증하고, 구현하기 전에 실패해 보는 것.
그것이 AI 시대의 기획자와 PM이 가져야 할 새로운 프로토타이핑 방식입니다.