1부. 소개
1장. 설계와 아키텍처란?#
- '아키텍처'는 저수준의 세부사항과는 분리된 고수준의 무언가를 가리킬 때 사용되고, '설계'는 저수준의 구조 또는 결정사항을 의미할 때가 많습니다. 그러나 이러한 구분은 무의미합니다.
- 저수준의 세부사항과 고수준의 구조는 모두 소프트웨어 전체 설계의 구성요소입니다.
- 개별로는 존재할 수 없고, 이 둘을 구분 짓는 경계는 뚜렷하지 않으며 고수준에서 저수준으로 향하는 의사결정의 연속성만 있을 뿐입니다.
목표는?#
소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화하는 데 있씁니다.
- 설계 품질을 재는 척도는 고객의 요구를 만족시키는 데 드는 비용을 재는 척도와 다름 없습니다.
- 비용이 낮을 뿐만 아니라 시스템의 수명이 다할 때까지 낮게 유지할 수 있다면 좋은 설계, 새로운 기능을 출시할 때마다 비용이 증가한다면 나쁜 설계입니다. 즉 좋은 설계는 단순명료합니다.
사례 연구#
- 코드 라인당 비용이 크면 클 수록 당장의 수익성은 중요하지 않으며, 사업 모델의 수익을 엄청나게 고갈시키며 회사의 성장을 멈추게 합니다.
엉마진창이 되어 가는 신호#
- 시스템을 급하게 만들거나, 결과물의 총량을 순전히 프로그래머 수로 결정하거나, 코드와 설계의 구조를 깔끔하게 만들려는 생각을 전혀 하지 않으면 파국으로 치닫는 비용 곳선에 올라타게 됩니다.
- 이러한 비용 곡선은 개발자 관점에서 100%로 시작하지만 출시마다 떨어져 결국 0으로 수렴합니다.
- 엉망이 되면 이러한 상황에 대처하는 데 에너지를 소모되기 시작합니다.
경영자의 시각#
- 출시에 비례해서 인건비가 엄청나게 늘어납니다.
무엇이 잘못되었나?#
- 개발자가 코드 정리를 나중에 하고 시장에 출시하는 것을 우선으로 잡으면, 이는 결국 생산성이 0으로 수렴하게 됩니다.
- 개발자가 속는 더 잘못된 거짓말은 지저분한 코드를 작성하면 단기간에 빠르게 갈 수 있고, 장기적으로 볼 때만 생산성이 낮아진다고 생각하게 됩니다.
빨리 가는 유일한 방법은 제대로 가는 것입니다.
- 개발자는 처음부터 다시 시작하여 전체 시스템을 재설계하는 것이 해답이라고 생각할지도 모릅니다.
자신을 과신한다면 재설계하더라도 원래의 프로젝트와 똑같이 엉망으로 내몰립니다.
결론#
- 어떤 경우라도 개발 조직이 할 수 있는 최고의 선택지는 조직에 스며든 과신을 인지하여 방지하고, 소프트웨어 아키텍처의 품질을 심각하게 고민하기 시작하는 것입니다.
- 소프트웨어 아키텍처를 심각하게 고려할 수 있으려면 좋은 소프트웨어 아키텍처가 무엇인지 이해해야 합니다.
2장. 두 가지 가치에 대한 이야기#
- 소프트웨어 시스템은 이해관계자에게 행위(beharvior) 과 구조(structure) 을 제공합니다.
행위#
- 소프트웨어 첫 번째 가치입니다.
- 프로그래머는 이해관계자가 기능 명세서나 요구사항 문서를 구체화할 수 있도록 합니다.
- 그러나, 이외에도 할 일이 있습니다.
아키텍처#
- 소프트웨어 두 번째 가치입니다.
- 소프트웨어는 '부드러움을 지니도록' 만들어졌으며 기계의 행위를 쉽게 변경하기 위해서입니다.
- 소프트웨어 개발 비용의 증가를 결정짓는 주된 요인은 변경사항의 범위와 형태의 차이가 있습니다.
- 아키텍처는 형태에 독립적이어야 하고, 그럴수록 더 실용적입니다.
더 높은 가치#
- 완벽하게 동작하지만 수정이 불가능한 프로그램은 결국 요구사항이 변경되면 동작하지 않게 됩니다.
- 동작 하지는 않지만 변경이 쉬운 프로그램은 이후에 돌아가게 할 수 있으며 변경사항이 발생해도 유지보수 할 수 있습니다.
현재 기능의 동작 여부와 미래의 유연성 둘 다 중요합니다.
아이젠하워 매트릭스#
- 긴급한 문제가 아주 중요한 문제일 경우는 드물고, 중요한 문제가 몹시 긴급한 경우는 거의 없습니다.
- 즉, 행위는 긴급하지만 매번 중요도가 높은 경우를 가진 것은 아니지만 아키텍처또한 중요하지만 즉각적인 긴급성을 필요로 하는 경우는 절대 없습니다.
이를 우선순위로 매기면 다음과 같습니다.
- 긴급하고 중요한
- 긴급하지 않지만 중요한
- 긴급하지만 중요하지 않은
- 긴급하지도 중요하지도 않은
여기서 실수하기 쉬운 부분은 3번 경우를 1번 경우로 올리는 방법입니다. 즉, 개발자는 이러한 딜레마를 해결해야합니다.
아키텍처를 위해 투쟁하라#
- 개발자는 책임을 위해서는 투쟁해야 합니다.
- 효율적인 소프트웨어 개발팀은 이러한 투쟁에서 정면으로 맞서 싸웁니다.
- 소프트웨어 개발자도 이해관계자이며 소프트웨어를 안전하게 보호해야 할 책임이 있습니다.
소프트웨어 아키텍처는 시스템이 제공하는 특성이나 기능보다는 시스템의 구조에 더 중점을 봅니다. 아키텍트는 이러한 특성과 기능을 개발하기 쉽고, 간편하게 수정할 수 있으며, 확장하기 쉬운 아키텍처를 만들어야 합니다.