소스 라인 오브 코드

**소스 라인 오브 코드**(Source lines of code, **SLOC**), 또는 **라인 오브 코드**(lines of code, **LOC**)는 프로그램 소스 코드 텍스트의 줄 수를 세어 컴퓨터 프로그램의 크기를 측정하는 데 사용되는 소프트웨어 메트릭이다. SLOC는 일반적으로 프로그램을 개발하는 데 필요한 노력의 양을 예측하고 소프트웨어가 생산된 후 프로그래밍 생산성 또는 유지보수성을 추정하는 데 사용된다.

## 측정 방법
여러 유용한 비교는 프로젝트 내 코드 라인의 크기 정도만을 포함한다. 10,000줄 프로젝트와 100,000줄 프로젝트를 비교하는 데 코드 라인을 사용하는 것이 20,000줄 프로젝트와 21,000줄 프로젝트를 비교하는 것보다 훨씬 유용하다. 코드 라인을 정확히 어떻게 측정할 것인지는 논란의 여지가 있지만, 크기 정도의 차이는 소프트웨어 복잡성 또는 공수의 명확한 지표가 될 수 있다.

SLOC 측정에는 물리적 SLOC (LOC)와 논리적 SLOC (LLOC)의 두 가지 주요 유형이 있다. 이 두 가지 측정의 구체적인 정의는 다르지만, 물리적 SLOC의 가장 일반적인 정의는 주석 줄을 제외한 프로그램 소스 코드 텍스트의 줄 수이다.

논리적 SLOC는 실행 가능한 "명령문"의 수를 측정하려고 시도하지만, 그 특정 정의는 특정 컴퓨터 언어에 묶여 있다(예를 들어, C와 유사한 프로그래밍 언어의 간단한 논리적 SLOC 측정은 명령문을 종료하는 세미콜론의 수이다). 물리적 SLOC를 측정하는 도구를 만드는 것이 훨씬 쉽고, 물리적 SLOC 정의는 설명하기 쉽다. 그러나 물리적 SLOC 측정은 논리적 SLOC보다 논리적으로 관련 없는 형식 지정 및 스타일 규칙에 더 민감하다. 그러나 SLOC 측정은 종종 정의를 제공하지 않고 언급되며, 논리적 SLOC는 물리적 SLOC와 크게 다를 수 있다.

SLOC를 결정할 때 발생하는 모호성의 예시로 다음 C 코드 스니펫을 고려해보자.

```c
for (i = 0; i < 100; i++) printf("hello"); /* How many lines of code is this? */
```


이 예시에서는 다음과 같다.
* 1개의 물리적 코드 라인 (LOC)
* 2개의 논리적 코드 라인 (LLOC) (for 문과 Printf 문)
* 1개의 주석 라인

프로그래머와 코딩 표준에 따라 위의 "코드 라인"은 여러 개의 개별 라인으로 작성될 수 있다.

```c
/* Now how many lines of code is this? */
for (i = 0; i < 100; i++)
{
    printf("hello");
}
```


이 예시에서는 다음과 같다.
* 4개의 물리적 코드 라인 (LOC): 중괄호를 배치하는 작업도 추정해야 하는가?
* 2개의 논리적 코드 라인 (LLOC): 명령문이 아닌 라인을 작성하는 모든 작업은 어떻게 되는가?
* 1개의 주석 라인: 도구는 주석 배치에 관계없이 모든 코드와 주석을 고려해야 한다.

심지어 "논리적" 및 "물리적" SLOC 값도 수많은 다양한 정의를 가질 수 있다. 로버트 E. 파크 (소프트웨어 공학 연구소 소속)와 다른 사람들은 프로젝트에서 사용되는 SLOC 측정을 신중하게 설명하고 정의할 수 있도록 SLOC 값을 정의하기 위한 프레임워크를 개발했다. 예를 들어, 대부분의 소프트웨어 시스템은 코드를 재사용하며, 측정을 보고할 때 어떤 (있다면) 재사용 코드를 포함할지 결정하는 것이 중요하다.

