애자일 팀에서 일해본 적이 있다면, 유저 스토리(User Story)가 애매모호하게 사용되는 것을 본 적이 있을 거예요. 스프린트를 채우기 위한 티켓, “완료”를 확인하는 체크리스트, 또는 생각을 대체하는 수단으로요. 이번 시리즈에서는 유저 스토리 매핑(User Story Mapping)을 산출물이 아니라, 팀 내 공유된 이해를 만들고 더 나은 제품 대화를 이끄는 도구로 살펴볼게요.
이 시리즈는 제프 패튼(Jeff Patton)의 유저 스토리 매핑 관점에 기반하고 있어요. 스토리를 고정된 요구사항이 아닌, 공유된 이해를 위한 도구로 바라보는 접근이죠.
1. 모두가 동의했는데 기능이 실패하는 이유
이해관계자가 이렇게 말해요.
“고객이 분석 리포트를 CSV로 내보내야 합니다.”
팀이 이걸 스토리로 만들어요.
“사용자로서, 리포트를 CSV로 내보낼 수 있다.”
구현하고, QA를 통과하고, 완료된 것처럼 보이죠. 그런데 고객 지원팀에 불만이 쏟아지기 시작해요.
“CSV에 시간대가 빠져 있어요.”
“합계가 대시보드에서 보이는 것과 다릅니다.”
“파일이 너무 커서 Excel에서 열리지 않아요.”
“버튼이 아니라 이메일로 예약 전송이 필요했어요.”
이런 실패가 나오는 이유는 팀 내에서 정의된 스토리가 올바른 대화를 이끌어내지 못한 거예요.
실패한 스토리에 빠져 있던 것은 진정으로 사용자를 이해한 이야기였어요.
- 누가 리포트를 내보내고, 왜 그러는 걸까?
- CSV를 내보낸 다음에 뭘 하는 걸까?
- 정확도와 포맷이 어느 수준이면 “쓸 만한” 건가?
- 제약 조건(Excel 행 제한, 로컬라이제이션, 권한)이 있는 건 아닌가?
- 진짜 해결하려는 할일(Job-to-be-Done)은 내보내기인가, 공유인가, 감사인가?
단순히 “티켓으로서의 스토리”는 이런 질문들을 숨겨버려요. “대화로서의 스토리”는 이 질문들을 수면 위로 올려주죠.
이 상황을 비유하면, 여행사에 “파리행 비행기 티켓”만 요청한 것과 같아요. 여행사는 티켓을 끊어주지만, 여행자가 정작 원한 건 “신혼여행을 위해 에펠탑이 보이는 호텔에서 3박하며 현지 맛집을 즐기는 것”이었을 수 있죠. 티켓(산출물)은 전달했지만, 여행 경험(성과)은 놓친 거예요. 스토리도 마찬가지로, 표면적 요청 뒤에 숨은 진짜 맥락을 대화로 끌어내야 해요.
2. 대화를 이끌어내는 도구로써 스토리
많은 팀이 유저 스토리를 원래 의도와 다르게 사용하고 있어요. 린(Lean)이나 애자일(Agile) 환경에서 일한다면, 스토리를 개발을 위해 기능을 쪼개는 용도로 쓰고 있을 거예요. 표면적으로는 합리적이지만, 실제로는 이런 일이 벌어지곤 하죠.
실제 사용자의 이야기가 ‘스토리’라는 이름 아래 잘게 쪼개진 요구사항의 바다에서 사라져 버리고 마는거예요. 결국 사용자가 원치 않는 기괴한 기능들로 무장한 “프랑켄슈타인 프로덕트”가 탄생하죠.
핵심 문제는 이거예요. 스토리는 인수 조건(Acceptance Criteria)이 아니에요. 대화를 촉진하기 위해 존재하는 거죠.
물론 스토리는 개발 과정에서 인수 조건으로 활용되기도 해요. 하지만 그건 스토리가 해야 할 일의 아주 작은 부분일 뿐이에요. 스토리를 인수 조건으로만 축소하면, 결국 요구사항이 위에서 내려오고 개발자는 “시키는 대로 하면 되는” 예전 워터폴(Waterfall) 방식을 재현하게 되는 거죠.
스토리의 진짜 목적은 공동의 이해(Shared Understanding)로 이어지는 더 나은 대화를 이끄는 거예요. 공유된 문서가 아니라요.
스토리는 다음과 같이 사용자에 대한 대화와 논의를 촉진하는 것으로써 다뤄져야 해요.
- 사용자가 무엇을 달성하려 하는가?
- 맥락은 무엇인가?
- 무엇이 잘못될 수 있는가?
- 사용자와 비즈니스 모두에게 성공은 어떤 모습인가?
이런 질문들이 생략되면, 팀은 종종 “기술적으로 올바르지만 이상하게도 아무도 안 쓰는” 기능을 출시하게 돼요.
3. 공유된 문서와 공동의 이해는 다르다
많은 팀이 빠지는 함정이 있어요.
- 프로덕트 매니저가 상세한 스펙을 작성한다
- 슬랙이나 노션에 공유한다
- 모두가 👍 반응을 남긴다
- 제품 또는 기능이 출시된다
- 그런데 사용자가 반응하지 않아서 다들 놀란다
이런 일이 발생하는 이유는 공유된 문서가 공동의 이해와 같지 않기 때문이에요.
공유된 이해는 이런 것에 더 가까워요.
- 사용자의 맥락과 목표를 이해한다
- 중요한 제약 조건과 엣지 케이스를 이해한다
- 사용자와 제품의 “성공”이 어떤 모습인지 이해한다
- 의도적으로 아직 하지 않는 것을 이해한다
이런 이해는 문서만으로 달성하기 어려워요. 특히 제품이 여러 레이어(UX, 백엔드, 분석, 운영, 정책, 마케팅)를 포함할 때는 더욱 그렇죠.
공동의 이해란 사용자에 대해 다른 사람이 무엇을 생각하고 왜 그렇게 생각하는지를 명확히 이해하고 하나의 합의점을 도출하는 것이에요. 이를 위해서는 맥락, 양방향 대화, 그리고 “왜?”를 여러 번 물을 수 있는 환경이 필요하죠.
4. “우리는 애자일이니까 문서를 안 써요”라는 착각
이 말이 실무에서 의외로 자주 등장해요.
“우리는 이제 애자일이니까 문서를 안 씁니다.”
애자일이 무엇인지 아는 사람들은 농담으로 얘기하지만, 진지하게 이렇게 얘기한다면 조직의 위험 신호일 수 있어요. 진짜 문제는 문서 자체가 아니에요. 문제는 공동의 이해을 대체하는 문서이죠.
애자일이 “문서 없음”을 의미하는 건 아니에요. 애자일이 의미하는 건 이런 거예요.
- 아무도 쓰지 않는 문서를 작성하지 않는다
- 작성하는 것과 이해하는 것을 혼동하지 않는다
- 문서가 일방적 전달이 되지 않게 한다
건강한 프로덕트 팀은 여전히 문서를 만들어요. 다만 결정과 학습을 크게 돕는 종류의 것들을 만드는 거죠. 워크숍 후 화이트보드 사진, “우리가 왜 이렇게 결정했는지”를 담은 짧은 메모 같은 것들이에요. 이건 “정보 덤프”가 아니라 결정을 기억할 수 있게하는 것들이에요.
애자일 문서를 비유하면, 요리 과정의 메모와 같아요. 셰프가 레시피북 전체를 매번 다시 쓰는 건 비효율적이지만, “이번에 소금을 조금 줄였더니 맛이 좋았다”라는 한 줄 메모는 다음 요리에 큰 도움이 되죠. 팀의 문서도 마찬가지로, 방대한 스펙이 아니라 핵심 결정과 그 이유를 간결하게 남기는 것이 중요해요.
5. 자가 진단: 우리 팀이 유저 스토리를 잘못 쓰고 있다는 신호
아래 패턴 중 하나라도 해당된다면, 스토리 매핑이 도움이 될 거예요.
- 스토리가 최소한의 논의만으로 작성되고 할당된다
- 스프린트 계획이 사용자에 대한 발견(Discovery)의 과정 아니라 공격적 협상처럼 느껴진다
- 이해관계자가 백로그(Backlog)를 이행해야 할 의무로 취급한다
- 엔지니어가 “주문 접수자” 같은 느낌을 받는다
- “완료된” 기능을 출시했는데 지표가 움직이지 않는다
다음 편에서는 요구사항이라는 단어가 어떻게 대화를 막는지, 그리고 스토리 매핑이 팀을 산출물 중심에서 성과 중심으로 전환시키는 원리를 살펴볼게요.
스토리 매핑 시리즈
(2) 이야기를 막는 ‘요구사항’과 성과를 이끄는 ‘스토리’
(5) 스토리 매핑을 제품 기획에 적용하는 5가지 방법