스토리 포인트는 왜 항상 들쭉날쭉할까: 측정 단위가 아닌 '느낌'의 함정

애자일의 스토리 포인트, 정말 객관적인 단위일까요?

스크럼이나 칸반을 한 번이라도 해본 분이라면 "스토리 포인트(Story Point)"라는 말을 들어보셨을 거예요. 이게 뭐냐면, 어떤 작업이 얼마나 복잡하고 시간이 걸릴지를 숫자로 표현한 단위거든요. 보통 1, 2, 3, 5, 8, 13 같은 피보나치 수열을 써서 "이 티켓은 3점짜리야", "저건 8점짜리네" 하고 추정해요. 시간(시/일)으로 직접 추정하면 부담스러우니까, 추상적인 점수로 "상대적 크기"만 비교하자는 아이디어에서 출발한 방식이에요.

그런데 힐렐 웨인(Hillel Wayne)이라는 형식 검증 분야의 베테랑이 "이거 사실 굉장히 이상한 단위 아니냐"고 짚는 글을 올렸어요. 현장에서 일해본 분들은 한 번쯤 느꼈을 거예요. 분명 같은 "5점"인데 어떤 팀에서는 반나절짜리 작업이고, 어떤 팀에서는 일주일 걸리는 일이 되어 있는 경험 말이에요.

포인트는 왜 일관되지 않을까

스토리 포인트의 핵심 주장은 "시간이 아니라 복잡도를 측정한다"는 거예요. 그래서 새 팀원이 들어와도, 기술 스택이 바뀌어도 포인트 값 자체는 변하지 않아야 한다는 거죠. 그런데 실제로는 그렇지 않아요. 똑같이 "로그인 화면 만들기"라는 작업이라도 React에 익숙한 팀에는 2점이지만, 처음 써보는 팀에는 8점이 되거든요. 결국 "복잡도"라는 게 팀의 숙련도, 코드베이스의 상태, 도구의 친숙함에 따라 다 달라진다는 뜻이에요.

웨인이 지적하는 또 다른 문제는 포인트가 합산되지 않는다는 점이에요. 보통 단위라는 건 1m + 1m = 2m처럼 더할 수 있어야 하잖아요? 그런데 3점짜리 작업 두 개가 모이면 6점이 아니라 13점처럼 느껴질 때가 많아요. 두 작업이 서로 영향을 주거나, 컨텍스트 스위칭 비용이 들거나, 통합 테스트가 추가되면서 비선형적으로 늘어나거든요. 반대로 비슷한 작업을 여러 개 묶으면 오히려 효율이 올라서 합보다 적게 걸리기도 해요.

게다가 포인트는 팀마다 단위 길이가 달라요. A팀의 5점과 B팀의 5점은 완전히 다른 크기인데, 경영진은 종종 "전사 평균 속도(velocity)"를 비교하면서 "A팀이 B팀보다 생산성이 낮네" 같은 결론을 내리기도 해요. 이건 마치 미국의 갤런과 영국의 갤런이 다른데도 같은 단어를 쓴다고 똑같다고 우기는 거랑 비슷한 상황이에요.

그럼 왜 아직도 쓸까

이렇게 허술한 단위인데도 스토리 포인트가 살아남은 이유가 있어요. 시간으로 추정하면 약속처럼 받아들여진다는 게 가장 큰 이유예요. "이거 3일 걸려요"라고 하면 매니저는 3일째에 "왜 안 끝났냐"고 묻기 시작하거든요. 반면 "3점이에요"라고 하면 그게 정확히 며칠인지는 평균 속도에 따라 사후적으로 계산되니까, 개발자 입장에서는 심리적 압박이 덜해요.

또 하나는 상대적 비교가 절대적 추정보다 쉽다는 점이에요. 사람은 "이 작업이 정확히 4시간 걸린다"고 말하기는 어렵지만, "이 작업이 저 작업보다 두 배쯤 복잡하다"고는 비교적 쉽게 말할 수 있거든요. 그래서 포인트는 추정의 부정확성을 인정하면서도 우선순위를 잡을 수 있는 도구로 쓰이는 거예요.

업계의 대안들

사실 스토리 포인트의 한계를 인식한 팀들은 다른 방식을 시도하고 있어요. 베이스캠프(Basecamp)의 "Shape Up" 방법론은 포인트 대신 "appetite(식욕)"라는 개념을 써요. "이 문제에 우리가 얼마나 시간을 쓸 가치가 있냐"를 6주 또는 2주 같은 고정된 박스로 정하고, 그 안에서 해결할 수 있는 범위로 문제를 빚어내는(shape) 방식이에요. 추정이 아니라 예산을 정하는 거죠.

또 다른 흐름은 "노 에스티메이트(No Estimates)" 운동이에요. 아예 추정 자체를 하지 말고, 그냥 작업을 비슷한 크기로 잘게 쪼개서 흘려보내자는 거예요. 티켓 개수를 세는 게 포인트를 합산하는 것보다 더 정확한 예측을 준다는 데이터도 꽤 있거든요. GitHub이나 일부 OSS 프로젝트들은 이미 이 방향으로 가고 있어요.

한국 개발자에게 주는 시사점

국내 IT 회사들도 대부분 지라(Jira)에서 스토리 포인트를 쓰고 있죠. 그런데 "우리 팀 평균 속도가 30점이니까 다음 스프린트는 30점만 받자" 같은 운영을 하다 보면 결국 점수 인플레이션이 일어나요. 매니저가 압박하면 같은 작업이 3점에서 5점, 5점에서 8점으로 슬며시 부풀어 오르거든요. 이건 단위로서의 의미를 완전히 잃은 상태예요.

실무에서 적용할 만한 팁은 이래요. 포인트를 팀 내부의 대화 도구로만 쓰고, 부서 간 비교나 평가 지표로는 절대 쓰지 마세요. 그리고 추정이 어렵다면 "이 작업이 하루 안에 끝날지, 하루 넘게 걸릴지"만 분류하는 T-shirt sizing(S, M, L) 방식도 좋아요. 정밀한 척하는 숫자보다 솔직한 카테고리가 더 정직하거든요.

마무리

스토리 포인트는 정밀한 척하지만 사실은 "느낌"에 가까운 단위예요. 문제는 단위 자체가 아니라, 그걸 절대적인 측정값처럼 다루는 조직 문화에 있다는 게 이번 글의 핵심이에요. 여러분의 팀에서는 스토리 포인트가 솔직한 대화를 돕는 도구로 쓰이고 있나요, 아니면 어느새 KPI가 되어버렸나요?