[Clean Architecture] 2장. 두 가지 가치에 대한 이야기

introduction

• 모든 소프트웨어 시스템은 이해관계자에게 서로 다른 두 가지 가치를 제공
  • 행위 (behavior)
  • 구조 (structure)
• 소프트웨어 개발자는 두 가지 가치를 모두 반드시 높게 유지해야 하는 책임을 진다.

행위

• 프로그래머를 고용하는 이유는 이해관계자를 위해 기계가 수익을 창출하거나 비용을 절약하도록 만들기 위해서
• 이를 위해 프로그래머는 이해관계자가 기능 명세서나 요구 사항 문서를 구체화할 수 있도록 돕는다.
• 그리고 이해관계자의 기계가 이러한 요구사항을 만족하도록 코드를 작성함
  • 기계가 이러한 요구사항을 위반하면, 프로그래머는 디버거를 열고 문제를 고침
• 많은 프로그래머가 이러한 활동이 자신이 해야 할 일의 전부라고 생각한다.
  • 이들은 요구사항을 기계에 구현하고 버그를 수정하는 일이 자신의 직업이라 믿지만, 이는 틀렸다.

아키텍처

• 소프트웨어는 반드시 부드러워야 하고, 변경하기 쉬워야 한다.
• 이해관계자가 기능에 대한 생각을 바꾸면, 이러한 변경사항을 간단하고 쉽게 적용할 수 있어야 한다.
• 이러한 변경사항을 적용하는 데 드는 어려움은 변경되는 범위에 비례해야 하며, 변경사항의 형태와는 관련이 없어야 한다.
• 소프트웨어 개발 비용의 증가를 결정짓는 주된 요인은 바로 이 변경사항의 범위와 형태의 차이에 있다.
  • 바로 이 때문에 개발 비용은 요청된 변경사항의 크기에 비례한다.
• 문제는 당연히 시스템 아키텍처
• 아키텍처가 특정 형태를 다른 형태보다 선호하면 할수록, 새로운 기능을 이 구조에 맞추는 게 더 힘들어진다.
• 따라서 아키텍처는 형태에 독립적이어야 하고, 그럴수록 더 실용적이다.

더 높은 가치

• 변경이 완전히 불가능한 프로그램이란 존재하지 않는다.
• 하지만 수정이 현실적으로 불가능한 시스템은 존재하기 마련
  • 변경에 드는 비용이 변경으로 창출되는 수익을 초과하는 경우
• 기능 또는 설정 측면에서 많은 시스템이 이처럼 수정이 현실적으로 불가능해지는 상황에 빠짐
• 업무 관리자에게 변경이 가능한 시스템을 원하는지 묻는다면, 당연히 그렇다고 답할 것
  • 물론 현재 기능의 동작 여부가 미래의 유연성보다 더 중요하다는 언급을 빼놓지는 않을 것
• 하지만 추후 업무 관리자의 변경 요청에 “변경 비용이 너무 커서 현실적으로 적용할 수 없다” 라고 대단하면,
  • “실질적으로 변경이 불가능한 상태에 처할 때까지 시스템을 방치했다” 며 당신에게 화를 낼 가능성이 높다.

아이젠하워 매트릭스

내갠 두 가지 유형의 문제가 있습니다. 하나는 긴급이며, 다른 하나는 중요합니다. 긴급한 문제는 중요하지 않으며, 중요한 문제는 절대 긴급하지 않습니다.

• 소프트웨어의 첫 번째 가치인 행위는 긴급하지만, 매번 높은 중요도를 가지는 것은 아니다.
• 소프트웨어의 두 번째 가치인 아키텍처는 중요하지만, 즉각적인 긴급성을 필요로 하는 경우는 절대 없다.
• 최종적으로 이들 네 가지 경우의 우선 순위

• 아키텍처는 2순위, 행위는 1순위, 3순위
• 기능의 긴급성이 아닌 아키텍처의 중요성을 설득하는 일은 소프트웨어 개발팀이 마땅히 책임져야 함

아키텍처를 위해 투쟁하라

• 효율적인 소프트웨어 개발팀은
  • 이러한 투쟁에서 정면으로 맞서 싸운다.
  • 뻔뻔함을 무릅쓰고 다른 이해관계자들과 동등하게 논쟁한다.
• 소프트웨어 개발자도 이해관계자이다.
• 소프트웨어를 안전하게 보호해야 할 책임이 있고, 역할 중 하나이며, 고용된 중요한 이유다.
• 소프트웨어 아키텍트는 시스템이 제공하는 특성이나 기능보다는 시스템의 구조에 더 중점을 둔다.
• 아키텍트는 이러한 특성과 기능을 개발하기 쉽고, 간편하게 수정할 수 있으며, 확장하기 쉬운 아키텍처를 만들어야 한다.
• 아키텍처가 후순위가 되면 시스템을 개발하는 비용이 더 많이 들고, 일부 또는 전체 시스템에 변경을 가하는 일이 현실적으로 불가능해진다.