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

• 모든 소프트웨어 시스템은 클라이언트에게 행위와 구조의 두 가지 가치를 제공한다.
• 개발자는 두 가치를 모두 반드시 높게 유지해야 하는 책임을 진다.

행위

• 소프트웨어의 첫 번째 가치는 행위(기능)이다.
• 개발자라면, 클라이언트의 요구사항을 만족하는 코드를 작성해야한다.
• 만일 코드가 원하는대로 작동하지 않는다면, 프로그래머는 디버깅을 해야한다.
• 행위는 분명 중요한 가치이다. 그러나, 많은 프로그래머들이 요구사항을 구현하고 디버깅하는데 지나치게 매몰되곤 한다.

아키텍처

• 소프트웨어의 두 번째 가치는 구조(아키텍처)다.
• 소프트웨어라는 단어는 'soft'(부드러운) 와 'ware'(제품)이라는 단어의 합성어다. 다시 말해, 소프트웨어는 근본적으로 부드러워야한다.
  • 소프트웨어를 만든 이유는 기계의 행위를 쉽게 변경할 수 있게 하기 위해서다.
  • 만약 기계의 행위를 바꾸는 일을 어렵게 만들고자 했다면, 소프트웨어가 아닌 하드웨어라고 불리웠을 것이다.
• 부드러워야 한다는 말은 다시 말하면, 변경하기 쉬워야 한다는 말이다. 만일 클라이언트가 기능의 변경을 원한다면, 이러한 변화를 쉽게 적용할 수 있어야 한다.
• 그렇기 때문에 소프트웨어 개발 비용은 변경의 형태가 아닌 변경의 범위에 의해 결정되어야 한다.
  
  • A를 B로 바꾸는 일은 적은 비용으로 쉽게 적용되어야 한다.
  • 그러나 A ~ Z까지를 모두 A` ~ Z`로 바꾸는 일은 많은 비용이 필요하다.
  • 🤔 이는 의존성이 적어야하는 이유와도 연결된다고 생각한다. 의존된 객체는 변경이 전파되기 때문이다.
• 그러나 실제로는 새로운 요청사항이 발생할 때마다 바로 이전의 변경사항을 적용하는 것보다 조금씩 어려워지는데, 이는 기존 시스템의 형태와 요구사항의 형태가 서로 맞지 않기 때문이다.
• 이는 결국 시스템 아키텍처가 특정 형태를 선호하기 때문이다. 따라서 아키텍처는 형태에 독립적이어야한다.

더 높은 가치

• 그래서 기능과 아키텍처 중 어느 것에 더 높은 가치를 두어야 하는가? 저자도 그렇고 나도 그렇고 아키텍처에 더 높은 가치를 두어야한다고 생각한다.
• 아래의 두 가지 경우 중 어느 경우가 더 나은지를 생각해보자.
  • 동작은 잘 되지만, 수정이 불가능한 프로그램.
  • 수정은 잘 되지만, 동작이 안되는 프로그램.
• 수정이 불가능한 프로그램은 현재 제공 가능한 기능만을 수행할 뿐이지만, 수정이 가능한 프로그램은 얼마든지 수정해서 동작하게 만들 수 있으며 더 많은 기능을 탑재할 수도 있다.

아이젠하워 매트릭스

• 위의 네 가지 일의 중요도를 매겨보자, 당연히 중요하고 긴급한 일이 1순위가 될 것이고, 중요하지도 긴급하지도 않은 일은 4순위가 될 것이다. 그럼 중요하지 않지만 긴급한 일과 중요하지만 긴급하지 않은 일 중 어느 것의 우선 순위를 먼저 두어야 할까?
• 흔히들 중요하지 않지만 긴급한 일은 Delegate 사분면 즉 위임 사분면이라고 부른다. 반면 중요하지만 긴급하지 않은 일은 Schedule 사분면 즉 계획 사분면이라고 부른다. 여기서 차이를 알 수 있다.
• 위임한다는 말은, 해당 Task를 내 손에서 떠나보낸다는 뜻이다. 즉, 그만큼 중요도가 떨어진다는 말이다. 반면 계획한다는 말은, 해당 Task를 언젠가는 스스로 처리한다는 뜻이다. 그만큼 중요도가 높다는 말이다.
• 소프트웨어의 관점에서 볼 때, 기능은 긴급하지만 매번 중요하지는 않다. 반면, 아키텍처는 중요하지만 즉각적인 긴급성을 필요로 하는 경우는 없다.
• 물론 기능은 긴급하면서 중요할 수 있다. 문제는, 우리가 긴급하지만 중요하지 않은 기능을 중요하다고 오판해 실제로 중요도가 높은 아키텍처의 우선순위를 낮추곤 한다.
• 업무 관리자에게 있어 기능은 항상 긴급하고 항상 중요하다. 그렇기에, 아키텍처의 중요성을 관리자에게 설득하는 일은 개발자의 몫이다.

아키텍처를 위해 투쟁하라

• 결국, 개발자 역시 업무 관리자에게 아키텍처의 중요성을 설득하는 클라이언트의 역할을 수행해야한다.
• 우리는 소프트웨어를 안전하게 보호해야할 책임이 있다.
• 아키텍처가 후순위가 되면 시스템을 개발하는 비용이 더 많이 들고, 시스템에 변경을 가하는 일이 현실적으로 불가능해질 수 있다. 이렇게 되기 전에, 아키텍처를 위해 투쟁하자.