[PM] 범위와 요구사항 — 무엇을 만들고 무엇을 안 만드는가

🚨INCIDENT ALERT

HIGH

SI 프로젝트 3개월 차. 개발은 거의 끝나가는데 분위기가 이상합니다.

고객 담당자가 회의 때마다 "그건 당연히 되는 줄 알았는데요?"라고 합니다. 모바일 화면, 엑셀 일괄 업로드, 타 시스템 연동 — 제안서엔 한 줄도 없던 것들입니다. 수행사 PM은 "그건 과업 범위가 아닙니다"라고 답하지만, 고객은 "그럼 처음부터 안 된다고 했어야죠"라며 언짢아합니다.

검수가 다가오자 더 첨예해집니다. 고객은 "느려서 못 쓰겠다"며 인수를 거부하고, 수행사는 "요구사항에 속도 기준이 없었다"고 맞섭니다. 둘 다 틀린 말이 아닙니다 — 애초에 '무엇을, 어디까지, 얼마나 잘' 만들지를 글로 합의하지 않았기 때문입니다.

이 모듈은 그 다툼이 일어나기 전에 막는 법을 다룹니다. 요구사항을 기능·비기능으로 나눠 정의하고, 현행(As-Is)과 목표(To-Be)의 차이(Gap)에서 할 일을 도출하고, 범위를 글로 못 박아 슬금슬금 늘어나는 일(스코프 크리프)을 통제하고, '완료'의 기준을 미리 합의하는 것 — PM의 가장 비기술적이지만 가장 프로젝트를 살리는 일입니다.

이번 챕터에서 배울 것

1기능 요구사항(시스템이 하는 일)과 비기능 요구사항(성능·보안·안정성·호환성)을 구분하고 둘 다 정의해야 하는 이유를 설명할 수 있다
2As-Is/To-Be/Gap 분석으로 현행과 목표의 차이에서 프로젝트의 과업(범위)을 도출할 수 있다
3범위(scope)와 범위 기술서의 역할을 이해하고, 스코프 크리프를 변경요청(CR) 절차로 통제할 수 있다
4요구사항 추적(Traceability)이 왜 필요한지, 요구사항-설계-개발-테스트를 어떻게 연결하는지 설명할 수 있다
5인수기준(Acceptance Criteria)을 요구사항마다 정의해 검수 단계의 다툼을 예방할 수 있다

요구사항 — 기능과 비기능

💡개념

'무엇을 하는가'와 '얼마나 잘 하는가'는 다른 질문이다

프로젝트의 모든 다툼은 결국 한 문장으로 돌아갑니다: "이건 하기로 한 거였나?" 이 질문에 글로 답할 수 있게 만드는 것이 요구사항 정의입니다.

요구사항은 크게 두 종류입니다.

기능 요구사항(Functional Requirement) — 시스템이 무엇을 하는가. "사용자는 주문을 취소할 수 있다", "관리자는 정산 내역을 엑셀로 내려받을 수 있다". 동사로 끝나는, 눈에 보이는 동작입니다.
비기능 요구사항(Non-Functional Requirement) — 그 동작을 얼마나 잘 하는가. 성능(응답 3초 이내), 가용성(월 99.9% 가동), 보안(개인정보 암호화 저장), 호환성(IE 미지원, 모바일 지원), 확장성(동시접속 1천 명). 형용사·부사로 측정되는 품질 속성입니다.

초보 PM이 가장 자주 빠뜨리는 쪽이 비기능입니다. 기능은 고객이 먼저 말해주지만("로그인 되게 해주세요"), 비기능은 말해주지 않습니다("당연히 빠를 줄 알았죠"). 그래서 "되긴 되는데 느려서 못 쓰는" 시스템이 검수에서 터집니다.

구분	묻는 질문	예시	빠뜨리면
기능 요구	시스템이 무엇을 하는가	"엑셀로 주문을 일괄 등록한다"	기능 누락 — 명백히 드러남
비기능: 성능	얼마나 빠른가	"1만 행을 5초 내 처리"	"느려서 못 쓴다" 분쟁
비기능: 보안	얼마나 안전한가	"개인정보 저장 시 암호화"	사고·법규 위반 위험
비기능: 안정성	얼마나 안 멈추는가	"월 가동률 99.9%"	SLA 분쟁
비기능: 호환성	어디서 도는가	"Chrome·모바일 지원"	"내 폰에선 안 돼요"

비기능 요구사항은 측정 가능한 숫자로 적어야 의미가 있습니다. "빨라야 한다"는 요구사항이 아니라 희망사항입니다. "응답 3초 이내(95 퍼센타일)"가 요구사항입니다.

