모든 소프트웨어 아키텍트들은 모든 것을 가질 수 없다는 것을 알고 이해해야 합니다. 높은 성능, 높은 가용성, 고 수준의  보안 그리고 고 수준의 추상화 모두를 동시에 충족하는 아키텍쳐를 설계하는 것은 사실상 불가능합니다.

소프트웨어 아키텍트들이 알아야만 하고, 이해해야 하는, 그리고 고객, 동료와 함께 대화를 나누어야 하는 진실된 이야기가 있습니다.

이 이야기는 Vasa라 불리는 배 이야기입니다.  1620년대에 스웨덴과 폴란드 사이에 전쟁이 발생했습니다. 스웨덴 국왕은 비용이 많이 드는 전쟁을 빨리 끝내고 싶었고, vasa라 불리는 배를 건조[1]할 것을 명령하였습니다. 이 순간부터, 이 배는 더 이상 평범한 배가 될 수 없었습니다.

이 배가 갖춰야 했던 조건(요구사항)들은 그 당시의 어떤 배와도 비교할 수 없었습니다: 선체가 200피트 정도 더 길고, 2개의 갑판에 64개의 총을 적재할 수 있고, 300명의 군사를 안전하게 태워 폴란드로 가는 바다를 가로지를 수 있는 수송 능력을 가져야 했습니다. 배를 건조하는 데드라인(시간)을 엄수해야 했으며, 재정(자금)적으로도 여유롭지 않았습니다.

배 설계자(아키텍트)는 이렇게 생긴 배를 전에 한번도 설계한 적이 없었습니다. 크기가 작고 총을 실을 수 있는 갑판이 한 개만 있는 배를 만드는 것이 그가 주로 한 일이 였습니다. 그럼에도 불구하고, 배를 설계자는 그의 예전 경험을 기반으로 추정하고, Vasa를 설계하고 건조하기 시작했습니다. 그 배는 결국 설계대로 건조가 되었고 배를 띄우는 날이 드디어 왔을 때, Vasa호는 위풍 당당하게 항구를 출항하였지만 배의 예포를 쏘고 난 뒤 바로 바다의 바닥으로 가라앉고 말았습니다.

Vasa호의 문제는 명확합니다.  그 어느 누구도 1600~1700년에 큰 전투함에서 갑판을 본적이 없었고 이러한 배의 갑판은 특히 전쟁 중에 붐비고 안전하지 않다는 것을 알았습니다. 전투함과 운송선 두 개의 역할을 다하는 하나의 배를 건조하는 것은 큰 실수였습니다. 국왕의 모든 소원을 충족하려고 한 배 설계자는, 균형이 맞지 않고, 불완전한 배를 만들었던 것입니다.

소프트웨어 설계자들은 이 이야기로부터 많은 것을 배울 수 있습니다. 이와 같은 불행한 사건을 소프트웨어 아키텍쳐의 설계에도 적용할수 있습니다. Vasa와 같이 모든 요구사항을 충족시킬려는 시도는, 궁극적으로 아무것도 수행할 수 없는 불 완전한 아키텍쳐를 만들게 됩니다.

트레이드 오프의 좋은 예로 SOA를 point to point 솔루션 같이 동작하게 만드는 요구입니다. 이런 요구는, SOA 접근법에 의해 만들어진 추상화의 다양한 단계를 무시하도록 당신에게 요구하게 됩니다. 그 때문에, 아키텍쳐를 만드는 것이 동네 이탈리안 레스토랑에서 당신이 전통적인 순서대로 어떤 것을 주문하는 것처럼 보이게 됩니다.

아키텍쳐를 설계할 때 어떠한 트레이드오프가 있는지 결정하도록 도와주는 몇 가지 도구들이 있습니다. 두 가지의 유명한 방법으로, 아키텍쳐 트레이드오프 분석 방법(ATAM)과 비용 이점 분석 방법(CBAM)이 있습니다. ATAM과 CBAM에 대한 정보를 더 얻고 싶다면 아래의 웹사이트 주소를 방문하면 됩니다. 웹사이트는 http://www.sei.cmu.edu/architecture/tools/systematam/index.cfm 와 http://www.sei.cmu.edu/architecture/cbam.html 입니다.

Written By Mark Richards.

이 자료는 Creative Commons Attribution 3 라이센스를 준수합니다.

1차 번역 : 김 현종

2차 번역:  손영수