클린 아키텍처: 소프트웨어 구조와 설계의 원칙 - 01

로머트 C. 마틴의 Clean Architecture 책을 읽고 정리한 내용입니다.

 

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

---

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

 

[목표는?]

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

 

[사례 연구]

• 실제 데이터로 보는 사례
  • 주요 소프트웨어 출시 때마다 엔지니어링 직원 수가 꾸준히 증가
  • 하지만 동일한 기간의 생산성은 한 곳으로 수렴하는 것처럼 보임
  • 동일한 기간의 코드 라인당 비용도 엄청난 상승
  • 이러한 비용 곡선은 사업 모델의 수익을 엄청나게 고갈시키며, 회사의 성장을 멈추게 하거나 심지어는 완전히 망하게 만듬
  • 이는 엉망진창이 되어 가는 신호
• 토끼와 거북이
  • 토끼는 타고난 빠르기를 과신한 나머지 경주를 심각하게 받아들이지 않아 낮잠을 자버리고, 거북이에게 패배
  • 토끼 개발자
    • 잠을 자는 것이 아니라 뼈 빠지게 일하지만 훌륭하고 깔끔하게 잘 설계된 코드가 중요하다는 사실을 알고 있는 뇌가 잠자고 있다.
    • 절대 수그러들지 않는 시장의 압박에 시장 출시가 먼저라며 코드 정리를 미룬다.
    • 토끼가 빠르기를 과신한 것처럼 생산성을 유지할 수 있다고 과신한다.
    • '지저분한 코드를 작성하면 빠르게 갈 수 있고 장기적으로 볼 때만 생산성이 낮아진다.라는 거짓말에 속는다.
• 소프트웨어의 단순한 진리
  • 빨리 가는 유일한 방법은 제대로 가는 것이다.
  • 자신을 과신한다면 재설계하더라도 원래의 프로젝트와 똑같이 엉망으로 내몰린다.

 

[결론]

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

 

 

 

 

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

---

• 이해관계자의 두 가지 가치
  • 소프트웨어 시스템은 행위(behavior)와 구조(structure)라는 두 가지 가치를 이해관계자에게 제공
  • 소프트웨어 개발자는 두 가치 모두 반드시 높게 유지해야 하는 책임을 짐
  • 하지만 한 가치 가치에만 집중하고 나머지 가치는 배제하곤 함. 결국에는 시스템이 쓸모없게 되버림

 

[행위]

• 프로그래머를 고용하는 이유
  • 이해관계자를 위해 기계가 수익을 창출하거나 비용을 절약하도록 만들기 위함
  • 이해관계자가 기능 명세서나 요구사항 문서를 구체화할 수 있도록 도움
  • 이해관계자의 기계가 이러한 요구사항을 만족하도록 코드를 작성
  • 만약 기계가 요구사항을 위반한다면, 디버거를 열고 문제를 고침
  • 많은 프로그래머가 이러한 활동이 전부라고 생각하지만 그들은 틀렸음.

 

[아키텍처]

• 소프트웨어란?
  • 부드러운(soft)와 제품(ware)이라는 단어의 합성어
• 소프트웨어의 본연의 목적
  • 반드시 부드러워야 하며 변경하기 쉬워야 한다.
  • 변경사항을 적용하는 데 드는 어려움은 변경되는 범위(scope)에 비례해야 하며, 변경사항의 형태(shape)와는 관련이 없어야 한다.
• 소프트웨어 개발 비용 증가의 주된 요인
  • 변경사항의 범위와 형태의 차이에 있음
  • 개발 비용은 요청된 변경사항의 크기에 비례
  • 시스템의 형태와 요구사항의 형태가 서로 맞지 않으면 새로운 요청사항이 발생할 때마다 조금 더 힘들어짐
• 문제의 원인
  • 시스템의 아키텍처가 문제
  • 아키텍처가 특정 형태를 다른 형태보다 선호하면 할수록, 새로운 기능을 이 구조에 맞추는 게 더 힘들어 짐
  • 따라서 아키텍처는 형태에 독립적이어야 하고, 그럴수록 더 실용적

 

