티스토리 뷰

들어가기 전에..

- 제목을 적고 보니 왠지 저 제목과 똑같이 생긴 딱봐도 지루해보이는 소프트웨어 공학 전공서적을 언젠가 도서관에서 본것 같은 착각이 들었다.


- 근 2년동안 '아키텍처'에 대해 배웠던 기억과 현실에서 아키텍처 설계에 대한 현재까지의 경험에 대한 글을 아키텍처에 대한 이론적 내용을 까먹지 않고 아키텍처 설계에 대한 경험도 어느 정도 갖춘 시점에서 작성해보고 싶었는데 이론을 까먹는 속도와 경험의 속도가 다름을 깨달았다..


- 혹시 이 글을 보시고 추가할 부분이나 의견 달아주시면 정말 감사합니다..!


소프트웨어 아키텍처 정의

소프트웨어 아키텍처 분야에서 아버지라 불리우고 자가적응 시스템으로도 유명하신 David Garlan의 논문 서론에서는 아키텍처를 다음과 같이 정의한다.

 

"아키텍처는 요구사항과 구현 사이 중요한 다리 역할 한다시스템의 추상적 묘사를 통해 아키텍처는 다른 것들을 숨기고 어떤 속성들을 노출시키는데 이상적으로 이런 표현은 전체 시스템을 따라갈  있는 가이드 제공하며 설계자가 시스템이 어떤 중요한 요구사항을 만족시킴에 대한 근거를 제공  있게 한다또한 명시적으로 설계를 지배하는 의도나 원리 잡아내어 시스템의 구조와 조합에 대한 청사진을 보여준다."



정의에 따라 아키텍처 설계가 가지는 장점을 몇 가지 언급해 볼 수 있는데

첫째로 시스템에 대한 가이드를 제공하는 것은 이해관계자 스스로의 이해와 더불어 이해관계자나 개발동료간 커뮤니케이션에 도움을 주는 장점이 있다. 

둘째로, 위에서 말하는 중요한 요구사항이란 기능적인 것도 있을 수 있지만 아키텍처 설계에서는 비기능적인 요구사항 예를 들면, 성능이나 보안, 안정성, 이용 가능성, 유지가능성 등에 대한 만족 근거를 제공하는 것에 더 큰 목적을 가진다. 구현이라는 비용 리스크가 큰 프로세스 이전에 설계를 통해 소프트웨어가 이런 요구사항을 달성할 수 있음을 보이는 것은 프로젝트의 리스크를 줄이는 데 큰 도움이 된다. 

마지막으로 설계 의도와 원리에 대해 청사진을 명시적으로 보여줌으로써 만들고자 하는 소프트웨어의 목적과 방향에 대한 합의를 이룰 수 있게 된다. 

이 외에도 Large-scale reuse를 가능하게 며 특히나 같은 도메인에서는 비슷한 아키텍처가 적용가능하다는 점에서 아키텍처 설계를 잘 하는 것이 비즈니스적으로도 이득이 되는 자산이 될 수 있게 된다.


Garlan은 아키텍처의 역할을 이런 장점들을 포함해 6가지로 분류했다.

Understanding, Reuse, Construction, Evolution, Analysis, Management

위에서 빠진 부분은 Evolution, 진화로 이 부분은 Product line과 같이 하나의 제품을 계속해서 발전시켜 나가거나 그 제품에 기반해 또 다른 새로운 제품을 만들어 내거나 하는 경우 설계시 확장시킬 수 있는 바운더리에 대한 분석도 같이 하게 되는데 그런 점에서 판단을 도울 수 있고, 그 외 기능을 확장하는 서비스의 경우에도 미리 확장 가능성을 고려해서 설계해 영향력을 판단할 수 있다.


여기까지 이론적인 부분에 있어서 아키텍처의 정의와 장점을 정리해보았다.

사실 이렇게 많은 장점과 역할에도 불구하고 실제 프로젝트에 적용하는데 있어서는 아직도 와 닿지 않는 부분이 많이 있다.

하지만 프로젝트를 진행하면서 몇 가지 경험들로 정말 현실적으로 시간투자를 해서 아키텍처를 설계하는 과정이 어떤 영향을 주었는지에 대해 위의 중요한 꼭지들을 하나씩 잡아서 말해보면


1. 시스템을 따라갈 수 있는 가이드 제공

아키텍처의 핵심은 요구사항들이 모두 포함된 빅픽처를 보여주는 것이다. 사실 이전 글에서 아키텍처 설계와 그 외 나머지 설계 (코드에 더 가까운)의 차이를 추상-상세로 나누는 것은 문제가 있다고 (아키텍처 설계에서도 중요한 사안이면 상세한 설계까지 들어갈 수 있기 때문에) 언급을 했어서 조금 조심스럽긴 하지만 그럼에도 불구하고 아키텍처는 추상적인 부분에 가깝고 전체 구조를 한 눈에 볼 수 있게 한다. 이 점은 정말 설계에 어마어마한 유용성을 발견하는데 기여했는데 static, dynamic 다이어그램을 옆에 붙여두고 코드 작업하는 것이 모듈이 수십 개 이상 나뉘어져 있을 때 순서나 흐름을 파악하는 데 큰 도움을 주었다.

또 한가지 장점인 아키텍처가 커뮤니케이션 용도로 쓰일 수 있다는 점은 일차적으로 개발자외에는 서비스가 내부적으로 어떻게 동작하는지 크게 궁금해하지 않았으며, 언급할 이유가 (아직까지는) 없었다. 


2. 요구사항을 만족시키는 것에 대한 근거 제공

비기능적 요구사항을 만족시키기 위해서는 설계를 하면서 검증하는 실험과정이 필요한데 사실 이런 실험을 하기 위해서는 선행적으로 알아야 할 Best Practice나 대안들을 이미 알고 있다는 것을 가정으로 가지고 있다는 생각이 크다. 현재 가지고 있는 전략이나 검증 방법의 부재로 사실 비기능적 요구사항에 대해 고민할 수 있는 시간이 거의 없었다. 현재까지 비기능적 요구사항이 크리티컬 하지 않았다는 점도 있지만, 아니다. 있긴 한데 검증방법의 부재가 크다. 하지만 올바른 검증 방법이 있다면 그 효과는 서비스 자체의 내구성이나 지속 가능성에 크게 도움일 되지 않을까 한다.


종합해보면 현재까지는 관리와 개발적인 측면에서 아키텍처가 가지는 유용성은 경험으로 느꼈고

프로젝트가 어느 규모이든 현재 진행하는 대부분의 프로젝트는 아키텍처 설계가 필요하다는 생각이 든다. 



[참고문헌]

Garlan, David. "Software architecture: a travelogue." Proceedings of the on Future of Software Engineering. ACM, 2014.

댓글
댓글쓰기 폼