죽은 줄 알았던 '코드 줄 수' 지표, AI 시대에 이름만 바꿔 돌아왔어요

한 줄도 안 짠 날이 제일 생산적인 날일 수도 있거든요

"개발자의 생산성을 어떻게 측정할까?"라는 질문은 소프트웨어 업계만큼이나 오래된 고민이에요. 그리고 가장 먼저 나왔다가 가장 먼저 폐기된 답이 바로 '코드 줄 수(LOC, Lines of Code)'였거든요. 짠 코드가 많을수록 일을 많이 한 거다, 라는 단순한 논리인데요. 이게 왜 틀렸는지는 업계의 전설적인 일화들이 잘 보여줘요. 빌 게이츠는 "코드 줄 수로 소프트웨어 진척도를 재는 건 비행기 만드는 진척도를 무게로 재는 것과 같다"고 말했고, 컴퓨터 과학자 데이크스트라는 코드 줄 수를 '생산된 줄'이 아니라 '소비된 줄(lines spent)'로 봐야 한다고 했어요. 코드는 자산이 아니라 부채라는 거죠.

그런데 최근 한 개발자가 쓴 글이 뼈아픈 지적을 했는데요. 죽은 줄 알았던 이 지표가 AI 코딩 시대에 '더 나은 홍보 담당자(publicist)'를 만나서 화려하게 부활했다는 거예요.

이름만 바꾼 같은 지표

요즘 빅테크 발표를 보면 이런 문구가 자주 보여요. "우리 회사 신규 코드의 30%는 AI가 작성합니다", "AI가 수백만 줄의 코드를 생성했습니다" 같은 거요. 경영진이 실적 발표에서 자랑스럽게 꺼내는 숫자들인데요. 이 숫자들을 한 꺼풀 벗겨보면 결국 옛날의 '코드 줄 수 세기'와 똑같은 지표예요. 사람이 짠 줄 수를 세면 촌스러운 관리 방식이라고 욕먹는데, AI가 짠 줄 수를 세면 혁신의 증거가 되는 이상한 상황인 거죠.

이게 왜 문제냐면, 코드의 양과 가치는 별개이기 때문이에요. 오히려 반비례할 때도 많거든요. 같은 기능을 100줄로 구현한 코드보다 30줄로 깔끔하게 구현한 코드가 보통 더 좋은 코드예요. 읽기 쉽고, 버그가 숨을 자리가 적고, 나중에 고치기도 편하니까요. 리팩토링으로 1,000줄을 지운 날이 1,000줄을 새로 짠 날보다 팀에 더 큰 기여를 한 날일 수 있어요. 그런데 '줄 수'를 성과로 잡는 순간, 코드를 지우는 일은 마이너스 성과가 돼버리는 거죠.

굿하트의 법칙이 또 등장해요

여기서 등장하는 게 '굿하트의 법칙(Goodhart's Law)'인데요. "어떤 지표가 목표가 되는 순간, 그 지표는 좋은 지표이기를 멈춘다"는 법칙이에요. 쉽게 말해, 시험 점수로만 학생을 평가하면 공부 대신 시험 요령만 느는 것과 같은 원리거든요. AI가 생성한 코드 비율을 KPI로 잡으면 어떤 일이 벌어질까요? 개발자들은 AI가 뱉어낸 장황한 코드를 굳이 다듬지 않고 그대로 커밋할 유인이 생겨요. 검토하고 줄이는 노력보다 생성량이 보상받으니까요. 결과적으로 코드베이스는 부풀어 오르고, 유지보수 비용은 조용히 쌓여가는 거죠.

실제로 AI 코딩 도구가 널리 퍼진 뒤 코드 중복이 늘고 리팩토링 비중이 줄었다는 분석도 나오고 있어요. AI는 기존 코드를 재사용하도록 정리하는 것보다 비슷한 코드를 새로 생성하는 데 더 능숙하거든요. 줄 수 기준으로는 생산성이 폭발한 것처럼 보이지만, 소프트웨어의 건강 상태로 보면 정반대일 수 있다는 거예요.

그럼 뭘 측정해야 할까요

그렇다고 "측정하지 말자"가 답은 아니에요. 경영진 입장에서는 AI 도구에 쓰는 돈이 효과가 있는지 확인하고 싶은 게 당연하니까요. 핵심은 측정 대상을 '산출물의 양'이 아니라 '결과'로 바꾸는 거예요. 예를 들어 DORA 메트릭이라고 불리는 지표들, 그러니까 배포 빈도, 변경 리드 타임(코드 작성부터 배포까지 걸리는 시간), 변경 실패율, 장애 복구 시간 같은 것들은 '코드를 얼마나 짰나'가 아니라 '소프트웨어가 사용자에게 가치를 얼마나 빠르고 안정적으로 전달하나'를 봐요. AI 도구가 정말 효과가 있다면 이런 지표에서 개선이 나타나야 하는 거죠.

한국 개발 조직에도 시사점이 커요. 요즘 많은 회사들이 AI 코딩 도구를 도입하면서 "도입 효과를 수치로 보고하라"는 요구를 받는데요. 이때 'AI 생성 코드 비율'이나 '생성된 줄 수' 같은 숫자를 보고 지표로 잡는 순간, 팀의 행동이 그 숫자에 맞춰 왜곡되기 시작해요. 보고하기 쉬운 숫자와 의미 있는 숫자는 다르거든요. 차라리 PR 리뷰 소요 시간, 버그 재발률, 신규 입사자의 온보딩 속도 같은 걸 함께 보는 게 훨씬 건강한 접근이에요.

마무리

정리하면, "코드 줄 수는 생산성이 아니다"라는 30년 묵은 교훈이 AI 시대에 와서 다시 시험대에 올랐다는 이야기예요. 사람이 짜든 AI가 짜든, 코드는 많을수록 좋은 자산이 아니라 적을수록 좋은 부채니까요. 여러분 회사에서는 AI 코딩 도구의 효과를 어떤 지표로 측정하고 있나요? '줄 수의 부활'을 현장에서 체감한 경험이 있다면 들려주세요.