소프트웨어를 개발하는데 있어서 꼭 알아야 할 규칙이 하나 있다. 바로 “1:10:100 rule”이다. 성숙한 개발 문화를 가지고 있는 회사는 전 직원들이 진정으로 그 의미를 알고 있고 실행하고 있다. 하지만 우리나라의 크고 작은 많은 소프트웨어 회사 임직원들은 그 의미를 모르거나 알고 있어도 단어의 의미로만 알고 있고 진정으로 깨우치고 있지는 못하다. 소프트웨어를 개발하면서 발생하는 많은 비효율과 문제들이 바로 여기서 출발하는 것이다.

그 1:10:100 rule을 설명한 그래프가 아래에 있다.

(스펙 1:10:100 규칙 그래프)

스펙을 작성할 때 요구사항을 바꾸면 “1″이라는 비용이 들지만 고객에게 전달된 다음에 바뀌면 수백배의 비용이 들어간다. 요구사항이든 설계든 한단계 뒤에서 고치게 될 경우 2~5배의 비용이 들어가서 단계를 거치고 시간이 흐를수록 수정 비용은 기하급수로 증가를 한다. 따라서 기획이 제대로 되어야 하고 분석 설계가 적절하게 잘되어야 한다. 한창 개발 중에 기획이 바뀌거나 요구사항이 바뀌면 그 수정 비용은 엄청나다는 것을 알아야 한다.

개발자들은 기획에서 정확한 요구사항을 주지 않는다거나 나중에 요구사항을 바꾼다고 불평이 많다. 불평은 하지만 그것을 현실로 받아들이고 스스로 이를 개선하려는 노력은 별로 하지 않는다. 오히려 상황이 그러니 분석, 설계를 제대로 하지 않고 대충 개발하다가 나중에 바꿔달라고 하면 또 대충 받아들여서 바꿔주고 이런 악순환을 반복하곤 한다.

기능에 따라서는 나중에 고쳐도 비용이 크지 않은 것도 있지만, 비용이 수백배 들어가는 것도 있다. 특히 아키텍처에 관련된 것이나, 비기능적인 요소는 나중에 수정할 경우 상상할 수 없는 비용이 들어간다.

이런 것을 극복하기 위해서 여러 방법론이 나오기도 하고 한때 Agile이 각광을 받았지만, 이런 방법론이나 기법으로는 이를 해결할 수는 없다. 정공법 외에는 방법이 없다. 기획을 제대로 하고 분석 설계를 효율적이고 적절하게 하면 된다. 또한 그 과정에서 모든 이해관계자가 책임을 지고 검토를 해서 문제가 없게 해야 하면 나중에 딴소리를 하거나 바꿔달라고 하면 안된다. 정말 중요한 변경 요청이 아니면 다음 버전으로 미루는 것이 좋은 전략이다.

from allofsoftware.net