모든 아키텍처는 리스크를 갖고 있다.(가용성, 확장성, 데이터 부정성에 문제는 없을까?)
아키텍처 리스크 분석은 아키텍트의 핵심 활동 중 하나로 리스크를 꾸준히 분석하여 아키텍처의 내부 결점을 바로잡고 리스크를 줄이는 일이다.

20.1 리스크 매트릭스

아키텍처의 리스크를 평가할 때에는 먼치 리스크를 낮음, 높은 정도로 분류할지 결정해야 한다. 리스크 매트릭스를 활용하면 주관성을 낮추고 특정한 아키텍처 영역에서 리스크를 찾아내는 데 도움이 된다.

아키텍처의 리스크 메트릭스는 아래와 같은 모습이다. 전체 리스크 영향도와 발생 가능성, 두 가지 차원으로 리스크를 평가한 뒤 낮음(1), 중간(2), 높음(3) 등급을 매긴 것이다. 괄호 안 숫자와 매트릭스 각 그리트의 숫자를 곱하면 리스크를 객관적인 수치로 정량화 할 수 있습니다. 1, 2는 낮은 리스크(밝은 회색), 3. 나는 중간 리스크(중간 회색), 6에서 파 자는 높은 리스크(짙은 회색)를 나타냅니다.

이를테면, 애플리케이션이 접속하여 사용하는 중앙 데이터베이스의 가용성이 문제가 됐다고 해보자. 첫째, 전체 리스크 영향도 차원을 생각한다. 만약 데이터베이스가 다운되어 사용할 수 없게 되면 전체 시스템이 어떤 영향을 받을까? 아키텍트는 당연히 리스크가 높다고 보고 3(중간)이나 6(높음), 또는 9(높음)로 매길 것이다. 하지만 둘째, 이 리스크의 발생 가능성 차원을 따져보자. 사실, 데이터베이스는 고가용성 클러스터로 구성되므로 전체 서버가 일시 다운되어 불용 상태가 될 가능성은 희박하다. 따라서 높은 영향도 낮은 가능성이 교차하는 지점에서 전체 리스크는 3등급(중간 리스크)을 받게 된다.

리스크 매트릭스로 리스크를 가늠할 때에는 먼저 영향도 차원을 고려한 다음 발생 가능성 차원을 생각해보세요.

20.2 리스크 평가

리스크 매트릭스를 활용하면 리스크 평가를 작성할 수 있다. 리스크 평가는 맥락에 따라 유의미한 평가기준에 대해 전체 아키텍처 리스크를 요약한 리포트이다.

리스크 평가는 천차만별이지만 일반적으로는 애플리케이션의 서비스나 도메인 영역에 기반한 (리스크 매트릭스로 식별한) 평가 기준이 포함된다.

아래는 기본적인 리스크 평가 리포트의 포맷이다. 1-2는 낮은 리스크, 3-4는 중간 리스크, 6-9는 높은 리스크를 의미한다.

이처럼 리스크 매트릭스로 정량화한 리스크는 평가 기준별로, 서비스 또는 도메인 영역별로 누적치를 계산할 수 있다.

예를 들어, 데이터 무결성에 관한 누적 리스크는 총 17점으로 가장 높고, 가용성에 관한 누적 리스크는 10점(최소 리스크 수준)으로 가장 낮다. 상대적 수치를 비교하면 어떤 리스크 범주나 도메인 영역에서 리스크가 개선됐는지, 아니면 반대로 악화됐는지 파악 할 수 있다.

모든 항목의 리스크 분석 결과를 담고 있지만, 보통 이렇게 표현하는 경우는 거의 없다. 주어진 맥락에 맞게 전달하려는 메시지를 잘 표현하려면 필터링이 꼭 필요하다.

아키텍트가 회의에 참석하여 리스크가 높은 시스템 영역을 발표할 경우, 위처럼 필터링을 걸쳐 리스크가 높은 영역만 표시하면 전체적인 신호 대 잡음비가 개선되고 시스템이 지금 좋은 상태인지, 나쁜 상태인지 명확하게 드러난다.

