머가필요해

최근에 소프트웨어 아키텍처 분야는 급격히 발전하고 있으나 아직은 미흡한 상태인지라 단일화된 정의가 아직 나오지 않고 있다. 그러나 소프트웨어 아키텍처의 정의가 아예 없는 것은 아니다. 다양한 소프트웨어 아키텍처 정의의 공통점은 구조와 아키텍처 요소, 그리고 그 요소들 간의 연결관계이다. 하지만 이들에 대한 세부 내용으로 들어가면 너무 다양해져서 공통점을 찾기 어렵다.

소프트웨어 아키텍처에 대한 연구는 설계자들이 따르는 설계 원칙과 설계자들이 실제 시스템에서 작업할 때 수행하는 활동을 관찰하는 데서 발전해왔다. 따라서 소프트웨어 아키텍처에 대한 연구는 시스템 설계에 고유하게 있는 공통성들을 추상화시켜 다양한 행동과 개념, 패턴, 접근 방법, 결과 등을 밝히는 데에 주력했다. 이런 이유로 소프트웨어 공학 커뮤니티마다 소프트웨어 아키텍처에 대한 다른 정의를 내리고 있다.

여기에서는 소프트웨어 아키텍처와 관련한 많은 저작물과 교육활동을 하고 있는 카네기멜론대학(CMU)의 SEI(Software Engineering Institude)에서 내리고 있는 정의를 기반으로 설명을 하겠다.

소프트웨어 아키텍처란,
"프로그램이나 컴퓨팅 시스템의 소프트웨어 아키텍처는 소프트웨어 구성요소와 그들이 지니고 있는 특성 중에 외부에 드러나는 특성, 그리고 구성요소들의 관계를 표현하는 시스템의 구조나 구조체를 말한다."

'외부에 드러나는' 특성이란 하나의 요소에 대해 다른 요소가 품게 되는 가정을 말한다. 예를 들어 그 요소가 제공하는 서비스와 성능 특성, 에러 관리, 공유되는 리소스 사용 등을 말한다. 위의 정의를 좀더 자세히 살펴보자.

첫째, 아케텍처는 소프트웨어 요소를 정의한다. 아키텍처는 요소들 간의 관계 정보를 담고 있다. 이 말은 특정 목적과 관계없는 요소들 간의 관계 정보를 명확하게 한정해서 생략할 수 있다는 의미이다. 이것이 아키텍처에서 가장 중요한 개념인 추상화이다. 다시 말해 아키텍처는 특정 목적과 관련이 없는 요소의 자세한 정보를 생략할 수 있다. 최근의 시스템들은 아키텍처 요소의 인터페이스를 통해 상호작용을 한다. 일반적으로 인터페이스는 공개 인터페이스와 비공개 인터페이스로 구분하는데, 아키텍처는 공개 인터페이스만을 고려한다. 그러므로 내부소통을 위한 비공개 인터페이스는 아키텍처에 표시할 필요가 없다.

둘째, 시스템은 하나 이상의 구조로 구성될 수 있다. 다시 말해 시스템은 한 개 이상의 구조를 포함할 수 있으므로 어느 한 구조만을 아키텍처라고 말할 수는 없다. 아키텍처를 하나의 구조로 한정한다면 많은 이견이 나올 것이다. 예를 들어 대부분의 프로젝트에서 구현 단위를 기준으로 시스템 구조를 나눈다. 이렇게 나뉜 구조는 주어진 책임이 명확하므로 프로그램팀의 업무 분할 기준이 된다. 또한 이 구조는 다른 구현 단위로부터 접근 가능한 공용 프로그램이나 데이터를 포함하거나, 전용 프로그램과 데이터도 포함할 수 있다. 큰 프로젝트에서는 대체로 아키텍처 요소를 나눠 각 요소를 하위 팀에게 할당하는데, 이런 종류의 구조가 시스템을 기술하는데 자주 쓰인다. 이 구조는 매우 정적인 구조로서 시스템을 기능 위주로 나눠 구현팀에게 할당하는 방식에 중점을 둔다.
정적인 구조를 제외한 시스템 구조 중에는 시스템이 기능을 수행할 때 각 요소가 실행시간에 상호작용하는 방식에 초점을 맞춘 경우가 있다. 시스템이 여러 개의 병렬 프로세스로 구현되었다고 가정하면, 이것을 표현하는 구조가 필요할 것이다. 앞에서 설명했듯이 다양한 방법으로 구현되는 프로그램을 실행환경에서 하나 이상의 프로세스로 표현된다. 프로세스 간의 동기화 관계는 시스템을 표현하는 데 사용되는 또 다른 종류의 구조이다.
이런 구조들 중 하나만 가지고 아키텍처라고 할 수 있을까? 그렇지 않다. 각 구조가 아키텍처 정보를 담고 있기는 하겠지만, 하나만으로 아키텍처라고 하기는 어렵다. 아키텍처는 여러 구조들과 그 외 많은 것이 모여서 이뤄진다. 예를 들어 아키텍처가 하나 이상의 구조로 구성된다면 여기에는 한 가지 이상의 아키텍처 요소와 한 가지 이상의 연관관계가 표시될 수 있고, 한 가지 이상의 시점이 존재할 것이다.

