1-1. 설계와 아키텍처란

설계(design)와 아키텍처(architecture) 사이에는 오랫동안 많은 혼란이 있었다.

밥아저씨(로버트 C.마틴)의 첫 번째 주장: 둘 사이에는 차이가 없다.

 

보통 ‘아키텍처’는 저수준의 세부사항과는 분리된 고수준의 무언가를 가리킬 때 흔히 사용되는 반면,

‘설계’는 저수준의 구조 또는 결정사항 등을 의미할 때가 많다.

그러나, 아키텍트의 일을 살펴보면, 실제로 이러한 구분은 무의미하다.

 

새로운 집을 설계하는 아키텍트가 만든 도면에는 무수히 많은 저수준의 세부사항도 확인할 수 있다.

콘센트, 전등, 전등 스위치, 보일러와 온수기, 배출 펌프와 크기 등이 모두 어디에 위치해있는지 알 수 있다.

벽, 지붕, 기초 공사 역시 어떻게 진행되는지도 알 수 있다.

 

소프트웨어도 마찬가지이다. 저수준의 세부사항과 고수준의 구조는 모두 소프트웨어 전체 설계의 구성요소다. 이 둘은 단절 없이 이어진 작물과 같으며, 이를 통해 대상 시스템의 구조를 정의한다.

고수준에서 저수준으로 향하는 의사결정의 연속성만이 있을 뿐이다.

 

목표는?

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

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

이 비용이 낮을 뿐만 아니라 시스템의 수명이 다할 때까지 낮게 유지할 수 있다면 좋은 설계라고 말할 수 있다.

새로운 기능을 추구할 때 마다 비용이 증가한다면 나쁜 설계다. 좋은 설계란 이처럼 단순명료하다.

 

무엇이 잘못되었나?

개발자들은 “코드는 나중에 정리하면 돼. 장당은 시장에 출시하는 게 먼저야!”라는 흔해 빠진 거짓말에 속는다. 이렇게 속아 넘어간 개발자라면 나중에 코드를 정리하는 경우는 한 번도 없는데, 시장의 압박은 절대로 수그러들지 않기 때문이다.

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

개발자들은 토끼와 거북이의 토끼처럼, 생산성을 유지할 수 있다고 자신을 과신한다. 하지만 엉망진창인 코드가 계속 쌓이면, 개발자 생산성은 차츰 낮아지고, 코드가 엉망이 되는 추세는 절대 멈추거나 수그러들지 않는다.

이대로 진행되면 결국 생산성이 0으로 수렴하는 일은 시간문제이다.

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

우리는 훌륭하고 깔끔한 아키텍처와 설계를 통해서 소프트웨어 개발자가 장기간에 걸쳐서 수익을 창출하는 시스템을 만들 수 있게 해야 한다.