[더 높은 가치]

• 동작하는 프로그램 vs 변경이 쉬운 프로그램
  • 업무 관리자에게 묻는다면 동작하는 것이 더 중요하다고 얘기하며, 개발자는 대체로 동조하는 태도를 취함
  • 아래와 같은 양 극단의 사례를 검토하는 방식으로 반박가능
    • 완벽하게 동작하지만 수정이 불가능하다면 프로그램의 요구사항 변경 시 동작하지 않게 되고 결국 프로그램이 돌아가도록 만들 수 없게 된다.
    • 동작은 하지 않지만 변경이 쉬운 프로그램을 준다면 프로그램이 돌아가도록 만들 수 있고, 변경사항이 발생하더라도 여전히 동작하도록 유지보수할 수 있다.
  • 변경이 불가능한 프로그램은 존재하지 않지만 현실적으로 분가능한 시스템은 존재
    • 변경에 드는 비용이 변경으로 창출되는 수익을 초과하는 경우

 

[아이젠하워 매트릭스]

• 드와이트 D. 아이젠하워가 고안한 매트릭스
  • 내겐 두 가지 유형의 문제가 있습니다. 하나는 긴급하며, 다른 하나는 중요합니다. 긴급한 문제는 중요하지 않으며, 중요한 문제는 절대 긴급하지 않습니다.

  • 중요함 긴급함	중요함 긴급하지 않음
    중요하지 않음 긴급함	중요하지 않음 긴급하지 않음

• 소프트웨어의 매트릭스
  • 소프트웨어의 첫 번째 가치인 행위는 긴급하지만 매번 높은 중요도를 가지는 것은 아님
  • 소프트웨어의 두 번째 가치인 아키텍처는 중요하지만 즉각적인 긴급성을 필요로 하는 경우는 절대 없음
  • 우선순위는 다음과 같이 매길 수 있음
    • 1. 긴급하고 중요한
    • 2. 긴급하지는 않지만 중요한
    • 3. 긴급하지만 중요하지 않은
    • 4. 긴급하지도 중요하지도 않은
  • 아키텍처는 1,2번에, 행위는 1,3번에 위치함
• 업무 관리자와 개발자의 흔한 실수
  • 긴급하지만 중요하지 않은 항목을 첫 번째로 격상시켜 버림
  • 긴급하지만 중요하지 않은 기능과 진짜로 긴급하면서 중요한 기능을 구분하지 못함
  • 업무 관리자는 보통 아키텍처의 중요성을 평가할 만한 능력을 겸비하지 못하지때문에 이것을 해결하기 위해 소프트웨어 개발팀은 마땅히 책임져야함

 

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

• 가치를 위한 투쟁
  • 개발팀은 회사에서 가장 중요하다고 스스로 믿는 가치를 위해 투쟁
  • 관리팀도 자신만의 가치를 위해 투쟁하며, 마케팅팀, 영업팀, 운영팀 또한 마찬가지
  • 효율적인 소프트웨어 개발팀은 이러한 투쟁에서 정면으로 맞서 싸움
  • 소프트웨어를 안전하게 보호해야 할 책임이 있는 소프트웨어 개발자도 이해관계자
• 소프트웨어 아키텍트의 역할
  • 시스템이 제공하는 특성이나 기능보다는 시스템의 구조에 더 중점을 둠
  • 이러한 특성과 기능을 개발하기 쉽고, 간편하게 수정할 수 있으며, 확장하기 쉬운 아키텍처를 만들어야 함
• 아키텍처가 후순위가 된다면...
  • 시스템을 개발하는 비용이 더 많이 들고, 일부 또는 전체 시스템에 변경을 가하는 일이 현실적으로 불가능해짐
  • 이는 소프트웨어 개발팀이 스스로 옳다고 믿는 가치를 위해 충분히 투쟁하지 않았다는 뜻