본문으로 건너뛰기
중급18

악몽의 머리기사 게임 — 리스크를 차터로 바꾸기

이 제품이 뉴스에 최악의 방식으로 나온다면 헤드라인이 뭘까를 상상해 형식적인 리스크 분석이 놓치는 위험을 끄집어낸다.

  • #악몽의머리기사
  • #리스크발견
  • #탐색적테스팅

개념

게임 방법

**"우리 제품이 최악의 방식으로 뉴스에 나온다면, 그 헤드라인은 뭘까?"**를 상상해서 적는다.

  • "OO쇼핑몰, 결제 이중 청구로 수천 명 피해"
  • "OO은행 앱, 타인 계좌 잔액이 내 화면에 노출돼"
  • "OO서비스, 개인정보 수만 건 유출 확인"

일부러 과장되고 극적으로 쓴다 — 이게 핵심이다. 딱딱한 리스크 분석표에는 안 나오는, 직관적으로 무서운 시나리오를 의도적으로 끄집어낸다.

왜 이게 형식적 리스크 분석보다 더 잘 통하는 경우가 있는가

모듈 4(레슨 2)의 리스크 매트릭스는 분석적이고 체계적이다. 하지만 사람은 "발생 가능성 중간, 영향도 높음" 같은 추상적 평가보다 구체적이고 생생한 이야기를 떠올릴 때 더 많은 위험을 상상해낸다. 머리기사 게임은 이 심리적 특성을 활용한다 — "이게 실제로 뉴스에 나온다면?"이라는 질문이 형식적 브레인스토밍보다 더 폭넓고 구체적인 리스크를 끌어낸다.

헤드라인을 차터로 바꾸기

머리기사를 만들었으면, **"이게 실제로 일어나려면 무엇이 깨져야 하는가"**를 물어 차터로 바꾼다.

헤드라인: "OO쇼핑몰, 결제 이중 청구로 수천 명 피해"

→ 이게 일어나려면? "결제 버튼을 여러 번 눌러도 중복 결제가 안 막히거나, 네트워크 재시도 로직이 결제 요청을 중복으로 보내야 한다."

→ 차터: "결제 버튼을 빠르게 여러 번 클릭하거나 네트워크를 불안정하게 만들어가며 탐험해서, 중복 결제가 발생하는지 알아낸다."

팀으로 하면 더 잘 된다

이 게임은 혼자보다 팀 브레인스토밍으로 할 때 효과가 크다. 각자 다른 관점(기획, 개발, QA, 운영)에서 다른 헤드라인을 떠올리기 때문에, 짧은 시간에 다양한 리스크가 쏟아져 나온다. 릴리즈 전 짧은 워크숍 형태로 자주 쓰인다.

실무에서 왜 필요한가

형식적인 리스크 분석은 종종 "이미 알고 있던 위험"을 재확인하는 데 그친다. 머리기사 게임은 "미처 생각 못 했던" 위험을 끌어내는 데 특히 강하다 — 실제로 큰 장애나 보안 사고는 사후에 보면 "왜 아무도 이걸 생각 못 했지?" 싶은 경우가 많다. 이 게임은 그 "생각 못 한" 지점을 릴리즈 전에 미리 건드려보게 한다. 특히 결제, 개인정보, 안전처럼 임팩트가 큰 영역의 릴리즈 전 워크숍에 잘 맞는다.

실습 과제

과제 1 — 헤드라인 만들기 (10분)

가상의 "병원 예약 앱"에 대해 악몽의 헤드라인을 3개 만든다. 최대한 구체적이고 극적으로 쓴다.

과제 2 — 헤드라인을 차터로 바꾸기 (10분)

과제 1의 헤드라인 중 하나를 골라 "이게 일어나려면 무엇이 깨져야 하는가"를 분석하고, 레슨 2에서 배운 형식으로 차터를 작성한다.

자가 체크리스트

  • 악몽의 머리기사 게임의 진행 방법을 설명할 수 있다
  • 이 게임이 형식적 리스크 분석과 무엇이 다른지, 왜 보완적인지 설명할 수 있다
  • 헤드라인에서 "무엇이 깨져야 이게 일어나는가"를 분석해 차터로 변환할 수 있다
  • 이 게임이 팀 단위로 할 때 왜 더 효과적인지 설명할 수 있다

흔한 실수

  • 헤드라인을 너무 얌전하게 쓴다. "버튼이 조금 느리다" 같은 헤드라인은 이 게임의 목적(극단적 리스크를 상상해 진짜 위험을 끄집어내기)에 안 맞는다. 더 과감하고 구체적으로 써야 한다.
  • 헤드라인만 만들고 차터로 연결하지 않는다. 헤드라인 자체는 테스트 대상이 아니다 — "무엇이 깨져야 이게 일어나는가"를 분석하는 단계가 빠지면 실제 탐험으로 이어지지 않는다.
  • 형식적 리스크 분석(모듈 4)을 완전히 대체한다고 생각한다. 이 게임은 보완 기법이다 — 체계적인 리스크 매트릭스와 함께 쓸 때 가장 효과적이다.

참고 자료

  • Elisabeth Hendrickson, Explore It! — 악몽의 머리기사 게임을 대중화한 원출처
  • Ministry of Testing — Risk Storming — 팀 단위 리스크 발견 워크숍 기법 관련 자료