[안영회의 UML 강좌19] - System Architecture - 200308

사실 System Architecture를 논하는 것은 너무 시기 상조가 될 수도 있습니다. 이제 UML을 처음 배우는 입장에서 과연 아키텍쳐에 대해 얼마나 이해를 할 수가 있겠습니까마는 그래도 그 중요성이 크기 때문에 ‘음~ 이런 것이구나!’하는 정도로 이해해보도록 합시다.


아키텍쳐(Architecture)란?

아키텍쳐에 대해서는 많은 정의가 있습니다. 그만큼 한마디로 정의를 내리기가 쉽지 않다는 반증이겠죠. 우선 아키텍쳐를 설계(Design)와 빗대어 생각해볼까요? 설계가 시스템의 필수적인 기능의 구현을 위한 논리적인 구성에 대해 다룬다면 아키텍쳐는 그와는 다른 점들을 고민한다고 할 수 있습니다.

가령, 기능적으로 볼 때 여러 가지 대안이 있을 수 있습니다. 늘 답은 하나가 아니기 마련이죠. 아키텍쳐 측면에서는 시스템의 성능이나 유연성 측면, 생산성이나 비용까지 고려하여 이들 대안 중에 하나를 고르게 되는 것이죠. 또 다른 측면으로 이해를 도울 그림을 하나 보죠.

그림 19-1. 아키텍쳐의 4+1 View

그림 19-1은 전에도 살펴보았던 그림이죠? 이번에는 아파트 건축에 비유해서 생각해봅시다. 만일 당신이 아파트 건축을 책임진 사람이라고 합시다. 당신이 아파트의 실내 인테리어 담당자나 배선, 도색 등의 일부 역할을 맡은 사람이라면 아파트의 특정한 모습만 상상하면 될 것입니다.

인테리어 담당자라면 실내 공간의 크기와 모양을 계산하고, 인테리어를 적용한 모델만 만들어내면 되겠죠. 배선 담당자라면 아파트 한 동의 높이와 길이를 알아내고, 각각 방이나 거실 등의 위치를 알아내어 배선도를 작성하면 크게 문제가 없을 것입니다. 도색을 담당한 사람도 이와 비슷하겠죠.

그렇지만, 건축 전체를 맡은 사람이라면 다각적인 이해를 해야 합니다. 아무리 배선이 잘 되었더라도 건물이 부실하다면 좋은 아파트가 아니며, 아무리 실내 인테리어가 뛰어나더라도 물이 제대로 안 나오거나 전기나 가스 공급이 제대로 이뤄지지 않는다면 매우 곤란하겠죠.

이렇듯 모든 측면을 고려하는 사람을 아키텍트(Architect)라고 합니다. 이러한 아키텍트가 아키텍쳐를 만들어냅니다. 건축에 있어서의 아키텍트도 배선이나 인테리어 담당자가 맡고 있는 업무를 동일한 수준까지 알아야 할 필요는 없겠죠. 이들 일은 그들의 몫이니까 아키텍트는 전체적인 상황을 파악하는 것이 더 중요합니다.

즉, 좀더 추상화 된 이해를 필요로 한다는 것이죠. 건물 내부에서 건물을 보면 자세히 관찰할 수는 있지만 전체적인 모습을 보기란 매우 힘듭니다. 반면, 높은 곳에서 건물을 내려다 보면 자세한 정보를 얻기는 힘들지만 다양한 측면에서 건물을 관찰할 수 있습니다. 이렇듯 아키텍쳐는 높은 곳에서 바라본 모델이라고 말할 수 있습니다.

그림 19-1은 이처럼 시스템 아키텍쳐가 시스템을 다각도로 바라볼 수 있다는 것을 나타낸 것입니다. Philippe Krutchten이 제안한 것으로 RUP에서 아키텍쳐를 조망하는 중요한 5가지 View를 제시한 것입니다.

한번의 강좌로 이들 각각에 대해 깊이 있는 논의를 하는 것은 무리입니다. 다만, 이들 각각에 대해 주요한 시사점을 파악하는데 주력하도록 하죠.

논리적 관점(Logical View) 혹은 디자인 관점(Design View)

논리적 관점에서의 아키텍쳐는 시스템의 주요한 기능적인 요구사항에 대한 것입니다. 그림 19-2는 수강신청 시스템 예제의 논리적인 관점에서의 아키텍쳐를 나타내는 다이어그램입니다.

