소프트웨어 아키텍처란 무엇인가?

Peter Eeles│IBM

아키텍팅(architecting)”에 대한 기본적인 개념에 접근하는 총 4부 시리즈 중 첫 번째 글입니다. 필자는 핵심 용어들을 정의하고 잘 설계된 아키텍처가 전개 환경에 어떤 기여를 하는지를 조명합니다.

이 세계는 점점 더 소프트웨어에 의존하고 있다. 소프트웨어는 유비쿼터스 셀폰 뿐만 아니라 복잡한 항공 제어 시스템의 필수적인 요소이다. 사실 우리가 지금 당연하다고 여기는 많은 혁신들도 소프트웨어가 없었다면 존재하지 않았을 것이다. 금융, 유통, 공공 분야 같은 전통적인 조직도 소프트웨어에 깊이 의존하고 있다.

이러한 혁신과 기업들이 살아 남기 위해서, 소프트웨어는 필요한 기능을 제공해야 하고, 품질도 갖추어야 하고, 기대하는 대로 사용할 수 있어야 하며, 합리적인 가격에 제공되어야 한다.

이 모든 특성들은 소프트웨어의 아키텍처에 영향을 받는다. 나는 이 글에서 “소프트웨어 중심 시스템(software-intensive systems)”에 대해 이야기하고자 한다. IEEE는 다음과 같이 정의한다.

소프트웨어 중심 시스템(software-intensive system)은 소프트웨어가 디자인, 구현, 전개, 시스템의 진화에 중요한 영향을 미치는 시스템을 의미한다. [IEEE 1471. "아키텍처 정의" 섹션 참조]

이 글에서 “아키텍처”라는 용어는 “소프트웨어 아키텍처”의 동의어이다. 이 글에서는 소프트웨어 중심 시스템을 중심적으로 다루겠지만, 소프트웨어 중심 시스템 역시 신뢰성이나 퍼포먼스 같은 특정 품질을 제대로 이행하기 위해서는 하드웨어가 필요하다. 나중에 보다 자세히 설명하도록 하겠다.

아키텍처 정의

“아키텍처”에 대한 정의는 부족함이 없다. 정의만을 모아서 관리하는 웹 사이트가 있을 정도니까 말이다.1 이 글에 사용되는 정의는 IEEE Std 1472000- IEEE Recommended Practice for Architectural Description of Software-Intensive Systems(IEEE 1471)2에서 발췌하였다. 핵심 내용은 볼드체로 표시했다.

아키텍처는 컴포넌트로 구체화된 시스템의 기본적인 조직이며, 환경에 대한 관계이며, 디자인과 진화를 이끄는 원리이다. [IEEE 1471]

이 표준은 이 정의와 관련하여 다음 용어를 정의하고 있다.

시스템은 특정 기능이나 기능 세트를 달성하도록 조직된 컴포넌트의 컬렉션이다. 시스템이라는 용어에는 개별 애플리케이션, 전통적인 의미의 시스템, 하위 시스템, 시스템의 시스템, 제품 라인, 제품군, 전체 엔터프라이즈, 기타 이익의 집합 등을 아우른다. 시스템은 이 환경에서 한 개 이상의 미션을 수행하기 위해 존재한다. [IEEE 1471]

환경또는 컨텍스트는 그 시스템에 대한 개발, 작동, 정책, 기타 영향들의 설정과 환경을 결정한다. [IEEE 1471]

미션은 스테이크홀더가 목표를 달성하기 위해 시스템이 수행할 사용이나 연산이다. [IEEE 1471]

스테이크홀더는 시스템에 관련된 개인, 팀, 조직이다. [IEEE 1471]

우리들도 볼 수 있듯이, “컴포넌트”라는 용어는 이러한 정의 전반에 걸쳐 사용된다. 하지만 아키텍처의 대부분의 정의는 “컴포넌트”를 정의하지는 않는다. IEEE 1471도 예외는 아니다. 따라서 산업계에서 여러 가지 의미로 사용하기 때문에 매우 모호하다. 컴포넌트는 논리적이거나 물리적이거나, 기술 독립적이거나 기술적이거나, 대단위 이거나 소단위 이거나이다. 이 글의 목적상 나는 UML 2.0 스팩에서의 컴포넌트의 정의를 사용한다. 그리고 나는 우리가 마주칠 수 있는 다양한 아키텍처 엘리먼트를 아우르기 위해 매우 느슨하게 용어를 사용하겠다. 객체, 기술 컴포넌트(이를 테면, Enterprise JavaBean), 서비스, 프로그램 모듈, 레거시 시스템, 패키지 애플리케이션 등이 포함된다. 다음은 “컴포넌트”에 대한 UML 2.0D의 정의이다.

