지난 15 여년 간 소프트웨어 아키텍처에 대한 연구가 성장하고 성숙됨에 따라 소프트웨어 아키텍트들은 단순히 아키텍처만 수립하는 일을 넘어서 수많은 일에 기여한다라는 사실이 매우 명확해졌다. 아키텍트는 설계자를 선도해주고, 새로운 기술을 도입하기 위한 계획을 수립하는 역할도 담당한다. 또한 조직의 경영목표를 구체화하는 데 참여하는 일에서부터 개발자와 테스터의 가이드 역할까지도 수행한다. 요약하면 아키텍트는 아키텍처를 올바로 이해하고 사용하는 데 필요한 모든 일이 제대로 돌아가게 하는 역할을 해야 한다.

아키텍트는 수많은 과업 중에서 무엇보다도, 설계한 아키텍처가 문제를 해결하는 데 올바른 것인지 최선을 다해야 한다. 즉 아키텍트는 아키텍처가 제대로 기능을 수행해내는가와 마찬가지로 성능과 보안, 가용성 등과 같은 품질속성도 올바르게 달성됐는지도 파악하는 일이 중요하다.

이 책『소프트웨어 아키텍처 평가』는 아키텍트가 이와 같은 업무 수행을 하는 데 도움을 주기 위해 집필한 책이다. 한국어판이 출간된다고 하니 기쁜 마음을 형언할 길 없다. 아무쪼록 이 책이 역동적으로 발전하고 있는 한국의 소프트웨어 산업에 큰 보탬이 되기를 기원한다. 아울러 우리가 이 책을 쓸 때의 환희와 즐거움을 한국의 독자들도 느끼게 되길 바란다. --- '한국어판 특별 서문' 중에서

소프트웨어 시스템의 토대는 아키텍처에 있다. 이는 소프트웨어 시스템이 개별적으로 개발된 구성요소들로 구축되며 이 구성요소 간에 상호작용하는 방식에 기반을 둔다는 사실을 의미한다. 어떤 시스템을 구축하더라도 한 명 이상이 참여하는 규모라면 아키텍처를 기반으로 한 구성원 간의 의사소통과 작업 할당에 대한 조율이 필요하다. 요구사항 중에 성능, 보안, 신뢰성, 유지보수성에 대한 목표가 있다면 아키텍처는 시스템이 어떻게 이 목표를 달성할 수 있을지를 최초로 표현하는 설계 산출물이 된다. 아키텍처는 개발 프로젝트의 구조를 결정하며 이는 프로젝트 문서화의 기반이 된다. 또한 아키텍처는 프로젝트에 참여한 신규인력이 가장 먼저 접하는 문서며, 유지보수 조직이 가장 먼저 파악해야 하는 첫 업무다. 일정, 예산과 작업계획 모두가 아키텍처를 중심으로 움직이게 된다. 따라서 선임이면서 가장 능력 있는 설계자가 아키텍처를 만들도록 요구된다.

시스템에 대한 변화의 압력 속에서 시스템의 수명을 어떻게 유지하는가는 전적으로 아키텍처에 달렸다. 3티어 아키텍처, 레이어 아키텍처, 파이프 필터 아키텍처와 같은 아키텍처 스타일은 일반화돼서 개발 커뮤니티에 널리 활용되고 있다. 이제는 점차 전사적인 목표를 달성하는 데 있어서 아키텍처의 가치와 중요성을 인식하고 있다. 아키텍처는 회사에 경쟁력을 제공하며 마치 금융자산과 같이 자산으로 축적될 수도 있다.

적합한 아키텍처는 성공의 첫걸음인 반면에 잘못된 아키텍처는 재난을 야기한다. 다음과 같은 중요한 질문을 고려해보자. 한 시스템의 아키텍처가 회사의 미래를 좌우한다고 할 때, 지금 적합한 아키텍처를 기반으로 개발하고 있다는 것을 어떻게 보장할 것인가?