## 기원
SLOC가 메트릭으로 도입될 당시, 포트란 및 어셈블리어와 같이 가장 일반적으로 사용되던 언어들은 라인 지향 언어였다. 이 언어들은 천공 카드가 프로그래밍을 위한 주요 데이터 입력 형태였던 시절에 개발되었다. 천공 카드 하나는 일반적으로 코드 한 줄을 나타냈다. 그것은 쉽게 셀 수 있는 개별적인 개체였다. 그것은 프로그래머의 가시적인 결과물이었기 때문에, 관리자들은 코드 줄을 프로그래머의 생산성 측정으로 세는 것이 합리적이라고 생각했으며, 심지어 "카드 이미지"라고 부르기도 했다. 오늘날, 가장 일반적으로 사용되는 컴퓨터 언어들은 형식 지정에 훨씬 더 많은 자유를 허용한다. 텍스트 줄은 더 이상 80 또는 96열로 제한되지 않으며, 텍스트 한 줄이 더 이상 반드시 코드 한 줄에 해당하지는 않는다.

## SLOC 측정의 사용
SLOC 측정은 다소 논란의 여지가 있으며, 특히 오용되는 방식에서 그렇다. 실험에 따르면 노력은 SLOC와 높은 상관관계가 있으며, 즉 SLOC 값이 큰 프로그램은 개발하는 데 더 많은 시간이 걸린다는 것이 반복적으로 확인되었다. 따라서 SLOC는 노력을 추정하는 데 효과적일 수 있다. 그러나 기능은 SLOC와 상관관계가 적다: 숙련된 개발자는 훨씬 적은 코드로 동일한 기능을 개발할 수 있으므로, SLOC가 적은 프로그램이 다른 유사한 프로그램보다 더 많은 기능을 나타낼 수 있다. SLOC를 생산성 측정으로 세는 것은 주의할 점이 있는데, 개발자는 몇 줄만 개발하고도 더 많은 줄을 생성하는 개발자보다 기능 측면에서 훨씬 더 생산적일 수 있기 때문이다(그리고 일반적으로 더 많은 노력을 들인다). 우수한 개발자는 여러 코드 모듈을 단일 모듈로 병합하여 시스템을 개선하지만, 코드를 제거했기 때문에 생산성이 음수로 나타날 수 있다. 또한, 미숙한 개발자는 종종 코드 중복에 의존하는데, 이는 버그 발생 가능성이 높고 유지 보수 비용이 많이 들기 때문에 매우 권장되지 않지만, SLOC를 높이는 결과를 초래한다.

SLOC 계산은 언어를 정규화하기 위해 조정 계수를 적용하지 않는 한, 다른 언어로 작성된 프로그램을 비교할 때 추가적인 정확성 문제를 나타낸다. 다양한 컴퓨터 언어는 간결성과 명확성 사이의 균형을 다르게 맞춘다. 극단적인 예로, 대부분의 어셈블리어는 APL에서 몇 글자로 동일한 작업을 수행하기 위해 수백 줄의 코드를 필요로 할 것이다. 다음 예시는 베이직, C, 그리고 (특히 장황한 것으로 알려진 언어인) 코볼로 작성된 "Hello world" 프로그램의 비교를 보여준다.

SLOC 메트릭을 비교하는 데 있어 또 다른 점점 흔해지는 문제는 자동 생성된 코드와 수작업으로 작성된 코드의 차이이다. 최신 소프트웨어 도구는 종종 몇 번의 마우스 클릭으로 엄청난 양의 코드를 자동 생성할 수 있다. 예를 들어, 그래픽 사용자 인터페이스 빌더는 아이콘을 작업 공간으로 드래그하는 것만으로 그래픽 제어 요소의 모든 소스 코드를 자동으로 생성한다. 이 코드를 생성하는 데 필요한 작업은 예를 들어 장치 드라이버를 작성하는 데 필요한 작업과 합리적으로 비교할 수 없다. 같은 맥락에서, 수작업으로 코딩된 사용자 지정 GUI 클래스는 간단한 장치 드라이버보다 훨씬 더 까다로울 수 있다. 따라서 이 메트릭의 단점이 드러난다.

