15장. 아키텍처란?
Introduction
- 소프트웨어 아키텍처란 무엇인가? 소프트웨어 아키텍트는 무슨 일을 하며, 언제 그 일을 하는가?
- 무엇보다도 소프트웨어 아키텍트는 프로그래머이며, 앞으로도 계속 프로그래머로 남는다.
- 소프트웨어 시스템의 아키텍처란 시스템을 구축했던 사람들이 만들어낸 시스템의 형태
- 그 모양은 시스템을 컴포넌트로 분할하는 방법, 분할된 컴포넌트를 배치하는 방법, 컴포넌트가 서로 의사소통하는 방식에 따라 정해짐
- 그리고 그 형태는 아키텍처 안에 담긴 소프트웨어 시스템이 쉽게 개발, 배포, 운영, 유지보수되도록 만들어짐
이러한 일을 용이하게 만들기 위해서는 가능한 한 많은 선택지를, 가능한 한 오래 남겨두는 전략을 따라야 한다.
- 시스템 아키텍처는 시스템의 동작 여부와는 거의 관련이 없다.
- 그렇다고 해서 아키텍처가 시스템이 제대로 동작하도록 지원하는 데 아무런 역할을 하지 않는다는 말은 아님
- 아키텍처는 분명히 그런 역할을 하며, 이 역할은 대단히 중요함
- 하지만 이 역할은 수동적이며 피상적인 것이지, 능동적이거나 본질적인 것은 아님
- 아키텍처의 주된 목적은 시스템의 생명주기를 지원하는 것
- 좋은 아키텍처는 시스템을 쉽게 이해하고, 쉽게 개발하며, 쉽게 유지보수하고, 또 쉽게 배포하게 해줌
- 아키텍처의 궁극적인 목표는 시스템의 수명과 관련된 비용은 최소화하고, 프로그래머의 생산성은 최대화하는데 있음
개발
- 시스템 아키텍처는 개발팀(들)이 시스템을 쉽게 개발할 수 있도록 뒷받침해야만 한다.
- 팀 구조가 다르다면 아키텍처 관련 결정에서도 차이가 난다.
배포
- 소프트웨어 시스템이 사용될 수 있으려면 반드시 배포할 수 있어야 함
- 배포 비용이 높을수록 시스템의 유용성은 떨어짐
- 따라서 소프트웨어 아키텍처는 시스템을 단 한 번에 쉽게 배포할 수 있도록 만드는 데 그 목표를 두어야 함
운영
- 아키텍처가 시스템 운영에 미치는 영향은 개발, 배포, 유지보수에 미치는 영향보다는 덜 극적
- 운영에서 겪는 대다수의 어려움은 소프트웨어 아키텍처에는 극적인 영향을 주지 않고도 단순히 하드웨어를 더 투입해서 해결할 수 있음
- 소프트웨어 시스템의 아키텍처가 비효율적이라면 단순히 스토리지와 서버를 추가하는 것만으로 제대로 동작하도록 만들 수 있을 때가 많음
- 하드웨어는 값싸고 인력은 비싸다는 말이 뜻하는 바는 운영을 방해하는 아키텍처가 개발, 배포, 유지보수 쪽으로 더 기운다는 말
- 좋은 소프트웨어 아키텍처는 시스템을 운영하는 데 필요한 도구도 알려줌
- 시스템 아키텍처가 개발자에게 시스템의 운영 방식을 잘 드러내 준다고 할 수 있음
- 시스템 아키텍처는 유스케이스, 기능, 시스템의 필수 행위를 일급 엔티티로 격상시키고, 이들 요소가 개발자에게 주요 목표로 인식되도록 해야함
- 이를 통해 시스템을 이해하기 쉬워지며, 따라서 개발과 유지보수에 큰 도움이 됨
유지보수
- 유지보수는 모든 측면에서 봤을 때 소프트웨어 시스템에서 비용이 가장 많이 듦
- 유지보수의 가장 큰 비용은 탐사와 이로 인한 위험부담에 있음
- 탐사란 기존 소프트웨어에 새로운 기능을 추가하거나 결함을 수정할 때, 소프트웨어를 파헤쳐서 어디를 고치는게 최선인지, 그리고 어떤 전략을 쓰는게 최적일지를 결정할 때 드는 비용
- 이러한 변경사항을 반영할 때 의도치 않은 결함이 발생할 가능성은 항상 존재, 이로 인한 위험부담 비용이 추가됨
- 주의를 기울여 신중하게 아키텍처를 만들면 이 비용을 크게 줄일 수 있음
- 시스템을 컴포넌트로 분리하고, 안정된 인터페이스를 두어 서로 격리함
- 이를 통해 확장에는 열려있고, 의도치 않은 장애가 발생할 위험을 크게 줄일 수 있음
선택사항 열어 두기
- 소프트웨어를 부드럽게 만드는 것은 구조적 가치
- 소프트웨어를 만든 이유는 기계의 행위를 빠르고 쉽게 변경하는 방법이 필요했기 때문
- 이러한 유연성은 시스템의 형태, 컴포넌트의 배치 방식, 컴포넌트가 상호 연결되는 방식에 상당히 크게 의존함
- 소프트웨어를 부드럽게 유지하는 방법은 선택사항을 가능한 한 많이, 그리고 가능한 한 오랫동안 열어두는 것
- 그렇다면 열어 둬야 할 선택사항이란 무엇일까?
- 그것은 바로 중요치 않은 세부사항 detail 이다.
- 모든 소프트웨어 시스템은 주요한 두 가지 구성요소로 분해할 수 있다.
- 정책
- 모든 업무 규칙과 업무 절차를 구체화
- 시스템의 진정한 가치가 살아 있는 곳
- 세부사항
- 사람, 외부 시스템, 프로그래머가 정책과 소통할 때 필요한 요소
- 정책이 가진 행위에는 조금도 영향을 미치지 않음
- 입출력 장치, 데이터베이스, 웹 시스템, 서버, 프레임워크, 통신 프로토콜 등
- 아키텍트의 목표
- 시스템에서 정책을 가장 핵심적인 요소로 식별하고,
- 동시에 세부사항은 정책에 무관하게 만들 수 있는 형태의 시스템을 구축
- 이를 통해 세부사항을 결정하는 일은 미루거나 연기할 수 있게 됨
- 세부사항에 몰두하지 않은 채 고수준의 정책을 만들 수 있다면, 이러한 세부사항에 대한 결정은 오랫동안 미루거나 연기할 수 있음
- 이러한 결정을 더 오래 참을 수 있다면, 더 많은 정보를 얻을 수 있고, 이를 기초로 제대로 된 결정을 내릴 수 있음
- 또한 이를 통해 다양한 실험을 시도해볼 수 있는 선택지도 열어 둘 수 있음
- 선택사항을 더 오랫동안 열어 둘 수 있다면, 더 많은 실험을 해볼 수 있고, 더 많은 것을 시도할 수 있음
- 뛰어난 아키텍트라면 이러한 결정이 아직 내려지지 않은 것처럼 행동하며, 여전히 결정을 가능한 한 오랫동안 연기하거나 변경할 수 있는 형태로 시스템을 만든다.
좋은 아키텍트는 결정되지 않은 사항의 수를 최대화한다.
장치 독립성
- 예전의 코드는 장치 종속적
- 1960년대 후반에 이르러서야 장치 독립성을 생각해냄
광고 우편
물리적 주소 할당
- 시스템에서 고수준의 정책이 물리적 구조로부터 독립되도록 수정
- 물리적 구조에 대한 결정사항을 애플리케이션으로부터 분리할 수 있게 됨
요약
- 좋은 아키텍트는 세부사항을 정책으로부터 신중하게 가려내고, 정책이 세부사항과 결합하지 않도록 엄격하게 분리함
- 정책은 세부사항에 관한 어떠한 지식도 갖지 못하게 됨
- 어떤 경우에도 세부사항에 의존하지 않게 됨
- 좋은 아키텍트는 세부사항에 대한 결정을 가능한 한 오랫동안 미룰 수 있는 방향으로 정책을 설계함