Requirements Elicitation Physics

1. Overview

요구사항 도출의 물리학(Requirements Elicitation Physics)은 고객의 머릿속에 파편화되어 있는, 심지어 본인조차 정확히 모르는 파편적인 욕망들을 끄집어내어 엔지니어링이 가능한 명제로 조립해 내는 소통과 갈등 해결의 심리전을 해부합니다.

학습자는 회의실에 앉아 고객이 불러주는 대로 받아 적는 앵무새 같은 '요구사항 수집(Gathering)'의 한계를 박살 내고, 5-Whys와 프로토타이핑(Prototyping)으로 고객의 진짜 고통을 발굴해 내는 능동적 **도출(Elicitation)**을 뜯어봅니다. 나아가 마케팅 팀은 "무조건 화려하게!", 보안 팀은 "무조건 접근 차단!"을 외치는 **이해관계자 충돌(Conflicting Requirements)**을 조율합니다. 마지막으로, 모든 걸 다 해달라는 고객의 탐욕을 통제하기 위해, 이번 릴리즈에서 버려야 할 것들을 칼같이 쳐내는 MoSCoW 우선순위 매기기 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Elicitation Techniques: 인터뷰, 설문조사, 섀도잉(Shadowing), JAD(Joint Application Design) 워크숍, 프로토타이핑.
• Conflict Resolution: 서로 다른 이해관계자(Stakeholders) 간의 상충하는 요구사항 조율(Win-Win 협상, 시스템 한계 증명).
• Prioritization (MoSCoW): Must have, Should have, Could have, Won't have 기반의 기능 잘라내기(Scope Management).
• The 5-Whys: 표면적 솔루션 요구에서 근본 원인(Root Cause)으로 파고드는 심층 질의 기법.

Out-of-Scope

• 요구사항 문서화 및 스펙 작성: 도출된 요구사항을 SRS(명세서) 문서나 유저 스토리로 예쁘게 적어내는 기술 $\rightarrow$ 09-02-02 SRS Engineering 영역으로 분리.
• 시스템 아키텍처 타당성 검토: 요구사항이 기술적으로 가능한지 벤치마킹하는 엔지니어링 딥다이브 $\rightarrow$ 09-03 Architecture & Design 영역으로 위임.

Boundaries

• 수집(Gathering) vs 도출(Elicitation): 수집은 땅에 떨어진 밤을 주워 담는 것입니다. 고객이 이미 답을 안다고 가정하는 치명적 오만입니다. 도출은 진흙 속에 파묻힌 다이아몬드를 캐내고 깎는 것입니다. 고객의 말은 모순투성이에 불완전하므로, 프로토타입과 인터뷰를 통해 "당신이 진짜 원하는 건 이게 맞습니까?"를 역으로 찔러 검증하는 '엔지니어 주도의 탐색'이라는 점에 명확한 선을 긋습니다.

3. Counterexample

• 앵무새 개발자의 최후: 고객이 "화면에 버튼을 누르면 엑셀이 다운로드되게 해주세요"라고 말했습니다. 개발자는 2주 동안 엑셀 생성 라이브러리를 붙여 완벽한 다운로드 기능을 만들었습니다. 납품 날, 고객은 다운받은 엑셀을 열더니 한숨을 쉬며 숫자를 복사해 다른 시스템에 수동으로 붙여넣기 시작합니다. 왜 엑셀이 필요한지(Why) 묻지 않은 탓에, 두 시스템을 API로 자동 연동하면 끝날 일을 엑셀이라는 '고객의 얄팍한 솔루션'에 끌려가 버린 도출 실패의 재앙입니다.
• 모두 만족시키려다 터진 짬짜면: 신규 시스템 구축 회의. 세일즈 팀은 "결제 단계를 최소화(1-Click)해달라"고 하고, 보안 팀은 "결제 시 2FA(투팩터) 인증과 공인인증서를 강제하라"고 요구했습니다. 개발자는 둘 다 만족시키려다 1-Click 버튼을 누르면 갑자기 보안 앱이 3개 깔리는 끔찍한 괴물(Frankenstein)을 만들었습니다. 상충하는 요구사항(Conflict)을 도출 단계에서 스폰서(결정권자)를 통해 조율(Trade-off)하지 않고, 코드 레벨로 끌고 내려간 요구사항 공학의 붕괴입니다.

4. Prerequisites