[컴포넌트는] 이것의 콘텐츠를 담고 있는 시스템의 모듈 부분이고 이것의 표현은 이것의 환경 내에서 대체 가능하다. 컴포넌트는 제공된 필수 인터페이스의 관점에서 작동을 정의한다. 컴포넌트는 유형으로서 작동하고 이것의 순응성은 필요한 인터페이스에 의해 정의된다. (정적 및 동적 의미로 정의된다.)

여기에 제공된 정의는 많은 다른 개념들을 아우른다. 이것은 이 글 후반에 논의되겠다. 산업계에는 “아키텍처”에 대해 일반적으로 동의된 정의가 없지만 다른 정의들도 고려하여 이들간 유사성을 관찰해 보는 것도 좋은 일이다. 중요한 내용은 볼드체로 표시했다.

아키텍처는 소프트웨어 시스템의 구성, 구조적 엘리먼트와 시스템을 구성할 인터페이스의 선택, 그러한 엘리먼트들간 협업에 지정된 것으로서 작동과 함께, 그러한 엘리먼트를 점진적으로 더 큰 하위 시스템으로의 구성, 이러한 조직을 이끄는 아키텍처 스타일, 이러한 엘리먼트와 인터페이스, 협업, 구성에 대한 중요한 결정 세트이다. [Kruchten]4

프로그램 또는 컴퓨팅 시스템의 소프트웨어 아키텍처는 소프트웨어 엘리먼트를 구성하는 시스템의 구조 또는 구조이자, 그러한 엘리먼트들을 외부로 보이는 속성이자 이들간 관계이다. [Bass et al] 5

[아키텍처는] 조직화된 구조이며 시스템의 제휴된 작동이다. 시스템의 제휴된 작동이다. 아키텍처는 인터페이스, 부분들과의 관계, 어셈블링의 제약조건 등으로 분할될 수 있다. 인터페이스를 통해 인터랙팅하는 부분들에는 클래스, 컴포넌트, 하위 시스템 등이 있다. [UML 1.5]6

시스템의 소프트웨어 아키텍처나 시스템의 컬렉션은 소프트웨어 구조와, 그 시스템을 구성하고 있는 구조들 간 인터랙션에 대한 중요한 디자인 결정들로 구성되어 있다. 디자인 결정은 원하는 품질을 보장해야 한다. 디자인 결정은 시스템 개발, 지원, 관리에 개념적인 기반을 제공한다. [McGovern]7

정의는 다소 다르더라도 우리는 여기에서 공통점을 발견하게 된다. 예를 들어, 모든 정의는 아키텍처는 구조와 작동에 관한 것이며, 중요한 결정들만 관여하며, 아키텍처 스타일에 순응하고, 스테이크홀더와 환경에 영향을 받으며, 이론적 근거에 입각하여 결정을 구체화 한다. 이제부터 자세히 설명하도록 하겠다.

아키텍처가 구조를 정의한다.

누군가가 당신에게 “아키텍처”에 대해 설명하라고 하면 십중팔구는 구조라고 말할 것이다. 이것은 빌딩 또는 다리 같은 도시 엔지니어링 구조와 관련이 있다. 작동, 적합성, 미학 같은 아이템의 다른 특성들도 물론 존재하지만 이것이 가장 익숙하고 자주 언급되는 구조적인 특성이다.

당신이 누군가에게 그가 작업하고 있는 소프트웨어 시스템의 아키텍처에 대해 설명하라고 요청하면 그는 시스템의 구조적 양상을 보여주는 다이어그램을 보여줄 것이다. 이 양상이 아키텍처 레이어든, 컴포넌트든, 분산 노드든 상관없이 말이다. 구조는 아키텍처의 진실로 중요한 특성이다. 아키텍처의 구조적 양상은 여러 가지 방법으로 드러나기 때문에 아키텍처에 대한 정의는 모호하다. 구조적 엘리먼트는 하위 시스템, 프로세스, 라이브러리, 데이터베이스, 전산 노드, 레거시 시스템, 제품 등이 될 수 있다.

