소프트웨어 아키텍처와 아키텍처 설계

 

소프트웨어 아키텍처

 

아키텍처란 소프트웨어 시스템의 구성 방법에 대한 중대한 결정 사항을 모아 놓은 것입니다. 시스템 구성 요소, 인터페이스, 협력 방법, 조립 방법을 다루며, 단순히 시스템의 구조와 행위만을 다루지 않고, 시스템의 유용성, 기능성, 성능, 탄력성, 재사용성, 이해가능성, 경제성, 기술 한계, 미학과 같은 모든 기준들을 어떻게 절충할지 결정합니다.

 

소프트웨어 아키텍처가 등장한 배경에는 복잡성을 들 수 있습니다. 현재 소프트웨어는 적시성(Time to market, 복잡한 업무를 빨리 만들어야 한다), 우연성(Flexibility, 급변하는 업무 환경에 적응할 수 있도록 유연한 시스템을 만들어야 한다), 통합(Integration, 기존 시스템들을 쉽게 통합하여야 한다)을 기본으로 하며 어느 정도의 복잡성을 기본적으로 가지고 있습니다. 이와 같은 복잡성을 해소하기 위한 방안으로 아키텍처를 구성하게 되는데, 시스템의 전체 구조를 생각하며, 시스템의 구성 요소를 찾아, 시스템 구성 요소들 사이에 일관성과 서로 조화를 이루며, 관계가 명확하고 일정한 규칙을 따르게 하는 것입니다.

 

소프트웨어는 여러 구성 요소로 이루어져 있으며, 아키텍처는 이 구성 요소를 다룹니다. 아키텍처는 구성 요소 처리에 다음과 같은 방법을 제시합니다.

 

 1. 분할하여 정복하라.

 2. 아키텍처는 중요한 구성 요소만 다룬다.

 3. 아키텍처는 시스템 구성 요소들의 관계나 구조, 일관성을 유지하며 조화를 이룬다.

 

이처럼 시스템 구성 요소는 외부에 드라난 인터페이스를 통해 상호작용하고 소프트웨어 아키텍처는 이 상호작용을 다룹니다. 즉 모든 것을 다루는 것이 아니라 중요한 부분만을 다룹니다. 위와 같이 아키텍처는 이해 관계자들이 시스템을 이해하고 의사소통할 수 있게 돕습니다. 또한, 이해 관계자들은 시스템의 다른 특징에 관심이 있습니다. 따라서 이해관계자들의 관심을 표현하고 상충하는 관심을 협상을 통해 절충할 수 있는 공통 언어가 필요합니다. 이 공통 언어가 바로 이키텍처이고 이해 관계자들은 아키텍처를 통해 시스템을 이해할 수 있습니다.

 

또한, 아키텍처는 재사용을 촉진합니다. 특정 문제영역에 적합한 아키텍처를 표준화하여 구성 요소와 상호 작용 방식을 재사용 할 수 있습니다. 아키텍처를 결정하면서 얻은 경험은 다른 곳에도 재사용할 수 있습니다.

 

소프트웨어의 아키텍처 정의는 다음과 같은 사항에 도움이 됩니다.

 

 1. 구현 제약 사항을 정의합니다.

 2. 시스템 개발을 조직화합니다.

 3. 시스템 품질 속성을 결정합니다.

 4. 시스템 변경을 추정하고 관리하기 쉽게 합니다.

 5. 프로토타이핑을 통해 위험을 줄입니다.

 6. 좀 더 정확하게 비용을 산정할 수 있습니다.

 

오늘날 엔터프라이즈 시스템을 구축한다는 것은 간단한 프로그램을 작성하는 것과는 전혀 다릅니다. 무작정 프로그램을 작성하다가 문제가 생기면 뒤엎고 다시 시작할 수는 없는 것입니다. 이에 일관되고 체계적인 프로세스를 통해 견고한 아키텍처를 정립한 후에야 성공적이며 효율적인 엔터프라이즈 시스템을 개발할 수 있게 되는 것입니다.

 

 

 

 

