"그렇게 하는 게 좋은 건 알겠는데, 개발이 느려지잖아."
소프트웨어 프로젝트에 있어서 빠른 개발 즉, 효율성이 중요하다는 것은 누구나 공감하는 사실일 것이다. 수많은 방법론들과 도구, 라이브러리, 프레임워크들은 한결같이 ‘효율성’을 강조한다. 그렇다면 소프트웨어 제품에 있어서 효율성이란 무엇인가? 시간당 코드 라인 수? 일주일에 구현하는 기능의 수?
가장 간단하게 정의한다면, 시간당 추가되는 소프트웨어의 기능과 품질이 될 것이다.* 하지만, 많은 사람들은 이 효율성이란 기준에서 품질을 무시한다. De Marco가 Peopleware에서 언급했듯이, time-to-market 압박에 가장 먼저 희생되는 것은 기능이 아니라 소프트웨어 품질이다. 소프트웨어의 품질**은 고객이나 매니저의 눈에 띄지도 않기 때문이다.
물론, 현실적으로 기능에 대비해 품질을 희생할 수 밖에 없는 상황은 비일비재하다. 어느 날 갑자기 사장이 인터뷰를 통해서 다음달에 어떤 소프트웨어 제품이 나올 거라고 공언해놓고, ‘자 이제부터 이러이러한 소프트웨어를 만들어라’ 하면서 일감을 던져주는 것을 받아본 경험은, 소프트웨어 개발자로서의 경험이 어느 정도 있는 사람이라면 한번 정도씩은 있을 것이다. 이러한 문제가 너무나 심각해서, 어떤 사람들은 품질을 희생하는 것이 아니라 오히려 기능을 희생해야 한다고 얘기하기도 한다. 무엇이 옳든 간에, 소프트웨어의 기능과 품질을 둘 다 만족시킬 수 없는 상황에서 이 문제는 전형적인 trade-off 문제가 된다. 현재 개발자 커뮤너티의 대체적인 의견은 이러한 trade-off에 의한 품질의 희생은 불가피하며 iterative development를 통해서 극복이 가능하다고 생각하는 편이다.
문제는, 효율성을 이유로 들어 소프트웨어 품질의 희생을 일상화하는 경우다. 소프트웨어 품질을 일상적으로 희생하게 되면, 소프트웨어 라이프사이클이 이어질수록 소프트웨어 효율성에 나쁜 영향을 미친다. 결국에는 그 소프트웨어를 버리거나 그냥 대충 때우는 것 외의 대안이 없는 상태가 되어버린다. 물론 모든 소프트웨어가 긴 수명을 가지지는 않는다. 학교에서의 소프트웨어 프로젝트와 같은 일시적으로 필요한 단순한 소프트웨어나, 빠르게 사용자 요구가 변화하고 사라지곤 하는 웹 어플리케이션과 같은 경우에는 품질을 희생하더라도 별 문제가 없을 수 있다. 하지만 반대로, 긴 수명을 가지는 소프트웨어도 존재한다. 그러한 소프트웨어를 매번 버리고 새로 만드는 것은 프로토타이핑의 목적이 아니라면 매우 비효율적이다. 설령 어떤 목적으로 (이를 테면, 경험이 부족한 도메인의 실험적인 프로젝트) 매번 버리고 새로 만든다 하더라도, 그럴 때마다 기존의 것을 가능한 한 재사용하는 방식을 추구해야 한다.
소프트웨어의 품질이 지속적으로 효율성에 영향을 미치는 장기적인 소프트웨어 프로젝트에서, 소프트웨어 품질의 희생을 일상적으로 받아들이는 태도는 잘못된 것이다. 마치 고급 아파트를 지을 때의 마감공사를 조립식 건물을 지을 때처럼 대충하는 것과 다를 바가 없다. 이러한 태도는 소프트웨어 품질 자체에 관해 무지하거나, 소프트웨어 프로젝트의 수명에 따라 품질에 대한 태도를 다르게 해야 한다***는 사실에 대해 무지하거나, 소프트웨어 프로젝트의 수명에 대해서 착각을 하고 있기 때문에 발생하는 것이다.
어떤 사람은 소프트웨어 품질에 대한 태도가 단지 개발자 개개인의 ‘스타일’의 문제이고 이를 받아들여야 한다고 얘기한다. 물론, 특정 도메인에서 소프트웨어 개발을 지속적으로 해온 사람은 소프트웨어 품질에 대한 특정한 태도를 내면화하여 그것을 ‘스타일’로 가질 수는 있다. 하지만, 그것이 ‘스타일’이라고 해서 합리화될 수는 없는 것이다. 소프트웨어 품질에 대한 태도는 개발자에 따라 달라지는 것이 아니라 소프트웨어 제품 또는 프로젝트에 따라 달라져야 하는 것일 뿐이다. 여기서 ‘스타일’이라고 지칭되는 것은 사실상 ‘습관’에 불과한데, 대부분의 평범한 소프트웨어 개발자들은 자신의 습관에 따라 행동하고, 때로 특정한 도메인이나 특정한 소프트웨어 프로젝트에서는 그 습관을 통해 최고의 능력을 보여줄 수도 있다. 하지만, 뛰어난 개발자들은 그러한 습관을 내면적인 규칙(discipline)을 통해 극복하고, 도메인이나 소프트웨어 프로젝트에 따라 서로 다른 적절한 태도를 취하고, 어느 곳에서나 최고의 능력을 보여줄 수 있다.
결국, 장기적인 소프트웨어 프로젝트에서 조차도, 소프트웨어 품질 희생의 일상화를, 효율성을 근거로 하여, 합리화하기를 즐기는 사람들은 대체로 자신의 습관이나 부족한 능력에 대한 변명을 하고 있을 뿐이다. 정말로 뛰어난 개발자는 거의 항상 (최고가 아니라) 적절한 – 기능과 품질 양쪽 모두에서의 – 효율성을 성취할 수 있기 때문이다.
* 소프트웨어의 특성을 기능과 품질로 양분한 것은 논의의 간결함을 위한 것이다. 소프트웨어는 그 복잡성만큼이나 요구되는 특성들이 많다.
** 이 때, 소프트웨어의 품질이란, 소프트웨어라는 제품이 가지는 특성으로서의 품질이 아니라, 소프트웨어 자체의 품질, 굳이 예로 들자면 코드의 품질과 같은 내부적인 특성을 얘기한다.
*** 소프트웨어의 수명만이 소프트웨어 품질에 대해 요구되는 태도를 결정짓는 것은 아니다. 다양한 비즈니스적인 요구나 도메인에 대한 개발자의 지식 등 여러 가지 요소들이 모두 영향을 미칠 수 있다.