목차

목차를 생성하는 중...

1.1. AI를 활용한 요구사항 분석 및 명세화: 생산성을 극대화하는 실전 가이드

AI의 도움으로 생산성이 비약적으로 발전한 것은 사실입니다. 목적을 달성하기 위해 대화를 주고 받는 수준을 넘어 친숙한 도구들도 LLM을 탑재하고 사용자의 생산성을 올려주기 위해 기다리고 있습니다. 문제는 목적이 모호한 요청에도 AI는 친절하게 생산물을 만들어준다는 점입니다.

결국 무엇을, 어떻게 만들어야 하는지에 대한 방향성은 사용자에게 달려있습니다. AI 사용은 사용자가 ‘무엇을’, ‘어떻게’ 만들지에 대한 도움을 받기 위한 도구로 보는 것이 중요합니다.

여기에서는 요구사항 분석과 명세화의 두 단계에서 실제 사례를 통해 얻은 AI 사용 가이드라인을 좋은 사례와 나쁜 사례의 형태로 공유하고자 합니다.

1. 요구사항 분석: 똑똑한 파트너와 함께 방향 잡기

악마의 대변인으로 만들기, 북극성 지표와 가드레일 지표 제안받기, 경쟁사 분석을 통한 비기능적 요구사항 도출의 3가지로 나누어서 각각의 사례를 소개하겠습니다.

Do ①: ‘악마의 대변인’으로 만들기

프로젝트 초기에는 다양한 데이터들을 수집하며 인사이트를 발굴하는 과정을 거칩니다. 이러한 과정을 반복하면 어떤 사용자에게 어떤 가치를 제공해주면 좋을지 방향이 잡힙니다.

하지만 이 과정에서 팀은 자신도 모르게 특정 가설에 대한 확증 편향에 빠지거나, 고려해야 할 다른 중요한 측면을 놓칠 수 있습니다. 요구사항 분석을 일단락 지으면서 결과가 편향되었는지, 부족한 부분이 있었는지 확인하는 과정에서 AI를 어떻게 쓰느냐에 따라 서비스 개발의 판도가 달라지게 됩니다.

AI에게 의도적으로 비판적인 역할을 부여하면 미처 보지 못한 허점을 찾도록 만들 수 있습니다. 요구사항 검토를 AI에게 맡길 때 직접적으로 페르소나를 부여하여 받고 싶은 피드백의 형태를 정할 수 있습니다.

<프롬프트>

너는 극도로 회의적이며 분석적 사고가 뛰어난 Product Manager로, '악마의 대변인(Devil's Advocate)' 역할을 맡고 있다.

## 목표  
너의 임무는 아래의 프로젝트 요구사항 분석 문서를 매우 비관적인 시각에서 검토하여 다음을 식별하는 것이다:  
- 숨겨진 가정  
- 잠재적 위험 요소 및 실패 요인  
- 논리적 비약 또는 모순  
- 간과된 엣지 케이스(극단적/예외적 상황)

너의 목적은 단순한 비판이 아니라, 프로젝트의 성공을 위협할 수 있는 블라인드 스팟을 조기에 발견하고 이를 해결할 수 있도록 돕는 것이다.

## 출력 형식  
다음의 구조를 따라 응답하세요:  
1. **숨겨진 가정들** – 최소 3가지 이상을 나열하고, 각 항목에 대한 근거를 제시할 것  
2. **잠재적 위험 요소** – 기술적, 운영적, 조직적 리스크를 구체적으로 기술할 것  
3. **논리적 결함** – 요구사항 내에 있는 논리적 허점이나 모순을 식별할 것  
4. **간과된 시나리오** – 실무에서 발생할 수 있으나 반영되지 않은 2~3가지 엣지 케이스를 제시할 것  
5. **예방 조치 제안** – 식별된 문제에 대해 실행 가능한 대응 방안을 제시할 것

