[AI입문 10편] 기획자는 AI를 이렇게 쓴다 – 요구사항 정의서·화면 설계 초안을 한 번에 뽑는 프롬프트

서론 – 빈 문서 앞에서 멍하니 있는 시간 줄이기

기획자에게 가장 무서운 것은 사실 일정이 아니라, “빈 문서”입니다.

회의는 끝났는데, 요구사항 정의서 문서는 텅 비어 있고
와이어프레임 툴은 열어놨지만 첫 화면 박스 하나 못 그리고 있고
머릿속에는 흐릿하게 그림이 있는데 문장과 박스로 안 떨어질 때

이때 AI를 제대로 쓰면, 역할이 아주 명확해집니다.

AI: “초안 담당” (구조 잡고, 문장 1차로 깔아주는 역할)
기획자: “판단·수정·결정 담당” (현실성과 맥락을 입히는 역할)

이 글에서는 회의록·아이디어 메모를 기반으로 요구사항 정의서와 화면 설계 초안을 뽑는 프롬프트를 정리하고,
실제 실무에서 어떻게 흐름을 잡으면 좋은지까지 함께 이야기해 보겠습니다.

1. 기획자가 AI를 써야 하는 이유 – “초안 노동”의 아웃소싱

기획자의 시간을 잡아먹는 건 보통 이런 일들입니다.

회의 끝나고 요구사항 정의서 처음부터 치기
머릿속 플로우를 화면 단위로 쪼개서 정리하기
비슷한 화면/요구사항을 여러 프로젝트에서 반복해서 다시 쓰기

이 중 상당수는 사실 “패턴이 있는 문서 작업”입니다.
그래서 AI에게 맡기기 좋은 영역이기도 합니다.

전략은 단순합니다.

회의록·아이디어·기존 문서를 AI에게 입력
“요구사항 정의서 형태로 정리해 달라”는 프롬프트 사용
결과물을 기반으로 기획자가 수정·추가·삭제
동일한 프롬프트를 여러 프로젝트에서 재사용

즉, “문서의 0 → 60% 구간”을 AI에게 넘기고, 60% 이후의 디테일과 현실 검증을 사람 쪽에서 맡는 구조를 만드는 게 목표입니다.

2. 요구사항 정의서 초안 뽑는 프롬프트 설계

먼저 요구사항 정의서 초안부터 봅니다. 보통 이런 항목들로 구성하죠.

프로젝트 개요·목표
용어 정의
사용자/고객 정의
주요 시나리오
기능 요구사항
비기능 요구사항(성능, 보안, 모니터링 등)
제약 사항·가정·우선순위

이 구조를 그대로 프롬프트에 녹이면, AI가 “요구사항 정의서 문법”에 맞춰 초안을 정리해 주기 쉬워집니다.

2-1. 요구사항 정의서 기본 프롬프트 (복붙용)

지금부터 너는 디지털 서비스 기획자를 도와
요구사항 정의서 초안을 작성하는 비서입니다.

아래에 내가 정리한 회의 메모/아이디어/배경 설명을 붙여 넣을 테니,
이를 바탕으로 요구사항 정의서 초안을 작성해 주세요.

요구사항 정의서 형식은 다음을 따라 주세요.

1. 프로젝트 개요
  - 서비스 이름(임시명)
  - 배경 및 문제 정의
  - 목표(비즈니스 목표 + 사용자 목표)

2. 주요 용어/대상 정의
  - 핵심 용어 간단 정의
  - 주요 사용자 유형(persona) 2~3개

3. 사용자 시나리오
  - 대표 사용자 여정(As-is → To-be)을 단계별로 bullet로 정리

4. 기능 요구사항
  - 기능별로 아래 항목을 포함해 bullet로 작성
    · 기능 ID (예: FR-001 형식으로 임시 부여)
    · 기능명
    · 설명(무엇을, 왜 제공하는지)
    · 관련 화면/채널(웹/앱/관리자 등)
    · 우선순위(상/중/하)

5. 비기능 요구사항
  - 성능, 보안, 모니터링, 장애 대응 등 필요한 항목을 bullet로 정리

6. 제약 사항 및 가정
  - 현재 전제하고 있는 가정
  - 일정/예산/시스템 측면 제약 사항

7. 리스크 및 논의 필요 사항
  - 추가 논의가 필요한 이슈를 bullet로 정리

문장은 한국어 존댓말로, 너무 문어체가 아닌 실무 문서 스타일로 작성해 주세요.

아래부터 회의 메모/아이디어입니다.
--------------------
[여기에 회의 메모·아이디어·요청 내용을 붙여 넣기]
--------------------

2-2. “회의록 기반” 요구사항 초안 프롬프트