아키텍처를 만드는 일이 점차 성숙되어 가면서 아키텍처로 인해 만들어진 설계 의사결정과 이를 기반으로 구축된 시스템에서 도출된 품질 및 특성 간에 의도하지 않았던 관련성을 식별할 수 있게 됐다. 이는 구축할 시스템에 부여된 목표와 요구사항 측면에서 아키텍처 의사결정을 분석하기 위해 아키텍처를 평가하는 게 가능하다는 의미다.

최근에는 시스템 개발에서 아키텍처가 필수적인 부분으로 여겨지고 있지만 아키텍처 평가는 거의 어떤 개발 프로세스에서도 표준으로 포함된 적이 없었다. 우리는 아키텍처 평가가 개발 프로세스에 포함돼야 한다고 믿으며 이 책을 통해서 이러한 현실과의 차이점을 극복하는 데 도움을 주고자 한다.

아키텍처 평가가 소프트웨어 공학적인 실제 활동으로 인정돼야 하는 시점이 된 데는 다음 두 가지 이유가 있다. 첫째, 아키텍처는 개발 프로젝트에 있는 엄청나게 많은 위험을 가시화한다. 앞에서도 말했듯이 잘못된 아키텍처는 프로젝트에 재앙을 야기한다. 일반적으로 불확실성이 있는 경우 위험완화전략을 세우듯이 핵심적인 산출물을 평가하는 것은 좋은 판단이라고 할 수 있다. 둘째, 생각보다 훨씬 적은 비용으로도 아키텍처 평가를 수행할 수 있다. 이 책에서 설명하는 평가방법은 프로젝트 일정에 일주일 이내의 시간만 필요하며 간략화된 방식은 하루나 이틀 정도의 시간만 추가하면 된다. 따라서 아키텍처 평가는 매우 저렴한 보험 증서라고 할 수 있다. 미흡한 아키텍처로 인해 발생하는 비용에 비하면 적절한 소프트웨어 아키텍처 평가에 대한 비용은 충분히 정당화된다. 이 책은 지금까지 부족했던 아키텍처 평가를 수행하는 실무적인 방법을 개선하려는 목적으로 등장했다.

이 책은 아키텍처 평가 실무자(또는 실무자가 되기를 원하는 사람)를 위한 지침서다. 이 책에서는 평가에 필요한 개념적인 배경을 제공하고 있지만 그보다는 아키텍처 평가와 분석의 실무에 대한 단계적인 지침을 제공하기 위한 작업을 목적으로 한다. 아키텍처 평가방법을 실무에서 적용하기 위해 다음과 같은 실제 사용할 수 있는 샘플 산출물을 추가했다. 예를 들면, 프리젠테이션 템플리트, 시나리오, 수행 후 설문, 최종보고서 템플리트 등이다. 이는 이 책을 읽은 후에 자신이 속한 조직의 아키텍처에 평가방법을 적용할 수 있을 정도의 자신감을 느끼게 하는 것이 목적이다. 평가 중에 "다음에는 무엇을 하지?" 같은 질문에 답을 할 수 있도록 노력했다.

이 책은 평가자 관점에서 쓰였으나 평가에 참여하는 다른 사람들(프로젝트 관리자, 아키텍트, 기타 이해관계자)도 이 책을 읽으면 아키텍처 평가에 대한 가치 있는 통찰을 얻을 수 있을 것이다. 이들도 자신의 제품이 어떻게 평가되는지와 평가 분류를 준수하면서 해당 제품을 좀 더 잘 만들지에 대해서 이해할 수 있게 된다. 마치 미리 시험 문제를 보고 점수를 잘 받는 것과 같지만, 이는 속임수가 아니라 뛰어난 관리와 공학적인 실무라고 할 수 있다. 하지만 이 책에서 '당신' 또는 '여러분'이라는 말을 사용할 때, 평가자만을 대상으로 이야기하고 있다는 것을 주지하기 바란다.

