티셔츠 사이즈부터 토큰 견적까지?

제 입장에서 시작하겠습니다. 왜냐하면 나머지 글 전체가 이 입장에 달려 있기 때문입니다.

저는 추정(estimation)에 반대합니다. 오랫동안 그래왔습니다. 제 팀은 이미 추정을 멈추고 스프린트 플래닝(sprint planning)도 중단했으며, 저는 둘 다 다시 도입할 계획이 없습니다. 한 가지 남은 것이 있습니다. 즉, 상위 경영진이 무언가가 얼마나 큰지 물어볼 때, 우리는 여전히 티셔츠 사이즈로 답한다는 것입니다.

심지어 그것조차 잘못된 느낌을 주기 시작했습니다.

이전 기사에서 저는 코딩 에이전트(coding agents)가 마침내 Scrum을 죽이고 있다고 주장했습니다. 또 다른 글에서는여기 코드의 비용이 저렴해지면 검증(verification)이 비싸진다고 주장했습니다. 이 글은 두 가지 모두에서 파생됩니다. 만약 팀들이 더 이상 추정하지 않고, 코드를 생산하는 것이 더 이상 제약 조건이 아니라면, 조직이 여전히 '얼마나 큰가요?'라고 물어볼 때 우리는 무엇이라고 말해야 할까요?

저는 팀들에게 추정을 다시 도입하려고 하지 않을 것입니다. 저의 질문은 더 좁습니다. 만약 조직이 여전히 크기 신호(size signal)를 필요로 한다면, 그 신호는 무엇이어야 할까요?

제 가설은 **토큰 견적(token quotes)**이 티셔츠 사이즈를 대체할 수 있다는 것입니다.

제가 이 주장이 얼마나 많은 확신을 받을 자격이 있는지 조심스럽게 다루고 싶습니다. 이것은 발견(finding)이 아니라 가설입니다. 저는 실제 결과와 비교한 토큰 견적 데이터셋을 가지고 있지 않으며, 실험도 진행하지 않았습니다. 다음 내용 중 일부는 제가 이전에 제시했고 여전히 지지하는 주장들, 주로 검증이 병목 현상(bottleneck)이 되었다는 것입니다. 일부는 저 자신을 포함하여 아무도 테스트해 보지 않은 메트릭에 대한 추측입니다. 저는 이 두 가지를 분리하려고 노력할 것이며, 아이디어를 어떻게 테스트하고 무엇이 그것이 틀렸음을 보여줄 수 있는지에 대한 섹션을 포함했습니다. 이 글의 모든 숫자는 예시적인 것입니다.

컨텍스트에 대해서도 명확히 해야 합니다. 저는 스프린트 약속 없이 작업하는 것을 용인하는 조직에서 코딩 에이전트를 사용하여 대부분의 구현 작업을 수행하는 팀을 설명하고 있습니다. 많은 팀들이 그렇게 일하지 않으며, 이 부분은 마지막쯤 와서 이것이 적용되는 경우와 그렇지 않은 경우로 돌아옵니다.

추정(Estimation)은 결코 제대로 작동하지 않았다

우리 모두 그 문제점들을 알고 있습니다.

