코드 라인 수(LOC) 메트릭의 부활: AI 시대에 더 악화된 개발 생산성 측정의 함정

3줄 요약

• Google, Microsoft, Meta 등 주요 테크 기업들이 AI 생성 코드 비율(25-90%)을 성과 지표로 발표하면서 40년 전 폐기된 코드 라인 수(LOC) 메트릭이 부활했습니다
• GitClear 분석에 따르면 2024년 복사-붙여넣기 코드가 8.3%에서 12.3%로 증가했고, 리팩토링은 60% 감소하며 코드 품질이 악화되고 있습니다
• 진정한 생산성 측정을 위해서는 코드 생성량 대신 시간-가치 전환, 코드 반감기, 결함 발생률, 이해도 커버리지 등 결과 중심 메트릭이 필요합니다

📌 주요 내용

코드 라인 수(LOC) 메트릭의 역사와 합의된 폐기

소프트웨어 업계는 탭 대 스페이스, 모놀리스 대 마이크로서비스 등 많은 주제에서 의견이 갈리지만, 약 40년 동안 하나의 합의점이 있었습니다. 바로 코드 라인 수(Lines of Code, LOC)는 끔찍한 메트릭이라는 것입니다.

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

2009년 Tom DeMarco는 “측정할 수 없는 것은 제어할 수 없다”는 자신의 유명한 발언을 공식적으로 철회했습니다. 소프트웨어 프로젝트는 본질적으로 실험적이며, 중요한 목표는 제어가 아닌 변환이라는 결론을 내렸습니다. 2023년에는 Kent Beck이 LOC를 “입력 메트릭”—최악의 범주—이라고 불렀습니다. “성공을 측정할 다른 방법이 없을 때만 사용하라”는 것이 그의 조언이었습니다.

AI 시대의 LOC 부활: 주요 기업들의 경쟁

그러던 합의가 AI의 등장과 함께 깨졌습니다. 현재 모든 주요 테크 기업 CEO들은 자사 코드 중 AI가 작성한 비율로 경쟁하고 있습니다.

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

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

도구와 문화가 강화하는 LOC 집착

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

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

한 개발자는 자신의 AI 에이전트 출력(3개월 동안 320만 줄)을 60년 동안 70만 줄이라는 자신의 평생 성과와 비교했습니다. 그리고 Grok을 사용하여 LOC가 유효한 메트릭인 이유에 대한 논증을 생성했습니다. AI를 사용하여 AI가 무의미하게 만든 메트릭을 정당화하는 것입니다.

굿하트 법칙의 극대화: 왜 더 악화되었나

굿하트 법칙(Goodhart’s Law)은 말합니다: 측정값이 목표가 되면, 좋은 측정값이 되기를 멈춥니다. LOC는 AI가 등장하기 전에도 이의 교과서적 사례였습니다. AI는 단순히 실수를 반복한 것이 아니라, 실수를 폭발시켰습니다.

세 가지 레이어로 생각해보겠습니다:

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

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

레이어 3: 우리는 굿하트 법칙에 굿하트 법칙을 적용하고 있습니다. 이미 고장난 메트릭이 이제 무한한 조작 능력을 가진 시스템의 목표가 되었습니다. 나쁜 메트릭을 단지 나쁜 수준으로 유지했던 제약이 제거되었고, 남은 것은 아무것도 측정하지 않는 메트릭입니다.

데이터가 보여주는 품질 저하

GitClear는 2020년부터 2024년까지 프라이빗 저장소와 25개 주요 오픈소스 프로젝트에서 2억 1,100만 줄의 코드를 분석했습니다. 결과는 다음과 같습니다:

• 복사-붙여넣기 코드가 8.3%에서 12.3%로 증가
• 5줄 이상 중복된 코드 블록이 2024년 동안 8배 증가
• 리팩토링 붕괴: 이동 및 재구조화된 라인 비율이 2020년 24.1%에서 2024년 9.5%로 하락 (60% 감소)
• 코드 변동률(churn) 2배 증가: 커밋 후 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%에 보안 결함이 포함되어 있습니다. 한 스웨덴 vibe-coding 플랫폼은 테스트된 1,645개 앱 중 170개에서 악용 가능한 취약점을 발견했습니다.

