매우 간단한 소프트웨어 시스템이 아닌 다음에야, 아키텍처에 세심한 주의를 기울이지 않은 상태로 개발에 성공하기란 쉽지가 않다. 여기서 아키텍처란 시스템을 서로 관련된 부분들로 나누는 방식과 그 부분들이 상호작용하는 방식을 일컫는다. 당면한 문제를 해결할 적당한 아키텍처가 없다면 프로젝트는 실패하고 말 것이다. 또한 매우 훌륭한 아키텍처가 있다 하더라도 이해하기 어렵거나 의미를 전달하기 어려울 때는, 다시 말해 문서화가 잘 안 돼 있을 때는 프로젝트가 혼란에 빠지게 된다.
최근 들어 소프트웨어 아키텍처가 뭇 사람들의 관심을 끌게 됐고, 이를 반영하듯 아키텍처를 다룬 책도 매달 새로이 등장하고 있다. 업계의 요구에 부응해 대학들도 소프트웨어 공학 과정에 소프트웨어 아키텍처 과목을 집어넣고 있다. 이제는 조직 내에 "소프트웨어 아키텍트"라는 구체적인 직책이 일반적으로 받아들여지는 경우가 많아졌고, 소프트웨어 아키텍트로 이루어진 전문적인 실무 그룹도 생겨나게 됐다. 소프트웨어 아키텍처는 주류 국제 학술대회와 워크샵의 주제로도 자리 잡고 있다. 통합 모델링 언어(UML)를 공급하는 회사들은 자신들의 제품을 "소프트웨어 아키텍처를 나타내는 표준 표기법"으로 내세우고 있다. 이런 것을 보면 아키텍처가 최소한 UML과 비슷한 정도로 자리 잡고 있음을 알 수 있다. 카네기 멜론 대학교(CMU)의 소프트웨어 공학 연구소(SEI)에서는 소프트웨어 아키텍처 관련해서 학술지나 학술대회 발표 자료를 1000여 개 가까이 모아 놓았다.
한 가지 안타까운 점은 언어나 표기법과 무관하게 아키텍처를 잡아낼 수 있는 실용적인 지침이 아직 부족하다는 것이다. 좀 더 명확히 말하자면 특정 언어(UML이라고 생각해 보자)를 사용하는 방법을 다루는 책들은 수없이 많다. 그러나 실제로 아키텍트가 요구하는 것은 아키텍처를 최우선 요소로 다루고 그와 관련된 언어는 그것을 지원하는 보조적인 역할로만 보는 지침서라고 봤을 때, 이를 다루는 책은 드물다.
일단 기본적인 배경지식을 살펴보자. 이 분야에서는 아직 소프트웨어 아키텍처에 대한 정의가 하나로 수렴되지 않고 여러 정의가 난립해 있기는 하지만, 이 책에서는 그중에서 하나를 골라 일관되게 사용할 것이다. 바로 베스, 클레멘츠, 캐즈먼(1998)에게서 가져온 정의이다. 비록 이 책에서 주로 다루는 내용이 요소와 관계의 의미에 대한 것이기는 하지만, 여기서 이 정의를 사용하는 이유는 아키텍처에는 매우 다양한 종류의 구조가 있음을 강조하기 위해서다. 구조에는 저마다 다양한 종류의 요소와 관계가 있고, 따라서 이런 구조를 통해 아키텍처의 특정 측면을 파악할 수 있는 시각을 얻을 수 있다.
"외부에 드러나는 속성"이란 어떤 컴포넌트에 대해 다른 컴포넌트들이 두고 있는 가정을 말한다. 예를 들어 컴포넌트에서 제공하는 서비스나 품질속성의 특성, 공유자원에 대한 사용 등을 일컫는다.
아키텍처는 시스템과 그 시스템을 개발하는 프로젝트 양쪽 모두에 대해 청사진의 역할을 한다. 특히 개발 프로젝트에서는 설계나 구현팀에서 수행해야 할 작업할당 내용을 정의할 때 쓰인다. 아키텍처는 성능, 변경용이성, 보안 등과 같은 시스템의 품질을 보장하는 최선의 방법이다. 이런 품질들은 하나같이 통합적인 아키텍처적 시각 없이는 달성할 수 없는 것들이다. 아키텍처라는 산출물은 채택한 설계 안을 가지고 수용 가능한 시스템을 만들어 낼 수 있는지를 확인하는 데 필요한 초기 분석에도 쓸 수 있다. 아키텍처는 배포가 끝난 상황에서 시스템을 이해하고, 유지보수하며, 정보를 뽑아내야 하는 경우에도 핵심적인 역할을 한다. 간단히 말해서 아키텍처는 프로젝트 상의 모든 단계와 프로젝트와 관련된 모든 이해관계자들을 연결해 주는 개념적인 접착제라고 할 수 있다.
아키텍처 문서화 작업은 아키텍처를 수립하는 과정에서 화룡점정에 해당한다. 완벽한 아키텍처라 하더라도 그 내용을 제대로 전달할 수 없다면 아무 쓸모가 없다. 강력한 아키텍처를 만들어 내고자 한다면 모호함 없이 충분히 자세하게 기술해야 하고, 다른 사람들이 필요한 정보를 재빨리 찾을 수 있는 형태로 내용을 구성해야 한다. 그렇게 하지 않으면 그 아키텍처를 활용할 수 없어서 결국 헛수고가 되고 만다.
이 책을 읽을 독자들은 주로 아키텍처 문서를 생산하거나 소비하는데 관련된 사람들, 즉 소프트웨어 개발자들일 것이다. 이 책의 목표는 개발자들이 아키텍처에 대한 정보 중에서 어떤 것들을 찾아내서 기록해야 하는지 결정하는 데 도움을 주고, 또 그런 정보를 기록할 때 필요한 지침, 표기법, 예제 등을 제공하는 데 있다. 저자들은 이 책이 아키텍처를 구성하는 다양한 종류의 정보를 다루는 데 있어 실무자 중심의 지침궼가 될 수 있도록 했다. 또한 저자들은 사람들이 아키텍처 기반의 업무, 즉 구현, 분석, 복구 등의 업무를 수행할 때 아키텍처를 활용할 수 있게 정보를 기록하는 방법을 UML을 비롯한 다양한 표기법으로 만든 예제를 통해 보여주고자 했다. 이에 따라 이 책에는 다음과 같은 내용이 담기게 됐다.
● 소프트웨어 아키텍처 문서 활용: 문서를 어떻게 작성하느냐는 그 문서를 어떻게 활용하기를 원하는지에 달렸다. 이 책에서는 아키텍처 문서화에 서 실현 가능한 최종 목표들을 설정하고, 그렇게 설정한 개별 목표에 맞는 문서화 전략을 제공한다.
● 아키텍처 뷰: 소프트웨어 아키텍처 문서화는 기본적으로 관련 뷰들을 문서화한 다음, 이 정보에 뷰 이외의 관련 정보를 보강하는 작업이다. 이 책의 핵심은 가장 관련이 깊은 아키텍처 뷰들을 뷰타입이라 불리는 세 가지 주요 군으로 묶고, 이를 실제 문서로 옮길 수 있는 실질적인 지침을 넣은 데 있다. 또한 각 뷰타입마다 예제도 제시해 놓았다.
● 정보 패키지화: 뷰에 대해 이해하고 나면 남는 문제는 관련 뷰들을 선택하고, 개별 뷰에 들어가지 못한 정보를 찾아낸 다음, 그 모든 정보를 모아서 일관된 하나의 패키지로 만드는 일이다. 저자들은 이 모든 측면들에 대해 실질적인 조언을 제시하고자 한다.
우리 저자들은 시스템을 성공적으로 구축하려면 아키텍처가 매우 중요하다고 굳건히 믿고 있다. 그러나 효과적으로 의사소통할 수 없는 아키텍처로는 불가능하다. 또한 성공적인 의사소통의 핵심은 문서화에 있다. 모쪼록 이 책이 현장 실무자들에게 매우 쓸모 있는 안내서가 되기를 바라 마지 않는다.
- 폴 클레멘츠, 텍사스 오스틴
- 펠릭스 바크만, 렌 베스, 데이비드 갈란, 제임스 이버스, 리드 리틀,
로버트 노드, 쥬디스 스태포드, 펜실베니아 피츠버그
--- '저자 서문' 중에서
소프트웨어 아키텍처를 다룬 정전들을 우리말로 옮겨서 펴내고자 마음 먹은 이래로 『소프트웨어 아키텍처: 이론과 실제』를 내고 이제 두 번째 책인 『소프트웨어 아키텍처 문서화』를 내게 됐습니다. 앞의 책이 소프트웨어 아키텍처에 대한 총론이라면, 이번 책은 소프트웨어 아키텍처 문서화에 집중한 각론에 해당합니다. 책의 구성으로 봐도 앞의 '이론과 실제' 책에서는 9장 한 장에서만 '소프트웨어 아키텍처 문서화'라는 제목으로 다뤘던 내용을 이번 책에서는 한 권 전체에 걸쳐 다루고 있습니다. 그만큼 아키텍처 문서화에 대해 필요한 거의 모든 내용을 다룬 전문서라 봐야 할 것입니다. 더불어 '이론과 실제' 11장에서 소개한, 'ATAM'을 필두로 한 소프트웨어 아키텍처 평가 방법들을 집중적으로 소개한 책도 조만간 나올 예정이라 하니, 우리 나라 업계에서도 소프트웨어 아키텍처 분야가 자리잡기 위한 구색이 점차 갖춰져 가는 느낌에 가슴이 뿌듯해 집니다.
한편, 이런 책들은 모두 원서가 2003년부터 2004년 즈음에 나온 것들로, 4~5년이나 지난 오늘에 와서 우리말로 번역돼 나온다는 사실이 안타깝기도 합니다. 어쨌든 이런 식으로 소프트웨어 아키텍처에 대한 총론서와, 세부 주제들을 집중적으로 다룬 각론서가 하나 둘씩 우리말로 소개되면서 소프트웨어 아키텍처라는 분야에 대한 지식이 대중화되고, 그로써 저희 역자들뿐 아니라 많은 독자들께서 동경하는 소프트웨어 아키텍트라는 역할이 좀 더 명확히 이해되고, 또 어떻게 하면 그 역할을 더 잘 할 수 있는지 지침이 제시되면서 업계에서 확고히 자리잡을 수 있지 않을까 기대합니다.
카네기 멜론 대학교의 소프트웨어 아키텍처 과목 교수이며, 저희 역자들에게 '저런 아키텍트가 되면 정말 멋지겠구나'라는 생각을 품게 해 준 역할 모델인 Anthony Lattanze 교수님이 했던 말이 기억납니다. "자네들 모두 소프트웨어 아키텍트가 되고 싶은 거 아네. 그런데 그거 아는가? 아키텍트가 하는 일 중에 98%는 모두 따분하고 재미없는 문서화 작업이라는 거. 나머지 한 2% 정도만 자네들이 신나고 재미있어 하는, 뭔가를 설계하고 결정하는 일이지. 힘 빠지는 얘기겠지만, 어쩌겠는가? 대부분의 전문분야가 다 이런 식으로 돌아가는걸. 약간의 매력적인 작업을 위해 하기 싫은 일을 견뎌내는 거지. 하지만 진짜 전문가는 하기 싫은 일을 효과적으로, 되도록 재미있게 하는 사람이야." 그렇지 못한 사람은 아마추어라는 말씀이시겠지요.
문서화 작업은 따분하고 재미없는 데서 그치지 않고, 하기 싫어서 미루다 보면 종국에는 고통스럽기까지 하더군요. 고통은 어디서 올까요? 부처님 말씀으로는, 무지에서 온다고 합니다. 그렇다면 혹시 제대로 알면 따분하고 재미없고 심지어 고통스럽기까지 한 문서화 작업이 재미있게 다가올까요? 전적으로 그런지는 모르겠지만, 알고 나면 흥미가 일고, 흥미가 일면 재미는 금방이지 않을까요?
이 책은 소프트웨어 문서화라는 게 무엇이고, 잘 하려면 어떤 원칙을 지켜야 하는지 설명하고, 소프트웨어 아키텍처 문서화에서 다뤄야 할 내용이 무엇인지 정리해 놨습니다. 따라서 아키텍처에는 관심이 있지만 문서화에는 관심이 없는 분들(언제까지고 그럴 수는 없겠지만!)도 아키텍처에서 다루는 내용이 어떤 것들인지 좀 더 심도 있게 살펴보거나, 아키텍처를 어떤 모습으로 구성해야 하는지 살펴보는 데 도움이 될 것입니다.
한 가지 양해를 구할 것은, 책 내용에 쉽지 않은 부분이 많아 독자들 눈에 거슬리는 부분이나 어색한 부분이 있지 않을까 하는 것입니다. 특히 90페이지 가까이 되는 소프트웨어 아키텍처 문서화 실전 예제 부록이 그런 부분이 아닐까 싶습니다. 원저자들이 '대규모 프로젝트 문서화 이렇게 한다!'를 사실적으로 보여주기 위해 전형적인 예제를 넣은 것인데, 안타깝게도 다루는 내용이 인공위성에서 데이터를 수집해 가공, 배포하는 쪽입니다. 분야가 워낙 독특하고 국내에서 접하기 힘든 내용들이라, 저희 역자들도 우리말 어휘나 표현으로 적절히 옮기기 어려운 점이 많았습니다. 간혹 틀린 데가 있더라도 독자들의 너그러운 양해 바랍니다.
끝으로 이 자리를 빌어 투박한 번역 원고를 검토해 여러 가지 고칠 곳을 지적해 주신 맹주원님과 정희종님, 엄태욱님께 감사 드립니다. 또한 원저자 중 한 분으로, 한국인 제자들이 자신이 쓴 책을 번역한다는 소식을 듣고 특별히 한국어판 추천의 글을 써 주신 카네기 멜론 대학교의 David Garlan 교수님께도 감사의 말씀을 전합니다.
2009년 1월 13일
역자 일동
--- '옮긴이의 말' 중에서