소프트웨어의 아키텍처 vs 설계 vs 개발 (그게 다 뭐래유?)

많은 개발자들은 매일매일 코드와 고군분투한다. 특히나 새로운 요구사항이 추가될 때마다 과거에 코드 몇줄을 추가하기 위해 혹은 수정하기 위해 누군가가(혹은 본인이) 쓴 의도를 파악할 수 없는 코드를 파악하는데 수많은 노력과 기나긴 시간을 쏟는다. 개발자의 의도가 드러나는 코드와 좋은 소프트웨어 아키텍처는 개발자들의 큰 갈증이었다.

 

(사실 책이 나오기 이전부터도)돌아가기만 하는 소프트웨어가 아닌 확장과 변경이 용이한 소프트웨어를 만들기 위해 다양한 아키텍처와 개발 방법론이 등장했다. 그 중에서도 로버트 마틴(a.k.a 엉클밥)의 저서 클린 코드와 클린 아키텍처는 클린 소프트웨어 아키텍처의 바이블이라고 불리우릴 만큼 개발자들에게 많은 인사이트를 주었다. 

 

좋은 소프트웨어 아키텍처란 단기적으로나 장기적으로 비용을 최소화하고 생산성을 극대화할 수 있는 아키텍처이다.

그리고 예상했듯이 좋은 아키텍처를 가진 소프트웨어는, 아키텍처의 확장성이 높고 소프트웨어 기능 개발과 변경이 쉽다는 특징을 가진다.

 

그렇다면 설계, 아키텍처, 개발 방법론은 뭐가 다를까?

 

설계(design) vs 아키텍처(architecture)

사실 엉클밥은 설계와 아키텍처의 차이가 없다고 본다. 

굳이 나누자면 아키텍처는 저수준의 세부사황과는 분리된 고수준의 것을 가리키는 것이고, 설계는 저수준의 구조 또는 결정사항 등을 의미한다. 

 

고수준의 구조와 저수준의 세부사항 모두 소프트웨어 전체 설계의 구성요소를 이루기에, 아키텍처와 설계가 굉장히 밀접하게 연관되어 있다. 설계와 아키텍처는 전체 설계를 이루는 것으로서 사과를 반으로 쪼개듯 나눌 수 없다. 엉클밥은 고수준(아키텍처)에서 저수준(설계)으로 향하는 의사결정의 연속성만이 있다고 한다. 그리고 의사결정의 목표는 좋은 소프트웨어 설계의 목표로서 유지보수의 인력(비용)을 최소화하고자 한다.

 

즉, 개발자는 좋은 소프트웨어 설계라는 목표를 향해 아키텍처와 이와 연관된 설계를 결정한다.

 

설계(design) vs 개발 방법론(deveolpment)

앞에서 보았듯이 아키텍처와 설계는 공통의 목표를 가지고 있어 비슷한 결로 본다. 지금부터는 설계와 아키텍처를 같은 선상의 것들로 보고, 개발 방법론을 비교해보겠다. 아래에 있는 용어들을 보자.

DDD = Domain Driven Design
TDD = Test Driven Development

 

DDD를 간혹 Development라고 말하시는 분들도 계시는데, 우리가 보편적으로 접하는 DDD의 마지막 D는 Design이다.

DDD는 말그대로 "도메인 주도 설계"라는 뜻이고, TDD는 "테스트 주도 개발"이라는 뜻으로, DDD는 설계, TDD는 개발 방법론이라는 말이다.

 

클라이언트의 요구사항과 설계를 반영한 프로젝틀를 완성하기 위해 개발자들은 작은 기능들 하나하나를 개발한다. 그리고 기능을 개발을 하는 방법은 무수히 다양하다. 개발방법론은 실제 개발을 하는 행위를 어떻게 하는지라고 보면된다. 설계를 집의 구조도, 청사진이라고 보면 개발 방법론은 실제 집을 지을 때 나무 목조틀을 만드는 행위라고 생각하면 된다. 가령 테스트 주도 개발(방법론 = TDD)은 테스트를 먼저 만들고 테스트를 통과하게 만드는 방법으로 개발을 진행하는 것이라고 보면된다. 

 

하지만 아키텍처, 설계, 개발 방법론 모두 소프트웨어를 유연(-> soft)하게 만들기 위한 것들이다.

개념 정의에 집착한 나머지 중요한 가치를 잊어버리는 것을 주의하자.

 

마치며

아키텍처나 개발 방법론 모두 유연한 소프트웨어를 지원하기 위한 것이다. 

좋은 아키텍처에 대한 공동 목표를 가지고 개발자가 고려해야할 유기적인 개념들이라고 생각한다.

 

출처

https://www.trig.com/explore/design-and-development-whats-the-difference

https://www.youtube.com/watch?v=yCUQuX819_8 

책 : 클린 아키텍처