이 글은 한달 한권 챌린지의 두번째 책, 클린아키텍처를 읽고 정리한 내용이다.
1장. 설계와 아키텍처란?
설계와 아키텍처의 차이
설계(design)와 아키텍처(architecture) 사이에는 차이가 없다.
보통 ‘설계’는 저수준의 구조 또는 결정사항 등을 의미하고, ‘아키텍처’는 저수준의 세부사항과는 분리된 고수준의 무언가를 가리킬 때 흔히 사용된다.
그러나 저수준의 세부사항과 고수준의 구조는 모두 소프트웨어 전체 설계의 구성요소다. 이 두 개의 개념을 통해 대상 시스템의 구조를 정의한다. 개별로는 존재할 수 없고, 실제로 이 둘을 구분 짓는 경계는 뚜렷하지 않다. 고수준에서 저수준으로 향하는 의사결정의 연속성만이 있을 뿐이다.
소프트웨어 아키텍처의 목표
소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화하는 데 있다.
설계 품질을 재는 척도는 고객의 요구를 만족시키는 데 드는 비용을 재는 척도와 다름없다. 이 비용이 낮을 뿐만 아니라 시스템의 수명이 다할 때까지 낮게 유지할 수 있다면 좋은 설계라고 말할 수 있다. 새로운 기능을 출시할 때 마다 비용이 증가한다면 나쁜 설계다.
생산성이 감소되고 비용이 증가하는 현상을 되돌릴 수 있는 유일한 방법은 개발자로 하여금 자신의 능력을 과신하려는 믿음을 버리고, 만들어 낸 엉망진창인 코드를 개발자가 책임지도록 하는 것뿐이다. 자신을 과신한다면 재설계하더라도 원래의 프로젝트와 똑같이 엉망으로 내몰린다.
2장. 두 가지 가치에 대한 이야기
행위(behavior)
소프트웨어의 첫 번째 가치는 바로 행위(behavior)다.
이해관계자는 기계가 수익을 창출하거나 비용을 절약하도록 만들기 위해 프로그래머를 고용한다. 프로그래머는 이해관계자가 기능 명세서나 요구사항 문서를 구체화할 수 있도록 돕고 기계가 이러한 요구사항을 만족하도록 코드를 작성한다. 기계가 이러한 요구사항을 위반하면, 프로그래머는 디버거를 열고 문제를 고친다.
많은 프로그래머가 이러한 활동이 자신이 해야 할 일의 전부라고 생각한 다. 이들은 요구사항을 기계에 구현하고 버그를 수정하는 일이 자신의 직업 이라고 믿는다.
아키텍처(architecture)
소프트웨어의 두 번째 가치는 소프트웨어(software)라는 단어와 관련이 있 다.
소프트웨어는 ‘부드러움을 지니도록’, 즉 기계의 행위를 쉽게 변경할 수 있도록 하기 위해 만들어졌다.
소프트웨어가 가진 본연의 목적을 추구하려면 변경하기 쉬워야 한다. 이해관계자가 기능에 대한 생각을 바꾸면, 이러한 변경사항을 간단하고 쉽게 적용할 수 있어야 한다. 이러한 변경사항을 적용하는 데 드는 어려움은 변경되는 범위(scope)에 비례해야 하며, 변경사항의 형태(shape)와는 관련이 없어야 한다.
소프트웨어 개발 비용의 증가를 결정짓는 주된 요인은 바로 이 변경사항 의 범위와 형태의 차이에 있다. 바로 이 때문에 개발 비용은 요청된 변경사항의 크기에 비례한다 . 문제는 당연히 시스템의 아키텍처다. 아키텍처가 특정 형태를 다른 형태보다 선호하면 할수록, 새로운 기능을 이 구조에 맞추는 게 더 힘들어진다. 따라서 아키텍처는 형태에 독립적이어야 하고, 그럴수록 더 실용적이다.
더 높은 가치
둘 중 어느 것의 가치가 더 높은가? 소프트웨어 시스템이 동작하도록 만드는 것이 더 중요한가? 아니면 소프트웨어 시스템을 더 쉽게 변경할 수 있도록 하는 것이 더 중요한가?
업무 관리자는 현재 기능의 동작 여부가 미래의 유연성보다 더 중요하긴 하지만, 변경이 가능한 시스템도 필요하다고 말할 것이다.
소프트웨어 아키텍트는 시스템이 제공하는 특성이나 기능보다는 시스템의 구조에 더 중점을 둔다. 아키텍트는 이러한 특성과 기능을 개발하기 쉽고, 간편하게 수정할 수 있으며, 확장하기 쉬운 아키텍처를 만들어야 한다.
아키텍처가 후순위가 되면 시스템을 개발하는 비용이 더 많이 들고, 일부 또는 전체 시스템에 변경을 가하는 일이 현실적으로 불가능해진다.
