이 기사의 결론

• 스토리 포인트(Story Point)는 객관적인 측정값이 아니라, 불완전한 정보와 팀의 경험으로부터 도출하는 주관적인 상대 추정임
• 과거 사례 검색, 상대 비교, 가채점, 근거 정리, 불확실성 탐지는 AI로 이관할 수 있음
• 인간은 AI가 취득할 수 없는 문맥을 보완하고, 인식 차이를 해소하며, 최종적인 사이징(Sizing)에 책임을 짐

애자일(Agile) 개발에서는 프로덕트 백로그(Product Backlog) 항목의 규모를 나타내기 위해 스토리 포인트가 널리 사용되고 있습니다.

하지만 스토리 포인트는 작업 시간이나 코드량처럼 객관적으로 측정할 수 있는 수치가 아닙니다. 팀이 과거의 경험, 유사 안건, 작업량, 복잡성, 리스크, 불확실성을 재료로 삼아 결정하는 주관적인 상대 추정입니다.

다시 말해, 스토리 포인트는 구조화된 짐작입니다.

많은 팀에서는 여러 개발자(Developers)가 플래닝 포커(Planning Poker) 등을 사용하여 모든 티켓에 대해 1차 추정부터 논의해 왔습니다. 하지만 과거의 티켓, Pull Request, 확정된 스토리 포인트, 코드베이스(Codebase), 테스트, 장애 기록을 AI가 참조할 수 있게 된 현재, 모든 사람이 매번 제로 베이스에서 1차 추정을 수행할 필요가 있을까요?

본고의 제안은 AI에게 최종 결정을 통째로 맡기자는 것이 아닙니다.

모두가 제로 베이스에서 숫자를 생각하는 프로세스를 그만두고, AI가 1차 추정을 만들면 인간은 불확실한 안건만을 논의하는 것입니다.

'짐작'이라는 말에는 '근거 없는 적당한 숫자'라는 인상이 있지만, 본고에서는 그런 의미로 사용하지 않습니다. 본고에서의 짐작은 다음과 같은 추정을 가리킵니다.

객관적인 계산식으로는 답을 확정할 수 없기 때문에, 불완전한 정보, 과거의 경험, 유사 안건, 기술적 리스크, 불확실성을 재료로 하여 수행하는 추정

스토리 포인트에는 다음과 같은 보편적인 계산식이 존재하지 않습니다.

변경 파일 수
×
변경 코드 행 수
...

동일한 티켓이라 하더라도 다음 조건이 다르면 포인트가 변합니다.

스토리 포인트는 누가 측정하더라도 같은 값이 되는 물리량이 아닙니다. 팀 고유의 판단 기준에 의해 결정되는 상대적인 추정치입니다.

전문적으로 표현하면 '프로젝트 고유·팀 고유의 주관적인 상대 추정'이지만, 본고에서는 보다 실태에 가까운 말로 '구조화된 짐작'이라고 부릅니다.

'추정은 추측이다'라는 생각은 AI 시대가 되어 갑자기 생겨난 것이 아닙니다.

Jonathan Rasmusson의 『The Agile Samurai』에서는 추정을 다루는 장에 다음과 같은 제목이 붙어 있습니다.

Estimation: The Fine Art of Guessing

출판사인 Pragmatic Bookshelf는 이 장의 발췌본을 PDF로 공식 공개하고 있습니다.

이 장에서는 초기 고수준 추정을 bad guesses라고 표현하며, 첫 번째 추정을 과도하게 신뢰하지 말 것을 설명하고 있습니다. 그 위에서 제시되는 방법은 다음과 같습니다.

애자일의 추정은 미래를 정확히 맞히는 기술이 아닙니다. 추정이 틀리는 것을 전제로, 상대 비교와 실적 데이터에 의해 계획을 갱신하는 메커니즘입니다.

