1. 설계와 아키텍처
우리는 보통 설계(Design)과 아키텍처(Architecture)를 이야기 할 때,
아키텍처의 경우 "고수준"의 구조 또는 결정사항 등으로, 설계의 경우에는 "저수준"의 구조 또는 결정사항으로 생각하고 이야기 하는 경우가 있다.
우리는 흔히 "아키텍처"라는 말은 우리나라말로 "건축"이라고 볼 수 있다.
자 그러면, 건축이라는 것의 사전적인 의미는 무엇일까?
건축(建築, 영어: architecture)은 건물이나 다른 구조물을 계획하고 설계하고 건설하는 과정과 그 결과물이다
(출처 : ko.wikipedia.org/wiki/건축)우리는 이러한 "건축"의 결과물로서 "설계자(Architect)"가 만든 도면을 볼 수 있다.
이러한 도면을 살펴보면, 우리는 무수히 많은 저수준의 세부 사항들도 마찬가지로 확인할 수 있다.
콘센트, 전등 스위치, 전등, 보일러, 온수기의 위치와 크기, 그리고 벽, 지붕의 크기등 고수준의 결정사항을 지탱하는 모든 세부사항을 자세하게 확인할 수 있다.
따라서, 설계(Design)과 아키텍처(Architecture)든 모두 소프트웨어 전체 설계의 구성요소이며 확실히 구분할 수 없다.
* 이후 책에 나오는 내용들 또한 구조에 대한 구성요소 결정에 대해 "설계" 또는 "아키텍처"를 동일한 의미로 설명하고 있음.
2. 좋은 소프트웨어를 위한 설계
소프트웨어 아키텍처(설계)의 목표는 필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화 하는데 있다.
설계 품질의 척도는 고객 요구를 만족 시키는데 드는 비용과 동일하다.
이 비용과 더불어, 설계된 제품의 유지보수 비용 또한 낮게 유지할 수 있다면 좋은 설계라고 할 수 있다.
2.1 사례
다음은, 시장을 선도하는 소프트웨어 제품의 연차별 라이플 사이클이다. 위의 그래프만 보면, 시장 선도를 위해서 초기에 비해 많은 요구사항이 있을 것이고, 많은 수의 개발자가 필요한 것은 당연하게 보인다.
하지만, 위의 소프트웨어 제품의 크기를 보면, 개발자의 수가 비약적으로 증가한 것에 비해, 제품의 크기는 어느순간 정체되었다. 개발자가 늘었음에도 제품의 크기는 정체 되어 있으니 당연히 코드 라인당 유지 보수 비용의 비약적인 증가 또한 필연적이게 된다.
왜 이런 현상이 발생하게 되었을까?
바로, "훌륭하고 깔끔하게 잘 설계된 코드"의 부재에서 비롯되었다.
개발자들은 "코드는 나중에 정리하면 돼. 당장은 시장에 출시하는게 먼저야!"라는 흔한 거짓말에 속아 넘어가게 된다.
물론 "코드를 정리할 시간"이라는 것은 다시 돌아오지 않는다. 다음에 개발해야할 새로운 기능들이 개발자를 기다리고 있기 때문이다. 결국 초기 생산성 향상을 위해 엉망으로 짜여진 코드 때문에 이후 엉망진창인 코드에 대한 유지보수, 수정등에 의해 시간이 지날 수록 생산성을 0%를 향해 수렴해가기 시작한다.
3. 결론
빨리 가는 유일한 방법은 제대로 가는 것이다.
어떤 경우라도 개발 조직이 할 수 있는 최선의 선택지는 개발자의 과신을 방지하고, 소프트웨어 아키텍처의 품질을 심각하게 고민하기 시작하는 것이 첫번째이다.
이를 위해 "클린 아키텍처"에서는 훌륭하고 깔끔한 아키텍처와 설계가 무엇인지 설명하고, 이를 통해 소프트웨어 개발자가 장기간에 걸쳐 수익을 창출하는 시스템을 만들 수 있도록 하는 내용에 대해 다룬다.
'프로그래밍 > 클린 아키텍처' 카테고리의 다른 글
| [클린아키텍처] 3부. 설계원칙 LSP (0) | 2021.03.01 |
|---|---|
| [클린아키텍처] 3부. 설계원칙 OCP (0) | 2021.03.01 |
| [클린아키텍처] 3부. 설계 원칙 SRP (0) | 2021.02.27 |
| [클린아키텍처] 2부. 프로그래밍 패러다임 (0) | 2021.02.24 |
| [클린아키텍처] 1부. 행위와 아키텍처 (0) | 2021.02.20 |
