[개발서적] 클린 아키텍처 1부 소개 - 내용 정리 및 요약

이번에는 로버트 C 마틴의 클린 아키텍처를 읽은 내용을 정리해보도록 하겠습니다. 개인적인 설명은 기울임으로 표시해두었으니, 읽으면서 참고하시면 될 것 같습니다.

 

 

 

 

1장. 설계와 아키텍처란?

---

[ 도입 ]

• 설계와 아키텍처의 정의
  • 아키텍처: 저수준의 세부사항과는 분리된 고수준의 무언가
  • 설계: 저수준의 구조 또는 결정사항
• 설계와 아키텍처의 관계
  • 설계와 아키텍처는 모두 소프트웨어 전체 설계의 구성요소임
  • 이 둘은 단절없이 이어지며, 이를 통해 대상 시스템의 구조를 정의함
  • 개별로 존재할 수 없으며 고수준에서 저수준으로 향하는 의사결정의 연속성만이 있음

이 부분에서 핵심은 "고수준에서 저수준으로 향하는 의사결정의 연속성만이 있음"이라는 부분이다. 저자가 다소 불친절하지만 엄청나게 많은 의미를 내포하고 있다. 이 문장이 어려운 이유는 "수준"에 대한 정의가 부족하기 때문인데, 수준이란 입/출력까지의 거리라고 뒤에서 나온다. 그러므로 고수준은 입/출력과 거리가 먼 비즈니스 영역(도메인 객체, 유스케이스 등), 저수준은 입/출력과 가까운 인프라 영역(HTTP, DB, Cache 등)이다. 그렇기에 "고수준에서 저수준으로 향하는 의사결정의 연속성만이 있음" 부분은 비즈니스 영역에 대한 결정 또는 개발이 된 후에 저수준 세부 사항을 결정해야 한다는 의미를 내포하고 있는 것이다.

 

 

 

[ 목표는? ]

• 소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고, 유지보수하는데 투입되는 인력을 최소화하는 것
• 설계 품질을 재는 척도는 고객의 요구를 만족시키는데 드는 비용을 재는 척도와 다를 바 없다.
• 이 비용이 낮을 뿐만 아니라, 시스템의 수명이 다할 때까지 낮게 유지할 수 있다면 좋은 설계임
• 새로운 기능을 출시할 때마다 비용이 증가한다면 이는 나쁜 설계임

마틴 파울러는 이와 관련해서 Design-Stamina Hypothesis(디자인-스태미너 가설)도 정리해두었다. 또한 리팩토링 관련 강연도 진행했는데, 여기서 소프트웨어 아키텍처가 중요한 이유는 경제성(Economics, 훨씬 더 많은 기능을 빠르게 구현하기 위함)이라고 설명했다.

관련된 영상의 내용은 다른 포스팅에 정리해두었으니 필요하면 참고하도록 하자.

 

 

 

[ 무엇이 잘못되었나? ]

• 현대의 개발자들은 훌륭하고 깔끔하게 잘 설계된 코드가 중요하다는 사실을 잊고 있음.
  • 새로 출시할 기능은 계속 있어서 당장 정리되지 않은 코드는 계속 정리되지 않고, 결국 생산성은 0을 향해 수렴하기 시작함
  • “지저분한 코드를 작성하면 단기간에는 빠르게 갈 수 있고, 장기적으로 볼 때만 생산성이 낮아진다”는 견해에 속기도 함
• 하지만 엉망으로 만드는 것은 항상 더 느리며, 소프트웨어 개발의 단순한 진리는 빨리 가는 유일한 방법은 제대로 가는 것
• 처음부터 재설계하는 것이 해답이라고 생각할 수 있지만, 자신을 과신한다면 재설계하더라도 원래의 프로젝트와 똑같이 엉망이 됨

 

 

 

[ 결론 ]

• 개발 조직이 할 수 있는 최고의 선택지는 소프트웨어 아키텍처의 품질을 심각하게 고민하기 시작하는 것
• 소프트웨어 아키텍처를 심각하게 고민하려면 좋은 소프트웨어 아키텍처가 무엇인지 이해해야 함
• 비용은 최소화하고 생산성은 최대화 할 수 있는 설계와 아키텍처를 갖는 시스템을 만드려면, 이러한 아키텍처가 지닌 속성을 알아야 함

 

 

 

 

2장. 두 가지 가치에 대한 이야기

---

[ 도입 ]

• 소프트웨어 개발자는 행위와 아키텍처라는 2가지 가치를 제공함
• 개발자는 두 가지 모두를 반드시 높게 유지하는 책임을 갖는데, 행위에만 집중하고 아키텍처는 배제함

 

 

[ 행위 ]

• 프로그래머는 이해관계자를 위해 수익을 창출하거나 비용을 절약하도록 함
• 이를 위해 이해관계자가 기능 명세서나 요구사항 문서를 구체화할 수 있도록 도움
• 그리고 이러한 코드를 작성하고, 요구사항을 위반하면 디버거를 열고 문제를 고침

 

 

