Clean Architecture - Robert C. Martin

 

 

정리하면서 읽지 않으면 다 까먹어 버리기 때문에... 정리해가면 읽는 Clean Architecture

사실 정리하면서 읽어도 까먹는건 똑같지만 핵심을 다시 보기엔 편하므로 읽으면서 정리합니다.

 

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

 

서문

아키텍처 규칙은 동일하다.

근본적으로 다른 시스템들이 왜 비슷한 아키텍처 규칙을 공유하는 것일까?

- 소프트웨어 아키텍처의 규칙은 다른 모든 변수에 독립적이다. <-- 밥아저씨의 생각

 

코드는 여전히 sequence, selection, iteration의 집합체일 뿐이다.

언어가 발전하고 도구가 좋아졌지만 프로그래밍을 이루는 기본 구성요소는 조금도 바뀌지 않았다.

이처럼 코드가 변하지 않았다는 사실이 시스템 종류와 상관없이 아키텍처의 규칙이 일관된 이유이다.

아키텍처의 규칙이란 프로그램의 구성요소를 정렬하고 조립하는 방법에 관한 규칙이다.

구성요소들이 변하지 않았으므로 구성요소들을 정렬하는 규칙도 변한것이 없다.

 

이 책은 바로 이러한 규칙에 관한 책이다.

 

 

 

소개

프로그램을 동작하게 만드는것은 그리 어려운 일이 아니다.

하지만 제대로 만드는 일은 전혀 다르다!

제대로 만들게 되면 소수의 인원으로도 프로그램이 지속적으로 동작하게 만들 수 있다. 그리고 새로운 기능을 추가하고 유지보수할 수 있다.

하지만 우리의 상황은?

서로 강하게 연관되고 복잡하게 결합되어 있어서 작은 변경에도 많은 시간이 걸릴 뿐만 아니라 제대로 동작하지 않는 위험을 감수해야 한다.

 

 

설계(Design)와 아키텍처(Architecture)란?

설계는 무엇이고 아키텍처는 무엇인가?

- 둘 사이에는 차이가 없다.

 

주로 설계는 저수준의 구조 또는 결정사항을 의미하고 아키텍처는 고수준의 무언가를 가리킬 때 사용한다.

근데 저수준이든 고수준이든 이 둘을 구분 짓는 경계는 뚜렷하지 않다. 그래서 둘 사이에는 차이가 없다고 봐도 된다.

고수준에서 저수준으로 향하는 의사결정의 연속성만이 있다.

 

그럼 이러한 의사결정의 목표는?

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

 

좋은 설계란 고객의 요구를 만족시키는데 드는 비용이 적고 시스템의 수명이 다할 때까지 이 비용을 낮게 유지시키는 것이다.

새로운 기능이 추가될 때마다 비용이 증가하면 좋은 설계라고 할 수 없다.

 

개발자들은 "코드는 나중에 정리하면 돼! 당장은 시장에 출시하는 게 먼저야!"라는 거짓말에 속는다. - 완전 뜨끔...

다음에 만들어야 할 기능들이 기다리고 있으므로 이전에 작성한 코드로 돌아가서 정리하는 일은 일어나지 않는다.

이렇게 되면 결국 생산성은 0을 향해 가기 시작한다.

 

개발자는 처음부터 다시 시스템을 재설계하는 것이 해답이라고 생각할 수 있지만 이러한 생각은 잘못됐다.

자신을 과신한다면 재설계를 하더라고 원래 코드와 같이 똑같이 엉망으로 내몰린다.

 

개발 조직이 할 수 있는 최고의 선택지는 과신을 인지해서 방지하고 아키텍처의 품질을 심각하게 고민하기 시작하는 것이다.

그럼 여기서 어떤 아키텍처가 좋은 아키텍처인지 알아야 한다.

비용을 최소화하고 생산성은 최대화할 수 있는 설계와 아키텍처를 만들려면 시스템 아키텍처가 지닌 속성을 이해해야 한다.

 

이 책에서는 훌륭하고 깔끔한 아키텍처와 설계가 무엇인지에 대해서 다루고 있다.

 

 

 

