클린 아키텍처(Clean Architecture)

 

다음주부터 일하게 될 회사에서 클린 아키텍처에 대해서 공부하고 오면 좋겠다고 안내해주셨다.

(아래 관련 링크 첨부)

 

학원에서도 그렇고 혼자 공부할 때에도 아키텍처에 대해서는 자세히 공부하지 않았던 것 같다. 정보처리기사 공부를 할 때, 그리고 학점은행제 과정에서 소프트웨어공학 강의를 들을 때에는 용어가 많이 나왔지만 그래서 어떤게 좋은 아키텍처인지에 대해서는 정확히 배운 바가 없다.

 

회사에서 보내준 유튜브 링크는 클린코드로 유명한 로버트 C. 마틴(엉클밥이라고도 불림)의 1시간짜리 강의였다. 한국어 자막은 없지만 말을 천천히 정확하게 해주는 편이라 조금 집중하면 어느정도 알아들을 수 있고, 아래 한국어로 요약 번역해 놓은 블로그와 함께 보면 더 이해가 쉽다.

 

사실 지금까지는 코드를 짜고 실행하기에 급급해서 좋은 아키텍처, 좋은 코드에 대해서 큰 노력을 기울이지는 않았던 것 같다. 그래도 클린코드는 여기저기서 들은대로 최대한 간결하고 잘 알아볼 수 있게 짜기는 했지만 클린 아키텍처는 거의 신경을 못쓴 것 같다. 

 

특히 초반에 '너희 회사 아키텍처 뭐야?' 라고 물어봤을때 Java, Spring, Eclipse, MVC... 와 같은 것들을 대답하더라 하는 내용에 뜨끔했다. 사실 누가 나에게 니 프로젝트 아키텍처 뭐야? 라고 물어보면 뭐라고 대답해야 할 지 감이 안왔다. 강의를 다 본 뒤 생각해보니 저 질문 자체가 약간 이상하긴 하다. 

 

아키텍처는 “What the system does?”에 대한 대답이라고 볼 수 있다. 어떤 구조로 이루어졌는지, 어떤 데이터베이스 시스템을 사용하는지, 어떤 툴을 사용하는지에 대한 대답이 아니다. 

 

• 좋은 아키텍처는 툴과 프레임워크에 대한 결정사항으로 구성되지 않는다.
• 좋은 아키텍처는 툴과 프레임워크에 대한 결정사항을 최대한 뒤로 미룬다.
  (예를 들면 데이터베이스에 대한 결정사항, 웹 서버에 대한 결정 사항, 그리고, DI 프레임워크에 대한 결정사항 등등)

 

강의를 보는 내내 의문이 들었다. 그래서 뭐가 좋은 아키텍처인건데?

결론은 유스케이스였다. 으잉? 정보처리기사 공부할 때 항상 맨앞에 나와서 수학의정석 집합마냥 계속 공부했던 그 유스케이스?

 

이 강의에서는 이바 얍콥슨이 제시한 모델을 예로 들었고, 여기에는 세 가지 중요한 오브젝트가 있다.
- Entity : 앱과는 무관한 도메인과 관련된 비지니스 규칙들
- Boundary : 인터페이스
- Interactor : 앱과 관련된 규칙들. 즉, 개발하려는 앱에 필요한 Use Case 를 의미.

좋은 아키텍처는 UI 관련된 부분을 어플리케이션의 Appendix 처럼 취급한다.

따라서 필요에 따라 UI를 다른 형태 혹은 다른 프레임워크를 사용하도록 변경하는 것을 용이하게 한다.

 

그리고 나서 유스케이스로 시스템의 작동을 정리한 손그림 다이어그램들을 보여주며 아키텍처를 보여주는데 이부분은 강의를 참고하는 것이 좋을 것 같다. (유튜브 링크 39:05 부터)

 

강의를 다 봤지만 뭔가 찜찜하다. 그래서 유스케이스로 잘 정리하면 클린 아키텍처인가? 맨 앞에서 엉클밥은 좋은 아키텍처로 만들어진 시스템은 아키텍처를 봤을때 그 자체로 어떤 서비스를 하는 시스템인지 알 수 있어야 한다고 했다. ('이건 트레이딩 시스템이군!' 할 수 있도록) 

 

한시간 강의로는 설명하기 부족했던걸까? 왜 맨앞에 프로젝트 디렉토리를 쫙 보여줬던거지? 그 부분에서 클린 아키텍처가 적용되어 잘 다듬어진 결과물을 비교해서 보고싶은데...

 

그래서 클린아키텍처 책을 주문해서 참고하였다.

 

---

 

클린 아키텍처 - 로버트 C. 마틴 저, 송준이 옮김

 

1부. 소개

 

소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화하는 데 있다.

 

소프트웨어 아키텍처를 심각하게 고려할 수 있으려면 좋은 소프트웨어 아키텍처가 무엇인지 이해해야 한다. 비용은 최소화하고 생산성은 최대화 할 수 있는 설계와 아키텍처를 가진 시스템을 만들려면 이러한 결과로 이끌어줄 시스템 아키텍처가 지닌 속성을 알고 있어야 한다.

 

소프트웨어의 시스템은 이해관계자에게 서로 다른 두가지 가치를 제공하는데 행위와 구조가 그것이다.

여기서 행위는 기능, 구조는 아키텍처라고 생각할 수 있는데 둘 중 어떤 것이 중요하고 가치가 더 높을까?

