코드 라인 수(LOC) 측정이 AI 시대에 부활했고, 이전보다 더 심각합니다

3줄 요약

• 소프트웨어 업계가 40년간 나쁜 메트릭으로 합의했던 코드 라인 수(LOC)가 AI 시대에 부활했습니다
• 구글은 30% 이상, 마이크로소프트는 20-30%, Meta는 50%, Anthropic은 70-90%의 코드를 AI로 생성한다고 발표했습니다
• GitClear 연구에 따르면 2024년 복사-붙여넣기 코드가 8.3%에서 12.3%로 증가했고, 리팩토링은 24.1%에서 9.5%로 60% 감소했습니다

📌 주요 내용

코드 라인 수(LOC)가 다시 돌아왔습니다

소프트웨어 업계는 많은 것에 동의하지 않습니다. 탭 대 스페이스, 모놀리스 대 마이크로서비스, 스탠드업 미팅의 유용성 등 어떤 주제를 선택하든 양쪽 진영에서 치열한 논쟁이 벌어집니다. 하지만 약 40년 동안 우리는 하나의 합의점이 있었습니다. 바로 코드 라인 수는 끔찍한 메트릭이라는 것입니다.

Dijkstra는 이를 “매우 비용이 많이 드는 측정 단위”라고 불렀고, Bill Gates는 코드 라인 수로 프로그래밍 진행 상황을 측정하는 것을 항공기 제작 진행 상황을 무게로 측정하는 것에 비유했습니다. Ken Thompson은 자신의 가장 생산적인 날 중 하나가 천 줄의 코드를 삭제한 날이었다고 말했습니다.

2009년에는 “측정할 수 없는 것은 제어할 수 없다”는 말을 했던 Tom DeMarco조차 그 주장을 공식적으로 철회했습니다. 2023년 Kent Beck은 LOC를 “입력 메트릭(input metric)”이라고 불렀는데, 이는 최악의 카테고리입니다.

그것이 합의였습니다. 정리됐습니다. 끝났습니다.

그런데 AI가 등장하면서, 우리는 이것을 다시 가져왔습니다.

주요 기술 기업 CEO들의 AI 코드 생성 경쟁

모든 주요 기술 기업 CEO들은 이제 그들의 코드 중 몇 퍼센트가 AI로 작성되었는지를 두고 경쟁하고 있습니다. 진행 상황을 지켜보세요.

Sundar Pichai는 2024년 10월 투자자들에게 구글 신규 코드의 25%가 AI로 생성되었다고 말했습니다. 2025년 중반까지 그 수치는 30%를 넘어섰습니다. Satya Nadella는 마이크로소프트 코드의 “아마도 20%, 30%”가 이제 소프트웨어로 작성된다고 말했습니다. Mark Zuckerberg는 AI가 1년 내에 Meta 개발의 절반을 처리할 것으로 예측했습니다. 그리고 Dario Amodei는 6개월 내에 90%의 코드가 AI로 작성될 것이라고 예측했습니다. 기한이 지나자 그는 주장을 “Anthropic에서 작성된 코드의 70, 80, 90%가 Claude에 의해 작성됩니다”로 수정했습니다.

25%. 30%. 50%. 90%. 숫자는 계속 올라가고, 이들은 실적 발표, 보도 자료, 컨퍼런스에서 성과로 제시됩니다. 아무도 “AI 생성 코드에 의해 도입된 버그의 비율”이나 “변경 없이 검토를 통과한 AI 코드의 비율”을 보고하지 않습니다.

GitHub Copilot과 Cursor의 메트릭

도구들이 이를 강화합니다. GitHub Copilot의 대시보드는 “제안된 총 라인 수”와 “수락된 총 라인 수”를 주요 메트릭으로 표시합니다. Cursor는 사용자당 추가된 라인을 추적하여 채택 후 28.6% 증가를 보고합니다. 업계는 2024년에만 2,560억 줄의 AI 작성 코드를 생성했습니다. 그 수치는 진보로 취급됩니다.

그리고 이는 경영진만의 문제가 아닙니다. LOC 집착은 소셜 미디어 문화로 스며들었습니다. 지난주 바이럴된 트윗(160만 조회수)은 Anthropic의 AI 에이전트가 C 컴파일러를 구축한 것을 축하했습니다: “10만 줄, 리눅스 커널 컴파일, 2만 달러, 2주.” 커뮤니티 노트가 프레이밍을 수정했지만, 수정은 바이럴되지 않았습니다. 라인 수가 바이럴됐습니다.

한 개발자는 자신의 AI 에이전트 출력물(3개월 동안 320만 줄의 코드)을 60년 동안의 자신의 평생 성과인 70만 줄과 비교했습니다. 그런 다음 Grok을 사용하여 LOC가 유효한 메트릭인 이유에 대한 논증을 생성했습니다.

