Eternity's Chit-Chat

aeternum.egloos.com



진화적인 설계-1.우리는 실패하고 있다 1부 Evolutionary Design

우리는 서둘러 전진하는 것은 배웠지만 기다릴 줄은 모른다.
- 조지 칼린

우리는 실패하고 있다
소프트웨어 개발자로서 우리의 목표는 품질 높은 소프트웨어를 개발하는 것이다. 일반적으로 소프트웨어의 품질에 관해 이야기하기 위해서는 소프트웨어를 사용하는 두 범주의 사용자 그룹을 고려해야 한다. 첫 번째 사용자 범주는 자신의 필요를 충족시키기 위해 실제로 소프트웨어를 사용하는 사용자 그룹이다. 이 사용자 범주에서 소프트웨어의 품질은 적절한 시기에 적절한 비용으로 사용자가 필요로 하는 기능을 제공했는지의 여부로 판단할 수 있다. 두 번째 사용자 범주는 소프트웨어를 유지보수 할 개발자 그룹이다. 이 경우 소프트웨어 품질은 작성된 코드가 얼마나 깔끔하고 이해하기 쉬운 가로 판단할 수 있다. 전자의 품질 기준을 외부 품질(external quality)이라고 하며, 후자의 품질 기준을 내부 품질(internal quality)이라고 한다.

소프트웨어의 일차적인 목표는 외부 품질을 만족시키는 것이다. 아무리 코드가 깔끔하고 유지보수가 쉽다고 하더라도 사용자가 필요로 하는 기능을 제공하지 못하는 소프트웨어는 외면 당할 수 밖에 없다. 소프트웨어 개발자로서의 우리의 첫 번째 목표는 사용자의 필요를 충족시킬 수 있는 소프트웨어를 개발하는 것이다.

1994년에 발표된 스탠디시 그룹의 연구 결과에 따르면 일반적인 시스템의 기능 중 45%는 전혀 사용되지 않고, 19%는 거의 사용되지 않는다. 소프트웨어 기능 중 항상 사용되는 비율은 불과 7%에 불과하다. 소프트웨어 개발자로서 우리의 가장 큰 임무가 사용자를 만족시키는 소프트웨어를 개발하는 것이라면 스탠디시 그룹이 들려주는 비극적인 이야기의 주제는 단 한가지다. 우리가 처참하게 실패하고 있다는 것이다.

                               <그림 1> 소프트웨어 기능 사용률(출처: Emergent Design)

그렇다면 사용자들이 소프트웨어가 제공하는 대부분의 기능을 외면하는 근본적인 이유는 무엇인가? 불필요한 기능을 개발하기 위해 많은 금액과 시간이 소모되고 있음에도 불구하고 소프트웨어 개발 커뮤니티가 이 문제에 관해 그렇게 오랜 시간 동안 침묵으로 일관하고 있었던 이유는 무엇인가?

모든 문제의 근원에 요구사항이 존재한다. 그리고 우리를 실패하게 만드는 요구사항의 가장 큰 특성은 요구사항이 너무나도 변덕스럽다는 점이다. Robert L. Glass는 폭주하는 소프트웨어의 흔한 원인 중 한 가지로 불안정한 요구사항을 뽑았을 정도다.

요구사항 변경이 문제가 되는 이유를 이해하기 위해 전형적인 소프트웨어 개발 프로젝트를 상상해 보자. 프로젝트가 시작되면 이해관계자들이 한 자리에 모여 개발할 소프트웨어에 관해 토론한다. 개발팀은 고객이나 사용자, 또는 사용자 대표로부터 소프트웨어가 제공해야 하는 기능과 만족해야 하는 품질 지표를 수집한다. 정리가 끝나면 고객이 요구사항을 승인하고 개발팀은 승인된 요구사항을 기반으로 소프트웨어를 설계하기 시작한다.

일반적으로 소프트웨어 생명 주기 초반에 요구사항을 수정하는데 비해 구현이나 테스트와 같은 후반부에 요구사항을 수정할 경우 초기에 상대적으로 큰 비용이 소요된다. 한 연구에 따르면 요구사항 분석 단계에서 요구사항 오류를 수정하는 비용을 1이라고 할 때 유지보수 단계에서 요구사항 오류를 수정하는 비용은 100배에서 최대 200배 이상일 것으로 추정하고 있다.

        <그림 2> 요구사항 오류 수정에 소요되는 상대적 비용(출처: Managing Software Requirements)

따라서 소프트웨어를 정해진 일정 내에 개발하기 위해 취하는 조치는 요구사항의 변경을 제한하는 장치를 마련하는 것이다. 요구사항 베이스라인이 확정되면 고객은 변경 통제 위원회(CCB, Change Control Board)에 의해 엄격하게 통제되는 변경 절차를 통해서만 요구사항을 변경할 수 있다.

이처럼 요구사항 변경을 통제하기 위한 장치를 마련했음에도 불구하고 소프트웨어가 사용자의 요구사항을 만족시키지 못하는 이유는 무엇인가? 사용자는 실제로 동작하는 소프트웨어를 보기 전까지는 자신이 원하는 기능이 무엇인지를 알지 못하기 때문이다. 따라서 실제 소프트웨어를 볼 수 있는 프로젝트 후반부에 가서야 가치 있는 요구사항을 내놓게 되며 이것은 곧 커다란 비용을 수반하는 요구사항 변경으로 이어진다.

앞서 언급한 바와 같이 생명주기 후반부에 요구사항이 변경될 경우 프로젝트의 출시가 지연될 가능성이 급격히 높아진다. 따라서 비록 가치가 있더라도 높은 비용이 수반되는 요구사항 변경 요청에 대한 일반적인 응답은 요구사항 변경을 금지하는 것이다. 그 결과 소프트웨어의 기능 중 단 7%만이 주기적으로 사용된다는 통계치가 보여주듯이 사용자가 요구하는 외부 품질 기준을 만족시키지 못하는 낮은 품질의 소프트웨어가 넘쳐나게 되고 말았다.