1:10:100 rule

소프트웨어를 개발하는데 있어서 꼭 알아야 할 규칙이 하나 있다. 바로 "1:10:100 rule"이다.

성숙한 개발문화를 가지고 있는 회사는 전 직원들이 진정으로 그 의미를 알고 있고 실행하고 있다. 하지만 우리나라의 크고 작은 대부분의 소프트웨어 회사 임직원들은 그 의미를 모르거나 알고 있어도 단어의 의미로만 알고 있고 진정으로 깨우치고 있지는 못하다.

소프트웨어를 개발하면서 발생하는 많은 비효율과 문제들이 바로 여기서 출발하는 것이다.

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

요구사항이 스펙을 작성하면서 바뀌면 "1"이라는 비용이 들지만 고객에게 전달된 다음에 바뀌면 "368"배의 비용이 들어간다.

요구사항이든 설계든 한단계 뒤에서 고치게 될 경우 2~5배의 비용이 들어가서 시간이 흐를수록 비용은 기하급수로 증가를 한다.

따라서 기획이 제대로 되어야 하고 분석 설계가 적절하게 잘되어야 하며 한창 개발중에 기획이 바뀌거나 요구사항이 바뀌면 그 수정 비용은 엄청나다는 것을 알야 한다.

말은 쉽지만 이를 진정으로 꺠닫고 실천하는 회사나 개발자를 만나는 것은 쉬운 일이 아니다. 

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

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

전 임직원이 1:10:100 rule을 진정으로 깨닫고 있다면 글로벌 소프트웨어 회사가 될 수 있는 잠재력이 충분히 있다고 할 수 있다.