분산이 폭발하는 시대의 견적

업계엔 두 가지 풍경이 오래 공존해왔다. 한쪽에서는 개발자가 야근에 시달린다. 다른 한쪽에서는 개발자만 너무 널널하다고 다른 직군이 불만이다. 정반대 같지만, 사실은 같은 문제의 두 얼굴이다. 공수 모델이 분산을 감당하지 못한다는 것.

AI가 그 분산을 더 키웠다. 하루 일이 한두 시간이면 끝나는 개발자들이 늘면서, "회사에 미안하다"는 자조 글이 블라인드 같은 게시판에 자주 보인다. (이런 회사들은 견적을 아직 예전 공수 기준으로 잡는 듯하다.)

공수 모델이라는 유물

월급이든 시급이든 외주 견적이든 단가 협상이든, 결국 우리가 노동에 가격을 매기는 방식은 시간으로 환산하는 것 하나로 수렴한다. 공수에 단가를 곱해서 가격이 나온다는 식이다. 정규직은 그걸 8시간 단위로 묶어 한 달치를 일괄로 파는 형태고, 외주는 같은 단위를 쪼개 시간 단위로 파는 형태다. 묶음이냐 낱개냐의 차이일 뿐, 시간을 단위로 삼는다는 점에서는 같다.

공장에서는 이 방식이 꽤 정직하게 작동한다. 1시간에 부품 한 개가 나오면 다음 1시간에도 비슷하게 한 개가 나오니까, 시간을 가격의 단위로 삼는 게 통계적으로 그럴듯해진다. 분산이 작은 일에 시간 단위를 박는 건 자연스럽다.

그런데 소프트웨어는 처음부터 그렇지 않았다. 어떤 1시간엔 0이 나오고, 어떤 1시간엔 100이 나온다. 같은 사람이더라도 그렇다. 공수 모델은 이 분산 자체를 감당하지는 못하고, 이 분포의 평균에 버퍼 20~30%를 얹은 값으로 가격을 박는다. 평균을 살짝 우상향으로 시프트한 셈인데, 분포의 꼬리가 그 버퍼 안에 머물지는 알 수 없다.

그러면 그 분산은 어디로 갈까. 누군가는 흡수해야 한다. 협상력에 따라 흡수자가 갈린다. 직원이 약하면 야근과 저품질로 흡수하고, 회사가 약하면 널널한 일정과 낭비로 흡수한다. 어느 쪽이든 비효율이다. 앞에서 말한 두 풍경이 바로 그 비효율의 모습이다.

다만 이걸 무조건 결함이라고만 보긴 어렵다. 공수 견적은 양쪽이 합의한 거짓말이기도 하다. 클라이언트에게 "9~12일, 80% 확률"을 정직하게 제시하면, 실무에서는 12일을 기준으로 협상이 시작된다. 분산을 명시적으로 가격에 박는 순간 평균 견적은 오히려 올라간다. "5일이요"라는 점추정은 거래 비용을 낮추는 암묵적 합의로 기능해 왔다. 그 합의를 빼면 거래 자체가 안 굴러간다. 그래서 이 모델은 폐기가 아니라 보완의 대상이다.

애자일¹과 스토리포인트²는 분포 사고로 가는 첫걸음이었다고 볼 수 있다. 시간 대신 상대적 복잡도로 매기자는 시도였다. 1, 2, 3, 5, 8 같은 피보나치 수열을 쓴 것³도 같은 맥락이었다. 그런데 현장에서는 대부분 "1포인트 = 반나절" 같은 식으로 시간 지수로 변질됐고, "이번 스프린트 30포인트"라는 점추정(point estimate)으로 다시 수렴한다. 개념을 만든 Ron Jeffries 본인이 후회하고 있을 정도다.⁴ 점추정의 그림자에서 끝내 못 벗어났다. (한 핀테크 스타트업에 있을 때, Jira 티켓에 스토리포인트 필드가 있었지만 아무도 안 매겼다. 매기는 것 자체가 난제였으니까ㅋㅋ)

업계가 이 문제를 다뤄온 세 흐름

(1) 점추정 자체를 폐기하기: #NoEstimates

이 흐름의 입장은 강경하다⁵. "추정하지 마라. 세라." 축적된 데이터로 미래를 시뮬레이션해서 분포를 뽑자는 것이다. 며칠 걸리냐가 아니라, "이런 종류의 일을 우리 팀이 처리하면 80% 확률로 9~12일 안에 끝납니다"가 답이다.

