스토리 포인트: AI가 흔든 건 눈금이 아니다

개발자 열여섯 명에게 자기가 몇 년째 손보던 저장소의 일감 246개를 맡기고, 그중 절반에만 AI 코딩 도구를 쓰게 했다. 저장소는 팀이 코드를 모아 두는 곳이고, 일감은 스프린트 하나에 담는 일 한 건이다. 다 끝내고 나서 그들은 도구를 쓴 쪽이 20%쯤 빨랐던 것 같다고 답했다. 실제로 잰 시간은 19% 더 길었다.

이 결과를 어떻게 읽느냐가 다음 계획 회의에 바로 걸린다. 앞 글의 스토리 포인트, 그러니까 일감마다 크기를 어림해 붙인 숫자가 날짜를 내주지는 않는다. 날짜는 나눗셈에서 나온다. 남은 점수를 지난 스프린트에 끝낸 점수로 나누면 몇 스프린트가 남았는지가 나온다. 그래서 팀이 실제 크기보다 크게 또는 작게 매기는 정도, 곧 배율만 일정하면 그 배율은 나눗셈에서 지워진다. 대신 조건이 두 가지 붙는다. 크기가 같은 일감에는 점수도 같게 매길 것, 한 스프린트에 해내는 양이 크게 안 흔들릴 것.

그 두 가지가 아직 지켜지는가.

AI 코딩 도구는 점수를 못 쓰게 만들지 않는다. 앞 글이 나눗셈에 단 두 조건이 흔들릴 뿐이다. 어떤 일감이 더 빨라지는지, 그리고 한 스프린트에 해내는 양이 몇 달 만에 어떻게 되돌아오는지가 그 두 조건에 차례로 걸린다.

도구를 쓰면 얼마나 빨라지는지가 실험 사이에서도 한 사람 안에서도 갈린다

도구를 썼을 때 일감이 얼마나 빨리 끝나는지 잰 값은 55.8% 단축에서 19% 지연까지 갈린다. 첫째 조건은 크기가 같은 일감에 점수를 같게 매기라고 요구하는데, 도구를 쓰면 그 크기와 실제 걸리는 시간이 일감마다 다른 만큼 벌어진다.

2022년 5월과 6월에 Upwork에서 뽑은 개발자 95명에게 정해진 규칙대로 요청을 받아 답을 돌려주는 프로그램, 곧 HTTP 서버를 자바스크립트로 되도록 빨리 만들라고 했다. 끝까지 마친 35명의 평균은 도구를 쓴 쪽 71분, 안 쓴 쪽 161분으로 55.8% 짧았다.Sida Peng, Eirini Kalliamvakou, Peter Cihon, Mert Demirer, The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, arXiv:2302.06590, 2023. 저자 셋이 Microsoft Research와 GitHub Inc. 소속이고 잰 대상이 그중 GitHub가 파는 GitHub Copilot이다. 그러고도 55.8%를 쓰는 까닭은 설계와 표본과 통계가 논문에 다 적혀 있기 때문이다.

느린 쪽은 METR가 한 도입부의 그 실험이다. 2025년 2월부터 6월까지, 개발자 열여섯 명이 자기가 평균 5년 기여한 저장소에서 일감을 맡았다. 그 저장소는 나이가 평균 10년이고 코드가 110만 줄이 넘는다.METR는 AI 모델을 평가하는 비영리 기관이고 도구를 파는 회사가 아니다. 다만 AI 능력 평가가 그 기관의 존재 이유다. Joel Becker, Nate Rush, Beth Barnes, David Rein, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, arXiv:2507.09089v2, 2025.

두 값을 화해시키는 문장을 두 논문이 스스로 적어 놨다. Peng 등은 자기가 잰 것이 표준화된 과제 하나이고 큰 프로젝트의 협업이 아니며, 이득은 일 종류와 언어에 따라 다를 수 있다고 적었다. METR는 자기 결과가 작은 신규 프로젝트나 낯선 코드에서 크게 빨라지는 것과 어긋나지 않는다고 적었다.

같은 실험 안에서도 갈린다. METR에서 개발자들은 자기가 익숙한 일감에서 더 느려졌고, 참고 자료를 덜 찾아도 되는 일감에서도 더 느려졌다. 논문은 이 대목의 근거가 중간 정도라고 스스로 적었다. 익숙한 정도는 참가자가 과제 전에 스스로 매긴 값으로 나눴다. 한 사람 안에서 갈린다면 아직 안 한 일감이 쌓인 한 팀의 백로그 안에서도 갈린다.

