소프트웨어를 설계하고 작성하는 수 많은 방법론이 존재한다. (아마 SW가 운영되는 환경, 조직, 분야의 수만큼이나 다양할 것이다.)
모든 방법론이 추구하고자 하는 목적은 '단단한 소프트웨어를 작성 하는것' 여기서 말하는 단단한 소프트웨어는 아마 견고하며 결함을 최소화하고 코드 스스로가 온전히 자명하도록 하는 소프트웨어 일 것이다.
이러한 목적을 달성하기 위해 패턴화되어 반복 사용되어온 여러 방법론들이 존재한다. DbC, Defensive Programming, SOLID 원칙 등이 패턴화된 방법론들이다.
이러한 방법론들은 최소한의 코드로 고성능의 SW를 작성하고, 체계적으로 DS를 설계하여 공간복잡도와 시간복잡도를 극한으로 줄여나가는 테크니컬 방법론과는 많이 차이가 나는 부분도 있다. (어쩌면 이러한 부분을 타협하면서 까지 추구하고자 하는 방향성들이 존재한다.)
물론 테크니컬한 방법론 역시 중요하다. (작성된 SW는 최소한의 자원으로 최대의 이익을 내기 위해 설계된 도구이니까.)
하지만 작동하는 SW는 끊임업이 변해야 한다. 사용자의 니즈에 맞추서, 시장의 니즈에 맞춰서, 운영하고 있는 비즈니스에 맞춰서.
이러한 변화를 지속적으로 요구당해온 현대 SW들은 이전의 SW들과는 비교도 할 수 없이 복잡해지고 거대해 졌다. (HW의 비약적 발전으로 테크니컬한 방법론들은 더이상 큰 이슈가 아니게 된 이유도 한몫하긴 했지만.)
그리고 이러한 변화의 요구는 곧 손에 잡히지 않는 엔트로피로 다가오게 된다.
'혼돈의 최소화.'
방법론이 필요한 이유를 이렇게 정의하고 싶었다.
거대해진 SW를 운영하고 개발해 보면 이 혼돈이 얼마나 무서운지 보게 된다. 우리가 흔히 '기술 부채' 라고 말하는 이 작은 혼돈들이 나중에는 걷잡을 수 없이 커져버려 도대체 어디서부터 손을 대야 하는지도 모르는 상황에 직면하게 될 수도 있다.
그 어떤 방법론을 도입해 SW를 개발해도 이 혼돈을 없애는 건 아마 불가능할 것이다. 하지만 '혼돈이라는 변수는 언제나 존제할 것이다' 라 가정하고 관리하기 위해 노력하다 보면 최소한 SW가 혼돈에 뒤덮이는 최악의 일 까지는 막을 수 있다고 생각한다.
오늘도 수 없이 많은 혼돈과 전쟁을 치르느냐 고생한 개발자들에게 작은 위로의 말을 전하면서 이만 글을 마치고자 한다.
(앞으로 기회가 된다면 다양한 방법론에 대해 다뤄보도록 하겠다.)