이 책은 정부기관과 업계에서 실제 적용된 기법을 기반으로 한다. 대부분 방법은 SEI에 있는 저자들과 다른 전문가들이 개발했으며 고객과 협력사 시스템에 적용했다. 그 밖의 내용은 아키텍처의 분석과 평가의 전문가들이 참여하는 워크숍을 개최해 얻었다. 다시 말해, 직접 수행하면서 배웠고 다른 사람들의 수행 경험을 통해서도 배웠다.

이 책은 훌륭한 아키텍트가 되는 방법을 알려주지 않으며 아키텍처의 이슈를 잘 이해할 수 있게 도와주지도 않는다. 이 책에서는 여러분이 이미 실무 경험을 통해서 아키텍처를 확실히 이해하고 있다고 전제한다. 이 책은 개인적인 아키텍트의 업무 성과 평가나 프로젝트의 아키텍처 프로세스(또는 개발 프로세스)를 도와주는 것도 아니다. 이 책이 도와줄 수 있는 것은 다양하고 중요한 품질속성을 준수해서 만들어질 아키텍처와 이를 기반으로 만들어질 미래 시스템을 어떻게 평가하는지를 보여주는 것이다.

마지막으로 소프트웨어 집약적 시스템에서 소프트웨어 아키텍처와 시스템 아키텍처에 대해서 이야기할 필요가 있다. 이 책은 소프트웨어 아키텍처에 대한 평가를 다루지만 다음과 같은 질문을 자주 받게 된다. "단순히 소프트웨어에 대해서만이 아니라 시스템에 대한 아키텍처는 어떻게 해야 하나요? 시스템도 소프트웨어만큼이나 중요하잖아요." 물론 맞는 말이다. 시스템 아키텍처도 소프트웨어 아키텍처와 같은 유사한 종류의 구조와 분할에 대한 의사결정을 담고 있다. 게다가 시스템 아키텍처에는 하드웨어/소프트웨어 간의 절충과 컴퓨팅 및 네트워크 장비를 포함하고 있어서 소프트웨어 아키텍처의 범위를 완전히 벗어나게 된다. 소프트웨어 아키텍처가 소프트웨어의 성패에 영향을 미치는 것처럼, 시스템 아키텍처는 시스템의 성패에 중요한 역할을 한다. 따라서 시스템 아키텍처도 소프트웨어 아키텍처와 마찬가지로 평가돼야 당연하다.

이 책에 소개된 방법들이 소프트웨어 아키텍처뿐만 아니라 시스템 아키텍처에도 동일하게 적용할 수 있다고 믿는다. 시스템의 변경용이성을 고려한다면 시스템의 생명주기 동안 변경하는 데 드는 비용을 측정하는 방법을 사용할 수 있다. 예를 들어 성능을 고려한다면 시스템과 소프트웨어에서 병목구간과 문제 영역을 찾아내는 방법을 사용할 수 있다.

시스템 아키텍처에도 적용될 수 있다면 왜 이 책을 '소프트웨어' 아키텍처 평가라고 부르는가? 이는 이 평가방법이 소프트웨어 범위에서 생성되고, 만들어지고, 테스트되고, 성숙했기 때문이다. 따라서 이 책에서 아키텍처라고 말할 때는 소프트웨어를 접두어로 붙여서 이해해도 무방하다. 시스템을 접두어로 붙일 수도 있지만 이는 여러분이 얼마나 해당 방법이 시스템 아키텍처에 적용 가능한지와 해당 내용에 대한 우리의 의도를 얼마나 확실하게 이해하는지에 달렸다.

마지막으로 여러분의 경험을 공유해주기를 바란다. 여러분이 어떤 부분을 잘 수행하고 있고 어떤 부분이 잘 안 되는지를 알고 싶다. 책을 쓴다는 것은 교훈을 공유할 기회지만, 새로운 교훈을 모으는 것도 중요하다.