스토리 포인트는 짐작을 배제하는 도구가 아니라, 불확실한 추정을 팀 내에서 비교·갱신하기 쉬운 형태로 변환하는 메커니즘입니다.

Mike Cohn은 스토리 포인트를 프로덕트 백로그 항목을 완료하기 위해 필요한 노력의 상대적인 추정치로 설명하고 있습니다.

스토리 포인트에 영향을 미치는 요소는 주로 4가지입니다.

여기서 중요한 것은 스토리 포인트가 '며칠이 걸리는가'를 직접 나타내는 것이 아니라는 점입니다.

예를 들어, 과거에 완료된 기준 스토리가 3포인트였다고 가정해 봅시다.

기준 스토리:
기존 API 항목을 화면에 1개 추가한다
→ 3포인트

새로운 스토리에 API 변경, 캐시 업데이트, 하위 호환성 확인이 추가되는 경우, 기준 스토리보다 크다고 판단합니다.

신규 스토리:
화면에 항목을 추가한다
+
...

이는 절대적인 측정이 아니라 과거 안건과의 비교입니다. 그리고 대량의 과거 안건에서 유사 사례를 찾아 차이점을 정리하는 처리는 AI가 잘하는 영역입니다.

Scrum과 스토리 포인트는 분리해서 생각해야 합니다.

Scrum Guide 2020은 스토리 포인트(Story Point) 사용을 필수 사항으로 규정하고 있지 않습니다. 규정하고 있는 것은 Product Backlog Item에 사이즈를 매기는 책임입니다.

실제로 작업을 수행할 Developers가 사이징(Sizing)에 대한 책임을 집니다.

실제로 작업을 수행하는 Developers가 사이징에 책임을 집니다. Scrum.org 또한 스토리 포인트는 Scrum의 필수 요소가 아니라고 설명하고 있습니다.

AI를 도입하는 경우에도 책임 분담은 변하지 않습니다.

AI가 1차 추정치를 생성하더라도 Scrum Guide와 모순되지 않습니다. AI는 사이징을 위한 지원 수단이며, 최종 책임은 Developers에게 남기 때문입니다.

이 부분은 명확히 구분해야 합니다.

1차 추정치 생성
≠
최종적인 사이징 책임

Planning Poker에서는 여러 멤버가 각자 포인트를 제시합니다. 3, 5, 8처럼 가까운 값으로 모이기도 하고, 3과 13처럼 크게 갈리기도 합니다.

A님:
기존 API를 이용할 수 있으므로 3포인트
B님:
...

이때 정말 가치 있는 것은 최종적으로 8포인트로 결정되었다는 사실이 아닙니다. 다음의 인식 차이가 발견되었다는 점에 가치가 있습니다.

구버전 대응에 대한 인식이 일치하지 않음
데이터 이관 필요 여부가 확정되지 않음
완료 조건(Definition of Done)이 공유되지 않음

Scrum.org도 추정은 대화와 공동 이해를 돕기 위한 것이며, 확정적인 약속이 아닌 예측이라고 설명합니다.

AI를 도입하더라도 인식 맞추기(Alignment) 과정까지 삭제해서는 안 됩니다.

삭감해야 할 작업은 모든 티켓에 대해 구성원 모두가 매번 제로 베이스에서 숫자를 생각하는 공정입니다. 남겨두어야 할 대화는 불확실성, 전제 조건, 기술적 리스크, 스코프(Scope)에 대해 인식 차이가 있는 안건에 대한 논의입니다.

AI의 역할은 대화를 없애는 것이 아니라, 인간이 대화해야 할 안건과 논점을 사전에 선별하는 것입니다.

스토리 포인트의 1차 추정은 여러 개의 작은 처리로 구성됩니다.

AI는 최종 결정자에는 적합하지 않습니다. 반면, 판단 재료의 검색, 비교, 정리에는 적합합니다.

AI는 전 건을 1차 분석합니다.

인간은 예외와 불확실성을 판단합니다.

