[Architecture] 5부 아키텍처 : 15장 아키텍처란?

 

클린 아키텍처 책의 15부 "아키텍처란?"

부분은 본격적으로 훌륭한 아키텍처를 설계하는 방법을 설명하기 전에,

아키텍처 그 자체의 개념과 목표, 특징들을 정리하는 장이다.

​

여러 관점 (개발, 유지보수, 배포)에서 잘 설계된 아키텍처가 주는 이점들을 설명하고,

아키텍처의 요소를 정책과 세부사항으로 구분하여 구체적으로 어떤 목표를 달성해야 하는지 설명하고 있다.

​

​

​

​

​

​

​

​

​

1) 소프트웨어 아키텍처란 무엇인가?

​

소프트웨어 시스템의 아키텍처란

시스템을 구축했던 사람들이 만들어낸 시스템의 형태이다.

​

그 모양은

- 시스템을 컴포넌트로 분할하는 방법,

- 분할된 컴포넌트를 배치하는 방법,

- 컴포넌트가 서로 의사소통하는 방식

에 따라 정해진다.

​

​

그리고 그 형태는

아킨텍처 안에 담긴 소프트웨어 시스템이

쉽게 개발, 배포, 유지보수​되도록 만들어진다.

​

​

​

​

이러한 일을 용이하게 하기 위해, 소프트웨어 아키텍처는 가능한 많은 선택지를, 가능한 한 오래 남겨두는 전략을 따라야 한다.

​

​

​

소프트웨어 아키텍트는 일단 개발에 직접 참여한다.

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

아키텍트는 팀원들이 생산성을 극대화시킬 수 있는 설계를 하도록 방향을 이끌어주는 역할을 한다.

​

그리고 개발에 직접 참여하는데,

그 이유는 코드 작업을 직접 하면서 문제점을 경험해보지 않는다면 다른 프로그래머를 지원하는 작업을

제대로 할 수 없기 때문이다.

​

​

​

​

​

​

​

2) 소프트웨어 아키텍처의 본질적인 목표는 무엇일까?

​

​

우리는 소프트웨어의 아키텍처의 목표가 시스템의 정상적인 동작여부로 오해하기 쉽다.

물론 시스템의 정상적인 동작여부도 중요한 부분이지만, 이는 수동적이고 피상적인 목표이며

본질적인 목표가 아니다.

​

엉망인 소프트웨어 아키텍처에서도 시스템이 정상적으로 동작하는 경우도 많이 있다.

소프트웨어 아키텍처의 능동적이고 본질적인 목표는

시스템의 생명주기를 지원하는 것이다.

​

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

즉 시스템의 수명과 관련된 비용은 최소화하고, 프로그래머의 생산성을 최대화하는 데 있다.

​

​

​

​

​

​

개발

시스템 아키텍처는 개발팀이 시스템을 쉽게 개발할 수 있도록 뒷받침하여야 한다.

​

팀구조에 따라서 이러한 아키텍처의 형태에서도 차이가 난다.

​

예를 들어, 소규모의 팀에서는 잘 정의된 컴포넌트나 인터페이스가 없더라도,

서로 효율적으로 협력하여 모놀리틱 시스템을 개발 할 수 있다.

​

반면, 비교적 대규모의 팀에서 위와 같이 소규모의 팀에서와 같은 아키텍처 하에서 개발을 진행하게 된다면,

개발 속도가 늦어지고, 유지보수, 배포를 하는데 잘 설계되고 분리된 아키텍처가 아니라면 난관을 겪을 것이다.

​

즉 시스템을 신뢰할 수 있고 안정된 인터페이스를 갖춘,

잘 설계된 컴포넌트 단위로 분리하지 않으면 개발이 진척되지 않는다.

​

​

​

​

​

배포

​

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

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

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

​

안타깝게도, 시스템의 개발 초기 단계에서는

이러한 배포 전략을 세세히 고려하지 않는다.

이로 인해 개발하기 쉬울지는 몰라도, 배포하기는 상당히 어려운 아키텍처가 만들어지기도 한다.

​

예를 들어, 개발 초기에 마이크로 서비스 아키텍처를 사용한다고 결정한다면,

개발과 유지보수 관점에서는

컴포넌트 경계가 뚜렷해지고 인터페이스가 대체로 안정화되므로

시스템을 매우 쉽게 개발할 수 있다고 판단할 수 있다.

​

​

하지만 배포 관점에서 보면 다르다.

어마어마하게 연관된 많은 서비스를 배포해야하고,

심지어 배포 순서, 작동 순서를 결정하는 과정에서 자칫 잘못하면

오작동이 발생할 수 있어 배포에 대한 복잡도가 상당히 증가할 수 있다.

​

아키텍트가 배포 문제를 초기에 고려했다면,

더 적은 서비스를 사용하여 서비스 컴포넌트와 프로세스 수준의 컴포넌트를 융합하여

좀 더 통합된 도구를 사용하여 상호 연결을 관리했을 수 있다.

​

​

​

​

​

운영