[ 아키텍처 ]

• 소프트웨어가 가진 본연의 목적을 추구하려면 부드러워야 함(Soft, 변경이 쉬워야 함).
  • 즉, 이해관계자가 기능에 대한 생각을 바꾸면, 변경사항을 간단하고 쉽게 적용할 수 있어야 함
  • 이때 드는 어려움은 변경의 범위에 비례해야 하며, 형태와는 관련이 없어야 함
  • 새로운 요청사항이 발생할 때마다 변경이 점점 더 힘들어지는 이유는 시스템의 형태와 요구사항의 형태가 서로 맞지 않기 때문
• 즉, 문제는 아키텍처이며, 아키텍처가 특정 형태를 다른 형태보다 선호할수록, 새로운 기능을 이 구조에 맞추는 게 힘들어짐
• 따라서 아키텍처는 형태에 독립적이여야하며, 그럴수록 실용적임

결국 개발자는 이해관계자가 얘기하는 요구사항을 수행하는 개발의 역할과, 개발되는 소프트웨어를 변경하기 쉽게 만드는 2가지 책임을 진다는 의미이다. 2가지 모두 중요하며, 흔히 변경하기 쉬운 소프트웨어를 만드는 책임을 잊지만 신경써야 한다는 것이다. 

그리고 이를 위해서는 아키텍처가 형태에 독립적이여야 한다.

 

 

 

 

[ 더 높은 가치? ]

• 업무 관리자는 기능의 동작이 중요하다고 얘기하고, 개발자는 이에 동조하겠지만 이는 다음과 같이 반박할 수 있음
  • 완벽하게 동작하지만 수정이 아예 불가능한 프로그램을 내게 준다면, 이 프로그램은 요구사항이 변경될 때 동작하지 않게 되고, 결국 프로그램이 돌아가도록 만들 수 없다. 따라서 이러한 프로그램은 거의 쓸모가 없다.
  • 동작은 하지 않지만 변경이 쉬운 프로그램을 내게 준다면, 나는 프로그램이 동작하도록 만들 수 있고, 변경사항이 발생하더라도 여전히 동작하도록 유지보수할 수 있다. 따라서 이러한 프로그램은 앞으로도 계속 유용한 채로 남는다.
• 수정이 현실적으로 불가능한 시스템은 존재하는데, 변경에 드는 비용이 변경으로 창출되는 수익을 초과하는 경우임
• 기능 또는 설정 측면에서 많은 시스템이 이처럼 수정이 현실적으로 불가능해지는 상황에 빠짐
• 업무 관리자는 보통 아키텍처의 중요성을 평가할만한 능력을 겸비하지 못하므로 기능의 긴급성이 아닌 아키텍처의 중요성을 설득하는 일은 개발팀이 마땅히 책임져야함

 

 

 

 

[ 아키텍처를 위해 투쟁하라 ]

• 개발팀, 관리팀, 마케팅팀, 영업팀, 운영팀 등은 회사에서 가장 중요하다고 스스로 믿는 가치를 위해 투쟁함
  
• 효율적인 개발팀은 뻔뻔함을 무릅쓰고 다른 이해관계자들과 동등하게 논쟁하며 이러한 투쟁에서 정면으로 맞서 싸움
• 개발자는 소프트웨어를 안전하게 보호해야 할 책임이 있는데, 이는 우리의 역할과 책무 중 하나이며 고용된 이유 중 하나이기도 함
• 아키텍처가 후순위가 되면 시스템 개발 비용은 더 많이 들고, 일부 또는 전체 시스템에 변경을 가하는 일이 현실적으로 불가능해짐
• 이러한 상황이 발생하도록 용납했다면, 이는 결국 개발팀이 스스로 옳다고 믿는 가치를 위해 충분히 투쟁하지 않았다는 뜻임

 

 

 

 

 

 

 

위의 내용은 로버트 C 마틴의 클린 아키텍처 책을 읽고 정리한 내용입니다. 개인적인 설명은 기울임으로 표시해두었으니, 읽으면서 참고하시면 될 것 같습니다! 혹시 추가적인 의견 있으면 편하게 댓글 남겨주세요ㅎㅎ

 

 

 

관련 포스팅

1. 클린 아키텍처 1부 소개 - 내용 정리 및 요약
2. 클린 아키텍처 2부 벽돌부터 시작하기: 프로그래밍 패러다임 - 내용 정리 및 요약
3. 클린 아키텍처 3부 설계 원칙 - 내용 정리 및 요약
4. 클린 아키텍처 4부 컴포넌트 원칙 - 내용 정리 및 요약
5. 클린 아키텍처 5부 아키텍처 - 내용 정리 및 요약
6. 클린 아키텍처 6부 세부사항 - 내용 정리 및 요약