AI나 머신러닝(Machine Learning)을 통한 스토리 포인트 추정은 이미 여러 연구를 통해 검증되었습니다. 다만, 현시점에서 "AI가 항상 인간보다 정확하다"라고 증명된 것은 아닙니다.

연구를 통해 알 수 있는 범위는 다음과 같습니다.

• AI를 통한 1차 추정은 유망하다
• 프로젝트 고유의 과거 사례를 제공하면 개선된다
• 인간을 완전히 배제하는 방식에는 한계가 있다

J.P. Morgan AI Research의 연구에서는 GPT-4에 제공하는 과거 사례의 수와 조합을 최적화하여 스토리 포인트를 추정하고 있습니다.

3개의 데이터셋을 사용한 예비 실험에서는 과거 사례를 적절히 선택함으로써, 제로샷(Zero-shot)과 비교했을 때 평균 절대 오차(MAE)가 평균 59.34% 개선되었다고 보고되었습니다.

여기서 읽어내야 할 점은 단순히 AI에게 티켓을 넘기기만 하면 되는 것이 아니라는 사실입니다.

정도를 좌우하는 것:
어떤 과거 사례를 선택할 것인가
몇 건의 과거 사례를 제공할 것인가
...

1차 추정 AI를 만들 경우에는 무관한 과거 안건을 대량으로 전달하는 것이 아니라, 비교 기준으로 유효한 안건을 선택해야 합니다.

이 연구는 예비적인 결과이며, 대상 프로젝트나 모델 수가 한정되어 있습니다. 59.34%라는 수치를 그대로 모든 프로젝트에 일반화할 수는 없습니다.

2025년 연구에서는 16개 프로젝트, 23,313건의 인간 추정 데이터를 사용하여 비교 학습(Comparative Learning)을 통한 스토리 포인트 추정을 검증하고 있습니다.

이 방식에서는 인간에게 직접 "몇 포인트입니까?"라고 묻는 대신, 두 항목을 비교하게 합니다.

태스크 A와 태스크 B 중,
어느 쪽이 더 많은 공수를 필요로 하는가

비교 결과를 사용하여 프로젝트 고유의 추정 모델을 구축합니다. 이는 스토리 포인트의 본질인 상대적 비교와 일치하는 사고방식입니다.

새로운 티켓에 대해 처음부터 5포인트나 8포인트를 직접 맞히게 하는 것이 아니라, 다음 순서로 판단하게 합니다.

이 태스크는 3포인트 기준 사례보다 큰가
↓
5포인트 기준 사례와 비슷한 정도인가
...

AI에게 직접 숫자를 내놓게 하는 것보다, 과거 사례와의 대소 관계를 먼저 설명하게 하는 것이 근거를 확인하기 더 쉽습니다.

2026년의 연구에서는 4종류의 LLM을 16개의 소프트웨어 프로젝트에서 평가했습니다.

학습 데이터를 주지 않는 제로샷 (Zero-shot)에서도, 프로젝트 데이터의 80%를 학습한 비교 대상인 지도 학습 (Supervised Learning) 모델을 상회하는 결과가 보고되었습니다. 나아가, 프로젝트 고유의 과거 사례를 5건 제공하는 퓨샷 (Few-shot)을 통해 추정 성능과 랭킹 성능이 개선되었습니다.

특히, 빈번하게 발생하는 포인트만 주는 것보다 포인트 척도 전체를 커버하는 다양한 사례를 주는 것이 유효했다고 합니다.

나쁜 예:
3포인트 사례
3포인트 사례
...

좋은 예:
1포인트 대표 사례
3포인트 대표 사례
...

이 논문은 프리프린트 (Preprint)입니다. 대상이 16개 프로젝트와 4종류의 LLM으로 한정되어 있으며, 프롬프트 설계에 따른 결과 변동도 연구상의 제약으로 기재되어 있습니다. 확립된 업계 표준이 아니라, AI를 통한 1차 추정의 유망성을 보여주는 연구로 다룰 필요가 있습니다.