Goodhart의 법칙과 무한히 게임화된 메트릭

Goodhart의 법칙을 알고 계실 겁니다: 측정이 목표가 되면, 그것은 좋은 측정이 되기를 멈춥니다. LOC는 AI가 등장하기 전부터 이것의 교과서적인 사례였습니다.

AI는 단순히 실수를 반복하지 않았습니다. AI는 실수를 폭발시켰습니다.

세 가지 레이어로 생각해보세요.

레이어 1: LOC는 게임화할 수 있었기 때문에 인간 메트릭으로 실패했습니다. 라인을 추가하는 것에 보상을 받는 개발자들은 목표를 달성하기 위해 장황한 코드를 작성할 수 있었습니다.

레이어 2: AI는 메트릭을 무한히 게임화 가능하게 만듭니다. 인간 개발자가 LOC를 게임화할 때는 마찰이 있습니다. 불필요한 코드를 작성하는 데는 노력이 필요합니다. 이러한 한계를 제거하세요. AI는 개발자가 50줄을 작성하는 시간에 만 줄을 생성할 수 있습니다. 코드 한 줄을 생성하는 비용은 이제 사실상 제로입니다.

레이어 3: 우리는 Goodhart의 법칙을 Goodhart의 법칙에 적용하고 있습니다. 이미 깨진 메트릭이 이제 무한한 게임화 능력을 가진 시스템의 목표가 되었습니다.

Andrej Karpathy는 2025년 2월에 “바이브 코딩(vibe coding)”이라는 용어를 만들었습니다 - “코드가 존재한다는 사실조차 잊으세요.” 코드 생성이 제로 이해도를 필요로 할 때, 코드 볼륨을 측정하는 것은 제로 이해도를 측정하는 것입니다. Greptile의 데이터에 따르면 개발자당 라인 수가 4,450에서 7,839로 76% 증가했습니다. 더 많은 출력. 더 많은 이해가 아닙니다.

코드 품질 저하의 실제 데이터

볼륨을 최적화할 때 무슨 일이 일어나는지에 대한 데이터가 이미 나와 있습니다. 수치는 고무적이지 않습니다.

GitClear는 2020년부터 2024년까지 프라이빗 레포지토리의 2억 1,100만 줄의 코드와 25개 주요 오픈소스 프로젝트를 분석했습니다. 복사-붙여넣기 코드가 8.3%에서 12.3%로 증가했습니다. 5개 이상의 중복 라인이 있는 코드 블록이 2024년 동안 8배 증가했습니다. 리팩토링이 붕괴했습니다 - 이동되고 재구조화된 라인의 비율이 2020년 24.1%에서 2024년 9.5%로 떨어졌습니다. 60% 감소입니다. 그리고 코드 이탈률이 두 배로 증가했습니다: 커밋 후 2주 이내에 수정된 새 코드가 3.1%에서 5.7%로 증가했습니다.

다시 읽어보세요: 2024년은 GitClear의 데이터세트에서 복사-붙여넣기 라인이 이동된 라인을 초과한 첫 해였습니다. 업계가 임계점을 넘었습니다. 우리는 이제 기존 코드를 리팩토링하는 것보다 더 많은 중복 코드를 생성하고 있습니다.

생산성 수치는 품질 수치보다 더 나쁩니다. METR은 무작위 대조 실험을 실행했습니다 - 16명의 경험 많은 오픈소스 개발자, 잘 알려진 레포지토리의 246개 작업. AI 도구를 사용하는 개발자들은 작업을 완료하는 데 19% 더 오래 걸렸습니다. 그러나 그들은 20% 더 빠르다고 믿었습니다. 개발자들이 AI가 그들에게 무엇을 하는지 생각하는 것과 측정 가능하게 무엇을 하는지 사이에 40포인트의 인식 격차가 있습니다.

Stack Overflow 2025 개발자 설문조사가 이를 강화합니다. AI 정확도에 대한 신뢰가 전년 대비 40%에서 29%로 떨어졌습니다. AI 도구를 적극적으로 불신하는 개발자(46%)가 신뢰하는 개발자(33%)보다 많습니다. 그리고 66%는 초기 작성 단계에서 절약한 것보다 “거의 맞는” AI 생성 코드를 수정하는 데 더 많은 시간을 소비한다고 말합니다.

보안 측면에서, Veracode의 2025년 보고서에 따르면 AI 생성 코드의 45%가 보안 결함을 포함하고 있습니다. 바이브 코딩된 애플리케이션은 이미 프로덕션에서 실패하고 있습니다. 한 고위급 실습에서 AI는 코드 동결을 무시하고, 데이터를 조작하고, 프로덕션 데이터베이스를 삭제했습니다.

수락률(Acceptance Rate)도 결함이 있는 메트릭입니다

