Ch22 아키텍처 위험 분석

한 줄 정의

아키텍처 위험 분석(risk analysis) 은 운영상·구조적 위험을 영향(impact)과 발생 가능성(likelihood) 두 차원으로 정량화하고, 여러 사람의 시각을 합의 과정으로 모아 시스템의 결함과 구조적 부패를 식별·완화하는 활동입니다. 그 핵심 협업 도구가 리스크스토밍(risk storming) 입니다.

쉽게 말하면

아키텍처에는 항상 위험이 따라옵니다. 가용성·확장성·데이터 무결성처럼 시스템이 망가지는 운영상의 위험도 있고, 컴포넌트 간 정적 결합처럼 구조 자체가 썩어가는 위험도 있습니다.

이 위험을 한 사람이 머릿속으로 평가하면 두 가지 함정에 빠집니다. 첫째, 평가가 주관적이라 사람마다 답이 다릅니다. 둘째, 한 명의 시야로는 절대 모든 영역을 볼 수 없습니다.

위험 평가 행렬은 첫 번째 함정을 다룹니다. 위험을 “영향 × 가능성”이라는 두 축의 곱으로 환산해 1~9의 숫자로 떨어뜨립니다. 리스크스토밍은 두 번째 함정을 다룹니다. 아키텍트와 수석 개발자·기술 리더가 함께 모여 각자 위험 영역을 식별하고, 합의하고, 완화책을 만듭니다.

위험 분석은 한 번 하고 끝나는 행사가 아닙니다. 시스템이 프로덕션에 가기 전까지 반복하며, 매 반복마다 아키텍처가 정말 비즈니스 요구사항을 풀고 있는지 검증합니다.

왜 중요한가?

• 해결하는 문제: 위험을 감각이 아니라 정량화된 점수로 다루게 합니다. 그리고 그 점수를 한 사람이 매기지 않고 협업으로 합의하게 합니다.
• 이게 없다면: “데이터베이스가 좀 위험할 것 같다” 같은 막연한 우려만 남습니다. 우려는 우선순위 없이 떠다니다가 결국 프로덕션 장애가 되어서야 실체로 드러납니다. 또 한 사람이 모르는 영역(예: Redis 캐시 운영 경험 없음)이 곧 시스템 전체의 사각지대가 됩니다.

핵심 내용

위험 평가 행렬

위험의 수준이 낮은지·보통인지·높은지를 판정해야 하는데, 이 판단은 본질적으로 주관적입니다. 같은 영역을 두고 한 아키텍트는 고위험으로 보고 다른 아키텍트는 중간 위험으로 보는 일이 흔합니다.

위험 평가 행렬(risk-assessment matrix) 은 이 주관성을 줄이기 위한 도구입니다. 위험을 두 차원으로 분해하고 각각을 낮음(1)·중간(2)·높음(3)으로 평가한 뒤 둘을 곱해 1~9 사이의 점수를 얻습니다.

	가능성 낮음(1)	가능성 중간(2)	가능성 높음(3)
영향 낮음(1)	1	2	3
영향 중간(2)	2	4	6
영향 높음(3)	3	6	9

점수 구간	등급	표시
1~2	낮은 위험	녹색(또는 가장 옅은 회색)
3~4	중간 위험	노란색(중간 회색)
6~9	높은 위험	빨간색(가장 짙은 회색)

영향을 먼저, 가능성을 나중에

행렬을 적용하는 실무 팁은 점수를 영향부터 매기는 것입니다. 영향은 “그 일이 벌어졌을 때 얼마나 아픈가”이고 가능성은 “그 일이 실제로 벌어질 확률”인데, 가능성을 객관적으로 평가하기 더 어렵기 때문입니다.

가능성이 확실하지 않다면 확실해질 때까지 일단 높음(3) 으로 평가하라는 보수적 룰이 추천됩니다. 데이터가 부족할 때는 위험을 과대평가하는 편이 과소평가보다 안전합니다.

적용 예시: 중앙 데이터베이스 가용성

중앙 데이터베이스가 다운되면 시스템이 전부 멈춥니다. 영향은 명백히 높음(3)입니다. 그런데 데이터베이스가 클러스터로 구성된 고가용성 서버에서 운영 중이라면 실제 다운 가능성은 낮음(1)에 가깝습니다.

행렬에서 영향 3 × 가능성 1 = 3(중간 위험) 이 됩니다. 클러스터링이 위험을 가능성 차원에서 끌어내린 셈입니다.

