소개

대부분의 인시던트 리뷰는 같은 후회로 끝납니다. “신호는 다 있었는데, 출시 전에 한데 모으지 못했다.”

팀은 보통 로그, 테스트, 대시보드, 출시 체크리스트를 갖고 있습니다. 하지만 없는 것이 있습니다. 바로 새로운 기능이 어디서, 얼마나 크게 우리를 다치게 할 가능성이 있는지에 대한, 모두가 공유하는 시각적 그림입니다.

여기서 등장하는 것이 바로 아날로그 인시던트 레이더(Analog Incident Radar) 입니다. 위험한 기능을 내보내기 전에 그리는, 한 장짜리 손그림 위협 지도(threat map) 입니다. 이게 공식적인 위협 모델링이나 보안 리뷰를 대체하는 건 아닙니다. 그 위에 빠르고 실용적인 레이어를 하나 더 얹어서, 모두가 리스크 지형을 한눈에 같은 그림으로 볼 수 있게 해 주는 도구입니다.

이 글에서는 아날로그 인시던트 레이더를 어떻게 설계하고, 활용하고, 유지할지 다룹니다.

• 한 장짜리 위협 지도가 어떻게 생겼는지
• 꼭 짚어야 할 다섯 가지 핵심 차원
• 프로덕트/엔지니어링/보안 대화에서 이걸 어떻게 쓰는지
• 리스크를 완화책(mitigation)과 관측(Observability)에 어떻게 연결하는지
• 한 번 만들고 잊혀지는 PDF가 아니라 살아있는 산출물로 유지하는 방법

"아날로그 인시던트 레이더"란 무엇인가?

아날로그 인시던트 레이더를 특정 기능이나 변경 사항에 대한 리스크 스케치(risk sketch) 라고 생각하면 됩니다.

• 한 페이지: 반드시 화면 한 장 또는 A4 한 장에 들어가야 합니다.
• 시각 우선: 사분면, 축, 레이더/스파이더 차트 등 10초 안에 감이 오는 형태여야 합니다.
• 협업 기반: 프로덕트, 엔지니어링, 보안이 함께 대화하며 만듭니다.
• 행동과 연결: 큰 리스크에는 최소 한 개 이상의 구체적인 완화책이 붙어 있어야 합니다.

모든 가능성을 다 적어 넣는 게 목적이 아닙니다. 이 기능이 진짜로 당신의 하루를 망칠 수 있는 소수의 방법과, 그 일이 벌어졌을 때 피해를 어떻게 제한할지에 집중하는 겁니다.

이 레이더는 이런 상황에서 사용합니다.

• 위험도가 높거나 유저에게 큰 영향을 주는 기능을 출시하기 전
• 대규모 아키텍처 변경이나 마이그레이션 전에
• 위험도가 높은 실험 플래그를 켜기 전에

출시가 매출, 데이터 무결성, 신뢰를 깨먹을 수 있는 힘을 갖고 있다면, 그 론칭은 아날로그 인시던트 레이더를 가질 자격이 있습니다.

소수의 핵심 차원에 집중하라

쓸모 있는 위협 지도는 ‘의견이 분명한(opinionated)’ 도구입니다. 20가지를 추적하지 마세요. 다섯 가지 핵심 차원으로 시작하고, 필요에 따라 조정하세요.

1. Impact(영향도) – 잘못됐을 때 얼마나 치명적인가?

   • 핵심 매출 흐름에 영향을 주는가?
   • 데이터 손실, 데이터 훼손, 프라이버시 이슈 위험이 있는가?
   • 브랜드 신뢰나 컴플라이언스를 해칠 수 있는가?

2. Likelihood(발생 가능성) – 실패나 오·남용이 얼마나 일어날 법한가?

   • 이 코드 경로가 새롭거나 복잡한가?
   • 불안정한 의존성이나 검증되지 않은 가정을 많이 타고 있는가?
   • 결제, 인증, 프로모션처럼 공격/오·남용에 매력적인 영역인가?