2026년 ICPC에서 발표된 연구에서는 23개의 오픈 소스 프로젝트를 대상으로 RAG를 사용한 스토리 포인트 추정을 검증했습니다.

RAG를 사용하는 방식에서는 새로운 태스크와 유사한 과거 태스크를 검색하고, 그 태스크와 과거 포인트를 LLM에 전달합니다.

신규 티켓
↓
유사한 과거 티켓 검색
...

사람이 플래닝 포커 (Planning Poker)에서 과거 사례를 떠올리며 비교하는 방법과 유사한 사고방식입니다.

연구에서는 일부 프로젝트에서 기존 수법을 상회했으나, 기존 수법에 대한 통계적으로 유의미한 우위성은 확인되지 않았습니다. 또한, 인간의 판단을 완전히 제외하면 성능이 제한될 가능성이 있다고 지적했습니다. 반면, 유사한 과거 사례를 제시하여 개발자 (Developers)의 의사결정을 지원하는 용도로는 유효하다고 결론지었습니다.

본고의 제안과 일치하는 부분입니다.

AI를 최종 결정자로 만드는 것이 아닙니다.

AI를 유사 사례와 판단 재료를 제시하는 1차 추정 담당자로 만드는 것입니다.

AI에게 단일 포인트만 내놓게 하는 설계는 불충분합니다.

추정: 5포인트

이것만으로는 다음 사항을 알 수 없습니다.

왜 5포인트인가
무엇과 비교했는가
어떤 전제에 의존하고 있는가
...

AI가 내놓아야 하는 것은 포인트뿐만 아니라 판단 재료입니다.

AI의 일은 포인트를 맞히는 것만이 아닙니다. 추정의 근거와 불확실성을 구조화하고, 인간이 논의해야 할 안건을 선별하는 것입니다.

기존 프로세스는 다음과 같았습니다.

AI 도입 후에는 다음과 같은 형태로 변경할 수 있습니다.

인간을 완전히 배제하는 것이 아닙니다. 인간의 작업을 모든 건에 대한 초기 추정에서 예외 안건의 판단으로 옮깁니다.

AI에게 일반론만으로 추정하게 하면 팀 고유의 포인트 척도와 어긋납니다. 먼저 이미 완료된 대표적인 스토리를 선택합니다.

기준 스토리는 추상적인 설명만으로는 불충분합니다. 가능하다면 다음 정보를 연결합니다.

Issue
Pull Request
변경된 파일
...

작은 포인트의 사례만 대량으로 주는 것이 아니라, 포인트 척도 전체를 커버합니다.

최소한 다음 정보가 필요합니다.

티켓 본문만으로 판단하게 하면 정보 부족을 AI가 추측으로 보완할 위험이 있습니다. 정보가 부족한 경우에는 무리하게 숫자를 내지 않고 '추정 불가'라고 답변할 수 있도록 합니다.

다음은 범용적으로 사용할 수 있는 프롬프트입니다.

당신은 애자일 개발 팀의 스토리 포인트 1차 추정 담당자입니다.
목적은 최종적인 스토리 포인트를 결정하는 것이 아닙니다.
프로젝트 고유의 과거 사례와 비교하여 개발자 (Developers)가 확인할 수 있도록
...

다음은 가상의 예시입니다.

도서 상세 화면에 '배포 상태'를 추가한다.
API에는 배포 상태 항목이 이미 존재한다.
화면 표시와 로컬 캐시 저장이 필요하다.
...

1차 추정

추정 스토리 포인트: 5
추정 범위: 3~8
...

이러한 출력이 있다면, 인간은 처음부터 "3인지, 5인지, 8인지"를 고민할 필요가 없습니다. 확인해야 할 논점이 캐시 이관과 오프라인 요구사항이라는 점도 알 수 있습니다.

