[안드로이드] - 클린아키텍처 - 1

이전 블로그에선 아키텍처를 왜 알아야할까? 에 대해 알아봤다면

이번 블로그 글에선 아키텍처가 무엇인지 좀 더 깊게 알아보자.

 

 

아키텍처

소프트웨어 아키텍처란?

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

💡시스템을 구축한 사람은 소프트웨어 아키텍트이다.

그 모양은 시스템을 1. 컴포넌트로 분할하는 방법. 2. 분할된 컴포넌트를 배치하는 방법, 3. 컴포넌트가 서로 의사소통하는 방식에 따라 정해진다. 그리고 그 형태는 아키텍처 안에 담긴 소프트웨어 시스템이 쉽개 개발, 배포, 운영 유지보수 되도록 만들어진다.

 

이 정의에 놀랐을 수도 있다.

아마도 소프트웨어 아키텍처의 목표가 시스템을 제대로 동작하도록 만드는 데 있다고 생각하고 있었을 것이다.

 

물론 우리는 시스템이 제대로 동작하기를 바라며, 시스템 아키텍처는 이를 최우선 목표 중 하나로 지원해야 한다.

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

 

그렇다고 해서 아키텍처가 시스템이 제대로 동작하도록 지원하는 데 아무런 역할을 하지 않는다는 말은 아니다.

아키텍처는 분명히 그러한 역할을 하며, 이 역할은 대단히 중요하다.

 

하지만, 이 역할은 수동적이며 피상적인 것이지, 능동적이거나 본질적인 것은 아니다. 행위에 대해 시스템 아키텍처의 선택지가 설령 있더라도 매우 적다.

 

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

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

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

 

개발

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

따라서 시스템 아키텍처는 개발팀(들)이 시스템을 쉽게 개발할 수 있도록 뒷받침해야만 한다.

 

팀 구조가 다르다면 아키텍처 관련 결정에서도 차이가 난다.

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

수 많은 시스템에서 좋은 아키텍처가 결여된 이유는 바로 위 상황 때문이다.
팀 규모가 작고, 상위 구조로 인한 장애물이 없기를 바라기 때문이다.

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

다른 요소를 고려하지 않는다면 이 시스템의 아키텍처는 여러 개의 컴포넌트로(즉, 각 팀마다 하나씩) 발전될 가능성이 높다.

이러한 팀별 단일 컴포넌트 아키텍처가 시스템을 배포, 운영, 유지보수하는 데 최적일 가능성은 거의 없다.

그럼에도 여러 팀이 순전히 순전히 일정에만 쫓겨 일한다면, 결국 위와 같이 최적 상태가 아니게 될 것이다.

 

배포

배포 비용이 높을수록 시스템의 유용성은 떨어진다. 따라서 소프트웨어 아키텍처는 시스템을 단 한 번에 쉽게 배포할 수 있도록 만드는데 그 목표를 두어야 한다.

💡시스템 유용성(가용성)이란? 소프트웨어 프로덕트의 실제 사용 목표를 효과적이고 효율적으로 달성할 수 있는 정도이다.

안타깝지만 초기 개발 단계에서는 배포 전략을 거의 고려하지 않는다. 이로인해 개발하기는 쉬울지 몰라도 배포하기는 상당히 어려운 아키텍처가 만들어진다.

 

예시를 하나 들겠다.

개발 초기 단계에 개발자가 'MSA' 를 사용하자고 결정할 수 있다.
이 접근법을 사용하면 컴포넌트 경계가 매우 뚜렷해지고 인터페이스가 대체로 안정화되므로 시스템을 매우 쉽게 개발할 수 있다고 판단했을지도 모른다.

하지만, 배포할 시기가 되면 위협적일 만큼 늘어난 수많은 마이크로 서비스를 발견하게 될지도 모른다.
마이크로서비스들을 서로 연결하기 위해 설정하고 작동 순서를 결정하는 과정에서 오작동이 발생할 원천이 스며들 수 있기 때문이다.

만약 위 같은 상황을 초기에 고려했다면, 이와는 다른 결정을 내렸을 것이다.

 

더 적은 서비스를 사용하고, 서비스 컴포넌트와 프로세스 수준의 컴포넌트를 하이브리드 형태로 융합하며, 좀 더 통합된 도구를 사용하여 상호 연결을 관리 했을 것이다.

 

운영

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

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

 

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

 

비용 공식 관점에서 운영보다는 개발, 배포, 유지보수 쪽으로 더 기운다.

 

 

유지보수

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

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

 

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

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

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

 

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

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

 

 

추가

아키텍처를 설명하기 위해서 위에서 언급한 개발, 배포, 운영, 유지보수 이외에 더 있다.

• 선택사항 열어두기
• 장치 독립성
• 물리적 주소 할당

클린 아키텍처 책에서 언급한 저 세 이야기는 사례를 토대로 한 가지를 설명하고자 한다.

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