가장 정합적이다. 분산이 큰 일에 점추정을 쥐여주는 것 자체가 거짓말이라면, 분포로 답하는 게 정직하다.

문제는 협상력만이 아니다. 회사가 외부에 견적을 낼 때, 클라이언트는 "5일"을 듣고 싶지 "9~12일 80%"를 듣고 싶어 하지 않는다. 시장 자체가 점추정을 강제하는 영역, 즉 고정가 외주, 정부 입찰, 마감일 박힌 마케팅 캠페인 같은 영역이 여전히 크다. 그리고 분포 답은 후속 작업의 병목이 된다. 의존성 있는 팀이나 계획이 "9~12일" 위에 쌓일 수 없다.

(2) 글로 미리 깎기: Writing-First

Basecamp의 Shape Up⁶과 Amazon의 Working Backwards / PR-FAQ⁷가 대표적인데 결은 꽤 다르다. Shape Up은 6주 cycle과 betting table로 시간을 고정하고, 6주 안에 안 끝나면 스코프를 깎거나 다음 cycle로 넘긴다. PR-FAQ는 코드 한 줄 쓰기 전에 가상 보도자료부터 쓴다. 그런데 둘이 하는 일은 같다. 글로 스코프를 미리 깎는 것이다.

이게 결국 애자일 아니냐고 물을 수도 있다. 절반은 맞다. Shape Up은 본인들이 "post-agile"이라고 명시할 정도로 애자일 가족이고, PR-FAQ는 오히려 "코드 전 매끈한 문서"라는 점에서 애자일이 거부했던 BDUF(Big Design Up Front)에 가깝다. 그런데 두 흐름이 공유하는 진짜 핵심은 애자일/워터폴 축이 아니라, 스코프 자체를 글로 깎아서 분산을 줄인다는 것이다. 스토리포인트가 분산을 측정하려 했다면, Writing-First는 분산이 발생하기 전에 잘라낸다.

Stripe의 memo culture⁸, Shopify의 GSD⁹, Spotify의 DIBBs¹⁰도 같은 동작을 의사결정 단위에서 한다. 글로 먼저 깎고, 합의가 잡히면 실행한다.

(3) 사후에 데이터로 잡기: DORA, METR, GitClear

가장 따끈한 흐름이다. AI 영향을 정량으로 재기 시작했다. 흥미롭게도 이 흐름의 자료들은 결론이 매년 흔들린다. 그만큼 환경이 빠르게 변하고 있다.

DORA 2025¹¹ 보고서는 AI 도입률이 90%까지 올라간 상황에서, AI가 처리량(throughput)과 제품 성과(product performance)에는 양의 상관을 보이지만 배포 안정성(delivery stability)에는 여전히 음의 상관을 보인다고 보고한다. 코드를 빨리 쓰는 만큼 시스템은 더 자주 깨진다. DORA는 이를 "AI는 팀을 고치지 않는다, 증폭한다"로 정리했다. 강한 팀은 더 강해지고, 약한 팀은 약점이 더 도드라진다.

METR이 2025년 7월에 낸 RCT 연구¹²는 더 도발적이다. 경험 많은 오픈소스 개발자 16명을 두 그룹으로 나눠, AI 도구 사용을 허용/금지하고 실제 작업 시간을 쟀다. 결과: AI를 쓴 그룹이 19% 더 느렸다. 정작 본인들은 AI가 24% 빠르게 해줬다고 답했고, 실험 후 회고에서도 20% 빨라졌다고 추정했다. 체감과 실측의 차이가 40%포인트 가까이 벌어진 것이다.

(이런 공신력 있는 자료가 나오면 웬만하면 수긍하는 편인데, 현역 개발자 입장에서 "더 느렸다"는 건 도저히 못 믿겠다. 표본이 16명으로 작고 Sonnet 3.5/3.7 시점이라는 한계도 있다.)

METR 본인들도 비슷한 의심을 한 모양인지, 2025년 8월부터 57명 규모로 후속 실험¹³을 돌렸다. 결과는 2026년 2월 24일에 공개됐는데, 결론이 흥미롭다. 데이터를 신뢰할 수 없다. 개발자들이 "AI 없이는 하기 싫은 task"는 아예 제출 자체를 안 했다는 거다. 30~50%가 그랬다. 한 참가자는 이렇게 말했다. "AI로는 2시간이면 끝낼 일을 20시간 들여야 하니까, 그런 task는 피한다." 학술 RCT가 선택 편향(selection bias)으로 무너진 셈이다. METR은 정성적으로는 "2026년 초에는 AI가 더 빠르게 해주고 있을 것 같다"고만 짚었다.

