2. 두 가지 가치에 대한 이야기
모든 소프트웨어 시스템은 이해관계자에게 서로 다른 두 가지 가치인 행위(behavior) 와 구조(structure) 를 제공한다.
소프트웨어 개발자는 이 두 가치를 반드시 높게 유지해야하는 책임을 가지고 있지만, 한 가지 가치에만 집중하고 나머지 가치가 배제되는 경우가 존재한다.
최악의 경우는 행위와 구조 중 덜 중요한 가치에 집중하는 바람에 소프트웨어 시스템 자체가 쓸모없게 된다는 사실이다.
2.1. 행위
소프트웨어의 첫 번째 가치는 바로 행위(behavior) 다.
개발자를 채용하는 이유는 이해관계자를 위해 기계가 수익을 창출하거나 비용을 절약하기 위해서인데,
이를 위해 개발자는 이해관계자가 기능 명세서나 요구사항 문서를 구체화할 수 있도록 돕는다.
그리고 이해 관계자의 기계까 이러한 요구사항을 만족하도록 코드를 작성한다.
만약 기계가 요구사항을 위반하는 경우, 개발자는 디버거를 통해 문제를 해결한다.
대부분의 개발자는 위에 명세한 행위가 주어진 업무의 전부라고 생각한다.
하지만 이는 틀린 생각이다.
2.2. 아키텍처
소프트웨어의 두 번째 가치는 소프트웨어(software) 라는 단어와 관련이 있다.
다들 잘 알다시피 소프트웨어라는 단어는 부드러운(soft) 와 제품(ware) 이라는 단어의 합성인데,
이 제품이라는 단어가 바로 상품(product) 을 의미한다.
남은 단어인 이 부드러운이라는 의미에 두 번째 가치인 아키텍처가 존재한다.
소프트웨어는 부드러움을 지니도록 만들어졌으며, 소프트웨어를 만드는 이유는 기계의 행위를 쉽게 변경할 수 있도록 하기 위해서다.
만약 기계의 행위를 바꾸는 일이 어렵게 해야하는 일이었다면 소프트웨어보다는 하드웨어라고 불렸을 것이다.
다시 말해 소프트웨어가 부드러움을 지녔다는 것은 변경하기 쉬워야한다는 뜻이다.
만약 이해관계자가 기능에 대한 생각을 바꾸면, 이러한 변경사항을 간단하고 쉽게 적용해야 하기 때문이다.
이러한 변경사항을 적용하는 데 드는 어려움은 변경되는 범위(scope)에 비례해야 하며, 변경사항의 형태(shape) 와는 관련이 없어야 한다.
소프트웨어 개발 비용의 증가를 결정짓는 주된 요인은 바로 이 변경사항의 범위와 형태의 차이에 있다.
자연스럽게 개발 비용은 요청된 변경사항의 크기에 비례하며, 출시를 거듭할 수록 증가한다.
이해관계자는 범위가 비슷한 일련의 변경사항을 제시할 뿐이지만, 개발자 입장에서는 복잡도가 지속적으로 증가해있는 상태인 경우가 많다.
이때문에 새로운 요청사항이 발생할 때마다 바로 이전의 변경사항을 적용하는 것보다 좀 더 공수가 들어가게 되는 것이다.
이러한 문제는 시스템의 형태와 요구사항의 형태가 서로 맞지않는 경우 더욱 힘들어지게 된다.
문제는 당연히 시스템의 아키텍처이다.
아키텍처가 특정 형태를 다른 형태보다 선호하면 할수록, 새로운 기능을 이 구조에 맞추는 게 더 힘들어질 것은 자명하다.
따라서 아키텍처는 형태에 독립적이어야 한다.
2.3. 더 높은 가치
기능과 아키텍처 중 어느 것의 가치가 더 높을까?
이 가치를 높게 유지하는 것이, 소프트웨어 시스템이 동작하도록 만드는 것이 더 중요할까?
아니면 소프트웨어 시스템을 더 쉽게 변경할 수 있도록 하는 것이 더 중요할까?
만약 업무 관리자에게 동일한 질문을 한다면 소프트웨어 시스템이 동작하는 것이 더 중요하다고 대답할 것이다.
이어서 개발자에게 묻는다면 업무 관리자의 의견에 대체로 동조하게 될 것이다.
결론적으로 이는 잘못된 태도이다.
엣지케이스를 통해 위의 태도가 잘못되었음을 증명해보자.
첫 번째 사례
완벽하게 동작하지만 수정이 아예 불가능한 프로그램이 주어지는 경우, 프로그램은 요구사항이 변경될 때 동작하지않게 되고 결국 프로그램이 돌아가도록 만들 수 없게 된다.
따라서 이러한 프로그램의 거의 쓸모가 없다.
두 번째 사례
동작은 하지 않지만 변경이 쉬운 프로그램이 주어지는 경우, 개발자는 프로그램이 돌아가도록 만들 수 있고 변경사항이 발생하더라도 여전히 동작하도록 유지보수할 수 있다.
따라서 이러한 프로그램은 유용한 채로 남아있게 된다.
물론 위의 사례가 주는 설득력이 떨어진다고 생각할 수 있다.
다만 현실적으로 수정이 불가능한 시스템은 존재하기 마련이며, 변경에 드는 비용이 변경으로 창출되는 수익을 초과하느 경우도 존재할 수 있다.
기능 또는 설정 측면에서 많은 시스템이 이처럼 수정이 현실적으로 불간으해지는 상황에 빠지게 된다.
2.4. 아이젠하워 매트릭스
미국 대통령이었던 아이젠하워가 고안한 중요성과 긴급성에 관한 아이젠하워 매트릭스를 살펴보자.
quadrantChart
title EISENHOWER’S MATRIX
quadrant-1 IMPORTANT / NOT URGENT
quadrant-2 IMPORTANT / URGENT
quadrant-3 UNIMPORTANT / URGENT
quadrant-4 UNIMPORTANT / NOT URGENT
아이젠하워는 중요함과 긴급함의 두 가지 가치로 업무를 분류하였다.
여기에 숨겨진 의미는 아래와 같다.
긴급한 문제는 절대 중요하지않고, 중요한 문제는 절대 긴급하지 않는 것이다.
소프트웨어에 대입해보자.
소프트웨어의 첫 번째 가치인 행위는 긴급하지만, 매번 높은 중요도를 가지진 않는다.
소프트웨어의 두 번째 가치인 아키텍처는 중요하지만, 즉각적인 긴급성을 필요로 하는 경우는 절대로 없다.
물론 어떤 일은 긴급하면서도 중요하며, 긴급하지도 중요하지도 않을 수 있다.
따라서 아래와 같은 우선순위를 매겨보도록 하자.
- 긴급하고 중요한
- 긴급하지는 않지만 중요한
- 긴급하지만 중요하지 않은
- 긴급하지도 중요하지도 않은
중요함에 해당하는 아키텍터라는 가치는 가장 높은 우선순위를 차지하지만, 행위를 첫 번째와 세번째의 위치하고 있다.
가장 흔한 실수는 세 번째 항목을 첫 번째로 격상시키는 경우이다.
이러한 일이 빈번하게 발생하면 시스템은 아키텍처 대신 기능을 선택하게되는 부작용이 발생한다.
따라서 기능의 긴급성이 아닌 아키텍처의 중요성을 설득하는 것이 개발자의 책임이라고 볼 수 있다.
2.5. 아키텍처를 위해 투쟁하라
효율적인 소프트웨어 개발팀은 다른 이해관계자들과 동등하게 논쟁한다.
개발팀 또한 이해관계자이기 때문이다.
개발자 개개인도 소프트웨어를 안전하게 보호해야할 책임이 있기에 이해관계가 성립한다.
즉, 아키텍처의 중요성을 설득하는 것이 개발자의 역할이자 책무인 것이다.
만약 개발자가 아닌 소프트웨어 아키텍트라면 이 책무는 더욱 중요해진다.
맡은 업무 자체도 시스템이 제공하는 특성이나 기능보다는 구조 자체에 중점을 두며,
좋은 설계와 구조를 통해 시트템의 특성과 기능을 개발하기 쉽고, 수정하기 쉽게 만들어야하기 때문이다.
