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

모든 소프트웨어 시스템은 행위(behavior) 와 구조(structure) 라는 2가지 가치를 제공한다. 소프트웨어 개발자는 두 가지 가치를 모두 높게 유지해야 한다. 불행히도 개발자는 한가지 가치에만 집중한다.

행위

프로그래머를 고용하는 이유는 이해관계자의 요구사항을 만족시켜 수익을 창출하거나 비용을 절약하도록 한다. 많은 프로그래머는 이러한 활동이 할 일의 전부라고 생각하지만 틀렸다.

아키텍처

소프트웨어는 말 그대로 부드러운(soft) 제품(ware)이다. 하드웨어와 달리 행위를 유연하게 변경할 수 있어야 한다. 즉, 변경이 쉬워야 한다. 변경 하는데 드는 어려움은 변경되는 범위(scope)에 비례해야 하며 변경 사항의 형태(shape)와는 관련이 없어야 한다.

이해관계자는 범위가 비슷한 변경사항을 제시하지만 개발자 입장에선 형태가 다른 퍼즐을 맞추는 것 처럼 느낀다. 시스템의 형태와 요구사항의 형태가 맞지 않기 때문이다. 아키텍처가 특정 형태를 다른 형태보다 선호할수록 새로운 기능을 이 구조에 맞추는게 힘들어진다. 따라서 아키텍처는 형태에 독립적이어야 하고 그럴수록 더 실용적이다.

더 높은 가치

기능과 아키텍처 중 어떤 것의 가치가 더 높은가?

• 완벽하게 동작하지만 수정이 불가능한 프로그램은 요구사항이 변경될 때 동작하지 않게 되기 때문에 쓸모가 없다.

• 동작하지 않지만 변경이 쉬운 프로그램이 있다면 동작하도록 만들 수 있고 변경사항이 발생하더라도 유지보수할 수 있기 때문에 유용하다.

아이젠하워 매트릭스

아이젠하워는 중요성과 긴급함에 관해 매트릭스를 고안했다.

중요하고 긴급함	중요하고 긴급하지 않음
중요하지 않고 긴급함	중요하지 않고 긴급하지 않음

이들 네 가지는 다음과 같은 우선순위를 갖는다.

1. 긴급하고 중요함

2. 긴급하지 않지만 중요함

3. 긴급하지만 중요하지 않음

4. 긴급하지 않고 중요하지 않음

소프트웨어의 첫 번째 가치인 행위는 긴급하지만 매번 높은 중요도를 갖는건 아니다. 소프트웨어의 두 번째 가치인 아키텍처는 중요하지만 긴급성을 필요로 하는 경우는 없다. 따라서 아키텍처는 우선순위가 높은 1, 2에 해당하고, 행위는 1, 3에 해당한다.

업무 관리자와 개발자는 흔히 1, 3을 구분하지 못하고 3을 1로 격상시킨다. 이렇기 때문에 아키텍처(2)를 무시한 채 기능(3)을 선택하게 된다. 업무 관리자는 아키텍처의 중요성을 잘 모르기 때문에 기능을 요구하고 개발자는 딜레마에 빠진다. 따라서 개발자는 아키텍처의 중요성을 설득해야 한다.

아키텍처를 위해 투쟁하라

이러한 책임을 다하려면 투쟁해야 한다. 효율적인 소프트웨어 개발팀은 투쟁에 정면으로 맞서 싸운다. 개발자는 소프트웨어를 안전하게 보호해야할 책임이 있기 때문에 이것이 역할이고 책무이다.

아키텍처가 후순위가 되면 시스템을 개발하는 비용이 더 많이 들고 시스템을 변경하는 일이 불가능해진다. 이런 일이 발생하게 용납했다면 충분히 투쟁하지 않았다는 뜻이다.