계획 오류(planning fallacy)는 우리가 계획 오류에 대해 알게 되더라도, 사물들이 걸리는 시간을 지속적으로 과소평가한다는 것을 말합니다. 호프스타터의 법칙(Hofstadter's Law)은 심지어 호프스타터의 법칙을 고려하더라도 항상 예상보다 더 오래 걸린다고 합니다. 수십 년간의 소프트웨어 프로젝트들은 이 두 가지 모두를 확인해 왔습니다.

스토리 포인트와 티셔츠 사이즈는 시간에서 벗어나도록 함으로써 이를 해결하고자 했습니다. 논리는 크기가 다른 작업과 상대적이어야 하며, 몇 시간을 예측할 수 있다고 가장하는 것을 멈추라는 것이었습니다. 그러다가 속도(velocity)가 등장하여 포인트를 다시 시간으로 되돌렸습니다. '우리는 스프린트당 30포인트를 처리하므로, 이 에픽은 네 번의 스프린트가 걸릴 것이다.' 상대적 추정은 추가 단계를 거치면서 다시 절대적 추정이 되었습니다.

#NoEstimates 운동은 원칙적으로는 옳았습니다. 하지만 스크럼(Scrum) 기사에서 주장했듯이, 조직들은 내재화해야 하는 원칙보다는 따를 수 있는 관행 쪽으로 기울어집니다. '추정하지 마라'는 원칙입니다. 조직들은 여전히 상자에 넣을 _무언가_가 필요하기 때문에, 그 상자는 포인트와 티셔츠로 채워졌습니다.

관리자들이 실제로 그 상자에서 무엇이 필요한지 질문할 가치가 있습니다. 때로는 정말 날짜일 수 있습니다: 계약, 규제 마감일, 마케팅 캠페인에 연결된 출시일 같은 것들입니다. 이 글은 그러한 경우들에 대해 유용한 내용을 아무것도 말해주지 못합니다. 하지만 제 경험상, 대부분의 경우 날짜를 요청하는 것은 다른 무언가를 대신하고 있습니다. 그들이 필요로 하는 것은 **상대적 크기 신호(relative size signal)**입니다. 이것이 저것보다 더 큰가요 아니면 작은가요? 대략 얼마나 차이가 나나요? 우리가 약속하기 전에 논의해야 할 아웃라이어 항목들은 무엇인가요? 그들은 그것을 우선순위 지정하고, 순서를 정하며, 예상보다 훨씬 큰 무언가가 있을 때 알아차리는 데 사용합니다.

크기 신호(size signal)는 얻고 싶은 합리적인 것이지만, 문제는 우리가 그것을 어떻게 생산해 왔는지이다.

왜 지금 T-셔츠 사이즈가 잘못된 느낌인가

T-셔츠 사이즈란 어떤 작업에 얼마나 많은 인간의 노력이 필요할지에 대한 인간의 직관이다. 코드베이스를 아는 사람이 티켓(ticket)을 보고, 과거 작업과 비교하며 "이건 M급이야"라고 말하는 식이다.

인간 구현 노력이 배포를 좌우하던 때는 이것이 말이 되었다. 하지만 더 이상 그렇지 않다.

코딩 에이전트(coding agents)가 등장하면서 구현 시간이 급격히 줄어들었고, 또한 신호 자체가 잡음이 되기도 한다. 동일한 티켓이라도 필요한 컨텍스트의 양, 탐색하는 막다른 길의 수, 의도가 얼마나 명확하게 표현되었는지에 따라 에이전트에게는 4분이 걸릴 수도 있고 40분이 걸릴 수도 있다. 시계 시간(wall-clock time)은 더 이상 유용한 신호가 아니다.

더 중요한 것은 제약 조건 자체가 이동했다는 점이다. When Code Gets Cheap, Verification Becomes Expensive에서 주장했듯이, 코드를 생산하는 것과 그것이 정확하다는 것을 확립하는 것은 두 가지 다른 활동이다. 에이전트들은 전자를 극적으로 저렴하게 만들었다. 하지만 후자에 대해서는 그렇지 못했다. 또는 my TPS article의 관점에서 볼 때, 이제 생산 속도가 검사(inspection) 속도를 앞지르고 있다.

따라서 T-셔츠 사이즈는 이제 과거보다 중요성이 떨어지는 양에 대한 직관적 추정치가 되었다. (전적으로 그렇지 않은 것은 아니다. 좋은 T-셔츠 사이즈에는 종종 리뷰와 위험이 조용히 포함되는데, 이는 토큰 인용만으로는 다룰 수 없는 지점이다.) 여전히 팀의 실제 시간이 소모된다: 누군가는 티켓을 읽고, 생각하고, 방에 있는 다른 사람들과 동의해야 한다. 그리고 그것은 절대 검증될 수 없다. 아무도 어떤 것이 "진짜로" L급이었는지 측정할 수 없다. 피드백 루프가 없기 때문에 추정치는 결코 개선되지 않는다.

인간 시간을 소모하고, 점점 잘못된 것을 측정하며, 개선될 수 없는 신호는 좋지 않은 거래처럼 보인다. 문제는 더 나은 것이 존재하는지 여부이다.

토큰 견적(The token quote)

**토큰 견적(token quote)**이란 작업이 시작되기 전에 이슈나 티켓에 할당되는 추정 토큰 범위입니다. 에이전트는 사전 검토 단계(pre-flight step)에서 이를 생성합니다. 즉, 티켓을 읽고 관련 리포지토리 부분을 탐색한 다음, 그 근거와 함께 범위(range)를 반환하는 것입니다. 코드는 작성되지 않습니다.

출력은 다음과 같을 수 있습니다 (예시적):

Token quote: 180K (P50) – 420K (P90)
Reasoning: 청구 모듈과 두 개의 API 계약에 영향을 미칩니다.
           청구(Billing)는 강력한 타입과 스키마를 가지고 있습니다; 알림(notification)은...

이것이 전부입니다. 유용한 부분은 이 신호가 무엇이고, 무엇이 아닌지입니다.

왜 달러가 아닌 토큰인가?

제가 처음 이 아이디어를 생각했을 때, 가장 당연한 움직임은 토큰을 돈으로 환산하는 것이었습니다. 토큰에는 가격이 있으니, "이 티켓은 약 20달러의 비용이 들 것입니다"라고 보고하면 안 될까요?

저는 그것이 실수라고 생각합니다.

달러 금액은 작업의 비용처럼 읽힙니다. 만약 관리자가 티켓 옆에서 20달러를 본다면, 그들은 20달러에 고정될 것입니다. 그들은 변경 사항을 검토하는 엔지니어, 이를 검증하는 제품 책임자(product owner), 통합, 조정 및 배포에 소요된 시간, 그리고 이후 운영 비용 등은 잊어버릴 것입니다. 토큰 비용은 전체 변경 비용의 아주 작은 부분입니다. 이것을 통화로 보여주는 것은 소프트웨어가 거의 무료로 구축되는 것처럼 보이게 하는 정확히 잘못된 결론을 초래합니다.

토큰은 의도적으로 추상적이기 때문에 그러한 함정을 피할 수 있습니다. "150만 토큰"은 예산 항목처럼 보이지 않으며, 아무도 그것을 기능(feature)의 비용으로 오해하지 않을 것입니다. 하지만 150만 토큰이 1만 토큰보다 훨씬 크다는 것은 누구나 볼 수 있습니다. 이 단위는 다른 어떤 것도인 척하는 대신 상대적 크기 신호로 작동합니다.

이것이 바로 티셔츠 사이즈가 되려고 했던 것과 정확히 같습니다. 목표는 토큰 견적이 유용한 속성(상대적 크기)은 유지하고, 오해를 불러일으키는 속성(비용에 대한 잘못된 정밀함의 감각)을 제거하는 것입니다. 이것이 정말로 올바른 상대적 크기를 포착하는지는 제가 아래에서 다시 다룰 열린 질문입니다.

토큰 견적이 티셔츠 사이즈보다 나을 수 있는 이유

팀에게는 아무 비용도 들지 않습니다. 에이전트가 견적을 산출합니다. 회의도, 플래닝 포커(planning poker)도, 정제 세션(refinement session)도 없습니다. 이것이 제가 추정 방식에 반대하는 사람으로서 이 아이디어가 마음에 드는 주된 이유입니다. 인간의 시간이 전혀 투입되지 않습니다. 이는 의식이 아니라 부산물입니다.

현실과 비교할 수 있습니다. 이는 티셔츠 사이즈나 스토리 포인트가 결코 가질 수 없었던 속성입니다. 이슈 트래커(Issue tracker)는 이미 작업이 시작된 시점과 완료된 시점을 기록하므로, 아무도 시간표를 작성하지 않아도 모든 견적을 티켓의 실제 **사이클 타임(cycle time)**과 비교할 수 있습니다. 처음으로 크기를 누군가 추정한 것이 아니라 측정된 결과와 비교할 수 있는 신호가 생기는 것입니다.

연속적인 척도에 있습니다. 티셔츠 사이즈는 다섯 개의 버킷을 가집니다. 토큰 견적은 이상치(outlier)를 단순히 큰 것과 구별해낼 수 있습니다.

만약 경영진이 익숙한 어휘에 집착한다면, 레이블은 직관적인 느낌 대신 토큰 대역에서 파생되어 유지될 수 있습니다. 예를 들면 (단지 예시적 임계값):

레이블은 그대로 유지됩니다. 그것을 만들어낸 회의만 사라지는 것입니다.

모든 것이 의존하는 가정

이 모든 것은 제가 아직 뒷받침할 수 없는 하나의 가정에 달려 있습니다. 즉, 토큰 견적이 경영진이 중요하게 생각하는 크기의 의미 있는 대리 지표(proxy)라는 것입니다. 아래에서 저는 '크기'를 티켓의 종단 간 사이클 타임으로 정의하겠습니다.

이에 대해 의심할 만한 좋은 이유들이 있습니다. 토큰은 _에이전트_가 얼마나 많은 작업을 했는지를 측정합니다. 그것은 _인간_이 얼마나 많은 작업을 할 것인지를 측정하지 않습니다. 인증 흐름(authentication flow)에 대한 한 줄 변경은 몇천 개의 토큰을 비용으로 발생시킬 수 있지만 여전히 신중한 보안 검토가 필요할 수 있습니다. 코드베이스 전반에 걸친 크고 기계적인 이름 변경은 백만 개의 토큰을 비용으로 발생시킬 수 있지만 거의 검토가 필요하지 않을 수 있습니다. 만약 경영진이 토큰 견적을

경험 많은 엔지니어의 티셔츠 사이즈 추정치에는 아무도 말해주지 않아도 그 위험과 검토 노력이 포함되는 경우가 많습니다. 하지만 토큰 견적(token quote)은 그렇지 않습니다. 이것이 실제 손실이며, 이 전체 아이디어에 대한 가장 강력한 반론입니다.

제 생각으로는 일반적인 백로그(backlog) 전반에 걸쳐 토큰 견적과 종단 간 사이클 시간(end-to-end cycle time)이 충분히 상관관계가 있어 상대적인 신호로 유용할 것이며, 예외는 어차피 인간의 주의를 기울여야 하는 고위험, 저볼륨 변경 사항일 것입니다. 하지만 이것은 추측입니다. 가장 먼저 테스트해야 할 부분이며, 만약 잘못된 것으로 밝혀진다면 토큰 견적은 티셔츠 사이즈의 나쁜 대체재가 될 것입니다.

올바한 것을 기준으로 보정하기

처음에는 이 견적이 단지 에이전트(agent)의 추측일 뿐입니다. 그 추측이 얼마나 좋을지는 모르겠습니다. 에이전트는 인간의 직감보다 한 가지 장점이 있습니다. 바로 자신이 변경해야 할 코드를 실제로 읽는다는 것입니다. 또한 명확한 단점도 가지고 있습니다. 경험 많은 엔지니어가 가져오는 조직적 맥락(organisational context), 역사, 암묵지(tacit knowledge)가 부족하며, 모델은 자신의 불확실성에 대해 잘 보정되어 있다는 것으로 알려져 있지 않습니다. 의심할 여지 없이 이점인 것은 비용이 들지 않는다는 것입니다.

추측을 개선하는 명백한 방법은 견적된 토큰 수를 **실제 토큰 수(actual tokens)**와 비교하여, 나중에는 _(티켓 → 실제 토큰 수)_에 대해 모델을 훈련시키는 것입니다. 이것은 아마도 작동할 것이며, 그 이유는 모델이 토큰 소비를 예측하는 데 능숙해질 것이기 때문입니다. 하지만 그것은 잘못된 질문에 답하게 할 것입니다. 에이전트가 얼마나 많은 토큰을 사용할지에 대한 완벽하게 보정된 예측은 토큰 소비 자체가 경영진이 신경 써야 하는 것인지에 대해서는 아무것도 알려주지 않습니다. 당신은 측정하는 것이 아니라, 측정 도구를 검증하고 있는 것입니다.

진정으로 중요한 비교는 **토큰 견적(token quote)**과 이슈의 주기 시간(issue's cycle time) 사이입니다. 즉, 티켓을 시작하여 검토, 재작업, 대기 및 확인 과정을 거쳐 실제로 완료되는 데 걸린 시간이 얼마나 되는가 하는 것입니다. 주기 시간은 사이즈 신호(size signal)가 대체해야 할 결과값입니다. 만약 토큰과 주기 시간이 함께 움직인다면, 그 견적은 유용한 상대적인 사이즈 신호가 됩니다. 하지만 그렇지 않다면, 아무리 정확하게 자체 토큰 사용량을 예측하더라도 마찬가지입니다.

여기에는 겉으로 보기엔 역설이 있습니다. 저는 시간 추정(estimating time)에 반대하는데, 정작 시간과 비교하여 검증할 것을 제안하고 있기 때문입니다. 차이점은 주기 시간은 예측되는 것이 아니라 측정된다는 것입니다. 아무도 그것을 예측하라고 요구받지 않습니다. 그것은 작업의 부수적인 결과로 트래커에 기록되며, 토큰 개수가 놓치는 바로 그 부분을 포착합니다. 즉, 인간적인 측면인 검토(review), 확인(verification), 요구사항에 대한 주고받음(back-and-forth on requirements)입니다.

물론 주기 시간은 노이즈가 많은 목표값입니다. 대기열(queueing), 우선순위 재조정(reprioritisation), 휴가를 간 사람, 주말 동안 막혀 있는 티켓 등이 포함되기 때문입니다. 이를 잘 사용하려면 일관된 정의(예: '진행 중'에서 '배포됨')가 필요하며, 가능하다면 명시적으로 차단되어 보낸 시간은 제외해야 합니다. 그럼에도 불구하고, 정확한 예측보다는 상관관계에 기대를 거는 것이 좋습니다.