디자이너 일로 옮겨 보자. 앞은 빈 파일에서 처음 그리는 화면, 뒤는 3년 된 디자인 시스템에서 버튼 하나의 동작만 바꾸는 일이다. 앞은 참고할 것이 없어 도구를 쓰면 크게 빨라지고, 뒤는 어디를 건드리면 무엇이 깨지는지가 이미 그 시스템을 만든 사람 머릿속에만 있다.

아래 산술은 논문이 아니라 내가 짜 본 것이다.

지난 스프린트에 끝낸 40점이 익숙한 일감에서 나왔다고 하자. 남은 백로그 120점은 새로 만드는 낯선 일감이라 1점에 걸리는 시간이 절반이다. 그러면 120점을 끝내는 데 실제로 드는 시간은 60점어치다. 120점을 40점으로 나누면 세 스프린트가 나오지만 실제로는 한 스프린트 반이면 끝난다. 나눗셈이 틀린 것은 남은 점수와 지난 스프린트에 끝낸 점수를 다른 자로 쟀기 때문이다.

눈금은 3이나 5 가운데 어떤 크기에 어느 값을 붙일지 팀이 회의에서 맞춰 둔 것이다. 그래서 첫째 조건은 그 맞춰 둔 것이 망가져서 깨지는 게 아니다. 같은 눈금이 가리키던 시간이 일감마다 다르게 짧아져서 깨진다. 반년 전의 3과 지금의 3이 같은 시간을 안 가리킨다.

늘어난 줄 수는 곧 제자리로 왔고, 늘어난 경고와 계획한 점수는 그러지 않았다

Cursor를 들인 저장소에서 추가된 줄은 첫 달에 281.3% 늘었다. 둘째 조건은 한 스프린트에 해내는 양, 그러니까 벨로시티(velocity)라고 부르는 그 값이 크게 안 흔들리기를 요구한다. 그런데 He 등이 센 줄 수는 셋째 달에 차이가 남지 않았고, Tomaz 등이 따라간 팀 한 곳에서는 계획한 점수가 두 배 반이 됐다. 그 줄 수로는 흔들렸다는 것까지만 말할 수 있다.

Cursor 설정 파일이 처음 들어간 때를 도입 시점으로 삼았다. 둘째 달에는 48.4% 늘었고, 셋째 달부터는 통계적으로 유의한 차이가 없었다. 우연으로 생길 만한 크기라는 뜻이다.견준 상대는 AI를 아예 안 쓰는 팀이 아니라 업계의 보통 상태다. 설정 파일이 들어간 저장소만 잡혔다. 도구가 빠르게 바뀌는 기간이라 결과가 안 이어질 수 있다고 논문이 적었다. Hao He 등, Speed at the Cost of Quality, MSR 2026, arXiv:2511.04427.

코드를 돌려 보지 않고 기계가 훑어서 내는 경고, 그러니까 정적 분석 경고가 30% 늘고 코드가 갈래를 많이 친 정도, 곧 코드 복잡도가 41% 늘었는데, 이 둘은 줄지 않았다. 그리고 경고와 복잡도가 쌓인 뒤로는 늘어나는 줄 수가 도로 줄어든다는 것을 같은 논문이 따로 보였다.

Tomaz 등이 애자일 팀 셋을 2023년부터 열세 달 따라간 자료에서는 도구를 들인 뒤 스프린트를 다 합친 계획한 점수가 447에서 1155로, 못 끝낸 점수가 166에서 708로 늘었다. 대형 기술 컨설팅 회사에서 구성이 안 바뀐 팀 한 곳의 값이다. 논문은 팀이 자기 여력을 더 믿어 더 많이 맡았다고 풀이했다. 지난 기록으로 다음 스프린트를 셈한 값이 그만큼 어긋났다.끝낸 점수는 59.1% 늘었는데 저장소에 적어 넣은 줄 수는 통계적으로 안 바뀌었다. 같은 줄 수로 더 큰 일을 해냈다는 쪽과 같은 일에 매기는 점수가 커졌다는 쪽으로 갈리는데, 이 자료로는 못 가른다. 논문은 앞쪽으로 풀이했다. Rafael Tomaz 등, Impacts of Generative AI on Agile Teams’ Productivity, arXiv:2602.13766, 2026.

첫 달과 둘째 달에 늘어난 그 줄 수도, 계획한 점수도 벌써 옛 도구로 잰 값이다. 이 글이 옮긴 값은 2022년의 GitHub Copilot부터 2025년 상반기의 Cursor Pro까지를 잰 것이다. 2026년 2월에 METR는 실험 설계를 바꾼다고 밝히면서 2026년 초에는 개발자가 2025년 초보다 빨라져 있을 것으로 본다고 적었다. 그 증가 폭을 받치는 증거는 매우 약하다고 스스로 덧붙였다.