셋째, 소프트웨어가 들어간 컴퓨터 시스템에는 전부 소프트웨어 아키텍처가 있다. 아키텍처 요소와 그 사이의 연관관계로 표현할 수 있기 때문이다. 아주 간단한 시스템이라면 시스템 자체를 단일 요소로 본다. 비록 관심도 끌 수 없고 유용하지도 않지만 그래도 아키텍처이다. 모든 시스템에는 아키텍처가 있지만, 그렇다고 해서 항상 그 아키텍처를 누군가가 알고 있다는 뜻은 아니다. 시스템을 디자인한 사람들은 오래 전에 떠나고 관련 문서는 사라졌으며(혹은 만들지도 않았거나) 소스코드 또한 잃어버려서(혹은 산출물로 제출되지 않았거나) 이진 실행 코드만 남아 있다면, 해당 시스템의 아키텍처는 존재하기는 하지만 알아보기는 힘들 것이다. 이 경우처럼 아키텍처 기술서(혹은 명세서)와 동떨어진 아키텍처가 존재하는 경우가 있는데, 이 때문에 아키텍처 문서화와 아키텍처 재건이 중요한 것이다.

넷째, 시스템 요소의 행위를 다른 요소에서 인식할 수 있다면, 이는 아키텍처로 표현될 수 있다. 외부에 드러나는 시스템 요소의 행위는 다른 시스템 요소와의 상호작용 방법을 제시하므로 분명히 아키텍처라고 할 수 있다. 아키텍처라면서 선과 도형으로 그린 그림 중에는 전혀 아키텍처가 아닌 것들이 있다. 단순히 선과 도형으로 그린 도면으로 좀더 관대하게 본다면 실제 요소가 하는 일을 나타내어 정보 단서를 제공해주는 수준일 뿐이다. 만야 운이 좋으면 요소의 이름만으로 행위를 유츄할 수 있다. 즉 요소의 이름이 데이터베이스, 그래픽 사용자 인터페이스, 실행 가능한 프로세스 등으로 표시되어 있다면, 그 이름을 가진 요소들이 어떤 행위를 할지 유추할 수 있을 것이다. 그러나 유추를 하는 사람이 지닌 지식에 따라 아키텍처를 다르게 볼 수 있으므로 문제는 여전히 남아 있다. 모든 요소들의 정확한 행위나 성능에 대해서 자세히 기술할 필요는 없다. 그러나 특정 요소가 다른 요소와 상호연동하는 동작이나, 특정 요소가 시스템에 수용됨으로써 시스템 전체에 미치는 영향 같은 것은 소프트웨어 아키텍처에서 표현돼야 한다.

마지막으로, 아키텍처 정의만으로 잘 만들어진 아키텍처와 그렇지 못한 아키텍처를 구분할 수는 없다. 잘 만들어진 아키텍처는 시스템 행위나 성능, 시스템 생명주기를 좋게 만들 수 있다. 시행착오는 시스템 아키텍처를 잘 만들기 위한 최선의 방법이 될 수 없다. 즉, 아키텍처를 아무렇게나 만들거나 선정하고 나서 좋은 시스템이 만들어지길 바라는 것은 말도 안된다는 뜻이다. 따라서 아키텍처 설계와 아키텍처 평가 방법의 중요성이 더 커진 것이다.