1-2. 두 가지 가치에 대한 이야기

모든 소프트웨어 시스템은 이해관계자에게 서로 다른 두 가지 가치를 제공하는데,

행위(behavior)와

구조(structure)가 있다.

소프트웨어 개발자는 두 가치를 모두 반드시 높게 유지해야 하는 책임을 가진다. 불행하게도 개발자는 한 가지 가치에만 집중하고 나머지 가치는 배제하곤 한다.

 

행위

소프트웨어의 첫 번째 가치는 바로 행위.

프로그래머는 이해관계자가 기능 명세서나 요구사항 문서를 구체화할 수 있도록 돕는다.

그리고 이해관계자의 기계가 이러한 요구사항을 만족할 수 있도록 돕는다.

기계가 이러한 요구사항을 위반하면, 프로그래머는 디버거를 켜고 문제를 고친다.

많은 프로그래머들은 이러한 활동이 자신이 해야 할 일의 전부라고 생각한다.

이들은 요구사항을 기계에 구현하고 버그를 수정하는 일이 자신의 직업이라고 믿는다. 슬프게도 그들은 틀렸다.

 

아키텍처

소프트웨어의 두 번째 가치는 소프트웨어라는 단어에 관련 있다.

부드러운(soft) + 제품(ware)의 합성이다.

소프트웨어는 ‘부드러움’을 지니도록 만들어졌다.

소프트웨어를 만든 이유는 기계의 행위를 쉽게 변경할 수 있도록 하기 위해서다.

만약 기계의 행위를 바꾸는 일을 어렵게 한다면, 우리는 소프트웨어가 아니라 하드웨어라고 했을 것이다.

소프트웨어는 부드러워야 한다.

소프트웨어 개발 비용의 증가를 결정짓는 주된 요인은 바로 이 변경사항의 범위와 형태의 차이에 있다. 바로 이 때문에 개발 비용은 요청된 변경사항의 크기에 비례한다.

문제는 시스템의 아키텍처다. 아키텍처가 특정 형태를 다른 형태보다 선호하면 할수록, 새로운 기능을 이 구조에 맞추는 게 더 힘들어진다.

따라서 아키텍처는 형태에 더 독립적이어야 하고, 그럴수록 더 실용적이다.

 

더 높은 가치

기능과 아키텍처, 어떤 게 더 가치가 높을까?

완벽하게 동작하지만 수정이 아예 불가능한 프로그램 - 요구사항이 변경되면 아무 것도 할 수 없고, 결국 프로그램은 쓸모가 없어진다.

동작은 하지 않지만 변경이 쉬운 프로그램을 - 우리는 프로그램을 돌아가게 만들 수 있고, 변경사항이 발생하여도 여전히 동작하도록 유지할 수 있다. 앞으로도 계속 유용한 채로 남는다.

물론 수정이 아예 불가능한 프로그램은 존재하지 않겠지만, 현실적으로 불가능한 경우는 많이 존재한다.

 

아키텍처를 위해 투쟁하라

효율적인 소프트웨어 개발팀은 이러한 투쟁에서 정면으로 맞서 싸운다.

하나만 기억하자. 아키텍처가 후순위가 되면 시스템을 개발하는 비용이 더 많이 들고, 일부 또는 전체 시스템에 변경을 가하는 일이 현실적으로 불가능해진다.