소프트웨어 품질과 아키텍처의 연관성은 명확해 보인다. 특히 품질 속성 주도의 디자인Attribute-Driven Design이 지배적인 방법론인 것을 고려하면 거의 동의어로 느껴질 정도이다. 이런 이유로 소프트웨어 품질 향상을 위해 아키텍처 평가 방법론을 살펴보는 것도 뜻이 있다고 생각한다. 이 글은 이런 배경에서 쓰였고 따라서 세부 절차보다는 평가 방법론의 주요 개념을 살펴보는 데 집중한다.
일을 끝낸 뒤에 그 결과와 과정을 평가하는 것도 뜻이 있지만 되돌리는 비용이 큰 결정에 앞서 그 결정의 적합성을 검토하고 평가하는 것도 뜻이 크다. 이런 평가가 효율적으로 이루어진다면 시행착오로 인한 비용을 줄이고 그 결정에 근거해서 수행될 일의 질 또한 높여 줄 것은 분명하다. 따라서 많은 선택과 결정이 전체 프로세스 상의 한 지점에서 이루어졌다면, 직후에 양식을 갖추어 평가를 시도하는 것은 고려할 가치가 있다. 오늘 소개하고자 하는 ATAMArchitecture Tradeoff Analysis Method은 소프트웨어 시스템 아키텍처의 장단점을 분석하는 방법론으로써 이런 평가의 취지에 부합한다.
ATAM을 간략히 요약하자면, 제품의 사업 동인business driver으로부터 설계 핵심 요구사항architecturally significant requirement을 선별하고, 이를 바탕으로 다양한 이해관계자의 입장에서 품질 속성 시나리오를 도출한 뒤, 이에 비추어 설계적 결정architectural decision의 적합성과 위험요소를 분석하고 평가하는 활동이다. 조금 더 자세히 살펴보기로 하자.
아키텍처는 보통 디자인 전반을 이르기보다는 개별 디자인에 제약constraint으로 작용하는 큰 틀에서의 방향성이라고 보는 것이 일반적이다. 아키텍처는 다소간 추상적이어서 재활용하기가 쉬우며, 여러 이해관계자의 관심사를 전반적으로 반영하므로 의사소통의 수단으로도 쓸 수 있으나 세부 디자인까지 포괄하지는 않는다. ATAM의 평가 대상인 설계적 결정은 초기 설계 의사결정의 방향으로 볼 수 있다.
ATAM의 권장 시기가 아키텍처 명세화 직후여서 세부 디자인이 존재하지도 않겠지만, 설령 존재한다고 해도 설계적 결정의 평가와 세부 디자인의 평가는 목표와 진행 방식에 차이가 커서 구분하는 것이 낫다. ARIDActive Reviews for Intermediate Design와 같이 세부 디자인을 평가하기 위한 기법에서는 해당 접근방식의 이유 혹은 다른 식의 접근 방식과의 장단점을 묻는 것이 금지된다. 오직 주어진 디자인이 목표를 달성하는 데 오류나 빈틈이 없는지를 묻는 것에 집중한다. 이에 반해 ATAM은, 주어진 아키텍처의 접근 방식이 다양한 품질 속성 시나리오에 비추어 위험요소가 없는지 평가한다.
아키텍처가 아닌 디자인 평가에서 접근 방식 자체를 문제시하는 등의 근원적인 질문으로 세부 디자인 평가가 미궁에 빠지는 것을 막기 위해서라도 먼저 아키텍처 전반에 대한 리뷰를 마치고 그 결과를 공유하는 것이 필요하다.
대상을 평가하는 기법은 몇 가지로 나누어 볼 수 있다. 평가 대상의 범주가 뚜렷하다면 평가 메트릭을 합의하기 쉽고 따라서 이를 기준으로 벤치마크 등과 같은 측정 기법을 활용할 수 있다. 가능한 대답의 종류가 제한된 체크리스트와 같은 질문 기법 또한 평가 대상의 범주가 비교적 뚜렷한 경우에 더 빛을 발한다.
그렇지 않다면 어떻게 해야 할까? 물론 어떤 경우라도 대상을 범주화하고, 측정을 위한 평가 메트릭과 정형화된 질문을 개발하는 식의 성숙한 평가 기법을 궁리해야겠지만 분명 그렇게 하기 힘들 때도 있다. 이런 경우, 즉흥적으로 열린 질문open question을 던진 뒤 나름의 기준으로 판단하는 것은 가장 피해야 할 방식이다. 바로 ATAM이 극복하려는 악습이기도 하다. 열린 질문이 불가피할 때는 대비책을 세워야 한다.
능동적 질문 기법Active Design Review은 그 한 예이다. 예컨대, “모든 프로그램에 예외가 충분히 정의됐는가?”와 같은 질문 대신 “모든 프로그램에서 발생할 수 있는 예외를 적어라.”와 같은 질문을 통해 불충분한 대답 혹은 자의적인 평가의 덫을 피하려 한다.
시나리오도 그 대비책 중 하나다. 예로써 살펴보자. 사람의 품성은 키, 재산과는 달리 소프트웨어의 비기능 요구사항과 닮아서 측정하기 쉽지 않다. 품성을 평하는 자리에서 막연한 호불호를 주장하는 것은 바람직하지 않다. 논의가 공론으로 흐르지 않으려면 그 사람이 구체적으로 어떻게 행동했는지, 혹은 기질상 어떻게 행동할 것인지를 검토하기에 적합한 상황situation을 마련할 필요가 있다. 시나리오는 상황을 명세화specification하기에 좋은 기법이다. 그리고 주어진 상황에서 평가의 기저가 될 만한, ‘정의감’, ‘용기’, ‘친화성’ 등의 개념을 미리 합의하는 것도 요긴하다.
품질 속성은 소프트웨어 품질을 논하기에 좋은 개념 틀이다. 이 역시 구체적인 맥락context이 필요한 데, 이를 표현하는 기법으로 많이 쓰이는 것 또한 시나리오다. 품질 속성은 여러 이해관계자를 고려한 시나리오 하에서 온전하게 논의될 수 있다. 그래서 품질 속성 시나리오라고 부른다. 특정 상황에서 한 사람의 정의감과 친화성 간에 상충trade-off이 발생할 수 있듯이 사려 깊게 작성된 품질 속성 시나리오 또한 설계적 결정이 가진 품질 속성 간의 상충을 드러낸다.
아키텍처가 가진 장단점을 비용 등의 단일한 잣대로 수량화할 때도 품질 속성 시나리오는 유용하다. 비록 그것이 비용을 바로 산출하지는 않지만 CBAMCost Benefit Analysis Method등을 통한 추가 분석이 뒤따른다면 가능하다고 한다. 예컨대, 가용성의 희생 정도와 유지 보수성의 이득 정도를 살펴보는 것, 즉 비용을 수량화하는데 품질 속성의 범주를 사용하는 것은 유용하다는 뜻이다.
사업 동인은 해당 소프트웨어를 개발하는 이유, 더 나가서 사업 목표에 대한 궁극적인 이유를 표현한다.
만약 개발 결과가 가져올 유용성을 열거하는 식으로 사업 동인이 설명된다면 세상에는 대체할 수 있는 것이 많으므로 굳이 소프트웨어를 개발하는 이유는 알 수 없게 된다. 논리적, 실증적 근거와 함께 사업 목표 이면의 전략을 제시할 수 있어야 한다.
평가과정에서 확인된 사업 동인은 설계 핵심 요구사항 선별하고 이를 바탕으로 시나리오를 작성하는 데 기준이 된다. 예컨대, 가용성에 더 무게를 두고 품질 속성 시나리오를 작성할지, 사용자 편의성에 더 무게를 두고 작성할지 판단 근거는 사업 동인으로부터 비롯된다.
따라서 피평가자의 대표는 다다익선 식이 아닌 전략적 관점에서의 사업 동인을 설명해야 하고, 평가자는 평소 자신의 관심사를 넘어서 사업 동인으로부터 시나리오를 도출해야 한다.
문제가 있는 의사 결정은 판단 착오에서 비롯되기도 하지만 중요한 의사 결정이 진행되었다는 것을 인지하지 못하는 데서 비롯되기도 한다. 나쁜 선택을 했다는 것을 인지하지 못한 채 관성대로 진행하는 것이 그 한 예이다. 아키텍처 또한 이와 비슷해서 옹호되기 힘든 선택을 했다는 것을 인지하지 못한 채 비용을 들여 세부 디자인까지 진행해버리는 경우가 있다. 아키텍처 문서가, 존재하지 않거나 너무 많은 것은 주로 이런 데서 연유한다. 불행히도 이런 초기 설계 의사결정의 방향은 시간이 흐른 뒤 되돌리기에 너무 큰 비용이 소요된다.
따라서 아키텍처는 디자인과 구현에 앞서 의식적으로 격리될 필요가 있다. 이것이 전제되지 않는다면 설계 평가 비용은 물론 평가 결과를 반영하는 데 드는 비용은 급격히 증가한다. 만약 이 격리가 성공한다면 많은 것이 생략된 내부 리뷰의 형식으로 설계 평가가 진행된다고 해도 수많은 이득을 기대할 수 있다.
설계 평가는, 세부 디자인이나 유행에 현혹되지 않고 중요한 설계적 결정에 집중하는 눈을 키워주며, 디자인 리뷰의 시간을 줄여주고, 이해관계자 간의 의사소통을 촉진하며, 사업 동인에서 설계 핵심 요구사항에 이르는 과정의 타당성을 살필 계기를 마련해 준다.
용기를 가지고 시도해 보기를 권한다.