As-Is / To-Be / Gap — 할 일은 '차이'에서 나온다

💡개념

현재와 목표 사이의 거리가 곧 프로젝트의 범위다

요구사항을 어디서 끌어낼까요? 고객 머릿속을 무작정 받아쓰면 빠지고 겹칩니다. 체계적인 방법이 As-Is/To-Be/Gap 분석입니다.

As-Is(현행) — 지금은 어떻게 하고 있는가. "정산을 엑셀로 수기 계산하고, 메일로 공유한다." 현실을 있는 그대로 적습니다.
To-Be(목표) — 끝나면 어떤 모습이어야 하는가. "정산이 시스템에서 자동 계산되고, 담당자에게 알림이 간다."
Gap(차이) — As-Is에서 To-Be로 가려면 무엇을 새로 만들거나 바꿔야 하는가. 이 Gap 목록이 곧 **프로젝트의 과업(범위)**입니다.

핵심은 Gap이 곧 할 일이라는 점입니다. As-Is와 To-Be가 같은 부분은 손댈 필요가 없고, 다른 부분(Gap)만큼만 일이 생깁니다. 그래서 As-Is를 대충 적으면 "이미 되는 줄 알고 안 했는데 안 되던" 사고가 나고, To-Be를 흐릿하게 적으면 끝이 안 보입니다.

As-Is(현행)	To-Be(목표)	Gap(해야 할 일)
엑셀로 수기 정산	시스템 자동 정산	정산 엔진 신규 개발
메일로 결과 공유	시스템 내 알림·대시보드	알림 모듈·대시보드 개발
주문 데이터 수기 입력	쇼핑몰 API 자동 수집	외부 연동 인터페이스 개발
권한 구분 없음	역할별 접근 제어	권한 관리 기능 추가
(없음) 종이 보관	5년치 이력 검색	이력 저장·검색 기능 신규

이 표 하나가 제안 단계와 검수 단계의 분쟁을 동시에 줄입니다. 고객은 "내가 뭘 받게 되는가(To-Be)"를 보고, 수행사는 "내가 뭘 만들면 끝인가(Gap)"를 봅니다. 합의는 이 표 위에서 이뤄집니다.

현행(As-Is)과 목표(To-Be)를 비교해 그 차이(Gap)에서 정산 엔진·알림·연동·권한 같은 개발 과업을 도출하는 흐름을 세 패널로 표현한 다이어그램

그림: 현행과 목표 사이의 차이(Gap)가 곧 프로젝트의 과업 — 제외 항목을 명시하면 추가 요청 시 변경요청의 근거가 된다.

범위와 범위 기술서

💡개념

'안 만드는 것'을 적는 것이 '만드는 것'을 적는 것만큼 중요하다

**범위(Scope)**는 "이 프로젝트가 무엇을 포함하고 무엇을 포함하지 않는가"의 경계선입니다. Gap 분석에서 도출한 과업을 **범위 기술서(Scope Statement)**로 정리합니다. 좋은 범위 기술서에는 세 가지가 있습니다.

포함(In-scope) — 이번에 만드는 것. "정산 자동화, 알림, 권한 관리."
제외(Out-of-scope) — 이번에 안 만드는 것. "모바일 앱, 타 그룹사 연동, 데이터 마이그레이션은 별도 계약." 명시적으로 적습니다.
가정·제약(Assumptions/Constraints) — "고객사가 테스트 데이터를 제공한다", "운영 서버는 고객사 환경에 구축한다."

초보가 가장 놓치는 것이 **제외(Out-of-scope)**입니다. "안 한다고 굳이 적어야 하나?" 싶지만, 적지 않은 항목은 나중에 "당연히 되는 줄 알았다"의 씨앗이 됩니다. 시나리오의 모바일·엑셀·연동이 전부 여기서 터진 것입니다. '안 만드는 것'을 글로 못 박아야, 그것을 요청할 때 "그건 범위 밖이라 변경요청이 필요합니다"라고 근거를 댈 수 있습니다.

범위 기술서는 단순 문서가 아니라 계약의 과업 정의입니다. SI 계약에서 "과업범위(SOW, Statement of Work)"가 곧 이것이며, 정산·검수·추가비용 산정의 기준선이 됩니다.

스코프 크리프 — 범위가 슬금슬금 늘어난다

💡개념

작은 요청이 누적되면 프로젝트가 무너진다

