# 현업을 위한 기획서 · 요구사항정의서 · 목업 작성 지침

> 개발 요청을 준비하는 현업 담당자용 템플릿입니다. AI와 문서 작업을 시작할 때
> 이 파일을 통째로 붙여 넣고 "이 지침대로 쓰자"고 말하면 됩니다.
>
> 출처: https://www.uniflow.kr/requirements-doc-vs-product-spec/
> 자유롭게 복사·수정해서 쓰세요.

---

## 0. 시작 전 30초 — 지금 쓰는 게 무엇인가

세 가지는 **답하는 질문**이 다릅니다. 한 파일에 담든 나눠 담든, 섞여 있으면 안 됩니다.

| | 답하는 질문 | 누가 읽나 |
|---|---|---|
| 기획서 | 왜 하는가, 누구를 위한 것인가 | 의사결정자, 유관 부서 |
| 요구사항정의서 | 무엇이 참이어야 하는가 | 개발, QA, 운영 |
| 목업 | 그래서 화면에서 어떻게 보이는가 | 전원 |

개발 기획(어떻게 만들 것인가, 레거시와 어떻게 붙일 것인가)은 **개발팀이 받아서 따로 합니다.**
여기서 거기까지 쓰지 않습니다. 쓰면 대개 틀리고, 틀린 채로 기준이 되면 더 나쁩니다.

### 이걸 다 쓸 필요가 없는 경우

- 문구 수정, 값 변경, 노출 on/off 같은 **단순 운영 건** → 한 줄 요청이면 충분합니다
- 화면이 없는 백엔드 작업 → 목업 대신 입력·출력 예시를 적습니다

---

## 1. 기획서 — 왜 하는가

AI에게 시킬 때는 이렇게 말합니다.

> 아래 내용으로 기획서를 써 주세요. **구현 방법은 쓰지 마세요.**
> 화면 설계, 데이터 구조, 기술 선택은 제외하고 목적과 판단 근거만 담아 주세요.

### 들어가야 할 것

- [ ] **배경** — 지금 무엇이 문제인가. 가능하면 숫자 하나 (문의 건수, 이탈 지점, 처리 시간)
- [ ] **목표** — 이걸 하면 무엇이 달라지는가. 한 문장
- [ ] **대상** — 누가 쓰는가. 역할로 적습니다 (예: "영업 담당자", "외부 거래처 담당자")
- [ ] **성공 기준** — 무엇이 보이면 성공인가. 측정 가능한 형태로
- [ ] **우선순위** — 이번에 꼭 필요한 것 / 있으면 좋은 것 / 다음에 할 것 세 묶음
- [ ] **하지 않을 것** — 범위 밖이라고 못 박을 것. 이 줄이 나중에 가장 많이 쓰입니다

### 쓰지 말 것

- 테이블 구조, API 설계, 프레임워크 이름 — 개발 기획의 영역입니다
- "최대한 빠르게", "유연하게", "확장 가능하게" — 판정이 불가능해 분쟁만 남습니다
- 일정 — 개발 기획이 끝나야 나옵니다. 원하는 **시점과 그 이유**는 적어도 됩니다
  (예: "11월 영업 캠페인 전", 이유가 있으면 조정 협의가 됩니다)

---

## 2. 요구사항정의서 — 무엇이 참이어야 하는가

개발이 가장 오래 들여다보는 문서입니다. 문장 하나가 곧 판정 기준이 됩니다.

> 아래 기능에 대해 요구사항정의서를 써 주세요.
> 각 항목을 **"~한다 / ~하지 않는다"로 판정 가능하게** 적어 주세요.
> 모호한 부분은 추측해서 채우지 말고 **질문 목록으로 따로 빼 주세요.**

### 항목 하나를 적는 형식

```
[기능명] 목록에서 상태 변경
- 동작: 목록 각 행의 상태 칸을 드롭다운으로 바꾼다
- 권한: 담당자와 관리자에게만 보인다. 그 외에는 칸 자체가 보이지 않는다
- 예외: 이미 마감된 건은 선택지가 비활성화된다
- 동시 수정: 나중 저장이 거절되고 최신 값을 다시 불러온다
- 빈 상태: 목록에 건이 없으면 "등록된 건이 없습니다"만 표시한다
- 수용 기준: 담당자가 아닌 계정으로 접속했을 때 상태 칸이 보이지 않는다
```

### 빠지면 반드시 되돌아오는 여섯 가지

문장으로 쓰면 거의 매번 빠지고, 빠진 채로 개발이 끝나면 다시 엽니다.

- [ ] **권한** — 누가 보는가 / 누가 바꾸는가. "안 보인다"와 "보이지만 못 누른다"는 다릅니다
- [ ] **빈 상태** — 데이터가 하나도 없을 때 화면에 무엇이 있는가
- [ ] **실패** — 저장이 실패하면 무엇이 보이고 입력값은 남는가
- [ ] **동시 수정** — 두 사람이 같은 건을 동시에 바꾸면 누가 이기는가
- [ ] **기존 데이터** — 지금 쌓여 있는 건들은 어떻게 되는가. 그대로 두는가, 바꾸는가
- [ ] **양 끝** — 0건일 때와 아주 많을 때(수만 건) 이 화면은 어떻게 되는가