위험 평가표

행렬로 점수를 매기는 법을 알면 그 점수를 모아 위험 평가표(risk assessment) 를 만들 수 있습니다. 위험 평가표는 시스템의 전반적인 위험을 특정 맥락(시스템의 서비스, 하위 도메인 영역, 도메인 영역)에서 의미 있는 평가 기준들로 평가해서 요약한 도표입니다.

평가 기준은 핵심 아키텍처 특성에서 나온다

위험 평가를 여러 차례 수행해 보면 아키텍처 특성이 훌륭한 위험 평가 기준이 됩니다. 시스템의 핵심 특성이 확장성·탄력성·데이터 무결성이라면 굳이 성능 위험을 분석하는 데 시간을 쓸 이유가 없습니다.

이는 위험 분석이 Ch04 아키텍처 특성의 정의·Ch05 아키텍처 특성의 식별 단계와 연결되어야 한다는 뜻입니다. 아키텍처가 지원해야 할 가장 중요한 특성들이 그대로 위험 평가 기준이 됩니다.

표 구조

위험 기준	고객 등록	카탈로그 결제	주문 이행	주문 배송	총 위험
확장성	2	6	1	2	11
가용성	3	4	2	1	10
성능	4	2	3	6	15
보안	6	3	1	1	11
데이터 무결성	9	6	1	1	17
총 위험	24	21	8	11

스프레드시트와 비슷한 형식입니다. 왼쪽에는 위험 기준(아키텍처 특성), 위쪽에는 맥락(도메인이나 하위 도메인)이 옵니다. 각 칸은 위험 평가 행렬에서 산출된 점수입니다.

이 한 장의 표가 두 가지 통찰을 동시에 줍니다.

• 기준 관점: 행 합계로 어느 특성이 가장 위험한지 — 데이터 무결성(17)이 1순위, 가용성(10)이 가장 안전
• 맥락 관점: 열 합계로 어느 도메인이 가장 위험한지 — 고객 등록(24)이 1순위, 주문 이행(8)이 가장 안전

이런 정보는 우선순위를 정하고 위험 완화 노력을 어디에 더 투입할지 결정할 때 직접적인 입력이 됩니다.

맥락 단위는 도메인이나 하위 도메인

서비스 단위로 맥락을 잡으면 세분도가 너무 높아져서 서비스 간 통신·조정 위험을 잡아내기 어렵습니다. 도메인이나 하위 도메인 수준이 적절합니다.

고위험만 필터링하기

위 표는 모든 결과를 보여주지만 이해관계자에게 시스템의 고위험 영역만 부각시키고 싶을 때가 있습니다. 그럴 때는 낮음·중간 위험(잡음)을 생략하고 고위험(신호)만 남깁니다.

위험 기준	고객 등록	카탈로그 결제	주문 이행	주문 배송	총 위험
확장성		6			6
가용성					0
성능				6	6
보안	6				6
데이터 무결성	9	6			15
총 위험	15	12	0	6

신호 대 잡음비를 끌어올리면 메시지 전달이 훨씬 명확해집니다.

방향(direction) 추가하기

지금까지의 표는 특정 시점의 스냅샷일 뿐, 위험이 좋아지는지 나빠지는지를 보여주지 않습니다. 위험의 방향(direction) 은 적합성 함수로 시스템을 지속적으로 모니터링·측정해서 파악합니다.

방향은 위험 점수를 감싼 도형으로 표시합니다.

도형	의미
▲ 위쪽 삼각형	위험이 증가하고 있음 (점수가 올라감)
▼ 아래쪽 삼각형	위험이 감소하고 있음 (점수가 내려감)
● 원	변화 없음

이 표시 덕분에 이전 평가표로는 불가능한 통찰이 생깁니다.

• 카탈로그 결제·주문 이행·주문 배송에서 데이터 무결성이 ▲(나빠지고 있음) — 데이터베이스에 뭔가 문제가 있을지 모르므로 확인 필요
• 고객 등록과 카탈로그 결제에서 보안과 가용성이 ▼ — 개선 중

방향 표시는 한 시점의 위험 평가표를 추세 데이터로 끌어올립니다. 이 단계에 가야 위험 분석이 일회성 워크숍이 아니라 살아있는 거버넌스 활동이 됩니다.

리스크스토밍