저자에 따르면 소프트웨어의 첫 번째 가치인 행위는 긴급하지만 매번 높은 중요도를 가지는 것은 아니다. 반면 소프트웨어의 두번째 가치인 아키텍처는 중요하지만 즉각적인 긴급성을 필요로 하지 않는다.

 

아키텍처가 후순위가 되면 시스템을 개발하는 비용이 더 많이 들고, 일부 또는 전체 시스템에 변경을 가하는 일이 현실적으로 불가능해진다. 우리는 이러한 상황이 발생하지 않도록 투쟁해야 한다.

 

 

2부. 벽돌부터 시작하기: 프로그래밍 패러다임

 

구조적 프로그래밍은 제어흐름의 직접적인 전환에 부과되는 규율이다.

객체 지향 프로그래밍은 제어흐름의 간접적인 전환에 부과되는 규율이다.

함수형 프로그래밍은 변수 할당에 부과되는 규율이다.

 

이들 세 패러다임 모두 우리에게서 무언가를 앗아갔다. 각 패러다임은 우리가 코드를 작성하는 방식의 형태를 한정시킨다.

예전과 지금의 소프트웨어 규칙은 조금도 다르지 않다. 도구는 달라졌고 하드웨어도 변했지만 소프트웨어의 핵심은 여전히 그대로다.

소프트웨어, 즉 컴퓨터 프로그램은 순차, 분기, 반복, 참조로 구성된다. 그 이상도 이하도 아니다.

 

 

3부. 설계원칙

 

SRP : 단일 책임 원칙

OCP : 개방-폐쇄 원칙

LSP : 리스코프 치환 원칙

ISP : 인터페이스 분리 원칙

DIP : 의존성 역전 원칙

 

 

4부. 컴포넌트 원칙

컴포넌트

컴포넌트 응집도

컴포넌트 결합

 

5부. 아키텍처

소프트웨어 시스템의 아키텍처란 시스템을 구축했던 사람들이 만들어낸 시스템의 형태다. 그 모양은 시스템을 컴포넌트로 분할하는 방법, 분할된 컴포넌트를 배치하는 방법, 컴포넌트가 서로 의사소통하는 방식에 따라 정해진다.

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

이러한 일을 용이하게 만들기 위해서는 가능한 한 만은 선택지를, 가능한 한 오래 남겨두는 전략을 따라야 한다.

의외로 시스템 아키텍처는 시스템의 동작 여부와는 거의 관련이 없다. 형편없는 아키텍처를 갖춘 시스템도 그런대로 잘 동작하지만 운영보다는 배포, 유지보수, 계속되는 개발 과정에서 어려움을 겪는다.

 

물론 아키텍처가 시스템이 제대로 동작하는데 역할을 하고 그 역할도 중요하지만 아키텍처의 주된 목적은 시스템의 생명주기를 지원하는 것이다. 좋은 아키텍처는 시스템을 쉽게 이해하고, 쉽게 개발하며, 쉽게 유지보수하고, 쉽게 배포하게 해준다. 

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

 

소프트웨어를 부드럽게 유지하는 방법은 선택사항을 가능한 한 많이, 그리고 가능한 한 오랫동안 열어 두는 것이다. 열어 둬야 할 선택사항은 바로 중요치 않은 세부사항이다.

 

모든 소프트웨어 시스템은 주요한 두 가지 구성요소로 분해할 수 있다. 바로 정책과 세부사항이다. 

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

세부사항은 사람, 외부 시스템, 프로그래머가 정책과 소통할 때 필요한 요소지만, 정책이 가진 행위에는 조금도 영향을 미치지 않는다. 이러한 세부사항에는 입출력 장치, 데이터베이스, 웹 시스템, 서버, 프레임워크, 통신 프로토콜 등이 있다.

 

좋은 아키텍처는 다음을 지원해야 한다.

- 시스템의 유스케이스

: 시스템의 아키텍처는 시스템의 의도를 지원해야 한다는 뜻이다. 시제로 아키텍트의 최우선 관심사는 유스케이스이며, 아키텍처에서도 유스케이스가 최우선이다. 아키텍처는 반드시 유스케이스를 지원해야 한다.

- 시스템의 운영

: 시스템의 운영 지원 관점에서 볼 때 아키텍처는 더 실질적이며 덜 피상적인 역할을 맡는다. 아키텍처는 요구와 관련된 각 유스케이스에 걸맞은 처리량과 응답시간을 보장해야 한다. 

- 시스템의 개발

: 아키텍처는 개발환경을 지원하는 데 있어 핵심적인 역할을 수행한다.

콘웨이의 법칙에 따르면 시스템을 설계하는 조직이라면 어디든지 그 조직의 의사소통 구조와 동일한 구조의 설계를 만들어 낼 것이다.

- 시스템의 배포

 

 

 

 

---

<참고자료>

 

• 유튜브영상 : Robert C Martin - Clean Architecture

https://justwrite99.medium.com/%ED%81%B4%EB%A6%B0-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-%ED%8C%8C%ED%8A%B81-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-vs-%EB%8F%84%EB%A9%94%EC%9D%B8-236c7008ac83

Clean Architecture : Part 1 — Database vs Domain

 

https://www.youtube.com/watch?v=Nltqi7ODZTM 

 

 

• 블로그 설명 (번역)

https://justwrite99.medium.com/%ED%81%B4%EB%A6%B0-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-by-%EC%97%89%ED%81%B4-%EB%B0%A5-a6a917ff6afc

클린 아키텍처 by 엉클 밥

 

 

• 참고 도서 : 클린 아키텍처 - 로버트 C. 마틴 저, 송준이 옮김