9편에서처럼 회의 녹음 → 전사 텍스트가 이미 있다면, 그 텍스트를 바로 요구사항 정의서 초안으로 연결할 수 있습니다.

아래 내용은 기능/서비스에 대한 회의 전체 대화 내용(전사본)입니다.
이 내용을 바탕으로 요구사항 정의서 초안을 만들어 주세요.

요청사항:
- 회의에서 실제로 논의된 내용만 반영하고, 추측은 최소화해 주세요.
- 참여자가 다르게 의견 낸 부분은 "논의 필요 사항" 섹션으로 정리해 주세요.

형식:
(위 요구사항 정의서 기본 프롬프트에 정의한 1~7번 구조 동일하게 적용)

아래부터 회의 전사본입니다.
--------------------
[여기에 회의 전사 텍스트 붙여 넣기]
--------------------

2-3. 기획자가 마지막에 손 봐야 할 포인트

기능 ID 체계: 실제 팀에서 쓰는 규칙에 맞게 정리
용어 정의: 사내에서 쓰는 표현과 AI가 만든 표현 간 차이 조정
우선순위: AI가 임의로 붙인 우선순위를, 팀 현실에 맞게 다시 조정

초안의 70~80%는 AI가 채우더라도, “용어·우선순위·리스크”는 기획자가 직접 다듬어야 하는 구간입니다.

3. 화면 설계(와이어프레임) 초안 뽑는 프롬프트 설계

화면 설계는 결국 아래 세 가지로 압축됩니다.

어떤 화면들이 필요한지 (화면 목록)
각 화면에 어떤 요소가 들어가는지 (컴포넌트, 필드, 버튼 등)
화면 간에 어떻게 이동하는지 (플로우)

텍스트 기반 AI에게 “피그마를 그려줘”라고 할 수는 없지만, “화면 설계 문서 초안”은 충분히 뽑게 할 수 있습니다.

3-1. 화면 목록·플로우 초안 프롬프트

위에서 만든 요구사항 정의서를 기반으로,
서비스 화면 설계 초안을 텍스트로 만들어 주세요.

요청사항:
1) 필요한 주요 화면 목록
   - 화면 ID (예: SC-001)
   - 화면명
   - 화면 목적(한 줄)

2) 화면 흐름(플로우)
   - 시작 화면부터 주요 화면까지 이동 흐름을
     "A → B → C" 형태로 그려 주세요.
   - 분기(조건)에 따라 다른 화면으로 가는 경우,
     조건을 함께 적어 주세요.

가능하면, 목록과 플로우를 표 또는 잘 정리된 bullet 형태로 작성해 주세요.

3-2. 화면별 요소 정의 프롬프트

화면 목록이 나왔다면, 이제 각 화면 안의 구성 요소를 뽑습니다.

위에서 정의한 각 화면(SC-001, SC-002, ...)에 대해,
화면 설계 문서에 쓸 수 있는 수준으로 구성 요소를 정리해 주세요.

각 화면마다 다음 항목을 포함해 주세요.

- 화면 ID / 화면명
- 섹션별 구성(예: 상단 영역, 메인 콘텐츠 영역, 하단 버튼 영역)
- 주요 컴포넌트
  · 텍스트/라벨
  · 입력 필드(필수/선택 여부)
  · 버튼(버튼명, 동작)
  · 리스트/카드 등 반복 요소가 있다면 구조 설명
- 상태/예외 케이스
  · 빈 상태(empty state)
  · 에러 상태
  · 로딩 상태가 필요한 화면이면 그 설명

문서는 한국어로 작성하고,
실제 화면 설계서에 바로 붙여넣어도 될 정도로
체계적으로 bullet 형식으로 정리해 주세요.

3-3. “PPT/피그마로 옮기기 좋은 형태”로 다듬는 프롬프트

마지막으로, 기획자가 PPT·피그마에 옮길 때 편하도록 섹션·요소를 한 줄씩 깔끔하게 정리해 달라고 요청할 수 있습니다.

위에서 작성한 화면 설계 내용을,
PPT 또는 피그마에 옮기기 쉽게 다시 정리해 주세요.

- 각 화면을 한 블록으로 보고,
  · 화면명
  · 화면 목적(1줄)
  · 주요 요소(5~10줄 이내 bullet)
  · 주요 플로우(어느 화면에서 진입하는지, 어디로 나가는지)
- 한 화면당 15줄 이내로 정리해 주세요.

4. 회의록 → 요구사항 → 화면 설계로 이어지는 전체 흐름

9편에서 다룬 회의록 자동화와 연결하면, 기획자의 전체 흐름은 이렇게 설계할 수 있습니다.

