[Clean Architecture] 1부를 읽고 정리하며 생각해보기

로버트C. 마틴의 Clean Architecture는 개발자 필독서라고 불리는 책 중 하나이다.

이 책을 공부하면서 이해가 되지 않는 부분이나 나의 궁금증을 함께 정리해보고자 한다.

필독서라고 해도 다양한 의견이 존재할 수는 있지 않을까..?

저자가 이 책을 쓰게 된 이유에 대해

지금까지 구축한 다양한 시스템들이 있지만 이들은 모두 비슷한 아키텍처 규칙을 공유한다.

따라서 소프트웨어 아키텍처의 규칙은 다른 모든 변수에 독립적이다.

반세기 동안 하드웨어는 많이 변해온 것에 비해, 소프트웨어는 여전히 순차, 분기, 반복의 집합체이다.

좋은 소프트웨어 설계의 목표?

프로그램을 동작하게 만드는 것과 제대로 만드는 일은 전혀 다르다.
제대로 된 소프트웨어를 만들면 최소한의 노력으로 기능과 유연성을 최대화할 수 있다.

 

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

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

개발하기 쉽고, 간편하게 수정할 수 있으며, 확장하기 쉬워야한다.

행위와 구조

모든 소프트웨어 시스템은 이해관계자에게 두 가지 '행위', '구조'를 제공한다.

행위

이해관계자의 기능 명세서나 요구사항 문서를 구체화 하는 것

기계가 이러한 요구사항을 위반하면, 프로그래머는 디버거를 열고 문제를 고친다.

대부분의 프로그래머는 구현과 버그 수정이 자신이 해야 할 일의 전부라고 생각하지만, 틀렸다.

아키텍처

소프트웨어는 부드러움(soft) + 제품(ware)의 합성어이다.

이유는 기계의 행위를 쉽게 변경할 수 있도록 하기 위해서다.

아키텍처가 특정 형태를 다른 형태보다 선호하면 할수록, 새로운 기능을 이 구조에 맞추는 게 더 힘들어진다.

따라서 아키텍처는 형태에 독립적이어야한다.

행위와 아키텍처 중 더 높은 가치?

동작하지만 수정이 불가능한 프로그램은 요구사항이 변경될 때 프로그램이 돌아가도록 만들 수 없음

변경이 쉽지만 동작을 하지 않는 프로그램은 돌아가도록 만들 수 있고, 변경사항이 발생해도 여전히 동작하도록 유지보수할 수 있다.

아이젠하워 매트릭스

중요성과 긴급성에 관한 매트릭스 우선순위이다.

1. 긴급하고 중요한
2. 긴급하지는 않지만 중요한
3. 긴급하지만 중요하지 않은
4. 긴급하지도 중요하지도 않음

여기서 중요한 일인 아키텍처는 이 항목의 가장 높은 두 순위를 차지하고, 긴급한 일인 행위는 첫번째와 세번째에 위치한다.

이를 근거로 업무 관리자와 개발자가 흔하게 저지르는 실수가 세 번째 위치한 항목을 첫번째로 격상시키는 일이다.

아키텍처가 후순위가 되면 시스템 개발 비용이 더 많이 들게 된다.

💡 이 부분에 대한 나의 생각.
상황에 따라 2번 “긴급하지는 않지만 중요한”보다 3번 “긴급하지만 중요하지 않은”이 더 우선시 되는 경우도 있지 않을까.라는 의문이 들었다. (물론 이 문단의 요점은 2번, 3번 이게 중요한 것이 아니고, 첫번째가 가장 높은 우선순위이고 세번째를 첫번째로 격상시키면 안된다를 말하고 있다.)

예를들어,
2번 : 천천히 구현해도 되지만, 쉽게 수정 가능한 것
3번 : 빠르게 구현해야 되지만, 쉽게 수정 불가능한 것
이라고 생각한다면 마감기한이 급한 경우… 얼른 구현해야하지 않을까????
주관적인 우선순위를 근거로 제시한 내용을 모든 상황에 절대적으로 대입하는 것이 맞을까?

이에 대한 자답,
동작하지만 수정이 불가능한 프로그램은 요구사항이 변경될 때 프로그램이 돌아가도록 만들 수 없기 때문에
빠르게 구현한다고 해도 이후 쓸모없는 프로그램이 될 것이라는 의미 같다! 그래서 결국 아키텍처가 가장 중요하다는 것.

물론 애초에 좋은 아키텍처가 설계가 몸에 배어 있어있어 빠르게 좋은 코드를 작성하는 것이 훌륭한 개발자이겠지만, 실무에서 빠른 개발 혹은 디버깅이 요구되는 추후에 아키텍처 수정하는 것이 우선시 되지 않을까? 궁금하다!! 

이에 대해 부가 설명 가능한 분들의 의견 듣고 싶다..
얼마든지 댓글 부탁 드립니다 🌟

 

1부를 읽고 아키텍처가 내가 생각했던 것보다 더~욱 중요한 것 같다고 느꼈다.

사실 나도 구현하는 것이 조금 더 중요하다고 생각했었기 때문이다. (위와 같은 의문이 드는 것도 그런 이유 인 것 같다..)

다양한 시스템들이 모두 비슷한 아키텍처 규칙을 공유한다는 점도 흥미롭다. 

여태껏 깊게 생각해보지 못했던 부분이기 때문이다. 

이 책을 읽음으로써 기존의 파편적인 생각들이 정리되는 기분이다!!