3. Detectability(탐지 가능성) – 문제가 생겼을 때 얼마나 빨리, 얼마나 분명히 알아챌 수 있는가?

   • 해당 이슈를 드러낼 메트릭, 로그, 알람이 있는가?
   • 온콜 담당자가 몇 시간씩 파지 않아도 문제를 눈에 띄게 볼 수 있는가?

4. Blast radius(피해 범위) – 문제가 퍼지는 범위가 얼마나 넓은가?

   • 한 명의 유저인가, 특정 코호트인가, 전체 고객 기반인가?
   • 특정 리전인가, 전체 인프라인가?

5. Recovery difficulty(복구 난이도) – 피해를 되돌리는 일이 얼마나 어려운가?

   • 플래그를 내리거나 롤백 한 번으로 안전하게 되돌릴 수 있는가?
   • 복잡한 데이터 복구나 수작업 개입이 필요한가?

각 주요 리스크 시나리오에 대해 이 차원들을 빠르게 평가합니다. 단순 1–5 점수 스케일이나, 시각적인 위치로 표현하면 충분합니다.

한 장짜리 위협 지도를 스케치하는 방법

화이트보드, 태블릿, 간단한 드로잉 툴이면 무엇이든 좋습니다. 핵심은 빠르고 읽기 쉬울 것, 예쁘게 만드는 게 아닙니다.

한 가지 단순한 포맷을 예로 들어 보겠습니다.

1. 2×2 또는 레이더 차트로 시작하기

흔히 쓰기 좋은 두 가지 레이아웃이 있습니다.

• 2×2 그리드

  • X축: Likelihood(발생 가능성, 낮음 → 높음)
  • Y축: Impact(영향도, 낮음 → 높음)
  • 각 리스크를 점 하나로 찍습니다. 색/모양으로 Detectability나 Blast radius를 표현할 수 있습니다.

• 레이더(스파이더) 차트

  • 축: Impact, Likelihood, Detectability(역방향), Blast Radius, Recovery Difficulty
  • 각 리스크가 이 축들에서 어떤 프로필을 가지는지 다각형으로 표현합니다.

대부분의 팀에는 2×2 그리드만으로도 충분하고, 훨씬 빨리 도입할 수 있습니다.

2. 현실적인 리스크 시나리오 5–10개 선정

예를 들어, 새로운 청구(billing) 기능을 론칭한다면 이런 시나리오를 떠올릴 수 있습니다.

• 고객에게 중복 청구가 발생
• 아예 청구가 되지 않음
• 청구서 상태가 일관성 없이 꼬임
• 결제 관련 민감 데이터가 로그에 일부 노출
• 레이트 리밋(rate limiting) 때문에 정상적인 대량 작업까지 차단

“시스템 불안정” 같은 모호한 문장은 피하세요. 구체적으로 적습니다. 예: “EU 유저의 20% 이상에서 체크아웃 지연이 3초를 넘는 상태”

3. 각 리스크를 지도 위에 배치하기

각 시나리오에 대해 팀이 함께 질문합니다.

• 이게 발생했을 때 얼마나 심각한가? (Impact)
• 출시 첫 주 안에 실제로 일어날 가능성이 얼마나 되나? (Likelihood)
• 문제가 나면 얼마나 빨리, 얼마나 분명히 알아차릴까? (Detectability)
• 몇 명의 유저/얼마나 많은 시스템에 영향을 미칠까? (Blast radius)
• 뒷수습이 얼마나 고통스러운가? (Recovery difficulty)

2×2 그리드에서는 Likelihood/Impact를 기준으로 점을 찍고, 그 옆에 이렇게 주석을 답니다.

• 아이콘이나 색으로 Detectability 표시 (예: 초록 = 발견 쉽고, 빨강 = 발견 어려움)
• 숫자나 라벨로 Blast radius 표시 (예: 1 = 소수 유저, 3 = 전체 유저)

페이지 한쪽에는 간단한 표를 더해 둡니다.

이게 바로 당신의 아날로그 인시던트 레이더입니다. 한눈에, 큰 골칫거리 리스크들이 어디에 모여 있는지 모두가 볼 수 있습니다.