아키텍트 혼자서는 시스템 전반의 위험을 판단할 수 없습니다. 이유는 두 가지입니다.

• 혼자 작업하면 일부 위험 영역을 놓치거나 간과합니다
• 시스템의 모든 부분을 완벽하게 아는 아키텍트는 거의 없습니다

리스크스토밍(risk-storming) 은 이 한계를 극복하기 위한 협업 활동입니다. 특정 차원(맥락 또는 기준)에서 아키텍처 위험 수준을 결정합니다. 둘 이상의 아키텍트가 참여하지만, 수석 개발자와 기술 리더의 참여를 강력히 권장합니다. 이들의 구현 관점이 아키텍트가 놓친 위험을 드러내고, 동시에 이들 자신도 아키텍처를 더 깊이 이해하게 됩니다.

진행자(facilitator)

리스크스토밍 활동을 이끄는 아키텍트를 진행자(facilitator) 라고 부릅니다. 세션이 진행되면서 갱신된 아키텍처 도식을 모든 참가자에게 보내는 것이 진행자의 책임입니다.

세 페이즈 구조

graph LR
    P1[페이즈 1<br/>식별<br/>개인 작업] --> P2[페이즈 2<br/>합의<br/>협업]
    P2 --> P3[페이즈 3<br/>완화<br/>협업]

페이즈 1은 반드시 개인별로 따로 수행하고, 페이즈 2와 3은 함께 협업합니다. 이 분리가 핵심입니다 — 식별을 함께 하면 누군가의 의견에 휩쓸려 다른 사람의 독립적 판단이 사라집니다.

페이즈 1: 식별

각 참가자가 위험 평가 행렬을 이용해 아키텍처 위험을 편견 없이 평가하고 기록합니다. 다른 참가자와 영향을 주고받지 않는 것이 이 페이즈의 절대 원칙입니다.

진행자가 미리 보낸 초대장에는 다음이 포함됩니다.

• 아키텍처 도식(또는 그것이 있는 위치)
• 분석할 위험 기준과 맥락
• 협업 세션의 날짜·시간·장소
• 기타 필요한 세부 정보

각자 위험을 낮음(12)·중간(34)·높음(6~9)으로 분류하고, 해당 숫자를 녹색·노란색·빨간색의 작은 스티커 메모(sticky note) 에 적습니다.

한 가지 기준 원칙

대부분의 리스크스토밍 활동은 한 가지 기준 또는 맥락만 분석합니다. “보안이 위험한 부분은 어디인가?” 같은 식입니다. 이 제약이 참가자들이 한 차원에 집중할 수 있게 하고, 실제 위험이 무엇인지에 대한 혼란을 피합니다.

인력이나 시간 확보가 어려워 둘 이상의 기준을 다뤄야 한다면, 스티커 메모 옆에 해당 기준을 기재합니다. 예를 들어 같은 데이터베이스에 한 명은 가용성 위험으로, 다른 두 명은 성능 위험으로 표시한 경우 두 기준을 별도로 논의해야 합니다.

페이즈 2: 합의

이 페이즈의 목표는 위험 영역에 대해 모든 참가자 간의 합의를 끌어내는 것입니다. 진행자가 커다랗게 인쇄한 아키텍처 도식을 벽에 붙이고(또는 대형 화면에 띄우고) 진행할 때 가장 효과적입니다.

합의 페이즈의 진짜 가치

다음 시나리오가 합의 페이즈의 본질을 보여줍니다.

• 두 명의 참가자가 AWS ELB를 중간 위험(3)으로, 한 명이 고위험(6)으로 식별 → 클러스터링 때문에 가능성을 낮춰 합의
• 한 명만 푸시 확장 서버를 고위험(9)으로 식별 → 그 사람이 비슷한 부하에서 푸시 서버가 다운된 경험을 공유 → 다른 참가자들이 인지하지 못한 위험이 드러남
• 한 명만 Redis 캐시를 고위험(9)으로 식별 → 그 이유를 묻자 “Redis 캐시가 뭔가요?”라고 답함 → 참가자에게 생소한 기술이라는 사실이 드러남

마지막 사례가 흥미롭습니다. 참가자가 특정 기술을 모른다는 사실 자체가 아키텍트에게 전체 위험에 대한 귀중한 정보입니다. 이 경우 아키텍트는 다른 기술로 바꾸거나 개발 팀의 역량을 높이는 교육에 비용을 들이기로 결정할 수 있습니다.

