 |
|
코드 재사용의 이점
소프트웨어 개발 초창기에는 개발자의 생산성이 개발자가 작성하는 코드 분량에 비례한다고 생각했다. 이는 그 당시에는 그럴 듯해 보이는 기준이었는데, 코드는 궁극적으로 잘 동작할 것으로 생각되는 바이너리 자산을 만들어낼 것이므로 많은 코드를 작성하는 것처럼 보이는 사람은 동작하는 애플리케이션을 향해 열심히 일하고 있는 것이어야 했다. 이 기준은 다른 산업에도 적용되는 것 같이 보인다. 더 많은 세금 환급을 처리하는 회계사나, 더 많은 에스프레소 음료를 만들어내는 바리스타(barista)가 생산성이 높아야 한다. 그렇지 않나? 양쪽 다 만들어 내야 하는 아이템을 많이 만들어 내기 때문에 각자의 사업을 위해 명백히 더 많은 수입을 올려야 한다.
하지만 시간이 흐르면서 작성한 코드 줄 수가 많다고 생산성이 높지는 않음을 알게 되었다. 많은 양의 코드는 분명 활동이 있다는 뜻이다. 하지만 활동이 반드시 일의 진척과 관련 있지는 않다. 매일 부정확한 세금 환급을 만들어 내는 회계사는 무척 활발하지만 고객이나 고용주 입장에서는 별 가치가 없다. 또 커피를 눈깜짝할 사이에 내어 놓지만 주문을 잘못 받는 바리스타는 분명 많은 활동을 하지만 생산적이지는 않다.
더 많은 코드는 더 많은 오류를 의미할지도 모른다
다행히도 소프트웨어 업계는 코드가 너무 많으면 나쁠 수도 있다는 점을 통상 인정한다. 두 개의 연구 결과에 따르면 평균적인 애플리케이션은 통상 코드 1000줄 당 20개에서 250개의 오류를 가지고 있다고 한다(참고자료). 이 척도는 오류 밀도(defect density)로 알려져 있다. 이 데이터로부터 끌어낼 수 있는 주된 결론은 바로 코드 줄 수가 적으면 오류도 적다는 것이다.
물론 여전히 코드는 작성해야 한다. 현재 기술 수준은 아직 애플리케이션이 스스로를 작성할 수 있는 단계에는 이르지 못했다. 하지만 이제 많은 코드를 빌려올 수는 있다. 아직 업무 컴포넌트(business component)에 있어 재사용을 현실화하지는 못했다. 즉 예를 들어 한 개발자가 다른 개발자의 Account 객체를 재사용할 수 있게 하려는 비전 말이다. 하지만 플랫폼 관점에서 재사용은 이미 우리 곁에 있다. 오픈 소스 프레임워크와 재사용하기 쉬운 지원 코드의 확산은 (예를 들면) Account 객체를 가능한 적은 줄의 코드로 구현하는 데 도움이 된다.
예를 들어, 하이버네이트(Hibernate)와 스프링(Spring)은 자바 공동체 내에서 널리 사용된다. Account 객체를 예로 들면 오늘날 (Account 객체가 필요한) 온라인 주문 애플리케이션을 만드는 신규 개발 프로젝트에 투입되는 팀이라면 객체 관계 매핑(object-relational mapping, 줄여서 ORM) 프레임워크를 완전히 새로 만드는 대신 하이버네이트나 그에 맞먹는 괜찮은 ORM 프레임워크를 사용함으로써 굉장한 이득을 얻을 수 있다. 단위 테스트(JUnit 같은 것을 쓰지 않을까?)나 의존성 주입(dependency injection, 이 경우라면 스프링(Spring)이 가장 가능성 큰 후보일 것이다) 같은 애플리케이션의 다른 측면도 마찬가지다. 이게 바로 재사용이다. 그저 우리가 한 때 재사용이 이러저러할 것이라고 생각했던 것과 다를 뿐이다.
이런 프레임워크를 빌리거나 재사용하면 궁극적으로 코드를 덜 작성할 수 있고 당면한 업무 문제에 더 적절히 집중할 수 있다. 프레임워크 자체는 많은 코드로 이뤄져 있으나 여기서 중요한 것은 여러분이 프레임워크를 작성하거나 유지 보수할 필요가 없다는 것이다. 이것이 바로 성공적인 오픈 소스 프로젝트의 좋은 점이다. 즉, 다른 사람들이 여러분을 위해 작성하고 유지 보수해 준다. 그리고 당연하지만 그 사람들은 그런 일을 하는 데 있어 여러분보다 낫다.
적은 편이 낫다
코드 줄 수가 적으면 시장에 더 빨리 출시할 수 있고 오류도 줄일 수 있다. 하지만 재사용은 코드 작성을 줄여준다는 면에서뿐 아니라 “군중의 지혜”라는 것을 활용할 수 있다는 점에서도 중요하다. 하이버네이트, 스프링, JUnit, 아파치 웹 서버 같은 인기 있는 오픈 소스 프레임워크나 도구는 지구촌 다수의 사람이 다양한 애플리케이션에 사용한다. 이런 실전에서 다듬어지고 테스트된 소프트웨어는 오류가 없지는 않겠지만 발생하는 어떤 이슈든 발견되고 고쳐질 것이며 비용도 없다는 점을 확신할 수 있다.
아파치 Commons 프로젝트는 나온 지 수년이 되었고 안정적이다. 최신판에는 대략 90개 클래스와 거의 1800개의 단위 테스트가 포함되어 있다. 테스트 커버리지(coverage)에 대한 정보는 공개되지 않았지만(그리고 분명 사람에 따라서는 이 프로젝트의 테스트 커버리지가 낮다고 할 사람도 있겠지만) 이 수치는 그 자체로 명백하다. 즉, 본질적으로 클래스 당 테스트가 20개 있다는 것이다. 개인적으로 이 프로젝트의 코드가 최소 여러분의 코드만큼은 테스트됐을 거라고 확신한다.
| 
