모든 소프트웨어 시스템은 이해관계자에게 행위(Behavior)와 구조(Structure)라는 두가지 가치를 제공한다.
따라서 소프트웨어 개발자는 두 가치를 모두 반드시 높게 유지해야 하는 책임을 진다.
하지만 한 가지 가치에만 집중하고 나머지 가치는 배제하곤 하며, 대체로 덜 중요한 가치에 집중하여 결국에는 소프트웨어 시스템이 쓸모 없게 만들어버린다.
행위(기능)
프로그래머를 고용하는 이유는 이해관계자를 위해 기계가 수익을 창출하거나 비용을 절약하도록 만들기 위해서이다.
- 이해관계자가 기능 명세서나 요구사항 문서를 구체화할 수 있도록 돕는다.
- 이해관계자의 기계가 이러한 요구사항을 만족하도록 코드를 작성한다.
- 요구사항을 위반하면 문제를 고친다.
행위는 개발자가 구현해야하는 기능을 의미하며, 기능을 구현하고 만들어진 기능을 운영하는 것만을 개발자의 역할이라고 생각한다.
아키텍처
소프트웨어라는 단어는 부드러운(soft)과 제품(ware)의 합성어이다.
소프트웨어는 부드러움을 지니도록 만들어졌으며, 소프트웨어를 만든 이유는 기계의 행위를 쉽게 변경할 수 있도록 하기 위해서이다.
따라서 소프트웨어가 가진 본연의 목적을 추구하려면 소프트웨어는 반드시 부드러움, 즉 변경이 쉬워야하며 이해관계자가 기능에 대한 생각을 바꾸면 이러한 변경사항을 간단하고 쉽게 적용할 수 있어야 한다.
변경사항을 적용하는 데 드는 어려움은 변경되는 범위에 비례해야하며, 변경사항의 형태와는 관련이 없어야 한다.
소프트웨어 개발 비용의 증가를 결정짓는 주된 요인은 바로 변경사항의 범위와 형태의 차이에 있다.
이해관계자는 범위가 비슷한 일련의 변경사항을 제시할 뿐이지만, 개발자 입장에서는 복잡도가 지속적으로 증가하는 퍼즐 판 위에서 이해관계자가 계속해서 퍼즐 조각을 맞추라는 지시를 하는 것처럼 느낀다.
이는 시스템의 형태와 요구사항의 형태가 서로 맞지 않기 때문인데, 원인은 소프트웨어 아키텍처다.
아키텍처가 특정 형태를 다른 형태보다 선호하면 할수록, 새로운 기능을 이 구조에 맞추는 게 더 힘들어진다.
따라서 아키텍처는 항상 형태에 독립적이어야하고, 그럴수록 더 실용적이다.
더 높은 가치
기능과 아키텍처 둘 중 어느 것의 가치가 더 높은지 업무 관리자에게 묻는다면, 대다수가 소프트웨어 시스템이 동작하는 것이 더 중요하다고 대답하지만, 개발자는 아키텍처에 더 가치를 둬야한다.
양 극단 사례 검토
- 완벽하게 동작하지만 수정이 불가능한 프로그램은 요구사항이 변경될 때 동작하지 않게 되어 쓸모가 없다.
- 동작은 하지 않니만 변경이 쉬운 프로그램은 개발자가 돌아가도록 만들 수 있고, 변경사항이 발생하더라도 여전히 동작하여 유용한채로 남는다.
변경에 드는 비용이 변경으로 창출되는 수익을 초과하는 경우 수정이 현실적으로 불가능하며, 이로 인해 기능 또는 설정 측면에서 만은 시스템이 현실적으로 수정할 수 없는 상황에 빠진다.
현재의 기능 동작을 위해 미래의 유연성을 희생한다면, 변경에 드는 비용이 높아지게되어 현실적으로 수정할 수 없는 상황에 빠지게되고, 결과적으로 책임은 개발자에게 돌아간다.
아이젠하워 매트릭스
긴급한 문제가 아주 중요한 문제일 경우는 드물고, 중요한 문제가 몹시 긴급한 경우는 거의 없다.
- 긴급 O, 중요 O
- 긴급 X, 중요 O
- 긴급 O, 중요 X
- 긴급 X, 중요 X
아이젠하워 매트릭스에서는 위와 같은 우선순위로 문제를 해결할 것을 제안하고 있다.
첫 번째 가치인 행위는 대부분 긴급하지만 매번 높은 중요도를 가지는 것은 아니며, 두 번째 가치인 아키텍처는 중요하지만 즉각적인 긴급성을 필요로 하는 경우는 절대 없다.
아키텍처는 1, 2를 차지하는 반변, 행위는 1, 3에 위치한다.
많은 업무 관리자와 개발자가 3번에 위치한 항목을 1번으로 격상시키는 실수를 많이 한다.
- 긴급하지만 중요하지 않은 기능과 진짜로 긴급하면서 주용한 기능을 구분하지 못한다.
이러한 실패로 중요도가 높은 아키텍처를 무시한 채 중요도가 떨어지는 기능을 선택하게 된다.
아키텍처를 위해 투쟁하라
더 중요한 가치인 아키텍처가 더 낮은 우선순위를 가지게 되는 이유는 대부분의 업무 관리자가 아키텍처의 중요성을 평가하지 못하기 때문이다.
따라서 개발자, 개발팀은 다른 이해관계자들을 설득해야 할 의무가 있다.
- 기능의 긴급성이 아닌 아키텍처의 중요성을 설득하는 일은 소프트웨어 개발팀이 책임을 져야한다.
- 소프트웨어 개발자도 이해관계자이며, 소프트웨어를 안전하게 보호해야 할 책임이 있다.
소프트웨어 아키텍트는 시스템이 제공하는 특성이나 기능보다는 시스템의 구조에 더 중점을 둔다. 아키텍트는 이러한 특성과 기능을 개발하기 쉽고, 간편하게 수정할 수 있으며, 확장하기 쉬운 아키텍처를 만들어야 한다.
개발자가 아키텍처에 더 높은 우선순위를 둘 수 있도록 이해관계자들과 투쟁하는 것은 장기적인 관점에서 더 나은 소프트웨어를 만들 수 있는 가능성을 높힌다.
아키텍처가 후순위가 되면 시스템을 개발하는 비용이 점점 더 많이 들게되고, 결국 일부 또는 전체 시스템에 변경을 가하는 일이 현실적으로 힘들어진다.
이러한 상황이 발생하도록 용납했다면, 이는 결국 소프트웨어 개발팀이 스스로 옳다고 믿는 가치를 위해 충분히 투쟁하지 않았다는 뜻이다.