Chapter 6. 요구사항 수집, 그 이상의 의미

The era of AI 2025. 5. 18. 21:12

728x90

– 기능이 아닌 문제를 정의하라

1. 경험담: 요구사항 문서는 있었지만, 아무도 만족하지 못했다

어느 글로벌 기업의 HCM 프로젝트에서 고객은 수십 페이지에 달하는 요구사항 문서를 제출했다.
채용 관리, 근태, 보상, 평가… 수백 개의 기능 항목이 정리되어 있었다.
하지만 실제 설계를 시작하자, 내부에서는 전혀 다른 목소리가 나오기 시작했다.

“이건 우리가 실제로 일하는 방식과 맞지 않아요.”
“요구사항에는 적었지만, 이건 꼭 필요합니다.”
“그건 시스템 기능보다 관리자 의사결정 이슈에 가깝죠.”

결국 문서에 담긴 것은 기능의 나열일 뿐, 문제의 본질은 담기지 않았다.
요구사항 수집이 아니라 '요구사항 사전 작성'에 머물렀던 프로젝트는, 결국 리디자인을 거쳐야 했다.

고객의 기능 사항을 다 구현했지만, 어려움을 겪는 프로젝트도 있다.

한 기업의 HCM 시스템 프로젝트에서 요구사항 워크숍은 꼼꼼하게 진행되었다.
각 기능별 담당자가 나와 상세히 설명했고, 요구사항 엑셀 파일은 200줄이 넘었다.

그런데, 시스템이 구축되고 나서 들려온 반응은 이랬다.
“이건 내가 말한 대로 된 게 아니에요.”
“기능은 맞는데, 우리 방식과는 안 맞아요.”
“쓸 수는 있는데, 불편해요.”

문제는 요구사항이 잘못된 게 아니라, 해석이 부족했던 것이다.
“무엇을 해달라”는 요청은 있었지만, “왜 그런 요구가 나왔는지”에 대한 맥락과 목적은 반영되지 않았던 것이다.

2. 이론적 배경: 요구사항은 ‘솔루션’이 아니라 ‘문제의 언어’로 시작해야 한다

요구사항 수집은 시스템에 넣을 기능 목록을 정리하는 작업이 아니다.
진정한 요구사항 정의는 “조직이 해결하고자 하는 문제를 기술의 언어로 번역하는 과정”이다.

잘못된 접근 vs 바람직한 접근

접근 방식	특징	결과
❌ 기능 중심 요구 목록화	기존 방식 그대로 “이 기능이 있어야 한다”	기존 문제를 고착화할 위험
✅ 문제 중심 접근	“왜 그 기능이 필요한가?”, “무엇이 불편했는가?”를 중심으로 질문	프로세스 혁신 및 사용자 경험 개선 가능

중요한 건 기능이 아니라 의도(intent) 이다.
기능은 진화하지만, 의도는 프로젝트의 방향을 잡아준다.

또한, 요구사항 수집(Requirement Gathering)은 단순히 사용자 요청을 정리하는 절차가 아니다.
그것은 조직이 가지고 있는 문제, 기대, 문화, 전략을 시스템 언어로 변환하는 과정이다.
성공적인 요구사항 정리는 3가지 관점이 함께 반영되어야 한다.

성공적인 요구사항 수집의 3가지 관점

관점	설명	질문 예시
① 기능적 관점	어떤 기능이 필요하고, 어떤 동작을 해야 하는가	“무엇을 하려는가?”
② 업무 맥락 관점	이 요구는 어떤 업무 상황에서 나왔는가	“왜 이게 필요한가?”, “기존에는 어떻게 했는가?”
③ 전략적 관점	이 요구는 조직의 어떤 목표와 연결되는가	“이 요구가 우리 전략에 어떤 가치를 주는가?”

단순한 “체크박스 기능”이 아닌, “사용자 행동과 비즈니스 목적을 연결”하는 것이 핵심이다.

3. 실천 조언: 요구를 수집하지 말고, 의도를 발견하라

요구사항 정의를 위한 실무 팁

“이 기능이 필요한 이유는 무엇인가요?”를 반복하라
- 기능을 요청받으면 무조건 되묻는다
- 예: “엑셀 다운 기능이 필요합니다” → 왜 필요한가? → “리더에게 일주일 단위 보고를 전달해야 해서…”
프로세스 중심보다 사용자 여정 기반 접근 시도
- 한 명의 사용자(예: 신규 입사자, 평가 관리자 등)를 따라가며
- 그 여정에서 어떤 기능/정보/결정이 필요한지 파악
현재 방식의 문제를 시각화하라 (Pain Map)
- 복잡한 승인 구조, 반복 입력, 시스템 간 단절 등
- 문제의 근본 원인을 ‘요구’ 이전에 구조적으로 파악
요구사항을 수집하는 것이 아니라, ‘설계 가능성’을 탐색하라
- 요구를 그대로 구현하는 것이 아니라, SaaS 구조에서 어떻게 설계할 수 있을지 미리 가늠
- 기술적 가능성과 운영 적합성 사이의 밸런스 조율
요구사항 정의 워크숍에서 ‘기대 시나리오’를 함께 그려보라
- “이 기능이 구현되면 사용자는 어떤 방식으로 일하게 되는가?”
- 기능 정의 + 사용 시나리오가 함께 있어야 유의미한 요구

