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

행위

소프트웨어의 첫 번째 가치는 행위입니다.

프로그래머를 고용하는 이유는 기계가 수익을 창출하거나 비용을 절약하도록 만들기 위해서 입니다.

그리고 기계에 문제가 생기면 디버거를 통해 버그를 고칩니다.

많은 프로그래머가 요구사항을 기계에 구현하고 버그를 수정하는 일이 자신의 직업이라고 믿지만 아쉽지만 그 생각은 틀렸습니다.

아키텍처

소프트웨어의 두 번째 가치는 아키텍처 입니다.

소프트웨어에서 소프트라는 단어가 이 가치에 부합합니다.

소프트웨어는 변경하기 쉬워야합니다.

변경사항을 적용하는데는 변경되는 범위와 비례해야 하며 형태와는 관련이 없어야 합니다.

아키텍처가 특정 형태를 다른 형태보다 선호하면 할수록, 새로운 기능을 이 구조에 맞추는게 더 힘들어집니다.

아키텍처는 형태에 독립적이어야하 하고, 그럴수록 더 실용적입니다.

더 높은 가치

기능과 아키텍처 둘 중 어느 것이 더 중요한가? 라는 질문에 저자는 양 극단으로 사례를 보여줍니다.

아래 두 케이스의 프로그램을 나한테 맡긴다면? 이라는 가정입니다.

• 완벽하게 동작하지만 수정이 아예 불가능
  • 요구사항이 변경 될 때마다 동작하지 않는 프로그램이 됨
  • 손 댈수 없음
• 동작은 하지 않지만 변경이 쉬운 프로그램
  • 변경이 쉬우므로 동작하도록 구현할 수 있음

변경이 불가능한 시스템은 없겠지만, 현실적으로 변경이 불가능한 시스템은 존재합니다.

바로 변경에 드는 비용이 변경으로 창출되는 수익을 초과하는 경우입니다.

업무관리자는 미래의 유연성보다 현재 기능 여부가 더 중요하다고 할테지만, 실제 그렇게 구현한다면 얼마 지나지 않아 더이상 변경이 불가능한 시스템을 보고 변경이 불가능한 지경까지 방치한 프로그래머에라며 화를 낼 가능성이 높다고 합니다.(진짜 그럴것 같음)

아이젠하워 매트릭스

트와이트 D. 아이젠하위 미국 대통령이 고안한 중요성과 긴급성에 관한 아이젠하워 매트릭스를 살펴보겠습니다.

• 소프트웨어의 첫 번째 가치인 행위는 긴급하지만 매번 높은 중요도를 가지는 것은 아님
• 소프트웨어의 두 번째 가치인 아키텍처는 중요하지만 죽각적인 긴급성을 필요로 하는 경우는 절대 없음

위 테이블을 우선순위로 매긴다면 중요도 > 긴급함이 됩니다.

1. 긴급하고 중요함
2. 긴급하지는 않지만 중요함
3. 긴급하지만 중요하지 않음
4. 긴급하지도 중요하짇 않음

업무 관리자는 3번을 1번처럼 말함으로써 프로그래머는 중요도가 높은 아키텍처는 뒤로하고 중요도가 낮은 일을 긴급하게 처리하게 됩니다.

기능의 긴급성이 아닌 아키텍처의 중요성을 설득하는 일은 소프트웨어 개발팀이 마땅히 책임져야 합니다.

아키텍처를 위해 투쟁하라

모든 팀은 자신만의 가치를 위해 투쟁합니다.

프로그래머는 소프트웨어를 안전하게 보호해야 할 책임이 있으며 그것이 책무 중 하나입니다.

또한 이것이 프로그래머로써 우리가 고용된 이유입니다.

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

이런 상황이라면 소프트웨어 개발팀이 스스로 옳다고 믿는 가치를 충분히 투쟁하지 않았는 뜻입니다.