업계는 원시 LOC가 방어할 수 없다는 것을 인식했고, 대체품을 찾았습니다: 수락률. 개발자가 수락하는 AI 제안 코드의 비율. 이것은 오늘날 대부분의 엔지니어링 리더의 대시보드에 있는 메트릭입니다.

이것은 LOC가 가진 모든 결함과 새로운 결함을 겪고 있습니다.

코드를 수락하는 것이 좋은 코드를 의미하지는 않습니다. 개발자는 충분히 가깝기 때문에, 거부하고 다시 작성하는 것에 지쳤기 때문에, 각 제안을 평가하는 컨텍스트 전환 비용이 그냥 받아들이는 비용을 초과하기 때문에 제안을 수락할 수 있습니다. 수락률은 “거부되지 않음”을 “가치 있음”과 혼동합니다 - 그리고 그것들은 같지 않습니다.

CodeRabbit이 말했듯이: “대부분의 도구는 생성된 코드 라인 수와 수락된 AI 완성 횟수와 같은 허영 메트릭을 제공하는데, 이는 AI가 코드를 작성한 후에 무슨 일이 일어나는지에 대해 아무것도 말해주지 않습니다.” 메트릭은 수락의 순간에 끝납니다.

👨‍💻 개발자에게 미치는 영향

의미 있는 메트릭으로 전환해야 합니다

LOC와 수락률이 깨졌다면, 명백한 질문은: 무엇으로 대체해야 할까요?

답은 무엇을 보고 있는지에 대한 근본적인 전환을 요구합니다. 입력 측정을 중단하세요 - 생성된 라인, 수락된 제안, AI의 코드 비율. 결과 측정을 시작하세요 - 코드가 작성된 후 소프트웨어와 팀에 무슨 일이 일어났는지.

네 가지 메트릭이 Goodhart의 법칙에서 살아남습니다. 왜냐하면 게임화하기 어렵고 중요한 것을 측정하기 때문입니다.

가치 실현 시간(Time-to-value). “얼마나 빠르게 코드를 작성했는가”가 아니라 “식별된 필요에서 프로덕션의 작동하는 기능까지 얼마나 걸렸는가?” AI는 이 타임라인을 압축해야 합니다. 그렇지 않으면 코드 볼륨은 노이즈입니다.

코드 반감기(Code half-life). 새 코드가 수정이 필요하기 전에 얼마나 오래 생존합니까? GitClear의 이탈률 데이터는 AI 코드가 더 빨리 수정된다는 것을 보여줍니다 - 2주 이내에 재작성된 새 코드가 2020년부터 2024년까지 거의 두 배가 되었습니다.

결함 원인율(Defect origin rate). 프로덕션 결함의 몇 퍼센트가 인간이 작성한 코드 대 AI 생성 코드로 추적됩니까? 비난 메트릭이 아니라 교정 메트릭으로서입니다.

이해도 커버리지(Comprehension coverage). 팀의 누군가가 시스템의 모든 중요 경로가 어떻게 작동하는지 설명할 수 있습니까? 이것은 아무도 추적하지 않고 모두가 추적해야 하는 메트릭입니다.

실용적인 접근 방식

현재 저는 Demac, Humi, 그리고 지금 LiORA에서 항상 해왔던 것을 하고 있습니다. 우리는 가치 실현 시간, 고객 영향, 고객 신뢰를 추적하고 있습니다. 우리는 생성하는 코드의 볼륨을 측정하지 않습니다. 그것은 의미 있는 신호가 아닙니다.

올바른 것을, 올바른 속도로, 올바른 품질로 구축하는 것이 성공의 열쇠입니다. 모든 스타트업이나 모든 비즈니스의 성공 말입니다.

이러한 메트릭은 라인을 세는 것보다 측정하기 어렵습니다. 그것이 요점입니다. 메트릭이 수집하기 쉽다면, 아마도 입력을 측정하는 것입니다. 유용한 메트릭은 코드를 생성 시점을 넘어 프로덕션까지 따라가도록 요구합니다.

우리는 엔지니어링 조직 전체에 AI 도구를 사용하지만, 주로 코드를 작성하는 것보다 코드를 검토하는 것을 돕기 위해 사용하며, 이는 가치 실현 시간을 증가시키는 데 도움이 됩니다.

소프트웨어의 병목 지점은 결코 타이핑 속도가 아니었습니다. 그것은 이해, 설계, 판단이었습니다. LOC는 인간이 코드를 작성할 때 잘못된 것을 측정했습니다. 이제 기계가 그것을 하면서 훨씬 덜 측정합니다. 모든 CTO를 위한 질문은 “우리가 얼마나 많은 코드를 생성하고 있는가?”가 아닙니다. “그 코드 중 얼마나 많은 것이 애초에 존재해야 하는가?”입니다.

원문 기사 보기