• What vs How (Basic): 요구사항과 설계의 분리 철학. (09-01-02 Req Engineering)
• 소통과 협업 (Basic): 고객 및 이해관계자와의 기본적인 비즈니스 커뮤니케이션.

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 수집의 신화 박살 내기 (The Myth of Gathering)

• Why to Learn: "요구사항 명세서 좀 주세요, 그대로 짜드릴게요"라는 마인드가 소프트웨어 프로젝트 실패 원인 1위임을 깨닫고, 셜록 홈즈처럼 숨겨진 진짜 니즈를 추적하는 집요함을 장악하기 위함입니다.
• What to Learn:
  • Concepts: Elicitation vs Gathering, The 5-Whys, Tacit Knowledge (암묵지), Root Cause Analysis.
  • Skills: "관리자 페이지 로딩 속도를 1초 이하로 줄여주세요"라는 껍데기 요구에 5-Whys 기법을 적용하여, "아르바이트생이 하루 1만 건의 송장 번호를 입력해야 해서 너무 바쁘다"는 진짜 고통(Root Cause)을 도출하기.
• How to Learn:
  • 1단계: 수집의 함정 (Gathering): 사과나무 밑에서 사과가 떨어지길 기다립니다. 고객이 주는 문서에는 "화면을 파란색으로 해주세요", "데이터를 엑셀로 주세요" 같은 '솔루션(How)'만 적혀있습니다.
  • 2단계: 5번의 왜? (5-Whys): 고객에게 질문을 던집니다. "왜 엑셀이 필요하죠?" $\rightarrow$ "옆 팀에 데이터를 보내야 하거든요." $\rightarrow$ "왜 옆 팀에 데이터를 보내죠?" $\rightarrow$ "월말 정산을 해야 하니까요." 아하! 고객이 진짜 원했던 건 '월말 정산 자동화(What)'였습니다. 고객의 뇌 속에 무의식적으로 깔려있어 말하지 않는 지식(암묵지)을 집요한 질문으로 멱살 잡고 끌어올리는 도출의 예술을 해부합니다.
• Implement: 5-Whys 챗봇 시뮬레이션. Client: "검색창에 자동완성 기능 넣어줘." Dev: "그 기능이 왜 필요하죠?" Client: "유저들이 검색을 너무 오래 해." Dev: "왜 오래 하죠?" Client: "상품명이 영어랑 숫자가 섞여서 타자 치기 빡세." $\rightarrow$ Solution 도출: 무거운 자동완성 엔진(Elasticsearch) 도입 대신, 상품에 바코드를 달고 앱에 바코드 스캐너 기능을 넣는 것으로 방향을 180도 선회하는 극적인 타임라인 렌더링.

Recommended

Core Topic 02: 팩트 폭행의 도구들 (Elicitation Toolkit)

• Why to Learn: 입으로 백날 떠들어봤자 각자의 머릿속에 그리는 그림이 다르다는 인지적 간극을 인정하고, 프로토타입이나 워크숍을 통해 눈에 보이는 실체로 요구사항의 핀트를 맞추기 위함입니다.
• What to Learn:
  • Concepts: Prototyping (Throwaway vs Evolutionary), JAD (Joint Application Design), Shadowing (Observation), Storyboarding.
  • Skills: 요구사항이 극도로 모호할 때 개발을 멈추고 칠판이나 피그마(Figma)로 버리는 프로토타입(Throwaway Prototype)을 1시간 만에 그려서 고객의 피드백("이게 아니야!")을 즉각 유도하기.
• How to Learn:
  • 1단계: 합숙 회의 (JAD): 이메일로 핑퐁하면 한 달 걸립니다. 기획자, 개발자, DBA, 고객을 모두 회의실에 가두고 피자가 식기 전에(JAD 워크숍) 아키텍처 스케치와 UI 흐름을 끝장 토론으로 합의 봅니다.
  • 2단계: 버리는 프로토타입 (Throwaway): 고객은 말로 설명할 때는 자기가 뭘 원하는지 모릅니다. 하지만 눈앞에 구린 UI를 보여주면 "여기 이거 빼고, 저거 넣어!"라며 갑자기 천재 비평가로 돌변합니다. 완벽한 코드를 짜기 전에 종이나 파워포인트로 대충 화면을 그려서 던져주고(Mockup), 고객의 진짜 욕망을 자극해 요구사항을 확정 짓는 도구적 접근을 뜯어봅니다.