널리 사용되는 배리 보임 등의 COCOMO 모델 시리즈, PRICE Systems True S 및 갈로라쓰의 SEER-SEM을 포함하여 SLOC를 입력 매개변수로 사용하는 여러 비용, 일정 및 노력 추정 모델이 있다. 이 모델들은 우수한 예측력을 보여주었지만, 입력된 추정치(특히 SLOC 추정치)만큼만 좋다. 많은 이들은 기능성 측정으로 SLOC 대신 기능 점수 사용을 주장했지만, 기능 점수가 SLOC와 높은 상관관계가 있고 (자동으로 측정될 수 없기 때문에) 이는 보편적으로 받아들여지는 견해가 아니다.

### 예시
빈센트 마라이아(Vincent Maraia)에 따르면, 마이크로소프트의 윈도우 NT 제품군의 다양한 운영 체제의 SLOC 값은 다음과 같다.

데이비드 A. 휠러(David A. Wheeler)는 리눅스 운영체제의 레드햇 배포판을 연구했으며, 레드햇 리눅스 버전 7.1 (2001년 4월 출시)이 3천만 줄 이상의 물리적 SLOC를 포함하고 있다고 보고했다. 그는 또한 이 배포판이 기존의 독점적인 방식으로 개발되었다면 약 8천 인년의 개발 노력이 필요했을 것이며 10억 달러 이상(2000년 미국 달러 기준)의 비용이 들었을 것이라고 추정했다.

유사한 연구가 나중에 데비안 GNU/리눅스 버전 2.2("포테이토"라고도 함)에 대해 수행되었다. 이 운영 체제는 2000년 8월에 원래 출시되었다. 이 연구는 데비안 GNU/리눅스 2.2가 5천5백만 줄 이상의 SLOC를 포함하고 있으며, 기존의 독점적인 방식으로 개발되었다면 14,005 인년이 필요하고 개발 비용으로 미화 19억 달러가 들었을 것이라고 밝혔다. 나중에 사용된 도구의 실행 결과에 따르면 데비안의 다음 릴리스는 1억 4백만 SLOC를 가졌고, , 최신 릴리스는 2억 1천 3백만 SLOC 이상을 포함할 예정이다.

## 유용성
### 장점
# 계산 자동화의 범위: 코드 라인은 물리적 개체이므로, 계산 프로세스를 자동화하여 수동 계산 노력을 쉽게 제거할 수 있다. 프로그램의 LOC를 계산하기 위한 작은 유틸리티가 개발될 수 있다. 그러나 특정 언어를 위해 개발된 논리적 코드 계산 유틸리티는 언어 간의 구문 및 구조적 차이 때문에 다른 언어에는 사용될 수 없다. 그러나 수십 가지 언어를 계산하는 물리적 LOC 카운터가 개발되었다.
# 직관적인 측정 항목: 코드 라인은 시각적으로 볼 수 있고 그 효과를 시각화할 수 있기 때문에 소프트웨어 크기를 측정하는 직관적인 측정 항목으로 사용된다. 기능 점수는 물리적 개체로 상상할 수 없는 더 객관적인 측정 항목으로 알려져 있으며, 논리적 공간에만 존재한다. 이런 식으로 LOC는 경험이 적은 프로그래머들 사이에서 소프트웨어 크기를 표현하는 데 유용하다.
# 보편적인 측정: LOC 측정은 소프트웨어 초기부터 존재해 왔다. 따라서 다른 어떤 크기 측정보다 더 많은 LOC 데이터를 사용할 수 있다고 주장할 수 있다.

