[책 정리] 15장. 아키텍처란? - Clean Architecture

 

-

소프트웨어 아키텍트는 프로그래머이며, 앞으로 계속 프로그래머로 남는다.

소프트웨어 아키텍트라면 코드에서 탈피하여 고수준의 문제에 집중해야 한다는 거짓말에 절대로 속아 넘어가서는 안 된다.

소프트웨어 아키텍트는 코드와 동떨어져서는 안 된다.

다른 프로그래머만큼 코드를 많이 작성하지 않을 수도 있지만, 프로그래밍 작업에는 지속적으로 참여한다.

프로그래밍 작업을 계속하는 이유는, 발생하는 문제를 경험해보지 않는다면 다른 프로그래머를 지원하는 작업을 제대로 수행할 수 없기 때문이다.

 

 

-

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

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

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

 

 

-

시스템 아키텍처는 시스템의 동작 여부와는 거의 관련이 없다.

형편없는 아키텍처를 갖춘 시스템이 수없이 많지만, 그런대로 잘 동작한다.

이러한 시스템은 대체로 운영에서는 문제를 겪지 않는다.

운영보다는 배포, 유지보수, 계속되는 개발 과정에서 어려움을 겪는다.

 

 

-

아키텍처의 주된 목적은 시스템의 생명주기를 지원하는 것이다.

좋은 아키텍처는 시스템을 쉽게 이해하고, 쉽게 개발하며, 쉽게 유지보수하고, 또 쉽게 배포하게 해준다.

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

 

 

 

개발

 

-

규모가 작은 팀 하나가 개발을 할 경우 아키텍처가 오히려 개발을 지연시킨다고 여겨져 아키텍처 없이 시작하곤 하는데, 

이것이 좋은 아키텍처가 결여되는 이유이다.

 

 

-

여러 팀이 시스템을 개발한다면 시스템을 신뢰할 수 있고 안정된 인터페이스를 갖춘, 잘 설계된 컴포넌트 단위로 분리하지 않으면 개발이 진척되지 않는다.

 

 

 

배포

 

-

소프트웨어 시스템이 사용될 수 있으려면 반드시 배포할 수 있어야 한다.

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

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

 

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

따라서 개발하기는 쉽지만 배포하기는 어려운 아키텍처가 만들어지곤 한다.

 

예를 들어 개발 초기 단계에 개발자가 마이크로서비스 아키텍처(micro service architecture)를 사용하기로 결정하면..

배포시기가 되어 위협적일 만큼 늘어난 수많은 마이크로서비스를 발견하게 될지도 모른다.

 

 

 

운영

 

-

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

운영에서 겪는 대다수의 어려움은 소프트웨어 아키텍처에는 극적인 영향을 주지 않고도 단순히 하드웨어를 더 투입해서 해결할 수 있다.

 

 

-

하드웨어는 값싸고 인력은 비싸다라는 말이 뜻하는 바는 운영을 방해하는 아키텍처가 개발, 배포, 유지보수를 방해하는 아키텍처보다는 비용이 덜 든다는 뜻이다.

그렇더라도 시스템을 운영할 때 아키텍처가 맡는 또 다른 역할이 있다.

좋은 소프트웨어 이키텍처는 시스템을 운영하는 데 필요한 요구도 알려준다.

 

 

-

시스템 아키텍처는 유즈케이스, 기능, 시스템의 필수 행위를 일급(first-class) 엔티티로 격상시키고, 이들 요소가 개발자에게 주요 목표로 인식되도록 해야 한다.

이를 통해 시스템을 이해하기 쉬워지며, 따라서 개발과 유지보수에 큰 도움이 된다.

 

 

 

유지보수

 

-

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

새로운 기능은 끝도 없이 행진하듯 발생하고, 뒤따라서 발생하는 결함은 피할 수 없으며, 결함을 수정하는 데도 엄청난 인적 자원이 소모된다.

 

 

-

유지보수의 가장 큰 비용은 탐사(spelunking)와 이로 인한 위험부담에 있다.

탐사란 기존 소프트웨어에 새로운 기능을 추가하거나 결함을 수정할 때, 소프트웨어를 파헤쳐서 어디를 고치는 게 최선인지, 그리고 어떤 전략을 쓰는게 최적일지를 결정할 때 드는 비용이다.

이러한 변경사항을 반영할 때 의도치 않은 결함이 발생할 가능성은 항상 존재하며, 이로 인한 위험부담 비용이 추가한다.

 