• Implement: Throwaway Prototyping ROI(투자 대비 수익률) 계산기. Without Prototype: 요구사항 구두 합의 $\rightarrow$ 3달 개발 $\rightarrow$ 고객 반려 $\rightarrow$ 재개발 (매몰 비용 $30,000). With Prototype: 종이 스케치 1일 $\rightarrow$ 고객 반려 $\rightarrow$ 스케치 수정 1일 $\rightarrow$ 확정 후 3달 개발 (매몰 비용 $0). 값싼 실패(Cheap Failure)를 도출 단계의 최전선으로 끌어당겨(Shift-Left) 프로젝트의 생존율을 극대화하는 시각화.

Practical

Core Topic 03: 전쟁과 평화, 충돌 조율하기 (Navigating Conflicts)

• Why to Learn: 소프트웨어는 수많은 부서의 욕망이 부딪히는 전쟁터입니다. 아키텍트가 중간에서 "보안을 높이면 속도는 무조건 떨어집니다"라는 트레이드오프를 무기로 멱살을 잡고 타협선을 긋기 위함입니다.
• What to Learn:
  • Concepts: Conflicting Requirements, Trade-off Matrix, Stakeholder Matrix, Negotiation (Win-Win vs Compromise).
  • Skills: "데이터를 영구 보존하라(법무팀)" vs "서버 비용을 월 100만 원 이하로 줄여라(재무팀)"의 충돌 상황에서, "최근 1년은 SSD(빠름/비쌈)에, 그 이전 데이터는 AWS S3 Glacier(느림/쌈)로 백업한다"는 아키텍처적 절충안(Trade-off) 제시.
• How to Learn:
  • 1단계: 모순의 발견: 마케팅 팀은 "이벤트 페이지에 동시 접속자 100만 명이 와도 0.1초 만에 떠야 한다"고 요구합니다. 재무팀은 "인프라 예산은 10만 원"이라고 합니다. 둘 다 들어주는 건 물리적으로 불가능합니다(Conflict).
  • 2단계: 트레이드오프의 수치화: 아키텍트는 엑셀을 켭니다. "100만 명을 0.1초에 처리하려면 서버 1,000대가 필요하고 예산은 1,000만 원입니다(대안 A). 예산 10만 원을 맞추려면 대기열 큐(Queue)를 달아서 고객이 10분 기다리게 해야 합니다(대안 B)."
  • 3단계: 의사결정권자의 소환: 개발자가 혼자 결정하면 욕을 먹습니다. 이 엑셀표를 프로젝트 스폰서(CEO)에게 들고 가 "돈을 더 쓸 건지, 느린 속도를 감당할 건지 선택하라"고 강요합니다. 갈등을 숨기지 않고 수치화하여 폭발시킴으로써 시스템의 파국을 막아내는 엔지니어의 정치적/기술적 협상술을 해부합니다.
• Implement: NFR Trade-off 레이더 차트 모사. 축: [Performance, Security, Cost, Usability]. Option A (보안팀 선호): Security 100, Usability 20 (매번 OTP 입력), Cost 80. Option B (마케팅팀 선호): Security 30, Usability 100 (원클릭), Cost 50. Option C (아키텍트 절충안): 평소엔 Option B로 가다가 이상 접근(Fraud) 감지 시에만 OTP를 띄우는 Risk-based Authentication 제안. 충돌을 아키텍처 패턴으로 우회 돌파하는 매트릭스 렌더링.

Advanced

Core Topic 04: 버릴 것을 정하는 권력, MoSCoW (MoSCoW Prioritization)

