개발자가 새 라이브러리 쓸 때 '코드 줄 수'부터 확인해보는 이유

요약 개발자가 새로운 루비 라이브러리(Gem)를 도입하거나 직접 설계할 때 '코드 줄 수(LOC)'를 여전히 유용한 판단 기준으로 삼아야 한다는 주장이 제기되었습니다. 글쓴이는 라이브러리의 README를 읽은 뒤 실제 구현에 대략 몇 줄의 코드가 필요할지 먼저 상상해보고, `cloc` 같은 도구로 실제 코드 라인 수를 측정해 비교해 보라고 권합니다. 예상보다 코드 줄 수가 훨씬 적다면, 개발자가 미처 몰랐던 흥미로운 Enumerable 메서드를 활용했거나 참신한 클래스 구조, 혹은 쓰레드 안전성을 영리하게 해결한 모범 사례가 숨어 있어 코드를 뜯어보며 배울 기회가 됩니다. 반대로 생각보다 코드가 지나치게 길다면, 해당 문제 영역 자체가 예상보다 훨씬 복잡하거나 라이브러리가 불필요하게 과도한 추상화를 적용해 코드가 비대해졌다는 신호일 수 있습니다. 이 경우 해당 라이브러리를 프로젝트의 의존성으로 추가하는 것을 재고해 볼 필요가 있습니다. 글쓴이는 이를 '산뜻하게 읽히는 설계(Breezy reads)'라고 부르며, 숙련된 개발자가 1시간 이내에 전체 구조를 파악할 수 있는 간결성을 지향합니다. 실제로 그가 만든 ActiveRecord::AssociatedObject나 ActiveJob::Performs 같은 젬은 핵심 로직이 100줄 미만으로 유지되고 있습니다. 그는 코드 줄 수를 기준으로 100줄 미만(작고 확실한 효용), 250~500줄(중간 수준의 복잡도), 500~1,000줄(복잡한 문제를 확실히 해결해야 정당화되는 규모), 1,000줄 이상(오류 발생 가능성이 급격히 커지는 대형 프로젝트)으로 나누어 라이브러리의 가치와 복잡도를 가늠하는 기준을 제시했습니다.