요구사항 분석 — 범위와 깊이를 잡는 법

"대학 행정 관리 프로그램"처럼 큰 아이디어가 머릿속에 있을 때, 어디서부터 어디까지를 요구사항으로 정의해야 하는지. 핵심은 "뭘 만들지"가 아니라 "뭘 안 만들지"를 정하는 것이다.

요구사항 단계에서 풀어야 하는 문제는 두 가지다: **범위(scope)**가 정해지지 않은 것, 그리고 **깊이(depth)**를 어디까지 파야 할지 모르는 것.

범위를 잡는 법 — MVP 사고방식

전체를 한 번에 설계하려고 하면 안 된다. 대신:

1) 전체를 1분 안에 큰 덩어리로 나열한다. 완벽하지 않아도 된다:

대학 행정 관리 프로그램:
- 시간표 관리
- 수강신청
- 성적/학점 관리
- 학사 일정 관리
- 공지사항/알림

2) 딱 하나만 고른다. 기준은 단순하다: "이것만 있어도 내가 실제로 쓸 건가?"

[v1 — 지금 만든다]          [v2+ — 나중에]
• 시간표 관리               • 수강신청
                           • 성적 관리
                           • 학사 일정
                           • 공지/알림 통합

"나중에" 칸은 존재를 인식하는 것이 목적이다. 설계할 때 "나중에 성적 관리가 붙을 수 있구나"를 머리 한쪽에 두는 거지, 지금 설계하라는 뜻이 아니다.

깊이를 잡는 법 — 3층 분해

고른 기능 하나를 놓고 3층까지만 내려간다.

1층: 사용자 행동 (User Story)

"누가 뭘 한다"의 형태로, 기술 용어 없이 일상어로 쓴다:

- 나는 새 학기가 시작되면 수업들을 시간표에 등록한다
- 나는 수업 시간이 바뀌면 시간표를 수정한다
- 나는 수강 철회하면 시간표에서 삭제한다
- 나는 주간 시간표를 한눈에 보고 싶다
- 나는 수업 시간이 겹치면 알고 싶다
- 나는 다음 수업 10분 전에 알림을 받고 싶다

2층: 기능 그룹 (Feature)

User Story들을 묶어서 이름을 붙인다:

[수업 관리]
  - 수업 등록 (이름, 교수, 시간, 강의실)
  - 수업 수정
  - 수업 삭제

[시간표 시각화]
  - 주간 뷰
  - 시간 충돌 표시

[알림]
  - 수업 시작 전 알림

3층: 경계 조건

각 기능 그룹에서 "이건 포함? 저건 포함?"을 결정하는 질문을 던진다. 이 질문들을 만드는 것 자체가 요구사항 분석이다:

[수업 관리]
  Q: 같은 과목의 분반(001, 002)을 구분하나? → O
  Q: 실습/이론 시간이 따로 있는 수업은? → O
  Q: 비정기 수업(보강, 휴강)도 관리하나? → v2로 미룸

[알림]
  Q: 시스템 알림? 앱 내 알림? → 시스템 트레이
  Q: 앱이 꺼져있을 때도? → X, 실행 중에만
  Q: 알림 시간 설정 가능? (10분 전, 30분 전) → O

답을 다 알 필요는 없다. "v1에서 할래, 나중에 할래"만 정하면 된다.

요구사항과 다른 단계의 경계

머릿속에 떠오르는 조각들이 사실은 각각 다른 설계 단계에 속한다:

떠오르는 조각              →  속하는 단계
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
등록/삭제/수정              →  요구사항 (1층~2층)
학사 행정 데이터 구조        →  도메인 모델링 (②단계)
알림 (interrupt)           →  요구사항 (2층, [알림] 그룹)
대학 행정 전체              →  범위 결정 (v1 vs v2+)

"학사 행정 데이터 구조"처럼 "데이터를 어떻게 관계 짓지?"라는 질문은 도메인 모델링 단계에서 다루는 것이다. 요구사항에서는 어떤 정보가 필요한지만 나열하면 된다:

수업 하나에 필요한 정보:
- 과목명, 과목코드, 교수명, 학점
- 강의 시간 (요일 + 시작~끝, 복수 가능)
- 강의실, 분반 번호

이걸 어떤 테이블로 나눌지, Course와 Lecture를 분리할지는 그다음 단계의 일이다.

실천 도구: 종이 한 장

세 칸으로 나눈 종이 한 장이 요구사항 문서가 된다:

┌─────────────────┬────────────────┬──────────────────┐
│   v1 (지금)     │   경계 질문     │   v2+ (나중에)   │
├─────────────────┼────────────────┼──────────────────┤
│ • 수업 CRUD     │ 분반 구분? → O  │ • 수강신청 연동  │
│ • 주간 뷰       │ 보강 관리? → X  │ • 성적 관리      │
│ • 충돌 검사     │ 앱 꺼져도     │ • 학사 일정      │
│ • 수업 전 알림  │  알림? → X     │ • 친구 시간표    │
│                 │ 여러 학기     │   비교           │
│                 │  관리? → v2    │                  │
└─────────────────┴────────────────┴──────────────────┘

30분이면 쓸 수 있다. 이 한 장을 들고 how-to-design-a-program-from-scratch|다음 단계(도메인 모델링)로 넘어가면 "어떤 개념이 필요하지?"가 훨씬 선명해진다.