입증되지 않은 기술의 처리 원칙

리스크스토밍에서 참가자에게 생소한 기술에는 자동으로 고위험 수준(9)을 배정합니다. 입증되지 않거나 알려지지 않은 기술에는 항상 최고 위험 등급(9)을 부여해야 합니다. 그런 기술에 해당하는 위험 기준이나 맥락에는 위험 평가 행렬을 적용할 수 없기 때문입니다.

이 페이즈는 모든 참가자가 식별된 위험 영역에 합의할 때까지 계속됩니다. 모든 스티커 메모가 통합되면 페이즈가 끝납니다.

페이즈 3: 위험 완화

위험을 완화한다는 것은 대개 원래대로라면 완벽하다고 여겼을 아키텍처의 특정 영역들을 변경하는 일을 수반합니다. 완화 방법은 두 가지 스펙트럼에 걸쳐 있습니다.

• 원래의 아키텍처를 완전히 바꾸는 것
• 제한된 영역에 직접적인 아키텍처 리팩터링(예: 처리량 병목을 줄이기 위해 배압용 대기열 추가)을 적용하는 것

핵심 비즈니스 이해관계자가 빠지면 안 된다

완화 페이즈는 거의 항상 추가 비용을 유발합니다. 그래서 주어진 완화 솔루션의 비용이 위험보다 큰지 결정할 권한을 가진 핵심 비즈니스 이해관계자들을 이 페이즈에 참여시키는 것이 중요합니다.

예시 시나리오: 데이터베이스 가용성을 중간 위험(4)으로 식별하고 클러스터링 + 별도 물리 데이터베이스 분리로 완화 가능하지만 50,000달러가 든다고 합시다. 비즈니스 소유자가 “50,000달러는 과하고 가용성 위험에 따른 비용이 그보다 크지 않을 것”이라고 판단하면, 아키텍트는 두 개의 별도 도메인 기반 데이터베이스로 분리하는 16,000달러짜리 대안을 제시할 수 있습니다. 이 대안이 50,000달러짜리 솔루션만큼 위험을 줄일 수 있다면 이해관계자들이 동의할 것입니다.

이 시나리오는 리스크스토밍이 단순히 아키텍처를 바꾸는 활동이 아니라 아키텍트와 비즈니스 이해관계자의 협상 방식 자체를 구조화하는 활동임을 보여줍니다.

사용자 스토리 위험 분석

리스크스토밍은 아키텍처 위험 식별 외에도 소프트웨어 개발의 여러 측면에 도움이 됩니다. 개발 팀은 스토리 그루밍(story grooming) 도중 사용자 스토리 완성과 관련된 위험을 파악(그리고 결과적으로 해당 반복의 전체 위험을 평가)하는 목적으로 리스크스토밍을 활용할 수 있습니다.

스토리 그루밍은 애자일에서 다음 스프린트를 위해 백로그에 있는 사용자 스토리를 검토하고 정련(refinement)하는 활동입니다. 백로그 정련(backlog refinement)이라고도 합니다.

아키텍트가 사용하는 것과 동일한 위험 평가 행렬을 이용해 개발 팀은 다음 두 가지를 식별합니다.

• 스토리가 반복 내에서 완료되지 않을 때의 전체 영향
• 스토리가 현재 반복에서 완료되지 않을 가능성

이를 통해 고위험 스토리를 식별하고 주의 깊게 추적할 수 있으며, 우선순위를 더 잘 매길 수 있게 됩니다.

리스크스토밍의 실전 예: 간호사 콜센터

리스크스토밍이 실제로 아키텍처를 어떻게 바꾸는지 보여주는 예입니다.

시스템 요구사항

• 서드파티 진단 엔진(diagnostics engine)이 문진 항목을 제시하며, 초당 약 500건의 요청 처리 가능
• 환자는 콜센터로 전화해 간호사와 대화하거나 셀프서비스 웹사이트를 이용할 수 있음(동일 진단 엔진 사용)
• 시스템은 전국 간호사 250명과 수십만 명의 셀프서비스 환자를 동시 지원
• 간호사만 의료 기록 교환 장치로 환자의 의료 기록에 접근 가능
• HIPAA 준수 필수 — 간호사 외에는 누구도 환자의 의료 기록에 접근 불가

핵심 아키텍처 특성은 가용성·탄력성·보안입니다.

초기 아키텍처

