Think

개집을 지을 때는 그냥 만들면 된다. 통나무집을 지을 때는 목수만 있으면 가능할 것이다. 하지만 63빌딩을 지을 때는? 당산철교를 다시 만들 때도 ‘그냥’ 만든다는 표현이 가능할까? 어느 정도 이상의 규모가 되면 복잡도가 기하급수적으로 증가하여 인간이 직관적으로 봐서 이해할 수 있는 크기를 훌쩍 넘겨버린다. 그래서 아키텍쳐는 등장하게 된다. <?XML:NAMESPACE PREFIX = O />

(참고: 많은 문헌에서 소프트웨어 아키텍쳐를 설명하기 위해 건축 설계의 비유를 들곤 한다. 이와 같은 비유를 메타포어 (Metaphore)라 하는데, 이를 단순히 어떠한 사실을 설명하기 위해 설정한 예일 뿐이라고 간과하기에는 그 중요도가 좀 크다고 볼 수 있다. 메타포어를 어떻게 잡느냐에 따라 개발자의 마인드가 바뀔 수 있기 때문이다. 예를 들어, 최근 객체지향이나 컴포넌트 기반의 개발방법은 반복적인(iterative) 개발 라이프 사이클을 강조하고 있다. 그러나 위에서 사용한 건축의 메타포어는 이 같은 패러다임 내에서 오해를 불러올 수 있다. 실제 반복적으로 건설되는 건축물은 하나도 없다! 그럼에도 불구하고 건축 메타포어를 사용하는 이유는, 시스템이 비대해지면서 발생하는 복잡도를 설명하는 데 무리가 없기 때문이다. 메타포어에 관련된 내용을 보고 싶다면, Steve C McConnell의 명저 Code Complete나 최근의 경향으로서 Alistair Cockburn의 글 ‘Games Programmer Play’ 등을 참고하기 바란다.

http://www.sdmagazine.com/documents/s=2398/sdm0202a/0202a.htm )

1.     소프트웨어 아키텍쳐의 필요성

노트패드는 ‘그냥’ 만들 수 있지만 흔히 우리가 무슨 무슨 시스템이라고 부르는 중대형 프로젝트의 결과는 절대로 ‘그냥’ 만들어지지는 않는다. 인식하고 있건 아니건 모든 소프트웨어는 아키텍쳐를 가지고 있다. 누가 만드냐에 따라 다르겠지만, 일반적으로 인식하고 만들어진 아키텍쳐는 그렇지 않은 아키텍쳐보다 훌륭할 것이다.

Fredrick P. Brooks가 그의 신화적 저서 ‘The Mythical Man-Month’에서 지적한 ‘9명의 여자가 투입된다고 해서 아기를 한달 만에 나을 수는 없다’ 라는 속담의 비유는 우리에게 많은 것을 시사하고 있다.프로젝트가 어느 정도 이상의 규모를 뛰어넘으면 산술적인 계산으로는 나오지 않는 새로운 이슈들이 등장하게 된다. [Brooks 1975]

1.1.   의사소통과 규모

5명의 개발자가 참여하는 프로젝트와 10인의 개발자가 참여하는 프로젝트는 단순하게 규모가 2배가 늘어났음을 의미하지는 않는다. 5명일 때의 대화 통로는 10개이지만 10명일 때는 45개가 가능하다.

1.2.   활동비율과 규모

프로젝트 규모가 증가하고 형식적인 의사 소통의 필요성이 증가함에 따라, 프로젝트가 필요로 하는 활동의 종류는 극적으로 바뀐다. 소규모 프로젝트에서 구현은 가장 두드러진 활동으로 전체 개발 시간의 80%를 차지한다. 중간 규모 프로젝트에서, 구현은 여전히 주도적인 활동이지만, 전체 노력에 대한 비율은 약 50%로 떨어진다. 아주 대형 프로젝트에서는 아키텍쳐, 통합성, 시스템 테스트가 구현과 동일한 혹은 그 이상의 비율을 차지한다. [Brooks 1975]

1.3.   프로그램, 상품, 시스템, 시스템 상품

코드 행수와 팀 크기가 프로젝트 규모에 영향을 미치는 유일한 요소는 아니다. 더 치밀하게 영향을 미치는 것은 최종적인 소프트웨어의 품질과 복잡성이다. 2500행의 프로그램 개발에 1개월이 걸린다면5000행의 프로그램은 6개월이 걸린다.

상품으로 제작되는 프로그램은 패키징, 문서화, 치장 등의 여러 작업으로 인해 일반 프로그램보다 약3배 정도의 비용이 든다. 또한 함께 작동할 프로그램 그룹인 시스템은 단일 프로그램에 비해 약 3배의 비용이 들고 이를 제품화하기 위해서는 단일 프로그램의 약 9배의 비용이 든다.[Boehm 1981]

1.4.   오류

오류의 종류와 양은 프로젝트의 크기에 영향을 받는다. 소규모 프로젝트에 있어 구현 상의 오류는 모든 오류의 약 75%이다. 더 큰 프로젝트에서 구현 오류는 전체 오류의 약 50% 정도로 줄어든다. 나머지 오류는 아키텍쳐와 분석에서 발생하게 된다.[Grady 1987]

결함의 종류가 크기와 함께 변하는 것처럼 결함의 수도 증가한다. 다음은 프로젝트의 크기와 오류 밀도간의 상관관계를 표현한 표이다.[Jones 1977]

1.5.   생산성

생산성은 프로젝트 크기에 있어 소프트웨어의 품질과 많은 점을 공유한다. 작은 크기의 프로젝트에서 생산성의 가장 큰 영향력은 프로그래머 개인의 기술이다. 그러나 프로젝트 크기가 증가함에 따라,팀 크기와 조직이 생산성에 대단한 영향을 미친다. 다음의 표는 프로젝트의 크기와 생산성의 상관관계를 표현한다.[Jones 1977]

2.     일반 설계와 아키텍쳐의 차이

아키텍쳐와 설계와의 공통점은 둘 다 요구사항을 만족하기 위한 해법을 제시한다는 것이다. 둘 간의 차이는 아키텍쳐는 보다 큰 그림에 초점을 맞추고 설계는 좀 더 미세한 문제에 초점을 맞춘다는 것이다. 다음의 비교는 아키텍트(Architect)와 비 아키텍트 간의 차이를 좀 더 직관적으로 이해할 수 있도록 도와줄 것이다.[suntone]

위의 표를 통해 아키텍트가 아키텍쳐를 설계할 때 어떤 점들을 고려하는지 직관적인 이해를 할 수 있었을 것이다. 이제 좀 더 정확한 차이를 비교해보자.

어떤 사람들은 윈도우보다 리눅스가 좋은 시스템이라고 하고 어떤 사람들은 리눅스보다 솔라리스가 더 좋다고 한다. 이 때 무엇을 기준으로 좋다 나쁘다고 사람들은 얘기하는 것인가? 가장 쉽게 눈에 보이는 요소는 시스템의 기능일 것이다. 하지만 그것은 누구나 파악할 수 있는 요소이고 사실 기능의 구현은 누구나 할 수 있는 것이다. 예를 들어 마우스 클릭 이벤트를 받을 수 있어야 한다는 기능은 모든 플랫폼이 다 가지고 있는 기능이다. 하지만 그 마우스 클릭에 대한 이벤트를 처리하는 방식은 플랫폼마다 다르다. 예를 들어 윈도우는 Callback이란 모델을 사용하고 자바의 경우는 Observer라는 모델을 사용한다. 여러 가지 이유로 Callback보다는 Observer모델이 더 바람직하기 때문에 자바가 윈도우보다 우월한 이벤트 모델을 가지고 있다고 얘기한다 (논란의 여지가 있지만…). 이 때 그러한 여러 가지 이유에 해당하는 것들이 품질속성 (Quality Attribute)들이다. 그리고 아키텍쳐가 다루는 요소는 시스템의 개별적인 기능이 아닌 바로 이러한 품질속성 들이다. [suntone]

3.     품질속성 (Quality Attribute)

절대적인 기아의 상태에서는 음식의 맛을 가리지 않는다. 고른 영양가와 몸에 좋은 음식, 안 좋은 음식 등에 대해서도 고려할 여지가 없다. 일단 배를 채우고 봐야 한다. 그러나 좀 먹고 살만하게 되면 음식의 맛과 향, 칼로리와 각종 영양분과 같은 질적인 문제를 고려하기 시작한다.

분야마다 차이가 있겠지만 90년대 초까지 국내 소프트웨어 개발의 경향은 소프트웨어의 질적인 부분에 대한 고려 보다는 양적인 문제 즉, 소프트웨어의 기능적 특징에 대해 주로 다루어 왔다. 지나치게 눈 앞에 보이는 결과에만 집착한 듯 하다. 그러나 시스템의 수명이 매우 길고, 복잡하며 업무 핵심적(mission-critical)인 분야에 사용될 경우에는 소프트웨어의 기능에 대한 관심 뿐만 아니라 좀더 고차원 적인, 품질 문제가 중요하게 다루어 지게 된다.

어떤 것의 품질을 다룰 때는 여러 가지 세부 항목을 두고 살피게 된다. 변경용이성, 상호운용성, 효율성, 안정성, 시험용이성, 재사용성과 같은 소프트웨어의 품질 요소 (Quality Attributes)들이 이에 해당한다. 이러한 소프트웨어의 품질 요소는 IEEE-Std 830-1993과 같은 표준, CMU의 SEI에서 발표한ATAM(Architecture Tradeoff Analysis Method)과 같은 연구소의 산출물, Rational의 RUP와 같은 개별 기업의 솔루션에서도 나타난다.

하나 하나 이들에 대해서 살펴보자. [POSA I]

3.1.   변경용이성 (Changeability)

변경사항에 대해 쉽게 대처할 수 있는 소프트웨어가 고품질 소프트웨어이다. 소프트웨어 공학에서 지금까지 매우 중하게 다루어온 문제가 바로 변경/비용 곡선이다. 나중에 변경할수록 비용이 기하급수적으로 늘어간다. 변경의 종류나 시점에 따라 다음과 같이 유지보수성, 확장성, 재구조화성, 이식성 등으로 세분해 볼 수 있겠다.

l         유지보수성 (Maintainability): 나중에 문제가 발생했을 때 얼마나 쉽게 고칠 수 있느냐에 대한 것이다. 수술을 할 때 온몸 전체를 건드리는 것이 아니라 특정한 부분만 건드려도 고칠 수 있는 구조를 가져야 한다.

l         확장성 (Extensibility): 기능을 추가, 확장, 또는 제거하기 얼마나 쉬운 가에 대한 것이다.

l         재구조화성 (Restructuring): 컴포넌트들을 재배치해서 구조를 고도화 시키기 얼마나 편하냐에 대한 것이다.

l         이식성 (Portability): 다양한 종류의 플랫폼에 이식시키기 얼마나 편하냐에 대한 것이다.

참고 -------------------------------------------------------------

다음 그래프는 요구사항의 변화 혹은 결점을 해결하기 위한 비용이 시간대별로 얼마나 급격하게 증가하는지를 보여준다. IBM, GTE, Safeguard Software 프로젝트, TRW등에서 있었던  실제 대형 프로젝트들을 조사한 결과이다. [Boehm 1981]

대부분의 문제가 유지보수 단계에서 발생하고 유지보수가 시스템 개발 비용의 80% 정도를 차지하는 것을 생각하면 이 곡선의 기울기를 낮추기 위한 노력이 얼마나 값어치 있는 것인지를 실감할 것이다.[Ambler 1999]

이 곡선의 문제를 해결하기 위해 수많은 방법이 나왔다. 초기에 요구사항을 명확히 규정하고 향후 요구사항의 변화에 대처하기 위한 방법 등을 다루는 요구 공학, 유연한 설계를 통해 변화를 해결하는 비용을 줄이기 위한 패턴들, 최근의 이슈로서 곡선 자체를 직선으로 바꾸기 위해 엽기적(?)으로 노력하는XP (extreme programming)와 같은 방법론 등이 그 예이다. 그리고 그 모든 방법들의 중심에 있는 것이 소프트웨어 아키텍쳐이다. 아키텍트는 요구 공학, 유연한 패턴의 도입, 올바른 아키텍쳐 방법론 등을 통해서 어떤 변화에도 흔들리지 않는 강건한 아키텍쳐를 만들기 위해 노력해 왔다. 그리고 그러한 노력은 헛되지 않아 SUN의 J2EE Blueprint와 SunOne, MS의 .NET, IBM의 Sanfrancisco Framework, 미 국방부(DoD)의 C4ISR 등 많은 참조 아키텍쳐가 나왔고, SUN의 Suntone, Open Group의 TOGAF, 필립스의 Gaudi, BredMeyer의 Action Guide 등 아키텍쳐 구축에 사용되는 여러 방법론이 나왔다.

-------------------------------------------------------------------

3.2.   상호운용성 (Interoperability)

외부 시스템과의 연동이 얼마나 용이하게 되어 있느냐에 대한 능력이다. 다른 언어, 다른 규약, 다른 자료 형식을 가진 시스템과 연동하는데 문제가 없도록 만들어야 한다. 가장 낮은 단계의 상호운용성은 디스켓을 통한 자료 전달이 있을 것이고, 점점 상위 단계로 올라가면 동일한 프로토콜을 사용하여 연동하는 웹 서비스 혹은 IIOP와 같은 기술이 있을 수 있다.

3.3.       효율성 (Efficiency)

가지고 있는 자원을 얼마나 최대한 활용해서 효율적인 시스템을 만드느냐에 대한 문제이다. 응답 시간이나 많은 동시사용자의 수용 등과 관련된 문제들을 해결하기 위해 최소한의 비용으로 최대의 효과를 얻어내는 것이 목표이다.

3.4.       안정성 (Reliability)

예외적인 상황이나 예측 못한 상황에 직면했을 때 얼마나 시스템의 기능을 유지할 수 있느냐에 대한 문제이다. 여기에는 두 가지 세부 분류가 가능하다.

l         고장 감내 (Fault Tolerance): 에러가 발생했을 때 이것을 ‘복구’할 수 있느냐는 것이다. 현재 보잉 747기에는 747기용 시스템과 737기용 시스템이 동작하고 있다. 비교적 최신인 747용 시스템이 다운될 경우, 기능은 좀 떨어지겠지만 수년간 사용되어서 검증된 737기용 시스템으로 교체되므로 소프트웨어 버그로 비행기가 추락할 일은 거의 없다고 봐야 할 것이다.[Simplex]

l         강건성 (Robustness): 시스템의 정상 상태를 얼마나 깨뜨리기 어려운가에 대한 문제이다. 윈도우에서 애플리케이션이 잘못된 연산을 수행할 경우 윈도우는 도스처럼 정지되지 않는다. 그 애플리케이션만을 종료시킴으로써 문제를 해결한다. 물론 때때로 자신을 도스로 착각하는 가슴 아픈 경우가 있기는 하다.(정말 눈물나게 가슴 아프다.)

3.5.   시험용이성 (Testability)

많은 개발자들이 개발보다 디버깅에 시간과 노력을 많이 빼앗기고 있다. 어렵게 만들어 놓은 코드는 역시 문제가 또 발생할 수 있다. 쉽게 테스트 할 수 있다면 문제가 많이 해결된다. 테스트하기 쉬운 소프트웨어는 그 자체만으로도 품질이 좋다고 말할 수 있다. 주로 하드웨어와 연관성이 적은 경우 시험용이성이 좋은 경향이 있다. 기존에 사용하던 컴포넌트를 충분히 테스트하지 못하고 사용했다가 공중 분해된 미국의 챌리저 우주왕복선은 시험용이성의 중요성을 잘 시사해준다.

3.6.       재사용성 (Reusability)

개발 비용과 시간을 줄이기 위한 방법으로 재사용이 계속 강조되어 왔다. 재사용은 재사용 컴포넌트를 개발하는 것과, 재사용 컴포넌트를 사용한 개발의 두 가지 측면으로 살펴볼 수 있다. 모든 개발자가 인식하지만 실제로는 아무도 안 하는 것 중의 하나가 재사용일 것이다. 최근에는 막연한 재사용을 실제로 하기 위한 여러 가지 방법들이 제시되고 있다. 프레임워크와 같이 제품을 통한 아키텍쳐의 재사용, Product-Line과 같은 조직 혹은 산업단위의 방법론적 해결방법 등이 그것이다.

4.     아키텍쳐 스타일

이러한 품질속성을 만족하는 아키텍쳐를 ‘발명’ 한다는 것은 어지간한 천재가 아니라면 불가능하다.사실 대부분의 경우에 아키텍쳐는 만들어지는 것이 아니다. 기존의 잘 만들어진 아키텍쳐들을 선택하고 우리 시스템에 적합하게 수정 작업을 한다. 이러한 기존의 잘 만들어진, 그리고 수 십년 동안 수많은 시스템으로부터 시행착오를 통해 정제되고 검증된 아키텍쳐들을 아키텍쳐 스타일이라고 부른다. 가장 널리 쓰이는 아키텍쳐 스타일인 Layer에 대해서 살펴보자.[Shaw, Garlan 1996]

4.1.   Layer

우리가 별 생각 없이 사용하는 인터넷은 모두가 알다시피 네트워크를 통해서 동작한다. 그리고 모든 네트워크의 구조는 흔히들 프로토콜 스택이라고도 부르는 Layer 아키텍쳐 스타일에 의해 구성되어 있다. 예를 들어 PC방에서 인터넷을 한다면 Lan Card/Network Device Driver/IP/TCP/HTTP 를 통해서 웹을 사용하게 된다. 가장 유명한 네트워크 구조인 ISO의 OSI 7 Layer도 이름에서 보다시피 Layer 구조를 사용한다.

4.1.1. 용도

Layer 아키텍쳐 스타일은 단일 단위로 개발하기에는 지나치게 복잡한 시스템을 특정 수준의 추상화 수준으로 각 계층 구조를 구성함으로써 시스템을 분해하는 방법이다. 예를 들어 네트워크의 예제에서는 물리적인(하드웨어적인) 추상화 수준에서 논리적인(소프트웨어적인) 추상화 수준까지를 계층도로 구성하였다.

4.1.2. Layer – Before & After

Layer가 해결하고 하는 문제는 무엇인가? 시스템을 설계하기 위한 주요 이슈들이 고수준의 문제와 저수준의 문제들의 혼합된 형태일 경우 그들을 분리하기 위한 방법이 Layer이다. 그러한 코드들이 한군데로 뭉쳐져 있다면 (유식한 말로 monolithic 하다고 한다) 작업의 분배가 힘들고, 약간의 코드의 변화에 대한 파급 효과 (도미노 효과)가 크다. 또한 시스템을 전체로서 이해해야 하기 때문에 이해하는 게 매우 어려워지고 그에 따라 변경용이성이 급격히 저하된다. 쉽게 얘기해서 main 함수 안에 모든 코드가 다 있는 격이다.

그렇다면 Layer를 적용하면 어떠한 점에 있어서 좋은가? 일단 위에서 나열한 문제는 모두 해결된다.뿐만 아니라 각 Layer를 표준화할 경우 하나의 계층을 구현한 각 제품들이 서로 교체 가능하게 된다.예를 들어 PC방의 랜 카드 혹은 디바이스 드라이버를 교체해도 아무 문제 없다. 이것은 변경용이성뿐만 아니라 각 계층을 독립적으로 재사용할 수 있음을 의미한다.

세상사 모두 그렇듯이 단점도 있다. Layer의 가장 큰 문제는 시스템을 몇 계층으로 구성할지, 각 계층의 역할을 무엇으로 할지 그 적정한 수준을 잡기가 굉장히 어렵다는 것이다. 그 다음의 문제는 항상 계층을 통해서 시스템이 동작하기 때문에 성능의 저하가 있을 수 있다는 것이다. 그 외의 문제로 모든 유스케이스가 항상 모든 계층을 통해서 동작하기 때문에 코드의 양이 불필요하게 늘어나는 경우가 많다.

(참고: Analysis Pattern, Refactoring 등의 저서로 유명한 Martin Fowler는 현재 Enterprise Application Architecture 란 제목으로 새로운 책을 준비하고 있다. 그는 계층을 Presentation, Domain, Data Source 로 나누어 각 계층에서의 이슈를 다루고 있다. Enterprise Application에 관심있는 분께 적극 추천하고 싶은 컨텐츠다. http://martinfowler.com/isa/index.html

 꼭 Fowler의 주장이 아니더라도 J2EE, MS DNA 등에서 볼 수 있는 것처럼 현재 거의 모든 EA는Layer 아키텍쳐 상에서 다루고 있다. 그 기원은 MVC (Model-View-Controller) 패턴에서 찾아볼 수 있을 것이다. MVC가 뭔지 궁금하신 분들은 또 한번 나아갈 길이 생긴것이다. ^^; )

5.     관점 (View)

건축에 대한 설계 도면을 그릴 때 하나의 그림으로 그리는 것은 불가능하다. 평면도, 측면도, 전기배선도, 수도배관도 등등 여러 도면에 나뉘어 그리게 된다. 왜냐하면 건축물이란 작품은 매우 복잡하므로 하나의 그림에 표현하는 것이 불가능하기 때문이다. 소프트웨어 시스템도 마찬가지이다. 흔히 아키텍쳐를 소프트웨어의 큰 그림이라고 표현하지만 한 장의 그림은 아니다. 이 때 몇 장의 그림으로 표현할 것인가에 대한 문제는 아직 결론이 나지 않았다. (앞으로도 결론은 없겠지만…) 여기서는 UML을 처음 만들어서 유명한 Rational의 4+1 view라는 5개의 관점으로서 소프트웨어를 바라보는 방법을 소개한다.[RUP]

5.1.   4+1 view

4+1 View는 유스케이스를 중심으로 총 5개의 관점으로 시스템을 바라본다. 유스케이스 관점은 최종 사용자가 바라보는 시스템의 기능을 의미하며, Logical 관점은 소프트웨어를 구성하기 위한 모듈들의 구성으로 Layer 같은 구조가 이에 해당한다. Process 관점은 시스템의 동시성에 관한 내용으로 시스템에 어떤 프로세스, 스레드가 있는 지 식별하고 그들간의 관계 (소유, 동기화 등)를 표현한다. Implementation 관점은 최종 소스코드들의 관계로 자바의 패키지간의 관계가 이에 해당한다. Deployment 관점은 시스템의 노드들 (컴퓨터, 디바이스)이 어떻게 배치되고 그들이 어떻게 연결되어 있는지를 의미한다. 그리고 이러한 모든 관점들은 유스케이스를 중심으로, 즉 요구사항을 끈으로 서로 연결되어 있다.

소프트웨어 시스템마다 필요한 관점은 서로 다를 것이다. 예를 들어 오피스 같은 애플리케이션은Process와 Deployment 관점은 필요 없을 것이고, 반면에 아파치와 같은 웹서버를 개발한다면 그 둘은 빠질 수 없는 중요한 관점이 된다. 따라서 프로젝트마다 적절한 관점을 선택하여 사용하는 것은 아키텍트의 가장 중요한 작업 중 하나이다.

6.     맺음말

아키텍쳐 설계는 개발자의 작업 중에 가장 창조적이고 고난이도의 작업에 해당한다. 따라서 매우 많은 지식과 경험을 필요로 한다. 미국에서는 CSA(Chief Software Architect)라는 직책이 따로 있고MS의 빌게이츠 회장이 CSA를 맡고 있다. 엔지니어로 평생 있을 생각이라면 한번 도전해볼 만한 직책이 아닌가?

< ISO/IEC 참고 문헌 > 

☆ 소프트웨어 개발절차