태그: AI / Claude Code / Cursor / LOC / 생성형 AI

최근, 어떤 경영자분의 인터뷰 기사를 보았습니다.

「비엔지니어인 내가, 2개월 만에 코드를 10만 행 작성했다」

처음에 든 생각은 이것뿐이었습니다.

10만 행이라니…… 단기간에 혼자서 그렇게나 많이 쓸 수 있는 건가?

엄청난 양이구나, 라고 솔직히 놀랐습니다. 하지만 동시에, 이런 의문도 생겼습니다.

애초에 LOC란 무엇을 세는 것인가?

AI로 개발할 때, 행수는 도대체 어떻게 카운트하는 걸까?

궁금해져서 직접 조사해 보기로 했습니다. 이 기사는 그 조사 기록입니다. 특정 누군가를 비판하려는 이야기가 아니라, 「AI 시대에 "행수"를 어떻게 받아들여야 할까」라는, 많은 사람이 한 번쯤은 품어봤을 법한 의문에 대한 저 나름의 답변입니다.

저는 수의사이며, 본업이 소프트웨어 엔지니어는 아닙니다. 다만, AI를 사용하여 자신의 업무용 도구를 개인 개발하는 과정에서 이 의문에 부딪혔습니다. 전문 지식이 없어도 읽을 수 있도록 작성하겠습니다.

LOC (Lines of Code)는 단순하게 말하면 「코드의 행수」입니다.

예전부터 소프트웨어 개발 세계에서는 「이 프로젝트는 몇 행인가」로 대략적인 규모감을 파악하는 습관이 있다고 합니다. 1,000행보다는 10,000행이 대체로 더 크고 복잡하다는 이미지. 행수로부터 역산하여 개발 비용이나 납기를 견적 내는 재료로도 오랫동안 사용되어 왔습니다.

다만 「LOC로 규모를 측정한다」는 방식에는 예전부터 약점이 있었습니다. 프로그래밍 언어에 따라 같은 기능이라도 쓸 수 있는 행수가 완전히 다르기 때문입니다. 같은 처리라도 언어 A로는 100행, 언어 B로는 20행으로 쓸 수 있습니다.

따라서 「행수만으로 규모를 비교하는 것은 무리가 있다」는 문제의식 자체는 사실 AI가 등장하기 훨씬 전인 1970년대부터 이미 존재했던 것이기도 합니다. LOC는 원래 「만능 자」가 아니었던 셈입니다. 그럼에도 대략적인 기준으로는 오랫동안 계속 사용되어 왔습니다.

여기서부터가 본론입니다.

Claude Code나 Cursor와 같은 AI 코딩 툴을 사용하면 다음과 같은 일이 일어납니다.

• AI가 한 번에 파일 전체를 다시 쓴다 (사람처럼 한 줄씩 추가하는 것이 아니라, 파일을 통째로 재생성하는 경우가 있다)
• 잘 되지 않으면 다시 다시 쓴다
• 그것을 몇 번이고 반복하면서 조금씩 완성에 다가간다

즉, 최종적으로 완성된 코드와 그 과정에서 AI가 실제로 생성한 행의 총량은 전혀 다른 숫자가 됩니다.

앞서 말한 「10만 행」으로 돌아가 보겠습니다. 만약 이것이 「AI가 대화 속에서 생성한 행수의 누적」이라면, 그것은 「완성된 앱의 규모」와 동일하지 않을 수도 있습니다.

조사해 보니, 「LOC」라고 한데 묶어 말해도 사실 몇 가지 종류가 있다는 것을 알게 되었습니다 (※ 아래의 명칭은 업계에서 완전히 표준화된 용어는 아니며, 이 기사에서는 편의상 이렇게 부르고 있습니다).

명칭	무엇을 세고 있는가
Final LOC (최종 행수)	현재 실제로 리포지토리에 있는 파일의 행수. 이른바 「완성품의 크기」
Generated LOC (AI 생성 누적 행수)	AI가 대화 속에서 생성한 행의 합계. 다시 쓴 부분·지운 부분도 포함될 가능성이 있음
Diff LOC (차분 행수)	Git 이력에 남는 「추가한 행·지운 행」의 축적
Token (토큰량)	AI와의 상호작용에서 소비한 양. 과금 금액과 직결됨

Final LOC가 10만 행이라면 비교적 대규모 성과물이라고 할 수 있는 경우가 많을 것입니다. 하지만 Generated LOC가 10만 행이라면, 그것은 「AI와의 시행착오가 그만큼 많았다」는 것일 뿐, 완성품의 크기와는 별개의 이야기가 됩니다.

