LOC로 읽는 소프트웨어 규모와 생산성 지표

라인 수가 프로젝트 판단의 출발점이 되는 이유

LOC(Line Of Code)는 소스코드의 물리적 라인 수를 세어 소프트웨어 규모를 표현하는 지표다. 단순한 숫자지만 개발 노력과 비용을 추정하고, 진행 상황을 점검하며, 리소스를 배분하는 데 필요한 기초 데이터를 제공한다.

규모를 정량화할 수 있다는 점 때문에 LOC는 개발자 생산성, 코드 품질, 복잡도 분석의 출발점으로도 쓰인다. 다만 줄 수 자체가 가치나 품질을 뜻하지는 않으므로, 무엇을 포함해 어떤 기준으로 셌는지를 먼저 맞춰야 한다.

무엇을 한 줄로 셀 것인가

LOC는 집계 기준에 따라 서로 다른 값을 낸다.

물리적 LOC(Physical LOC)는 소스 파일에 존재하는 모든 라인을 센다. 공백, 주석, 코드가 모두 포함되므로 측정은 가장 쉽지만 작성 스타일에 크게 좌우된다.

논리적 LOC(Logical LOC)는 실행 가능한 명령문을 기준으로 계산한다. 세미콜론(;)이나 명령 종결점을 기준으로 삼으며, 스타일 영향은 줄어든다. SLOC(Source Lines Of Code)라는 이름으로도 사용된다.

주석 제외 LOC는 소스코드에서 주석을 뺀 라인 수다. 기능 구현에 집중해 규모를 보려 할 때 쓰이며, 코드와 주석의 비율을 분석하는 데도 활용할 수 있다.

KLOC와 MLOC로 규모를 표현하는 방식

프로젝트가 커지면 단순 LOC 대신 더 큰 단위를 사용한다.

- LOC: 기본 단위, 라인 수 그대로 표현
- KLOC: 천 라인 단위 (Kilo Lines Of Code)
- MLOC: 백만 라인 단위 (Million Lines Of Code)

대형 시스템은 MLOC로 나타내는 경우가 많다. Windows 10은 약 50 MLOC, Linux 커널은 약 27.8 MLOC 규모로 알려져 있다.

자동 집계와 수동 검증을 조합하는 방법

LOC는 SonarQube, CLOC, CodeCounter 같은 도구로 집계할 수 있다. 대규모 프로젝트에서는 반복 가능한 기준을 적용할 수 있어 자동화가 필수적인 접근이 된다.

작은 프로젝트나 특정 모듈처럼 별도 기준이 필요한 경우에는 수동 측정도 쓸 수 있다. 다만 시간이 많이 들고 오류 가능성도 높다. 실무에서는 자동화 도구로 먼저 측정한 뒤 수동으로 검증하는 하이브리드 방식이 정확도와 효율성의 균형점이 될 수 있다.

같은 기능도 언어와 스타일에 따라 줄 수가 달라진다

언어의 표현력부터 LOC 값에 영향을 준다.

⤢✕

같은 기능이라도 C언어에서는 100 LOC가 필요하고 Python에서는 20 LOC로 구현될 수 있다. 따라서 언어가 다른 팀이나 프로젝트의 LOC를 직접 비교하는 데는 한계가 있다.

코딩 스타일도 결과를 바꾼다.

// 스타일 A: 한 줄에 여러 명령문
int x = 5; int y = 10; int z = x + y;

// 스타일 B: 한 줄에 하나의 명령문
int x = 5;
int y = 10;
int z = x + y;

스타일 A는 1 LOC, 스타일 B는 3 LOC로 측정되지만 기능은 같다. 비교와 추세 관찰에 LOC를 사용하려면 조직이나 프로젝트 안에서 일관된 측정 기준을 유지해야 한다.

IDE와 코드 생성기가 만든 코드 역시 측정 목적에 따라 포함 여부가 달라진다. 자동 생성 코드를 넣을지 빼는지에 따라 개발 노력이나 실제 구현 규모에 대한 해석이 달라질 수 있다.

생산성 계산에 LOC를 쓸 때 남는 공백

LOC는 개발자나 팀의 생산성을 계산하는 데 사용할 수 있다.

생산성 = 총 LOC / 투입 시간(또는 인원)

5,000 LOC를 개발하는 데 100인/시간이 들었다면 생산성은 50 LOC/인/시간이다.

하지만 이 값만으로 생산성을 판단하기는 어렵다. 코드 품질을 반영하지 못하고, 문제 복잡도와 언어 차이도 담지 못한다. 재사용한 코드를 어떻게 처리할지도 별도 기준이 필요하다. 줄 수가 많은 사람이 더 생산적이라는 해석은 불필요한 코드 작성을 유도할 수 있다.

규모 추정과 품질 관리에서의 활용

대형 IT 기업 A사는 새로운 금융 시스템을 개발하면서 유사 프로젝트의 LOC 데이터를 분석했다. 핵심 기능별 평균 LOC를 구한 뒤 개발 예정 기능에 적용해 약 150K LOC로 규모를 추정했고, 이를 인력·일정·비용 계획의 기반으로 삼았다.

보안 소프트웨어 개발사 B사는 LOC당 결함 수(Defects per KLOC)를 핵심 품질 지표로 사용한다. 산업 평균인 15개 결함/KLOC와 비교해 자사 제품은 5개 결함/KLOC을 유지하며 품질 우위를 확보했다.

C사는 레거시 시스템 현대화 과정에서 리팩토링 전후의 LOC 변화를 측정했다. 초기 42K LOC는 리팩토링 후 28K LOC가 되어 33% 감소했고, 이 수치를 코드 가독성과 유지보수성 향상을 보여주는 객관적 지표로 활용했다.

LOC만으로 보이지 않는 영역을 보완하는 지표

LOC는 측정하기 쉽고 직관적이며, 축적된 산업·도메인별 데이터를 활용할 수 있다. COCOMO 같은 전통적 추정 모델의 입력값으로도 쓰여 초기 비용과 일정 계획을 지원한다.

반면 코드 품질과 알고리즘의 효율성을 직접 반영하지 못하고, 언어마다 표현력이 달라 비교가 어렵다. 그래서 규모, 복잡도, 품질을 보는 지표를 함께 둔다.

⤢✕

기능점수(Function Point)는 사용자 관점의 기능 단위로 규모를 측정하므로 언어에 독립적이지만 계산 과정이 복잡하다. 사이클로매틱 복잡도(Cyclomatic Complexity)는 제어 흐름의 복잡도를 측정해 테스트 케이스 수를 추정하는 데 쓰이며, LOC와 함께 보면 품질 지표로 활용할 수 있다.

객체지향 설계에서는 CK 메트릭 스위트 같은 지표로 클래스 간 결합도와 응집도를 측정한다. 프로젝트 특성과 목적에 맞춰 이러한 지표를 조합해야 LOC가 제공하는 규모 정보가 실제 의사결정에 연결된다.