20.3 리스크 스토밍

시스템의 모든 리스크를 아키텍트 혼자 결정할 수는 없다. 아키텍트 한 사람이 리스크 영역을 하나도 빠짐없이 살펴볼 수도 없거니와, 시스템 전 부문을 완벽하게 알고 있는 아키텍트도 없기 때문에 리스크 스토밍을 하는 것이 좋다

리스크 스토밍은 특정 범위 내에 있는 아키텍처 리스크를 찾아내는 협력적인 활동이다. 일반적인 리스크 영역으로는 검증되지 않은 기술, 성능, 확장성, 가용성(전이적 종속성 포함), 데이터 소실, 단일 장애 지점, 보안 등이 있다.

리스크 스토밍의 수행 과정은 개별 파트와 협력 파트가 공존한다. 개별 파트는 모든 참가자가 (다른 사람과의 협력 없이) 앞 절에서 설명한 리스크 매트릭스를 이용하여 각자 알아서 아키텍처 영역에 리스크를 할당한다. 각 참가자가 특정 아키텍처의 영역의 영향을 받거나 주의가 산만해지지 않기 때문에 리스크 스토밍을 할 때에는 이런 비협력적인 활동 역시 꼭 필요하다. 협력 파트는 전체 참가자가 모여 리스크 영역에 대해 공감하고 어떻게 하면 리스크를 줄일 수 있을지 논의한다.

아래 아키텍처를 보면서 리스크 스토밍 과정을 살펴봅시다. AWS 엘라스틱 로드 밸런서는 웹 서버(엔진엑스)와 애플리케이션 서비스가 위치한 각 EC2 인스턴스를 처리한다. 애플리케이션 서비스는 MySQL, 레디스 캐시, 몽고DB를 호출해서 로깅한다. 푸쉬 확장 서버도 함꼐 호출하는데, 이 확장 서버는 다시 MySQL, 레디스 캐시, 몽고DB의 로깅 기능과 연계된다.

리스크 스토밍은 크게 세 가지 활동으로 이루어진다.

1. 식별
2. 합의
3. 완화

식별 활동은 언제나 개별적이고 비협력적이며, 합의와 완하는 모든 참가자가 한데 모여 작업하는 협력적 활동이다.

20.3.1 식별

각 참여자가 아키텍처 내부의 리스크 영역을 개인적으로 식별하는 활동이다. 세부적으로는 다음 단계를 거친다.

1. 리스크 스토밍을 주관하는 아카데트가 협력파트진행하기 하루전에 참가자 전원에게 초대장을 보낸다. 이는 아키텍처 다이어그램(또는 파일 경로), 리스크 스토밍 부분(리스크 스토밍을 하여 분석할리스크 대상 영역), 리스크 스토밍의 협력파트를 진행할 날짜 및 장소가 적혀 있다.
2. 참가자는 리스크 매트릭스를 이용해 개별적으로 아키텍처를 분석하고 리스크를 낮음(1-2), 중간(3-4), 높음(6-9)으로 분류한다.
3. 참가자는 작은 색상별(초록색 노란색 빨간색) 포스트잇 메모지에 (리스크 매트릭스에 기재한) 리스크 번호를 각각 기재한다.

리스크 스토밍은 보통 한 가지 특정 부분(예: 성능)만 분석하지만 인력, 일정 등의 사정에 따라 한 번에 여러 부문(예: 성능, 확장성, 데이터 소실)을 분석하는 경우도 있다.

리스크 스토밍을 할 때에는 가급적 한 가지 부문으로 제한해라. 그래야 참가자가 거기에만 집중하고 동일한 아키텍처 영역에서 식별되는 다수의 리스크 영역과 헷갈리지 않는다.

20.3.2 합의

리스크 스토밍에서 합의는 참가자 모두가 아키텍처 내부의 리스크에 대해 뜻을 함께 한다는 목표를 생각해보면 매우 협력적인 활동이다.