**스코프 크리프(Scope Creep)**는 공식 합의 없이 범위가 조금씩 늘어나는 현상입니다. 한 번에 "기능 10개 더"를 요구하면 누구나 거절하지만, "이 버튼 하나만", "화면 하나만 더"는 거절하기 어렵습니다. 문제는 이런 작은 요청이 누적된다는 것입니다 — 일정·비용·품질이 소리 없이 무너집니다.

스코프 크리프의 흔한 원인:

요구사항이 처음부터 모호했다(무엇이 범위인지 합의가 없음).
"작으니까 그냥 해드리자"는 호의가 절차를 건너뛴다.
제외 항목(Out-of-scope)을 명시하지 않았다.
변경요청(CR) 절차가 없거나, 있어도 지키지 않는다.

대응은 거절이 아니라 통제입니다. 핵심 도구가 변경요청(Change Request, CR) 절차입니다.

추가/변경 요청이 들어오면 일단 모두 CR로 접수합니다(크기 불문).
그 요청의 범위·일정·비용 영향을 산정합니다("A를 넣으면 개발 1주, 검수 3일 추가").
영향을 고객에게 보여주고 의사결정을 받습니다 — 넣을지, 뺄지, 다음 단계로 미룰지.
합의되면 범위 기술서·일정·계약을 갱신하고 반영합니다.

이렇게 하면 고객도 트레이드오프를 보고 결정합니다 — "이 기능을 넣으면 납기가 밀린다"는 사실을 알고도 원하면, 그건 정당한 변경이지 크리프가 아닙니다. PM의 역할은 "안 됩니다"가 아니라 **"되는데, 이만큼의 대가가 듭니다. 결정해 주세요"**입니다.

고객 요구가 들어왔다 — 무엇으로 처리하는가

약속한 기능이 명세대로 동작하지 않는다(버그)오류 수정(하자 보수)계약 범위 내 — 무상 수정, 추가비용 없음

범위 기술서에 있는 기능을 만들어 달라정상 과업원래 할 일 — 일정대로 수행

범위에 없던 새 기능·화면을 추가해 달라변경요청(CR)범위·일정·비용 영향 산정 후 승인받아 반영

'이렇게 운영하고 싶다'는 정책·설정 변경운영 정책 협의개발이 아닐 수 있음 — 설정·매뉴얼로 해결되는지 먼저 판단

'작은 거니까 그냥' 구두로 들어온 추가 요청변경요청(CR)으로 문서화크기 불문 — 누적이 스코프 크리프, 구두 합의 금지

합의된 범위 기준선 위로 '버튼 하나·화면 하나·항목 추가·리포트 하나·연동 살짝' 같은 작은 요청이 계단처럼 누적되어 범위를 초과하는 그래프와, 모호한 요구·"작으니까 그냥"·제외 항목 미명시·CR 절차 미준수라는 흔한 원인, 그리고 접수→영향 산정→고객 결정→갱신·반영으로 이어지는 변경요청(CR) 4단계 통제 흐름을 함께 보여주는 다이어그램

직접 해보기 — 요구사항정의서와 Gap 표 만들기

1요구사항정의 항목표를 작성한다

아래는 '정산 자동화' 프로젝트의 요구사항정의서 일부입니다. 각 항목이 ID·유형·내용·우선순위·인수기준 다섯 칸으로 구성됨에 주목하세요. 빈 행(REQ-004)을 직접 채워 보세요.

TEXT

요구사항정의 항목표 (Requirements Definition)

┌─────────┬──────────┬──────────────────────┬────────┬──────────────────────────────┐
│ ID      │ 유형     │ 내용                 │ 우선   │ 인수기준(Acceptance Criteria)│
├─────────┼──────────┼──────────────────────┼────────┼──────────────────────────────┤
│ REQ-001 │ 기능     │ 엑셀로 주문 일괄 등록│ 필수   │ 1만 행 업로드 시 오류 행을   │
│         │          │                      │        │ 사유와 함께 화면에 표시한다  │
├─────────┼──────────┼──────────────────────┼────────┼──────────────────────────────┤
│ REQ-002 │ 비기능   │ 엑셀 업로드 응답시간 │ 필수   │ 1만 행을 5초 이내 처리       │
│         │ (성능)   │                      │        │ (95 퍼센타일 기준)           │
├─────────┼──────────┼──────────────────────┼────────┼──────────────────────────────┤
│ REQ-003 │ 비기능   │ 개인정보 보호        │ 필수   │ 주문자 연락처는 저장 시      │
│         │ (보안)   │                      │        │ 암호화, 화면에선 마스킹 표시 │
├─────────┼──────────┼──────────────────────┼────────┼──────────────────────────────┤
│ REQ-004 │ 기능     │ 정산 결과 알림       │ 권장   │ (직접 작성해 보세요)         │
└─────────┴──────────┴──────────────────────┴────────┴──────────────────────────────┘

