1. 소프트웨어 아키텍처의 이해
2. 소프트웨어 아키텍처란 무엇일까?
2.1. 소프트웨어 아키텍처의 정의
소프트웨어 아키텍처(software architecture)는 소프트웨어를 구성하는 요소와 요소간의 관계를 정의한것 입니다.
이는 소프트웨어의 전체적인 구성 관계인 구성 요소와 구성 요소간의 포함 관계, 호출 관계 등을 표현하여 소프트웨어 구성 전체를 조망하고 이해하는 데 매우 유용합니다.
2.2. 아키텍처의 표현
아키텍처는 시스템을 조망하고 소통의 도구이므로 이해할 수 있는 언어와 수준으로 작성되고 공유되야 합니다.
아키텍처를 표현하는 언어는 UML(Unified Modeling Language)와 같은 표준화 모델링 언어를 이용하여 작성해야합니다.
표준된 언어를 사용하는 이유
아키텍처를 표현하는 방법이 이를 표현하는 아키텍트(architect) 수준과 설계도 모습도 제각각으로 도식, 표기법으로 작성될 가능성이 높아 다르게 해석가능성이 있습니다.
하나의 아키텍처에는 운영자, 아키텍트, 백엔드 개발자, 프론트엔드 개발자, 품질 담당자 등등 각기 다른 아키텍처를 이해할 수 있는 상황이 발생하게 됩니다. 즉, 다양한 이해관계 각자의 관점에서 시스템을 바라봅니다.
아키텍처의 다양한 관점으로 접근하고 표현되는것을 뷰(view)라 일컫습니다.
4+1 View(뷰)
-
논리 뷰(logic view)
소프트웨어를 구성하는 요소들의 관계 구조 -
프로세스 뷰(process view)
동적 흐름과 스레드(thread), 프로세스(process)등의 동시성 처리 -
구현 뷰(implementaion view)
논리적인 설계의 실제 구현된측면에서 소프트웨어의 구성과 구조 -
배치 뷰(deployment view)
소프트웨어 배치
즉, 4가지의 모든 뷰를 포함하는 중심에는 유스케이스 뷰(usecase view)
View(뷰)란?
시스템과 관련된 다양한 이해관계자들이 소프트웨어의 구조를 쉽게 이해할 수 있게 다양한 관점을 제시하고 표현한 명세
2.3. 아키텍처의 역할
소프트웨어 아키텍처는 폭넓은 시각과 사례를 기반으로 설계되어야합니다. 프로그램들을 연결하고 안정적으로 운영하기 위한 전체적인 뼈대를 설계하는 것이 무엇보다 중요합니다.
즉, 아키텍처는 구성 요소 간의 역할관계가 명확하고 효율적으로 구성될때 탄력적인 아키텍처가 되고, 시스템 품질속성으로 충족할 수 있게 설계되어야 합니다.
3. 소프트웨어 아키텍처 스타일
3.1. 스타일
아키텍처의 스타일은 특정 제약 조건에서 아키텍처의 방향과 접근 방법을 말합니다. 즉, 어떠한 상황에 잘 어울릴 수 있는 방식이나 형태입니다.
3.2. 소프트웨어 아키텍처 스타일
소프트웨어 아키텍처 스타일(software architecture style) 시스템 요건을 충족시키기 위한 제약 조건을 가진 아키텍처 측면의 접근방법입니다. 아키텍처 스타일과 아키텍처 패턴을 흔히 혼용해서 사용하지만 둘 사이에는 차이점이 존재합니다.
스타일은 상호아을 해결할 수 있는 접근 방법을 제시하지만, 정답을 제시해주지는 않습니다. 다만, 스타일에서 제시하는 접근 방법을 선택하면 그만큼 실패할 확률을 줄일 수 있습니다.
즉, 스타일은 접근방식을 제시하고 패턴은 구체적은 해결 전술을 제시한다고 생각하면 됩니다.
아키텍처 스타일 예시
아키텍처 -> 아키텍처 스타일 -> 시스템의 구조가 있으면 아키텍처 접근 방향을 제시하고 아키텍처를 어떻게 설계할지를 고민합니다.
아키텍처 패턴
메시지 전달이나 이벤트처리, Peer to Peer Patten, 이벤트-버스 패턴(Event Bus Pattern), Listener
4. 아키텍처와 아키텍트 역할의 변화
4.1. 모놀리스에서 마이크로서비스로 변화
모놀리스한 아키텍처란?
모든 업무로직이 하나의 애플리케이션 형태로 패키지(package)되어 서비스 되고, 애플리케이션에서 사용하는 데이터 또한 한곳에 모인 데이터를 참조하여 서비스하는 것이 일반적인 형태입니다.
제조회사에서는 약 1000개이상의 프로그램들이 단일 애플리케이션 패키지로 배포하고 돌아가기때문에 일부 프로그램을 수정하려고 하면 단일 애플리케이션이 다시 배포되어야 하는 번거로움과 시간적인 비용이 들어가게 됩니다.
즉, 관리구조의 편리함을 가지고 있지만 변화에 대한 대응이 힘들 수 있습니다.
Cloud, PaaS(Platform as a service)같은 플랫폼 서비스가 지금 수준으로 서비스 되지 않던 시절의 기준에서는 최적의 아키텍처 설계안으로 간주되었습니다.
하지만, 현재에는 서비스를 유연하고 안정적으로 운영할 수 있는 인프라 지원기술들(AWS, Azure)가 등장하면서 서비스 설계의 접근방법과 구축 운영 형태의 패러다임 전환이 일어나고 있습니다. 이때 나타나게 된 것이 마이크로 서비스입니다.
마이크로 서비스
기존 모놀리스와 달리 하나의 큰 애플리케이션을 아주 작은 애플리케이션으로 나누어 서비스하는 사싱입니다. 단일 애플리케이션이 가지는 단점을 해결하고 민첩성과 유연한 시스템을 구축할 수 있습니다.
4.2. 회색지대와 아키텍트
대내외 크고 작은 시스템 통합 프로젝트를 수행하다 보면 업무 영억이나 기술적인 측면에서 담당자가 애매하거나 복잡한 이해관계자들의 의견대립으로 결론나지 않은 상태 혹은 무관심한 상태로 방치되는 영역이 생기게 됩니다.
기술적인 측면에서 팀간의 틈을 메워 주는 역할자는 아키텍트 집단입니다 즉, 조직간에 발생할 수 있는 기술적 이슈와 연결에 대한 해결과 중재, 결과물의 통합과 프로젝트 경계 밖의 요소와 연결하는 역할을 잘 수행하여 프로젝트를 이끄는것들이 아키텍처 집단의 역할이 됩니다.
4.3. 아키텍트 역할의 세분화와 변화
아키텍트들은 프로젝트 모든 기술 요소에 이해수준이 높아야하며 소프트웨어와 하드웨어의 기술 구조를 이해하고 활용을 위한 가이드 배포를 작업하는 수행을 합니다. 모놀리스 형태의 아키텍처든 마이크로서비스 아키텍처구조에 대한 아키텍트 역할에 대한 구분이 필요한 이유중에 하나가 됩니다.
역할의 세분화
소프트웨어 아키텍트, 프론트엔드 아키텍트, 프레임워크 아키텍트, 데이터 아키텍트, 테크니컬 아키텍트, 인프라 아키텍트
4.4. 솔루션 아키텍트
과거에는 아키텍트들이 했던 대부분의 작업 Saas(Software as a service), PaaS(Platform as a service), IaaS(Infrastructure as a service) 등 자동화된 기능으로 지원하게 되었습니다.
예시
- 시스템 자원 구성, 할당, 관리, 모니터링, 소프트웨어 빌드, 통합, 배포 등의 일련의 프로세스들을 최근에는 자동화 시각화
- 인증 권한, 로깅, 모니터링 서비스기능 단위까지도 SaaS형태로 제공
5. 결론
아키텍트들도 기존 온프레미스(on-premise) 형태의 구축성 사업에서 요구하는 역할보다는 하루가 다르게 새롭게 만들어지는 기술 집약적 솔루션의 특징을 이해하고 조합할 줄 아는 능력이 요구되어지고 있습니다.