아키텍처의 많은 정의들은 구조적 엘리먼트를 인정할 뿐만 아니라 구조적 엘리먼트의 구성, 이들의 관계, 인터페이스, 파티셔닝도 다루고 있다. 이들 각 엘리먼트들은 다양한 방식으로 제공될 수 있다. 예를 들어, 커넥터는 소켓이 될 수 있고, 동기식 또는 비동기식일 수 있으며 특정 프로토콜과 제휴될 수 있다.

그림 1은 구조적 엘리먼트의 예제이다. 이 그림은 주문 처리 시스템을 나타내는 구조적 엘리먼트들을 포함하고 있는 UML 클래스 다이어그램을 보여주고 있다. 세 개의 클래스 OrderEntry, CustomerManagement, AccountManagement가 있다. OrderEntry 클래스는 CustomerManagement 클래스와 AccountManagement 클래스에 의존하여 나타난다.

아키텍처가 작동을 정의한다.

아키텍처가 구조적 엘리먼트를 정의하는 것 외에도 구조적 엘리먼트들간 인터랙션을 정의한다. 원하는 시스템 작동을 제공하는 것이 이러한 인터랙션이다. 그림 2는 UML 시퀀스 다이어그램으로서 많은 인터랙션들을 보여주고 있다. 시스템은 주문 처리 시스템에서 주문의 생성을 지원할 수 있다. 여기에서 다섯 개의 인터랙션이 보인다. 첫 번째는 Sales Clerk 액터가 OrderEntry 클래스의 인스턴스를 사용하여 주문을 만든다. OrderEntry 인스턴스는 CustomerManagement 클래스의 인스턴스를 사용하여 고객의 상세를 얻는다. OrderEntry 인스턴스는 AccountManagement 클래스의 인스턴스를 사용하여 주문을 만들고, 주문 아이템들에 주문을 파퓰레이트 하고 주문을 한다.

그림 2는 그림 1의 연장선상에 있다. 그림 2에서 정의된 인터랙션에서 그림 1에서 보여준 종속관계를 이끌어 낼 수 있다. 예를 들어, 그림 2의 인터랙션을 보면 OrderEntry는 CustomerManagement의 인스턴스에 의존한다. 이러한 의존성은 상응하는 OrderEntry와 CustomerManagement 클래스 간 의존성 관계에 반영된다. (그림 1)

아키텍처가 중요한 엘리먼트에 집중한다.

아키텍처가 구조와 작동을 정의하지만 모든 구조와 모든 작동에 대해서 그렇게 하는 것은 아니다. 오직 중요한 엘리먼트들에만 그렇게 한다. 중요한 엘리먼트는 길고 지속적인 영향력을 갖고 있는 엘리먼트이다. 이러한 엘리먼트들은 필수 작동과 제휴되어 있고 신뢰성과 확장성 같은 중요한 품질을 다루고 있다. 일반적으로 아키텍처는 이러한 엘리먼트의 세분화된 상세를 신경 쓰지 않는다. 아키텍처 중요성은 경제적인 중요성도 띤다. 특정 엘리먼트를 다른 것보다 귀중히 여기는 이유는 생성 비용과 변경 비용이 관련되어 있기 때문이다.

아키텍처가 중요한 엘리먼트에만 집중하기 때문에 시스템 관점에서 생각해 봐야 한다. 이는 대부분 아키텍처와 관련이 있다.8 아키텍처는 아키텍트가 복잡성을 관리하는 것을 돕는 시스템의 추상화이다.

중요한 엘리먼트 세트는 정적이지 않고 시간이 지나면서 변한다. 변화하는 요구 사항, 리스크 분석, 실행 가능한 소프트웨어 구현, 레슨 등의 결과로 중요한 엘리먼트는 변하기 마련이다. 하지만 변화에 직면해서도 아키텍처가 안정적이라는 것은 좋은 아키텍처라는 신호이자, 아키텍팅 과정이 잘 실행되었다는 신호이며, 좋은 아키텍트라는 신호이다. 아키텍처가 비교적 소소한 변경 때문에 지속적으로 개정되어야 한다면 이것은 좋은 징조가 아니다. 하지만 아키텍처가 비교적 안정적이라면 정 반대이다.