작성 요령: 유형(기능/비기능)을 먼저 정하고, **인수기준은 반드시 '확인 가능한 조건'**으로 적습니다. "알림이 잘 간다"가 아니라 "정산 완료 시 담당자에게 알림이 발송되고, 미수신 시 1회 재발송한다"처럼요.

요구사항 ID · 유형 · 내용 · 우선순위 · 인수기준

2As-Is/To-Be/Gap 표로 과업을 도출한다

같은 프로젝트를 As-Is/To-Be/Gap으로 정리합니다. Gap 칸이 곧 개발 과업이 됨을 확인하세요.

TEXT

As-Is / To-Be / Gap 분석

┌────────────────────────┬──────────────────────────┬────────────────────────────┐
│ As-Is (현행)           │ To-Be (목표)             │ Gap (해야 할 일 = 과업)    │
├────────────────────────┼──────────────────────────┼────────────────────────────┤
│ 엑셀 수기 정산         │ 시스템 자동 정산         │ 정산 엔진 신규 개발        │
│ 메일로 결과 공유       │ 시스템 알림·대시보드     │ 알림 모듈·대시보드 개발    │
│ 주문 데이터 수기 입력  │ 쇼핑몰 API 자동 수집     │ 외부 연동 인터페이스 개발  │
│ 권한 구분 없음         │ 역할별 접근 제어         │ 권한 관리 기능 추가        │
│ (모바일 사용 안 함)    │ (이번 범위 아님)         │ ── 제외(Out-of-scope) ──   │
└────────────────────────┴──────────────────────────┴────────────────────────────┘

마지막 행처럼 '제외'를 명시적으로 적는 습관을 들이세요. 모바일은 이번에 안 한다는 것을 표 안에 박아두면, 나중에 "모바일도 되게 해주세요"가 왔을 때 "그건 범위 밖이라 변경요청으로 처리합니다"라는 근거가 됩니다.

현행 → 목표 → 차이(할 일)

🔍실행 후 확인할 것

REQ-004 인수기준 예시: "정산 완료 시 담당자에게 시스템 알림이 발송되고, 미수신 시 1회 재발송한다" — 확인 가능한 조건으로 적었는지
모든 비기능 요구사항(REQ-002, 003)이 측정 가능한 숫자·조건을 가졌는지("빠르게"가 아니라 "5초 이내")
우선순위(필수/권장/선택)가 매겨져 있어, 일정이 부족할 때 무엇을 먼저 포기할지 판단 가능한지
As-Is/To-Be/Gap에서 Gap 칸의 항목들이 그대로 개발 과업 목록과 일치하는지
제외(Out-of-scope) 항목이 표 안에 명시되어 있어, 나중에 추가 요청 시 변경요청 근거가 되는지
핵심 감각: 요구사항정의서와 Gap 표는 "나중에 누가 됐다/안 됐다 다툴 때 펴 보는 합의 문서"다 — 그래서 모호하면 안 된다

요구사항 추적 — 빠짐과 군더더기를 잡는다

💡개념

요구사항 하나가 끝까지 살아 있는지 추적한다

요구사항을 잘 정의해도, 개발·테스트로 가는 동안 하나가 슬쩍 누락되거나 요구에 없던 기능이 만들어지기도 합니다. 이를 잡는 장치가 요구사항 추적(Traceability), 그 도구가 **요구사항 추적 매트릭스(RTM, Requirements Traceability Matrix)**입니다.

RTM은 요구사항 하나하나가 **설계 → 개발 → 테스트(검수)**의 어느 산출물과 연결되는지를 표로 잇습니다.

요구사항 ID	설계 문서	구현(모듈)	테스트 케이스	상태
REQ-001	화면설계서 §3.1	주문업로드 모듈	TC-011, TC-012	완료
REQ-002	성능설계 §2	업로드 배치	TC-021(부하)	진행
REQ-003	보안설계 §4	암호화 컴포넌트	TC-031	완료
REQ-004	알림설계 §5	알림 모듈	(미작성)	미착수

이 표가 주는 것은 두 방향의 점검입니다.

누락 방지(요구 → 구현): 모든 요구사항이 구현·테스트로 이어졌는가? REQ-004는 테스트 케이스가 비어 있으니 검수 전에 잡아야 합니다.
군더더기 방지(구현 → 요구): 만들어진 기능이 어떤 요구사항에서 나왔는가? 출처 없는 기능은 누군가의 '서비스' 또는 스코프 크리프의 흔적입니다.