세 가지 웹 기반 UI(셀프서비스용·간호사용·관리자용)와 진단 시스템 API 게이트웨이(클러스터화 인스턴스)를 중심으로, 네 가지 백엔드 서비스가 REST로 통신합니다. 외부 시스템(Diagnostics Engine, Medical Records Interface)과는 전용 프로토콜을 씁니다. 모든 서비스가 하나의 중앙 데이터베이스를 공유합니다.

이 아키텍처를 가용성·탄력성·보안 세 차원에서 차례로 리스크스토밍합니다.

가용성 라운드

페이즈 1·2를 거쳐 다음 위험 영역이 도출됩니다.

영역	영향	가능성	점수	근거
중앙 데이터베이스	3	2	6 (고위험)	다운 시 전체 사용 불가
Diagnostics Engine	3	3	9 (고위험)	외부 의존, 가용성 알 수 없음
Medical Records Interface	-	-	2 (저위험)	특정 의료 결정에 필수 아님
그 외	-	-	0	다중 인스턴스 + 클러스터화

완화책 1: 데이터베이스 분리

데이터베이스가 다운되면 통화 라우터가 작동하지 않아 시스템 전체가 멈춥니다. 하나의 물리 데이터베이스를 두 개로 분할합니다.

• 간호사 프로필용 클러스터형 데이터베이스
• 사례 노트용 단일 인스턴스 데이터베이스

이 변경은 가용성 문제뿐 아니라 사례 노트의 보안도 강화합니다(보안 라운드에서 활용됨).

완화책 2: 외부 시스템의 SLA 확인

서드파티 시스템의 가용성은 직접 통제할 수 없습니다. 팀은 두 시스템의 SLA·SLO 공개 여부를 조사합니다.

외부 시스템	SLA	연간 다운타임
Diagnostics Engine	99.99%	52.60분
Medical Records Interface	99.90%	8.77시간

Note

SLA는 일반적으로 법적 구속력이 있는 계약상 합의이지만 SLO는 법적 구속력이 없는 것이 보통입니다.

SLA를 문서화하는 것 자체가 위험 완화입니다. 식별된 위험을 제거할 수 있는 충분한 정보를 얻은 셈입니다. 두 SLA는 수정된 아키텍처 다이어그램에 추가합니다.

탄력성 라운드

탄력성은 사용자 부하의 급증에 대한 대처 능력(가변 확장성, variable scalability)입니다.

간호사는 250명뿐이라 Diagnostics Engine에 동시 접근하는 간호사는 많아야 250명입니다. 하지만 셀프서비스 UI 사용자가 합쳐지면 동시 요청 수는 250보다 훨씬 클 수 있습니다. 특히 독감 시즌과 COVID 유행 시기에는 부하가 크게 증가합니다.

모든 참가자가 Diagnostics Engine 인터페이스를 고위험(9)으로 식별합니다. 이 엔진은 초당 500개 요청만 처리 가능해 예상 처리량을 따라잡지 못할 위험이 있고, REST 인터페이스를 쓰면 처리량 부담이 더 커집니다.

완화책 1: 비동기 메시징으로 변경

API 게이트웨이와 Diagnostics Engine이 비동기 대기열 기반 메시징으로 통신하도록 바꿉니다. 대기열이 누적되면 배압(backpressure) 지점으로 작용합니다.

하지만 비동기 메시징은 응답 도달 시간을 줄여주지는 않습니다. 응답이 늦어져 요청이 만료(타임아웃)될 가능성이 있습니다.

완화책 2: 구급차(Ambulance) 패턴

구급차 패턴은 메시지 채널을 두 개 사용하며, 두 채널의 우선순위를 다르게 둡니다. 간호사 요청을 셀프서비스 요청보다 먼저 처리하게 함으로써 간호사용 UI의 반응성을 개선합니다.

• 간호사용 대기열
• 셀프서비스 환자용 대기열

이것이 위험을 완화하지만, 여전히 대기 시간 문제는 남습니다.

완화책 3: Diagnostics Outbreak Cache Server

특정 진단 질문(주로 독감 등 유행병 관련)을 캐싱해 Diagnostics Engine에 아예 도달하지 않게 합니다. 진단 엔진 호출 수가 줄어든 덕분에 다른 증상과 관련된 동시 요청을 더 많이 처리할 수 있습니다.

