13.1 요구사항 발견과 분석 — 요청 뒤의 목표와 제약을 찾는다
요구사항은 회의에서 받아 적는 기능 목록이 아니다. 서로 다른 이해관계자가 가진 목표·업무·제약·위험을 시스템 경계 안에서 조정한 결과다. 이 문서는 요구사항을 곧바로 해법으로 번역하기 전에 누구의 어떤 문제가 있는지, 무엇이 사실이고 무엇이 가정인지, 갈등을 어떤 근거로 우선순위화할지를 다룬다.
학습 목표
- 이해관계자와 시스템 경계를 식별하고 목표·요구사항·설계 해법을 구분한다.
- 인터뷰·관찰·워크숍·프로토타입이 드러내는 증거와 편향을 비교한다.
- 충돌하는 요구사항을 가치·비용·위험·의존성으로 우선순위화한다.
- 사실·가정·제약·미해결 질문을 분리해 발견 결과를 검증한다.
배경: 사용자는 자신이 필요한 것을 말해 주는가
“고객이 주문을 취소할 수 있게 해 주세요”는 출발점이지 완성된 요구사항이 아니다. 고객이 실제로 원하는 것은 잘못 주문한 비용을 회복하는 것일 수 있다. 물류팀은 이미 포장한 상품의 낭비를 막고 싶고, 재무팀은 승인과 환불 기록을 맞춰야 하며, 고객지원팀은 예외를 처리할 권한이 필요하다. 결제사와 택배사는 직접 회의에 참석하지 않아도 시스템이 의존하는 외부 이해관계자다.
표면 요청을 그대로 구현하면 가장 목소리가 큰 사람의 해법을 최적화하기 쉽다. 요구사항 발견(requirements elicitation)은 숨은 목표와 제약을 드러내는 활동이고, 분석(analysis)은 발견한 내용을 경계·우선순위·갈등·실현 가능성 관점에서 정리하는 활동이다. 둘은 한 번 끝나는 단계가 아니다. 설계와 운영 증거가 새로운 질문을 만들 때 반복한다.
핵심 개념
이해관계자 — 시스템 결과에 영향을 받는 사람과 시스템
이해관계자(stakeholder)는 최종 사용자만을 뜻하지 않는다. 시스템을 사용하거나 운영하고, 비용을 지불하며, 규칙을 집행하고, 실패의 영향을 받거나, 입력·출력을 제공하는 모든 주체가 후보이다.
주문 취소 사례의 이해관계자를 역할과 관심사로 정리하면 다음과 같다.
| 이해관계자 | 원하는 결과 | 두려워하는 실패 | 제공할 증거 |
|---|---|---|---|
| 구매 고객 | 실수한 주문을 예측 가능하게 취소 | 돈은 빠졌는데 상태를 알 수 없음 | 문의·이탈 데이터, 사용성 관찰 |
| 고객지원 | 예외를 설명하고 수동 조정 | 상태가 달라 원인을 복원하지 못함 | 티켓 유형, 처리 시간 |
| 물류 운영 | 출고와 취소의 충돌 방지 | 포장 뒤 취소로 재고 불일치 | 업무 절차, 상태 전이 기록 |
| 재무·감사 | 승인·환불 원장의 대응 | 변경 이력 유실과 중복 환불 | 정산 규칙, 감사 사례 |
| 결제사 | 정해진 API·한도 내 요청 | 중복·과도한 재시도 | API 계약, 장애·지연 통계 |
| 개발·운영팀 | 변경과 장애를 통제 | 모호한 책임과 관측 불가능 | 코드·장애 기록, 운영 비용 |
stakeholder map의 목적은 이름을 빠짐없이 수집하는 것이 아니라 결정 권한, 지식, 영향의 불균형을 드러내는 것이다. 고객지원은 예외 사례를 가장 많이 알지만 정책 결정권은 없을 수 있다. 보안 담당자는 기능 요청자가 아니어도 배포를 중단시킬 수 있다. 참석자가 많다고 관점이 자동으로 대표되지는 않는다.
목표, 요구사항, 해법을 분리한다
세 층을 섞으면 대안이 사라진다.
목표: 취소 실패 문의와 수동 환불 비용을 줄인다.
└─ 요구사항: 결제사가 지연되어도 2초 안에 취소 접수 여부를 알린다.
└─ 해법 후보: 작업 큐, outbox, 결제사 비동기 API, 제한된 동기 대기- **목표(goal)**는 왜 변화가 필요한지 설명한다.
- **요구사항(requirement)**은 시스템이나 업무가 제공해야 할 결과와 제약을 정한다.
- **해법(solution)**은 그 결과를 만드는 한 가지 구현 선택이다.
“마이크로서비스로 분리한다”, “Kafka를 쓴다”, “버튼을 추가한다”가 요청으로 들어오면 거부하기보다 한 단계 위의 목표를 묻는다. “그 해법이 없으면 어떤 결과가 실패하는가?”, “성공했다는 것을 무엇으로 알 수 있는가?”가 유용한 질문이다. 이미 계약이나 규제로 기술이 고정되었다면 그것은 해법 후보가 아니라 설계 제약으로 명시한다.
시스템 경계 — 책임을 선택하는 모델
시스템 컨텍스트(system context)는 대상 시스템과 외부 주체 사이의 책임 경계를 보여 준다. 경계는 현실의 고정된 선이 아니라 분석 목적에 따른 선택이다.
고객 ── 취소 요청/상태 조회 ──▶ 주문 시스템
│
고객지원 도구 ── 강제 취소 ────────┤
├── 승인 취소 ──▶ 결제사
├── 출고 중지 ──▶ 물류 시스템
└── 회계 이벤트 ─▶ 정산 시스템이 그림에서 결제사 내부의 재시도 알고리즘은 범위 밖이지만, 결제사가 반환하는 상태와 시간 계약은 경계 계약의 일부다. “결제사 장애를 고친다”는 시스템 책임이 아니어도 “장애 중 요청을 보존하고 상태를 설명한다”는 책임은 주문 시스템에 둘 수 있다.
경계를 그릴 때 각 화살표에 다음을 묻는다.
- 누가 시작하고 어떤 데이터·권한을 전달하는가?
- 성공, 거절, 시간 초과와 중복은 무엇을 뜻하는가?
- 어느 쪽이 기록의 원천(source of truth)인가?
- 어떤 법·계약·조직 제약이 이 경계를 고정하는가?
도출 기법 — 서로 다른 종류의 증거를 얻는다
한 기법으로 모든 요구를 찾을 수 없다.
| 기법 | 잘 드러내는 것 | 주요 편향·비용 |
|---|---|---|
| 인터뷰 | 목표, 용어, 예외에 대한 설명 | 기억과 자기보고 편향, 권력 관계 |
| 업무 관찰 | 실제 순서, 우회 절차, 암묵지 | 관찰 효과, 드문 예외를 놓침 |
| 워크숍 | 관점 충돌, 우선순위, 공동 언어 | 강한 참석자가 논의를 지배 |
| 문서·로그 분석 | 기존 계약, 빈도, 실제 실패 분포 | 기록되지 않은 맥락, 데이터 품질 |
| 프로토타입 | 상호작용과 실현 가능성의 빠른 피드백 | 시각적 완성도가 범위 확정으로 오해됨 |
| 운영 실험 | 실제 행동과 성능 증거 | 안전·윤리·비용 제약, 인과 혼동 |
취소 버튼 위치는 프로토타입으로 빨리 검증할 수 있지만 감사 기록의 보존 의무는 재무 규정과 실제 정산 사고를 확인해야 한다. 인터뷰에서 “거의 없다”는 예외가 로그에서는 하루 수백 건일 수 있다. 서로 다른 기법의 증거가 충돌할 때 어느 한쪽을 평균내지 말고 차이가 생긴 이유를 조사한다.
사실, 제약, 가정, 미해결 질문
발견 노트에 네 종류를 표시하면 거짓 확신을 줄일 수 있다.
| 종류 | 예 | 다음 행동 |
|---|---|---|
| 확인된 사실 | 출고 시스템은 PACKING 이후 중지 API를 거절한다 | 출처와 확인 날짜를 연결 |
| 제약 | 카드 환불 기록을 법정 기간 보존해야 한다 | 근거 규정과 적용 범위를 확인 |
| 가정 | 취소 요청의 99%는 결제 후 10분 안에 온다 | 로그 질의로 검증 |
| 미해결 질문 | 부분 배송 주문의 취소 단위는 무엇인가 | 정책 소유자와 결정 기한 지정 |
가정은 나쁜 것이 아니다. 표시되지 않은 가정이 위험하다. 가정마다 틀렸을 때의 영향과 확인 비용을 평가해 먼저 검증할 순서를 정한다. “결제사 응답은 항상 2초 이내”처럼 아키텍처를 좌우하는 가정은 낮은 비용으로 빨리 검증할 가치가 크다.
갈등과 우선순위 — 목록의 순서가 아니라 결정 규칙
모든 요구를 must로 표시하면 우선순위가 없는 것과 같다. 우선순위는 가치만이 아니라 다음 요소를 함께 본다.
- 가치: 어떤 목표와 이해관계자 결과를 개선하는가?
- 비준수 비용: 법적·안전·재무 손실이나 신뢰 훼손은 무엇인가?
- 시간 민감성: 지금 하지 않으면 언제 가치가 사라지는가?
- 의존성: 다른 요구나 검증을 가능하게 하는가?
- 불확실성과 위험: 모르는 것이 크고 실패 비용이 큰가?
- 구현·운영 비용: 초기 개발뿐 아니라 지속 운영 비용은 얼마인가?
예를 들어 “환불 완료를 즉시 보여 준다”와 “결제사 장애에도 고객 요청을 잃지 않는다”가 충돌할 수 있다. 둘을 동시에 must로 적는 대신 완료와 접수를 구분하고 상태 모델을 협상한다. 고객에게 2초 안에 CANCEL_REQUESTED를 알리고, 최종 CANCELED는 결제사 확인 후 전환하는 식이다. 이것은 단순한 문구 수정이 아니라 목표 사이의 트레이드오프를 명시한 결정이다.
우선순위 기법의 이름보다 결정 근거가 중요하다. MoSCoW는 대화를 시작하기 쉽지만 Must 남용을 막아 주지 않는다. 가치/비용 점수는 비교를 돕지만 불확실한 숫자를 객관성으로 포장할 수 있다. 규제·안전처럼 협상 불가능한 제약과 사업 선호를 같은 점수로 합치지 않는다.
사례 분석: 취소 기능을 다시 발견하기
처음 요청은 “고객이 앱에서 주문을 취소한다”였다. 한 차례 발견·분석 후 결과는 다음처럼 달라질 수 있다.
목표와 경계
- 목표 G1: 취소 관련 고객 문의의 중간 처리 시간을 줄인다.
- 목표 G2: 중복 환불과 주문·물류·정산 상태 불일치를 막는다.
- 경계: 주문 시스템은 취소 의도를 접수하고 상태를 조정하지만 결제 승인 취소와 출고 중단의 최종 성공은 외부 시스템이 결정한다.
핵심 갈등
- 고객의 빠른 확정 기대 대 외부 시스템의 지연·부분 실패
- 고객지원의 예외 처리 권한 대 감사 가능한 통제
- 단순한 단일 상태 대 부분 취소·부분 배송의 표현력
먼저 검증할 가정
- 요청의 99%가 출고 시작 전에 온다는 가정은 로그로 확인한다.
- 결제사가 멱등 키를 지원한다는 가정은 공식 API 계약과 샌드박스 실험으로 확인한다.
- 상담원 강제 취소가 월 10건 미만이라는 가정은 티켓 분류 데이터로 확인한다.
이 결과는 아직 완성된 명세가 아니다. 그러나 누가 무엇을 원하고 어떤 외부 책임과 불확실성이 있는지 드러냈기 때문에 다음 문서에서 검증 가능한 약속으로 바꿀 수 있다.
실무 관점
“사용자가 그렇게 말했으니”는 근거가 아니다
사용자 발언은 중요한 증거지만 유일한 진실은 아니다. 사용자는 현재 절차의 제약 안에서 해법을 말하고, 드문 실패나 다른 역할의 비용을 보지 못할 수 있다. 발언을 무시하지 말고 목표·관찰·데이터와 삼각 검증한다.
현재 상태를 자동으로 요구사항으로 승격하지 않는다
레거시 시스템이 이메일로 승인한다고 해서 새 시스템도 이메일을 보내야 하는 것은 아니다. 그것이 규제 제약인지, 우연한 구현인지, 사용자가 만든 우회 절차인지 구분한다. 반대로 오래된 우회 절차에는 공식 문서가 놓친 실제 필요가 숨어 있을 수 있다.
미래를 모두 예측하려 하지 않는다
“언젠가 해외 진출할 수 있다”는 말만으로 다국어·다중 통화·다중 리전을 모두 설계하면 현재 문제보다 추측을 최적화한다. 미래 옵션의 가치, 발생 신호, 나중 변경 비용을 비교한다. 지금은 가정을 기록하고 경계를 좁히는 것이 더 합리적일 수 있다.
발견의 완료 조건
모든 요구를 찾았을 때가 아니라 현재 결정을 내리기에 중요한 불확실성이 허용 수준으로 줄었을 때 발견 단계를 닫는다. 열린 질문이 없어야 하는 것이 아니라 각 질문의 위험, 소유자와 확인 시점이 있어야 한다.
정리
- 요구사항은 사용자의 기능 목록이 아니라 여러 이해관계자의 목표와 제약을 조정한 약속이다.
- 목표·요구사항·해법을 분리해야 대안을 비교하고 숨은 목적을 보존할 수 있다.
- 시스템 경계는 외부 실패를 없애지 않지만 어느 반응을 우리 책임으로 둘지 정한다.
- 인터뷰·관찰·로그·프로토타입은 서로 다른 증거와 편향을 가지므로 조합해야 한다.
- 사실·제약·가정·질문을 구분하고 가치·비용·위험·의존성으로 갈등을 우선순위화한다.
확인 문제
- 영업팀이 “대형 고객마다 전용 주문 서비스를 배포해야 한다”고 요청했다. 목표·요구사항·해법을 분리하기 위해 무엇을 질문할 것인가?
- 고객 인터뷰에서는 취소 실패가 드물다고 했지만 고객지원 로그에서는 가장 긴 처리 시간을 차지한다. 두 증거를 어떻게 다룰 것인가?
- 모든 이해관계자가 “즉시 환불”을 최우선으로 표시했지만 결제사는 완료 시간을 보장하지 않는다. 요구사항을 어떻게 재구성할 수 있는가?
정답과 해설
- 고객별 배포가 없을 때 어떤 격리·성능·규제 목표가 실패하는지, 고객별 차이가 데이터·정책·트래픽 중 무엇인지, 성공을 어떤 지표로 판별할지 묻는다. 전용 배포는 그 뒤에 비교할 해법 후보 또는 계약상 제약이다.
- 인터뷰와 로그 중 하나를 버리지 않는다. 사용자가 실패 빈도와 고통을 다르게 인식하는지, 로그 분류가 정확한지, 드물지만 비용이 큰 꼬리 사례인지 조사한다. 빈도와 영향은 별도 축으로 평가한다.
- 요청 접수와 최종 완료를 구분한다. 예를 들어 2초 안에 접수·거절 상태를 알리고, 결제사 확인 뒤 최종 완료하며, 지연 중 요청 보존·상태 조회·통지 계약을 명세한다.
참고 자료
- ISO/IEC/IEEE 29148:2018: 이해관계자 요구와 시스템·소프트웨어 요구사항 공학의 프로세스와 정보 항목을 정의한다.
- Quality Attribute Workshops, Third Edition: 이해관계자가 초기 단계에서 아키텍처에 중요한 품질 속성을 도출하고 정제하는 절차를 설명한다.
- NIST SP 800-160 Vol. 1 Rev. 1: 신뢰할 수 있는 시스템을 위한 이해관계자 요구, 시스템 경계와 수명 주기 관점을 제공한다.