팀 간 트레이드오프를 명시적으로 만들기

이 위협 지도의 진짜 가치는 문서 그 자체가 아니라, 그걸 둘러싼 대화에 있습니다.

프로덕트, 엔지니어링, 보안 담당을 한 자리에 모아 이 지도를 함께 훑어보세요.

• 프로덕트: “이 리스크는 첫 번째 5% 코호트까지는 감수할 수 있지만, 전 유저 대상 롤아웃에서는 안 됩니다.”
• 엔지니어링: “여기서 Likelihood를 줄이려면 테스트와 부하 검증에 일주일 정도 더 필요합니다.”
• 보안: “이 데이터 유출 리스크는 로그 스크러빙과 더 강한 접근 통제가 없이는 수용 불가합니다.”

이 지도를 통해 이런 질문에 답합니다.

• 어떤 리스크는 출시를 막는 수준(Show-stopper) 이고, 어떤 것은 가드레일을 전제로 수용 가능한가?
• 어떤 리스크는 출시 전에 반드시 줄여야 하고, 어떤 건 100% 롤아웃 전에만 줄이면 되는가?
• 이 기능을 켜기 전에 어떤 수준의 Observability(모니터링과 가시성), Alerting 이 필요할까?

대화가 끝나면 팀은 다음을 명확히 문서화해야 합니다.

• 어떤 리스크를 수용(accept) 하는지, 그리고 그 이유는 무엇인지
• 어떤 리스크를 감소(reduce) 시키기로 했는지, 그리고 어떻게 줄일 것인지
• 어떤 리스크는 차단(block) 되어 있으며, 어떤 완화책이 준비되기 전까지는 진행 불가인지

이렇게 하면 속도와 안전 사이의 트레이드오프가 흐릿하고 암묵적인 상태가 아니라, 명시적이고 합의된 형태로 드러납니다.

각 리스크를 구체적인 완화책에 연결하기

Impact와 Likelihood가 모두 높은, 오른쪽 위 코너의 리스크에는 최소 한 개 이상의 완화책이 필요합니다. 단순한 규칙 하나를 세우면 좋습니다.

빨간 점 리스크에는 반드시 이름이 박힌 완화책과 책임자가 있어야 한다.

자주 쓰이는 완화 패턴은 다음과 같습니다.

• Feature flag(기능 플래그)

  • 점진적 롤아웃 (1% → 10% → 50% → 100%)
  • 위험한 경로를 즉시 비활성화할 수 있는 스위치

• Rate limit와 쿼터

  • 오·남용과 폭주 프로세스를 방지
  • DB, 서드파티 API 등 하위 서비스 보호

• Rollback과 안전한 배포 전략

  • Blue/green, canary 배포
  • 스키마/설정 변경에 대한 사전 검증된 롤백 경로

• 추가 테스트

  • 가장 위험한 플로우에 대한 타깃 유닛/통합 테스트
  • 핵심 의존성 주변에 대한 Chaos 테스트나 부하 테스트

• 추가 모니터링 및 알람

  • 에러율, 레이턴시, 행태(예: 환불 급증)를 추적하는 새 메트릭
  • End-to-end 플로우를 확인하는 Synthetic check

위협 지도 하단에는 리스크와 완화책을 잇는 간단한 표를 추가합니다.

이렇게 하면 위협 지도는 단순한 리스크 목록이 아니라, 실행 가능한 완화 계획이 됩니다.

레이더를 릴리스와 Observability에 연결하기

아날로그 인시던트 레이더는 기존 도구와 연결될 때 비로소 진짜 힘을 발휘합니다.

각 주요 리스크에 대해 다음을 결정합니다.

• 어떤 신호(signal)가 이 리스크가 실제로 발생했음을 알려줄까?

  • 에러? 타임아웃? 특정 로그 패턴? 고객지원 티켓 급증?