이 말은 듣고 보니 당연한 것인데, 뉴스나 SNS에서 「◯만 행을 썼다」라는 숫자를 보았을 때, 저는 지금까지 무의식적으로 전자로 생각하며 받아들여 왔던 것 같습니다.

말로 설명해도 와닿지 않을 것 같아, 제가 개발하고 있는 수의료용 약용량 계산 툴 (VetCalc PRO)로 실제로 측정해 보았습니다.

먼저, 현재 실제로 사용 중인 파일의 행수 (Final LOC에 해당하는 것).

find . -name "*.html" -o -name "*.py" -o -name "*.json" | xargs wc -l

결과: 3,611행

다음으로, 지금까지 저장해 온 개발 중인 버전 파일(프로토타입, 폐기안, 백업 등등)을 전부 집계해 보았습니다.

find . -type f \( -name "*.html" -o -name "*.json" \) -print0 | xargs -0 wc -l

결과: 약 266만 행 (중복 파일 포함)

나아가, 내용이 완전히 동일한 파일을 중복 제거해 보면:

최종적으로 사용 중인 코드 (Final LOC): 3,611행 -
지금까지의 시행착오 총량 (Generated LOC에 가까운 것): 약 190만 행

같은 프로젝트를 가리키고 있음에도, 어떻게 잘라내느냐에 따라 '3,611'이 되기도 하고 '190만'이 되기도 한다. 처음에 이 숫자를 봤을 때, "아니, 190만이라니 대체 뭐야"라며 혼자서 황당해했습니다. wc -l이 고장 난 게 아닌가 진심으로 의심했을 정도입니다.

이유는 단순합니다. Final과 Generated는 애초에 서로 다른 것을 세고 있기 때문입니다.

AI와의 대화는 대략 이런 식으로 진행됩니다.

생성 → 수정 → 생성 → 삭제 → 생성 → 수정 → … (수십 번, 수백 번 반복)
↓
최종적으로 남은 것만이
...

시행착오 과정에서 생겨났다 사라진 부분까지 전부 '생성된 행(Generated LOC)'으로 카운트한다면, 당연히 최종 결과물보다 압도적으로 큰 숫자가 됩니다. 477개의 버전 파일을 다시 살펴보니, 주사제 계산 앱만 해도 v0부터 v51까지, CRI 계산기도 v0.1부터 v0.7까지, 꾸준히 쌓아온 기록이 남아 있었습니다. 전부 더했더니 190만 행이었다는 것뿐입니다.

내 숫자라서 신뢰할 수 있고, 남의 숫자라서 의심스럽다는 뜻은 아닙니다. "무엇을 어떻게 측정했는가"를 확인하지 않는 한, 어떤 숫자도 맹신할 수 없다. 그것이 이번에 가장 절실히 느낀 점이었습니다.

• 단 한 글자만 다른 저장 버전 (v20_1, v20_2와 같은 연번 파일)은 각각 별개의 파일로 카운트되어 버림
• 개발과 직접적인 관계가 없는 파일도 일부 섞여 있었음

내가 내놓은 190만 행이라는 숫자도 사실 완벽한 지표는 아닙니다.

"◯만 행"이라는 숫자만으로는 아무것도 알 수 없습니다.

우선, 무엇을 센 숫자 인가. 그것을 보지 않으면 비교할 방법이 없습니다.

이번에 가장 공부가 된 부분은 바로 그 점이었습니다.

AI 코딩에서는 코드를 쓰는 속도가 확실히 크게 변했습니다. 하지만 이번에 조사하며 느낀 것은, "LOC"라는 단어 그 자체도 이전과는 조금 의미가 변하기 시작한 것이 아닌가 하는 점이었습니다.

"◯만 행"이라는 말을 들으면, 그전에 딱 하나만 확인하고 싶습니다. 그 숫자는 무엇을 센 LOC인가요?

앞으로는 저도 "◯만 행"이라는 숫자만으로는 판단하지 않으려 합니다.

※ 이 기사는 공개된 정보와 본인의 검증 결과를 바탕으로, LOC라는 지표의 해석에 대해 정리하고 있습니다. Claude Code 등 각 도구의 "누적 행수" 내부 구현이나 산출 방식에 대해서는 공개되지 않은 부분도 있어 일부 추측을 포함하고 있습니다. 오류나 더 정확한 정보가 있다면 꼭 댓글로 알려주세요.