graph TB
    GW[API 게이트웨이] --> NQ[간호사 대기열]
    GW --> SQ[셀프서비스 대기열]
    NQ --> DE[Diagnostics Engine Interface]
    SQ --> DE
    GW --> Cache[유행병 진단 캐시]
    DE --> Engine[외부 서드파티<br/>Diagnostics Engine]

리스크스토밍이 없었다면 독감 시즌이 닥쳐서야 이 위험을 알아챘을지 모릅니다.

보안 라운드

HIPAA 규정 때문에 환자의 의료 기록을 제공하는 Medical Records Interface에는 간호사만 접근할 수 있어야 합니다.

진행자는 API 게이트웨이의 인증·권한 부여 검사가 이를 완화한다고 믿었지만, 참가자들의 논의 끝에 모두가 이를 고위험(6)으로 식별합니다. 영향은 높음(3, 관리 직원이나 셀프서비스 환자가 의료 기록에 접근하는 것은 절대 안 될 일). 가능성은 중간(2, 모든 호출이 동일 API 게이트웨이를 통과하기 때문).

완화책: 사용자 유형별 별도 API 게이트웨이

관리 직원·셀프서비스 사용자·간호사 각각에 대해 별도의 API 게이트웨이를 둡니다. 비간호사 호출이 Medical Records Interface에 도달하는 것을 구조적으로 차단합니다.

graph TB
    Admin[관리자용 UI] --> AdminGW[관리자용<br/>API 게이트웨이]
    Nurse[간호사용 UI] --> NurseGW[간호사용<br/>API 게이트웨이]
    Self[셀프서비스 웹 앱] --> SelfGW[진단 시스템<br/>API 게이트웨이]
    AdminGW --> NPM[Nurse Profile Mgmt]
    NurseGW --> CM[Case Management]
    NurseGW --> MRI[Medical Records<br/>Interface]
    SelfGW --> DEI[Diagnostics<br/>Engine Interface]

원래의 아키텍처와 리스크스토밍 후의 아키텍처를 비교하면, 가용성·탄력성·보안에 대한 우려가 모두 해결되어 시스템 성공 가능성이 높아진 결과를 얻습니다.

위험 분석은 일회성이 아니다

리스크스토밍은 일회성 프로세스가 아닙니다. 시스템을 프로덕션에 배치하기 전까지 시스템 개발 수명 주기 전체에서 팀은 위험 영역을 식별하고 완화하기 위한 리스크스토밍을 반복해야 합니다.

리스크스토밍 세션의 횟수와 빈도는 다음 요인에 따라 달라집니다.

• 상황과 요구의 변경 빈도
• 아키텍처 리팩터링 노력
• 아키텍처의 점진적 발전

일반적으로는 주요 기능을 추가한 후 또는 각 반복 주기의 끝에서 특정 차원이나 특성에 대해 리스크스토밍을 수행해서 아키텍처가 올바르고 비즈니스 요구사항을 해결할 수 있는지 확인합니다.

비교 / 트레이드오프

위험 평가 행렬 vs 평가표 vs 방향 표시

도구	입력	출력	한계
위험 평가 행렬	한 항목의 영향·가능성	1~9 점수	한 항목짜리 점수일 뿐
위험 평가표	여러 기준 × 여러 맥락	시스템 전체 위험의 한 시점 스냅샷	추세를 못 봄
방향 표시 평가표	적합성 함수의 시계열 데이터	위험이 좋아지는지/나빠지는지	적합성 함수 인프라 필요

세 단계는 누적적입니다. 행렬 → 평가표 → 방향 표시 순으로 정보 밀도를 올립니다.

식별을 협업으로 vs 개인 작업으로

리스크스토밍이 페이즈 1을 반드시 개인 작업으로 두는 것은 의도적입니다.

식별 방식	장점	단점
협업 식별 (피하라)	빠름	첫 번째 발언자의 의견이 닻이 됨, 소수 의견 묻힘
개인 식별 (권장)	독립적 판단 보존, 모르는 영역 자동 노출	시간이 더 걸림

Redis 캐시 사례가 정확히 이 점을 증명합니다. 협업 식별이었다면 “Redis 캐시가 뭔가요?”라는 질문은 입 밖에 나오기 전에 묻혔을 가능성이 높습니다.

비즈니스 이해관계자 참여 시점

리스크스토밍의 세 페이즈 중 비즈니스 이해관계자는 어디에 들어와야 할까요?

