코드 라인 수가 더 나은 홍보 담당자를 얻었다 — 2026년 AI 코딩 효율성 논란 정리

코드 라인 수가 더 나은 홍보 담당자를 얻었다 — 2026년 AI 코딩 효율성 논란 정리

2026년 6월, AI 코딩 시장은 "코드 라인 수" 경쟁으로 점철된다. AI 작성 코드 비율은 75~80%에 이르렀고, 코드량 정량화는 곧장 채용·감원·예산 결정을 움직인다. 본문은 curlewis.co.nz 글과 Hacker News 토론을 종합해 AI 코딩 효율성 측정의 허상과, 개발팀이 채택해야 할 검증된 측정 프레임을 정리한다. "성과인가 볼륨인가"를 묻는 단일 질문이 팀의 평가 문화를 다시 세우는 출발점이 된다.

코드 라인 수 지표가 다시 주목받는 이유

SaaS 시대부터 두 시니어 개발자 중 40% 더 많은 코드를 작성한 사람이 더 낫다고 평가받아서는 안 된다. 실제로 중요한 것은 무엇이 출시(ship)되어 고객·매출·안정성에 기여했는가이다. 코드 라인 수와 PR 개수는 수십 년간 나쁜 측정 방식으로 학습됐고, 2026년의 AI 벤더들은 이 지표를 더 세련된 포장인 "AI 작성 비율"로 재활용한다. 모두 AI 회사라는 점에서 채택률 부풀리기 동기가 작동한다.

성과 주장은 어떻게 변질됐는가

과거 GitHub Copilot의 55% 작업 속도 향상 주장은 반증 가능한 성과(outcome)였다. 반면 2026년의 "코드 75%가 AI 작성"은 실제 개선과 무관하게 사실일 수 있고 계속 상승한다. 볼륨 수치는 채택이 정체될 때만 실망을 주며, 채택이 진짜라는 점에는 대부분 동의한다. 주장은 커졌으나 실제로 말하는 바는 줄어들었다.

연구가 보여주는 AI 생산성의 진실

성과 증거는 양쪽으로 갈린다. Cui et al.의 5,000명 개발자 대상 연구는 완료 작업 +26%를, 특히 주니어 개발자에서 가장 큰 향상을 보였다. 반면 GitClear는 Copilot 채택이 깊어질수록 코드 처닝(churn) 증가와 리팩터링 붕괴를, METR는 숙련 개발자가 AI 사용 시 19% 느려졌다고 보고했다. 2026년 2월 METR은 후속 추정으로 입장을 번복해 "AI가 개발자 속도를 높일 가능성이 크나 그 정도를 깔끔하게 측정할 수 없다"로 정리했다. NBER의 6,000명 임원 조사에서는 약 10곳 중 9곳이 측정 가능한 생산성 효과가 없다고 답해, 조직 단위 효과는 약 10% 수준에 머무른다. Anthropic이 2026년 상반기에 공개한 RCT는 AI 지원 개발자가 방금 출시한 코드 이해도에서 17% 낮은 점수를 기록했다는 점에서 "8배 더 많은 코드" 주장과 모순을 보인다. Augment가 219명 엔지니어링 리더에게 "AI-native engineering" 정의를 물었더니 219개의 서로 다른 답변이 나왔다. 도구 벤더마다 "성숙도 사다리"를 출시하지만 최상단은 거의 항상 자사 제품을 더 많이 쓰라는 권고다. 마케팅 효과까지 겹치면, AI 코딩 효율성의 진짜 측정값은 단일 지표로 환원되지 않는다.

AI를 명분으로 한 감원과 허영 지표

이 수치들은 예산·성과 기대치·인력 계획을 움직인다. 2026년 2월 Jack Dorsey는 Block 인력의 40% 이상(4,000명+) 감축을 AI를 명시적 논거로 발표했고, Atlassian은 10%(약 1,600명) 감축을 단행했다. Dorsey는 같은 자리에서 사업이 견조하고 총이익이 성장 중이라 언급해, 감원이 다른 이유(과잉 채용, 투자자 압박)로 내려진 결정의 PR 역할임을 시사했다. 효율성 기반 감축이 정당할 때도 있지만, 그럴 때는 토큰 수나 "AI 작성 코드 비율"이 아니라 이미 운영 중인 개인 성과 시스템을 사용해야 한다. 선별 근거가 허영 지표라면 그 선별은 립스틱 바른 복권에 불과하다. 이 흐름을 끊으려면 CEO 발표 단계에서 "AI로 N% 감축"과 "어떤 결과 지표가 같은 비율로 좋아졌는가"를 한 문장으로 묶어 보고하도록 회계 기준을 손봐야 한다. 그 연결 고리가 없으면 그 감축 결정은 데이터가 아니라 마케팅이다.

개발자·팀이 채택해야 할 측정 프레임

2026년 6월 기준으로, 일하는 방식은 AI-first로, 측정하는 방식은 검증된 방식으로 분리하는 것이 핵심이다. 분리하지 않으면 같은 발표에서 "AI 8배"와 "RCT 부재"가 양립하는 모순이 매 분기 반복된다.

단기적으로는 팀 단위 DORA 지표(주 배포 빈도, 변경 리드타임, 변경 실패율, 복구 시간)를 분기별 리뷰에 다시 올려놓는 것이 출발점이다. 코드 라인 수나 AI 작성 비율은 평가 등급에서 제거하고, PR당 리뷰 라운드 수와 머지 후 defect율을 보완 지표로 활용한다. 중기적으로는 개인 성과 시스템에 "출시 가치" 정량화 항목(매출 기여, MAU 영향, NPS 변화)을 명시적으로 추가한다. AI 도구 사용률은 의무화하되, 코드 볼륨이 아니라 결과 지표로 보상한다. 마지막으로 임원 발표에서 "AI로 X% 감축" 같은 문구가 나오면, 그 감소분이 어떤 결과 지표의 향상과 연결되는지 직접 묻고, 연결 고리가 없으면 결정을 보류해야 한다.

코드 줄은 우리가 지불하는 가격이다. 무엇을 샀는지를 함께 말하지 않고 "코드 200줄"이라고 자랑하지 말아야 한다. 새 기능 X를 구현했는데 200줄밖에 들지 않았다는 표현처럼, 비용 관점에서 수치를 다시 서술하는 팀이 다음 1년 동안 가장 빠르게 성장한다. AI 도입은 출발선이지 점수판이 아니다. 검증된 지표를 버리고 AI 허영 점수를 택할 이유는 없다. 2026년 6월 기준으로, "이것은 성과인가, 볼륨인가?"라는 단일 질문이 팀의 평가 문화를 다시 세우는 출발점이 된다. Hacker News 토론에서 반복적으로 등장한 표현이 있다. "이건 마치 사무실에 있는 시간을 일한 시간이라고 보고하던 시절과 다르지 않다." AI slop은 비기술자에게도 직관적으로 와닿는 단어지만, 같은 무게로 통하던 기술 부채는 경영진 앞에 다시 세우지 못한다. 그래서 검증된 측정 프레임으로의 복귀는 단순한 선택이 아니라, AI 시대의 엔지니어링 정체성 회복이다. 1년 뒤 팀의 평가 시트를 다시 꺼냈을 때, "코드 라인 수"가 사라지고 "출시 가치"가 남아 있는 것이 이 시기 개발자가 남길 가장 의미 있는 변화다.