주의를 기울여 아키텍처를 만들면 이 비용을 크게 줄일 수 있다.

 

 

 

선택사항 열어 두기

 

-

소프트웨어는 두 종류의 가치, 즉 행위적 가치와 구조적 가치를 지닌다.

이 중에서 두 번째 가치가 더 중요한데, 소프트웨어를 부드럽게 만드는 것은 바로 이 구조적 가치이기 떄문이다.

소프트웨어를 만든 이유는 기계의 행위를 빠르고 쉽게 변경하는 방법이 필요했기 때문이다.

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

 

 

-

소프트웨어를 부드럽게 유지하는 방법은 선택사항을 가능한 한 많이 그리고 가능한 한 오랫동안 열어 두는 것이다.

열어 둬야 할 선택사항이란 바로 중요치 않은 세부사항(detail)이다.

 

 

-

모든 소프트웨어 시스템은 주요한 두 가지 구성요소로 분해할 수 있다.

바로 정책(policy)과 세부사항이다.

 

정책 요소는 모든 업무 규칙과 업무 절차를 구체화한다.

정책이란 시스템의 진정한 가치가 살아 있는 곳이다.

 

세부사항은 사람, 외부 시스템, 프로그래머가 정책과 소통할 때 필요한 요소지만,정책이 가진 행위에는 조금도 영향을 미치지 않는다.

이러한 세부사항에는 입출력 장치, 데이터베이스, 웹 시스템, 서버, 프레임워크, 통신 프로콜 등이 있다.

 

 

-

아키텍트의 목표는 시스템에서 정책을 가장 핵심적인 요소로 식별하고, 동시에 세부사항은 정책에 무관하게 만들 수 있는 형태의 시스템을 구축하는 데 있다.

이를 통해 세부사항을 결정하는 일은 미루거나 연기할 수 있게 된다.

 

 

-

고수준의 정책은 어떤 데이터베이스를 사용하는지 신경 써서는 안 된다. (개발 초기에는 db 시스템을 선택할 필요가 없다.)

신중한 아키텍트라면 고수준의 정책을 db 가 관계형인지, 분산형인지, 계층형인지, 플랫 파일인지 관련없도록 만든다.

 

고수준의 정책은 자신이 웹을 통해 전달된다는 사실을 알아서는 안 된다. (개발 초기에는웹 서버를 선택할 필요가 없다.)

HTML, AJAX, JSF 같은 웹 개발 기술들에 대해 고수준의 정책이 전혀 알지 못하게 만들면 프로젝트 후반까지는 어떤 종류의 웹 시스템을 사용할지를 결정하지 않아도 된다.

 

고수준의 정책은 외부 세계로의 인터페이스에 대해 독립적이어야 한다. (개발 초기에 REST 를 적용할 필요가 없다.)

 

고수준의 정책은 의존성을 해석하는 방식에 대해 신경 써서는 안 된다. (개발 초기에는 의존성 주입(DI)프레임워크를 적용할 필요가 없다.)

 

 

-

뛰어난 아키텍트라면 특정 db, 특정 웹 서버, 특정 프레임워크가 이미 결정된 상태에서 개발을 시작한다고 해도, 결정이 내려지지 않은 것처럼 행동하며, 여전히 결정을 가능한 한 오랫동안 연기하거나 변경할 수 있는 형태로 시스템을 만든다.

 

"좋은 아키텍트는 결정되지 않은 사항의 수를 최대화한다."

 

 

 

장치 독립성

 

-

장치 독립성(device independence)에 의해 오늘날의 운영체제는 입출력 장치를 소프트웨어 함수로 추상화했다.

프로그램은 운영체제의 서비스를 호출하고, 해당 서비스가 추상화된 단위 레코드 장치를 처리한다

그리고 오퍼레이터가 해당 추상 서비스를 카드 판독기, 자기 테이프, 아니면 또 다른 단위 레코드 장치 중 어디에 연결해야 하는지를 운영체제에게 알려준다.

 

이제는 동일한 프로그램을 아무런 변경 없이 카드에서 일고 쓰거나 테이프에서 읽고 쓸 수 있게 되었다.

 

 

 

광고 우편

 

 

 

물리적 주소 할당

 

 

 

결론

 

-

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

이를 통해 정책은 세부사항에 관한 어떠한 지식도 갖지 못하게 되며, 어떤 경우에도 세부사항에 의존하지 않게 된다.

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