기획 입문: AI와 문제 한 장으로 정리하기
기능 아이디어보다 먼저, 누구의 어떤 불편인지 그림과 메모로 구분합니다.
읽기 약 15분2026.10 기준
이 글을 마치면
- 사실과 가설을 구분합니다.
- 사용자 관점의 문제를 씁니다.
- 기능 후보를 근거와 비교합니다.
이런 분께
- 이 업무를 처음 맡아 AI와 함께 생각을 정리하고 싶은 분
- AI의 초안을 그대로 믿지 않고 근거를 확인하고 싶은 분
준비물
- 이 글의 사례·기록·숫자는 모두 연습용 가상 자료입니다. 실제 모델 응답이나 조사 결과가 아닙니다.
- 종이와 펜만으로도 연습할 수 있습니다. AI를 쓴다면 이미 이용 가능한 도구에 이 가상 자료만 넣으세요.
이 수업의 용어, 쉬운 말로
뜻을 먼저 읽고 본문으로 가세요. 용어를 누르면 예시까지 볼 수 있습니다.
핵심 정리
앱을 만들기 전에, 막힌 장면부터
그림: 세 메모가 돋보기 검토를 거쳐 장소 찾기 문제 한 장으로 모입니다. · AI Ping “독서 모임 앱에 AI 추천을 넣자.” 회의에서는 그럴듯하지만, 누가 어떤 상황에서 곤란했는지는 보이지 않습니다. 이 수업에서는 가상의 모임 운영자가 보낸 메모로 시작합니다. 메모 A는 “처음 온 사람이 다음 모임 장소를 다시 물었다”, 메모 B는 “장소는 공지 맨 아래에 있다”, 메모 C는 “운영자는 자동 답변 기능을 원한다”입니다. 세 메모는 실제 조사 기록이 아니라 문제를 구분하는 연습 자료입니다.
그림의 왼쪽 작은 카드들은 이 메모를 뜻합니다. 가운데 돋보기는 내용을 더 멋지게 만드는 도구가 아니라, 어떤 말이 어떤 근거에서 나왔는지 확인하는 과정입니다. 오른쪽 한 장에는 “처음 온 참가자가 장소를 찾기 어렵다”처럼 장면을 남깁니다. 자동 답변은 가능한 해결책 하나일 뿐, 지금 확인한 문제 자체는 아닙니다. 장소를 위로 옮기는 것만으로 해결될 가능성도 아직 남아 있습니다.
AI에게 처음부터 기능 열 개를 요청하면 해결책 후보가 늘어납니다. 하지만 질문에 빠져 있던 사용자의 상황까지 확인되는 것은 아닙니다. 먼저 사람, 하려던 일, 막힌 지점을 한 문장씩 적으세요. 이 연습에서는 세 항목을 쓰지만 모든 기획서가 세 줄이어야 한다는 뜻은 아닙니다. 메모 A에 없는 “매번”, “모든 참가자”, “한 시간 낭비”를 넣는 순간 관찰보다 큰 주장을 하게 됩니다. 작은 불편을 정확히 쓰는 것이 출발입니다.
사실·해석·질문을 다른 칸에
기획에서 가설은 “아직 확인하지 않았지만 시험해 볼 생각”입니다. 메모 B의 “장소가 공지 맨 아래에 있다”는 제공된 자료 속 사실입니다. “처음 온 사람은 긴 공지를 끝까지 읽지 않는다”는 해석입니다. “실제로 어디까지 읽었나요?”는 그 해석을 확인할 질문입니다. 이 세 가지를 한 문단에 섞으면 AI가 문장을 매끄럽게 연결하면서 해석을 사실처럼 보이게 만들기 쉽습니다.
종이에 사실, 가설, 확인 질문이라는 칸을 만드세요. 사실에는 메모 번호도 붙입니다. 출처 번호는 권위를 꾸미는 장식이 아니라 틀렸을 때 돌아갈 주소입니다. “참가자가 장소를 못 찾았다”와 “장소가 없었다”도 다릅니다. 메모 B는 장소가 있었음을 알려 줍니다. AI가 후자로 요약했다면 표현이 조금 바뀐 정도가 아니라 원인에 대한 판단이 달라진 것입니다. 공지 추가와 공지 배치 변경은 서로 다른 작업이 됩니다.
빈칸은 실패가 아닙니다. 기기를 무엇으로 봤는지, 첫 참석인지, 공지를 전달받았는지는 자료에 없습니다. 이런 항목에는 미확인이라고 씁니다. AI가 일반적인 앱 사용 습관을 알고 있더라도 이 참가자의 행동을 증명하지는 못합니다. 기획 문서의 품질은 모든 칸을 채웠는지가 아니라, 어떤 칸은 아직 비어 있어야 하는지 판단했는지로 확인합니다. 팀원이 원문을 보고 같은 구분에 동의하는지도 확인하세요.
사용자 스토리는 기능 주문서가 아니다
그림: 사람 → 하려는 일 → 목적지 순서로 사용자 스토리를 읽습니다. · AI Ping 사용자 스토리는 “누가, 무엇을 하고 싶고, 왜 필요한지”를 짧게 적는 방식입니다. GOV.UK의 작성 안내도 사용자와 필요, 목표를 담도록 설명합니다. 이 사례에서는 “처음 참석하는 사람으로서, 다음 모임 장소를 바로 확인하고 싶다. 늦지 않고 도착하기 위해서다”라고 써 볼 수 있습니다. 마지막 이유는 연습용 제안이며 실제 참가자에게 확인한 말은 아닙니다. 문서에도 이 차이를 남깁니다.
두 번째 그림에서 사람 아이콘, 문서, 목적지 표시를 순서대로 보세요. 사람은 주인공, 문서는 하려는 일, 목적지 표시는 얻고 싶은 결과입니다. 이 사이에 챗봇 그림을 반드시 넣을 필요는 없습니다. “AI로 장소를 알려 준다”라고 쓰면 해결 방식이 먼저 고정됩니다. “장소를 확인한다”라고 쓰면 공지 배치, 검색, 운영자 답변 등 여러 해결책을 비교할 여지가 남습니다.
여기에 완료 기준을 붙입니다. 예를 들어 “공지에서 다음 모임의 날짜와 장소를 찾을 수 있다”는 확인할 수 있는 결과입니다. “이용자가 만족한다”는 이번 자료만으로 판단하기 어렵습니다. 가상의 공지에서 날짜와 장소를 표시해 보고, 어떤 정보를 보여 줘야 기준을 확인할 수 있는지 적으세요. 특정 초 단위 속도나 만족도 수치를 붙이고 싶다면 먼저 어떻게 측정할지 정해야 합니다. 숫자가 없다고 불완전한 기획은 아닙니다.
AI에는 정답 대신 비교할 재료를 요청
이제 AI가 맡을 일을 좁힙니다. “최고의 기능을 정해 줘” 대신 “이 자료로 설명 가능한 문제와 아직 모르는 점을 나눠 줘”라고 요청합니다. 아래 요청은 복사해서 시험할 수 있는 연습 문장입니다. 실제 모델이 돌려준 답은 실려 있지 않습니다. 결과를 받아도 정답으로 채택하지 말고, 각 문장이 메모 A·B·C 중 어디에 기대는지 표시해 보세요. 연결할 메모가 없으면 추론이라고 적습니다.
비교할 후보는 두 개면 충분합니다. 하나는 공지 위에 장소를 올리는 방법, 다른 하나는 질문에 자동으로 답하는 방법입니다. 먼저 사용자가 얻는 결과가 같은지 확인합니다. 공지 변경은 장소가 바뀔 때 한 문서를 고치면 되지만, 자동 답변에는 어떤 자료를 최신으로 볼지 결정하는 일이 더 생깁니다. 이는 이 연습 설계에서 생각할 작업 차이이며, 어떤 도구가 언제나 더 비싸다는 가격 주장이 아닙니다.
선택 이유에는 장점 하나만 쓰지 않습니다. “장소가 반복해서 바뀌면 누가 고치는가”, “잘못 안내했을 때 누가 발견하는가” 같은 운영 질문도 붙입니다. 기능을 만든 날에는 둘 다 잘 보여도 이후 책임이 달라질 수 있기 때문입니다. AI의 유창한 추천보다 비교 표의 빈칸이 더 중요한 경우가 있습니다. 빈칸 때문에 선택을 보류한다면 부족한 자료와 다음 확인 행동을 적어 두세요.
프롬프트 예시 연습 자료: A 처음 온 참가자가 다음 모임 장소를 다시 물음. B 장소는 공지 맨 아래에 있음. C 운영자는 자동 답변을 원함. 사실·가설·확인 질문을 나누고 각 사실에 A/B/C를 붙여 줘. 자료에 없는 원인은 미확인으로 남겨 줘.
직접 해 보기: 한 장짜리 문제 정의
메모 A·B·C를 다시 읽고 한 장에 문제, 근거, 가설, 후보, 다음 질문을 적으세요. 문제에는 참가자가 하려던 일을 넣고 기능 이름은 잠시 뺍니다. 근거에는 메모 번호를 씁니다. 가설에는 실제로 확인하지 못했다는 표시를 붙입니다. 후보에는 공지 개선과 자동 답변을 함께 놓고, 다음 질문에는 원인을 가르는 질문을 넣습니다. 이 다섯 칸은 이번 연습의 도구이지 회사마다 반드시 써야 할 양식은 아닙니다.
완료 여부는 다른 사람이 원문 없이도 따라갈 만큼 화려한지로 판단하지 않습니다. 원문을 함께 읽은 사람이 “이 문장은 여기서 왔구나”라고 확인할 수 있어야 합니다. 자동 답변을 선택했더라도 공지 개선을 제외한 이유가 있어야 하고, 공지 개선을 선택했더라도 다른 참가자에게 같은 문제가 있는지 아직 모른다는 점은 남겨야 합니다. 한 사람의 질문에서 전체 사용자의 수요를 바로 계산하지 마세요.
마지막으로 문서에서 가장 자신 있는 문장 하나와 가장 불확실한 문장 하나를 표시하세요. 확실한 문장에는 근거가, 불확실한 문장에는 확인 행동이 있어야 합니다. 예를 들어 다음 모임 공지를 실제로 찾는 장면을 관찰하는 것이 확인 행동입니다. AI에게 가상 참가자 역할을 시켜 받은 반응은 질문을 다듬는 재료로만 씁니다. 그 반응으로 실제 수요가 검증됐다고 결론 내리지 않는 것까지가 이 수업의 마지막 과제입니다.
자주 하는 실수
- 가상 사례나 AI의 추측을 실제 고객 근거처럼 쓰지 마세요.
- 원문에 없는 일정·성과·약속을 채워 넣지 마세요.
- 예쁜 문서보다 왜 그렇게 판단했는지 설명하는 것이 먼저입니다.
연습 문제
“참가자 모두가 공지를 안 읽는다”를 고쳐 쓰세요.
풀이 보기
“메모 A의 참가자는 장소를 다시 물었다”로 범위를 줄입니다. 공지를 안 읽었는지, 다른 참가자도 같은지는 확인하지 못했습니다.
자동 답변을 만들지 않고 시험할 후보를 적으세요.
풀이 보기
공지 위에 날짜와 장소를 모아 두는 안입니다. 장소 찾기가 문제라면 기능 개발 전에 배치 변경으로 해결되는지 살펴볼 수 있습니다.
AI가 가상 참가자 역할로 좋다고 답했습니다. 수요 검증일까요?
풀이 보기
아닙니다. 가상 반응은 질문이나 시안을 고치는 재료이며 실제 사용자의 행동 근거가 아닙니다. 실제 참가자가 장소를 찾는 장면을 확인해야 합니다.
참고 자료
- Learning about users and their needs — GOV.UK
- Writing user stories — GOV.UK