아키텍트는 프로그래밍 작업을 놓아서는 안된다. 아키텍트는 프로그래밍 작업을 통해 발생하는 문제를 경험하고 프로그래머를 지원하는 역할을 해야 한다. 시스템 아키텍처의 목표는 시스템을 쉽게 개발하고 배포하고 운영하며 유지보수 되도록 만드는 것이다.
시스템 아키텍처는 시스템이 제대로 동작하기를 최우선 목표로 삼는 것은 당연하나 아키텍처가 엉망이더라도 시스템은 제대로 동작할 가능성이 크다. 사실상 아키텍처는 운영보다 배포, 유지보수, 개발을 쉽게 하는데에 초점이 맞춰져야 한다.
아키텍처의 주된 목적은 시스템의 생명주기를 지원하는 것이다. 좋은 아키텍처는 시스템을 쉽게 이해하고, 쉽게 개발하며, 쉽게 유지보수하고, 또 쉽게 배포하게 해준다. 아키텍처의 궁극적인 목표는 시스템의 수명과 관련된 비용은 최소화하고, 프로그래머의 생산성은 최대화하는 데 있다.
개발
시스템 아키텍처는 개발자 또는 개발팀이 쉽게 개발할 수 있도록 도움을 주어야 한다. 팀의 구성원이 5명 이하의 작은 팀이라면 별도의 컴포넌트 혹은 인터페이스 없이 모노리틱 시스템을 개발하는 것이 좋을 가능성이 높다. 그러나 여러 개발팀이 존재한다면 서로 다른 개발팀에 의존성을 가져가지 않기 위해서 안정된 인터페이스를 설계하고 별도의 컴포넌트로 시스템 아키텍처를 구성하는 것이 좋을 가능성이 크다.
배포
소프트웨어 아키텍처는 시스템을 단 한 번에 쉽게 배포할 수 있도록 만드는 데 그목표를 두어야 한다.
개발 초기 단계에는 주로 배포에 대해 고민하지 않기 때문에 개발하기는 쉬워도 배포하기는 어려운 아키텍처가 만들어진다. 개발 초기부터 마이크로 서비스로 계획하고 개발한다면 배포해야 할 때 각각의 서비스를 어떤 순서로 실행해야 하는지 결정하는 과정에서 문제를 겪을 가능성이 크다.
운영
처음에 말한 것처럼 아키텍처가 운영에 미치는 영향은 크지 않다. 대부분 운영에 좋은 아키텍처를 위해 인력을 투입하는 것보다 하드웨어에 자원을 투자하는 것이 저렴할 수 있다.
그러나 운영하기 쉽게 아키텍처를 가져간다면 개발자들은 시스템의 유스 케이스를 더 쉽게 이해하고 이는 개발과 유지보수에 큰 도움이 될 수 있다.
유지보수
소프트웨어 시스템에서 가장 비용이 많이 드는 곳이 유지보수다. 새로운 기능 추가 요건은 항상 발생하고 기존의 버그도 수정해야 한다. 유지보수에 큰 비용이 드는 것은 새로운 기능을 추가하거나 버그를 수정할 때 어느 부분에 수정 및 추가를 해야할지 찾는 과정이 필요하기 때문이다.
시스템을 컴포넌트로 분리하고 안정된 인터페이스를 두어 서로 격리한다면 미래에 추가될 기능에 대비할 수 있고 장애 발생 위험을 줄일 수 있다.
선택사항 열어 두기
소프트웨어를 부드럽게 유지하는 방법은 선택사항을 가능한 한 많이, 그리고 가능한 한 오랫동안 열어 두는 것이다.
중요하지 않은 결정들, 이 책에서 세부사항이라고 말하는 것들은 결정을 최대한 미루어야 한다. 그럼 세부사항에는 어떤 것들이 있을까?
- 입출력 장치
- 데이터베이스
- 웹 시스템
- 서버
- 프레임워크
- 통신 프로토콜
위의 요소들은 핵심적인 정책을 개발하는데 결정되지 않아도 되는 부분이다. 세부사항에 몰두하지 않은 채 고수준의 정책을 만들 수 있다면 세부사항의 결정을 오랫동안 미루고 연기할 수 있다. 그리고 이렇게 확보된 시간에 더 많이 각 요소들의 장단점을 고려하고 판단할 수 있다.
좋은 아키텍트는 결정되지 않은 사항의 수를 최대화한다.