아키텍처가 스테이크홀더의 필요를 조정한다.

아키텍처는 궁극적으로 스테이크홀더의 필요를 다루기 위해 만들어진다. 하지만 모든 필요를 다 맞추기는 불가능하다. 예를 들어, 스테이크홀더가 지정된 시간 안에 특정 기능을 요청하지만 이러한 두 가지 필요(기능과 타임프레임)은 상호 배타적이다. 스케줄러에 맞추기 위해 범위게 줄어들거나, 초과된 타임프레임에서 기능이 제공 될 수도 있는 것이다. 이와 비슷하게 다른 스테이크홀더들은 상충하는 필요를 표현하기 때문에 적절한 밸런스가 필요하다. 따라서 트레이드오프는 아키텍팅 프로세스와 협상의 중요한 측면이자 아키텍트가 갖추어야 할 자질이다.

스테이크홀더들의 필요에 대해 생각해 보자.

ㆍ 엔드 유저는 매력적이고 정확한 작동, 퍼포먼스, 신뢰성, 가용성, 보안 등에 관심이 있다.
ㆍ 시스템 관리자는 매력적인 작동, 관리, 모니터링 툴에 관심이 있다.
ㆍ 마케터는 경쟁력 있는 기능, 출시일, 다른 제품들과의 포지셔닝, 비용 등에 관심이 있다.
ㆍ 고객은 비용, 안정성, 스케줄에 관심이 있다.
ㆍ 개발자는 명확한 요구 사항, 간단하고 일관성 있는 디자인 방식을 원한다.
ㆍ 프로젝트 매니저는 프로젝트 예견, 스케줄, 효과적인 자원활용, 예산 등을 신경 쓴다.
ㆍ 유지 보수를 하는 사람들은 포괄적이고 일관되면서 문서화가 된 디자인 방식과 변경의 용이성 등을 생각한다.

이 리스트를 보면 알겠지만 아키텍트의 또 다른 도전은 스테이크홀더들이 시스템이 필요한 기능을 제공하는 것에만 관심을 갖는 것은 아니라는 점이다. 위에 제시한 관심 영역들은 비기능적이다. 시스템의 기능에는 어떤 기여도 하지 않는다. (비용과 스케줄링 등). 이 같은 영역은 시스템 품질이나 제약조건을 나타낸다. 비기능적 요구 사항들은 아키텍트에 있어서 가장 중요한 요구 사항이다.

아키텍처가 이론에 입각한 결정을 구체화 한다.

아키텍처의 중요한 측면은 단순히 최종 결과인 아키텍처에 있지 않다. 이론적 근거가 필요하다. 따라서 아키텍처와 결정에 대한 이론적 근거를 문서화 하는 것이 중요하다.

이 정보는 많은 스테이크홀더와 관련이 있다. 특히 시스템을 관리해야 하는 사람들과 관련이 있다. 이 정보는 결정에 대한 이론적 근거를 알고 싶어하는 아키텍트에게도 매우 귀중한 것이다. 예를 들어, 이 정보는 아키텍처가 리뷰 될 때와 아키텍트가 결정을 판단할 때 사용된다.

아키텍처가 아키텍처 스타일에 순응한다.

대부분의 아키텍처들은 비슷한 영역들을 공유하는 시스템에서 파생된다. 이러한 유사성을 아키텍처 스타일이라고 한다. 이는 특정 유형의 패턴으로도 생각할 수 있다. 종종 복잡한 합성 패턴일 때가 많다. (많은 패턴들이 함께 적용된다.) 패턴과 마찬가지로 아키텍처 스타일은 경험의 성문화를 나타내고, 아키텍트가 그러한 경험들을 재사용 할 기회를 찾는 것은 좋은 방법이다. 아키텍처 스타일의 예제에는 분산 스타일, 파이프와 필터 스타일, 데이터 중심 스타일, 규칙 기반 스타일 등이 있다. 시스템은 한 가지 이상의 아키텍처 스타일을 보여준다. Shaw 와 Garlan은 다음과 같이 설명한다.