또, 한가지 실천할 수 있는 전략은 '대화'와 '시나리오'를 최대한 활용해서, 요구사항을 끌어내는 것이다.

효과적인 요구사항 수집을 위한 실무 전략

워크숍보다 인터뷰를 먼저
- 집단 논의보다, 1:1 인터뷰를 통해 숨겨진 불편과 진짜 니즈를 먼저 수집
- 특히 관리자, 현장 사용자, HR팀 등 다양한 관점 확보
요구사항을 시나리오화하라
- “사용자가 어떤 상황에서 이 기능을 언제, 왜, 어떻게 쓰는가”
- → 기능 + 맥락 + 기대 효과를 함께 정리
‘이건 왜 필요한가’를 3번 물어보라
- 예: “이 버튼은 왜 필요한가?” → “승인을 빨리 받고 싶어서요” → “왜?” → “관리자가 자주 출장을 가요” → “그럼 모바일 우선 설계가 더 적합하겠군요.”
요구사항 문서를 ‘설계 의도서’로 확장하라
- 기능 설명 + 사용 목적 + 기대 결과까지 포함한 명세 구조
- 예: [요구 ID] – [요청 배경] – [요구 내용] – [사용자 시나리오] – [비즈니스 가치]
요구 우선순위를 기능이 아닌 '비즈니스 임팩트' 기준으로 설정하라
- 단순히 ‘기능 필요도’가 아니라, 조직에 주는 효과나 리스크를 기준으로 판단

마무리 메시지

좋은 요구사항은 '많은 기능'이 아니라
‘명확한 목적’을 가진 간결한 구조에서 나온다.

요구사항 정의는 시스템의 방향을 설정하는 이정표다.
기능보다 의도, 목록보다 맥락, 요청보다 공감을 담아야
그 시스템이 조직을 바꾸는 도구가 된다.

그리고, 요구사항은 사용자로부터 받는 것이 아니라, 함께 발견해 나가는 것이다.
잘 정의된 요구는 단순히 "할 일" 목록이 아니라,
시스템이 해결해야 할 문제와, 조직이 실현하고자 하는 가치를 명확히 보여주는 나침반이다.

📌 다음 장 예고:
요구사항이 정리되었다면, 이제
어떻게 내부 공감대를 만들고 Stakeholder들을 조율할 것인가?
→ Chapter 7. 내부 공감대 형성과 Stakeholder 조율

✅ 실무 점검 체크리스트: 우리는 ‘요구’가 아니라 ‘의도’를 수집하고 있는가?

점검 항목	예/아니오	간단한 메모
1. 요구사항 수집 시 기능 설명 외에 업무 배경과 사용자 상황을 함께 기록하고 있다	☐ / ☐	(예: 기존 업무 흐름, 제도상 제약 등)
2. 기능을 요청한 사람과 직접 업무 시나리오나 사용 맥락에 대해 대화를 나눈 적이 있다	☐ / ☐
3. 각 요구사항이 어떤 전략적 목표나 조직 가치와 연결되는지 판단해본 적이 있다	☐ / ☐
4. 요구사항 문서가 단순 체크리스트가 아니라 사용자 유형, 사용 흐름, 기대 효과까지 포함하고 있다	☐ / ☐
5. 동일한 요구라도 여러 이해관계자의 관점 차이나 우선순위 충돌을 확인하고 조율한 경험이 있다	☐ / ☐
6. “왜 필요한가?”라는 질문을 반복하며, 기능적 요청 뒤에 있는 진짜 니즈를 파악해본 적이 있다	☐ / ☐
7. 요구 우선순위를 ‘개수’나 ‘긴급도’가 아니라, 조직에 미치는 영향력(임팩트 기준)으로 정하고 있다	☐ / ☐

✅ 점검 결과 해석

예 6개 이상:
귀하의 팀은 단순한 기능 수집을 넘어서, 조직의 목적과 사용자 니즈를 설계로 연결하는 수준 높은 요구 정의 역량을 보유하고 있습니다.
이 기반은 프로젝트의 품질과 사용자 수용성을 동시에 높일 수 있는 강력한 자산이 됩니다.
예 4~5개:
실무적으로는 충분한 수집이 되고 있으나, 전략적 정렬과 사용자 맥락 해석이 다소 부족할 수 있습니다.
향후 요구 문서의 구조나 수집 방식 개선을 통해 깊이를 더할 수 있습니다.
예 3개 이하:
현재의 요구 수집은 '시스템 기능 정의'에 치우쳐 있을 가능성이 큽니다.
도입 후 사용자 불편, 적응 문제, ROI 미흡 등의 리스크로 이어질 수 있으므로
조기에 **"요구 = 의도 해석 + 업무 맥락 + 사용자 경험"**이라는 프레임을 도입할 필요가 있습니다.

“요구사항이란 무엇을 하겠다는 선언이 아니라,
왜 해야 하는지에 대한 공감과 설계의 출발점이다.”

728x90

저작자표시 비영리 변경금지 (새창열림)