### 단점
# 책임 부족: 코드 라인 측정은 몇 가지 근본적인 문제점을 안고 있다. 일부는  코딩 단계의 결과만을 사용하여 프로젝트의 생산성을 측정하는 것은 유용하지 않다고 생각하는데, 코딩 단계는 일반적으로 전체 노력의 30%에서 35%만을 차지한다.
# 기능과의 응집성 부족: 비록 실험을 통해 노력이 LOC와 높은 상관관계가 있지만, 기능은 LOC와 덜 상관관계가 있다는 것이 반복적으로 확인되었다. 즉, 숙련된 개발자는 훨씬 적은 코드로 동일한 기능을 개발할 수 있으므로, LOC가 적은 프로그램이 다른 유사한 프로그램보다 더 많은 기능을 나타낼 수 있다. 특히 LOC는 개인의 생산성 측정에 좋지 않은데, 몇 줄만 개발하는 개발자도 더 많은 코드 라인을 생성하는 개발자보다 생산성이 더 높을 수 있기 때문이다. 심지어 "메서드 추출"과 같은 좋은 리팩토링은 중복 코드를 제거하고 깨끗하게 유지하여 코드 라인 수를 줄이는 경우가 대부분이다.
# 추정에 대한 부정적인 영향: 1번에서 제시된 사실 때문에, 코드 라인을 기반으로 한 추정은 모든 가능성에서 부정적으로 잘못될 수 있다.
# 개발자의 경험: 특정 로직의 구현은 개발자의 경험 수준에 따라 달라진다. 따라서 코드 라인 수는 사람마다 다르다. 숙련된 개발자는 같은 언어를 사용하더라도 상대적으로 경험이 적은 다른 개발자보다 더 적은 코드 라인으로 특정 기능을 구현할 수 있다.
# 언어의 차이: 동일한 기능(화면, 보고서, 데이터베이스)을 제공하는 두 가지 애플리케이션을 고려해 보자. 한 애플리케이션은 C++로 작성되었고 다른 애플리케이션은 코볼과 같은 언어로 작성되었다. 기능 점수 수는 정확히 동일하겠지만, 애플리케이션의 측면은 다를 것이다. 애플리케이션을 개발하는 데 필요한 코드 라인 수는 분명히 같지 않을 것이다. 결과적으로 애플리케이션을 개발하는 데 필요한 노력의 양도 달라질 것이다(기능 점수당 시간). 코드 라인과 달리 기능 점수 수는 일정하게 유지될 것이다.
# GUI 도구의 등장: 비주얼 베이직과 같은 GUI 기반 프로그래밍 언어 및 도구의 등장으로 프로그래머는 상대적으로 적은 코드를 작성하고 높은 수준의 기능을 달성할 수 있다. 예를 들어, 창을 만들고 버튼을 그리는 프로그램을 작성하는 대신, GUI 도구를 사용하는 사용자는 드래그 앤 드롭 및 기타 마우스 작업을 사용하여 작업 공간에 구성 요소를 배치할 수 있다. GUI 도구에 의해 자동으로 생성되는 코드는 LOC 측정 방법을 사용할 때 일반적으로 고려되지 않는다. 이로 인해 언어 간에 차이가 발생한다. 한 언어에서는 한 줄의 코드(또는 전혀 코드 없이)로 수행할 수 있는 동일한 작업이 다른 언어에서는 여러 줄의 코드를 필요로 할 수 있다.
# 여러 언어의 문제점: 오늘날의 소프트웨어 환경에서는 소프트웨어가 종종 하나 이상의 언어로 개발된다. 복잡성과 요구 사항에 따라 여러 언어가 사용되는 경우가 많다. 이 경우 생산성 및 결함률 추적 및 보고에 심각한 문제가 발생하는데, 시스템 통합 후 결함을 특정 언어에 귀속시킬 수 없기 때문이다. 이 경우 기능 점수는 크기를 측정하는 가장 좋은 방법으로 두드러진다.
# 계산 표준의 부족: 코드 라인이 무엇인지에 대한 표준 정의가 없다. 주석도 세어야 하는가? 데이터 선언은 포함되는가? 명령문이 여러 줄에 걸쳐 확장되면 어떻게 되는가? – 이것들은 종종 발생하는 질문들이다. 비록 SEI 및 IEEE와 같은 조직들이 계산을 표준화하기 위한 일부 지침을 발표했지만, 특히 매년 새로운 언어가 도입되는 상황에서 이를 실제로 적용하기는 어렵다.
# 심리: 코드 라인으로 생산성을 측정받는 프로그래머는 불필요하게 장황한 코드를 작성하려는 동기를 가질 것이다. 경영진이 코드 라인에 더 집중할수록 프로그래머는 불필요한 복잡성으로 코드를 확장하려는 동기를 더 많이 갖게 된다. 이는 바람직하지 않은데, 복잡성 증가는 유지 보수 비용 증가 및 버그 수정에 필요한 노력 증가로 이어질 수 있기 때문이다.