[아키텍처 스타일]은 구조적 조직의 관점에서 시스템 군을 정의한다. 보다 구체적으로 말하면, 아키텍처 스타일은 컴포넌트와 커넥터 유형의 어휘를 정의하고 이들이 결합되는 방식에 대한 제약 조건들을 정의한다.

그리고 UML의 관점에서는

[패턴은] 주어진 상황에서 일어나는 일반적인 상황에 대한 일반적인 솔루션이다.

경험을 재사용 하는 것 외에도 아키텍처 스타일(또는 패턴)의 적용은 아키텍트의 삶을 더 풍요롭게 만든다. 스타일은 이론적 근거라는 관점에서, 그리고 작동의 관점에서 문서화되기 때문이다. (생각을 좀 덜해도 되고 스타일을 참조하기 때문에 아키텍처 문서들이 줄어든다.)

아키텍처가 아키텍처 스타일에 순응한다.

시스템은 환경 안에 거하고, 이 환경은 아키텍처에 영향을 미친다. 이것을 “정황 속의 아키텍처”라고 한다. 환경은 시스템이 운영되고 아키텍처에 영향을 미치는 바운더리를 결정한다. 아키텍처에 영향을 미치는 환경적 요인들에는 아키텍처가 지원할 비즈니스 미션, 시스템 스테이크홀더, 내부적인 기술 제약조건들(조직의 표준에 순응하는 제약조건 등), 외부적인 제약조건(외부 시스템에 대한 인터페이스의 필요라든가, 외부적인 규제 표준에 순응할 것 등) 등이 포함된다.

반대로, Bass, Clements, Kazman11이 설명한 것처럼 아키텍처도 환경에 영향을 미친다. 기술적인 관점에서 아키텍처의 생성이 환경을 변화시킬 뿐만 아니라, 아키텍처의 생성이 기능적인 관점에서 환경을 변경시킨다.

소프트웨어 중심 시스템의 경우 언제나 고려해야 하는 환경의 특정 측면이 있다. 유용한 소프트웨어가 되려면 실행될 수 있어야 한다. 실행될 수 있으려면 소프트웨어는 하드웨어에서 실행되어야 한다. 따라서 결과 시스템은 소프트웨어와 하드웨어의 결합이고, 신뢰성과 퍼포먼스 같은 속성들이 갖추어져야 한다. 소프트웨어는 하드웨어와 별개로 이를 달성할 수 없다.

IEEE Std 12207-1995, IEEE Standard for Information Technology -- Software Life Cycle Processes는 IEEE 1471 시스템 정의와는 다르게 시스템을 정의한다. (이것은 소프트웨어 중심 시스템에 초점이 맞춰져 있다.) 하지만 시스템 엔지니어링 분야에 대한 정의는 동의하고 있다.

[시스템은] 필요나 목적을 달성할 수 있는 기능을 제공하는 한 개 이상의 프로세스, 하드웨어, 소프트웨어, 장치, 사람들로 구성된 통합 구성체이다. [IEEE 12207]

Rational Unified Process for Systems Engineering (RUP SE)의 설정에도 비슷한 정의가 있다.

[시스템은] 기업이 비즈니스 목적이나 미션을 수행하기 위해 사용하는 서비스를 제공하는 일종의 리소스이다. 시스템 컴포넌트에는 하드웨어, 소프트웨어, 데이터, 작업자 등이 포함된다.

시스템 엔지니어링 분야에서, 소프트웨어, 하드웨어, 사람들간 상쇄 현상이 일어난다. 예를 들어, 퍼포먼스가 중요하다면, 소프트웨어나 사람이 아닌 하드웨어에 특정 시스템 엘리먼트를 구현하는 결정을 내리게 된다. 고객에게 유용한 시스템을 제공하려면 소프트웨어나 하드웨어에서 구현된 인터페이스 보다는 인간이라는 인터페이스를 제공하게 된다. 좀더 복잡한 시나리오의 경우는 소프트웨어, 하드웨어, 사람들이 결합을 해야 한다. (따라서 본 시리즈에서는 소프트웨어 외의 다른 엘리먼트도 참조할 것이다.)