수락률: 새로운 포장의 같은 문제

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

하지만 이는 LOC가 가진 모든 결함과 새로운 결함들을 겪고 있습니다. 코드를 수락한다고 해서 그것이 좋은 코드라는 의미는 아닙니다. 개발자는 충분히 가깝기 때문에, 거부하고 다시 작성하는 데 지쳤기 때문에, 각 제안을 평가하는 컨텍스트 전환 비용이 단순히 받아들이는 비용을 초과하기 때문에 제안을 수락할 수 있습니다.

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

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

LOC가 의미 있을 때와 AI 도구의 진정한 가치

LOC가 항상 무의미한 것은 아닙니다. 러프한 규모 측정 메트릭으로서—생산성 메트릭이 아닌—코드 라인 수는 프로젝트 범위를 추정하는 데 도움이 될 수 있습니다. 시간 경과에 따른 코드베이스 성장 추적은 유지보수성 문제가 위기가 되기 전에 신호를 보낼 수 있습니다.

AI 코딩 도구 자체도 문제가 아닙니다. 문제는 우리가 그것들을 측정하는 방법입니다. Redis 창시자 antirez(Salvatore Sanfilippo)는 AI가 무엇을 만들어야 하는지 알 때 실제로 더 빠르게 구축할 수 있게 한다는 설득력 있는 사례를 제시합니다. 그는 5분 만에 BERT와 유사한 임베딩 모델용 순수 C 라이브러리를 만들었습니다: PyTorch와 비슷한 출력의 700줄 코드. 가치는 무엇을 만들어야 하는지에 대한 그의 수십 년 지식에 있었고, AI는 타이핑을 처리했습니다. 이것이 정당한 생산성 향상입니다.

MIT Technology Review는 생성형 코딩을 2026년 10대 혁신 기술 중 하나로 선정했습니다. 이러한 인정은 마땅합니다. 이 도구들은 보일러플레이트, 익숙하지 않은 API 탐색, 문제 러버덕킹, 신속한 프로토타이핑에 유용합니다.

대안 메트릭: 무엇을 측정해야 하는가

LOC와 수락률이 고장났다면, 명백한 질문은: 무엇으로 대체해야 하는가입니다. 답은 보고 있는 대상의 근본적인 전환을 요구합니다. 입력 측정을 중단하고—생성된 라인, 수락된 제안, AI 코드 비율—결과 측정을 시작하십시오.

네 가지 메트릭이 굿하트 법칙에서 살아남습니다:

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

코드 반감기(Code half-life): 새 코드가 수정이 필요하기 전에 얼마나 오래 살아남는가? GitClear의 변동률 데이터는 AI 코드가 더 빨리 수정된다는 것을 보여줍니다. 건강한 코드는 긴 반감기를 가집니다. 14일 만에 다시 작성되는 코드는 결코 완성되지 않은 것입니다.

결함 발생률(Defect origin rate): 프로덕션 결함의 몇 퍼센트가 AI 생성 코드 대 인간 작성 코드로 거슬러 올라가는가? 비난 메트릭이 아닌 보정 메트릭으로서입니다.

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

메타 원칙: 좋은 메트릭은 코드가 작성된 후 무슨 일이 일어났는지를 측정합니다. 나쁜 메트릭은 작성 중에 무슨 일이 일어났는지를 측정합니다. 코드 작성 행위는 결코 병목이 아니었습니다. 이해, 설계, 판단이 병목입니다. 그에 따라 측정하십시오.

진짜 질문들

이사회가 AI 생성 코드의 비율이 몇 퍼센트인지 물을 때, 그들은 무엇을 묻고 있습니까? 그리고 당신이 제공하는 답변이 그들이 들어야 하는 것입니까?

AI 도구가 내일 사라진다면, 당신의 팀은 더 느리게 배송할까요—아니면 단지 더 적은 코드를 작성할까요?

팀의 누군가가 기억으로 설명할 수 있는 코드베이스의 비율은 얼마입니까? 그 숫자는 올라가고 있습니까, 내려가고 있습니까?

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

원문 기사 보기