시스템을 운영할 때 아키텍처가 맡는 또다른 역할이 있는데,

바로 좋은 소프트웨어 아키텍처는 시스템을 운영하는데 필요한 요구를 쉽게 이해할 수 있고 그것을 표현한다.

​

즉 시스템 아키텍처가 개발자에게 시스템의 운영방식을 잘 드러내준다는 것이다.

​

시스템 아키텍처는 유스케이스, 기능, 시스템의 필수 행위를 일급 엔티티로 격상시키고,

이들 요소가 개발자에게 주요 목표로 인식되도록 해야 한다.

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

​

​

​

​

​

​

유지보수

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

​

새로운 기능을 추가하거나 변경해야하는 요구사항이 지속적으로 쏟아지는데,

이러한 작업을 하다가 뒤따라서 발생하는 결함은 피할 수 없으며,

결함을 수정하는 데도 영향 범위 파악, 테스트, 배포 등등까지의 엄청난 인적 자원이 소모된다.

​

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

탐사란 기존 소프트웨어에 새로운 기능을 추가하거나 결함을 수정할 때,

소프트웨어를 파헤쳐서 어디를 고치는 게 최선인지,

그리고 어떤 전략을 쓰는게 최적일지 결정할 때 드는 비용이다.

​

이러한 변경사항을 반영할 때,

의도치 않은 결함이 발생할 가능성은 항상 존재하며,

그로 인한 위험 부담 비용이 추가된다.

​

​

위와 같은 상황을 막기 위해

우리는 아키텍처를 설계할 때, 시스템을 컴포넌트 단위로 분리하고

책임과 경계를 명확히 그어 서로 영향도를 낮출 수 있도록 격리시켜야 한다.

​

이를 통해 미래에 추가될 기능에 대한 길을 밝혀 둘 수 있고

의도치 않은 장애가 발생할 위험을 크게 줄일 수 있다.

​

​

​

​

​

​

​

선택사항 열어 두기

​

소프트웨어는 행위적 가치와 구조적 가치를 가진다.

여기서 소프트웨어를 부드럽게 만드는 것은 바로 이 구조적 가치이기 때문이고, 이 가치가 더 중요하다.

​

소프트웨어를 만든 이유는,

기계의 행위를 쉽고 빠르게 변경하기 위함이였다.

​

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

​

또한 소프트웨어를 부드럽게 유지하는 방법은

가능한 세부사항에 대한 선택사항을 가능한 한 많이, 또 오랫동안 열어두는 것이다.

​

​

이 부분에서 저자는 소프트웨어 시스테의 주요한 두 가지 구성요소로 "정책"과 "세부사항"에 대한 개념을 구분한다.

​

"정책" 요소는 모든 업무 규칙과 업무 절차를 구체화하고, 시스템의 진정한 가치가 살아있는 곳이다.

반면 "세부 사항"은 외부 시스템, 프로그래머가 정책과 소통할 때 필요한 요소지만,

"정책"이 가진 행위에는 전혀 영향을 미치지 않는다.

​

예를 들면 데이터베이스, 프레임워크, 웹 시스템, 서버, 통신 프로토콜 등이 "세부사항" 이라고 할 수 있다.

​

​

아키텍트의 목표는 시스템에서 "정책"을 가장 핵심적인 요소로 식별하고,

동시에 세부사항은 정책에 무관하게 만들 수 있는 형태의 시스템을 구축하는 데 있다.

이를 통해 세부사항에 대한 선택, 결정을 미루거나 연기할 수 있게 한다.

​

​

세부사항에 몰두하지 않은 채, 고수준의 정책을 만들 수 있다면,

데이터베이스 웹서버, 프레임워크와 같은 세부사항에 대한 결정을 오랫동안 미루거나 연길할 수 있다.

​

세부사항을 미룸으로써 얻는 장점은

세부사항을 선택하기까지에 대한 다양한 시도를 해돌 수 있는 선택지를 열어둘 수 있다.

​

예를 들어 다양한 데이터베이스를 후보로 두고 그 적용 가능성과 성능을 검토해 볼 수 있다.

웹 시스템, 웹 프레임워크, 심지어 웹 자체에 대해서도 마찬가지다.

​

좋은 아키텍트는 결저오디지 않은 세부 사항의 수를 최대화한다.

​

​

​

​

​

​

​

결론

​

잘 설계된 소프트웨어 아키텍처는 정책과 세부사항을 잘 분리한다.

고수준의 정책을 세부사항으로부터 신중하게 가려내고,

정책이 세부사항과 결합되지 않도록 엄격하게 분리하고 변경에 대한 영향도를 최소화한다.

​

이를 통해 정책은 세부사항에 대한 어떠한 지식도 갖지 않게 되며,

이는 어떠한 경우에도 정책이 세부사항에 의존하지 않게 된다.

​

좋은 아키텍트는 세부사항에 대한 결정을 가능한 오래 미룰 수 있는 방향으로

정책을 설계한다.

​

​

​

#소프트웨어아키텍처 #클린아키텍처 #아키텍트