RTM은 검수 단계의 든든한 무기이기도 합니다. 고객이 "이게 다 된 거냐"고 물으면, 요구사항-테스트가 1:1로 연결되고 모두 '완료'인 RTM을 보여주는 것이 가장 강력한 답입니다.

현장에서 자주 보는 함정

증상: 개발은 다 끝났다는데 검수가 통과되지 않습니다. 고객은 "이건 우리가 기대한 게 아니다", "느려서 못 쓴다"고 하고, 수행사는 "요구사항대로 다 만들었다"고 맞섭니다. 회의가 감정 싸움으로 번지고 정산이 지연됩니다.

원인: '완료'의 기준이 사람마다 머릿속에 다르게 있었습니다. 요구사항을 "정산 알림 기능"처럼 한 줄로만 적어두면, 고객은 "실시간 푸시"를 상상하고 수행사는 "일배치 메일"을 만듭니다. 둘 다 '알림'이지만 같은 것이 아닙니다. 비기능(속도·가용성)을 안 적어두면 "느리다"는 주관적 불만에 반박할 근거조차 없습니다.

해결 방향(이 모듈에서 다룬 것):

요구사항마다 인수기준(Acceptance Criteria)을 미리 합의한다 — "1만 행을 5초 내 처리하고 오류 행을 표시한다"처럼 확인 가능한 조건으로.
비기능 요구사항을 측정 가능한 숫자로 적는다 — "빠르게"가 아니라 "응답 3초 이내(95 퍼센타일)".
RTM으로 요구사항-테스트를 1:1 연결해, 검수를 '주관적 판단'이 아니라 '기준 충족 확인'으로 만든다.
추가 요청은 모두 변경요청(CR)으로 문서화해, 범위 밖 기대가 검수에 섞여 들어오지 않게 한다.

검수에서 다투지 않는 비결은 검수를 잘하는 게 아니라, 착수 단계에서 '완료'를 미리 글로 합의해 두는 것입니다. 다툼은 항상 모호함에서 시작됩니다.

💼

실무 맥락

현업 패턴

한국 SI/SM 현장에서 PM·PMO의 하루는 "이 요구가 우리 일인가 아닌가"를 판단하는 일로 채워집니다. 고객 담당자가 메신저로 "이것 좀 해주세요"를 보낼 때, 당신은 즉답하기 전에 네 가지로 분류해야 합니다.

기능 추가인가 — 범위 기술서·요구사항정의서에 없는 새 기능·화면이면, "되는데 일정·비용 영향이 있습니다"라며 **변경요청(CR)**으로 받습니다. 절대 구두로 "네 해드릴게요" 하지 않습니다.
오류 수정인가 — 약속한 기능이 명세대로 안 도는 것(버그)이면 계약 범위 내 하자 보수입니다. 무상으로 즉시 처리해야 하며, 이걸 CR로 떠넘기면 신뢰를 잃습니다.
운영 정책인가 — "이렇게 운영하고 싶다"는 설정·정책 변경이면, 개발이 아니라 설정·매뉴얼·운영 협의로 풀리는 경우가 많습니다. 개발 과업으로 키우기 전에 먼저 확인합니다.
계약 범위 안인가 — 위 판단의 기준은 결국 과업범위(SOW)와 요구사항정의서입니다. 그래서 이 문서들을 모호하게 써두면 매번 감정 싸움이 되고, 명확히 써두면 "문서를 함께 봅시다"로 차분히 정리됩니다.

기술을 아는 PM이 강한 이유가 여기 있습니다 — 협력사 엔지니어가 "그건 큰 작업입니다/금방 됩니다"라고 할 때, 그 말이 맞는지 가늠하고 영향을 산정할 수 있어야 변경요청을 제대로 통제하고, 잘못된 보고에 속지 않습니다. 범위와 요구사항을 글로 다스리는 능력이, 발주사와 협력사 사이에서 프로젝트를 지키는 PM의 핵심 무기입니다.

관련 모듈로 더 깊이:

WBS와 일정 관리 — 확정한 범위를 작업분해구조로 쪼개 일정·책임으로 연결하는 법
품질과 검수 — 요구사항의 완료(검수) 기준을 인수 조건으로 고정하는 법
요구사항정의서·검수확인서·릴리즈노트·SLA 리포트 — 요구사항정의서·검수 기준 산출물을 실제로 작성하는 법

다음 모듈에서는 이렇게 확정한 범위(과업)를 실제로 '언제 누가 무엇을' 할지로 쪼개는 법 — 작업분해구조(WBS)와 일정 관리를 다룹니다.