시스템 엔지니어링이 소프트웨어와 하드웨어를(사람들도 포함) 피어로서 취급하고, 따라서 하드웨어가 소프트웨어 대한 제 2의 클래스로서 취급 받거나 소프트웨어를 실행하는 단순한 기구로서 취급 받게 되는 상황을 방지한다. 또는 소프트웨어가 하드웨어에 대한 제 2의 클래스이고 하드웨어를 위한 단순한 도구로 취급 받지 않도록 한다.

아키텍처가 팀 구조에 영향을 미친다.

아키텍처는 주어진 영역을 다루는 관련 엘리먼트들의 그룹핑을 정의한다. 예를 들어, 주문 처리 시스템을 위한 아키텍처는 주문 시작, 계정 관리. 고객 관리, 업무 수행, 외부 시스템과의 통합, 영속성, 보안에 대한 엘리먼트들을 그룹핑 한다.

이들 각각의 그룹핑은 다른 기능 세트를 필요로 한다. 따라서 소프트웨어 개발팀 구조가 정의되었다면 아키텍처로 정렬하는 것 맞다. 하지만 아키텍처는 초기 팀 구조에 의해 영향을 받는 경우가 종종 있다. 이것은 매우 위험한 일이다. 이상적인 아키텍처 상이 아니다. Conway의 법칙에서는 “컴파일러 상에 실행되는 네 개의 그룹이 있다면 4-pass 컴파일러를 갖게 된다.”라고 명시하고 있다. 실제로 우리는 의도하지 않았는데도 아키텍처를 만들어서 기업에 반영하는 아키텍처들을 만든다.

하지만 이렇게 다소 이상적인 뷰가 늘 실질적은 것은 아니다. 순전히 실제적인 이유로 인해 현재 팀 구조와 기능은 무엇이 가능한 지에 대한 매우 실질적인 제약조건을 나타내고 아키텍처는 이를 고려해야 한다.

아키텍처가 모든 시스템에 존재한다.

모든 시스템은 아키텍처를 갖고 있다. 아키텍처가 공식적으로 문서화 되지 않았더라도, 시스템이 하나의 엘리먼트로 구성된 아주 단순한 시스템이라도 말이다. 아키텍처에 대한 문서는 상당한 가치가 있다. 문서화된 아키텍처는 그렇지 않은 것 보다 조심스럽고 효과적으로 다루어져야 한다. 아키텍처의 기록 과정에서 통찰력이 생기기 때문이다.

반대로, 아키텍처가 문서화 되지 않으면 품질, 관리 가능성, 베스트 프랙티스의 채택 등을 입증할 방법이 없다. 오늘날 대부분, 아키텍처는 문서화 되지 않았으며 이는 의도적이기 보다는 일종의 사고다.

아키텍처가 특정 범위를 갖고 있다.

많은 종류의 아키텍처가 있다. 빌딩이나 도시 엔지니어링 건축물들도 아키텍처로 잘 알려져 있다. 소프트웨어 엔지니어링 분야에서도 우리는 다양한 형태의 아키텍처를 만나게 된다. 예를 들어, 소프트웨어 아키텍처의 개념 외에도, 엔터프라이즈 아키텍처, 시스템 아키텍처, 조직적 아키텍처, 정보 아키텍처, 하드웨어 아키텍처, 애플리케이션 아키텍처, 인프라 아키텍처등의 개념들을 보게 된다. 또한 특정 범위의 아키텍팅 행위를 정의하는 용어도 있다.

안타깝게도 산업계에는 이러한 용어나 서로간의 관계에 대한 어떤 동의도 없다. 따라서 같은 용어가 다른 의미를 갖게 되고 한 가지를 의미하는데 두 개 이상의 용어들이 생겨난다. 하지만 이러한 용어들의 범위는 그림 3처럼 한정된다. 이 그림과 그 뒤에 나오는 논의를 생각해 보면 여러분이 동의할 수 없는, 기업에서 다르게 사용했던 엘리먼트들이 많음을 알 수 있다. 그렇다. 이러한 용어들이 산업계에 존재하지만 의미에 대한 동의가 없다.

그림 3 의 엘리먼트:

