1장 - 설계와 아키텍처란?

설계와 아키텍처의 정의

설계와 아키텍처 사이의 혼란을 없애고 두 용어에 대해 완전하게 정의하고자 합니다.

 

첫 번째로 둘 사이의 차이는 없습니다.

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

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

 

집을 설계하는 아키텍트가 있고 이 집은 아키텍처를 가지고 있습니다.

집의 형태, 외관, 입체도, 공간이나 방의 배치가 여기에 포함됩니다.

하지만 도면을 살펴보면 무수히 많은 저수준의 세부사항도 확인할 수 있습니다.

콘센트, 전등, 스위치, 전등이 모두 어디에 위치하는지 도면에서 알 수 있습니다.

 

다시 말해 고수준의 결정사항을 지탱하는 모든 세부사항을 자세하게 확인할 수 있습니다.

 

소프트웨어 설계에서도 이와 동일합니다.

 

목표

필요한 시스템을 만들고 유지 보수하는 데 투입되는 인력을 최소화하기

 

사례로 알아보는 설계의 중요성

제품이 성장하면서 개발자가 증가하게 됩니다.

개발자는 점점 많아지고 새로운 기능이 추가될수록 코드 라인 수가 많아집니다.

개발자는 많지만 생산성은 떨어지게 됩니다.

 

당장의 수익성은 중요하지 않으며 이러한 비용 곡선은 회사의 성장을 멈추게 합니다.

 

코드와 설계의 구조를 깔끔하게 만들려는 생각을 하지 않으면 파국으로 치닫는 비용 곡선에 올라타게 됩니다.

개발자의 생산성은 초기에 100%로 시작하지만 시간이 지남에 따라 결국에는 0으로 수렴하게 됩니다.

 

이는 개발자의 입장에서도 사소한 기능을 추가하기 위해 수많은 에너지를 소비해야 합니다.

마찬가지로 경영자의 입장에서도 사소한 기능을 추가하기 위해 막대한 인건비를 들여야 합니다.

 

 

원인

대부분 다음과 같은 생각을 하곤 합니다.

"코드는 나중에 정리하면 돼. 당장은 시장에 출시하는 게 먼저야"

하지만 나중에 코드를 정리하는 경우는 거의 없습니다.

시장의 압박은 절대로 수그러들지 않기 때문입니다.

계속해서 다음 기능들이 기다리고 있으며 결국 엉망진창이 되어 생산성이 0으로 수렴하게 됩니다.

 

빨리 가는 유일한 방법은 제대로 가는 것이며 자신을 과신한다면 재설계하더라도 원래의 프로젝트와 똑같이 엉망으로 될 가능성이 높습니다.

 

결론

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

 

 

개인적인 견해

최근에 프로젝트를 진행하며 코드의 덩치가 커지면서 새로운 기능을 추가할 때 다양한 의존성을 고려해야 하며 side effect를 찾기 위해 힘들었던 기억이 존재합니다.

 

이때 리팩토링의 필요성을 느꼈으며 초기부터 설계를 깔끔하게 가져가서 코드의 품질을 높게 유지한다면 기능이 많아지더라도 빠른 생산성을 가질 수 있을 것이라고 생각하게 되었습니다.

 

이런 계기로 객체지향과 클린코드에 대해 관심을 가지게 되었으며 앞으로 이 책을 읽으며 알아가고자 합니다.