결론부터
AI에게 "이 기능 중에 뭘 먼저 만들까"를 물으면 답은 나오지만 쓸 만하지 않습니다. AI는 모든 아이디어가 그럴듯하다고 말하기 때문에, 우선순위를 물으면 판단이 평균으로 수렴합니다. 무엇을 만들지, 무엇을 안 만들지는 기획자가 정합니다. AI가 줄여 주는 건 정리하는 시간입니다. 회의록, 요구사항 목록, 인터뷰 녹취 요약, 기획서의 빈 틀이 그렇습니다.
회의가 끝나고 30분 안에 보내는 회의록
회의록은 쓰는 시간보다 "누가 뭘 하기로 했는지"를 기억해 내는 시간이 깁니다. 회의 녹취나 메모를 붙여 넣고 결정 사항, 담당자, 기한만 뽑게 하면 회의록의 80퍼센트는 끝납니다. 나머지 20퍼센트가 확인 작업입니다. AI는 말하지 않은 담당자를 만들어 넣기도 하니, 담당자와 기한은 반드시 원본과 대조합니다.
아래는 앱 개편 주간 회의 메모다. 다음 형식으로 정리해줘. 1) 결정된 것 2) 아직 결정되지 않은 것과 이유 3) 할 일 표(할 일, 담당자, 기한). 메모에 담당자나 기한이 없으면 칸을 비우고 "미정"이라고 써. 사람 이름을 추측해서 채우지 마. [메모 붙여넣기]
"미정"으로 비워 두게 시키는 것이 요령입니다. 비워 두면 회의에서 안 정했다는 사실이 드러납니다.
기획서는 빈 틀부터 채우기
기획서를 쓰다가 막히는 곳은 보통 두 군데입니다. 어떤 항목이 들어가야 하는지 모를 때, 그리고 빠진 항목을 못 찾을 때. AI는 두 가지에 모두 쓸 만합니다. 다만 "기획서 써줘"라고 하면 어느 서비스에나 맞는 일반론이 나옵니다. 문제, 대상, 지금 상황을 내가 먼저 주고 목차와 빈틈을 묻는 방식이 낫습니다.
나는 동네 모임 앱의 기획자 이준호다. 아이디어: 같은 동네 사람끼리 주 1회 걷기 모임을 만들 수 있는 기능. 지금 알고 있는 것: 20~30대 직장인 대상, 기존 앱에서 모임 개설이 어렵다는 불만이 있음. 기획서 목차를 제안하고, 각 항목에서 내가 아직 모르는 것을 질문 형태로 적어줘. 내용을 지어서 채우지는 마.
아래는 내 기획서 초안이다. 개발자, 디자이너, 운영팀 각자의 입장에서 읽고 "이 문서만으로는 알 수 없는 것"을 3개씩 뽑아줘. 비판이 아니라 질문으로. [초안]
리뷰어 입장을 나눠 주면 질문이 구체적으로 나옵니다.
요구사항, 개발자가 읽을 수 있는 문장으로
"로그인을 편하게"라는 요구사항은 개발자에게 아무 정보도 못 줍니다. 편하다는 게 뭔지, 어떤 경우를 말하는지가 빠져 있습니다. AI에게 모호한 요구사항을 주고 "개발자가 되물을 질문"을 뽑으면 작성자가 놓친 부분이 드러납니다.
단, 기술적으로 가능한지, 개발 기간이 얼마나 걸릴지는 AI가 모릅니다. 그건 개발자와 정합니다.
요구사항: "로그인을 편하게 해줘". 개발자가 이 문장을 받았을 때 되물을 질문을 10개 뽑아줘. 그다음 내가 답하면 "사용자가 ~하면 시스템은 ~한다" 형식의 인수 조건으로 바꿔줘. 일정이나 기술 구현 방식은 제안하지 마.
사용자 인터뷰 10건 요약
인터뷰 녹취를 다 읽는 데 하루가 걸립니다. 녹취록을 AI에게 주면 반복되는 불만과 표현을 묶어 줍니다. 다만 AI가 요약하면 소수의 강한 의견이 묻히기 쉽습니다. "한 명만 말했지만 심각한 문제"를 따로 뽑으라고 해야 합니다.
인터뷰 참가자의 실명, 연락처, 회사 정보는 지우고 올립니다. 참가자 동의 범위에 외부 AI 서비스 사용이 들어 있는지도 확인합니다.
아래는 걷기 모임 앱 사용자 인터뷰 녹취 3건이다(참가자는 A, B, C로 표기). 1) 2명 이상이 말한 불편 2) 1명만 말했지만 이탈로 이어질 만한 이야기 3) 참가자가 실제로 쓴 표현 그대로 인용 5개를 정리해줘. 인용은 누가 말했는지 표시하고, 내가 붙여넣은 글에 없는 문장은 만들지 마. [녹취록]
코드 없이 프로토타입 만들어 보기
화면 기획서를 설명하는 것보다 클릭해 볼 수 있는 시안을 보여 주는 게 빠를 때가 있습니다. AI에게 말로 설명해서 브라우저에서 움직이는 간단한 화면을 만드는 방식을 바이브 코딩이라고 합니다. 레시피 중 브라우저 게임을 만드는 글이 그 과정을 가장 가볍게 보여 줍니다.
이렇게 만든 건 아이디어 확인용입니다. 개발에 넘기는 산출물이 아니고, 보안과 구조가 정리되지 않은 코드입니다. 회의에서 "이런 느낌"을 맞추는 용도로만 쓰세요.
우선순위는 AI에게 묻지 않습니다
- 우선순위 결정. AI는 모든 기능이 가치 있다고 답합니다. 순서를 정하는 건 사용자 데이터와 팀 사정을 아는 사람입니다.
- 시장 규모, 경쟁사 수치. 출처 없는 숫자는 지어낸 숫자일 가능성이 높습니다. 기획서에 들어가면 제일 먼저 질문받는 부분입니다.
- 개발 일정 추정. 개발자의 영역입니다.
- 사용자 인터뷰 자체를 AI로 대신하기. 가상의 사용자 응답은 실제 사용자의 불편을 보여 주지 못합니다.
- 회사 내부 자료 통째 입력. 사내 보안 지침이 있으면 지침이 먼저입니다. 승인된 도구가 따로 있는 회사도 많습니다.
자주 묻는 질문
회의 녹음을 AI에 올려도 되나요?
참석자 동의와 회사 보안 지침을 먼저 확인하세요. 외부 서비스에 올리면 안 되는 회의도 있습니다. 개인정보 설정 글에서 대화가 학습에 쓰이지 않게 하는 방법을 볼 수 있습니다.
비개발자가 프로토타입을 만들어도 되나요?
아이디어를 보여 주는 용도로는 충분합니다. 그대로 서비스에 쓰는 건 위험합니다. 바이브 코딩 글에서 한계를 설명합니다.
PM에게 어떤 AI가 맞나요?
긴 문서를 한 번에 읽는 능력과 파일 업로드 여부가 기준입니다. 세 서비스 비교는 별도 글을 보세요.
AI가 쓴 기획서를 그대로 내도 되나요?
권하지 않습니다. 문서의 문제 정의가 일반론이 되고, 질문을 받으면 내가 답하지 못합니다. 초안과 빈틈 찾기에만 쓰세요.
관련 페이지
2026-11-05 작성. 작성 원칙