클린 아키텍처 도서 요약 내용입니다.

15장 아키텍처란?

아키텍처라는 단어는 권력과 신비로움을 연상케 한다. 소프트웨어 아키텍트를 생각할 때면, 권한을 가지며 존경심을 불러일으키는 사람을 떠올린다.

그러면 소프트웨어 아키텍처란 무엇인가? 무슨일을 하며, 그 일은 언제 하는가?

무엇보다도 소프트웨어 아키텍트는 프로그래머이며, 앞으로도 계속 프로그래머로 남는다. 소프트웨어 아키텍트라면 코드에서 탈피하여 고수준의 문제에 집중해야 한다는 거짓말에 절대로 속아 넘어가서는 안된다. 소프트웨어 아키텍트는 코드와 동떨어져서는 안된다. 소프트웨어 아키텍트는 최고의 프로그래머이며, 앞으로도 계속 프로그래밍 작업을 맡을 뿐만 아니라 동시에 나머지 팀원들이 생산성을 극대화할 수 있는 설계를 하도록 방향을 이끌어준다. 프로그래밍 작업을 계속 하는 이유는, 발생하는 문제를 경험해보지 않는다면 다른 프로그래머를 지원하는 작업을 제대로 수행할 수 없기 때문이다.

시스템 아키텍처는 시스템의 동작여부와는 거의 관련이 없다. 형편없는 시스템들은 대체로 운영에서는 문제를 겪지 않는다. 운영보다는 배포, 유지보수, 계속되는 개발 과정에서 어려움을 겪는다.

좋은 아키텍처는 시스템을 쉽게 이해하고, 쉽게 개발하며, 쉽게 유지보수하고, 또 쉽게 배포하게 해준다. 아키텍처의 궁극적인 목표는 시스템의 수명과 관련된 비용은 최소화하고, 프로그래머의 생산성을 최대화 하는데 있다.

개발

개발하기 힘든 시스템이라면 수명이 길지도 않고 건강하지도 않을 것이다.

팀 구조가 다르다면 아키텍처 관련 결정에서도 차이가 난다. 일례로 팀이 개발자 다섯 명으로 구성될 정도로 작다면, 잘 정의된 컴포넌트나 인터페이스가 없더라도 서로 효율적으로 협력하여 모노리틱 시스템을 개발할 수 있다. 사실 이러한 팀이라면 개발 초기에는 아키텍처 관련 제약들이 오히려 방해가 된다고 여길 가능성이 높다.

다른 한편으로 일곱 명씩으로 구성된 다섯 팀이 시스템을 개발하고 있다면 시스템을 신뢰할 수 있고 안정된 인터페이스를 갖춘, 잘 설계된 컴포넌트 단위로 분리하지 않으면 개발이 진척되지 않는다. 다른 요소를 고려하지 않는다면 이 시스템의 아키텍처는 다섯 개의 컴포넌트로 발전될 가능성이 높다.

각각 5개의 컴포넌트가 일정에 쫓겨 최적의 상태가 될 가능성은 거의 없다. (배포, 운영, 유지보수)

배포

소프트웨어 아키텍처는 시스템을 단 한 번에 쉽게 배포할 수 있도록 만드는데 그 목표를 두어야 한다.

예를 들어 개발 초기에 개발자가 '마이크로서비스 아키텍처'를 사용하자고 결정할 수도 있다. 이렇게 되면 컴포넌트 경계가 매우 뚜렷해지고 인터페이스가 대체로 안정화되므로 시스템을 쉽게 개발할 수 있을 것이다. 하지만 배포를 하기 위해 설정 및 작동순서를 결정하는 과정에서 오작동이 발생할 가능성이 있다.

운영

아키텍처가 시스템 운영에 미치는 영향은 개발, 배포, 유지보수에 미치는 영향보다는 덜 극적이다.

소프트웨어 시스템의 아키텍처가 비효율적이라면 단순히 스토리지와 서버를 추가하는 것만으로 제대로 동작하게 만들 수 있다. 하드웨어는 싸고 인력은 비싸다는 말이 있듯이 운영을 방해하는 아키텍처가 개발, 배포, 유지보수를 방해하는 아키텍처보다는 비용이 덜 든다는 뜻이다.

유지보수

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

유지보수의 가장 큰 비용은 탐사(spelunking)와 이로 인한 위험부담에 있다. 탐사란 기존 소프트웨어에 새로운 기능을 추가하거나 결함을 수정할 때 소프트웨어를 파헤처서 어디를 고치는게 최선인지, 어떤 전략을 쓰는게 최적일지를 결정할 때 드는 비용이다. 이러한 변경사항을 반영할 때 의도치 않게 결함이 발생할 가능성은 항상 존재한다.

시스템을 컴포넌트로 분리하고, 안정된 인터페이스를 두어 서로 격리한다. 이를 통해 미래에 추가될 기능에 대한 길을 밝혀 둘 수 있을 뿐만 아니라 의도치 않게 장애가 발생할 위험을 크게 줄일 수 있다.

선택사항 열어 두기

소프트웨어는 두 종류의 가치, 즉 행위적 가치와 구조적 가치를 가진다. 이 중 두번째 가치가 더 중요한데 소프트웨어를 부드럽게 만드는 것은 바로 이 구조적 가치이기 때문이다.

소프트웨어를 부드럽게 유지하는 방법은 선택사항을 가능한 한 많이, 그리고 가능한 한 오랫동안 열어 두는 것이다. 그렇다면 열어둬야 할 선택사항이란 무엇일까? 그것은 바로 중요치 않은 세부사항(detail)이다.

모든 소프트웨어 시스템은 주요한 두가지 구성요소로 분해할 수 있다. 바로 정책과 세부사항이다. 정책요소는 모든 업무 규칙과 업무 절차를 구체화한다. 정책이란 시스템의 진정한 가치가 살아 있는 곳이다.

세부사항은 사람, 외부 시스템, 프로그래머가 정책과 소통할 때 필요한 요소지만, 정책이 가진 행위에는 조금도 영향을 미치지 않는다. 이러한 세부사항에는 입출력장치, 데이터베이스, 웹 시스템, 서버, 프레임워크, 통신 프로토콜이 있다.

아키텍트의 목표는 시스템에서 정책을 가장 핵심적인 요소로 식별하고, 동시에 세부사항은 정책에 무관하게 만들 수 있는 형태의 시스템을 구축하는데 있다. 이를 통해 세부사항을 결정하는 일은 미루거나 연기할 수 있게 된다.

개발 초기에는 데이터베이스 시스템을 선택할 필요가 없다. 신중한 아키텍트라면 고수준의 정책을 데이터베이스가 관계형인지, 분산형인지, 계층형인지 관련이 없도록 만들어야 한다.
개발 초기에는 웹 서버를 선택할 필요가 없다.
개발 초기에는 REST를 적용할 필요가 없다. 고수준의 정책은 외부 세계로의 인터페이스에 대해 독립적이어야 하기 때문이다.
개발 초기에는 의존성 주입 프레임워크를 적용할 필요가 없다.