ㆍ 소프트웨어 아키텍처. 이것은 이 글의 핵심 주제이다.
ㆍ 하드웨어 아키텍처. CPU, 메모리, 하드 디스크, 프린터 같은 주변 장치, 이러한 엘리먼트에 연결하는데 사용되는 엘리먼트 등이 있다.
ㆍ 조직적 아키텍처. 비즈니스 프로세스, 기업 구조, 역할과 책임, 기업의 핵심 능력 등이 여기에 속한다.
ㆍ 정보 아키텍처. 정보가 조직화 되는 구조를 의미한다.
ㆍ 소프트웨어 아키텍처, 하드웨어 아키텍처, 조직적 아키텍처, 정보 아키텍처. 이 모두는 전체적인 시스템 아키텍처의 하위 세트들이다.
ㆍ 엔터프라이즈 아키텍처. 하드웨어, 소프트웨어, 사람들 같은 엘리먼트를 갖고 있다는 점에서 시스템 아키텍처와 비슷하다. 하지만 엔터프라이즈 아키텍처는 비즈니스와 깊이 연결되어 있다. 비즈니스 목적의 달성에 집중하며 비즈니스 기민성과 조직의 효율성 같은 아이템과 관련이 있다. 엔터프라이즈 아키텍처는 기업 바운더리를 넘나든다.

물론 이에 상응하는 아키텍트(소프트웨어 아키텍트, 하드웨어 아키텍트)와 아키텍팅(소프트웨어 아키텍팅, 하드웨어 아키텍팅)이 있다.

지금까지 정의를 통해 고찰했다. 많은 의문점이 남아있을 것이다. 엔터프라이즈 아키텍처와 시스템 아키텍처의 차이는 무엇인가? 엔터프라이즈가 시스템인가? 데이터 중심 소프트웨어 애플리케이션에서 정보 아키텍처가 데이터 아키텍처와 같은 것인가? 불행히도 이러한 질문에 대한 정확하고 동의를 이룬 답은 없다.

현재까지는 다양한 용어들이 존재하지만, 이러한 용어들에 대한 일관된 정의와 관계 방식에는 동의 된 바가 없다. 따라서 여러분의 기업과 관련된 용어들을 선택하여 적절히 정의할 것을 권한다. 그렇다면 적어도 일관성은 이룰 것이고 오해로 빚어진 의사소통 문제도 줄어들 것이다.

요약

소프트웨어 아키텍처의 중심적인 특성을 정의하는 것에 대해 집중 조명해보았다. 하지만 아직도 많은 의문점들이 남아있다. 소프트웨어 아키텍트의 역할은 무엇인가? 아키텍트가 주로 하는 일은 무엇인가? “아키텍팅”의 효용성은 무엇인가? 이러한 질문에 대한 해답은 후속 시리즈에서 지속적으로 다루도록 하겠다.

Notes
1 Software Engineering Institute (SEI) Architecture Website -- http://www.sei.cmu.edu/architecture/definitions.html 참고

2 IEEE Computer Society, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems: IEEE Std 1472000. 2000.

3 Object Management Group Inc., UML 2.0 Infrastructure Specification: Document number 03-09-15. September 2003.

4 Philippe Kruchten, The Rational Unified Process: An Introduction, Third Edition. Addison-Wesley Professional 2003.

5 Len Bass, Paul Clements, and Rick Kazman, Software Architecture in Practice, Second Edition. Addison Wesley 2003.

6 Object Management Group Inc., OMG Unified Modeling Language Specification Version 1.5, Document number 03-03-01. March 2003.

7 James McGovern, et al., A Practical Guide to Enterprise Architecture. Prentice Hall 2004

8 역할에 대해서는 다음 시리즈에서 다룰 것이다.

9 Mary Shaw and David Garlan, Software Architecture -- Perspectives on an Emerging Discipline. Prentice Hall 1996.

10 Grady Booch, James Rumbaugh, and Ivar Jacobson, The Unified Modeling Language User Guide. Addison Wesley 1999.

11 Bass et al., Op. cit.

12 IEEE Computer Society, IEEE Standard for Information Technology -- Software Life Cycle Processes. IEEE Std 12207-1995.

13 Murray Cantor, "Rational Unified Process for Systems Engineering." The Rational Edge, August 2003. http://download.boulder.ibm.com/ibmdl/pub/software/dw/rationaledge/aug03/f_rupse_mc.pdf