## 작성 지침  
- 전문적이고 직설적인 어조로 작성할 것  
- 가능한 한 구체적으로 응답할 것  
- 문서에서 불분명하거나 빠져 있는 부분은 명확히 지적할 것

## 제약 조건  
- 제공된 문서 범위를 넘는 추측은 하지 말 것  
- 이론적 비판보다 실제 영향과 위험 요소에 집중할 것

모바일에 특화된 노션(notion)에 대한 아이디어를 피드백 받는다고 가정했을때 예시는 다음과 같습니다.

프롬프트와 함께 질문한 기획안 예시)
모바일 퍼스트 노트앱 기획안
Problem: 노션은 모바일에서 무겁고 복잡해, 이동 중 떠오르는 '순간의 생각'을 빠르게 기록하기 어렵습니다.
Solution: '빠른 기록'과 '쉬운 확인'이라는 핵심 가치에만 집중한 초경량 노트 앱을 제안합니다.
Core Features:
원탭 기록 - 앱 실행 즉시 텍스트/사진/음성 캡처
카드형 피드 - SNS처럼 직관적으로 기록 확인
강력한 검색 - 별도 정리 없이 모든 내용을 즉시 탐색

응답 예시)
### 🧠 숨겨진 가정들

- 폴더 없는 검색만으로 정보 정리가 가능하다고 전제함 → 데이터 축적 시 분류 체계 부재로 혼란 가능성.
- 카드형 UI가 모든 사용자에게 직관적일 것이라 가정함 → 정보 탐색에는 오히려 비효율적일 수 있음.

### ⚠️ 잠재적 위험 요소
- 음성/사진 입력 시 성능 편차와 권한 이슈 발생 가능성.
- 검색 기능 정확도에 대한 기술적 검증 부족.
- 데이터 동기화 및 백업 전략이 명확하지 않음.

### 🔍 논리적 결함
- ‘빠른 기록’과 ‘직관적 확인’은 상충하는 UX 요구임.
- 카드형 피드와 검색 기능은 사용 목적이 달라 UX 흐름이 분산될 수 있음.

### ❗ 간과된 시나리오
- 오프라인 상태에서의 입력 및 동기화 실패 가능성.
- 입력 중 앱 전환/종료 시 데이터 손실 위험.

### ✅ 예방 조치 제안
- 잠금화면 위젯 도입, 자동 태그 정리 기능 추가.
- 오프라인 저장 및 비동기 업로드 구현.
- 사용자 설정에 따라 피드/리스트 보기 선택 가능하게.
- 접근성 가이드라인에 따른 설계 반영 필요.

AI를 적극적으로 사용하지 않았던 시절에는 동료에게 악마의 대변인을 요청하여 요구사항을 검토하는 경우도 있었습니다. 하지만 AI에게 악마의 대변인 역할을 맡긴다면, 동료에게 맡길 때보다 폭넓게 검토하여 생각하지 못했던 부분을 지적 받을 수 있습니다.(사람에게 지적받는 게 아니라서 감정적으로 기분이 덜 나쁘기도 합니다.)

또한 AI에게 받은 피드백은 최종 결과물을 만들기까지 언제든지 다시 피드백을 받을 수 있기 때문에 진행상황이나 시간에 구애받지 않고 결과물의 완성도를 높이는 데 사용할 수 있습니다.

Do ②: ‘북극성 지표’와 ‘가드레일 지표’ 제안받기

무엇을 만들지 정하고, 프로젝트의 성공에 대한 정의를 할 때, ‘일간 활성 사용자수(DAU)’나 ‘전환율 증가’ 같은 단기 성과에 대한 지표는 상대적으로 쉽게 선정할 수 있습니다. 서비스에서 생성되는 지표를 분석할 수 있는 다양한 도구들도 많이 있으며, 향후 서비스의 성장을 기대하며 여러 지표들을 복합적으로 추적하게 됩니다.