• 그 신호를 어디서 측정할까?

  • 메트릭 대시보드 (예: Prometheus, Datadog, CloudWatch)
  • 로그 시스템 (예: ELK, Splunk)
  • 트레이스 (예: OpenTelemetry, Honeycomb)
  • 세션/이벤트 분석 (예: Amplitude, Mixpanel)

• 어떤 알람 임계값에서 행동을 촉발할까?

  • "5분 동안 더블 차지 에러 비율 >2%" → 온콜에 페이지 발송
  • "EU 유저 대상 체크아웃 레이턴시가 10분 이상 2초 초과" → 카나리 자동 롤백

위협 지도에는 각 리스크에 대해 다음을 적어 둡니다.

• Signal: 우리가 보는 지표 (메트릭, 로그 패턴, 트레이스 스팬, 세션 이벤트 등)
• Alert: 임계값과 채널 (Slack, 페이지, 이메일 등)
• Response: 첫 번째 대응 단계 (롤백, 플래그 비활성화, 레이트 리밋 상향 등)

이제 이 지도는 출시 전에 한 번 그리고 마는 문서가 아니라, 일이 꼬였을 때 온콜이 바로 참고할 수 있는 운영 대응 가이드가 됩니다.

살아있는 산출물로 유지하기

이 위협 지도를 일회성 체크리스트로 취급하는 것이 가장 나쁜 사용법입니다.

대신, 다음 두 가지 정기적인 리추얼에 녹여 넣으세요.

1. 릴리스 기획 단계

각 롤아웃 단계(베타 → 10% → 100%)로 넘어가기 전에, 지도를 짧게라도 다시 봅니다.

• 새로운 코드나 아키텍처 변화로 리스크 프로필이 바뀐 것은 없는가?
• 실제 운영 데이터를 근거로 우려 수준을 낮출 수 있는 리스크는 없는가?
• 전체 롤아웃 전에 새로운 완화책이나 더 빡센 알람이 필요한 지점은 없는가?

지도에 간단히라도 수정 사항을 적습니다. 릴리스 노트 옆이나 런북이 담긴 문서와 같은 위치에 보관하세요.

2. 포스트 인시던트 리뷰

문제가 실제로 발생했을 때는 다음을 합니다.

• 당시의 원래 위협 지도를 꺼냅니다.
• 질문합니다: 이 리스크는 레이더에 있었는가? 아니었다면, 왜 빠졌는가?
• 있었다면, 완화책이 충분했고 실제로 배포/적용되어 있었는가?
• 이번 학습을 반영해 각 차원, 완화책, 신호 정의를 어떻게 업데이트해야 할까?

그다음 지도를 수정하고, 필요하다면 템플릿까지 업데이트하여 다음 팀이 이 학습을 재사용하게 합니다. 시간이 지나면 패턴 라이브러리가 쌓입니다. 비슷한 유형의 리스크와 완화책이 반복해서 등장하는 걸 보게 될 것이고, 다음 번 지도 작성 속도는 점점 더 빨라집니다.

결론

대부분의 무서운 이슈를 잡아내는 데 거창한 프로세스가 꼭 필요한 건 아닙니다. 필요한 건, 리스크가 어디에 있는지와 어떻게 대응할지를 팀이 함께 공유하는 공통된 그림입니다.

아날로그 인시던트 레이더는 다음을 제공합니다.

• 각 위험 기능마다 갖는 한 장짜리 시각적 위협 지도
• 프로덕트, 엔지니어링, 보안이 리스크를 이야기할 때 쓰는 공통 언어
• 리스크와 완화책, 그리고 Observability 신호 간의 직접적인 연결
• 릴리스와 인시던트를 거치며 함께 진화하는 살아있는 산출물

다음에, 출시를 앞두고 왠지 불안한 기능이 있다면 한 시간만 멈춰 보세요. 화이트보드나 간단한 드로잉 툴을 켭니다. 위협 지도를 스케치하고, 함께 논쟁하고, 구체적인 완화책과 알람을 붙입니다.

그 한 페이지가, 매끄러운 론칭과 다음 대형 인시던트 리뷰 사이를 가르는 차이가 될 수 있습니다.