### 수용 기준 쓰는 법

각 요구사항 끝에 **"이렇게 하면 통과"**를 한 줄 답니다.
검수할 때 그대로 쓰고, 개발도 이걸 보고 끝을 압니다.

- 좋음: "관리자가 아닌 계정으로 목록을 열면 상태 칸이 보이지 않는다"
- 나쁨: "권한 처리가 잘 되어야 한다"

---

## 3. 목업 — 그래서 화면에서 어떻게 보이는가

AI에게 HTML 목업을 만들게 할 때 쓰는 지시문입니다.

> 아래 요구사항으로 **단일 HTML 파일** 목업을 만들어 주세요.
> - 외부 라이브러리 없이, 더미 데이터를 화면 안에 넣어 주세요
> - 실제 저장·로그인·API 호출은 만들지 마세요
> - **빈 목록 / 로딩 중 / 오류 / 권한 없음** 상태를 각각 볼 수 있게 해 주세요
> - 각 화면 위에 그 화면의 이름을 적어 주세요
> - 맨 아래에 "이 목업은 요구사항을 보여주기 위한 것이며 구현 코드가 아닙니다"를 적어 주세요

### 목업에 기획 내용을 같이 담아도 되는가

**됩니다.** 화면 위에 그 화면의 목적과 요구사항을 적어 두면 읽는 사람이 편합니다.
파일을 꼭 세 개로 나눌 필요는 없습니다. 지킬 것은 하나뿐입니다 —
**어디까지가 확정된 요구사항이고 어디부터가 예시인지 구분이 되게** 적는 것.

- 확정된 요구사항: 번호를 붙이고 "~한다"로
- 보여주려고 넣은 더미: "예시" 표시. 숫자·이름·금액은 전부 여기에 들어갑니다

### 목업에 적어 둘 한 줄

목업을 보내기 전에 본문이든 파일 맨 위든 이 문장을 넣습니다.

> 이 목업은 **요구사항의 그림**이며 결과물의 초안이 아닙니다.
> 코드는 사용되지 않고, 실제 구현은 개발 기획 이후 새로 진행됩니다.

이 한 줄이 "만든 걸 왜 안 쓰냐"와 "거의 다 된 거 아니냐"를 미리 막습니다.

### 목업으로 정해지지 않는 것

목업을 아무리 잘 만들어도 아래는 비어 있습니다. 개발 기획에서 정해집니다.

| 보이는 것 (목업이 답함) | 보이지 않는 것 (개발이 정함) |
|---|---|
| 화면 흐름, 버튼 위치, 용어 | 어떤 테이블·API를 쓰는가 |
| 빈 상태, 오류 화면 모양 | 기존 데이터를 어떻게 이관하는가 |
| 입력 항목과 순서 | 동시 수정을 어떻게 막는가 |
| 분기와 조건 | 성능이 버티는가, 무엇이 같이 깨지는가 |

---

## 4. 보내기 전 최종 점검

- [ ] 기획서 내용과 요구사항 내용이 **섞여 있지 않은가** (한 파일이어도 절은 나뉘어야 함)
- [ ] 요구사항이 전부 **판정 가능한 문장**인가 ("잘", "최대한", "유연하게"가 없는가)
- [ ] 위 **여섯 가지**(권한·빈 상태·실패·동시 수정·기존 데이터·양 끝)를 각각 적었는가
- [ ] 목업에 **"요구사항의 그림이다"** 한 줄을 넣었는가
- [ ] 확정된 것과 예시가 **구분되게** 표시돼 있는가
- [ ] **하지 않을 것**을 적었는가
- [ ] 일정을 묻는 시점을 **개발 기획 뒤**로 잡았는가
- [ ] 개발이 돌려줄 **질문 목록을 받을 자리**를 만들어 뒀는가

---

## 5. AI와 작업할 때 주의

- **AI가 뽑은 질문을 그대로 개발에 보내지 않습니다.** 현업이 먼저 답할 수 있는 것과
  개발에 물어야 할 것으로 가른 뒤에 보냅니다
- **AI가 채운 숫자·법령·정책은 반드시 확인합니다.** 요구사항정의서에 들어간 숫자는
  그대로 구현됩니다
- **고객사 이름, 계약 금액, 개인 연락처는 넣지 않습니다.** 역할과 조건만 남겨도
  문서 품질은 거의 그대로입니다
- **목업의 완성도가 높을수록** "요구사항의 그림"이라는 한 줄을 더 분명히 둡니다.
  색과 여백까지 맞은 화면은 손그림과 달리 완성처럼 보입니다