[책 정리] 1장. 설계와 아키텍처란? - Clean Architecture

-

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

하지만 프로그램을 제대로 만드는 일은 전혀 다르다. 올바르게 만드는 일은 어렵다.

 

 

-

설계와 아키텍처의 차이는 무엇인가? 둘 사이에는 아무런 차이가 없다.

아키텍처는 저수준의 세부사항과는 분리된 고수준의 무언가를 가리킬 때 흔히 사용되는 반면, (비유 : 집의 형태, 외관, 입면도, 공간, 방의 배치)

설계는 저수준의 구조 또는 결정사항 등을 의미할 때가 많다. (비유 : 콘센트, 전등 스위치, 전등, 보일러, 온수기와 배출 펌프의 크기와 위치 등)

하지만 결국은 무의미하다. 둘은 같다.

 

 

 

목표는?

 

-

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

설계 품질을 재는 척도는 고객의 요구를 만족시키는 데 드는 비용을 재는 척도와 같다.

이 비용이 낮을 뿐만 아니라 시스템의 수명이 다할 때까지 낮게 유지할 수 있다면 좋은 설계라고 할 수 있다.

 

 

 

사례 연구

 

* 엉망진창이 되어 가는 신호

 

 

* 경영자의 시각

 

 

* 무엇이 잘못되었나?

 

-

개발자도 생산성을 유지할 수 있다고 자신의 능력을 과신한다.

하지만 엉망진창인 코드가 서서히 쌓이면 개발자 생산성은 차츰 낮아지고, 코드가 엉망이 되는 추세는 절대 멈추거나 수그러들지 않는다.

결국 생산성이 0으로 수렴하는 일은 시간문제다.

 

 

-

개발자가 속는 더 잘못된 거짓말은 "지저분한 코드를 작성하면 단기간에는 빠르게 갈 수 있고, 장기적으로 볼 때만 생산성이 낮아진다" 는 견해다.

진실은 다음과 같다. 엉망으로 만들면 깔끔하게 유지할 때보다 항상 더 느리다. 시간 척도를 어떻게 보든지 관계없이 말이다.

 

 

-

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

 

 

 

결론

 

-

어떤 경우라도 개발 조직이 할 수 있는 최고의 선택지는 조직에 스며든 과신을 인지하여 방지하고, 소프트웨어 아키텍처의 품질을 심각하게 고민하기 시작하는 것이다.

소프트웨어 아키텍처를 심각하게 고려할 수 있으려면 좋은 소프트웨어 아키텍처가 무엇인지 이해해야 한다.

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