AI가 짠 코드 30%? '코드 라인 수'라는 망령이 돌아왔습니다
요즘 빅테크 CEO들의 단골 멘트가 하나 생겼습니다. “우리 회사 코드의 30%는 AI가 짭니다.” 듣기엔 그럴듯한데, 자세히 들여다보면 어딘가 익숙한 냄새가 납니다. 개발 업계에서 오래전에 폐기된 그 지표, 바로 ‘코드 라인 수’가 AI라는 옷을 갈아입고 돌아온 겁니다.
오늘은 이 자랑 경쟁이 왜 위험한 신호인지, 그리고 우리가 진짜 봐야 할 것은 무엇인지 이야기해보려고 합니다.
“AI가 코드의 30%를 짠다"는 말의 정체
지난 몇 년간 여러 빅테크 수장들이 비슷한 발언을 쏟아냈습니다. AI가 사내 코드의 4분의 1을, 어떤 곳은 절반 가까이를 생성한다는 식이죠. 숫자만 보면 혁신적입니다. 그런데 한 가지 질문을 던져봐야 합니다. 그 비율은 대체 어떻게 측정한 걸까요?
대부분은 자동완성이 제안한 글자 수, 혹은 AI 도구가 커밋에 끼어든 라인 수를 기준으로 잡습니다. 즉 “AI가 타이핑한 양"입니다. 코드가 좋은지, 실제로 배포됐는지, 한 달 뒤에도 살아남았는지는 따지지 않습니다.
여기서 핵심을 짚자면, 이 지표는 생산성이 아니라 생산량을 잽니다. 둘은 전혀 다른 이야기입니다.
한때 조롱받던 ‘LOC’의 부활
코드 라인 수, 영어로 LOC(Lines of Code)는 소프트웨어 업계에서 오래된 흑역사입니다. 1980년대부터 관리자들은 개발자를 라인 수로 평가하려 했고, 그때마다 처참하게 실패했습니다.
이유는 단순합니다. 라인 수로 평가하면 사람은 라인을 늘리는 방향으로 움직입니다. 세 줄로 끝낼 일을 굳이 열 줄로 풀고, 중복 코드를 복사 붙여넣기 합니다. 좋은 개발자가 하는 일은 오히려 그 반대인데 말이죠. 코드를 줄이고, 합치고, 지웁니다.
그래서 나온 유명한 농담이 있습니다. “라인 수로 프로그래밍 진척도를 재는 건, 비행기 제작 진척도를 무게로 재는 것과 같다.” 빌 게이츠가 했다고 알려진 이 말은 LOC 지표의 허망함을 정확히 찌릅니다.
그런데 AI 시대가 되자 이 망령이 슬그머니 부활했습니다. 이번엔 개발자 개인이 아니라 회사 전체의 ‘AI 활용도’를 자랑하는 도구로요.
왜 CEO들은 이 숫자에 집착할까
이유를 이해하려면 그들의 입장에 서봐야 합니다. AI에 막대한 돈을 쏟아부은 경영진은 그 투자가 효과 있다는 증거가 필요합니다. 그리고 주주와 시장에 보여주기 가장 쉬운 숫자가 바로 “AI가 코드의 X%를 생성합니다"입니다.
문제는 이 숫자가 보여주기엔 완벽하지만 실속은 없다는 점입니다.
첫째, 측정 기준이 제각각입니다. A사의 30%와 B사의 30%가 같은 의미인지 아무도 모릅니다.
둘째, AI가 생성한 코드가 실제로 쓰이는지 불분명합니다. 자동완성으로 뜬 제안을 개발자가 받아들였다가 곧바로 지우는 경우도 라인 수에는 잡힙니다.
셋째, 가장 중요한 것을 놓칩니다. 코드는 적게 짤수록 좋을 때가 많습니다. 버그 없는 100줄이 버그투성이 1000줄보다 훨씬 가치 있죠.
진짜 봐야 할 지표는 따로 있다
그럼 AI가 개발에 도움이 되는지 어떻게 알 수 있을까요. 라인 수가 아닌 결과를 봐야 합니다.
기능이 더 빨리 출시되는지, 버그가 줄었는지, 개발자가 지루한 반복 작업에서 해방돼 더 중요한 문제에 집중하는지. 이런 것들이 진짜 생산성입니다. 측정하기 어렵지만, 어렵다고 엉뚱한 걸 재는 건 핑계일 뿐입니다.
실제로 현장 개발자들 사이에서는 우려의 목소리도 큽니다. AI가 쏟아내는 코드를 검토하고 고치는 데 드는 시간이 만만치 않다는 겁니다. 생성은 빨라졌는데 리뷰 부담이 늘었다면, 전체 속도는 오히려 느려질 수 있습니다. ‘코드 부채’가 쌓이는 거죠.
마무리
‘AI가 짠 코드 비율’은 듣기 좋은 마케팅 문구입니다. 하지만 그 본질은 40년 전에 실패한 라인 수 지표의 재탕에 가깝습니다. 숫자가 크다고 일을 잘하는 게 아니라는 교훈을, 우리는 이미 비싼 값을 치르고 배웠습니다.
다음에 어떤 회사가 “우리 코드의 절반은 AI가 만듭니다"라고 자랑하거든, 한 번쯤 되물어 보면 어떨까요. 그래서 그 소프트웨어는 더 좋아졌나요? 숫자를 자랑하는 것과 가치를 만드는 것, 여러분은 무엇을 보고 계신가요?
댓글
댓글을 불러오는 중...