아키텍처 설계

 

아키텍처 설계는 예비 설계(perliminary design) 또는 상위 수준 설계(high-level design)이라 부르며, 시스템의 전체 구조, 기능, 흐름, 구성 요소물을 결정하는 설계입니다. 아키텍처를 설계할 때는 가능하면 단순하게 설계하게 하는 것이 좋은데, 단순한 아키텍처는 설계에 드는 비용이 줄어들고, 개발에서 출시까지의 시간을 단축할 수 있습니다.

 

 

 

아키텍처 설계의 핵심 '관심사의 분리'

 

아키텍처를 설계할 때는 기능 중복을 최소화해야 합니다. 각각의 업무 처리에 트랜잭션 제어 기능이나 보안, 백업 등 다양한 업무가 중복되어 있는 경우 구조가 복잡해지면서 각 업무의 요건이 바뀌는 사태가 발생하면 보수가 불가능한 상태에 빠지게 됩니다. 이는 극단적인 예이지만 본래 트랜잭션 제어 기능이나 보안 기능은 가능한 업무와 독립된 기능으로 설계하면 좋습니다. 따라서 아키텍처를 설계할 때는 기능을 기준으로 분리시켜 설계해야 합니다. 각각의 기능이 시스템과 분리되어 있으면 업무 요건이 바뀌어 기능을 수정해야 할 때 다른 업무 프로그램에 영향을 적게 받게 됩니다.

 

따라서 아키텍처를 설꼐할 때는 기능을 기준으로 분리시켜 설계해야 합니다. 각 각의 기능이 시스템과 분리되어 있으면 업무 요건이 바뀌어 기능을 수정해야할 때 다른 업무 프로그램에 영향을 적게 받게 됩니다. 이와 같이 아키텍처 설계시 '관심사를 분리'하여 업무에 밀접한 기능을 아키텍처로 정리한 후 추후에 필요한 요건을 후속 배치 설계에서 하면 좋습니다.

 

 

 

아키텍처 설계의 핵심

 

첫째, 업무 처리를 실시하기 위해 필요한 중요 기능을 밝혀내 시스템을 구성하는 컴퍼넌트의 후보로 합니다. 여기서 컴퍼넌트는 아키텍처 상 필요한 기능을 추상화한 것이고, 프로그래밍 상의 클래스나 모듈보다 크다 세분화됩니다. 그러나 업무의 기능을 모두 망라할 필요는 없고, 필요한 시스템 기능만 밝혀내면 됩니다.

 

둘째, 밝혀진 컴포넌트의 책무를 검토하여 1개의 컴퍼넌트가 복수의 책무를 가지고 있는 경우 컴퍼넌트의 분할을 검토합니다. 반대로 같은 책무를 담당하는 컴포넌트가 다수 있는 경우에는 1개의 컴포넌트에 통합하는 것을 검토합니다. 분할/통합시에는 컴포넌트끼리 가능한 소결합이 되도록 배려합니다. 이 때 컴포넌트들 간의 레이어화하는 것이 좋은 구조가 되는 경우가 많습니다.

 

셋째, 업무와 시스템적인 기능을 분리해 구조화합니다. 시스템적인 기능은 미들웨어나 체제에 의해서 실현되는 것이 많기 때문에 업무와 명확하게 분리해 두면 좋습니다. 이 때 레이어화를 하면 업무 컴포넌트간의 의존 관계를 알기 쉬워집니다. 또한 레이어에 컴포넌트 배치를 실시하는 과정에서 컴포넌트의 과부족을 알 수 있습니다. 이와 같이 업무와 시스템을 분리해 구조화를 실시하면 업무 담당자는 업무 논리의 개발에 전념할 수 있습니다. 또한 구조화되어 있으므로 변경에 강한 재사용성이 높은 시스템으로 만드는 것이 가능해집니다.

 

 

<참고: 이랜서>