소프트웨어 아키텍처(Architecture)

[마틴 파울러] 소프트웨어 아키텍처의 중요성 (한글자막)

소프트웨어 아키텍처의 정의
아키텍처란 소프트웨어를 구성하고 있는 부품들 간의 연결관계를 의미한다. 소프트웨어를 어떻게 구조화시켜야 되는지, 상위메뉴와 하위메뉴를 어떻게 배치해야 하는지 등등, 소프트웨어를 구성하고 있는 기능 하나하나를 어떻게 관계시킬지에 대한 모든 구조적인 문제가 아키텍처에 해당된다.

건물을 건축할 때의 아키텍처를 예로 들었을 때, 건물의 뼈대가 되는 골격으로 나무, 철골, 시멘트, 벽돌 등의 특성과 관계를 건축의 아키텍처라고 할 수 있다. 뼈대에서 덧붙여지는 전기공사, 난방공사, 건물의 소재를 사용하는 방법과 같은 부분도 아키텍처에 포함된다. 침대를 놓는 위치, 옷장을 놓는 위치에도 이유와 구조가 존재하듯이 '건물'을 이루고 있는 구성요소인 모듈(가구),이나 컴포넌트(방)을 다루는 모든 일련의 시스템 구조와 지침을 아키텍처라고 할 수 있다.




소프트웨어 아키텍처가 중요한 이유
소프트웨어의 '품질'을 결정하기 떄문이다.

품질이란 내가 비용을 지불할 수 있는 어떤 것 이라는 생각에 근거하는 개념이다.하지만 소프트웨어에서 품질이란 전혀 다른 개념이다. 중요한 점은 평가하는 사람이 외부의 사람들이라는 것이다. 그들은 품질을 볼 줄 모른다. 따라서 소프트웨어가 좋은 아키텍쳐를 가지고 있거나 좋은 모듈러 디자인을 가지고 있다고 해도 그것은 겉으로 보여지지 않는다.

소프트웨어의 품질이 외부적 품질(External Quality)과 내부적 품질(Internal Quality)로 나뉠 때 소프트웨어 아키텍쳐는 내부의 품질과 관련되어 있다. 만약 동일한 기능을 가진 두 개의 소프트웨어가 있을 때, 내부적 품질은 비용에 영향을 미치게 된다. 동일한 기능이란 전제 안에서 유저는 보통 내부 품질이 낮더라도 비용이 적게 드는 쪽을 택하게 될 것이다. 그렇다면 겉으로 보이지 않는 '내부적 품질'의 중요함에 대해 우리는 어떻게 유저를 설득할 수 있을까?

소프트웨어의 내부적 품질은 장기적인 관점에서 중요한 것이다. 아래의 그래프를 통해 그 이유를 살펴볼 수 있다.

디자인 스테미너 가설 그래프

상기 그래프는 시간의 흐름에 따른 소프트웨어 기능의 고도화에 대한 그래프이다. 프로젝트를 진행하면서 디자인이나 아키텍쳐에 대해 신경쓰지 않는다면 위와 같은 그래프 모양이 형성된다. 위와 같은 경우 시간이 지날 수록 새로운 기능을 추가하기 어려워진다. 왜냐하면 기능이 추가될 수록 이미 존재하는 소스코드를 바꾸는데 시간이 오래걸리기 때문이다.

디자인 스테미너 가설 그래프

반대로 좋은 아키텍쳐 디자인은 시간이 갈수록, 소프트웨어 기능이 고도화 될 수록 더욱 좋은 효율을 발휘하게 된다. 우리는 좋은 아키텍쳐를 디자인하기 위해서 지속적으로 관심을 기울일 수 있다. 특히 소스코드를 리팩토링하면서 더 나은 방향으로 나아갈 수 있다. 이런 노력을 통해 기능을 추가하는데 어려움을 겪지 않고 오히려 빨라질 수 있다. 소프트웨어가 너무나 잘 컴포넌트화 되어있고, 그저 해야할일은 어떻게 소프트웨어 기능을 변경할지 정하고 변경하는 것이다.

어디를 어떻게 변경할지 더 빨리 찾을 수 있고, 그러면서 가속도가 붙는다. 왜냐하면 이미 존재하는 소스코드가 플랫폼화 되는 것이고, 이 플랫폼 위에서 더욱 빠르게 개발할 수 있게 되는 것이기 때문이다.

위 사진에서 Good Design과 No Design의 교차점을 보더라도, 내부적 품질이 높은 소프트웨어는 짧은 기간 동안에도 빠르게 기능이 추가 되고 있음을 확인할 수 있다. (가파른 그래프) 몇 개월이 아닌 몇주 만에 새로운 기능이 추가되고 업데이트 되는 것이다.



내부적 품질은 떨어지지만 비용은 저렴한 소프트웨어는 구매 시점~짦은 기간 동안에는 이득일 수 있다. 하지만, 더 나은 내부 퀄리티를 가진 소프트웨어를 고른다면 새로운 기능을 더 빠르게 많이 추가할 수 있게 된다. 퀄리티가 낮은 제품은 금방 개선할 수 없게 된다. 이런 케이스들은 우리 주변에서 흔하게 일어나는 현상이다. 우리가 소프트웨어를 지속적으로 업데이트하기 위해 CI, CD를 도입하는 것과 관련이 있다. 지속적으로 기능을 추가하는 것은 그만큼 중요하기 때문이다.


결과적으로 좋은 아키텍쳐, 좋은 퀄리티의 소스코드를 가지기위해 노력하지 않는다면 우리는 결국 더욱 낮은 품질의 소프트웨어를 개발하는데 시간을 쏟고, 더욱 낮은 품질의 결과물을 유저에게 제공하느라 경쟁사와 싸우게되는 매우 비효율적인 프로젝트를 매 시간 진행하게 되는 것이다.

---

소프트웨어 아키텍처의 비즈니스 품질 속성
그렇다면 좋은 품질은 무엇을 의미할까? 소프트웨어 아키텍처의 품질을 결정하는 속성은 다음과 같다.


시장 적시성(Time to Market)
- 지정한 시간에 소프트웨어를 출시해 경쟁력을 높일 수 있는 정도를 의미

비용과 이익(Cost and Benefit)
- 비용의 유연성을 두고 설계할 것인지, 비용을 절감하는데 초점을 맞출 것인지 판단하는 척도

예상 시스템 수명(Predicted lifetime of the system)
- 소프트웨어의 유통기간 및 폐기 시점을 고려해 변경 용이성, 확장성, 이식성 등을 고려하는 정도

목표 시장(Targeted market)
- 소프트웨어를 사용할 고객층을 정확히 파악하여 시장성을 파악하는 정도

신규 발매 일정 또는 공개 일정(Rollout Schedule)
- 소프트웨어의 릴리즈 일정, 유통 일정, 관리 일정을 공개하여 일정대로 관리할 수 있는 정도

기존 시스템과의 통합(Integration with legacy system) 
- 기존 시스템이나 타 시스템과의 통합 방법을 고려한 정도