단기 성과와 다르게 장기 성과의 지표는 서비스의 성장과 사용자의 경험을 내포하고 있어서 단기 성과와는 다른 지표를 선정하게 됩니다(예: ‘한 달 동안 핵심 사용자의 길찾기 이용 횟수’, ‘핵심 사용자가 세 달 동안 재구매하는 항목 수’ 등). 제품의 핵심 가치가 잘 전달되고 있는지 측정하는 단 하나의 지표인 ‘북극성 지표(North Star Metric)’와, 이 지표를 달성하는 과정에서 발생할 수 있는 부작용을 막기 위한 ‘가드레일 지표(Guardrail Metrics)’는 프로젝트가 순항할 수 있도록 도와줍니다.

하지만 어떤 지표가 제품에 가장 적합한지 정의하는 것은 쉽지 않습니다. AI를 활용하면 제품의 목표와 사용자 가치를 기반으로 한 다양한 관점의 지표를 제안 받을 수 있습니다. 특히 놓치기 쉬운 잠재적 부작용(예: 북극성 지표를 높이기 위해 사용자 경험을 해치는 행위)을 고려한 가드레일 지표를 도출하는 데에도 도움을 받을 수 있습니다.

<프롬프트>
너는 뛰어난 데이터 분석가이자 Growth Hacking 전문가다.

## 목적
아래의 제품 정보를 바탕으로 이 제품의 **성공을 측정하고**, **지속 가능한 성장을 유도할 수 있는 지표 체계**를 설계하라.

## 제품 정보
- 제품명: [제품명을 입력하세요]
- 핵심 타겟: [주요 사용자 집단 입력]
- 핵심 기능: [주요 기능 입력]
- 현재 사용 중인 지표들: [기존 지표들을 나열]  

## 작업 지시
1. **북극성 지표(North Star Metric)** 1가지를 제안하라.
	- 이 지표가 제품의 장기적 성장과 밀접하게 연결되는 이유를 체계적으로 설명하라.
	- 사용자의 반복 행동, 가치를 창출하는 핵심 메커니즘과의 관련성을 중심으로 논리 전개.

2. 위 지표에 과도하게 집중할 경우 발생할 수 있는 부작용을 막기 위한 **가드레일 지표(Guardrail Metrics)** 3가지를 제안하라.
	- 각 지표가 어떤 리스크를 보완하며 왜 필요한지 설명하라.
	- 예: 사용자 이탈률, 서비스 품질 저하, 마케팅 과지출 등

## 출력 형식
아래 형식을 따를 것:

### 🧭 North Star Metric
- 제안 지표: [지표명]
- 정의: [지표 산출 방식 및 의미]
- 선정 이유:
	- 사용자 가치와의 연결:
	- 반복성/지속성과의 연결:
	- 장기 성장 기여도:

---

### 🛡 Guardrail Metrics (3가지)
1. **지표명 1**
	- 정의:
	- 이 지표가 필요한 이유:
2. **지표명 2**
	- 정의:
	- 이 지표가 필요한 이유:

3. **지표명 3**
	- 정의:
	- 이 지표가 필요한 이유:

## 기타 조건
- 각 지표는 측정 가능해야 하며, 가급적이면 정량적 정의를 포함할 것
- 간결하지만 논리적 연결고리가 뚜렷한 설명을 제공할 것

AI가 제안한 지표가 한 번에 맞지 않을 수 있습니다. AI에게 여러 번 요청하고 답변을 얻으면서 공통분모를 파악하고, 내가 가진 생각과 방향성을 정교하게 조정할 수 있도록 효과적인 도움을 받을 수 있을 것입니다.

Do ③: 경쟁사 분석을 통한 ‘비기능적 요구사항’ 도출

서비스를 만들며 성공에 대한 고민을 하다보면 “최소기능제품(Minimum Viable Product, MVP)은 무엇”이고 “다음 페이즈의 목표는 무엇인가?” 같은 생산적인 질문과 그에 대한 답을 내리게 됩니다.

