[클린 아키텍처] 행위, 아키텍처 두가지 가치에 대하여

소프트웨어 개발자는 행위(behavior), 구조(structure)이 두 가지 가치를 반드시 높게 유지해야 하는 책임을 가진다.
행위에만 집중하게 된다면 소프트웨어 시스템은 쓸모없게 된다.

행위, 동작(Behavior)

• 프로그래머는 이해관계자나 기능 명세서나 요구사항 문서를 구체화할 수 있도록 돕는다.
• 이해관계자의 기계가 이러한 요구사항을 만족하도록 코드를 작성한다.
• 많은 프로그래머가 이러한 활동이 자신이 해야 할 일의 전부라고 생각하지만(버그 수정 및 기능 개발), 이 것은 틀렸다.

아키텍처(Architecture)

• 소프트웨어가 가진 본연의 목적을 추구하려면 소프트웨어는 반드시 부드러워야 한다.
  • 다시 말해 변경하기 쉬어야 한다.
  • 이해관계자가 기능에 대한 생각을 바꾸면, 변경사항을 간단하고 쉽게 적용할 수 있어야한다.
  • 이러한 변경사항을 적용하는 데 드는 어려움은 변경되는 범위(scope)에 비례해야하며, 형태(shape)와는 관련이 없어야 한다.
• 아키텍처가 특정 형태를 선호하면, 새로운 기능(다른 형태)을 이 구조에 맞추는게 힘들어진다.
  • 아키텍처는 형태에 독립적이어야 하고, 그럴수록 더 실용적이다.

행위, 아키텍처 더 높은 가치(기능 vs 아키텍처)

• 완벽하게 동작하지만 수정이 아예 불가능한 프로그램
  • 요구사항이 변경될 때 동작하지 않게 되고, 결국 프로그램이 돌아가도록 만들 수 없다.
  • 이러한 프로그램은 거의 쓸모가 없다.
• 동작은 하지 않지면 변경이 쉬운 프로그램
  • 개발자가 프로그램이 돌아가도록 만들 수 있고, 변경사항이 발생하더라도 동작하도록 유지보수가 가능하다.
  • 앞으로 계속 유용하다.

업무 관리자라면 시스템이 동작하는 것을 더 중요시 여기겠지만, 개발자는 행위, 아키텍처에 대해 다시 한번 생각해볼 필요가 있다.
물론 현재 기능의 동작 여부가 미래의 유연성보다 더 중요하지만 결국에는 변경 가능한 시스템이 더 큰 가치를 갖는 것이 아닐까?

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

우선 순위

1. 긴급하고 중요한
2. 긴급하지는 않지만 중요한 - 아키텍처
3. 긴급하지만 중요하지 않은 - 행위
4. 긴급하지도 중요하지도 않은

-> 업무 관리자는 중요도가 높은 아키텍처를 무시한 채 행위를 더 중요시 여기는 경향이 있다.
-> 소프트웨어 개발팀은 아키텍처의 중요성을 설득하는 일을 책임져야 한다.

아키텍처를 위해 투쟁하라!

• 개발팀에서는 회사에서 가장 중요하다고 스스로 믿는 가치에 투쟁해야 한다.
• 아키텍처가 후순위가 되면 시스템을 개발하는 비용이 더 많이 들고, 전체 시스템 변경을 가하는 일이 현실적으로 불가능해진다.
  • 이러한 상황이 발생하도록 용납하지 말자