두 가지 가치에 대한 이야기
2. 두 가지 가치에 대한 이야기
모든 소프트웨어 시스템은 이해관계자에게 서로 다른 두 가지 가치를 제공
행위(behavior)와 구조(structure)
행위
소프트웨어의 첫 번째 가치는 바로 행위
이해관계자를 위해 기계에서 수익을 창출하거나 비용을 절약하도록 만든다.
많은 프로그래머가 이러한 활동이 자신이 해야 할 일의 전부라고 생각하고 믿는다.
하지만 그들은 틀렸다.
아키텍처
소프트웨어는 부드러움을 지니도록 만들어짐 (기계의 행위를 쉽게 변경할 수 있도록 하기 위해서)
변경하기 쉬워야 한다.
변경사항을 적용하는 데 드는 어려움은 변경되는 범위에 비례해야 하면 변경사항의 형태와는 관련이 없어야 한다.
소프트웨어 개발 비용의 증가를 결정짓는 주된 요인은 바로 이 변경사항의 범위와 형태의 차이에 있다.
그래서 개발 비용은 요청된 변경사항의 크기에 비례한다.
새로운 요청사항이 발생할 때마다 바로 인전의 변경사항을 적용하는 것보다 조금 더 힘들어지는데, 시스템의 형태와 요구사항의 형태가 서로 맞지 않기 때문
문제는 당연히 시스템의 아키텍처
아키텍처가 특정 형태를 다른 형태보다 선호하면 할수록, 새로운 기능을 이 구조에 맞추는 게 더 힘들어진다.
따라서 아키텍처는 형태에 독립적이어야 하고, 그럴수록 더 실용적이다.
더 높은 가치
기능와 아키텍처 중 어느 것의 가치가 더 중요한가?
- 완벽하게 동작하지만 수정이 아예 불가능한 프로그램 -> 요구사항이 변경되면 동작하지 않기 때문에 결국 프로그램이 돌아가지 않음 -> 쓸모 없음
- 동작은 하지 않지만 변경이 쉬운 프로그램 -> 동작하도록 만들 수 있고, 변경사항이 발생하더라도 여전히 동작하도록 유지보수 가능 -> 계속 유용함
아이젠하워 매트릭스
중요성과 긴급성에 관한 매트릭스
내겐 두 가지 유형의 문제가 있습니다. 하나는 긴급하며, 다른 하나는 중요합니다. 긴급한 문제는 중요하지 않으며, 중요한 문제는 절대 긴급하지 않습니다.
소프트웨어의 첫 번째 가치인 행위는 긴급하지만 매번 높은 중요도를 가지는 것은 아님
소프트웨어의 두 번째 가차인 아키텍처는 중요하지만 즉각적인 긴급성을 필요로 하는 경우는 절대 없음
- 긴급하고 중요한
- 긴급하지는 않지만 중요한
- 긴급하지만 중요하지 않음
- 긴급하지도 중요하지도 않음
업무 관리자와 개발자가 흔하게 저지르는 실수는 세 번째에 위치한 항목을 첫 번째로 격상시켜 버리는 일
기능의 긴급성이 아닌 아키텍처의 중요성을 설득하는 일은 소프트웨어 개발팀이 책임져야 한다.
아키텍처를 위해 투쟁하라
효율적인 소프트웨어 개발팀은 이러한 투쟁에서 정면으로 맞서 싸운다.
소프트웨어 개발자인 당신도 이해관계자임을 명심하라.
소프트웨어 아키텍트는 이러한 특성과 기능을 개발하기 쉽고, 간편하게 수정할 수 있으며, 확장하기 쉬운 아키텍처를 만들어야 한다.
아키텍처가 후순위가 되면 시스템을 개발하는 비용이 더 많이 들고, 일부 또는 전체 시스템에 변경을 가하는 일이 현실적으로 불가능
이러한 상황이 발생하도록 용납했다면, 소프트웨어 개발팀이 스스로 옳다고 믿는 가치를 위해 충분히 투쟁하지 않았다는 뜻
참조
- 클린 아키텍처(Clean Architecture)