기획자가 개발팀에 전달합니다. "알림 기능 좀 넣어주세요." 개발자가 되묻습니다. "어떤 이벤트에? 푸시예요 이메일이에요? 실패하면 재시도하나요? 사용자가 끌 수 있어야 하나요?" 한 줄짜리 요청이 열 개의 질문으로 돌아옵니다. 이 질문들에 답이 없으면 개발은 추측으로 만들고, 결과물은 기대와 어긋나며, 재작업이 발생합니다. 요구사항 정의는 '하고 싶은 것'을 '만들 수 있는 것'으로 번역하는 작업입니다. 이 번역이 부실하면 [[sdlc-overview]]의 모든 뒷 단계가 흔들립니다.
- 1PRD의 핵심 구성요소(배경·목표·범위·요구·성공지표)를 설명할 수 있다
- 2유저스토리를 "역할·목표·가치" 형식으로 작성할 수 있다
- 3인수 기준(AC)으로 정상·예외·경계 조건을 명시해 모호함을 없앨 수 있다
- 4비기능 요구(성능·가용성·보안)를 식별해 인프라 설계와 연결할 수 있다
PRD — 무엇을 왜 만드는가의 합의서
PRD: 모두가 같은 그림을 보게 하는 문서
PRD(Product Requirements Document)는 "이 제품/기능이 무엇을 왜 하는지"를 이해관계자가 합의하는 문서입니다. 형식은 조직마다 다르지만 핵심 골격은 공통입니다.
1. 배경/문제 — 어떤 문제를 푸는가, 왜 지금
2. 목표/성공지표 — 무엇을 달성하면 성공인가(측정 가능하게)
3. 사용자/시나리오 — 누가 어떤 상황에서 쓰나
4. 요구사항 — 기능 요구(유저스토리) + 비기능 요구(NFR)
5. 범위/Out of Scope — 이번에 할 것 / 안 할 것
6. 의존성/리스크 — 외부 연동, 제약, 가정
PM 관점: PRD는 '명령서'가 아니라 '합의서'입니다. 개발·디자인·인프라가 함께 읽고 빈틈(모호함·누락된 예외·비현실적 가정)을 미리 메웁니다. 인프라 관점: 4번의 NFR과 6번의 의존성이 곧 인프라 준비물의 근거입니다.
유저스토리와 인수 기준
역할·목표·가치, 그리고 '완료'의 정의
요구사항을 '기능 제목'이 아니라 사용자 가치로 적으면 개발팀이 '왜'를 잃지 않습니다.
유저스토리:
"구매자로서, 주문 상태 변경 시 알림을 받고 싶다,
왜냐하면 배송 진행을 일일이 확인하지 않아도 되기 때문이다."
인수 기준(Given-When-Then):
- Given 주문이 '배송 시작'으로 바뀌면
When 사용자가 알림을 켜 둔 상태에서
Then 푸시 알림이 1분 이내 발송된다
- 예외: 알림을 끈 사용자에게는 발송하지 않는다
- 예외: 발송 실패 시 3회까지 재시도, 그래도 실패면 로그 기록
- 경계: 동일 상태 변경이 중복 발생해도 알림은 1건만
인수 기준이 정상 흐름만 적고 예외·경계(끈 사용자, 발송 실패, 중복)를 빠뜨리면, 그 빈틈이 [[sdlc-overview]]에서 본 것처럼 뒤 단계에서 비싸게 터집니다. "완료의 정의(DoD)"를 AC로 못 박는 것이 핵심입니다.
모호한 요청을 요구사항으로 — 직접 변환
"알림 기능 넣어주세요" 같은 한 줄을 개발 가능한 형태로 분해합니다. 코드를 몰라도 PM·기획이 하는 핵심 작업입니다.
원본 요청: "알림 기능 좀 넣어주세요"
분해:
역할/목표/가치 →
"구매자로서 주문 상태 변경 알림을 받고 싶다(배송 확인 수고를 덜기 위해)"
채널/조건 → 푸시? 이메일? 어떤 이벤트에?
인수 기준 →
[정상] 배송 시작 시 1분 내 푸시
[예외] 알림 OFF 사용자 제외 / 발송 실패 3회 재시도
[경계] 중복 이벤트 시 1건만
비기능(NFR) → 발송 지연 p95 < 5초, 일 100만건 처리
Out of Scope → 이번엔 푸시만(이메일·SMS는 다음 단계)
echo '요청 → 역할/목표/가치 + AC(정상·예외·경계)'- 유저스토리에 "왜(가치)"가 있는지 먼저 본다 — 없으면 개발이 목적 모르고 구현 → 엉뚱한 해법 위험. "so that ~"을 반드시 채운다
- 인수 기준에 예외·경계가 있는지 확인 — 정상 흐름만 있으면 "데모는 되는데 운영서 터지는" 전형. 실패·중복·빈값 케이스를 명시
- NFR(성능·처리량·가용성)이 적혀 있으면 인프라 설계 근거가 된다 — "일 100만건"이면 큐·스케일 설계로 이어짐. 비어 있으면 인프라가 추측하게 됨
- Out of Scope가 비어 있으면 scope creep 위험 신호 — "이번에 안 하는 것"을 한 줄이라도 못 박아 기대를 정렬한다
상황: 알림 기능을 정상 흐름만 정의해 출시했더니, 운영에서 "같은 알림이 두 번 온다", "껐는데도 온다", "발송이 실패하면 영영 안 온다" 같은 클레임이 쏟아집니다.
원인: 인수 기준이 정상 케이스만 담고 예외·경계(중복 이벤트, 수신거부, 발송 실패 재시도)를 빠뜨렸습니다. 개발은 명시되지 않은 것을 구현하지 않으므로, 빈틈이 그대로 버그가 됐습니다.
진단 — 요구사항 점검 체크:
□ 실패하면? (재시도 횟수·최종 실패 처리)
□ 중복으로 들어오면? (멱등성 — 1건만)
□ 사용자가 거부하면? (수신거부 존중)
□ 빈 값/경계값은? (0건, 최대치)
해결: 모든 유저스토리에 예외·경계를 포함한 AC를 요구합니다. 특히 알림·결제처럼 외부로 나가거나 돈이 걸린 기능은 멱등성(중복 방지)과 실패 재시도를 필수 항목으로 둡니다. 이는 [[async-event-driven]]에서 다루는 메시지 처리 설계와도 직결됩니다.
인프라/SRE로서 PRD 리뷰에 참여하면, 당신이 가장 집요하게 봐야 할 곳은 비기능 요구(NFR)와 의존성입니다. "일 100만 건 알림"이라는 한 줄이 메시지 큐·워커 스케일·DB 부하 설계를 결정하고, "외부 결제사 연동"이라는 의존성이 아웃바운드 방화벽·키 관리·장애 격리 설계로 이어집니다. NFR이 비어 있으면 그 자리에서 "목표 처리량과 응답시간이 어떻게 되나요?"를 물어 채워 넣어야 합니다 — 이 질문 하나가 출시 후의 새벽 장애를 막습니다. PM은 AC를 게이트로 삼아 QA·개발과 '완료'의 정의를 공유합니다.
다음 모듈에서는 이렇게 정의한 요구사항들의 우선순위를 어떻게 매기고 규모를 추정하는지를 다룹니다.