[Clean Architecture] 1부 소개

옮긴이의 글

• 소프트웨어 시스템이란 무엇인지를 우리는 제대로 이해하고 있을까?
• 소프트웨어 시스템을 통해서 우리가 얻고자 하는 것은 무엇일까?
• 잘 설계한 소프트웨어 아키텍처는 소프트웨어 시스템을 만들 때 왜 중요할까?
• 중요하다면 어떻게 해야 소프트웨어 아키텍처를 잘 만들 수 있을까?

 

1장 설계와 아키텍처란?

우선 설계와 아키텍처 사이에는 차이가 없다. 둘은 동일하다.

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

고객의 요구를 만족시키는 데 드는 비용이 낮을 뿐만 아니라 시스템의 수명이 다할 때까지 낮게 유지할 수 있다면 좋은 설계,

새로운 기능을 출시할 때마다 비용이 증가한다면 나쁜 설계이다.

 

개발자는 훌륭하고 깔끔하게 잘 설계된 코드가 중요하다는 사실을 인지하고 있음에도 당장의 시장 출시에 눈이 멀어 코드는 엉망이 되고 만다.

'시장 출시가 먼저'라는 생각을 하는 이유는 바로 뒤에 여러 무리의 경쟁자가 뒤쫓고 있고, 경쟁자보다 앞서 가려면 가능한 한 빠르게 달려야 하기 때문이다.

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

처음부터 다시 시작하여 전체 시스템을 재설계하는 것이 해답일까? 자신을 과신한다면 원래의 프로젝트와 똑같이 엉망으로 내몰릴 뿐이다.

 

소프트웨어 아키텍처의 품질을 높이기 위해서는 좋은 소프트웨어 아키텍처가 무엇인지 이해해야 한다.

 

2장 두 가지 가치에 대한 이야기

1. 행위

프로그래머는 이해관계자가 기능 명세서나 요구사항 문서를 구체화할 수 있도록 돕는다. 그리고 이해관계자의 기계가 이러한 요구사항을 만족하도록 코드를 작성한다.

= 요구사항을 반영해야 하는 책임

 

2. 아키텍처

소프트웨어를 만든 이유는 기계의 행위를 쉽게 변경할 수 있도록 하기 위해서다. 이해관계자가 기능에 대한 생각을 바꾸면, 이러한 변경사항을 간단하고 쉽게 적용할 수 있어야 한다. 이러한 변경사항을 적용하는 데 드는 어려움은 변경되는 scope에 비례해야 하며, 변경사항의 shape와는 관련이 없어야 한다. 아키텍처는 형태에 독립적이어야 하고, 그럴수록 더 실용적이다.

= 변경사항을 간단하고 쉽게 적용해야 하는 책임

 

행위는 긴급하지만 매번 높은 중요도를 가지는 것은 아니다. 아키텍처는 중요하지만 즉각적인 긴급성을 필요로 하는 경우는 절대 없다.

우리는 긴급하지만 중요하지 않은 기능(행위)과 진짜로 긴급하면서 중요한 기능(아키텍처)을 구분할 줄 알아야 한다.

아키텍처가 후순위가 되면 시스템을 개발하는 비용이 더 많이 들고, 일부 또는 전체 시스템을 변경하는 일이 현실적으로 불가능해진다.