기획자가 개발팀에 전달합니다. "알림 기능 좀 넣어주세요." 개발자가 되묻습니다. "어떤 이벤트에? 푸시예요 이메일이에요? 실패하면 재시도하나요? 사용자가 끌 수 있어야 하나요?" 한 줄짜리 요청이 열 개의 질문으로 돌아옵니다. 이 질문들에 답이 없으면 개발은 추측으로 만들고, 결과물은 기대와 어긋나며, 재작업이 발생합니다. 요구사항 정의는 '하고 싶은 것'을 '만들 수 있는 것'으로 번역하는 작업입니다. 이 번역이 부실하면 SDLC의 모든 뒷 단계가 흔들립니다.
- 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번의 의존성이 곧 인프라 준비물의 근거입니다.
확대
위 그림처럼 PRD는 배경/문제 정의부터 유저스토리·인수기준·NFR·스코프아웃까지 5개 섹션으로 모호함을 제거합니다.
유저스토리와 인수 기준
역할·목표·가치, 그리고 '완료'의 정의
요구사항을 '기능 제목'이 아니라 사용자 가치로 적으면 개발팀이 '왜'를 잃지 않습니다.
유저스토리:
"구매자로서, 주문 상태 변경 시 알림을 받고 싶다,
왜냐하면 배송 진행을 일일이 확인하지 않아도 되기 때문이다."
인수 기준(Given-When-Then):
- Given 주문이 '배송 시작'으로 바뀌면
When 사용자가 알림을 켜 둔 상태에서
Then 푸시 알림이 1분 이내 발송된다
- 예외: 알림을 끈 사용자에게는 발송하지 않는다
- 예외: 발송 실패 시 3회까지 재시도, 그래도 실패면 로그 기록
- 경계: 동일 상태 변경이 중복 발생해도 알림은 1건만
인수 기준이 정상 흐름만 적고 예외·경계(끈 사용자, 발송 실패, 중복)를 빠뜨리면, 그 빈틈이 SDLC에서 본 것처럼 뒤 단계에서 비싸게 터집니다. "완료의 정의(DoD)"를 AC로 못 박는 것이 핵심입니다.
확대
위 그림처럼 유저스토리는 역할·목표·가치(As a / I want / So that)로 사용자 중심 요구를 담고, 인수 기준은 Given-When-Then으로 완료 조건을 명확히 하며 예외·경계 케이스까지 포함합니다.
모호한 요청을 요구사항으로 — 직접 변환
"알림 기능 넣어주세요" 같은 한 줄을 개발 가능한 형태로 분해합니다. 코드를 몰라도 PM·기획이 하는 핵심 작업입니다.
원본 요청: "알림 기능 좀 넣어주세요"
분해:
역할/목표/가치 →
"구매자로서 주문 상태 변경 알림을 받고 싶다(배송 확인 수고를 덜기 위해)"
채널/조건 → 푸시? 이메일? 어떤 이벤트에?
인수 기준 →
[정상] 배송 시작 시 1분 내 푸시
[예외] 알림 OFF 사용자 제외 / 발송 실패 3회 재시도
[경계] 중복 이벤트 시 1건만
비기능(NFR) → 발송 지연 p95 < 5초, 일 100만건 처리
Out of Scope → 이번엔 푸시만(이메일·SMS는 다음 단계)
echo '요청 → 역할/목표/가치 + AC(정상·예외·경계)'- 유저스토리에 "왜(가치)"가 있는지 먼저 본다 — 없으면 개발이 목적 모르고 구현 → 엉뚱한 해법 위험. "so that ~"을 반드시 채운다
- 인수 기준에 예외·경계가 있는지 확인 — 정상 흐름만 있으면 "데모는 되는데 운영서 터지는" 전형. 실패·중복·빈값 케이스를 명시
- NFR(성능·처리량·가용성)이 적혀 있으면 인프라 설계 근거가 된다 — "일 100만건"이면 큐·스케일 설계로 이어짐. 비어 있으면 인프라가 추측하게 됨
- Out of Scope가 비어 있으면 scope creep 위험 신호 — "이번에 안 하는 것"을 한 줄이라도 못 박아 기대를 정렬한다
확대
위 그림처럼 기능 요구사항(무엇을)은 사용자가 할 수 있는 것을, 비기능 요구사항(얼마나 잘)은 성능·가용성·보안·확장성 등 품질 기준을 담습니다. NFR이 빠진 PRD는 절반짜리입니다.
상황: 알림 기능을 정상 흐름만 정의해 출시했더니, 운영에서 "같은 알림이 두 번 온다", "껐는데도 온다", "발송이 실패하면 영영 안 온다" 같은 클레임이 쏟아집니다.
원인: 인수 기준이 정상 케이스만 담고 예외·경계(중복 이벤트, 수신거부, 발송 실패 재시도)를 빠뜨렸습니다. 개발은 명시되지 않은 것을 구현하지 않으므로, 빈틈이 그대로 버그가 됐습니다.
진단 — 요구사항 점검 체크:
□ 실패하면? (재시도 횟수·최종 실패 처리)
□ 중복으로 들어오면? (멱등성 — 1건만)
□ 사용자가 거부하면? (수신거부 존중)
□ 빈 값/경계값은? (0건, 최대치)
해결: 모든 유저스토리에 예외·경계를 포함한 AC를 요구합니다. 특히 알림·결제처럼 외부로 나가거나 돈이 걸린 기능은 멱등성(중복 방지)과 실패 재시도를 필수 항목으로 둡니다. 이는 동기 vs 비동기에서 다루는 메시지 처리 설계와도 직결됩니다.
심화 — 좋은 형식이 좋은 요구사항을 보장하지 않는다
심화: 요구로 위장한 해법, 아무도 안 읽는 PRD — 문서가 죽는 경로
유저스토리·AC·NFR의 형식을 갖추는 법을 배웠다면, 다음 관문은 형식이 갖춰졌는데도 요구사항이 실패하는 경우들입니다. 현장에서 PRD가 무너지는 경로는 대체로 네 가지입니다.
- 요구로 위장한 해법: "엑셀 다운로드 버튼을 만들어주세요"는 요구가 아니라 해법입니다. 진짜 요구를 파 보면 "월말 정산 데이터를 회계 시스템에 옮기고 싶다"일 수 있고, 그렇다면 맞는 답은 다운로드가 아니라 연동일 수 있습니다. 요청이 UI나 기술을 지정해서 오면 "그걸로 무엇을 하시려고요?"를 한 번 되묻는 것이 가장 값싼 설계 검토입니다 — 유저스토리의 'so that'이 비어 있는 요청일수록 이 함정일 확률이 높습니다.
- 상세도는 조직에 따라 다르다: 한 사무실의 5인 팀은 1페이지 PRD와 대화로 충분하지만, 외주 계약·규제 도메인·시차가 있는 원격 조직은 두꺼운 명세가 필요합니다. 기준은 '문서 없이 어긋났을 때의 복구 비용'입니다 — 소통 거리가 가까울수록 얇게, 핸드오프가 멀수록 두껍게. 모든 팀에 같은 템플릿을 강제하는 것이 오히려 안티패턴입니다.
- PRD가 죽는 순간: 개발 중의 결정이 슬랙·회의에서 이뤄지는데 PRD에 반영되지 않으면, 몇 주 뒤 PRD는 '틀린 문서'가 되고 아무도 열지 않습니다. 죽었다는 신호는 명확합니다 — QA가 테스트 기준을 문서가 아니라 개발자에게 물어보기 시작할 때입니다. 처방은 '문서와 다르게 결정하면 그 자리에서 문서를 고친다'를 결정의 완료 조건으로 삼고, PRD에 변경 이력 섹션을 두는 것입니다.
- 회람은 합의가 아니다: PRD 링크를 뿌리고 코멘트가 없다고 합의로 치면, 출시 직전에 "나는 그렇게 이해하지 않았다"가 나옵니다. 침묵은 동의가 아니라 대부분 '안 읽음'입니다. 핵심 이해관계자에게는 리뷰 자리에서 자기 말로 요약하게 하거나 섹션별 명시적 승인을 받아야, 합의가 실재하게 됩니다.
정리하면 PRD의 성패는 템플릿이 아니라 운영에 달렸습니다 — 되묻는 습관, 조직에 맞는 두께, 갱신 규칙, 명시적 합의. 이 네 가지가 없는 PRD는 형식이 완벽해도 어긋남을 막지 못합니다.
상황: 개발 중반, 슬랙 스레드에서 기획·개발이 "알림 발송 조건을 A안에서 B안으로 바꾸자"고 합의했습니다. PRD는 갱신되지 않았습니다. QA는 PRD 기준으로 테스트 케이스를 작성했고, 릴리스 전 주에 "B로 동작함 = 스펙 위반" 버그 17건을 등록합니다. 개발은 "합의대로 만들었다", QA는 "문서대로 검증했다", 기획은 "바꾼 게 맞는데 왜 버그냐" — 사흘간 논쟁이 이어지고 출시가 1주 연기됩니다.
원인: 결정 채널(슬랙)과 기준 문서(PRD)가 분리된 채 문서 갱신이 누구의 책임도 아니었습니다. 그 결과 팀 안에 '스펙'이 두 벌 존재하게 됐고, QA는 낡은 쪽을 단일 진실로 삼아 성실하게 일했습니다. 개인의 실수가 아니라, 결정이 문서에 도달하는 경로가 없는 구조의 문제입니다.
진단: 등록된 버그 17건을 분류합니다 — 실제 결함 3건, 나머지 14건은 '문서가 낡아서 생긴 스펙 불일치'였습니다. 이 비율이 진단의 핵심입니다: 버그의 다수가 코드가 아니라 문서 쪽 문제라면, 품질 이슈가 아니라 합의 관리 이슈입니다. 슬랙에서 해당 결정 스레드를 찾아 결정 시점과 PRD 최종 수정일의 간격을 확인하면 확정됩니다.
해결: 스펙 불일치 14건은 PRD를 B안으로 갱신하며 일괄 종료하고, 실결함 3건만 수정합니다. 재발 방지로 ① '스펙 변경 결정 = PRD 갱신까지가 완료'를 팀 규칙으로 못 박고, 결정 스레드에 PRD 수정 링크가 달려야 종료로 칩니다 ② PRD에 변경 이력(날짜·내용·결정 링크) 섹션을 둡니다 ③ QA 테스트 케이스에 '기준 PRD 버전'을 명시해, 문서가 낡으면 즉시 드러나게 합니다. 문서는 쓰는 순간이 아니라 갱신이 멈추는 순간 죽습니다.
인프라/SRE로서 PRD 리뷰에 참여하면, 당신이 가장 집요하게 봐야 할 곳은 비기능 요구(NFR)와 의존성입니다. "일 100만 건 알림"이라는 한 줄이 메시지 큐·워커 스케일·DB 부하 설계를 결정하고, "외부 결제사 연동"이라는 의존성이 아웃바운드 방화벽·키 관리·장애 격리 설계로 이어집니다. NFR이 비어 있으면 그 자리에서 "목표 처리량과 응답시간이 어떻게 되나요?"를 물어 채워 넣어야 합니다 — 이 질문 하나가 출시 후의 새벽 장애를 막습니다. PM은 AC를 게이트로 삼아 QA·개발과 '완료'의 정의를 공유합니다.
다음 모듈에서는 이렇게 정의한 요구사항들의 우선순위를 어떻게 매기고 규모를 추정하는지를 다룹니다.
실전 랩으로 손에 익히기: 요구사항 정의 실습 — 모호한 요구를 유저스토리·인수기준(Given-When-Then)으로 다듬습니다.
관련 모듈로 더 깊이:
- 추정과 우선순위 — 정의한 요구사항의 우선순위·규모를 정하는 법
- 로드맵과 이슈 트래킹 — 요구사항을 로드맵·이슈로 풀어 추적하는 법
- API와 계약 — 요구사항을 시스템 간 합의(API 계약)로 구체화하기