리스크 스토밍 세션 참가자들은 각자 리스크를 발견한 영역의 아키텍처 다이어그램에 포스트잇을 붙이기 시작한다. 전자 버전으로 할 경우, 리스크 스토밍을 관장하는 아키텍트는 모든 참가자에게 리스크가 식별된 아키텍처 영역의 다이어그램에 리스크를 배치해달라고 요청한다.

포스트잇을 다 붙인 후 리스크 스토밍의 협력 파트가 시작된다. 리스크 스토밍의 목표는 사람들이 한 팀이 되어 리스크 영역을 분석하고 과연 그것이 리스크가 맞는지 합의를 이끌어내는 것이다. 위 그림을 보면 다양한 아키텍처 리스크 영역이 식별됐다.

1. 일래스틱 로드 밸런서의 리스크에 대해 두 참가자는 리스크 중간(3). 나머지 한 참가자는 리스크 높음(6)으로 식별했다.
2. 한 참가자가 푸시 확장 서버를 리스크 높음(9)으로 식별했다.
3. 세 참가자가 MySQL 데이터베이스를 리스크 중간(3)으로 식별했다.
4. 한 참가자가 레디스 캐시를 리스크 높음(9)으로 식별했다.
5. 세 참가자가 몽고DB 로깅을 리스크 낮음 (2)으로 식별했다.
6. 다른 아키텍처 영역은 모두 리스크가 없는 것으로 보고 따로 포스트잇을 붙이지 않는다.

이 중 3,5번은 세 참가자 모두 리스크 레벨과 당위성에 동의했으니 더 이상 논의할 필요가 없지만, 1번은 의견 차이가 있었고 2,4번은 한 명의 참가자만 리스크라고 생각하기 때문에 합의활동을 통해 논의되어야 한다.

검증되지 않았거나 알려지지 않은 기술은 해당 부문에서 리스크 매트릭스를 사용할 수 없으니 가장 높은 리스크 등급(9)을 매겨라.

20.3.3 완화

모든 참가자가 아키텍처 리스크 영역에 대해 합의한 후 마지막으로 가장 중요한 리스크 완화 활동을 한다. 아키텍처에서 리스크를 줄이려면 일반적으로 아키텍처의 특정 영역을 변경 또는 개선하는 작업이 필요하다.

식별된 리스크에 따라 원래 아키텍처를 완전히 바꿔야 할 수도 있지만, 처리량 병목 이슈를 줄이기 위해 배압 큐를 추가하는 등 간단한 아키텍처 리팩터링만으로 해소되는 경우도 있다.

아키텍처를 어떻게 변경하든 모든 작업에는 추가 비용이 들어가므로 주요 이해관계자들은 리스크를 줄이기 위해 그 만한 비용을 부담할 가치가 있는지 결정한다.

전체 아키텍처는 물론, 아키텍트와 비즈니스 이해관계자들 간의 협상에도 리스크 스토밍은 상당한 영향을 미칠 수 있다. 앞부분에서 설명한 리스크 평가와 리스크 스토밍 기법을 적절히 혼용하면 리스크 식별 및 추적, 아키텍처 개선, 주요 이해관계자 간의 협상을 진행하는 과정에서 큰 도움이 될 것이다.

20.4 애자일 스토리 리스크 분석

리스크 스토밍은 아키텍처는 물론, 다른 소프트웨어 개발 분야에도 응용할 수 있다. 가령, 우리는 스토리 그루밍을 하면서 이번 애자일 이터레이션에서 유저 스토리를 완료하는 데 전체적으로 어떤 리스크가 있는지 알아보는 용도로(그래서 결국 그 이터레이션의 전체 리스크 평가를 하려고) 리스크 스토밍을 활용했다. 리스크 매트릭스를 사용하면 유저 스토리의 리스크는 첫 번째 차원(해당 이터레이션에서 이 스토리가 완료되지 않을 경우의 전체 영향도)과 두 번째 차원(스토리가 완료되지 않을 가능성)으로 식별할 수 있다. 동일한 아키텍처 리스크 매트릭스를 스토리에 활용함으로써 리스크가 높은 스토리를 찾아내고 그런 스토리를 주의 깊게 추적해서 우선 순위를 두는 것이다.