폴 클레먼츠, 릭 케즈먼, 마크 클라인 --- '저자 서문' 중에서

최근 소프트웨어 아키텍처에 대한 관심이 점차 높아지면서 다양한 서적과 교육과정들도 속속 생겨나고 있습니다. 또한 실제 현장에서도 아키텍처를 정의하는 절차에 따라 아키텍처 정의서를 작성하는 사례도 많아지고 있으며 이를 전담하는 아키텍트도 늘어나고 있습니다. 이 모두 소프트웨어 업계가 점차 성숙한다는 측면에서 반가운 일이지만 구축된 소프트웨어 아키텍처가 올바른지를 검증하는 일은 아직 부족한 상황이라고 할 수 있습니다.

저희 역자들이 몸담은 시스템 통합(SI) 프로젝트를 살펴보면 대부분 상용 또는 오픈소스 솔루션을 이용하는 환경에서 아키텍처를 수립하게 됩니다. 이처럼 각기 특정 기술이나 독자적인 아키텍처를 바탕해 만들어진 아키텍처 구성요소들을 기반으로 애플리케이션의 기능을 구현함에 있어 발생하는 위험요소와 절충점을 사전에 파악하는지의 여부는 성공을 가름하는 중요 요소가 됩니다. 따라서 아키텍트는 다양한 의사결정의 조합으로 발생하는 결과가 목표에 부합하는지를 확인하는 데 많은 시간을 할애해야 하지만 이런 시간은 잘 주어지지 않는 게 현실입니다. 따라서 많게는 수 백 명의 개발자가 준수해야 하는 아키텍처가 달성하고자 하는 목표에 얼마나 근접한지를 확인할 수 있는 절차나 검증 방법은 매우 단편적인 경우가 대부분이며 실제 오픈에 다다라서야 문제를 알 수 있는 경우가 많습니다.

한편 이와 같은 문제를 개선하기 위해 경험이 풍부하고 실력 있는 여러 엔지니어가 참여하더라도 고객의 요구사항과 개발자의 수준을 고려하지 않고 자신이 적용해본 특정 기술을 적용하는 일만 지향하거나 이들간의 이견을 효율적으로 조율할 수 있는 원칙이 없다면 이러한 접근방법도 심각한 문제를 일으킬 수 있습니다.

이 책에서 소개한 아키텍처 평가는 소프트웨어 공학이라는 관점에서 봤을 때 가장 최적의 비용으로 최대의 효과를 보장하는 안전장치라고 할 수 있습니다. 앞에 설명한 바와 같이 다양한 참여자들 간의 의견 공유를 통해 프로젝트의 중요한 의사결정을 내려야 할 때 편중된 의견을 효과적으로 조율하거나 침묵하는 다수 의견을 가시화하는 일은 매우 어렵습니다. 따라서 아키텍처 평가의 가장 중요한 효과는 이러한 프로젝트 참여자들 간의 역학관계를 매우 효과적으로 대응할 수 있는 방안을 제시한다는 점입니다. 이는 아키텍처 평가가 아키텍처 방향성을 수립하는 데 참여, 공유, 개방이라는 키워드에 매우 잘 들어맞는다고 할 수 있습니다. 이 책을 읽는 독자들도 저희 역자들이 느낀 아키텍처 평가의 효과를 공감하고 특히, 평가되는 데에 대해 두려움을 느끼기보다는 평가를 할 수 있음에 안도감을 느낄 수 있기를 바랍니다.

베타리더에 참여하셔서 이 책을 번역하는 데 조언을 주신 옥상훈님, 강용석님, 차병태님, 최정일님과, 물심양면의 도움은 물론 뜨거운 관심을 보여 주신 한국 소프트웨어 아키텍트 연합회 회원들과 회사 선배님, 동료들에게 감사드립니다.