GitClear 2025 보고서¹⁴는 211M 라인을 분석해서 코드 churn(작성하고 2주 안에 되돌리는 코드)이 2020년 3.1%에서 2024년 5.7%로 거의 두 배가 됐다고 보고한다. 중복 코드 블록도 8배가 증가했다. 빨리 쓰고, 그만큼 빨리 지우거나 같은 코드를 여러 곳에 박는다. 인지적 갭의 정량 증거다.

이 세 자료가 한 방향을 못 가리키는 게 오히려 신호다. 측정 자체가 아직 어렵고, 측정 방법론이 매번 무너진다. AI가 task 분포를 바꾸고, 개발자가 task 선택을 바꾸고, 에이전트가 도는 동안 다른 일을 하므로 작업 시간의 단위 자체가 흔들린다. 공수 모델이 분산을 못 잡듯, 학술적 측정도 같은 한계를 겪고 있다.

LLM이 추가한 새 변수

이 세 흐름이 다루던 분산을 LLM이 한 번 더 뒤흔들었다.

스파이크의 평균은 낮아졌다. 분산은 커졌다.

평균 case — 스캐폴딩, 프로토타입, 새 도메인 진입 — 는 LLM이 빠르게 처리한다. 한 시간 걸릴 일이 7분이면 끝난다. 스파이크¹⁵도 같이 싸졌다.

그런데 꼬리값은 그대로거나 더 비싸졌다. 통합, 검증, 엣지 케이스, 운영 중인 시스템에 변경 박기. LLM이 평균을 낮춘 만큼 분산도 함께 키운 것으로 보인다. 단정하긴 어렵다. 위에서 본 DORA, METR, GitClear 모두 평균에 대한 측정이지 분산을 직접 잰 자료는 아니다. 분산이 커졌다는 건 측정보다 현장 체감에 가깝다. 그래도 평균에서 멀리 있던 일이 더 멀어진다는 감각은 실무에서 점점 또렷해진다.

이게 견적에 어떻게 영향을 주는가 하면, "3.25일이요"가 더 거짓말이 된다. 같은 3일짜리 일이 LLM 손에 닿으면 어떤 날은 반나절에 끝나고, 어떤 날은 7일을 잡아먹는다. 점추정이 더 의미를 잃는다.

인지적 갭: Bainbridge가 1983년에 이미 썼다

Lisanne Bainbridge라는 영국 산업심리학자가 1983년 Automatica 저널에 Ironies of Automation¹⁶이라는 짧은 논문을 썼다. 항공, 원전 제어실 같은 데서 자동화가 들어왔을 때 인간 오퍼레이터에게 무슨 일이 벌어지는지를 관찰한 글이다.

자동화가 늘어날수록 인간은 시스템을 장악하는 감각을 잃는다. 그리고 자동화하기 어려운 일, 예외적인 일, 진짜 어려운 일만 인간 몫으로 남는다.

네 가지 아이러니를 정리해뒀는데, 코드베이스로 그대로 옮겨와도 들어맞는다.

1. 설계자 — 여기선 LLM의 학습 데이터를 만든 사람들 — 의 오류를 잡는 건 결국 현장 인간이 해야 한다. 예를 들어 LLM에 견적을 시키면, 학습 데이터의 보수적 패턴을 그대로 받아 한참 널널한 답을 내놓는다.
2. 잔여 업무의 난이도가 올라간다. LLM이 쉬운 걸 다 처리하고 나면, 개발자에게 남는 일이 평균적으로 더 어려워진다.
3. 기술 위축(skill atrophy). 오래 안 쓰면 못 한다. 디버깅이 그렇게 된다.
4. Out-of-the-loop performance problem. 평소엔 LLM이 다 하다가, 막상 시스템이 망가진 순간 인간에게는 컨텍스트가 없다.

이전 글에서 "AI가 한 일을 검토하는 것 자체가 일이 되고, 일은 더 진행되는데, 그만큼 밀도 높은 날은 육체적으로 피곤하다"고 썼는데, 그 피로의 학술 명칭이 out-of-the-loop performance problem이다. 1983년에 이미 정의돼 있던 단어다.

LLM은 개발자 일을 쉽게 만들지 않는다. 개발자에게 남는 일을 더 어렵게 만든다.

그래서 어느 흐름이

세 흐름 중 어느 게 LLM 시대를 가장 잘 흡수할까. 개인적으로는 Writing-First가 끌린다. 더 정확히는, 사전 스펙아웃과 사이클 내 spec in이 결합된 하이브리드가 끌린다.

