2장 두 가지 가치에 대한 이야기

모든 소프트웨어 시스템은 이해관계자에게 서로 다른 두 가지 가치를 제공하는데, 행위behavior와 구조structure가 바로 그것이다. 소프트웨어 개발자는 두 가치를 모두 반드시 높게 유지해야 하는 책임을 진다. 불행하게도 개발자는 한 가지 가치에만 집중하고 나머지 가치는 배제하곤 한다. 더 안타까운 일은 대체로 개발자가 둘 중 덜 중요한 가치에 집중하여 결국에는 소프트웨어 시스템이 쓸모없게 된다는 사실이다.

행위

소프트웨어의 첫 번째 가치는 바로 행위behavior다. 프로그래머는 기능 명세서나 요구사항 문서를 구체화할 수 있도록 돕는다. 그리고 요구사항을 만족하도록 코드를 작성한다. 요구사항을 위반하면, 문제를 고친다. 많은 프로그래머가 이러한 활동이 자신이 해야 할 일의 전부라고 생각한다. 이들은 요구사항을 구현하고 버그를 수정하는 일이 자신의 직업이라고 믿는다. 슬픈 일이지만 그들은 틀렸다.

아키텍처

소프트웨어의 두 번째 가치는 소프트웨어software‘라는 단어와 관련이 있다. 소프트웨어’라는 단어는 부드러운soft과 제품ware 이라는 단어의 합성어다. 소프트웨어는 부드러움을 지니도록 만들어졌다. 소프트웨어를 만든 이유는 기계의 행위를 쉽게 변경할 수 있도록 하기 위해서다. 만약 기계의 행위를 바꾸는 일을 어렵게 만들고자 했다면, 우리는 소프트웨어가 아니라 하드웨어라고 불렀을 것이다.

소프트웨어가 가진 본연의 목적을 추구하려면 소프트웨어는 반드시 부드러워야 한다. 다시 말해 변경하기 쉬워야 한다. 이해관계자가 기능에 대한생각을 바꾸면, 이러한 변경사항을 간단하고 쉽게 적용할 수 있어야 한다. 이러한 변경사항을 적용하는 데 드는 어려움은 변경되는 범위scope에 비례해야하며, 변경사항의 형태shape와는 관련이 없어야 한다.

새로운 요청사항이 발생할 때마다 바로 이전의 변경사항을 적용하는 것보다 조금 더 힘들어지는데, 시스템의 형태와 요구사항의 형태가 서로 맞지 않기 때문이다. 흔히 소프트웨어 개발자는 사각형 마개를 동그란 구멍에 밀어 넣도록 강요받는 느낌을 받기 때문이다.

문제는 당연히 시스템의 아키텍처다. 아키텍처가 특정 형태를 다른 형태보다 선호하면 할수록, 새로운 기능을 이 구조에 맞추는 게 더 힘들어진다. 따라서 아키텍처는 형태에 독립적이어야 하고, 그럴수록 더 실용적이다.

더 높은 가치

기능인가 아니면 아키텍처인가? 둘 중 어느 것의 가치가 더 높은가? 소프트 웨어 시스템이 동작하도록 만드는 것이 더 중요한가? 아니면 소프트웨어 시스템을 더 쉽게 변경할 수 있도록 하는 것이 더 중요한가?

대다수의 개발자와 업무관리자는 위 질문에 이렇게 답할 것이다.

“소프트웨어 시스템이 동작하는 것이 더 중요하다.”

단순한 논리 기법인 양 극단의 사례를 검토하는 방식으로 이 의견을 반박할 수 있다.

완벽하게 동작하지만 수정이 아예 불가능한 프로그램을 내게 준다면, 이프로그램은 요구사항이 변경될 때 동작하지 않게 되고, 결국 프로그램이 돌아가도록 만들 수 없게 된다. 따라서 이러한 프로그램은 거의 쓸모가 없다.

동작은 하지 않지만 변경이 쉬운 프로그램을 내게 준다면, 나는 프로그램이 돌아가도록 만들 수 있고, 변경사항이 발생하더라도 여전히 동작하도록 유지보수할 수 있다. 따라서 이러한 프로그램은 앞으로도 계속 유용한채로 남는다.

수정이 현실적으로 불가능한 시스템은 존재하기 마련인데, 변경에 드는 비용이 변경으로 창출되는 수익을 초과하는 경우에는 수정이 불가능하다고 판단할 수 있다.

아이젠하워 매트릭스

드와이트 D. 아이젠하워(Dwight D. Eisenhower) 미국 대통령이 고안한 중요성과 긴급성에 관한 아이젠하워 매트릭스를 살펴보자(그림 2.1).

그림 2.1 아이젠하워 매트릭스

여기서 엄청 중요한 사실이 담겨 있다. 긴급한 문제가 아주 중요한 문제일 경우는 드믈고, 중요한 문제가 몹시 긴급한 경우는 거의 없다.

행위는 긴급하지만 매번 높은 중요도를 가지는 것은 아니다. 아키텍처는 중요하지만 즉각적인 긴급성을 필요로 하는 경우는 절대 없다.

물론 어떤 일은 긴급하면서도 중요할 수 있다. 긴급하지도 않고 중요하지 조차 않은 일도 있다. 최종적으로는 이들 네 가지 경우에 다음과 같이 우선순위를 매길 수 있다.

1. 긴급하고 중요한
2. 긴급하지는 않지만 중요한
3. 긴급하지만 중요하지 않은
4. 긴급하지도 중요하지도 않은

아키텍처, 즉 중요한 일은 가장 높은 두 순위를 차지하고, 행위는 첫 번째와 세번째에 위차한다는 점을 주목하자.

업무 관리자와 개발자가 흔하게 저지르는 실수는 세 번째에 위치한 항목을 첫 번째로 격상시켜 버리는 일이다. 다시 말해 긴급하지만 중요하지 않은 기능과 진짜로 긴급하면서 중요한 기능을 구분하지 못한다. 이러한 실패로 인해 시스템에서 중요도가 높은 아키텍처를 무시한 채 중요도가 떨어지는 기능을 선택하게 된다.

아키텍처를 위해 투쟁하라

소프트웨어 개발자인 당신도 이해관계자임을 명심하라. 개발자인 우리도 소프트웨어를 안전하게 보호해야 할 책임이 있다.

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