많은 팀에서 요구사항(Requirements)이라는 단어는 조용히 서로가 불편해지는 권력 행사의 무언가로 되는 경우가 많아요. 누군가 의도적으로 그러는 건 아니지만, 업무가 종종 이렇게 흘러가거든요.
- 누군가 무엇을 만들지 결정한다
- 그것이 “요구사항”이 된다
- 논의는 선택 사항이 된다
- 요구사항 이행 및 구현이 성공의 주된 척도가 된다
“우리는 애초에 ‘왜’ 무언가를 만들고 있는가?”
1. 요구사항이 대화를 차단할 때
건강한 요구사항은 결정을 명확히 해요. 건강하지 않은 요구사항은 대화를 원천 차단해 버리죠. 어떤 유형인지는 요구사항이 제시된 후 일어나는 일을 들으면 구분할 수 있어요.- 건강한 경우: “이건 우리가 해결하려는 문제이고, 현재 우리의 생각입니다. 어떤 가정을 놓치고 있을까요?”
- 건강하지 않은 경우: “이것이 요구사항입니다. 질문 있으면 알려주세요.”
1) 사람들이 리스크를 제기하지 않게 된다
“요구사항”이 최종 확정으로 취급되면, 디자이너나 개발자는 자신이 우려를 제기하면 일이 느려지게 할 것이라고 인지하게 돼요. 그래서 리스크가 나중에 이런 형태로 나타나죠.- 예상치 못한 지연
- 품질 문제
- 움직이지 않는 지표
- “이걸 더 일찍 말했어야 했는데…”
2) 팀이 진짜 사용자의 맥락과 이야기를 잃어버린다
“요구사항”이 지배하면, 사용자는 그저 문서 내의 문자로 전락해버려요.- “사용자”
- “관리자”
- “고객”
2. 산출물 vs 성과: 스토리 매핑이 가능하게 하는 핵심 사고 전환
| 차원 | 산출물(Output) | 성과(Outcome) |
|---|---|---|
| 정의 | 팀이 출시하는 것 | 출시 덕분에 바뀌는 것 |
| 예시 | 문서, 기능, 제품 | 사용자 행동, 비즈니스 임팩트, 해결된 문제 |
| 전형적 초점 | “제 때 전달했는가?” | “실제로 뭔가 바뀌었는가?” |
| 어려운 이유 | 완료와 측정이 쉬움 | 학습, 트레이드오프, 측정이 필요 |
| 지금 중요한 이유 | AI가 산출물을 빠르고 저렴하게 만듦 | 성과는 여전히 희소하고 불확실 |
산출물과 성과의 차이를 비유하면, 운동과 건강의 관계와 같아요. “주 5회 헬스장에 갔다”(산출물)는 노력을 보여주지만, “체지방률이 5% 줄었다”(성과)는 실제 변화를 보여주죠. 매일 헬스장에 가도 식단과 수면을 관리하지 않으면 몸은 안 바뀌어요. 제품도 마찬가지로, 기능을 출시하는 것과 사용자 행동이 바뀌는 것은 전혀 다른 문제예요.
3. 문서는 정보 쓰레기통이 기억을 유도하는 도구
많은 팀이 두 극단 사이를 오가요.- 극단 1: “문서 없음, 우리는 애자일이니까.”
- 극단 2: “모든 것을 상세하게 문서화해야 해.”
- 어떤 결정을 내렸는가?
- 왜 그렇게 결정했는가?
- 어떤 대안을 고려했는가?
- 어떤 가정에 베팅하고 있는가?
- 작동했는지 어떻게 알 수 있는가?
4. 기능 출시에서 비즈니스 성과 창출로
이건 말하기는 쉽고 실천하기 어려운 부분이에요. 기능 중심 팀에서 성공은 이렇게 들려요.- “스프린트에서 모든 것을 구현했습니다.”
- “로드맵을 출시 완료했습니다.”
- “활성화가 개선되었고, 그 이유를 이해하고 있습니다.”
- “잔존(Retention)이 움직이지 않았지만, 어떤 가정이 실패했는지 배웠습니다.”
- “계획보다 적게 출시했지만, 핵심 플로우가 원활하게 작동합니다.”
“가치를 만들고 무언가를 배울 수 있는 가장 작은 일관된 경험은 무엇인가?” 이 전환을 비유하면, 레스토랑 평가 방식의 변화와 같아요. “메뉴 100가지를 제공한다”(산출물)가 아니라 “손님이 재방문한다”(성과)가 진짜 성공의 척도이죠. 미슐랭 스타 레스토랑은 메뉴 수가 아니라 손님의 경험으로 평가받아요. 제품 팀도 “얼마나 많이 출시했는가”가 아니라 “사용자에게 어떤 변화를 만들었는가”로 성공을 정의해야 해요.
다음 편에서는 스토리 맵이 실제로 무엇이고, 무엇이 아닌지, 그리고 사용자 정의와 AS-IS/TO-BE 맵의 차이를 구체적으로 살펴볼게요. 스토리 매핑 시리즈
(2) 이야기를 막는 ‘요구사항’과 성과를 이끄는 ‘스토리’