[Clean Architecture] 아키텍처란?

아키텍처란 단어는 중대한 결정과 심도 있는 기술적 기량을 떠올리게 한다.

소프트웨어 아키텍처는 기술적 성취의 정점에 서 있다. 이 소프트웨어 아키텍처를 결정하는 아키텍트에 대해 먼저 알아보자.

 

소프트웨어 아키텍트란?

• 무엇보다도 그들은 프로그래머이다. 앞으로도 계속 프로그래머이다.
• 아키텍트라면 코드에서 탈피하여 고수준의 문제에 집중해야한다는 말은 거짓
• 절대로 코드와 멀어져서는 안된다.
• 프로그래밍 작업을 계속할 뿐만 아니라 동시에 나머지 팀원들의 생산성을 극대화 할 수 있는 설계 방향을 이끌어낸다.

 

소프트웨어 아키텍처란?

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

• 시스템의 형태는 시스템을 컴포넌트로 분리하는 방법, 분할된 컴포넌트를 배치하는 방법, 컴포넌트의 의사소통 방식에 따라 달라진다.
• 그 방식은 시스템이 쉽게 개발, 배포, 운영, 유지보수되도록 만들어진다.
• 이를 위해 가능한 한 많은 선택지를, 가능한 한 오래 남겨두는 전략을 따라야 한다.(!!!)

 

소프트웨어 아키텍처의 목표

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

• 소프트웨어 아키텍처의 목표가 시스템을 제대로 동작하도록 만드는데 있다고 생각할 수 있다.
• 물론 이를 최우선 목표 중 하나로 지원해야한다.
• 하지만 시스템 아키텍처는 시스템의 동작 여부와는 거의 관련이 없다.
  - 형편없는 아키텍처도 잘 동작한다. 하지만 운영보다는 배포, 유지보수, 개발과정에서 어려움을 겪는다.
  - 아키텍처의 관점에는 능동적이거나 본질적이지 않고 수동적이며 피상적인 요소임.
• 아키텍처의 주된 목적은 시스템의 생명주기를 지원하는 것.
• 좋은 아키텍처는 쉽게 개발하며, 쉽게 유지보수하고, 쉽게 배포하게 해준다.

 

1 ) 개발

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

• 팀의 구조가 다르면 아키텍처 관련 결정에서도 차이가 난다.
• 규모가 작은 팀(5명 이하)의 경우 모놀리틱(monolithic)시스템을 개발할 수 있다.
  오히려 아키텍처 관련 제약들이 오히려 방해가 된다고 생각할 수 있다.
• 여러 팀이 한 시스템을 개발한다면, 안정된 인터페이스, 잘 설계된 컴포넌트로 분리하지 않으면 개발이 진척되지 않는다.
  (보통은 한 팀당 하나의 컴포넌트로 발전될 가능성이 크다.)

 

2 ) 배포

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

• 보통 초기 개발 단계에서는 배포 전략을 거의 고려하지 않음.
  이로인해 개발은 쉽지만 배포는 어려운 아키텍처가 만들어진다. (책의 마이크로서비스 케이스 참고)
• 만약 초기에 배포 문제와 관련하여 고민은 한다면 다양한 컴포넌트의 상호 융합을 위해 통합된 도구를 사용하여 관리할 수 있을 것이다.

 

3 ) 운영

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

• 아키텍처가 비효율적이라면 단순히 스토리지와 서버를 추가하는 것만으로도 제대로 동작가능할 때가 많다.
• 운영의 관점에서는 운영을 방해하는 아키텍처가 개발, 배포, 유지보수를 방해하는 아키텍처보다는 비용이 덜 든다는 뜻.
  (하드웨어는 값이 싸고, 인력은 비싸다)
• 하지만 운영에 있어서 아키텍처는 시스템을 운영하는 데 필요한 요구를 알려주는 알려주는 역할을 한다.
• 즉, 시스템 아키텍처가 개발자에게 시스템의 운영 방식을 잘 드러내 준다고 할 수 있다.
  유스케이스, 기능, 시스템의 필수 행위를 일급 엔티티로 격상시키고, 이들 요소가 개발자에게 주요 목표로 인식되도록 해야한다.

4 ) 유지보수

유지보수는 모든 측면에서 봤을 때 소프트웨어 시스템에서 비용이 가장 많이 든다. 하지만, 신중하게 아키텍처를 만들면 이 비용을 크게 줄일 수 있다.

• 새로운 기능은 끝도 없이 발생하고, 뒤따라 발생하는 결함은 피할 수 없고, 이를 위해 엄청난 인적 자원이 소모된다.
• 유지보수의 가장 큰 비용은 탐사(selunking)와 이로 인한 위험부담에 있음.
  • 탐사란, 소프트웨어를 파헤쳐서 어디를 고치는게 최선인지, 어떤 전략을 쓰는게 최적일지를 결정할 때 드는 비용을 말함.
  • 이러한 변경사항을 반영할 때 의도치 않은 결함이 발생할 가능성은 항상 존재하며 이로인한 위함부담 비용이 추가.
• 시스템을 컴포넌트로 분리하고, 안정된 인터페이스를 두어 서로 격리하여 이 비용을 최소화할 수 있음
  • 격리를 통해 미래에 추가될 기능에 대한 길을 밝혀 둘 수 있음.
  • 의도지 않은 장애 발생의 위험을 크게 줄일 수 있음 (둑과 같은 역할)

 

선택사항 열어 두기

내가 읽었던 내용중에 여태까지 가지고 있었던 편견을 쉽게 깨뜨려 버린 내용들이다.

어떤 종류의 시스템을 개발하던지간에 여러 고려요소들이 있겠지만 마음속에 품고 있어야할 것 같다.

 

• 소프트웨어가 가진 두가지 가치 (행위적 가치, 구조적 가치) 중에 구조적 가치가 더 중요한 의미를 가진다.
• 구조적 가치가 소프트웨어를 soft하게 만들어주기 때문이다.
• 소프트웨어를 만든 이유는 기계의 행위를 쉽게 변경하는 방법이 필요했기 때문이다.
  • 이러한 유연성은 시스템의 형태, 컴포넌트의 배치 방식, 컴포넌트 상호 연결 방식에 크게 의존.
• 선택사항을 가능한 한 많이, 오랫동안 열어 두는 것이 소프트웨어를 soft하게 유지하는 방법!

 

선택사항이란?

선택사항은 중요치 않은 세부사항을 이야기한다.

• 소프트웨어 시스템은 정책(policy)와 세부사항의 구성요소로 나눌 수 있다.
  • 정책 : 모든 업무 규칙과 업무 절차를 구체화
  • 세부사항 : 사람, 외부 시스템, 프로그래머가 정책과 소통할 때 필요한 요소.
• 세부사항은 정책이 가진 행위에 조금도 영향을 미치지 않는다.
• 세부사항 종류
  • 입출력 장치, 데이터베이스, 웹 시스템, 서버, 프레임워크, 통신 프로토콜 등
• 아키텍트의 목표는 정책을 가장 핵심요소로 식별하고, 세부사항은 정책에 무관하게 만들 수 있는 형태의 시스템을 구축하는데 있다.
  반드시 책에서 이에 관한 예시를 읽어보길...
• 이를 지킨다면 세부사항에 대한 결정을 미룰 수 있으며, 세부사항에 대한 더 많은 정보를 얻어 이를통한 제대로된 결정을 내릴 수 있다.

(장치독립성에 관한 케이스도 반드시 참고해보길 바랍니다.)

 

결론

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

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

 

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