두 가지 가치에 대해서

 

개발자들은 두 가지 가치를 제공해야 한다.

행위(Behavior)와 구조(Structure)

개발자는 두 가지를 모두 높게 유지할 책임이 있는데 대부분은 한 가지에 집중하고 나머지는 버리게 된다.

 

행위

개발자들은 기계가 요구사항을 만족하도록 코드를 작성한다.

대부분 개발자들이 이러한 활동이 자신의 할 일의 전부라고 생각한다.

 

구조

소프트웨어가 가진 본연의 목적을 추구하려면 소프트웨어 이름답게 부드러워야 한다. 즉 변경이 쉬워야 한다.

기능에 변경사항이 있으면 이 변경을 쉽게 적용할 수 있어야 한다.

이러한 변경사항을 적용하는데 드는 어려움은 변경되는 범위에 비례해야 하고 형태와는 관련이 없어야 한다.

변경사항의 형태와 관계가 있게 되면 새로운 요청사항이 발생할 때마다 적용하는 게 힘들어진다.

현재 시스템의 형태와 변경사항의 형태가 서로 맞지 않기 때문이다.

 

그렇기 때문에 아키텍처는 형태에 독립적이어야 하고 이럴수록 더 실용적이다.

 

그럼 시스템이 동작하도록 만드는 게 중요한가? 변경을 쉽게 하도록 만드는게 중요한가?

관리자는 대다수가 동작하는 게 중요하다고 대답할 것이다.

이는 양 극단의 사례를 들면 명확해진다.

 

1. 완벽하게 동작하지만 수정이 아예 불가능한 프로그램이 있다면 이는 요구사항이 변경되면 동작하지 않게 되고 결국에는 프로그램이 동작하지 않게 된다.

 

2. 동작하지는 않지만 변경이 쉬운 프로그램이 있다면 이를 돌아가도록 만들 수 있고 변경사항이 있어도 동작하도록 유지 보수할 수 있다.

 

물론 변경이 아예 불가능한 프로그램이란 없으니 이 예시가 올바르다곤 할 수없다.

하지만 현실적으로 변경에 들어가는 비용이 변경으로 인한 수익보다 높은 경우 변경하는 게 불가능하다고 볼 수 있다.

 

하지만 중요한 건 변경 비용이 너무 커서 현실적으로 변경을 할 수 없는 상태가 된다면 이 상황이 될 때까지 프로그램을 방치한 개발자에게 책임이 있다는 건 분명하다.

 

모든 일은 긴급함과 중요함이 있다.

그리고 이를 통해 4가지로 분류가 된다.

 

1. 긴급하고 중요한 일

2. 긴급하지 않지만 중요한 일

3. 긴급하지만 중요하지 않은 일

4. 긴급하지도 않고 중요하지도 않은 일

 

아키텍처는 2번째에 해당하는 일이다.

행위는 1, 3번째에 해당하는 일이다.

 

여기서 중요한 것은 3번째에 해당하는 일을 1번째로 격상시키는 것이다.

긴급하지만 중요하지 않은 일과 진짜 긴급하고 중요한 일을 구분하지 못한다.

이러한 일 때문에 중요도가 높은 아키텍처를 무시한 채 기능을 택하게 된다.

 

관리자는 보통 아키텍처의 중요성을 모르기 때문에 개발자는 딜레마에 빠진다.

하지만 개발자를 고용하는 이유는 이 딜레마를 해결하기 위해서이다.

따라서 기능의 긴급성이 아닌 아키텍처의 중요성을 설득하는 일은 개발팀이 책임져야한다.

 

하나만 기억하자 아키텍처가 후순위가 되면 시스템 개발비용이 점점 증가하고 시스템을 변경하는 게 현실적으로 불가능해지는 순간이 온다.

이러한 상황이 발생하는 것은 전적으로 개발팀이 스스로 옳다고 믿는 가치를 위해 충분히 투쟁하지 않았다는 뜻이다.

 

 

2장은 다음 시간에!