아키텍처 설계란?
소프트웨어를 위한 아키텍처 설계는 빌딩의 아키텍처 설계와 유사합니다. 빌딩은 방과 여러 서브시스템, 예를 들면 난방, 에어컨, 전기, 가스, 수도 등의 배관을 포함하고 있습니다. 각 서브시스템은 나름대로의 목적과 빌딩전체의 기능 및 용도에 대하여 기여하고 있습니다. 빌딩의 아키텍처 설계는 주요 컴포넌트와 서브시스템을 강조하고 어떻게 서로 연관되어 있고 작동하는지 알려줍니다.
아키텍처 설계의 정의
먼저 아키텍처와 아키텍처 설계에 대한 정의는 다음과 같다.
정의 아키텍처 설계
소프트웨어 아키텍처란 주요 컴포넌트 사이의 인터페이스와 인터랙션을 포함한 시스템 구조의 설계 유형을 말합니다. 아키텍처 설계는 개발 중인 시스템에 대한 아키텍처를 정하는 의사 결정 과정입니다.
아키텍처를 소프트웨어 구조의 유형이라고 한다면 그 안에 특정한 설계의 결정이 포함되어 있습니다. 그리고 아키텍처는 의사결정의 결과라 할 수 있습니다. 이런 의미에서 소프트웨어 아키텍처는 설계 결정의 집합체입니다.
아키텍처를 설계의 유형이라고 보는 관점과 설계 결정의 집합이라고 보는 두 가지 견해가 있습니다. 설계유형이라는 관점은 눈에 보이며 이해하기가 쉽습니다. 시스템의 아키텍처를 서브시스템과 그 관계로 가시화할 수 있기 때문입니다. 반면 설계 결정은 아키텍처를 사용하기 위한 근거로 의미가 있습니다.
소프트웨어 아키텍처의 예로는 계층구조 스타일, 클라이언트-서버 스타일, MVC 스타일, 브로커 스타일, 트랜젝션 처리 스타일, 파이프라인 스타일이 있습니다. 계층구조는 시스템을 여러 층으로 나누고 각 층은 하위층이 제공하는 서비스를 이용하는 구조입니다. 클라이언트-서버 구조는 서버 컴포넌트가 클라이언트라 불리는 다른 컴포넌트에게 서비스를 제공하는 스타일입니다. MVC 구조는 데이터와 뷰, 컨트롤 부분으로 나누어 컨트롤 부분이 데이터 모델에서 뷰를 분리해 내는 역할을 합니다. 데이터가 테이블, 파이차트, 히스토그램 차트 등 여러 가지 뷰를 이용하여 디스플레이 됩니다.
아키텍처에 관하여 계속 설명하기 위하여 시스템의 구조를 이루는 부품에 대한 중요한 용어를 미리 정의해 둡니다. 서브시스템, 컴포넌트, 모듈 세 가지 용어는 같은 의미로 혼용되기도 합니다. 그러나 이 포스팅에서는 각 용어에 다음과 같은 의미로 사용할 것입니다. 컴포넌트와 모듈은 시스템이 구체적으로 구현된 부분을 나타냅니다.
컴포넌트
컴포넌트란 명백한 역할을 가지고 있으며 독립적으로 존재할 수 있는 시스템의 부분입니다. 같은 기능을 가진 다른 컴포넌트로 대체시킬 수 있습니다.
대부분의 컴포넌트들은 재사용 가능하도록 설계된다. 반면 특정한 목적, 예를 들면 특정 시스템의 사용자 인터페이스를 제공하는 기능 등을 수행하는 경우도 있습니다. 프레임워크는 컴포넌트의 한 종류입니다. 원시코드 파일과 실행 파일, 동적링크 라이브러리(DLLs), 데이터베이스 등도 또 다른 컴포넌트입니다. 원시코드 파일 같은 컴포넌트들은 단지 컴파일 시간에만 존재하며, 데이터 파일 등의 다른 컴포넌트들은 실행 시간에만 존재합니다.
모듈
모듈이란 프로그래밍 언어의 문법 구조에서 정의된 컴포넌트를 말한다.
모듈(module)이라는 용어는 구체적인 프로그래밍 언어로 작성된 문법단위로 한정하여 사용하기로 합시다. 예를 들어 메소드, 클래스, 패키지는 Java 프로그램의 모듈이다. C 프로그래밍 언어에서의 모듈은 파일과 함수입니다.
서브시스템은 여러 다른 방법들로 구현될 개체를 나타낸다. 따라서 컴포넌트나 모듈보다는 더 추상적입니다. 시스템은 정의 가능한 책임과 목적들을 가지고 있고 소프트웨어나 하드웨어로 구성된 논리적 개체입니다. 시스템은 컴포넌트들이 시간이 흐름에 따라 변하거나 다른 컴포넌트로 교체되더라도 지속적으로 존재하는 것입니다. 서브시스템은 보다 큰 시스템의 일부분으로 유한한 인터페이스를 가집니다. Java 언어는 서브시스템을 구현하기 위해 패키지를 사용하며 별개의 클래스는 더 낮은 수준의 개별적인 서브시스템을 구현한다.
아키텍처 설계의 중요성
아키텍처의 중요성은 아무리 강조해도 지나치지 않습니다. 예를 들어 다음과 같은 실제 일어났던 스토리를 소개하겠습니다. Ontologies라는 객체지향 데이터베이스를 사용하는 중규모의 C++ 언어를 사용한 소프트웨어를 개발하는 프로젝트가 있었습니다. 지금은 Ontologies를 잘 모르겠지만 1990년대에는 잘 나가던 제품이었다. Ontologies는 C++ 언어에 질의 어를 제공합니다. 즉 C++ 프로그램이 직접 데이터베이스에 접근할 수 있음을 의미합니다. 비즈니스 객체가 데이터베이스와 잘 통합된 것입니다. 하지만 통합, 즉 강하게 결합된 경우 잘 다루지 못하면 문제가 될 수 있습니다. 예를 들어 애플리케이션 코드가 써드파티 컴포넌트인 데이터베이스에 너무 의존하게 되고 만일 데이터베이스가 바뀐다면 애플리케이션 코드의 대부분을 수정하여야 합니다. 이런 위험을 피하려면 애플리케이션 객체로부터 데이터베이스를 숨기기 위하여 데이터베이스 래퍼 (wrapper)를 개발하여야 합니다. 이렇게 하면 데이터베이스가 갱신되거나 교체되었을 때 비즈니스 객체에 대하여 보호할 수 있습니다. 데이터베이스가 바뀐다면 비즈니스 객체를 그대로 두고 래퍼만 수정하면 됩니다. 비즈니스 객체보다는 래퍼는 변경하기가 훨씬 쉽습니다. 불행하게도 개발팀은 복잡하고 비효율적이고 시간이 많이 걸릴 것이라고 판단하여 이 방법을 거부하였습니다. 이것이 프로젝트의 초반에 있었던 일입니다.
10개월 후 대부분의 시스템이 개발되었을 때 Ontologies 회사에서 내분이 있다는 소문이 있었습니다. 결과적으로 기술에 중요한 역할을 맡고 있는 공동설립 자가 회사를 떠나 다른 회사를 차리겠다고 위협하였습니다. Ontologies에 의존하 던 개발팀은 긴장하고 Ontologies 직원들이 남아주기를 바랬습니다. 1개월 후 소문이 현실로 다가왔다. 공동설립자는 회사를 떠나 새 회사를 차렸습니다. 성공을 바라보던 프로젝트는 처참하게 되었습니다. 개발팀은 래퍼를 구현하기 시작하였으나 이미 때는 너무 늦었습니다. 프로젝트는 일정이 너무 늦어졌습니다. Ontologies 회사는 2개월 후 파산하였고 개발팀도 2개월 후 해체되었습니다.
참고자료 출처 : 새로쓴 소프트웨어 공학 (저자 : 최은만)