클린 아키텍처 1부. 소개

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

---

설계와 아키텍처

아키텍처는 저수준의 세부사항과는 분리된 고수준의 무언가를 말한다.(ex. 집의 구조)

설계는 저수준의 구조 또는 결정사항 등을 의미한다.(ex. 집 내부의 전등, 콘센트, 가구, 공간이나 방의 배치)

• 아키텍처와 설계는 모두 소프트웨어 전체 설계의 구성요소다.
• 이 둘은 단절 없이 이어지며, 이를 통해 대상 시스템의 구조를 정의한다.
• 개별로 존재할 수 없고 두 실제로 구분 짓는 경계는 뚜렷하지 않다.
• 고수준에서 저수준으로 향하는 의사결정의 연속성만이 있을 뿐임

 

좋은 소프트웨어 설계의 목표는?

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

 

무엇이 잘못되었나?

• 현대의 개발자는 자신의 능력을 과신하고 진실을 오인한다.
  • 바로 다음에 만들어야할 새로운 기능 때문에 이전에 작성한 코드를 정리하는 일이 없고, 결국 전체 코드가 엉망진창이 되어 생산성은 0을 향해 수렴한다.
  • “지저분한 코드를 작성하면 단기간에는 빠르게 갈 수 있고 장기적으로 볼 때만 생산성이 낮아진다”는 말에 속는다.
• 진실은 엉망으로 만들면 깔끔하게 유지할 때보다 항상 더 느리고 빨리가는 유일한 방법은 제대로 가는 것이다.
• 생산성이 감소되고 비용이 증가하는 현상을 되돌릴 수 있는 방법은 과신함을 버리고 자신이 작성한 코드를 책임지는 것이다.
• 자신을 과시한다면 재설계하더라도 원래의 프로젝트와 똑같이 엉망으로 내몰린다.

 

결론

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

 

 

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

---

• 모든 소프트웨어 시스템은 이해관계자에게 서로 다른 두가지 가치를 제공한다.
• 소프트웨어 개발자는 행위와 구조를 높게 유지해야하는 책임을 진다.
• 하지만 대체로 한 가지 가치에만 집중하고 나머지 가치는 배제한다. → 결국 소프트웨어 시스템이 쓸모없게 된다

행위

• 프로그래머는 이해관계자를 위해 기계가 수익을 창출하고 비용을 절약하도록 만들어야한다.
• 이를 위해 이해관계자가 기능 명세서나 요구사항 문서를 구체화할 수 있도록 돕는다.
• 기계가 이러한 요구사항을 위반하면 프로그래머는 디버거를 열고 문제를 고친다.
• 많은 프로그래머가 행위를 만드는 것이 자신이 해야할 일의 전부라고 생각한다.

 

아키텍처

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

 

더 높은 가치

• 소프트웨어가 동작하게 만드는 것 더 쉽게 변경할 수 있도록 하는 것 중 업무 관리자는 소프트웨어가 동작하게 만드는 것이 중요하다고 생각하고 개발자는 이에 동조한다. 이 의견을 다음과 같이 반박할 수 있다.
  • 완벽하게 동작하지만 수정이 불가능하다면, 요구사항이 변경될 때 동작하지 않게되고, 결국 프로그램이 돌아가도록 만들 수 없게된다. 따라서 이러한 프로그램은 거의 쓸모가 없다.
  • 동작은 하지 않지만 변경이 쉽다면, 변경사항이 발생하더라도 여전히 동작하도록 유지보수할 수 있다. 따라서 앞으로도 프로그램이 계속 유용한채로 남는다.
• 수정이 현실적으로 불가능한 시스템은 변경에 드는 비용이 변경으로 창출되는 수익을 초과하는 경우다.
• 업무 관리자는 보통 아키텍처의 중요성을 평가할 만한 능력을 겸비하지 못하기 때문에 아키텍처의 중요성을 설득하는 일은 개발팀이 마땅히 책임져야 한다.

 

아키텍처를 위해 투쟁하라

• 회사내에서 개발팀, 마케팅팀, 영업팀, 운영팀 등 각팀은 스스로 옳다고 믿는 가치를 위해 투쟁한다.
• 효율적인 소프트웨어 개발팀은 투쟁에서 정면으로 맞서 싸워야한다.
• 개발자는 소프트웨어를 안전하게 보호해야할 책임의 역할이 있으며 이것이 회사에 고용된 중요한 이유중 하나이다.
• 아키텍트는 기능을 쉽게 개발하고 간편하게 수정할 수 있는 확장하기 쉬운 아키텍처를 만들어야 한다.
• 아키텍처가 후순위가 되면 시스템을 개발하는 비용이 더 많이 들고, 일부 또는 전체 시스템에 변경을 가하는 일이 현실적으로 불가능해진다.
• 이러한 상황이 만들어졌다면, 개발팀이 스스로 옳다고 믿는 가치를 위해 충분히 투쟁하지 않았다는 것이다.

 

---

모든 내용은 [클린 아키텍처] 서적의 정리한 내용이며, 망나니 개발자님의 블로그에서 정리 방법을 참고했습니다.

클린 아키텍처: 소프트웨어 구조와 설계의 원칙 | 로버트 C. 마틴 - 교보문고

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