요구사항
모든 요구 사항을 수렴하는 소프트웨어는 존재하지 않는다 . - Mark Richards
전 프로젝트를 시작할 때 항상 꺼내는 이야기가 있습니다 . 소프트웨어 아키텍트 들이라면 알아야 하고 , 이해해야 하며 , 그리고 고객 , 동료와 함께 꼭 프로젝트 시작 전 나눠야 하는 이야기가 있습니다 .
1620 년대에 스웨덴과 폴란드의 전쟁에서 나온 ‘Vasa 호 ’ 라는 배 이야기입니다 . 스웨덴 국왕은 전쟁을 빨리 끝내기 위해 Vasa 호라는 특별한 배를 만들라고 주문했습니다 . 이 배가 갖춰야 했던 조건 ( 요구사항 ) 들은 그 당시의 어떤 배와도 비교할 수 없었습니다 . 선체가 200 피트 정도 더 길고 , 2 개의 갑판에 64 개의 총을 적재할 수 있고 , 300 명의 군사를 안전하게 태워 폴란드로 가는 바다를 가로지를 수 있는 수송 능력을 가져야 했습니다 . 배를 건조하는 데드라인 ( 시간 ) 을 엄수해야 했으며 , 재정 ( 자금 ) 적으로도 여유롭지 않았습니다 . 또한 배 설계자 ( 아키텍트 ) 는 이렇게 생긴 배를 이전까지는 설계한 적이 없었습니다 . 크기가 작고 총을 실을 수 있는 갑판이 한 개만 있는 배를 만드는 것이 그가 주로 한 일이었습니다 . 그럼에도 불구하고 , 설계자는 그의 예전 경험을 기반으로 추정하고 Vasa 를 설계하고 건조하기 시작했습니다 . 그 배는 결국 설계대로 건조되었고 마침내 배를 출항하는 날이 왔습니다 . 어떻게 되었을까요 ? Vasa 호는 위풍당당하게 항구를 출항했지만 예포를 쏘고 난 뒤 바로 바다 저 밑으로 가라앉고 말았습니다 .
Vasa 호의 문제는 명확합니다 . 그 어느 누구도 1600~1700 년에 큰 전투함에서 갑판을 본적이 없었고 이러한 배의 갑판은 특히 전쟁 중에 붐비고 안전하지 않다는 것을 알았습니다 . 전투함과 운송선 2 개의 역할을 다하는 하나의 배를 건조하는 것은 큰 실수였죠 .
국왕의 모든 소원을 충족하려고 한 배 설계자는 균형이 맞지 않고 , 불완전한 배를 만들 수밖에 없었던 것입니다 . 저희 소프트웨어 설계자들은 Vasa 호로부터 많은 것을 배울 수 있습니다 . 이와 같은 불행한 사건을 소프트웨어 아키텍처의 설계에 적용할 수도 있겠죠 . 하지만 Vasa 호와 같이 모든 요구사항을 충족시키려는 시도는 궁극적으로 아무것도 수행할 수 없는 불완전한 아키텍처를 만들게 됩니다 .
프로세스와 팀 빌딩
가장 큰 문제는 기술이 아니라 기회를 잡을 수 있느냐 이다. - Mark Ramm4)
대부분의 프로젝트들은 사람에 의해 만들어지며, 사람들은 성공과 실패에 대한 기반이 됩니다. 따라서, 사람들을 성공할 수 있게 만드는데 도움이 되는 것에 대해 생각해 볼 필요가 있습니다. 한편으로는, “단지 일을 올바로 하지 않고” 프로젝트를 어렵게 하는 누군가가 있다는 가망성에 대해 충분히 생각해 볼 수 있습니다. 이러한 경우들에서 문제를 해결하는데 필요한 기술은 매우 오래되었지만 정말 잘 입증되었습니다. 사실 이 기술은 인류의 역사에서 가장 중요한 기술 혁신일 것입니다. 여러분에게 필요한 것은 대화입니다. 기교로써 대화에 단지 익숙해지는 것만으로 충분하지 않습니다. 존경심을 가지고 사람을 대하는 것을 배우고, 사람에 대한 성급한 판단을 버리는 것을 배우는 것이 영리한 아키텍트가 유능한 아키텍트로 변하는 핵심 기술 중에 하나입니다.
설계
불확실성을 설계의 지표로 사용해라! - Kevlin Henny7)
여러분이 설계 시 둘 중 하나를 선택해야 한다면 대부분은 중요한 것을 선택합니다. 하지만 설계(소프트웨어 또는 다른 것들) 시에는 그렇게 해선 안 됩니다. 두 가지 선택사항이 존재한다는 것은 설계 시 불확실성을 고려할 필요가 있다는 것은 알려주는 지표(indicator)입니다. A와 B 두 가지 중 하나를 결정하려고 시도하는 것보다는 A와 B 사이의 결정을 덜 중요하게 만들기 위해 어떻게 설계해야 할지를 고민해야 합니다. 흥미로운 것은 A와 B 사이의 (적절한) 선택이 존재한다는 것입니다. 설계 시 변경되는 결정을 쉽게 수용할 수 있는 분할(separation) 또는 캡슐화 기법을 고민할 필요가 있습니다.
