설계와 아키텍처의 차이

설계(Design)와 아키텍처(Architecture)의 정의가 모호하여 오랫동안 많은 혼란이 있었지만 실제로는 둘의 차이는 없다.

• 아키텍처는 저수준 세부사항과는 분리된 고수준의 무언가를 가릴킬 때 흔히 사용된다.
• 설계는 저수준의 구조 또는 결정사항 등을 의미할 때가 많다.

하지만 아키텍트가 실제로 하는 일을 살펴보면 이러한 구분은 무의미하다.

새로운 집

새로운 집을 설계하는 아키텍트가 있다면 이 집의 아키텍처는 형태, 외관, 입면도, 공간이나 방의 배치등이 포함된다.

하지만 아키텍트가 만든 도면을 살펴보면 콘센트, 전등 스위치, 전등이 모두 어디에 위치하는 지 등 세부사항도 모두 확인할 수 있으며, 벽, 지붕 기초 공사등이 어떻게 진행될지도 상세히 확인할 수 있다.

이처럼 모든 고수준의 결정사항을 지탱하는 모든 세부사항과 고수준의 결정사항은 집의 전체 설계의 구성요소가 된다.

소프트웨어 설계도 마찬가지로, 저수준의 세부사항과 고수준의 구조는 모두 소프트웨어 전체 설계의 구성요소다.

저수준 세부사항과 고수준 세부사항은 단절 없이 이어진 직물과 같으며, 이를 통해 대상 시스템의 구조를 정의한다.

이 둘은 개별로 존재할 수 없으며, 경계 또한 뚜렸하지 않고 고수준에서 저수준으로 향하는 의사결정의 연속성만이 있을 뿐이다.

목표는?

이러한 의사결정, 좋은 소프트웨어 설계 즉 소프트웨어 아키텍처의 목표는 필요한 시스템을 만드록 유지보수하는데 투입되는 인력을 최소화하는 데 있다.

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

• 비용이 낮을 뿐만 아니라 시스템의 수명이 다할 때까지 낮게 유지할 수 있다면 좋은 설계라고 말할 수 있다.
• 새로운 기능을 출시할 때 마다 비용이 증가한다면 나쁜 설계다.

좋은 설계가 필요한 이유

소프트웨어 아키텍처가 나쁘다면 소프트웨어가 진화함에 따라 점점 비용이 증가한다. (생산성이 떨어진다.)

• 이러한 비용의 상승은 사업 모델의 수익을 고갈시킨다.
• 회사의 성장을 멈추게 하거나 심지어는 완전히 망하게 만든다.

시스템을 급하게 만들거나, 결과물의 총량을 순전히 프로그래머 수만으로 결정하거나, 코드와 설계와 구조를 깔끔하게 만들려는 생각을 전혀 하지 않는다면, 시간이 지남에 따라 비용이 급격히 상승하게되고, 이를 통해 생산성이 바닥을 치게 된다.

이러한 현상이 발생하게 되면 개발자가 기능 개발보다는 엉망이 된 상황에 대처하는 데 소모되기 시작하며, 개발자들이 쏟은 노력의 가치를 보잘것없게 만든다.

무엇이 잘못 되었나?

생산성을 유지할 수 있다는 착각

일부 개발자들은 생산성을 유지할 수 있다고 자신의 능력을 과신한다.(언제든지 돌아가 생산성을 회복시킬 수 있다고 생각한다.)

현대의 개발자들은 빠른 시장 출시가 경쟁자보다 앞서 가는 것이라 생각하며 “코드는 나중에 정리하면 돼. 당장은 시장에 출시하는 게 먼저야!“라고 스스로를 속인다.

하지만 시장의 압박은 절대 수그러들지 않기 때문에 태세를 전환하지 않고 정리하는 일은 매우 드물게 되며, 이로 인해 휼륭하고 깔끔하게 잘 설계된 코드와 점점 더 거리가 멀어지게 된다.

이러한 상황에서 계속해서 새로운 기능들이 추가가 되어 결국 엉망진창이 되고, 생산성이 0으로 수렴하기 시작한다.

지저분한 코드를 작성하면 단기간에 빠르게 갈 수 있다는 착각

지저분한 코드를 작성하면 단 기간에는 빠르게 갈 수 있고, 장기적으로 볼 때만 생산성이 낮아진다는 견해는 엉망으로 코드를 짜기위한 자기합리화이며, 진실은 엉망으로 만들면 깔끔하게 유지할 때보다 항상 더 느리다.

제이슨 고먼은 코드를 깔끔하게 유지하는 잘 알려진 방법 중 하나인 TDD를 사용 여부로 생산성을 측정했다.

TDD를 적용했을때가 훨씬 더 빨랐으며, 심지어 TDD를 적용한 가장 느렸던 날이 적용하지 않은 가장 빨리 작업한 날보다 더 빨랐다.

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

생산성이 감소되고 비용이 증가하는 현상을 되돌릴 수 있는 유일한 방법은 없다.

이러한 문제를 해결하기 위해 처음부터 다시 시작하더라도 한번 문제를 발생시킨 개발자(팀)는 똑같은 문제를 반복하는 경우가 많으며, 이 때문에 항상 코드와 설계를 깔끔하게 만들려는 노력을 지속해야한다.

결론

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

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

• 비용은 최소화하고 생산성은 최대화 할 수 있는 설계와 아키텍처를 가진 시스템을 만드려면, 시스템 아키텍처가 지닌 속성을 알고 있어야 한다.

이 책은 훌륭하고 깔끔한 아키텍처와 설계가 무엇인지 설명하고, 이를 통해 소프트웨어 개발자가 장시간에 걸쳐 수익을 창출하는 시스템을 만들 수 있게 하고자 한다.