#NoEstimates는 분산 폭발의 시대에 가장 정합적이고 정직하지만, 외부 협상에서는 약하다. 데이터 기반은 측정 자체가 새 인프라가 될 가능성이 있는데, 위에서 봤듯 측정 방법론이 매번 무너지고 있다. DORA도 GitClear도 METR도 같은 일을 다른 결로 측정하고 있고, 한 방향으로 수렴하지 못하고 있다.

측정이 매번 무너진다면, 사전에 협상으로 자르는 수밖에 없다. Writing-First가 끌리는 이유는 단순하다. 원래 세상사 상당 부분이 협상의 기예로 굴러가기 때문이다. 견적은 결국 추정이고, 그 추정이 받아들여지는 건 추정 자체의 정확성이 아니라 추정을 낸 '사람'이나 '팀'에 대한 신뢰가 좌우한다. 견적이 질소포장인 개발자, 빡빡한 일정을 정확히 내는 사람, 자기 속도를 과신해 타이트하게 잡다가 매번 늦어지는 사람. 같은 "5일"이라도 누가 말했느냐에 따라 받아들여지는 무게가 다르다. 분산을 사후에 측정하기보다 사전에 협상으로 잘라내는 게, 분산이 폭발하는 시대일수록 더 현실적이다.

그리고 스펙아웃이라는 행위가 굉장히 저평가돼 있다고 생각한다. "코드 짜기 전에 글로 먼저 깎는다"는 게 옛날엔 워터폴이라고 비웃음을 샀지만, 사실은 Writing-First 흐름이 다시 끌어올린 동작이다. 이게 한 발 앞서 분산을 잡는 가장 현실적인 도구다. LLM이 코드 작성을 싸게 만든 시대일수록, 코드 전에 무엇을 만들지를 글로 먼저 깎는 시간의 가치가 더 올라간다. 코드가 싸진 만큼, 잘못 깎인 스코프의 대가가 커졌다.

그런데 LLM 시대엔 흥미롭게도 spec in(스펙인)도 늘어난다. 솔직히 현업에서 이 단어를 들어본 적은 없다. 스펙은 늘 깎고 빼는 방향(out)으로만 흘렀다. 코드가 비쌌으니까. 그런데 코드가 거의 공짜에 가까워지면서, 어떤 걸 구현하다 보니 여기는 더 깊이, 더 정교하게 가야 한다는 발견이 늘어난다. 전에는 "추가 요구사항", "기획 변경" 같은 부정적 라벨로 처리되던 것이, 가장 가치 있는 발견의 순간일 수 있다.

(나도 Writing-First 하는 회사에서 일해봤다. 작은 디테일은 Pull Request 단에서 자연스럽게 결정되기도 했지만, 리뷰어가 "PR-FAQ에서 이미 컨펌됐어야 할 내용"이라고 판단해 며칠씩 승인이 안 나는 경우도 많았다.)

이걸 인정하면 순수한 Writing-First는 살짝 흔들린다. 사전에 다 깎을 수 없는 분산이 사이클 내내 튀어나온다는 일종의 자백이다. 그래서 사실상 #NoEstimates와 Writing-First의 하이브리드에 가깝다. 사전엔 글로 깎고, 사이클 안에서는 흐름에 맞춰 다시 협상한다. 사전 한 번이 아니라 사이클 내내 협상이 일어나는 모양이다.

물론 단서가 있다. Shape Up의 6주 cycle 자체는 LLM이 스파이크를 줄인 시대에는 너무 길지도 모른다. 2주? 1주? 재조정이 필요할 수 있다. 그리고 글로 깎는다는 것 자체에 협상력이 필요하다. 위계가 강하거나 즉흥 결정·메신저·구두에 의존하는 조직에서는 PR-FAQ 한 장 쓰는 데 한 달이 걸리기도 한다. 협상력이 없는 게 아니라, 글로 깎을 권한 자체가 부족한 것이다. 도입 비용이 작지 않다.

그래도 #NoEstimates와 데이터 기반 흐름이 측정 인프라를 새로 짓는 동안, Writing-First는 이미 작동하는 협상 도구를 LLM 시대에 맞게 손보면 된다.

마치며

신입 때부터 견적 잘 내는 개발자가 되고 싶었다. 팀장의 신뢰를 얻는 가장 빠른 길이라 봤기 때문이다. 지금은 내 관심의 단위가 개인에서 팀으로 옮겨가는 중이다. 시대가 바뀌어도 이 고민은 유효하다고 생각한다. 그 자리에서 최대한 잘해보려는 중이다.