회의 녹음·전사 → 니즈·이슈·아이디어가 담긴 회의 전사 텍스트 확보
회의 요약 프롬프트 → 주요 논의 내용·결정사항·액션 아이템 정리
요구사항 정의서 프롬프트 → 회의 결과를 정식 문서 구조로 변환
화면 설계 프롬프트 → 요구사항 정의서를 화면 목록·플로우·요소 정의로 분해
기획자 검토·수정 → 현실성·정책·운영·데이터 구조 등을 반영해 최종 문서 완성

즉, 회의가 끝났을 때 이미 “기획 문서의 1차 재료”가 준비되어 있고, AI를 통해 그 재료를 요구사항 → 화면 설계로 빠르게 변환한 뒤, 기획자는 “판단과 조정”에 집중하는 구조입니다.

5. 실무에서 쓸 때 주의할 점과 한계

당연하지만, AI가 뽑아 준 문서를 그대로 개발에 넘기는 것은 위험합니다. 실무에서는 아래 몇 가지를 꼭 체크해야 합니다.

5-1. 도메인·정책·운영 규칙은 AI가 모른다

우리 회사만의 정책, 요금 체계, 조직 구조는 AI가 “추측”할 뿐입니다.
결제·개인정보·보안 관련 기능은 반드시 사람 검토가 필요합니다.

5-2. 용어·ID 체계는 팀 표준에 맞춰 수정하기

화면 ID, 기능 ID, 메뉴명 규칙은 팀마다 다릅니다.
AI가 임의로 만든 ID를 “참고용”으로 보고, 실제 규칙에 맞게 일괄 정리하는 과정이 필요합니다.

5-3. 개발·디자인 동료와의 “신뢰” 관리

AI 초안은 어디까지이고, 기획자가 어디부터 책임졌는지 명확히 하는 게 좋습니다.
동료에게는 “AI로 뼈대를 잡고, 나는 검수·조율을 했다”는 식으로 투명하게 설명하면 협업에 도움이 됩니다.

5-4. 보안·비밀 유지

대외비 정보·고객 정보·실제 계정 정보 등은 직접 올리지 않도록 주의합니다.
필요하다면 숫자·이름·계정을 가명·마스킹 처리한 뒤 AI에 입력하는 습관을 들이는 게 좋습니다.

결론 – 초안은 AI, 최종 책임은 기획자

요약하면, 기획자가 AI를 잘 쓰는 포인트는 이 정도입니다.

회의록·아이디어를 “문서화하기 전 단계”에서 AI를 활용해 초안을 만든다.
요구사항 정의서·화면 설계처럼 형식이 정형화된 문서는 프롬프트만 잘 짜도 효과가 크다.
초안 작성 시간을 줄이고, 도메인·전략·경험이 필요한 판단에 더 많은 시간을 쓴다.

한 문장으로 정리하면,

“문서를 처음부터 혼자 쓰지 말고, AI에게 초안부터 맡기는 습관을 들이자.”
이 습관 하나가, 기획자의 하루를 꽤 다르게 만들어 줄 수 있습니다.

FAQ – 기획자들이 자주 하는 질문

Q AI가 만든 요구사항 정의서를 그대로 개발팀에 줘도 될까요?

A 그대로 쓰기보다는 “초안”으로 보는 게 좋습니다. 특히 용어 정의, 비기능 요구사항, 엣지 케이스는 반드시 기획자가 검토해서 실제 비즈니스·시스템에 맞게 손을 봐야 합니다.

Q 프롬프트가 너무 길어지면 오히려 귀찮지 않나요?

A 처음 한두 번 만들 때만 길게 느껴지고, 이후에는 이 글에 나온 프롬프트를 자신의 업무에 맞게 템플릿화해서 재사용하는 게 핵심입니다. 한 번 제대로 만들어 두면, 이후에는 일부만 수정해서 계속 쓸 수 있습니다.

Q 화면 설계를 AI에게 맡기면, 디자이너와 충돌 나지 않을까요?

A AI가 하는 일은 어디까지나 “정보 구조와 요소 나열” 수준입니다. 실제 인터랙션·비주얼·브랜드 표현은 여전히 디자이너의 영역이고, 오히려 AI가 초안 구조를 빠르게 뽑아주면 디자이너는 더 고급 UX·UI 고민에 시간을 쓸 수 있습니다.

Q 어떤 도메인에서 AI 문서 초안이 특히 잘 먹히나요?

A 반복되는 패턴이 많고, 텍스트 설명이 많은 영역일수록 효과가 큽니다. 예를 들어 가입/로그인/결제/마이페이지/검색·필터·리스트/상세 화면 등은 기본 플로우와 구성 요소가 어느 정도 패턴화되어 있어 AI 초안 활용에 적합합니다.

이 블로그 검색

AI야, 기획 아이디어 줄래?