• Why to Learn: 고객은 모든 기능이 "당장 안 하면 시스템 망하는 1순위 필수 기능"이라고 우깁니다. 제한된 시간(Sprint)과 예산 안에서 살아남기 위해, 피도 눈물도 없이 기능의 목을 치는 우선순위 권력을 장악하기 위함입니다.
• What to Learn:
  • Concepts: Prioritization, MoSCoW Method (Must have, Should have, Could have, Won't have), Timeboxing, Scope Creep.
  • Skills: 고객이 던진 20개의 요구사항 리스트를 보고, 법적 강제성이 있는 결제 모듈(Must)과 있으면 좋지만 빼도 무관한 다크 모드 UI(Could)를 칼같이 분리하여 이번 릴리즈 스코프(Scope) 확정하기.
• How to Learn:
  • 1단계: Must (숨을 쉬게 하는 것): 이거 없으면 오픈 자체를 못 하는 기능입니다. "물건을 장바구니에 담고 결제한다." 이건 Must입니다.
  • 2단계: Should (중요하지만 우회 가능한 것): 중요하긴 한데 런칭 날 며칠 빠져도 회사가 망하진 않는 겁니다. "결제 영수증 이메일 발송." 정 안 되면 오픈 첫 주에는 고객센터 직원이 수동으로 메일을 보내면 됩니다.
  • 3단계: Could (있으면 좋은 사치): 시간이 남으면 하는 기능입니다. "유저별 맞춤 상품 추천 AI."
  • 4단계: Won't (이번엔 절대 안 해): "드론 배송 연동." 이번 프로젝트 기간 내에는 절대 안 한다고 처음부터 못을 박아 고객의 기대를 꺾어버립니다(Scope Creep 방어). 시간이 부족해지면 Could와 Should를 쳐내면서도 Must만은 런칭해 내는 타임박싱(Timeboxing)의 냉혹한 결단력을 뜯어봅니다.
• Implement: MoSCoW 타임박싱(Timeboxing) 다이어트 시뮬레이션. Total Capacity: 100 Story Points (1 Sprint). Must: 60 SP. Should: 30 SP. Could: 40 SP. (합계 130 SP $\rightarrow$ 30 초과, 폭발 위기). Action: PO가 Could 전체를 삭제하고(0 SP), Should 중 10 SP를 다음 스프린트로 이월함. Result: 이번 릴리즈는 총 90 SP로 확정. 개발팀이 밤새우지 않고 "안전하게 동작하는 핵심 기능"을 오픈일에 맞춰 납품하는 MVP 생존율 100% 차트 렌더링.

7. Terminology

8. References

Primary

• [P1] CS2023 - Software Engineering (SE) - Requirements Engineering (Elicitation Techniques)
• [P5] SFIA - Requirements Definition and Management (REQM) - Stakeholder Needs Analysis

Secondary

• [Software Requirements] Karl Wiegers, Joy Beatty - Elicitation, Resolving Conflicts, Prioritization
• [User Story Mapping] Jeff Patton - Discovering the Whole Story (Iterative Elicitation)

Industry

• [BABOK Guide (Business Analysis Body of Knowledge)] - Elicitation and Collaboration
• [Agile Alliance] - MoSCoW Prioritization in Agile

9. Final Checklist

Primary

• 요구사항을 단순히 받아 적는 '수집(Gathering)' 방식이 초래하는 얄팍한 솔루션(How)의 늪을 피하기 위해, '5-Whys'를 던져 고객의 뇌 속에 숨겨진 진짜 니즈(What/Root Cause)를 끄집어내는 도출(Elicitation)의 차이를 설명할 수 있는가?
• 시스템에 대한 시각적 실체가 없어 발생하는 기획자와 개발자 간의 뇌피셜 간극을, 빠르고 싸게 깎아 만든 버리는 프로토타입(Throwaway Prototyping)으로 즉각 검증(Fact-Check)하여 설계 매몰 비용을 방어할 수 있는가?

Secondary

• 시스템의 응답 속도를 올리라는 영업팀과 모든 페이로드를 RSA로 암호화하라는 보안팀의 '상충하는 요구사항(Conflicting Requirements)' 앞에서, 아키텍트가 성능과 암호화 비용의 트레이드오프 엑셀 매트릭스를 들고 결정권자를 소환하는 조율 과정을 해부할 수 있는가?
• 프로젝트 일정이 절반으로 잘린 절망적인 타임박싱(Timeboxing) 상황에서, MoSCoW 기법을 휘둘러 'Should'와 'Could'를 무자비하게 쳐내고 시스템의 코어 엔진인 'Must'만으로 MVP를 런칭해 내는 생존 스코핑(Scoping)을 설계할 수 있는가?

Industry

• 수십 명의 이해관계자(기획, 마케팅, 운영, 개발)가 이메일로 요구사항을 한 달째 핑퐁하며 평행선을 달릴 때, JAD(Joint Application Design) 워크숍을 열어 화이트보드 앞에서 단 2일 만에 시스템 골격을 합의해 내는 퍼실리테이터(Facilitator)의 역할을 평가할 수 있는가?
• 고객이 개발 도중에 자꾸 "이 버튼 하나만 더 추가해 줘"라고 스며드는 스코프 크립(Scope Creep) 현상을, MoSCoW의 'Won't have(이번 릴리즈엔 절대 불가)' 명세서에 고객의 사인(Sign-off)을 받아냄으로써 공학적으로 방어하는 계약 통제력을 논증할 수 있는가?