Userstory와 SB 방식, 무엇이 더 좋을까?

병렬적인 요구사항과 게층적인 요구사항의 방식

아, 정말 UserStory는 hierarchy가 있네

 오늘 함께 일하는 PO와 여느 때처러 일의 어려움에 대해서 토로하다가 과거 일하던 방식과 지금의 일하던 방식 중 문서 커뮤니케이션에 대한 이야기를 했다.  이제 함께 일한지 2개월이 좀 넘어가는 주니어인 이 친구는 SB를 작성하는 것보다 Userstory를 쓸 때어려움을 느꼈었다고 한다.  사실 나도 그런 느낌이 있었지만 사실 이유를 명확하게 생각해본 적은 없었다.

 SB로 업무를 할 때, 지금 PO로 일할 때보다 쉬웠던 것은 익숙했던 탓이었다. '걸어다니는 정책서'라고 불릴 정도로 사내 서비스들간의 모든 세세한 정책을 줄줄 외우고 있던 탓에, 나는 어려운 문제를 잘 풀어내는 것에 더 익숙했었다. 어려운 문제를 푼다는 것은 '모든 제약 조건을 고려하여 가장 좋은 방법'을 선택하는 것에 있다.   

 서비스 기획자로 일하면서 마지막에 토나오게 힘들었던 프로젝트에서 매일 밤 12시 넘어 집에 오고 주말에도 기획서를 했었다. 몸이 힘들었고, 프로젝트 자체에 대한 불신이 컸지만 기획을 하는 것 자체에는 분명 스트레스가 없었다. 그냥 아는 것을 모두 쏟아내서 기획을 했기 때문이었다.  솔직히 말하면 문서의 양도 많고 해야했던 범위가 많았어도 지금보다 쉬웠다는 느낌이었다고 할까.

 언뜻보면 말이 안되는 상황이지만, 이유는 케이스에 대한 경중이 상대적으로 중요하지 않았기 때문이었다. 서비스를 기획하고 개발하는 과정에서 분명 중요 케이스에 대한 정의는 존재한다. 하지만 SB의 특성 상 케이스의 구분 후 케이스별 동작이나 정책에 대한 설명은 병렬적으로 정리된다. 그리고 모든 케이스를 다 정리해 둔 뒤에 각각의 요구사항을 우선순위와 빈도를 중심으로 일부를 제외하는 방식이다.

  모든 케이스는 발생확률과 중요도가 달라도 1로서의 가치를 가진다. 물론 개발적인 부분에서는 여전히 케이스를 개발하고 말고는 동등한 무게를 가진다. 그래서 UserStory 방식은 이러한 동등한 무게를 가진 케이스를 아예 없애버리는 것이 가능해진다.

중요도에 따라서 MVP를 걸러내기 쉬운 Userstory

 Userstory는 계층적 체계를 가진다.

사용자는 주문을 할 수 있다.

최초의 Userstory는 너무나 넓어서 개발할 수 있는 기준이 될 수 없는 정도로 광범위하다. 그런데 이 중에서 주문을 하는 상세 Userstory를 쪼개나가면 계층이 생긴다. 위의 Userstory를 Epic이라고 한다면, 그 사위의 story나 task를 더 세분화할 수 있다.

사용자는 할인을 적용하여 주문할 수 있다

사용자는 배송유형을 변경하여 주무할 수 있다.

사용자는 배송지를 변경하여 주문할 수 있다.

사용자는 카드 결제수단으로 결제할 수 있다.

 등등 다양한 세분화에서, 배송유형 하나만 놔도 '배송,배달,픽업'으로 나눠질 수 있고,  같은 레벨로 쓰여있던 배송지를 변경할 수 있다는 기능은 '배송'이나 '배달'일 경우에만 유효해진다.  그래서 상위의 계층의 Userstroy 문장은 하위의 케이스를 나눌 수 있는 대표성이 있어야 한다. 기능이라기 보다는 What(무엇)에 해당 된다.

그런데, 이렇게 대표성을 띄면, 잘 되는 것이 하나 있었다. 바로 삭제!

이 사이트가 너무너무 초창기라 주문은 시스템 없이 수기로 입금확인을 한다고 치면, 결제할 수 있다는 스토리도 날려버릴 수 있다. 이 지점에서 머리 속이 번쩍했다.

 앞쪽에서 Userstory의 중요성이 명확하지 않으면 문장 자체가 삭제되고, 이에 하위에서 기다리고 있던  과도하고 세세한 케이스 단위의 정책 요구사항들은 없어질 수 있다!  우리는 MVP 방식을 이야기할 때 가장 중요한 것은 제거인데, Userstory는 잘만 활용하면 제거하기에 유리한 구조다.

주니어 시절에 프로젝트를 익힐 때는 SB를 쓰는 것이 좋다..

 SB의 방식은 주니어 입장에서 세세하고 꼼꼼하게 빠지지 않고 케이스를 볼 줄아는 연슴을 하기에 굉장히 좋은 방식이다. Userstory도 너무 상위 레벨로만 쓴다면 개발을 할 수가 없다. 만들기로 한 거대한 레벨의 Epic이라면 그 하위에는 SB와 마찬가지로 세세한 정책이 있어야 한다. SPEC의 문서를 따로 만들어서라도 이런 내용을 정리하고 쓸 수 있는 실력은 있어야 한다.

  SB는 그런 점에서 주니어들에게 굉장히 필요한 과정이다. UI와 동작을 일일이 눈으로 보면서 고민할 수 있기에 빠지는 케이스없이  만들기에 유용하다.

  얼마전 강연에 나오셨던 20년차 네이버 기획자분도 SB가 있어야 케이스가 누락없이 잘 정리될 수 있다는 이야기를 했다. SB를 더 오랜기간 써온 사람으로서 이 부분도 굉장히 공감간다. 이 감각이 없다면 처음부터 좋은 Userstory를 쓰고 이를 프로젝트에 잘 활용하기 더 어려울 것 같다.

그래서...

 어떤 문서방식이 더 좋냐는 질문에 대해서는 상황과 본인 실력에 따라서 다를 것 같다. 아주 작은 일이라고 해도 주니어기 때문에 개발 케이스에 대해서 본인의 이해를 높이고 고민을 세세하게 하고 싶다면 SB방식을 통해서 모든 케이스를 동작까지 꼼꼼하게 살펴보며 모든 정책의 중요도를 1로 놓고 고민해보는 시간이 성장에 필수적이다.

 그러나 이제  스펙정의나 케이스를 인지하고 해결하는 것에 익숙하다면, 모든 요구사항을 Userstory를 통해서 계층적으로 정리해보면서 진짜 꼭 만들어야 하는 개발대상(What)을 구분해내는 능력을 키워야 하는 것 같다.

 어쩐지.. PO라도 SB를 써도 되고, 서비스기획자라고 Userstory를 쓰는 것을 이상하게 생각할 필요는 없는 것 같다.