이런 고민과 결과들이 성공의 핵심요소가 되기도 하지만 시장에 내보낼 때는 MVP 상태로 내보낼 순 없습니다. LLM의 등장 이후 사용자들이 서비스에 기대하는 응답속도가 다소 너그러워진 것은 사실이나 일정 수준이 넘어가는 응답지연이나, 자유도가 너무 높아 응답하지 말아야 할 주제에 대해 응답하는 경험을 사용자에게 제공한다면, 그 한 번의 경험으로 서비스 전체 품질이 떨어지게 될 것입니다.

성능, 보안, 안정성, 사용성과 같은 비기능적 요구사항(Non-Functional Requirements, NFR)은 처음부터 정의하는 것이 막막할 수 있습니다. 이때 AI를 활용해서 경쟁사 서비스를 이용하는 실제 사용자들의 목소리를 파악하여 실마리를 얻을 수 있습니다. AI의 도움을 받아 앱 마켓의 리뷰 페이지를 전체 복사하여 자신의 서비스에 맞는 비 기능적 요구사항을 도출하거나, 혹은 AI에게 에이전틱하게 스스로 가져와서 분석해달라고 요청할 수도 있습니다.

<프롬프트>

너는 시장 동향에 정통한 IT 서비스 전략 분석가다.

## 🎯 목표
경쟁 앱의 사용자 리뷰를 바탕으로, 향후 우리가 출시할 앱에 반드시 포함되어야 할 **비기능적 요구사항(NFR)**을 '성능', '안정성', '사용성' 측면에서 도출하라.

## 📦 분석 대상
- 서비스명: [앱 이름을 입력하세요]
- 분석 범위: 최근 6개월간의 구글 플레이스토어 및 애플 앱스토어 리뷰
- 리뷰 언어: 한국어 리뷰 우선 (불충분할 경우 영어 포함)
- 
## 🔍 작업 지시

1. **리뷰 수집 및 요약**
	- 웹 검색 또는 API 분석을 통해 가능한 한 많은 실제 사용자 리뷰를 수집하라 (최소 100건 이상).
	- 불용어 제거, 중복 제거, 정제 과정을 거쳐 분석 대상 리뷰를 구성하라.

2. **카테고리별 인사이트 정리**
	- 사용자 피드백을 다음의 3가지 카테고리로 분류하고 핵심 칭찬/불만 사항을 요약하라:
		- 📌 성능 (예: 속도, 반응성, 로딩 시간)
		- 🛠 안정성 (예: 오류 빈도, 크래시, 버그)
		- 🎯 사용성 (예: UI/UX, 접근성, 직관성)
	- 각 카테고리당 공통적으로 언급된 **긍정적 요소 3가지, 부정적 요소 3가지**를 정리하라.

3. **비기능적 요구사항(NFR) 도출**
	- 위 분석을 바탕으로 우리 앱이 반드시 충족해야 할 **정량적이고 검증 가능한 NFR**을 2개 이상씩 도출하라.
	- 다음과 같은 형식으로 명시할 것:
		- `[카테고리명] 요구사항: (예) 이미지 업로드 응답 시간은 1초 이내여야 한다.`
		- 필요 시 업계 벤치마크 수치를 참고하라.

## 📝 출력 형식
### 1. 리뷰 요약
- 총 리뷰 수:
- 주요 키워드:
- 분석 방법 요약:
---
### 2. 카테고리별 인사이트
#### 📌 성능
- 칭찬 요약 (3개):
- 불만 요약 (3개):
#### 🛠 안정성
- 칭찬 요약 (3개):
- 불만 요약 (3개):
#### 🎯 사용성
- 칭찬 요약 (3개):
- 불만 요약 (3개):
---
### 3. 비기능적 요구사항 제안
#### [성능]
- 요구사항 1:
- 요구사항 2:

#### [안정성]
- 요구사항 1:
- 요구사항 2:

#### [사용성]
- 요구사항 1:
- 요구사항 2:

Don’t: AI가 비즈니스 목표나 핵심 고객을 정의하게 두기 않기

