•
설계와 아키텍쳐 둘은 사실상 다를게 없다.
◦
설계는 저수준, 아키텍쳐는 고수준의 구조를 나타내는 단어지만, 아키텍쳐 내에 설계가 포함되므로 둘이 크게 다를바가 없다.
목표는?
•
설계의 목표는 필요한 시스템을 만들고 유지보수하는 데, 투입되는 인력을 최소화하는 데 있다.
◦
설계 품질을 결정하는 것은, 고객의 요구를 만족시키는 데 드는 비용을 재는 척도와 비슷하다.
◦
설계 품질을 좋게한다는 것은, 유지비용이 낮은 아키텍쳐를 구현한다는 것이다.
사례연구
사례
•
대부분의 회사에서 초기에는 인원이 증가함에 따라 생산성도 빠르게 증가한다.
•
그러다 특정 시점을 기준으로 생산성이 빠르게 줄기 시작한다. 생산성을 현저하게 저하시킨 요인은 뭘까?
엉망진창이 되어 가는 신호
•
개발자의 생산성은 100%로 시작하지만 출시 때마다 하락하다 0에 수렴하게 된다.
•
이유는 개발자가 시간을 새로운 기능을 개발하는데 사용되는 것이 아닌, 기존 코드들로 엉망이 된 상황들에 대처하는데 소모되기 시작하기 때문이다.
경영자의 시각
•
첫 번째 출시에선 매월 수십만 달러의 인건비만으로 제품을 출시했다. 두 번째 출시에선 수십만 달러가 더 들었다. 계속 증가하는 추세다.
•
가장 최근 출시에 이르러서는 매달 수천만 달러의 비용으로도 별 다른 소득이 없었다.
•
그렇다면 어떤 조치를 취해야할까? 무엇이 잘못되었을까? 생산성이 믿기 힘들 정도로 낮아진 원인은 뭘까?
무엇이 잘못되었나?
•
현대의 개발자도 토끼와 거북이와 같은 경주를 한다.
•
개발자가 속는 잘못된 거짓말은 지저분한 코드를 작성하면 단기간에 빠르게 갈 수 있고 장기적으로 볼 때만 생산성이 낮아진다는 견해다.
•
소프트웨어 개발의 단순한 진리는, 빨리 가는 유일한 방법은 제대로 가는 것이다.
결론
•
개발 조직이 할 수 있는 최고의 선택지는 조직에 스며든 과신을 인지하여 방지하고 소프트웨어 아키텍처의 품질을 심각하게 고민하기 시작하는 것이다.
•
소프트웨어 아키텍처를 심각하게 고려할 수 있으려면 좋은 소프트웨어 아키텍처란 무엇인지 이해해야 한다.
◦
비용은 최소화하고 생산성은 최대화할 수 있는 설계와 아키텍처를 가진 시스템을 만들려면 이러한 결과로 이끌어줄 시스템 아키텍처가 지닌 속성을 알고 있어야 한다.
