유저 스토리가 모든 걸 해결해주지 않아요!

제품 개발에 필요한 내용들

Jul 20. 2025

회사에서 제품을 만들기 위해 기획안 어디까지 작성하시나요? 요새는 대부분 PM/PO 분들이 PRD 내에 유저 스토리만 작성하는 편이에요. 이유를 들어보면 회사 차원에서 빠른 릴리즈를 하려고 하다보니 시간이 부족하기도 하고 목적 조직으로 운영되다보니 바로 옆에서 의사결정을 내릴 수 있기 때문이라고 해요. 맞는 말이에요. 하지만 유저 스토리만으로 제품을 만들 수는 없다는 점을 잊어서는 안돼요.

유저 스토리의 착각과 현실

"고객으로서 장바구니에 상품을 담고 싶다. 그래야 나중에 한 번에 결제할 수 있다."

위 유저 스토리는 기본 틀인 Who, Why, What을 모두 담으면서 고객 관점도 잘 반영되어 있었어요. 그러나 실제 개발이 시작되면 이 정보만으로는 부족해요. 왜 그럴까요?

해당 문장 속에는 규칙 즉, 정책이 없기 때문이에요. 예를 들어 우리 상품이 특정 기간에만 판매해야 하는 상품이 있다면 해당 상품이 장바구니에 담겼을 때 어떻게 보여야 할까요? 장바구니에 담긴 상품이 판매자가 더 이상 팔지 않게 되었을 때 어떻게 보여줘야 할까요? 여러 브라우저에 로그인 되어 있는 상태에서 상품을 장바구니에 담았을 때 최종적으로 어떻게 저장되어야 할까요? 이처럼 유저 스토리 한 문장으로 해당 기능을 구현하기에는 필요한 다른 정보들이 많아요.

제품 개발을 위해 필요한 내용

제품 혹은 기능 구현을 하기 위해서 필요한 내용들은 무엇이 있을까요? 아래 내용은 정말 필수라고 생각해요.

1. 고객 요구사항 리스트

고객이 진짜 무엇을 원하는지 정리한 내용이에요. 유저 스토리에 담겨있으니 필요없다고 하는 사람들도 많은데 요구사항 리스트를 없이 유저 스토리 만으로는 진짜 문제를 찾기 어려워요. 고객이 필요로 하는 날 것의 문장을 작성하고 그로 부터 진짜 문제를 찾았는지 비교해보는 것이죠. 또한 이 내용이 마케팅 문구를 만들어내는 기본이 되기 때문이에요. 마케팅 문구는 따로 만드는 것이 아니라 고객의 목소리로부터 나와야 하는 것이죠.

예시: "기존 고객 중 73%가 모바일에서 장바구니 기능 부재로 구매를 포기함"

2. 유저 스토리

유저 스토리는 왜 중요할까요? 고객 요구사항 리스트만 있어도 되는 거 아닐까요? 저 또한 다양한 프로젝트를 진행하면서 유저 스토리를 안 쓰면서 일해 본 적도 있었는데요, 그러면서 깨달은 것이 고객 관점으로 다시 한 번 생각해 볼 수 있다는 점이었어요. 요구사항으로부터 바로 기능 명세를 만들어 낼 때는 항상 나의 입장이 같이 반영되기 마련이에요. 문제를 계속 생각하기 때문에 문제 밖에서 객관적으로 보는 것이 아니라 문제에 매몰되어 버리는 것이죠. 그렇기 때문에 고객 입장에서 생각해 볼 수 있는 시간이 필요해요. 그게 바로 유저 스토리인 것이죠.

예시: "고객으로서 장바구니에 상품을 담고 싶다"

3. 기능 명세

앞서 이야기한 것처럼 유저 스토리만으로는 기능 구현할 수가 없어요. 시스템이 어떻게 동작해야 하는지 구체적으로 정리한 내용이 필요한 것이죠. 그게 바로 기능 명세입니다. 이 기능 명세를 통해 고객의 문제를 해결할 수 있는지 확인하는 것이죠. 필요한 기능들과 해당 기능들의 목적, 예외 사항들을 기능 명세에 담겨야 해요.

예시: "장바구니 보관 기간 30일, 재고 부족 시 고객 알림 및 대체 상품 추천"

4. 화면과 정책

유저 스토리와 기능 명세를 통해 얼추 어떤 기능을 구현할 것이다라는 것을 짐작할 수 있어요. 하지만 해당 내용에는 사용자가 입력할 때 숫자만 입력해야 하는지, 특수 문자를 입력해도 되는지, 에러가 발생하면 어떻게 처리되어야 하는지 등등 사용자가 볼 수 있는 화면 단위로 자세하게 정리되어 있어야 기능 구현을 할 수 있어요. 이를 통해 고객에게 이러한 화면을 제공해주면 문제가 해결될 것이다 짐작해보는 것이죠.

예시: "장바구니 버튼은 상품 이미지 우측 하단, 32px 크기, primary 컬러"

문서화 VS 속도, 정말 반비례할까?

많은 PM/PO분들이 "문서 작성하느라 제품 릴리즈가 늦어진다"고 생각해요. 하지만 제 경험으로는 정반대였어요. 고객 요구사항이 잘 정리되지 않으면 진짜 문제를 찾을 수 없고, 기능 명세와 정책이 정리되지 않으면 기능 구현을 할 수 없어요. 다시 말해, 각 내용들이 모두 있어야지만 제품 개발이 가능하다는 의미예요. 이 내용 중 하나라도 빠지면 결국 개발이 지연될 수 밖에 없어요.