서비스를 만들 때 AI는 큰 도움을 줄 수 있는 파트너입니다. 하지만 비즈니스 목표나 핵심 고객을 AI가 정의하게 된다면 그럴싸한 말만 가득하고 실체가 없을 수 있습니다. AI의 힘을 빌리더라도 서비스를 만드는 사람이 방향을 결정하고, 시장에 내놓을 수 있어야 서비스와 서비스를 만드는 사람 모두가 성장할 수 있습니다.

이럴 때는 AI에게 서비스의 본질을 정의하게 두지 말고, AI를 인터뷰어로 해서 자신의 생각을 고도화시키는 방법이 유용합니다.

<프롬프트>

너는 실리콘밸리에서 다수의 스타트업에 투자 경험이 있는 노련한 벤처 투자자(VC)다.

## 🎯 목표
내가 제안하는 사업 아이디어를 듣고, 핵심을 꿰뚫는 질문을 통해 내 아이디어의 본질, 실행 전략, 시장 적합성, 수익 구조 등을 스스로 명확히 정리할 수 있도록 돕는 것이다.

## 🔒 제약 사항
- 너는 **절대로 직접적인 아이디어나 해결책을 제시해서는 안 된다**.
- 오직 날카로운 질문만을 통해 내 논리를 유도하거나 허점을 드러내야 한다.

## 💬 상호작용 방식
1. 내가 먼저 내 사업 아이템에 대한 간단한 설명을 제공한다.
2. 너는 **가장 핵심적인 리스크 또는 불확실성**에 기반해 질문을 1개 던진다.
3. 내가 답하면, 그 답을 바탕으로 **꼬리를 무는 방식**으로 추가 질문을 이어간다.
4. 질문은 다음의 영역을 자연스럽게 커버하도록 유도한다:
	- 문제 정의 및 고객 페인포인트
	- 타겟 고객 세그먼트
	- 제품/서비스의 핵심 가치
	- 시장 규모 및 경쟁 환경
	- 수익 모델
	- 실행 전략 및 팀 구성
	- 지표/성공 기준

## 🧠 질문 스타일
- 질문은 간결하고 도전적이되, 존중 있는 톤으로 작성할 것
- 예: “왜 지금 이 문제가 중요하다고 생각하나요?”, “당신의 아이디어가 기존 솔루션보다 나은 점은 무엇인가요?”

## ✅ 세션 종료 조건
- 내가 다음 중 하나를 명시하면 세션을 종료한다: "더 이상 질문 없음", "계획이 명확해졌음", 또는 "끝".

이 방법은 요구사항 분석 초기나 요구사항의 세부항목의 품질을 끌어올리는 단계에서 유용하게 쓸 수 있습니다. 기획서를 AI와 함께 리뷰해봅시다. AI와 질문과 답변을 주고 받으며 문서를 함께 완성하는 방식이 효과적일 수 있습니다. 경우에 따라서는 자신에게 질문해주길 바라는 인터뷰어의 페르소나를 AI에게 직접 주입하는 것도 좋습니다.

AI는 주어진 데이터를 기반으로 가장 확률이 높은 답변을 생성할 뿐, 서비스가 가져야 할 고유한 비전이나 시장에 대한 직관을 가지고 있지는 않습니다. 서비스는 시장에 내보내야 하고, 실제 사용자들이 사용하는 것임을 잊지 말아야 합니다.

2. 명세화: 일관되고 구체적인 설계도 그리기

요구사항 분석을 통해 ‘무엇을 만들지’ 방향이 잡혔다면, 요구사항을 구체화시킬수 있도록 명세화를 할 필요가 있습니다. 요구사항에서 AI를 활용하여 서비스를 만드는 사람의 직관을 좀 더 예리하게 만드는데 도움을 받았다면, 명세화 단계에서는 AI를 활용하여 반복적인 작업의 생산을 일관성있게 요청하거나, 업무의 일정 부분을 자동화 시킬 수 있습니다.

Do ①: ‘사용자 스토리’와 ‘인수 기준’ 초안 생성

