05 아키텍처 (1)

15장. 아키텍처란?

소프트웨어 시스템의 아키텍처란 시스템을 구축했던 사람들이 만들어낸 시스템의 형태이다.

그 모양은 시스템을 컴포넌트로 분할하는 방법, 분할된 컴포넌트를 배치하는 방법, 컴포넌트가 서로 의사소통하는 방식에 따라 정해진다.

그리고 그 형태는 아키텍처 안에 담긴 소프트웨어 시스템이 쉽게 개발, 배포, 운영, 유지보수되도록 만들어진다.

 

이러한 일을 용이하게 만들기 위해서는 가능한 한 많은 선택지를, 가능한 한 오래 남겨두는 전략을 따라야 한다.

 

시스템 아키텍처는 시스템의 동작 여부가 아닌 배포, 유지보수가 원할하도록 해야한다.

아키텍처의 궁극적인 목표는 시스템의 수명과 관련된 비용은 최소화하고, 프로그래머의 생산성은 최대화하는 것이다.

 

개발

잘 정의된 컴포넌트나 인터페이스 없이 개발을 시작한다면,

각각의 팀마다 하나씩 '팀별 단일 컴포넌트' 아키텍처로 발전될 가능성이 높다.

그리고 이러한 아키텍처가 시스템을 배포, 운영, 유지보수하는 데 최적일 가능성은 거의 없다.

 

배포

배포 비용이 높을수록 시스템의 유용성은 떨어진다.

초기 개발 단계에서는 배포 전략을 거의 고려하지 않는다.

이로 인해 개발하기는 쉬워도 배포하기는 어려운 아키텍처가 만들어진다.

 

운영

운영에서 어려움을 겪는다면, 시스템 아키텍처에 영향을 주지 않고도 단지 하드웨어를 더 투입해서 해결할 수 있다.

아키텍처가 운영보단 배포와 유지보수 측면에서 더 중요하긴 하지만, 운영적인 측면에도 도움을 줄 수 있다.

시스템을 운영하는데 필요한 요소(유스케이스, 기능, 일급 엔티티 격상)들을 개발자에게 주요 목표로 인식하도록 하여, 시스템을 이해하기 쉽고 배포와 유지보수가 용이하도록 할 수 있다.

 

유지보수

유지보수는 소프트웨어 시스템에서 가장 비용이 많이 든다.

그 중 가장 큰 비용은 탐사와 이로 인한 위험 부담에 있다.

탐사란 기존 소프트웨어에 새로운 기능을 추가하거나 수정할 때, 개발 범위와 영향도를 파악하는 작업이다.

시스템을 컴포넌트로 분리하고, 안정된 인터페이스를 두어 서로 격리하면 이 비용을 크게 줄일 수 있다.

 

선택사항 열어 두기

소프트웨어를 만든 이유는 기계의 행위를 빠르고 쉽게 변경하기 위함이다.

하지만 이러한 유연성은 시스템의 형태, 컴포넌트의 배치 방식 및 상호 연결되는 방식에 크게 의존한다.

유연성을 극대화하기 위해서는 선택사항을 가능한 많이, 가능한 오랫동안 열어두어야 한다.

세부적인 결정은 언제든 내릴 수 있도록 특정 DB, 웹 서버, 프레임워크 등의 세부사항에 몰두하지 않고 고수준의 정책을 만들어야 한다.

 

장치 독립성

초기의 코드는 장치 종속적이었다. 다른 기기에서 동작하는 프로그램은 다시 만들어야 했다.

오늘날의 운영체제는 입출력 장치를 소프트웨어 함수로 추상화했고, 해당 서비스는 추상화된 단일 레코드 장치를 처리한다.

 

결론

좋은 아키텍트는 세부사항을 정책으로부터 신중하게 가려내고, 정책이 세부사항과 결합하지 않도록 엄격하게 분리한다.

세부사항에 대한 결정은 가능한 한 오랫동안 미룰 수 있는 방향으로 정책을 설계한다.

정책은 세부사항에 관한 어떠한 지식도 갖지 못하고, 세부사항에 의존하지 않게 된다.