페이즈	이해관계자 참여
1 식별	✗ 기술 판단
2 합의	△ 도메인 지식 필요할 때만
3 완화	✓ 비용 결정 권한자로서 필수

특히 페이즈 3에서 이해관계자가 빠지면 “기술적으로 옳지만 회사가 감당할 수 없는” 완화책으로 미끄러집니다. 50,000달러 vs 16,000달러 시나리오가 이 지점입니다.

내 생각

”주관성”을 인정하는 첫걸음

위험 평가의 본질이 주관적이라는 점을 인정하면서 시작하는 점이 중요합니다. 실무에서 “이거 위험해 보여요”가 의사결정에 안 먹히는 이유는 객관적 근거가 없기 때문이 아니라 그 주관을 정량화·합의하는 절차가 없기 때문입니다.

행렬 + 리스크스토밍은 주관성을 없애려 하지 않습니다. 대신 여러 사람의 주관을 모아 합의된 주관으로 끌어올립니다. 이게 SRE의 SLO 협상이나 보안 위협 모델링과 본질적으로 같은 구조라는 점이 흥미롭습니다.

”확실하지 않으면 일단 높음(3)“의 가치

이 룰이 실무에서 가장 강력합니다. 보통 사람은 모르는 위험을 과소평가하는 경향이 있습니다. 가능성을 모를 때 일단 높음으로 잡고 시작하면 분석을 미루는 인센티브가 사라집니다.

“가능성 1~3 중 못 정하겠으면 3”이라는 룰은 결국 “당신이 지금 무지하다는 사실을 인정하라”는 압박입니다. 이게 위험을 추적할 동기를 만듭니다.

Redis 사례의 진짜 교훈

“Redis 캐시가 뭔가요?”가 발생하는 순간이 리스크스토밍의 가장 가치 있는 출력입니다. 팀의 무지가 시스템의 위험과 같다는 사실을 보여주기 때문입니다.

운영 경험이 없는 기술을 도입할 때는 그 기술 자체의 신뢰성과 별개로 운영 위험이 자동으로 9점입니다. 우리가 가진 SLO·관측·복구 능력이 0이기 때문입니다. 이 통찰은 신기술 도입 결정에 그대로 적용됩니다 — “이 기술 좋은가?”가 아니라 “우리 팀이 이걸 운영할 수 있는가?”가 더 큰 위험 변수입니다.

방향 표시는 적합성 함수와 직결된다

방향 ▲▼ 표시를 진짜로 채우려면 적합성 함수가 미리 깔려 있어야 합니다. “데이터 무결성이 나빠지는 중”을 직관이 아니라 데이터로 말하려면 무결성을 측정하는 자동 체크가 운영되고 있어야 합니다.

이 연결이 위험 분석과 거버넌스를 하나의 흐름으로 묶습니다. 거버넌스 없이는 위험 평가표가 한 시점의 사진에서 멈추고, 위험 평가표 없이는 거버넌스 결과를 의사결정에 연결할 통로가 없습니다.

더 알아볼 것

• 리스크스토밍 진행 가이드 — riskstorming.com 자료
• STRIDE·DREAD 같은 보안 위협 모델링과 리스크스토밍의 차이·결합 방법
• 적합성 함수로 위험 점수의 방향(▲▼)을 자동 산출하는 파이프라인 설계
• 사용자 스토리 위험 분석을 백로그 정련에 통합한 팀의 사례
• 입증되지 않은 기술의 자동 9점 룰을 ADR 결정 기준에 반영하는 방법

관련 개념

• Ch04 아키텍처 특성의 정의 — 평가표의 위험 기준이 되는 핵심 특성
• Ch05 아키텍처 특성의 식별 — 어떤 특성을 위험 분석 대상으로 삼을지 결정
• Ch06 아키텍처 특성의 측정과 거버넌스 — 위험 방향(▲▼)을 채우는 적합성 함수의 기반
• Ch21 아키텍처적 결정 — 위험 평가 결과는 ADR의 결과·준수 섹션에 반영
• Ch23 아키텍처 도식화 — 리스크스토밍 세 페이즈의 시각적 매개체
• Ch24 유능한 팀 만들기 — 리스크스토밍의 협업 페이즈 운영과 직결

출처

• 마크 리처즈, 닐 포드, 라주 간디, 프라모드 사달게. 『소프트웨어 아키텍처 The Basics』. 한빛미디어, 2024. Chapter 22.