PBS 다큐멘터리 너드들의 승리에서 마이크로소프트의 임원인 스티브 발머는 코드 라인 수를 세는 관행을 비판했다.

IBM에는 소프트웨어에 대한 종교가 있는데, K-LOC를 세야 한다고 말한다. K-LOC는 천 줄의 코드다. 프로젝트 규모는? 아, 대략 10K-LOC 프로젝트야. 이건 20K-LOC짜리야. 이건 50K-LOC짜리야. IBM은 우리가 어떻게 돈을 벌었는지, 그들이 얼마나 했는지에 대한 종교를 만들고 싶어 했다. 우리가 OS/2로 얼마나 많은 돈을 벌었는지, 그들이 얼마나 했는지. K-LOC를 몇 개 만들었냐고? 우리는 계속해서 그들을 설득하려고 했다. "이봐, 만약 개발자가 좋은 아이디어를 가지고 20K-LOC 대신 4K-LOC로 뭔가를 해낼 수 있다면, 우리가 돈을 덜 벌어야 할까?" 그는 더 작고 빠른 것을 만들었는데, K-LOC는 더 적었다. K-LOC, K-LOC, 그게 방법론이다. 에휴! 어쨌든, 그 생각만 하면 항상 등골이 오싹해진다.

컴퓨터 역사 박물관에 따르면 애플 개발자 빌 앳킨슨은 1982년에 이 관행에 문제점을 발견했다.

1982년 Lisa 팀이 소프트웨어를 완성하기 위해 노력하고 있을 때, 프로젝트 관리자들은 프로그래머들에게 매주 작성한 코드 라인 수를 보고하는 양식을 제출하도록 요구하기 시작했다. 빌 앳킨슨은 그것이 어리석다고 생각했다. QuickDraw의 영역 계산 루틴을 6배 더 빠르게 만들고 2000줄 더 짧게 만든 주에 그는 양식에 "-2000"이라고 기입했다. 몇 주 후에 관리자들은 그에게 양식을 작성하라고 요구하지 않았고, 그는 기꺼이 따랐다.


## 같이 보기
* 소프트웨어 개발 노력 추정
* 추정 (프로젝트 관리)
* 소프트웨어 공학의 비용 추정

## 내용주


## 각주

## 추가 자료
* 
* 
* 

## 외부 링크
* 실용적인 소스 코드 라인의 정의 Resource Standard Metrics (RSM)는 "유효 코드 라인"을 프로그래밍 스타일에 관계없는 현실적인 코드 메트릭으로 정의한다.
* 인기 오픈 소스 소프트웨어에 대한 유효 코드 라인 eLOC 메트릭 RSM을 사용하는 리눅스 커널 2.6.17, 파이어폭스, 아파치 HTTPD, MySQL, PHP.
* 
* 
* Tanenbaum, Andrew S. Modern Operating Systems (2nd ed.). Prentice Hall. .
* 
* 
* Folklore.org: 매킨토시 이야기: -2000 코드 라인

분류:소프트웨어 메트릭