그림 19-2 수강신청 시스템의 논리적인 아키텍쳐

논리적인 관점의 아키텍쳐와 설계의 주된 차이점은 기능적인 요구사항 하나 하나를 다루는 것이 설계라면 아키텍쳐에서는 전체적인 시스템의 기능에 영향을 미치는 설계 전략(design strategy)을 결정하는 것이 아키텍쳐라고 하겠습니다.

가령, 구현 언어를 결정한다던가 사용할 DB를 결정하는 일, GUI를 결정하는 일은 설계자의 역할이기 보다는 아키텍트 혹은 아키텍쳐를 담당하는 팀의 몫이겠죠.


구현 관점(Implementation View)

구현관점의 아키텍쳐는 실제 소프트웨어 모듈의 조직에 관한 것입니다. 논리적인 것이 아니라 실제로 구동하는 시스템의 모습에 관한 것이죠.

논리적 관점에서의 패키지가 논리적인 기능별 묶음이었다고 하면 구현관점에서의 패키지는 물리적인 묶음으로 변모합니다. 이러한 패키지들은 보통 잘 정의된 인터페이스에 의해 나누어지면서 층(Layer)을 이루게 됩니다. 이러한 층(Layer)은 J2EE와 같은 응용프로그램 개발 프레임워크에서 제시하는 Tier와 일맥상통하는 것이죠.

그림 19-3. J2EE의 응용 프로그램 모델

한편, 설계에서의 하나 이상의 클래스는 구현관점에서 하나 이상의 컴포턴트로 나타내어지게 됩니다. 하나의 클래스가 하나의 컴포넌트가 되기도 하지만, 더러는 패턴을 이루는 클래스들이 하나의 컴포넌트가 되기도 하죠. 최근 불고 있는 디자인 패턴 열풍은 바로 아키텍쳐 관점에서 좋은 소프트웨어 설계를 위한 노력의 일환이라고 볼 수 있습니다.

그림 19-4. 컴포넌트 다이어그램

Rose에서 구현관점은 ‘Component View’ 패키지 내에서 컴포넌트 모델로 표현됩니다.


프로세스 관점(Process View)

프로세스관점은 구현관점과 유사합니다. 다만, 구현관점이 개발 과정에서의 소프트웨어 구조라면 프로세스관점은 실행 시(run-time)를 다룬다는 것이 차이점이죠. 따라서, UML 표현은 구현관점과 프로세스관점 모두 동일한 방식을 취합니다. 모델의 차이는 실제 구현 시에 어떠한 형태를 띄느냐 하는 것이죠. 가령, ‘EXE로 구동하느냐’, 아니면 ‘DLL 형태로 구동하느냐’ 하는 것들이죠.


배포 관점(Deployment View)

배포관점은 그야말로 시스템이 실제 배치되는 모습에 관한 것입니다. 인터넷과 무선 통신 등의 발달로 점차 프로그램이 분산화 되는 측면에서 갈수록 중요성이 강화되는 측면이라고 하겠죠. Rose에서는 ‘Deployment View’라는 다이어그램을 기본적으로 갖고 있어 배포도를 나타내도록 하고 있습니다.


유스케이스 관점(Use Case View)

19-1의 그림을 보면 유스케이스 관점은 다른 관점들을 묶으며 이들 가운데 위치하게 됩니다. 유스케이스 관점의 키워드는 ‘통합’입니다. 앞서 언급한 관점들은 각기 다른 시사점을 제시합니다. 이들 중 어느 하나의 관점을 강조하면 다른 하나의 관점에서는 상대적으로 악영향을 미칠 수가 있습니다. 가령, 성능을 높이기 위해 프로세스 관점에서 변화를 주자 논리적인 관점에서 설계 모델의 유연성이 떨어졌다고 합시다. 이것은 올바른 의사결정인가요?

이러한 관점의 차이에서 오는 마찰을 어떻게 극복할 것인가? 이들을 통합해주는 유스케이스에 그 답이 있다는 것이죠. 시스템의 가치는 유스케이스로 평가 받습니다. 즉, 평가는 고객의 몫이라는 것이지 단순히 성능이나 유연성, 유지보수성 등으로만은 이야기할 수 없습니다. 아키텍쳐에 대한 이들 각각의 관점은 결국 유스케이스 관점에서 평가하고, 검증할 수 있다는 것입니다.