AI의 1차 추정에는 새로운 문제도 있습니다. AI가 처음에 "3포인트"라고 표시하면, 인간은 그 숫자에 끌려가게 됩니다.

이것은 앵커링 (Anchoring)이라고 불리는 인지 편향입니다. 소프트웨어 개발자를 대상으로 한 실험에서도, 처음에 제시된 수치가 이후의 공수 추정에 영향을 미친다는 것이 확인되었습니다.

따라서 AI의 출력에서는 처음에 포인트만을 강조해서는 안 됩니다. 권장되는 확인 순서는 다음과 같습니다.

1. 유사 사례
2. 전제 조건
3. 미확인 사항
...

고위험 사례에 대해서는, 인간이 AI의 포인트를 보기 전에 독립적인 추정치를 기록하는 방법도 있습니다.

인간의 독립 추정
+
AI의 1차 추정
...

AI를 도입해도 인지 편향은 사라지지 않습니다. 인간 사이의 앵커링이 AI에서 인간으로의 앵커링으로 바뀔 뿐일 가능성이 있습니다.

모든 티켓을 플래닝 포커 (Planning Poker)로 가져갈 필요는 없습니다. 다음 조건에 해당할 때만 인간에 의한 논의를 필수적으로 합니다.

저위험이며 기준 사례와의 대응이 명확한 사례는 짧은 확인만으로 확정됩니다. 고위험 사례에 대해서는 기존 방식대로 개발자 (Developers)가 논의하고, 필요하다면 스파이크 (Spike)나 티켓 분할을 수행합니다.

AI가 "실제 작업 시간을 정확히 맞혔는가"만으로 평가하는 것은 적절하지 않습니다. 스토리 포인트는 시간 그 자체가 아니라, 팀 내의 상대적 척도이기 때문입니다.

도입 시에는 다음 지표를 기록합니다.

봐야 할 것은 AI 추정의 정답률만이 아닙니다.

인간의 시간을 절감하면서, 구현 전에 불확실성을 발견할 수 있었는가

제목만으로는 테스트, 이관, 호환성, 운영까지 판단할 수 없습니다. 설명, 수락 조건 (Acceptance Criteria), 관련 코드, 과거 사례를 포함해야 합니다.

스토리 포인트는 팀 고유의 것입니다. 일반적인 AI의 감각으로 5포인트라고 판단하더라도, 그 팀의 5포인트와는 일치하지 않습니다.

근거이나 불확실성을 표시하지 않으면 AI의 숫자를 검증할 수 없습니다. 또한 인간이 숫자에 앵커링되기 쉬워지기도 합니다.

AI는 팀의 암묵지나 조직 사정을 완전히 파악할 수 없습니다. 최종적인 사이징 (Sizing) 책임은 개발자 (Developers)에게 남겨둡니다.

과거 인간에 의한 추정에도 인식 부족이나 편향이 포함됩니다. 기준 사례는 정기적으로 검토하여, 현재의 완료 정의 (Definition of Done)나 기술 환경과 일치하는지 확인합니다.

다른 팀의 8포인트가 우리 팀의 8포인트와 같다고 단정할 수 없습니다. 모델이나 검색 대상은 원칙적으로 팀 또는 프로젝트 단위로 교정합니다.

추정 과정에서의 대화에는 가치가 있습니다. 다만, 모든 사례에 대해 모든 사람이 처음부터 숫자를 생각할 필요는 없습니다.

AI가 사전에 논점을 정리하고, 추정이 갈릴 것 같은 사례에 대해서만 인간이 논의하는 편이 대화의 밀도를 높일 수 있습니다. 절감하는 것은 대화가 아니라, 기계적인 검색과 비교 작업입니다.

그렇습니다. 그렇기에 최종 결정을 AI에게 맡기지 않습니다. AI가 부족한 문맥을 밝혀내고, 인간이 이를 보충하는 설계로 만듭니다.

AI에게 입력할 수 없는 암묵지가 발견되는 것 자체가 문서나 티켓의 개선 재료가 됩니다.

