아키텍처라는 단어는 권력과 신비로움을 연상케 한다.
소프트웨어 아키텍트는 프로그래머이며, 앞으로도 계속 프로그래머로 남는는다.
소프트웨어 아키텍트라면 코드에서 탈피하여 고수준의 문제에 집중해야 한다는 거짓말에 절대로 속아 넘어가서는 안 된다.
소프트웨어 시스템의 아키테처란 시스템을 구축했던 사람들이 만들어낸 시스템의 형태다.
이러한 일을 용이하게 만들기 위해서는 가능한 한 많은 선택지를, 가능한 한 오래 남겨두는 전략을 따라야 한다.
아키텍처의 주된 목적은 시스템의 생명주기를 지원하는 것이다.
개발하기 힘든 시스템이라면 수명이 길지도 않고 건강하지도 않을 것이다.
팀별 단일 컴포넌트 아키텍처가 시스템을 배포, 운영, 유지보수하는 데 최적일 가능성은 거의 없다. 그럼에도 여러 팀이 순전히 일정에만 쫓겨서 일한다면, 결국 이 아키텍처로 귀착될 것이다.
소프트웨어 시스템이 사용될 수 있으려면 반드시 배포할 수 있어야 한다.
배포 비용이 높을수록 시스템의 유용성은 떨어진다.
따라서 소프트웨어 아키텍처는 시스템을 단 한 번에 쉽게 배포할 수 있도록 만드는 데 그 목표를 두어야 한다.
만약 아키텍트가 배포 문제를 초기에 고려했다면 이와는 다른 결정을 내렸을 것이다.
더 적은 서비스를 사용하고, 서비스 컴포넌트와 프로세스 수준의 컴포넌트를 하이브리드 형태로 융합하며, 좀 더 통합된 도구를 사용하여 상호 연결을 관리했을 것이다.
아키텍처가 시스템 운영에 미치는 영향은 개발, 배포, 유지보수에 미치는 영향보다는 덜 극적이다.
운영에서 겪는 대다수의 어려움은 소프트웨어 아키텍처에는 극적인 영향을 주지 않고도 단순히 하드웨어를 더 투입해서 해결할 수 있다.
아키텍처가 개발자에게 시스템의 운영 방식을 자라 드러내 준다고 할 수 있다.
시스템 아키텍처는 유스케이스, 기능, 시스템의 필수 행위를 일급 엔티티로 격상시키고, 이들 요소가 개발자에게 주요 목표로 인식되도록 해야 한다.
이를 통해 시스템을 이해하기 쉬워지며, 따라서 개발과 유지보수에 큰 도움이 된다.
유지보수는 모든 측면에서 봤을 때 소프트웨어 시스템에서 비용이 가장 많이 든다.
주의를 기울여 신중하게 아키텍처를 만들면 이 비용을 크게 줄일 수 있다.
구조적 가치는 중요한 가치인데, 소프트웨어를 부드럽게 만드는 것이기 때문이다.
소프트웨어를 만든 이유는 기계의 행위를 빠르고 쉽게 변경하는 방법이 필요했기 때문이다.
이러한 유연성은 시스템의 형태, 컴포넌트의 배치 방식, 컴포넌트가 상호 연결되는 방식에 상당히 크게 의존한다.
아키텍트의 목표는 시스템에서 정책을 가장 핵심적인 요소로 식별하고, 동시에 세부사항은 정책에 무관하게 만들 수 있는 형태의 시스템을 구축하는 데 있다. 이를 통해 세부사항을 결정하는 일은 미루거나 연기할 수 있게 된다.
좋은 아키텍트는 결정되지 않는 사항의 수를 최대화한다.
오늘날의 운영체제는 입출력 장치를 소프트웨어 함수로 추상화했고, 해당 함수는 천공카드와 같은 단위 레코드를 처리한다.
프로그램은 운영체제의 서비스를 호출하고, 해당 서비스가 추상화된 단위 레코드 장치를 처리한다.
이제는 동일한 프로그램을 아무런 변경 없이도 카드에서 읽고 쓰거나 테이프에서 읽고 쓸 수 있게 되었다. 개방 폐쇄 원칙이 탄생한 순간이다.
장치 독립성이 지닌 가치는 굉장하다.
어떤 장치를 사용할지 전혀 모른 채, 그리고 고려하지 않고도 프로그램을 작성할 수 있었다.
그런 후 운영체제에게는 자기 테이프에 인쇄하도록 지시할 수 있었고, 이를 통해 수십만 장에 달하는 편지 양식을 인쇄할 수 있었다.
이 장에 포함된 두 가지 이야기는 소규모 사례이지만, 그 원칙은 아키텍트가 대규모 시스템에 적용할 수 있는 예이기도 하다.
좋은 아키텍트는 세부사항을 정책으로부터 신중하게 가려내고, 정책이 세부사항과 결합되지 않도록 엄격하게 분리한다. 이를 통해 정책은 세부사항에 관한 어떠한 지식도 갖지 못하게 되며, 어떤 경우에도 세부사항에 의존하지 않게 된다. 좋은 아키텍트는 세부사항에 대한 결정을 가능한 한 오랫동안 머물 수 있는 방향으로 정책을 설계한다.