코드 라인 수(LOC)는 생산성 지표가 될 수 있을까?
1982년, 애플 리사(Apple Lisa) 개발팀은 코드 라인 수(Lines of Code, LOC)를 엔지니어 생산성 지표로 활용하려 함
퀵드로우(Quickdraw) 개발자 빌 앳킨슨(Bill Atkinson)은 코드 최적화(Code Optimization)를 통해 2,000 라인 감소를 달성
앳킨슨은 LOC가 무의미한 지표(Meaningless Metric)임을 강조하며, 오히려 코드 품질 저하(Code Quality Degradation)를 유발한다고 비판
커뮤니티에서는 생산성 지표의 적절성(Appropriateness of Productivity Metrics)에 대한 다양한 의견이 제시됨
LOC(Lines of Code) 지표의 한계
본문은 1982년 당시, 애플 리사(Apple Lisa) 개발팀이 엔지니어의 생산성을 측정하기 위해 LOC(Lines of Code)를 활용하려 했던 시도를 보여준다. 하지만 퀵드로우(Quickdraw) 개발자 빌 앳킨슨(Bill Atkinson)은 코드 최적화(Code Optimization)를 통해 오히려 2,000 라인의 코드를 줄이는 성과를 냈다. 이는 LOC가 코드 품질(Code Quality)이나 프로젝트의 실제 진척도(Project Progress)를 제대로 반영하지 못한다는 것을 시사한다.
빌 앳킨슨의 통찰: 코드 품질과 생산성
빌 앳킨슨은 코드의 양(Amount of Code)보다 코드의 질(Code Quality)과 실행 속도(Execution Speed)를 중시했다. 그는 더 적은 코드(Less Code)로 더 빠르고 효율적인 프로그램을 만드는 것을 목표로 삼았다. 앳킨슨은 퀵드로우(Quickdraw)의 영역 계산 엔진(Region Calculation Engine)을 재작성하여 성능을 6배 향상시켰고, 동시에 2,000 라인의 코드를 줄였다. 이는 코드 최적화(Code Optimization)가 생산성 향상에 기여할 수 있음을 보여준다.
생산성 지표의 올바른 활용
커뮤니티에서는 LOC와 같은 단순 지표가 아닌, 다양한 생산성 지표(Productivity Metrics)를 활용해야 한다는 의견이 제시된다. 예를 들어, 코드 리뷰(Code Review) 횟수, 테스트 커버리지(Test Coverage), 버그 발생률(Bug Rate), 리팩토링 빈도(Refactoring Frequency) 등이 고려될 수 있다. 또한, 팀의 협업(Team Collaboration)과 개발 문화(Development Culture) 역시 생산성에 큰 영향을 미친다는 점을 간과해서는 안 된다.