유사 사례의 이슈 ID (Issue ID), 풀 리퀘스트 (Pull Request), 변경 파일 등 검증 가능한 근거를 필수적으로 합니다. 근거가 존재하지 않는 경우에는 추정 불가능하다고 답변하게 합니다.

AI가 자유롭게 이유를 지어낼 수 있는 설계로 만들어서는 안 됩니다.

최종적인 사이징은 개발자 (Developers)가 수행합니다. AI는 IDE, 정적 분석, 테스트 도구와 마찬가지로 개발자가 판단하기 위해 이용하는 도구입니다. 1차 안의 생성과 최종적인 책임은 분리해서 생각해야 합니다.

스토리 포인트를 사용하지 않는 팀도 있습니다. 처리량 (Throughput), 사이클 타임 (Cycle Time), 몬테카를로 시뮬레이션 (Monte Carlo Simulation) 등 실적 데이터로부터 확률적으로 예측하는 방법도 있습니다.

본 글은 모든 팀에 스토리 포인트를 권장하는 것이 아닙니다. 이미 스토리 포인트를 사용하고 있는 팀이 AI를 통해 운영 비용을 낮추는 방법을 다루고 있습니다.

스토리 포인트는 객관적으로 측정할 수 있는 진실된 숫자가 아닙니다. 인간이 과거의 경험, 유사 사례, 작업량, 복잡성, 리스크, 불확실성을 재료로 하여 수행하는 상대적인 추정 (Estimation)입니다.

그 안에는 AI가 잘하는 처리가 대량으로 포함되어 있습니다.

과거 티켓 찾기
유사 사례 비교하기
변경 범위 정리하기
...

이것들을 매번 모든 사람이 처음부터 수행하는 합리성은 낮아지고 있습니다.

반면, AI가 취득할 수 없는 정보도 있습니다.

팀 고유의 암묵지 (Tacit Knowledge)
조직 간의 조정 상황
사양서에 적혀 있지 않은 운영 방식
...

AI 시대의 역할 분담은 다음과 같은 형태가 됩니다.

"1차 추정은 AI의 업무"라는 주장은 AI가 항상 더 옳다는 의미가 아닙니다.

AI가 전 건을 처리하고, 인간이 예외와 불확실성에 집중하는 것이 전문가의 시간을 합리적으로 사용할 수 있다는 의미입니다.

스토리 포인트는 객관적인 측정값이 아닙니다. 팀 고유의 경험과 불완전한 정보에 기반한 주관적인 상대 추정입니다.

『애자일 사무라이 (Agile Samurai)』 또한 초기 추정이 추측임을 전제로, 상대 비교와 실적에 의한 지속적인 업데이트를 제안하고 있습니다.

최근에는 LLM, 비교 학습 (Comparative Learning), Few-shot, RAG를 사용한 스토리 포인트 추정 연구가 진행되고 있습니다. 이러한 연구들은 AI에 의한 1차 추정이 유망하며, 프로젝트 고유의 과거 사례를 제공함으로써 개선될 가능성이 있음을 보여줍니다. 반면, 인간을 완전히 배제한 자동 추정이 항상 기존 수법을 능가한다는 점은 입증되지 않았습니다.

현시점에서 합리적인 결론은 다음과 같습니다.

스토리 포인트는 인간이 수행해 온 구조화된 짐작이다.

1차 추정 생성, 과거 사례와의 비교, 근거 정리, 불확실성 탐지는 AI의 업무로 만든다.

인간은 AI가 이해할 수 없는 문맥을 보완하고, 인식 차이를 해소하며, 최종적인 사이징 (Sizing)에 책임을 진다.

AI 시대에 재검토해야 할 것은 스토리 포인트 그 자체만이 아닙니다.

모든 사람이 모든 안건에 대해 매번 처음부터 숫자를 생각해야 하는가. 재검토해야 할 것은 바로 이 전제입니다.