[Clean Architecture] 1장. 설계와 아키텍처란?

introduction

• 설계 (design) 과 아키텍처 (architecture) 의 차이는 무엇인가?
  • 둘 사이에는 차이가 없다. 아무런 차이가 없다.
• 이 책의 목적 중 하나는 설계와 아키텍처가 무엇인지 완전하게 정의하는 것
• 소프트웨어에서 저수준의 세부사항과 고수준의 구조 모두 소프트웨어 전체 설계의 구성요소
  • 이 둘은 단절 없이 이어진 직물과 같으며, 이를 통해 대상 시스템의 구조를 정의
  • 개별로는 존재할 수 없고, 실제로 이 둘을 구분 짓는 경계는 뚜렷하지 않음
  • 고수준에서 저수준으로 향하는 의사결정의 연속성만이 있을 뿐

목표는?

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

• 설계 품질을 재는 척도는 고객의 요구를 만족시키는 데 드는 비용을 재는 척도와 다름 없음
  • 이 비용이 낮을 뿐만 아니라 시스템의 수명이 다할 때까지 낮게 유지할 수 있다면 좋은 설계라고 말할 수 있음
• 새로운 기능을 출시할 때마다 비용이 증가한다면 나쁜 설계
• 좋은 설계란 이처럼 단순명료

사례 연구

• 매번 새로운 기능을 출시할 때마다 개발자의 수는 지속적으로 증가했지만, 코드 생산성은 수렴하는 것처럼 보이는 현상은 명백히 잘못되었다.
• 코드 라인당 비용이 증가 추세하는 것도 오래갈 수 없는 추세이다.
• 이러한 비용 곡선은 사업 모델의 수익을 엄청나게 고갈시키며, 회사의 성장을 멈추게 하거나 심지어는 완전히 망하게 만든다.

엉망진창이 되어 가는 신호

• 시스템을 급하게 만들거나, 결과물의 총량을 순전히 프로그래머 수만으로 결정하거나, 코드와 설계의 구조를 깔끔하게 만들려는 생각을 전혀 하지 않으면, 파국으로 치닫는 이 비용 곡선에 올라타게 된다.
• 개발자가 초인적인 노력을 기울이고, 잔업을 하며, 헌심한에도 불구하고 더 이상 진척이 없는 상황에 처하게 된다.
• 개발자의 노력은 기능 개발보다는 엉망이 된 상황에 대처하는 데 소모되기 시작
• 개발자들이 쏟은 노력의 가치가 결국 보잘 것 없게 된다.

경영자의 시각

• 출시별 월 인건비를 보게 된다면, 어떤 식으로 보든 우려의 대상임에는 틀림없다.

무엇이 잘못되었나?

• 개발자들은 “코드는 나중에 정리하면 돼. 당장은 시장에 출시하는 게 먼저야!” 라는 흔해 빠진 거짓말에 속는다.
  • 이렇게 속아 넘어간 개발자라면 나중에 코드를 정리하는 경우는 한 번도 없는데, 시장의 압박은 절대로 수그러들지 않기 때문이다.
  • ‘시장의 출시가 먼저’라는 생각을 하는 이유는 바로 뒤에 여러 무리의 경쟁자가 뒤쫓고 있고, 경쟁자보다 앞서 가려면 가능한 한 빠르게 달려야 하기 때문
  • 결국 개발자는 절대로 태세를 전환하지 않음
  • 개발자도 생산성을 유지할 수 있다고 자신의 능력을 과신함
• 개발자가 속는 더 잘못된 거짓말은 “지저분한 코드를 작성하면 단기간에는 빠르게 갈 수 있고, 장기적으로 볼 때만 생산성이 낮아진다”는 견해
• 엉망으로 만들면 깔끔하게 유지할 때보다 항상 더 느리다.
  • 시간 척도를 어떻게 보든지 관계없이 말이다.

빨리 가는 유일한 방법은 제대로 가는 것이다.

• 개발자는 처음부터 다시 시작하여 전체 시스템을 재설계하는 것이 해답이라고 생각할지도 모른다.
  • 현실은 장밋빛 기대와는 거리가 멀다.

자신을 과신한다면 재설계하더라도 원래의 프로젝트와 똑같이 엉망으로 내몰린다.

결론

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