[Clean Architecture] 클린 아키텍처(아키텍처란?) - 12

아키텍처

아키텍처라는 단어는 권력과 신비로움을 연상케 한다.
SW 아키텍처는 기술적 성취의 정점에 서 있따.

그렇다면 SW 아키텍처란 무엇인가?

• SW 아키텍트 또한 프로그래머이다.
• 다른 프로그래머들의 생산성을 극대화할 수 있는 설계를 하도록 방향을 이끌어 준다.

시스템 아키텍처는 시스템의 동작 여부와는 관련이 없다.
형편없는 아키텍처를 갑춘 시스템도 잘 동작한다. 이러한 시스템들은 배포, 유지보수, 이어지는 개발 단계에서 어려움을 겪는다.
-> 아키텍처가 시스템이 제대로 동작하도록 지원하는 데는 아무런 역할을 하지 않는다는 말은 아니다.
아키텍처는 시스템의 생명주기를 지원한다.
좋은 아키텍처는 시스템을 쉽게 이해하고, 쉽게 개발하며, 쉽게 유지보수한다.

아키텍처의 주된 목적은 프로그래머의 생산성을 최대화하는 데 있다.

개발

개발하기 힘든 시스템이라면 수명도 짧고 건강하지 않을 것이다.
사실 팀 단위(5명)가 작다면, 잘 정의된 컴포넌트나 인터페이스가 없더라도 서로 효율적으로 협력하여 개발할 수 있다.
이러한 팀에서는 아키텍처 관련 제약들이 오히려 방해가 된다고 생각할 것이다.

반대로 총 다섯 팀이 시스템을 개발하고 있다면 안정된 인터페이스, 잘 설계된 컴포넌트 단위로 분리하지 않으면 개발이 진척되지 않는다.
다른 요소를 고려하지 않는다면 이 시스템의 아키텍처는 다섯개의 컴포넌트로 발전될 가능성이 높다.

배포

SW 시스템이 사용될 수 있으려면 반드시 배포할 수 있어야 한다.
배포 비용이 높을수록 시스템의 유용성은 떨어진다.
따라서 SW 아키텍처는 시스템을 단 한번에 배포할 수 있도록 만드는 데 목표를 두어야 한다.

하지만 개발 초기 단계에서는 배포 전략을 거의 고려하지 않는다.
이로 인해 개발은 쉽지만, 배포하기는 어려운 아키텍처가 만들어진다.

EX
개발 초기 단계에서 "MSA" 를 사용하자고 결정할 수 있다.

• 컴포넌트 경계가 뚜렷해지고
• 인터페이스가 대체로 안정화되므로
  시스템을 쉽게 개발할 수 있다고 판단했을지도 모른다.
  하지만 배포할 시기가 되면 너무 많은 마이크로서비스를 발견하게 될지도 모른다.
  서로를 연결하고 설정하고 순서를 결정하는 과정에서 오작동이 발생할 원천이 스며들 수도 있다.

IF) 배포 문제를 초기에 고려했다면 이와는 다른 결정을 내렸을 것이다.

운영

아키텍처가 시스템 운영에 미치는 영향은 "개발, 배포, 유지보수"에 비해 적다.
대다수의 어려움은 더 많은 하드웨어를 투입해서 해결할 수 있다.

• 아키텍처가 비효율 적이라면 -> 스토리지와 서버를 추가

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

유지보수

유지보수는 모든 측면에서 봤을 때 SW 시스템에서 비용이 가장 많이 든다.
새로운 기능은 끝도없이 생성되고, 그에 따른 결함도 피할 수 없으며, 결함을 수정하기 위한 인력이 소모된다.

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

• 기존 SW에 새로운 기능을 추가하거나 결함을 수정할 때, SW를 파헤쳐서 어디를 고치는 게 최선인지, 어떤 전략을 쓰는게 최적일지 결정할 때 드는 비용

선택사항 열어두기

SW의 두 종류의 가치 "행위적 가치, 구조적 가치"
SW를 부드럽게 만드는 것은 구조적 가치이다.

SW를 만든 이유는 기계의 행위를 빠르고 쉽게 변경하는 방법이 필요했기 때문이다.
하지만 이러한 유연성은 시스템의 형태, 컴포넌트의 배치 방식, 컴포넌트가 서로 연결되는 방식에 크기 의존한다.
그렇다면 열어둬야하는 선택사항은 무엇일까?
-> 중요치 않은 세부 사항

모든 SW 시스템은 주요한 2가지 구성요소로 분해할 수 있다.

• 정책
  • 모든 업무 규칙과 업무 절차를 구체화 한다
• 세부사항
  • 사람, 외부 시스템, 프로그래머가 정책과 소통할 때 필요한 요소
  • 하지만 정책이 가진 행위에는 조금도 영향을 미치지 않는다.
  • 이러한 세부 사항에는 입출력 장치, DB, 웹 시스템, 서버, 프레임워크 등

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

• 개발 초기에는 DB 시스템을 선택할 필요가 없다. 고 수준의 정책은 어떤 종류의 DB를 사용하는 지 신경쓰지 않는다. 신중한 아키텍트라면 관계형 DB인지 분산형인지, 계층형인지는 관련이 없도록 아키텍트를 설계해야 한다.

• 개발 초기에는 웹 서버를 선택할 필요가 없다. 고수준의 정책은 자신이 웹을 통해 전달된다는 사실을 알아서도 안된다. HTML, AJAX, JSF 같은 웹 개발 기술들에 대해 고수준의 정책이 전혀 알지 못하게 만들면, 프로젝트 후반까지는 어떤 종류의 웹 시스템을 사용할지 결정하지 않아도 된다. 심지어는 시스템을 웹을 통해 전송할 것인지조차도 결정할 필요가 없다.

• 개발 초기에는 REST를 적용할 필요가 없다. 고수준의 정책은 외부 세계로의 인터페이스에 대해 독립적이어야 하기 때문이다. 마이크로서비스 프레임워크 또는 SOA 프레임워크도 적용할 필요가 없다. 다시 한번 말하지만 고수준의 정책은 이러한 것들에 신경 써서는 안 된다.

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

요점

• 세부사항에 몰두하지 않은 고수준의 정책을 만들 수 있다면, 이러한 세부사항에 대한 결정을 오랫동안 미루거나 연기
• 이러한 결정을 늦게 할수록, 더 많은 정보를 얻고 제대로 된 결정을 내릴 수 있다.
  이를 통해 다양한 실험을 시도해볼 수 있는 선택지도 열어 둘 수 있다.
  현재 동작하고 있는 일부 고수준 정책이 있고, 이들 정책이 DB에 독립적이라면 다양한 DB를 후보로 두고 성능을 검토해 볼 수 있다.

이미 다른 누군가가 결정을 내렸다면?
또는 회사에서 특정 프레임워크, 웹 서버, DB에 기여해왔다면?
-> 그렇다 하더라도 최대한 결정하지 않는 것이 좋다.

결론

좋은 아키텍트는 세부사항을 정책으로부터 신중하게 가려내고, 정책이 세부사항과 결합되지 않도록 분리한다.
이를 통해 정책은 세부사항에 관한 어떤 지식도 갖지 못하며, 의존하지 않는다.