도구를 바꾸기 전 세 스프린트의 숫자를 그대로 다음 분기 계획에 넣는 팀은 도구가 지금과 다르던 때의 값을 쓴다. 그러니 둘째 조건은 사람이 빠지고 들어와서가 아니라 도구가 바뀌는 동안에 깨진다.

크기를 견주는 감각은 아직 맞고, 추정을 그만두자는 쪽도 나눗셈은 그대로 한다

가장 센 반론의 근거를 이 글이 제일 크게 쓴 METR 논문이 댄다. 개발자가 미리 적은 예상 시간과 실제 걸린 시간의 상관은 도구를 쓸 수 있는 일감에서 0.64, 못 쓰는 일감에서 0.59다. 상관은 하나가 크면 다른 것도 큰 정도인데, 아예 안 따라가면 0이고 같이 가면 1이다. 논문은 개발자들이 일감마다 걸릴 시간을 서로 견주는 데서는 대체로 잘 맞히는데 도구를 쓰면 얼마나 빨라질지 품은 기대만 뒤집혔다고 적었다. 그러면 달라진 것은 빠르기 하나뿐이고 크기를 견주는 감각은 그대로다. 그 감각이 그대로면 앞 글의 나눗셈도 그대로여서, 한두 스프린트면 새 값이 잡히고 배율은 다시 지워진다.

둘째 반론은 아예 추정하지 말자는 쪽이다. Ron Jeffries는 추정을 점수로 하든 시간으로 하든 피하는 편이 낫다고 적었다. 점수를 만든 것이 자기라면 미안하다고 그가 적었다. 그는 일감을 두어 시간에서 하루 안에 끝나게 잘라 두고 추정을 아예 안 하라고 권했다.

이 글은 크기를 견주는 감각이 망가졌다고 주장한 적이 없다. 도구가 한 번 바뀌고 그대로 있다면 이 글의 걱정은 두 스프린트짜리다. 개수만 세는 쪽이 유리해졌다는 것도 맞다. 매 스프린트 지금 도구로 일감을 다시 자르는 팀은 반년 전 회의에서 정한 눈금을 들고 다니지 않는다.

그러나 갈림은 다른 데 있다. 점수를 쓰느냐 개수를 세느냐가 아니라 언제 잰 자로 재느냐다. 그런데 도구는 거기서 안 멈춘다. 앞 절에서 본 대로 METR는 지금은 더 빨라져 있을 것으로 본다고 적었다. 계속 바뀌는 동안에는 나눗셈에 넣는 지난 스프린트의 점수가 늘 지금 백로그보다 오래된 도구로 잰 값이다.

개수 세기도 나눗셈이다. 일감을 하루짜리로 잘라도 지난 스프린트에 끝낸 개수로 나눠야 날짜가 나온다고 앞 글이 이미 짚었다. 개수 세기가 유리한 까닭이 눈금을 매번 다시 맞추는 데 있다면, 점수를 쓰는 팀도 같은 것을 할 수 있다.반박 1은 앞 절이 댄 잰 값 둘과 METR 자신의 예상 위에 서는데, 그 예상은 METR가 증거가 매우 약하다고 적은 것이다. 반박 2에는 그런 값이 없고 내 셈으로만 선다.

그러니 남는 물음은 지난 스프린트 가운데 나눗셈에 넣어도 되는 것이 몇 번이나 남았느냐다.

정리: 나눗셈에 넣는 두 수를 같은 자로 쟀는지 보라

망가진 것은 점수가 아니다. 지난 스프린트의 기록을 도구가 바뀐 지금도 그대로 쓸 수 있다고 믿는 그 몇 달이다.

일감이 얼마나 빨리 끝나는지는 실험마다도, 한 사람의 백로그 안에서도 갈렸다. 도구를 들인 저장소에서는 줄 수만 두 달 만에 돌아왔다. 계획한 점수도 경고도 안 그랬다.

다음 계획 회의에서 지난 세 스프린트의 점수를 꺼내기 전에, 그 사이에 팀이 쓰는 도구가 바뀌었는지부터 확인하라. 바뀌었으면 그 앞의 스프린트는 다른 자로 잰 값이다. 그리고 그 스프린트를 채운 일감과 지금 백로그에 남은 일감이 같은 종류인지 보라. 익숙한 일감으로 채운 스프린트의 점수로 낯선 일감이 쌓인 백로그를 나누면 도구가 그대로여도 나눗셈은 안 맞는다.