생산성 표준 지표가 완료 시간에서 흐름 지표로 이동한다
개인의 작업 완료 시간은 이미 측정 불가능해지고 있다. 조직은 리뷰 대기열 길이, 머지 리드타임, 변경 실패율처럼 사람이 다중 작업을 해도 무너지지 않는 지표로 옮겨갈 것이다.
반증 조건 — 2027년 말까지 작업 단위 시간 측정 실험이 신뢰할 만한 신호를 회복하고, 주요 조직이 완료 시간을 1차 지표로 계속 쓴다면 이 예측은 틀렸다.
난이도 논쟁으로 보이지만 실은 배분 논쟁이다. 생성 비용과 검증 비용의 비율로 보면 양쪽이 왜 동시에 옳은지, 그리고 왜 끝나지 않는지가 드러난다.
2026년 8월 8일, 크로아티아의 개발자 세뇨 라시치(Senko Rašić)가 올린 짧은 글이 해커뉴스에서 하루 만에 100개가 넘는 댓글을 모았다. 요지는 한 문장이다. 요즘 흔히 들리는 "코드는 어려운 부분이 아니었다(code was never the hard part)"라는 말은 프로그래머 전체에 대한 모욕이라는 것.
글은 반문의 나열로 되어 있다. 코딩이 쉽다면 왜 프로그래머 임금이 높았고, 왜 번아웃이 그렇게 흔했고, 왜 『컴퓨터 프로그래밍의 예술』 같은 책이 존재하며, 왜 소프트웨어는 이토록 버그투성이인가. 반대편도 같은 방식으로 두들긴다. 무엇을 만들지 정하는 일이 정말 더 어렵다면 왜 프로덕트 매니저가 개발자보다 적게 받고, 왜 시장조사·사용성 전문가는 회사의 스타가 아닌가.
수사적으로는 시원하다. 그러나 이 글이 하루 만에 그만한 반응을 얻은 이유는 논증이 강해서가 아니라 정확히 아픈 데를 건드렸기 때문이고, 논증 자체는 여러 곳에서 새고 있다. 새는 자리를 따라가면 이 논쟁이 왜 3년째 같은 자리를 맴도는지가 보인다.
먼저 용어다. 영어권 토론에서 coding과 programming은 자주 구분된다. 앞의 것은 이미 정해진 것을 언어로 옮기는 행위, 뒤의 것은 문제를 계산 가능한 형태로 환원하는 행위를 가리킨다. 라시치의 반문 목록은 coding을 최대한 넓게 — 설계·디버깅·유지보수·운영까지 포함해 — 쓰고, 그가 반박하는 문장은 coding을 최대한 좁게 — 키보드로 코드를 산출하는 일로 — 쓴다.
그래서 양쪽 모두 자기 정의 안에서 참이다. 해커뉴스에서 가장 많이 반복된 지적도 그것이었다. 타이핑은 어렵지 않지만 프로그래밍은 어렵다는 말. 라시치 본인도 댓글에서 자기 결론이 "AI를 받아들여라"가 아니라 "적응 가능한 상태로 있어라"였다고 정정했다.
문제는 그다음이다. 단순한 용어 충돌이라면 이 정도로 뜨거울 이유가 없다. 정의를 맞추자고 하면 끝날 일이다. 그런데 끝나지 않는다. 이 문장이 서술문이 아니라 서열 선언이기 때문이다. 어떤 능력이 희소하고 어떤 능력이 흔한지를 다시 매기는 말이고, 희소성 순위는 곧 보상 순위다. 라시치가 "모욕"이라는 단어를 고른 것은 그가 이 성분을 감지했다는 증거다. 다만 그는 그것을 난이도 문제로 번역했고, 번역하는 과정에서 논증이 샜다.
글의 첫 번째 논거이자 가장 약한 고리는 이것이다. 코딩이 쉽다면 왜 임금이 높았는가.
이 추론은 성립하지 않는다. 가격은 난이도가 아니라 공급과 수요, 그리고 레버리지의 함수다. 소프트웨어 임금이 다른 공학 분야보다 높았던 것은 한 번 짜서 전 세계에 파는 구조 때문이지 작업의 인지적 부담 때문이 아니다. 해커뉴스에서 어느 참여자가 조목조목 되짚은 대로, "시간이 오래 걸리는 일"과 "어려운 일"은 다르다. 야근이 많다는 것은 난이도의 증거가 아니라 물량과 마감의 증거다. 두꺼운 기술서가 존재한다는 것도 마찬가지다. 세무 실무서도 두껍다.
"코드는 어렵다"와 "코더의 임금은 떨어진다"는 동시에 참일 수 있다. 난이도가 그대로여도 공급이 늘면 가격은 내려간다. 난이도를 방어하는 것으로는 임금을 방어하지 못한다.
라시치가 지키려 한 것은 직업의 존엄이고, 그가 든 증거는 임금과 수요다. 존엄은 난이도에, 임금은 희소성에 걸려 있다. 두 변수를 한 문장에 묶은 순간 논증은 반박 가능해졌다.
이 구분은 사소하지 않다. 지난 3년간의 논쟁 대부분이 이 혼동 위에서 진행됐다. 임금이 떨어지는 것을 본 사람은 "그러니까 어렵지 않았던 것"이라 말하고, 일이 어렵다는 것을 아는 사람은 "그러니까 임금이 떨어질 리 없다"고 말한다. 둘 다 틀렸다. 두 값은 애초에 연동되어 있지 않다.
난이도와 임금을 떼어놓고 나면 남는 질문은 하나다. 코드 생성이 실제로 병목이었는가. 이 질문에는 실측 자료가 있다.
비영리 평가기관 METR(Model Evaluation & Threat Research)이 2025년 7월에 내놓은 무작위 대조 시험이 출발점이다. 숙련 오픈소스 개발자 16명이 평균 5년간 다뤄온 저장소에서 실제 이슈 246건을 처리하되, 각 이슈마다 AI 사용 허용 여부를 무작위로 배정했다. 도구는 당시 최상급이던 Cursor Pro와 Claude 3.5·3.7 Sonnet이었다. 참가자들은 사전에 24% 단축을 예상했고, 실험이 끝난 뒤에도 20% 단축됐다고 느꼈다. 실제로는 19% 더 걸렸다(신뢰구간 +2%~+39%).
이 수치는 자주 인용되지만 대개 여기서 멈춘다. 정작 중요한 것은 후속이다. METR은 2025년 8월부터 개발자 57명, 저장소 143곳, 800건 이상의 작업으로 2차 실험을 돌렸고, 2026년 2월 그 데이터가 현재의 생산성 효과에 대한 신뢰할 만한 신호를 주지 못한다고 판단하며 설계 자체를 바꾸겠다고 발표했다. 원래 참가자 집단에서는 18% 단축(신뢰구간 −38%~+9%), 신규 참가자 집단에서는 4% 단축(−15%~+9%)이 나왔지만, 두 구간 모두 0을 품고 있다.
실패의 이유가 결과보다 정보량이 많다. 응답자의 30~50%가 AI 없이 처리하기 싫은 작업은 아예 실험에 제출하지 않았다고 답했다. 시급 50달러를 받으면서도 절반의 작업을 AI 없이 하기는 싫다며 참여 자체를 거절하는 개발자가 늘었다. 어떤 참가자는 AI 비허용으로 배정된 작업을 한 건도 끝내지 않았다. 한 사람은 평소 차를 타던 거리를 갑자기 걸어서 건너는 기분이라고 표현했다. 그리고 결정적으로, 에이전트가 도는 동안 다른 일을 하기 때문에 작업별 소요 시간을 보고하는 것 자체가 불가능해졌다.
"작업당 완료 시간"이라는 지표는 개발자의 주의가 한 작업에 묶여 있을 때만 성립한다. 그 전제가 깨졌다. 병목이 이동했다는 가장 직접적인 증거는 속도 수치가 아니라, 속도를 재던 자가 부러졌다는 사실이다.
동시에 이 실패는 낙관 쪽의 증거로도 쓸 수 없다. 표본에서 빠져나간 것이 AI 효과가 큰 작업들이므로 남은 추정치는 하한이지만, 하한이라는 사실만으로 상한을 말할 수는 없다. METR 자신이 그렇게 적었다.
개인 단위 측정이 무너진 자리에서 조직 단위 관측은 비교적 일관된 그림을 준다. 구글이 주관하는 DORA의 2025년 조사(기술 인력 약 5,000명)는 AI를 해결책이 아니라 증폭기로 규정했다. 잘 굴러가던 조직에서는 강점을, 망가진 조직에서는 역기능을 키운다는 것이다. 2024년 조사에서 오히려 낮아졌던 배포 처리량은 2025년에 상승으로 돌아섰다. 그러나 배포 불안정성은 계속 올라갔고, 마찰과 번아웃에는 유의미한 변화가 없었다. 응답자의 90%가 AI를 쓴다.
코드 변경 이력을 분석하는 GitClear의 2026년 보고서는 같은 이야기를 구조 지표로 옮긴다. 100만 변경 줄당 중복 블록은 2023년 40.3건에서 2026년 73.0건으로 늘었다. 리팩터링을 뜻하는 "이동한 줄"의 비중은 2022년 21%에서 2026년 3.8%까지 떨어졌다. 여러 파일에서 호출되는 함수, 즉 재사용의 흔적은 35% 줄었고, 오래된 코드를 손보는 활동은 74% 줄었다.
유보를 붙인다. GitClear는 자사 도구 고객과 오픈소스를 대상으로 하는 상업 분석 업체이고, 방법론이 공개되어 있지 않으며, 데이터는 인과가 아니라 상관이다. 이 시리즈에 무게를 주는 것은 세 해 연속 같은 방향을 가리켰다는 일관성이지 단일 수치의 정확성이 아니다.
이 숫자들이 말하는 것은 "AI가 코드를 못 쓴다"가 아니다. 재사용과 리팩터링과 레거시 정비, 즉 어렵다고 불리던 행위 자체가 줄었다는 것이다.
그리고 그것이 줄면 "코드는 어려운 부분이 아니었다"는 문장은 사후적으로 참이 된다. 어려운 부분을 하지 않기로 했으니까. 명제가 세계를 맞춘 것이 아니라 세계가 명제 쪽으로 옮겨 앉았다.
여기까지의 자료를 하나로 묶으려면 축이 필요하다. 나는 두 개를 쓴다. 어떤 작업을 만들어내는 데 드는 비용(생성 비용)과, 그 결과가 틀렸는지 확인하는 데 드는 비용(검증 비용)이다.
"코드가 병목이었는가"라는 질문의 답은 이 둘의 비율로 갈린다. 생성이 비싸고 검증이 싼 영역에서는 코드가 병목이었다. 만드는 데 두 주가 걸리는데 맞는지 확인하는 데는 반나절이면 되는 업무 시스템이 그렇다. 반대로 생성이 싸고 검증이 비싼 영역도 있다. 규제 준수 로직이나 보험 약관 처리는 코드가 짧고, 어려운 것은 규칙 해석과 그 해석이 옳다는 증명이다. 여기서는 애초부터 코드가 어려운 부분이 아니었다.
대규모 언어 모델이 한 일은 명확하다. 세로축, 곧 생성 비용을 0에 가깝게 눌렀다. 가로축은 건드리지 않았다. 오히려 검증해야 할 산출물의 물량을 늘려 총 검증 비용을 올렸다. 앞 절에서 본 세 갈래 관측 — 처리량 상승과 동반한 불안정성 상승, 중복 블록의 증가, 시간 측정의 붕괴 — 은 모두 같은 이동의 다른 그림자다.
그래서 엔지니어의 시장 가치는 점점 검증 능력 쪽으로 수렴한다. 지난 2년 사이 업계 어휘에서 취향, 판단, 책임 같은 단어가 갑자기 늘어난 것은 유행이 아니라 이 수렴의 언어적 증상이다. "리뷰가 병목"이라는 실무자들의 반복되는 하소연도 같은 자리에서 나온다.
그리고 이 그림은 논쟁이 끝나지 않는 이유를 설명한다. 좌상 사분면에서 일하는 사람과 우상 사분면에서 일하는 사람은 서로 다른 세계를 정확하게 서술하고 있다. 웹 업무 시스템을 만들던 사람에게 코드는 실제로 병목이었고 실제로 그 병목이 사라졌다. 분산 시스템이나 수치 해석을 다루던 사람에게 생성은 원래 병목이 아니었고, 지금은 검증 부담만 늘었다. 두 사람이 같은 문장을 두고 싸우면 영원히 안 끝난다. 서로의 좌표를 모르기 때문이다.
수렴점이 검증 능력이라면 다음 질문은 자연스럽다. 그 능력은 어디서 오는가.
짜본 적 없는 코드를 검증할 수는 없다. 리뷰어가 어떤 변경이 왜 위험한지 아는 것은 비슷한 것을 직접 잘못 짜봤기 때문이다. 검증 능력은 생성 경험의 잔여물이다. 그런데 지금 자동화가 먼저 먹어치우는 것이 바로 그 생성 경험의 초입 구간이다.
스탠퍼드 디지털경제연구소가 미국 최대 급여 처리 업체 ADP의 월별 자료로 추적한 결과, 22~25세 소프트웨어 개발자의 고용은 2022년 말 대비 약 20% 줄었다(2025년 9월 기준). AI 노출도가 높은 직군의 청년 고용은 다른 연령대 대비 13% 상대 감소를 보였고, 감소는 AI가 노동을 보완하는 직군이 아니라 대체하는 직군에 몰려 있었다.
저자들은 2026년 2월 후속 노트에서 스스로 조건을 좁혔다. 금리로는 설명되지 않는다는 것이 그들의 결론이다 — AI 노출이 높은 직군은 오히려 금리 민감도가 낮다. 다만 기업×시점 고정효과까지 넣은 가장 엄격한 통제에서는 AI 노출 직군의 감소가 2024년부터야 통계적으로 유의해지고, 그 이전 감소는 다른 요인의 몫일 가능성이 크다고 적었다. 인과가 아니라 상관이라는 단서도 유지된다.
코드가 쉽다면 신입이 맡을 일이 남지 않는다. 코드가 어렵다면 신입은 그 어려운 일을 배울 자리를 잃는다. 어느 쪽 주장이 맞든 도제 경로는 닫힌다.
라시치의 처방 — 주니어는 포인터와 재귀와 메모리 계층을 공부하라 — 은 개인에게는 옳다. 그러나 배울 자리가 사라지는 것은 개인의 학습 계획으로 풀리는 문제가 아니다. 15년 뒤 검증을 맡을 사람은 지금 생성을 하고 있어야 하는데, 그 자리가 비어가고 있다.
발화 위치를 짚는 것은 인신공격이 아니라 구조 설명이다. 라시치는 90년대부터 코드를 짜온 개발자이고, 협업 화이트보드 서비스를 만들어 미로(Miro)에 매각한 이력을 포함해 여러 회사를 세웠으며, 지금은 파트타임 최고기술책임자와 컨설팅을 겸한다. 해커뉴스에서 "결국 AI 컨설턴트 아니냐"는 반응이 나왔고, 그는 90년대부터 프로그래머이기도 하다고 답했다.
더 흥미로운 것은 문장의 분포다. "코드는 어려운 부분이 아니었다"는 말은 대체로 이미 코드를 짜지 않는 자리 — 창업자, 아키텍트, 프로덕트 매니저, 경영진 — 에서 나오고, 반박은 코드를 짜는 자리에서 나온다. 각자 자기 자리를 정확히 보고 있다. 위에서 내려다보면 구현은 여러 공정 중 하나이고, 안에서 보면 구현은 하루 전부다.
여기에 분배 함의가 붙는다. 구현이 싸지면 잉여는 요구사항과 고객 관계를 쥔 쪽으로 옮겨간다. 이 문장을 사실 주장으로 읽으면 사소하고, 배분 주장으로 읽으면 사소하지 않다. 라시치가 감지한 것은 후자였을 것이다. 그가 난이도 논쟁으로 옮겨 쓰는 바람에 상대편은 손쉽게 반박할 수 있었지만, 그가 반응한 대상 자체는 실재한다.
동시에 그의 글에도 판매 위치가 있다. 하드코어 개발자의 정서를 먼저 모으고 "적응하라"로 넘어가는 구성은 컨설팅 글의 표준 형식이며, 해커뉴스 상위 반응 중 하나가 정확히 그 점을 지적했다. 그가 붙인 추천 도서 목록에 고전 알고리즘 교재와 사용자 조사·제품 전략 서적이 나란히 놓인 것도 같은 형식의 흔적이다. 이 관찰이 그의 주장을 무너뜨리지는 않는다. 다만 이 논쟁에서 중립적인 발화 위치는 없다는 것을 보여준다.
각 예측에 반증 조건을 붙인다. 근거는 앞 절에서 확인된 현재 상태에서만 가져왔다.
개인의 작업 완료 시간은 이미 측정 불가능해지고 있다. 조직은 리뷰 대기열 길이, 머지 리드타임, 변경 실패율처럼 사람이 다중 작업을 해도 무너지지 않는 지표로 옮겨갈 것이다.
반증 조건 — 2027년 말까지 작업 단위 시간 측정 실험이 신뢰할 만한 신호를 회복하고, 주요 조직이 완료 시간을 1차 지표로 계속 쓴다면 이 예측은 틀렸다.
DORA가 관측한 불안정성 상승과 GitClear가 관측한 중복 증가는 모두 리뷰 단계에서 흡수해야 하는 부하다. 리뷰 전담 역할, 리뷰 소요 시간 예산, 산출물 출처 표기가 표준 관행으로 자리 잡는 흐름이 이어질 것이다.
반증 조건 — 2028년까지 주류 조직에서 사람이 승인하지 않은 자동 병합이 전체 병합의 과반이 된다면 이 예측은 틀렸다.
22~25세 코호트의 감소가 계속되면 5년 안에 중간 연차 공백이 드러난다. 검증 능력의 내부 공급이 끊긴 조직부터 비용을 감수하고 신입 훈련 경로를 다시 열 것이다. 다만 규모는 예전 수준으로 돌아가지 않는다.
반증 조건 — 같은 자료에서 26~30세, 31~34세 코호트까지 유사한 폭으로 감소가 확산된다면, 파이프라인 자체가 불필요해진 것이므로 이 예측은 틀렸다.
검증 비용이 낮은 영역에서는 "코드는 어려운 부분이 아니었다"가 상식으로 굳고, 검증 비용이 높은 영역 — 안전 제어, 의료, 금융 결제, 전력·교통 인프라 — 에서는 반대 방향의 규범이 생긴다. 생성 출처 기록과 검증 절차 의무가 계약서와 규제 문서에 들어가는 방향이다.
반증 조건 — 2029년까지 안전 관련 영역에서도 AI 생성 코드에 대한 별도 검증·기록 요구가 제도화되지 않고 일반 소프트웨어와 동일하게 취급된다면 이 예측은 틀렸다.
라시치의 글에서 가장 오래 버틸 문장은 논쟁적인 제목이 아니라 마지막 한 줄이다. 이해와 판단과 취향을 기계에 외주 주지 말라는 것, 책임을 넘기지 말라는 것. 이 대목은 앞의 반문 목록과 논리적으로 이어지지 않는다. 앞은 난이도 이야기이고 뒤는 책임 이야기다. 그런데 이 불연속이야말로 글이 실제로 무엇에 반응했는지를 드러낸다.
문장 하나가 이렇게 오래 사람을 붙드는 것은 그것이 명제가 아니라 좌표이기 때문이다. 코드가 어려웠는지 아닌지는 어느 사분면에서 물었느냐에 따라 답이 갈리고, 그 답은 다시 누가 무엇으로 값을 받아야 하는지에 대한 주장으로 이어진다. 지난 3년의 관측 자료가 일관되게 가리키는 것은 어느 쪽이 옳았는가가 아니다. 병목이 옮겨갔고, 옮겨간 자리를 재는 도구가 아직 없다는 것이다.