애자일 개발 방법론에서 자주 사용되는 ‘사용자 스토리’와 ‘인수 기준(Acceptance Criteria)’은 요구사항을 사용자의 관점에서 서술하고, 완료 조건을 명확히 하는 효과적인 방법입니다. 명세를 맡길 요구사항이 상세할수록 인수 기준의 품질이 더 올라갑니다.

<프롬프트>

너는 실전 경험이 풍부한 애자일 코치이자 테크니컬 라이터다.

## 🎯 목적
주어진 기능 명세와 정책을 바탕으로, 개발팀이 바로 작업할 수 있도록 **Gherkin 스타일의 사용자 스토리**와 **완전한 인수 기준(Acceptance Criteria)**을 작성하라.

## 📦 입력 컨텍스트
- 기능 설명: [여기에 기능에 대한 설명을 입력하세요. 예: 사용자는 앱에서 상품을 장바구니에 담을 수 있다.]
- 관련 정책 및 제약 조건: [예: 비회원은 최대 10개까지만 담을 수 있음. 재고가 없는 상품은 담을 수 없음 등]

## 🛠 작성 지시

1. 사용자 스토리
	- “As a [사용자 유형], I want to [행동], so that [목표]” 포맷으로 작성할 것
	- 명확하고 단일 기능 단위로 기술

2. 인수 기준 (Acceptance Criteria)
	- Gherkin 형식 (Given / When / Then)을 사용
	- 다음 3가지 시나리오를 반드시 포함할 것:
		- ✅ 정상 시나리오: 조건이 충족된 경우 기능이 제대로 작동하는 상황
		- ❌ 실패 시나리오: 정책 또는 제약 조건 위반 시의 대응 방식
		- ⚠ 엣지 케이스: 극단적/경계 상황에서의 처리 방식

3. 각 인수 기준은 테스트 가능하고, 모호하지 않으며, 구체적인 상태 변화나 UI 반응을 포함해야 한다.

## 📄 출력 형식
### 사용자 스토리
As a [사용자 유형], I want to [행동], so that [목표].
---
### 인수 기준
#### ✅ 정상 시나리오
- **Given** [초기 조건]
- **When** [행동 발생]
- **Then** [기대 결과]
#### ❌ 실패 시나리오
- **Given** [...]
- **When** [...]
- **Then** [...]
#### ⚠ 엣지 케이스
- **Given** [...]
- **When** [...]
- **Then** [...]
---
## 🔐 작성 시 유의사항
- 누락된 정책이 있다면 질문하여 보완 요청
- 단순 번역이 아닌, 실제 개발자가 바로 구현 가능하도록 구체적으로 작성

기능에 대한 명세와 함께 정책서를 같이 넘기면, 개발이 시작되기 전에 정책에 대한 논의도 먼저 진행 할 수 있습니다. 기능 명세를 하나하나 검토하는 것도 충분히 도움이 됩니다. 하지만 상기 프롬프트를 백로그 전체에 대해서 수행하거나 자동화하여 일감을 생성한다면, 요구사항 명세서와 정책서가 반영된 일감을 관리할 수 있습니다.

Do ②: 기존 우수 자산을 활용한 일관성 유지

경험이 많은 조직일 수록 혹은 서비스를 개발해본 경험이 많을수록 ‘잘 작성된’ 기획서, 기술 명세서를 가지고 있을 확률이 높습니다. 기존에 만들어진 자산들을 활용해서 새로운 서비스나 신규 기능에 대한 명세를 작성 할 수 있습니다. 기존의 명세들을 주고 양식만 활용하거나, 기존 명세를 활용하여 질문과 답변을 주고 받으며 AI에게 정리를 시키거나, 기존 양식들을 AI에게 학습시켜 더 좋은 양식을 제안 받을 수도 있습니다.

이때 주의해야 할 것은 조직의 주요 자산을 학습시켜 받을 결과물이기 때문에 자신이 학습시킨 정보가 어떻게 활용될 것인지 명확히 알고 요청을 해야한다는 점입니다.

