LOC 산정 (LOC) · Lines of Code

“소스 코드 라인 수 기반 규모 산정. 단순하지만 언어 의존적.”

LOC 산정이란 무엇인가

LOC(Lines of Code) 산정은 소프트웨어의 규모를 작성된 소스 코드의 라인 수로 추정하는 방법이다. 만들어야 할 코드의 분량을 먼저 가늠하고, 이를 근거로 개발에 필요한 노력과 기간, 비용을 역산하는 방식으로 활용된다.

규모를 코드 줄 수라는 직관적이고 세기 쉬운 단위로 환원한다는 점에서 가장 오래되고 단순한 산정 기법으로 꼽힌다. 과거 실적에서 라인당 평균 생산성을 알고 있다면, 예상 라인 수만으로 곧바로 공수를 추정할 수 있다는 점이 이 방법의 가장 큰 매력이다.

측정과 계산이 명료해 누구나 이해하기 쉽다는 점도 오래 쓰여 온 이유다.

LOC 기반 산정 흐름

LOC의 강점은 계산 논리가 투명하고 적용이 간편하다는 데 있다. 비슷한 성격의 프로젝트를 반복적으로 수행하는 조직이라면, 과거에 작성한 코드량과 실제 투입 공수의 관계가 데이터로 쌓이면서 추정 정확도가 점차 올라간다.

동일한 언어와 동일한 개발 방식을 유지하는 환경에서는 라인 수와 노력 사이의 비례 관계가 비교적 안정적으로 유지되기 때문이다. 또한 개발이 끝난 뒤에는 실제 라인 수를 그대로 집계할 수 있어 사후 생산성 분석과 다음 산정의 보정 자료로 삼기 쉽다.

입력이 명확하고 결과 검증이 쉽다는 점에서 내부 관리 지표로서의 실용성은 여전히 남아 있다.

LOC 산정의 가장 근본적인 한계는 라인 수가 사용하는 언어와 작성 방식에 크게 좌우된다는 데 있다. 같은 기능을 구현해도 저수준 언어로는 길어지고 표현력이 높은 언어로는 짧아지므로, 라인 수만으로는 서로 다른 환경의 규모를 공정하게 비교하기 어렵다.

또한 라인을 어떻게 세느냐, 즉 주석과 공백을 포함할지, 논리적 문장을 단위로 볼지 물리적 줄을 단위로 볼지에 따라 같은 코드도 수치가 달라진다. 짧고 효율적인 코드가 오히려 작은 규모로 집계되어 좋은 설계가 과소평가되는 역설도 발생한다.

이런 특성 탓에 LOC는 조직과 언어가 통제된 좁은 범위 안에서만 비교 근거로 의미를 가진다.

LOC 산정의 강점과 한계

LOC가 결과물의 분량을 측정하는 데 비해, 기능점수는 사용자가 누리는 기능의 양을 측정한다는 점에서 두 기법은 출발점이 다르다. 코드가 한 줄도 없는 기획 초기에 규모를 가늠해야 할 때, 아직 존재하지 않는 라인 수를 추정하는 것은 본질적으로 불확실하다.

그래서 발주·계약처럼 객관성이 요구되는 국면에서는 구현 방식에 흔들리지 않는 기능점수가 선호된다. 반면 LOC는 개발 방식이 고정된 조직 내부에서 생산성을 추적하거나 신속한 개략 추정을 할 때 여전히 유용하다.

두 기법은 우열의 관계라기보다 적용 국면이 다른 상호 보완적 도구로 이해하는 편이 정확하다.

LOC는 단독 산정 도구를 넘어 비용 추정 모형의 입력값으로도 널리 쓰여 왔다. 대표적으로 COCOMO 계열의 모형은 예상 코드 규모를 받아 프로젝트의 노력과 기간을 산출하는데, 이때 규모 입력으로 LOC가 활용된다.

규모가 같아도 프로젝트의 난이도와 팀의 숙련도, 제약 조건에 따라 실제 공수는 달라지므로, 모형은 라인 수에 여러 보정 계수를 곱해 추정을 정교화한다. 즉 LOC는 추정의 출발점일 뿐이며, 그 위에 환경 요인을 반영해야 현실적인 수치가 나온다.

라인 수라는 단일 입력을 맹신하기보다, 그것을 보정하는 계수의 타당성에 더 주의를 기울여야 한다.

LOC를 산정에 쓸 때 가장 위험한 것은 라인 수를 생산성이나 성과의 지표로 오용하는 일이다. 더 많은 코드를 작성한 쪽이 더 많은 일을 했다고 보는 순간, 불필요하게 장황한 코드가 보상받고 간결한 설계가 손해를 보는 왜곡이 생긴다.

따라서 LOC는 규모를 가늠하는 내부 추정 도구로 한정하고, 개인이나 팀의 평가 잣대로 전용하지 않는 것이 원칙이다. 또한 라인을 세는 규칙을 사전에 통일하고, 과거 실적과 동일한 언어·환경에서만 비교해야 추정이 흔들리지 않는다.

단순함을 활용하되 그 단순함이 감추는 전제들을 분명히 인식하는 것이 LOC를 제대로 쓰는 길이다.