행위, 구조
모든 소프트웨어 시스템은 이해관계자에게 서로 다른 두 가지 가치를 제공하는데, 행위(behavior)와 구조(structure)가 바로 그것이다.
소프트웨어 개발자는 두 가지를 모두 반드시 높게 유지해야 하는 책임을 진다.
행위
소프트웨어의 첫 번째 가치를 바로 행위(behavior)다. 프로그래머를 고용하는 이유는 이해관계자를 위해 기계가 수익을 창출하거나 비용을 절약하도록 만들기 위해서다. 그리고 이해관계자의 기계가 이러한 요구사항을 만족하도록 코드를 작성한다.
그리고 기계가 이러한 요구사항을 위반하면, 프로그래머는 디버거를 열고 문제를 고친다.
많은 프로그래머가 이러한 활동이 자신이 해야 할 일의 전부라고 생각한다. 이들은 요구사항을 기계에 구현하고 버그를 수정하는 일이 자신의 직업이라고 믿는다. 하지만 그들은 틀렸다.
아키텍처
소프트웨어의 두 번째 가치는 소프트웨어라는 단어과 관려이 있다. '부드러운(soft)'과 '제품(ware)'이라는 단어의 합성어다.
소프트웨어는 '부드러움을 지니도록' 만들어졌다. 소프트웨어를 만든 이유는 기계의 행위를 쉽게 변경할 수 있도록 하기 위해서다.
소프트웨어가 가진 본연의 목적을 추구하려면 소프트웨어는 반드시 '부드러워'야 한다. 다시 말해 변경하기 쉬워야 한다.
이러한 변경사항을 적용하는 데 드는 어려움은 변경되는 범위(scope)에 비례해야 하며, 변경사항의 형태(shape)와는 관련이 없어야 한다.
소프트웨어 개발 비용의 증가를 결정짓는 주된 요인은 바로 이 변경사항의 범위와 형태의 차이에 있다. 개발 비용은 요청된 변경사항의 크기에 비례한다. 또한 개발 첫 해가 다음 해보다 비용이 덜 들고, 다음 해에는 그다음 해보다 비용이 적게 드는 이유도 이 때문이다.
문제는 시스템 아키텍처다. 아키텍처가 특정 형태를 다른 형태보다 선호하면 할수록, 새로운 기능을 이 구조에 맞추는 게 더 힘들어진다. 따라서 아키텍처는 형태에 독립적이어야 하고, 그럴수록 더 실용적이다.
더 높은 가치
기능과 아키텍처, 둘 중 어느 것의 가치가 더 높은가?
아래의 단순 논리 기법인 양 극단의 사례를 검토해보자
완벽하게 동작하지만 수정이 불가능한 프로그램 - 요구 사항이 변경될 때 동작하지 않게 되고, 결국 프로그램이 돌아가도록 만들 수 없게 된다.
동작은 하지 않지만 변경이 쉬운 프로그램 - 프로그램이 돌아가도록 만들 수 있고, 변경사항이 발생하더라도 여전히 동작하도록 유지보수할 수 있다. 따라서 이러한 프로그램은 앞으로도 계속 유용한 채로 남는다.
아이젠하워 매트릭스
행위 - 긴급하지만 매번 높은 중요도를 가지는 것은 아니다.
아키텍처 - 중요하지만 즉각적인 긴급성을 필요로 하는 경우는 절대 없다.
다음 네 가지 경우에 다음과 같이 우선순위를 매길 수 있다.
긴급하고 중요한
긴급하지는 않지만 중요한
긴급하지만 중요하지 않은
긴급하지만 중요하지도 않은
아키텍처, 즉 중요한 일은 이 항목의 가장 높은 두 순위를 차지하는 반면, 행위는 첫 번째와 세 번째에 위치한다.
업무 관리자와 개발자가 흔하게 저지르는 실수는 세 번째에 위치한 항목을 첫 번째로 격상시켜 버리는 일이다.
긴급하지만 중요하지 않는 기능과 진짜로 긴급하면서 중요한 기능을 구분하지 못한다. 이러한 실패로인해 시스템에서 중요도가 높은 아키텍처를 무시한 채 중요도가 떨어지는 기능을 선택하게 된다.
업무 관리자는 보통 아키텍처의 중요성을 평가할 만한 능력을 겸비하지 못하기 때문에 개발자는 딜레마에 빠진다.
소프트웨어 개발자를 고용하는 이유는 바로 이 딜레마를 해결하기 위해서다.
따라서 기능의 긴급성이 아닌 아키텍처의 중요성을 설득하는 일은 소프트웨어 개발팀이 마땅히 책임져야 한다.
결론
아키텍처가 후순위가 되면 시스템을 개발하는 비용이 더 많이 들고, 일부 또는 전체 시스템에 변경을 가하는 일이 현실적으로 불가능해진다. 이러한 상황이 발생하도록 용납했다면, 이는 결국 소프트웨어 개발팀이 스스로 옳다고 믿는 가치를 위해 충분히 투쟁하지 않았다는 뜻이다.
Last updated
