[Clean Architecture] Clean Architecture chap 1 정리

우선, 이 책의 시작은 책의 이름에 걸맞게 설계와 아키텍처 의 차이점에 대해 설명합니다.

아키텍쳐와 설계의 차이점은 그 규모에 있습니다. 아키텍쳐가 더 큰 개념이고, 아키텍쳐 안에 설계가 있는 형태 입니다. 이 책에서는 집을 예로듭니다. 집 전체의 구조를 따지는것은 아키텍쳐이고, 집 안에 안방, 화장실 등의 구성요소의 구조를 따지는것을 설계라고 설명합니다. 소프트웨어도 마찬가지입니다. 저수준의 세부사항과 고수준의 구조는 모두 소프트웨어 전체 설계의 구성요소 입니다. 이 둘은 단절 없이 이어진 직물과 같으며, 이를 통해 대상 시스템의 구조를 정의합니다. 개별로는 존재할 수 없고, 실제로 이 둘을 구분 짓는 경계는 뚜렷하지 않습니다. 고수준에서 저수준으로 향하는 의사결정의 연속성만 있다고 합니다.

다음은 소프트웨어의 목적 입니다.

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

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

저자는 이름을 밝히지 않길 원하는 어떤 회사를 예로 듭니다. 어떤 서비스를 개발할 때, 기능이 커질수록 개발자의 수와 개발하는데 걸리는 시간이 기하급수적으로 올라가는 회사입니다. 이는 잘못된 설계가 서비스에 얼마나 영향을 줄 수 있는지 시사하는 아주 좋은 예 입니다.

또한 다음과 같은 말을 합니다.

소프트웨어 (soft-ware)란 하드웨어 (hard-ware)와는 다르게 ‘부드러움을 지니도록’ 만들어졌다. 소프트웨어를 만든 이유는 기계의 행위를 쉽게 변경할 수 있도록 하기 위해서다.

위 말은 소프트웨어는 언제든지 요구사항에 따라서 바뀔 수 있다는 말을 시사합니다. 따라서, 언제든지 바뀔 수 있다고 상정하고 작업을 해야 합니다. 대부분의 개발자가 소프트웨어를 하면서도 그 본질을 망각한 채 작업을 하며, 요구사항이 바뀔 때 마다 성질을 내곤 합니다. 따라서 소프트웨어를 다룬다면, 언제든지 바뀔 수 있음을 이해하고, 요구사항이 바뀔 수 있을만한 부분을 생각하고 설계해야 합니다. 또한 저자는 다음과 같은 말을 합니다.

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

지금에 급급하여 아키텍처를 생각하지 않고 기능을 만드는데만 신경을 쓴다면 나중에 그 부채들을 감당하는데 엄청난 비용이 들것입니다. 따라서 제대로갈 수 있도록 노력을 해야합니다.

다음은 아이젠하워 미국 대통령이 고안한 중요성과 긴급성에 관한 아이젠하워의 매트릭스를 발췌하였습니다.

내겐 두 가지 유형의 문제가 있습니다. 하나는 긴급하며, 다른 하나는 중요합니다. 긴급한 문제는 중요하지 않으며, 중요한 문제는 절대 긴급하지 않습니다.

이를 소프트웨어에 적용해본다면 다음과 같습니다. 소프트웨어의 첫 번째 가치인 행위는 긴급하지만 매번 높은 중요도를 가지는 것은 아닙니다. 소프트웨어의 두 번째 가치인 아키텍처는 중요하지만 즉각적인 긴급성을 필요로 하는 경우는 절대 없습니다. 따라서 이 둘의 밸런스를 잘 잡는게 중요합니다. 하지만 하나만 기억하자면, 이키텍처가 후순위가 되면 시스템을 개발하는 비용이 더 많이 들게 되고 일부 또는 전체 시스템에 변경을 가하는 일이 현실적으로 불가능해집니다. 이러한 상황이 발생하도록 용납하였다면, 이는 결국 소프트웨어 개발팀이 스스로 옳았다고 믿는 가치를 위해 충분히 투쟁하지 않았다는 뜻입니다.

Clean Architecture 카테고리 내 다른 글 보러가기