15.아키텍처란
- 소프트웨어 시스템의 아키텍처란 시스템을 구축했던 사람들이 만들어낸 시스템의 형태이다.
- 그 모양은 시스템을 컴포넌트로 분할하는 방법, 분할된 컴포넌트를 배치하는 방법, 컴포넌트가 서로 의사소통하는 방식에 따라 정해진다.
- 이러한 일을 용이하게 만들기 위해서는 가능한 한 많은 선택지를, 가능한 한 오래 남겨두는 전략을 따라야 한다.
- 시스템 아키텍처는 시스템의 동작 여부와는 거의 관련 없다.
- 형편없는 아키텍처 시스템이라도 그런대로 동작한다.
- 이러한 시스템은 운영보다는 배포, 유지 보수, 계속되는 개발 과정에서 어려움을 겪는다.
- 아키텍처의 주된 목적은 시스템의 생명주기를 지원하는 것이다.
- 좋은 아키텍처는 시스템을 쉽게 이해하고, 쉽게 개발하며, 쉽게 유지 보수하고, 쉽게 배포하게 해준다.
- 아키텍처의 궁극적인 목표는 시스템의 수명과 관련된 비용은 최소화하고, 프로그래머의 생산성을 최대화하는데 있다.
- 개발하기 힘든 시스템은 수명이 짧고 건강하지 않다.
- 시스템 아키텍처는 개발팀이 시스템을 쉽게 개발할 수 있도록 뒷받침해야만 한다.
- 팀 구조가 다르다면 아키텍처 관련 결정에서 차이가 날 수 있다.
- 예를 들어 개발자 다섯 명으로 구성된 작은 팀이라면, 잘 정의된 컴포넌트나 인터페이스가 없더라도 서로 효율적으로 협력하여 모노리틱 시스템을 개발할 수 있다.
- 이러한 팀이라면 개발 초기에 오히려 아키텍처 관련 제약들이 방해가 된다고 여길 가능성이 있다.
- 수많은 시스템에서 좋은 아키텍처가 결여된 이유는 바로 이 때문이다.
- 이러한 팀은 아키텍처 없이 시작하는데, 팀 규모가 작은 데다가 상위 구조로 인한 장애물이 없기를 바라기 때문이다.
- 다른 한편으로, 일곱 명씩 다섯 팀이 시스템을 개발하고 있다면 시스템을 신뢰할 수 있고 안정된 인터페이스를 갖춘, 잘 설계된 컴포넌트 단위로 분리하지 않으면 개발이 진척되지 않는다.
- 배포 비용이 높을수록 시스템의 유용성이 떨어진다.
- 아키텍처는 시스템을 단 한 번에 쉽게 배포할 수 있도록 만드는데 그 목표를 두어야 한다.
- 초기 개발 단계에서 배포 전략을 고려하지 않는다면 개발하기는 쉬울지 몰라도 배포하기는 상당히 어려운 아키텍처가 만들어진다.
- 아키텍처가 시스템 운영에 미치는 영향은 개발, 배포, 유지 보수에 미치는 영향보다는 덜하다.
- 운영에서 겪는 대다수의 어려움은 단순히 하드웨어를 더 투입해서 해결할 수 있다.
- 하드웨어는 값싸고 인력은 비싸다. 운영을 방해하는 아키텍처가 개발, 배포, 유지 보수를 방해하는 아키텍처보다는 비용이 덜 든다.
유지 보수
- 유지 보수는 모든 측면에서 봤을 때 소프트웨어 시스템에서 비용이 가장 많이 든다.
- 새로운 기능은 끝도 없이 행진하듯 발생하고, 뒤따라서 발생하는 결함은 피할 수 없으며, 결함을 수정하는 데도 엄청난 인적 자원이 소모된다.
- 유지 보수에서 가장 큰 비용은 기존 소프트웨어에 새로운 기능을 추가하거나 결함을 수정할 때, 소프트웨어를 파헤쳐서 어디를 고치는 게 최선일지 찾는 일이다.
- 주의를 기울여서 신중하게 아키텍처를 만들면 일 비용을 크게 줄일 수 있다.
선택사항 열어두기
- 소프트웨어는 행위적 가치와 구조적 가치를 지닌다.
- 이 중에서 구조적 가치가 더 중요하다. 소프트웨어를 부드럽게(soft) 만드는 것은 바로 이 구조적 가치이기 때문이다.
- 소프트웨어를 부드럽게 유지하는 방법은 선택사항을 가능한 한 많이, 그리고 가능한 오랫동안 열어 두는 것이다.
- 그렇다면 열어 둬야 할 선택사항이란 무엇일까?
- 바로 중요치 않은 세부사항이다.
- 모든 소프트웨어 시스템은 주요한 두 가지 구성요소로 분해할 수 있다. 바로 정책과 세부사항이다.
- 정책이란 시스템의 진정한 가치이다.
- 세부사항은 사람, 외부 시스템, 프로그래머가 정책과 소통할 때 필요한 요소이지만, 정책이 가진 행위에는 영향을 미치지 않는다.
- 예를 들어 입출력 장치, 데이터베이스, 웹 시스템, 서버, 프레임워크, 통신 프로토콜 등이 있다.
- 아키텍트의 목표는 시스템에서 정책을 가장 핵심적인 요소로 식별하고, 동시에 세부사항은 정책에 무관하게 만들 수 있는 형태의 시스템을 구축하는 데 있다.
- 세부사항에 몰두하지 않은 채 고 수준의 정책을 만들 수 있다면, 이러한 세부사항에 대한 결정은 오랫동안 미루거나 연기할 수 있다.
- 현재 동작하는 고수준 정책이 있고, 이들 정책이 데이터베이스에 독립적이라면 다양한 데이터베이스를 후보로 두고 그 적용 가능성과 성능을 검토해 볼 수 있다.
- 웹 시스템, 프레임워크, 심지어 웹 자체에 대해서도 마찬가지이다.
- 선택사항을 더 오랫동안 열어 둘 수 있다면 더 많은 실험을 해볼 수 있고 더 많은 것들을 시도할 수 있다.
- 그리고 결정을 더 이상 연기할 수 없는 순간이 닥쳤을 때는 이러한 실험과 시도 덕분에 더 많은 정보를 획득한 상태일 것이다.
- 좋은 아키텍트는 결정되지 않은 사항의 수를 최대화한다.
- 좋은 아키텍트는 세부사항을 정책으로부터 신중하게 가려내고, 정책이 세부사항과 결합되지 않도록 엄격하게 분리한다.
- 이를 통해 정책은 세부사항에 관한 어떠한 지식도 갖지 못하게 되며, 어떤 경우에도 세부사항에 의존하지 않게 된다.
- 좋은 아키텍트는 세부사항에 대한 결정을 가능한 한 오랫동안 미룰 수 있는 방향으로 정책을 설계한다.