요구사항 정의서 : 작업의 방향성을 정하는 문서

핵심 요약

성공적인 소프트웨어 프로그래밍 프로젝트를 위해서는 추상적인 아이디어를 요구사항 정의서(SRS/PRD)로 체계화하고, 기획 ➔ 설계 ➔ 개발 ➔ 테스트 ➔ 배포/운영의 전체 워크플로우를 관화해야 한다.

프로젝트 성격에 따라 Waterfall과 Agile의 하이브리드(Hybrid) 개발 방법론을 채택해야 하며, 불가피한 요구사항 변경에는 CR(Change Request) 절차와 MVP(최소 기능 제품) 중심의 차수별 업데이트(Bugfix ➔ Update ➔ Fetch) 전략으로 대응하는 것이 가장 현실적이고 성공적인 개발 엔지니어링 패러다임이다.

1. 소프트웨어 개발 6단계 워크플로우와 요구사항 정의서(SRS)

1) 프로그래밍을 위한 6단계 전체 워크플로우

[1. 기획 & 아이디에이션] (Business Goal / Problem Definition)
          │
          ▼
[2. 요구사항 수집 & 정의] (SRS / PRD 작성)  <--- 🔥 성공적인 프로젝트의 핵심 기준점!
          │
          ▼
[3. 아키텍처 & 시스템 설계] (DB ERD, API 명세서, UI/UX 와이어프레임)
          │
          ▼
[4. 개발 & 구현] (Front/Back-end Coding, Git, CI/CD Pipeline)
          │
          ▼
[5. 테스트 & 검수] (QA, Unit/Integration Test, 고객 인수 검수)
          │
          ▼
[6. 배포 & 운영 유지보수] (Deployment, Monitoring, Maintenance)

2) 요구사항 정의서 (SRS: Software Requirements Specification)의 개념과 역할

• 정의: 시스템이 제공해야 할 기능 요구사항(FR)과 품질/성능/보안 등 비기능 요구사항(NFR), 시스템 제약조건(Constraints)을 명확한 언어로 기술한 문서.
• SRS가 결정적으로 중요한 5가지 이유:

1. 프로젝트 범위(Scope) 및 계약의 기준 확정: 무엇을 만들고 만들지 않을지(Out of Scope)를 선명하게 획정.
2. 정확한 비용 및 공수(Man-Month) 추산의 근거.
3. 클라이언트-기획자-개발자 간의 소통 오류(Miscommunication) 사전 예방.
4. 무분별한 요구사항 추가(Scope Creep) 차단 및 추가 견적의 객관적 근거.
5. 최종 QA 테스트 및 고객 인수 검수(Acceptance Test)의 검수 표.

2. 요구사항 문서의 시대적 변화와 개발 방법론 (Waterfall vs Agile vs Hybrid)

1) SRS의 변화 (과거 vs 현재)

2) 애자일(Agile) 만능주의에 대한 비판적 재검토

실무에서 무조건 애자일만 고집하는 것은 심각한 프로젝트 파산을 부를 수 있다.

• 애자일이 실패하는 3가지 대표 사례:

1. 외주 턴키(Fixed Price) 계약: 예산과 기간이 고정된 상태에서 요구사항만 애자일하게 변경하면 개발사의 공수 폭탄 및 분쟁으로 직결됨.
2. 미션 크리티컬 도메인 (금융/의료/항공): 단 한 번의 오류도 용납되지 않는 시스템에서는 사전 Waterfall 방식의 철저한 서류 검증이 필수임.
3. 가짜 애자일 (Agile in Name Only): 기획서/설계서 작성을 게을리하는 핑계로 애자일을 악용하는 현상.

3) 실무 권장: 하이브리드(Hybrid) 개발 전략

프로젝트 성공을 위해서는 계약/예산, 요구사항 명확성, 도메인 리스크, 클라이언트 참여도 4가지 관점을 종합 고려해야 한다.

 
[Phase 1: Waterfall 방식]  --->  초기 계약 범위(Scope), DB 구조, 큰 틀의 SRS 작성 & 견적 확정
          │
          ▼
[Phase 2: Agile 방식]      --->  확정된 범위 안에서 2주 단위 스프린트(Sprint) 기반 기능 개발 및 시연

3. 요구사항 변경 대응 전략 (CR)과 MVP 중심 대안 프로세스

1) 요구사항 변경 관리 프로세스 (CR Process)

요구사항 변경(Change)은 비즈니스 환경상 피할 수 없는 현상이다. 변경 발생 시 감정적 대립 대신 공식적인 CR 절차를 밟아야 한다.

[요구사항 변경 요청 발생]
          │
          ▼
1. 변경 요청서 (CR: Change Request) 작성 (이유, 세부 변경 내용)
          │
          ▼
2. 영향도 분석 (Impact Analysis: 일정 지연, 추가 공수/비용, 아키텍처 리스크 계산)
          │
          ▼
3. 변경 관리 위원회 (CCB / 고객-개발사 합의)
          │
  ┌───────┴───────┐
  ▼               ▼
[승인 (Approved)]  [반려 (Rejected)]
  │               └─> 기존 요구사항 및 스펙 유지
  ▼
4. 계약 변경 / 예산 추가 / Scope Swapping (기능 일대일 교체) ➔ 개발 반영

2) IKIWISI 현상과 MVP (Minimum Viable Product)의 가치

• IKIWISI (I Know It When I See It): 클라이언트는 완성된 화면을 직접 만져보기 전까지 자신이 진짜 원하는 것을 모른다.
• MVP (최소 기능 제품): 핵심 문제(Core Problem)를 해결할 최소한의 필수 기능만 탑재하여 빠르게 출시하는 제품.
• MVP의 효과: 불필요한 기능(Nice-to-have)에 대한 초기 낭비를 방지하고, 실제 사용자 피드백 데이터를 기반으로 합리적인 요구사항 변경 우선순위를 설정할 수 있다.

3) 지속적 제품 진화 방향성: Bugfix ➔ Update ➔ Fetch

[Phase 1: MVP 1차 오픈] ──> [Phase 2: Bugfix & 서비스 안정화] ──> [Phase 3: Update & Feature Fetch]

1. Phase 1: MVP 빠른 오픈: 핵심 기능(상위 20%의 핵심 가치)만 우선 개발하여 1차 출시.
2. Phase 2: Bugfix & 서비스 안정화: 초기 운영 중 발생하는 버그 수정 및 시스템 안정화.
3. Phase 3: Update & Feature Fetch (피처 추가): 사용자가 추가 요구하는 사항을 버림 없이 2차, 3차 고도화 패치(Update/Fetch) 백로그로 이관하여 단계적으로 개발.

4) 요구사항 변경 대응 3대 실무 가이드라인

1. 트레이드 오프 규칙 (Scope Swapping Rule): 예산/기간이 고정된 경우, 신규 기능 A를 추가하는 대신 기존 우선순위가 낮은 기능 B를 제거하는 일대일 교체를 실시.
2. CR 서식을 통한 공수/지연 명확화: 구두 요청은 엄격히 금지하고, 변경으로 인한 추가 공수(Man-Day)와 출시 지연 날짜를 수치로 전달하여 클라이언트의 신중한 결정을 유도.
3. 단계별 차수 개발 (Phased Release): "거절"이 아닌 "1차 MVP 범위 대신 2차 고도화 업데이트 범위로 이관"하여 프로젝트 리스크를 분산.