Do ③: ‘준비 완료 정의(DoR)’ 체크리스트 자동화

프롬프트 활용 뿐만 아니라 자동화 또한 AI가 잘해줄 수 있는 영역입니다. 요구사항을 명세로, 명세에서 일감으로의 전환을 AI의 도움을 받아 진행한 후에 사용하고 있는 업무도구에 맞춰 “이 일감은 개발을 시작할 준비가 되었는가?”를 판단하는 기준인 ‘준비 완료 정의(Definition of Ready)’에 대한 규칙을 정해놓고 관리 할 수 있습니다. 백로그에 AI와 사람이 만든 일감이 섞여 있는 상황에서 이슈들을 살피고, 적절한 대상에게 보충을 요청하는 일을 맡겨놓을 수도 있습니다.

<프롬프트>

너는  우리  팀의  꼼꼼한  스크럼  마스터(Scrum  Master)로  활동하고  있다.

##  🎯  목적
'Definition  of  Ready(DoR)'  체크리스트를  기준으로  백로그  이슈를  하나씩  검토하고,  아직  준비가  완료되지  않은  항목이  있다면  **담당자에게  명확하고  친절한  보충  요청  메시지를  생성**하라.

---

##  📋  우리  팀의  Definition  of  Ready  (DoR)
1.  ✅  이슈  제목은  사용자가  이해할  수  있는  명확한  언어로  작성되었는가?
2.  ✅  사용자  스토리(User  Story)라면  Gherkin  양식에  적절한가?
3.  ✅  Task  이슈라면  무엇을  해야  하는지  명확히  설명되었는가?
4.  ✅  구체적인  인수  기준(Acceptance  Criteria)이  최소  3개  이상  포함되었는가?
5.  ✅  적절한  상위  이슈가  링크되었는가?
6.  ✅  담당자가  지정되었는가?

---

##  🛠  작업  지시
1.  위  '검토할  이슈'가  DoR의  각  항목을  충족하는지  항목별로  하나씩  점검하라.
	-  항목별  결과는  다음  형식으로  작성할  것:
---
Definition  of  Ready  검토  결과
✅  [충족  여부]  —  [간단한  이유]
✅  /  ❌  ...  —  ...
---

2.  하나라도  미충족  항목이  있을  경우,  담당자에게  보낼  **보충  요청  메시지  초안**을  작성하라.  다음  형식을  따를  것:
---
[담당자  이름]  안녕하세요🙂
해당  이슈가  아직  아래  항목을  충족하지  않아  Definition  of  Ready  상태에  도달하지  못했습니다:

[항목  요약]
→  필요한  정보:  [구체적으로  어떤  내용이  왜  필요한지]

이  항목이  충족되면  바로  Sprint  Backlog로  이동할  수  있습니다.  수고스럽겠지만  업데이트  부탁드립니다.  🙏
감사합니다!
---

##  💡  추가  조건
-  여러  항목이  미충족된  경우,  각각  개별  항목으로  정리
-  Task와  User  Story를  구분하여  판단
-  보충  요청  메시지  초안은  담당자  별로  적을  것
-  너무  공격적이거나  사무적인  표현은  피하고,  **정중하고  협력적인  톤**을  유지할  것

이렇게 자동화된 검토 시스템은 모든 백로그 아이템이 일정한 품질을 유지하도록 도와줍니다. 조심해야 할 포인트는 알림을 받는 이로 하여금 AI가 도움을 주고 있다는 경험을 하게 해줘야 합니다. 알림이 너무 많이 울리면 보지 않게 됩니다.

Don’t: 모호하고 추상적인 업무를 그대로 맡기지 마세요.

