[Software Enginnering] 애자일(Agile) 요구사항 관리: 유저 스토리와 일정 산정의 기술

"기능 개발하는데 며칠이나 걸리나요?"

 

개발자라면 기획자나 PM에게 이 질문을 받을 때마다 스트레스를 받을 것이다. 코드를 한 줄도 짜보기 전인데, 우리는 알 수 없는 변수(레거시 코드, 인프라 세팅, 타 부서 연동)들을 머릿속으로 굴리며 방어적인 날짜를 부르기 바쁘다.

 

이번 포스팅에서는 파이프라인에 들어가는 작업(티켓)의 크기를 어떻게 정의하고 일정을 산출할 것인가에 대해 다룬다. 애자일에서는 전통적인 맨먼스(Man-Month) 방식의 환상을 버리고, 유저 스토리와 스토리 포인트를 활용한다.

 

1. 단순한 기능 명세가 아닌 유저 스토리(User Story)

전통적인 워터폴 환경의 요구사항 명세서는 주로 시스템 관점에서 작성된다. "회원가입 API를 만든다.", "DB에 유저 정보를 인서트한다." 같은 식이다. 이런 티켓을 받은 개발자는 목적도 모른 채 기계적으로 테이블을 굽고 API를 찍어낸다.

 

반면, 애자일에서는 유저 스토리(User Story)라는 포맷을 사용한다.

    As a [어떤 사용자/고객]은

    I want to [어떤 기능/동작]을 원한다.

    So that[어떤 가치/이유]를 얻기 위해서다.

 

왜 개발자에게 유저 스토리가 필요한가?

기획팀에서 소셜 로그인 API 생성을 요청했다고 가정해보자.

 - 단순 기능 명세로 접근할 때 : 개발자는 구글, 카카오, 네이버 연동을 모두 고려하여 거대한 OAuth2 Provider 팩토리 패턴을 며칠에 걸쳐 설계한다. (오버 엔지니어링)

 

 - 유저 스토리로 접근할 때 : [10대 모바일 사용자]는 [카카오 1초 로그인]을 원한다. [복잡한 비밀번호 찾기 과정을 피하기 위해서]다.

 -> 이 스토리를 읽은 개발자는 "타겟이 10대 모바일 유저고 빠른 진입이 핵심이구나. 당장 구글/네이버 확장은 필요 없으니 OCP는 고려하되 카카오 연동만 가장 심플하고 빠르게 배포하자" 라고 엔지니어링 방향과 아키텍처의 범위를 스스로 결정할 수 있게 된다.

 

2. 맨먼스(Man-Month)의 환상과 스토리 포인트(Story Point)

소프트웨어 공학의 고전 <맨먼스 미신>이 증명했듯, "개발자 2명이 투입되면 개발 기간이 절반으로 줄어든다"는 것은 철저한 환상이다. 인간은 절대적인 시간(시간, 일 단위)을 추정하는데 매우 취약하다.

그래서 애자일에서는 시간을 버리고 스토리 포인트(Story Point)라는 상대적 크기를 사용한다. 보통 피보나치수열(1,2,3,5,8...)을 사용한다.

 

 - 상대적 추정의 원리 : "이 API 개발에 며칠 걸려요?" 라는 질문에는 답하기 엉렵지만, "저번에 만들었던 [장바구니 API]가 3포인트였는데, 이번 [결제 API]는 그것보다 복잡할까요?"라고 물으면 개발자들은 "결제는 외부 PG사 연동이 있고 트랜젝션도 복잡하니 8포인트 줍시다"라고 쉽게 합의할 수 있다.

 

 - 복잡도와 불확실성 반영 : 스토리 포인트는 단순한 시간이 아니라, 작업량(Volume) + 복잡도(Complexity) + 불확실성(Risk)의 종합 점수다.

 

3. 팀 단위의 합의 과정 : 플래닝 포커 (Planning Poker)

스프린트 플래닝 시간에 스토리에 포인트를 부여할 때, 가장 널리 쓰이는 기법이 플래닝 포커다. 팀원 전원이 카드를 엎어두고, PO(Product Owner)의 스토리 설명을 들은 뒤 동시에 카드를 뒤집어 점수를 공개한다.

이 기법의 진짜 가치는 평균 점수 내기가 아니다. 점수가 크게 엇갈렸을 때 발생하는 대화에 있다. 대화를 통해 주니어는 시스템의 레거시 구조를 학습하게 되고, 팀 전체가 티켓에 숨겨진 기술적 리스크(불확실성)를 사전에 인지하게 된다. 만약 혼자서 시간을 산정했다면 배포 당일에 서버가 터지는 대참사가 일어났을 것이다.

 

4. 결론

스토리 포인트와 일정 산정은 피로 맺은 계약서가 아니다. 이는 어디까지나 팀이 이번 스프린트에 얼마만큼의 일을 안정적으로 소화할 수 있을지 예측하기 위한 가늠자일 뿐이다.

 

 - 경고 : 경영진이나 PM이 팀의 스토리 포인트 소화량(Velocity)을 개발자의 인사 고과나 성과 측정도구로 무기화하는 순간 애자일은 망가진다. 개발자들은 혼나지 않기 위해 2포인트짜리 일을 8포인트로 부풀리기 시작할 것이다.

 

 - 엔지니어의 자세 : 개발자는 요구사항을 받을 때 명목적으로 답하는 습관을 버려야 한다. 유저 스토리를 통해 비즈니스 목적을 파악하고, 플래닝 포커를 통해 숨겨진 아키텍처 리스크를 팀원들과 끄집어내어 공유하는 것. 이것이 주니어 코더와 시니어 엔지니어를 가르는 중요한 기준이다.