1장: 설계와 아키텍처란?
개요
설계(design)과 아키텍처(architecture)에 오랫동안 혼란이 있었다. 하지만 둘은 아무런 차이가 없다. 보통 아키텍처는 고수준의 무언가를 가리킬때 사용되고 디자인은 저수준의 세부사항, 결정사항을 의미할때가 많다.
새로운 집을 생각해보자. 형태, 외관, 공간, 방의 배치 등 고수준 결정 사항들은 아키텍처에 포함된다. 하지만 잘 살펴보면 그 안에 컨센트, 스위치, 전등 등 저수준의 세부사항들로 구성된걸 알 수 있다.
소트트웨어 또한 마찬가지로 저수준의 세부사항과 고수준의 구조는 소프트웨어 전체 설계의 구성요소이다. 이들의 경계는 모호하며 의사결정의 연속성만 있을 뿐이다.
목표는?
간단히 말해 "필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화하는데 있다." 하지만 많은 기업에서 출시 및 업데이트가 늘어갈수록 생산성이 줄었으며 코드 한 줄당 비용 엄청나게 늘어났다. 이런 비용 곡선은 수익을 고갈시키며 기업의 성장을 방해한다. 그렇다면 무슨 요인이 있었을까?
당연히 코드와 설계의 구조를 깔끔하게 하지 않고 당장 급하게 시스템을 만들거나 결과물의 총량을 순전히 개발자 수만으로 결정하였던 것이다.
무엇이 잘못되었나? 토끼와 거북이 우화를 생각해보자. 토끼가 자신의 빠르기를 과신한 것처럼 개발자는 자신이 생산성을 유지할 수 있다고 생각한다. 엉망진창인 코드 안에선 필연적으로 생산성은 낮아지고 난잡함은 더해져만 간다.
결론
개발 조직의 최고의 선택은 과신을 인지하여 방지하고 SA 품질을 심각하게 고민하기 시작하는 것이다. 그러기 위해선 좋은 소포트웨어 아키텍처가 무엇인지 이해해야 한다. 이를 위해선 시스템 아키텍처가 지닌 속성을 알고 적절히 다룰 줄 알아야 한다.
2장: 두 가지 가치에 대한 이야기
개요
소프트웨어 시스템은 관계자에게 행위(behavior)와 구조(structure)라는 서로 다른 가치를 제공한다. 개발자는 둘 모두를 높게 유지해야 하지만 한 가치에만 집중하여 결국은 그 소프트웨어 시스템 자체가 쓸모없어진다...
행위
행위란 요구사항에 따라 기계에 코드를 작성하고 소프트웨어를 구현하는 것이다. 많은 개발자가 이러한 활동이 자신의 일의 전부라고 생각한다...
아키텍처
소트트웨어 단어 자체가 부드러움과 제품을 합친 합성어이다. 즉, 변경하기 쉬워야 하며 변경의 어려움은 변경되는 범위에 비례해야 하며, 변경 사항의 형태와는 관련이 없어야한다. (제일 핵심 내용인거 같다.)
더 높은 가치
행위가 중요한거처럼 보이겠지만 결국은 아키텍처, 행위 둘 모두 중요하다. 행위를 우선하여 소프트웨어를 만들면 시간이 갈수록 업데이트의 생산성이 떨어질 것이다. 결국 느린 업데이트의 책임은 개발자에게 돌아갈것이기 때문에 아키텍처를 위해 계속 투쟁해야한다.