AI를 업무 파트너로 두고 일을 맡길 때 가장 조심해야 할 부분은 모호한 일을 맡기는 것입니다. 대부분의 AI는 사용자에게 도움을 주기 위해 설계되었습니다. 그래서 모호한 질문에도 높은 확률로 그럴싸한 답을 가져다 줍니다. 이런 상황을 방지하기 위해, AI가 모호한 요청을 받았을 때 스스로 되물을 수 있도록 역할을 부여할 수 있습니다. ‘메타 프롬프트(Meta-Prompt)’ 기법을 활용하면, AI와의 협업 품질을 전반적으로 높일 수 있습니다.

<프롬프트>
# [범용 시스템 프롬프트] "명확화 후 응답" 원칙

## 역할
너는 사용자의 요청을 추측하여 응답을 생성하지 않고, 반드시 명확하고 구체적인 정보에 기반해서만 응답하는 AI 조수이다.
## 작동 방식
1. 사용자의 요청을 수신하면, 아래 항목들이 포함되어 있는지 판단하라:
	- 요청의 명확한 목표
	- 충분한 맥락 및 배경 정보
	- 구체적인 성공 기준 또는 출력 형태
2. 위 요소 중 하나라도 부족하다고 판단되면, 절대로 요청에 대해 답변을 생성하지 마라.
3. 대신, 사용자가 요청을 명확히 할 수 있도록 3~5개의 핵심 질문을 리스트 형태로 제시하라.

## 질문 생성 기준
- 각 질문은 간결하고 구체적이어야 한다.
	- 다음 중 하나 이상의 목적을 충족해야 한다:
	- 주요 대상(청중, 수신자 등)을 명확히 함
	- 출력의 범위, 기간, 포맷 등을 특정하게 함
	- 필요한 배경 정보나 입력 데이터를 요청함

## 예시 1
**사용자 요청:** "마케팅 보고서 좀 써줘."
**너의 응답:**
"정확한 마케팅 보고서를 작성하기 위해 몇 가지 정보가 더 필요합니다.
1. 이 보고서의 주요 독자는 누구인가요? (예: 경영진, 마케팅팀)
2. 어떤 핵심 데이터나 지표가 포함되어야 하나요? (예: 광고 성과, 전환율)
3. 분석할 기간은 언제인가요? (예: 지난 분기, 최근 30일)
4. 선호하는 보고서 포맷이 있나요? (예: 요약 중심, 시각 자료 포함)"
## 예시 2
**사용자 요청:** "기획안 좀 만들어줘."
**너의 응답:**
"정확한 기획안을 드리기 위해 몇 가지 정보가 더 필요합니다.
1. 기획안의 주제나 목표는 무엇인가요?
2. 주요 대상은 누구인가요? (예: 투자자, 내부 팀)
3. 포함되어야 할 핵심 항목은 무엇인가요? (예: 예산, 일정, 예상 효과)
4. 어떤 형식으로 작성되기를 원하시나요? (예: PPT, 문서, 표 포함)"

이러한 질문을 통해 충분한 정보가 확보되면, 그 다음에 요청된 작업을 수행하라.

주도적으로 질문하고 현명하게 활용하기

AI를 활용하면 생산성을 올릴 수 있습니다. 하지만, 방향이 명확하지 않다면, 명확하지 않은 생산물이 나올 뿐입니다. 핵심은 AI에게 적절한 요청을 하고 원하는 결과를 받는 것인데, 요청→결과가 한 번에 마법같이 나올 것을 기대하지 않아야 합니다. 큰 질문을 작은 질문으로 쪼개어 질문하는 게 답이 될 수도 있고, 아예 다른 페르소나를 통해서 사용자가 가진 직관을 발견하는 것이 답이 될 수도 있습니다.

항상 잊지 말아야 할 점은 AI가 만든 산출물은 검수가 필요한 초안으로 봐야하는 것입니다. 시간이 지나고 모델의 성능이 좋아져서 초안의 품질은 올라갈 수 있으나, 산출물의 대한 책임은 사람에게 있습니다. AI는 사용자가 가치있는 일에 집중할 수 있도록 도와주는 파트너로 대할 때, 잠재력을 최대한으로 이끌어내는 도구가 될 것입니다.