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

개념

왜 "게임" 인가

레슨 2 끝에서 "무엇을 알아내고 싶은지 안 떠오르면 반대로 물어본다" 고 했다. 이 레슨이 그 방법이다.

사람은 "무엇이 잘못될 수 있나" 를 직접 물으면 잘 못 떠올린다. 추상적인 질문이라 머릿속에서 잡히지 않기 때문이다. 그런데 같은 것을 "이게 뉴스에 나온다면 제목이 뭘까" 로 바꿔 물으면 갑자기 쏟아져 나온다. 구체적이고 생생한 장면이 떠오르기 때문이다.

그래서 이 레슨은 기법이라기보다 질문을 바꾸는 요령에 가깝다. 30분이면 할 수 있고, 준비물은 종이 한 장이다.

게임 방법

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

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

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

좋은 헤드라인에는 공통점이 있다. 누가 어떤 피해를 입었는지가 들어 있다.

오른쪽 칸들은 읽는 순간 "그게 어떻게 가능한데?" 가 따라온다. 그 질문이 바로 차터가 된다. 왼쪽은 그 질문이 안 나온다 — 그래서 쓸모가 없다.

세 축으로 밀어붙이기

처음 해 보면 두세 개 적고 막힌다. 그때 쓰는 축이 셋 있다.

축 1 — 누구에게. 피해자를 바꿔 본다. 일반 사용자, 어린이, 고령자, 장애가 있는 사용자, 우리 직원, 거래처, 경쟁사, 규제 기관. 같은 결함도 누가 겪느냐에 따라 뉴스 크기가 달라진다.

축 2 — 언제. 시점을 바꿔 본다. 평소, 세일 첫날, 마감 직전, 명절 연휴, 새벽 점검 중, 경쟁사 장애로 사람이 몰렸을 때. 같은 장애도 타이밍이 사고를 만든다.

축 3 — 무엇이 샜나. 피해의 종류를 바꿔 본다. 돈, 개인정보, 시간, 신뢰, 안전, 법적 책임. QA 는 대개 돈과 시간만 떠올리는데, 개인정보와 안전 쪽 헤드라인이 실제로는 더 치명적이다.

세 축을 돌리면 혼자서도 열 개 넘게 나온다. 팀으로 하면 더 빨리 나오고, 서로 다른 축을 자연스럽게 맡는다.

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

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

헤드라인을 차터로 바꾸기

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

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

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

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

변환이 이 기법의 절반이다

헤드라인 자체는 테스트할 수 없다. "이게 일어나려면 무엇이 깨져야 하는가" 를 묻는 단계가 빠지면 재미있는 회의로 끝난다. 변환은 세 단계다.

1. 헤드라인 — "OO은행 앱, 타인 계좌 잔액이 내 화면에 노출"
2. 깨져야 하는 것 — 화면이 "지금 로그인한 사람" 이 아니라 다른 기준으로 계좌를 고르고 있어야 한다. 세션이 섞이거나, 캐시가 남거나, 조회 요청에 계좌 번호가 그대로 실려 바꿔치기할 수 있거나
3. 차터 — "계좌 조회를, 두 계정으로 번갈아 로그인하며 그리고 요청의 계좌 번호를 바꿔 가며 탐험해서, 다른 사람 정보가 보이는 경로가 있는지 찾는다"

2번이 가장 어렵고 가장 값지다. 이 단계에서 기술 지식이 쓰인다 — 세션, 캐시, 요청 파라미터 같은 것을 알아야 "무엇이 깨져야" 를 구체적으로 적을 수 있다. 모르면 개발자에게 물어보는 것이 정답이고, 그 대화 자체가 이 기법의 부수 효과다.

하나의 헤드라인에서 차터가 여러 개 나오는 것이 정상이다. 위 예에서도 세션 쪽, 캐시 쪽, 요청 파라미터 쪽이 각각 다른 세션이 될 수 있다.

변환이 안 되는 헤드라인도 있다

전부 차터가 되지는 않는다. 나오는 것 중 상당수는 QA 가 다룰 수 없는 것이다.

못 다루는 것을 버리라는 뜻이 아니다. 그 목록을 들고 담당자에게 가는 것이 QA 가 할 수 있는 일이다. "이런 시나리오가 나왔는데 이건 우리 범위 밖입니다, 누가 보고 있나요" 라고 묻는 것만으로 공백이 드러나는 경우가 많다.

팀으로 하면 더 잘 된다

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

분야마다 다른 악몽

같은 질문을 던져도 분야에 따라 나오는 헤드라인이 전혀 다르다. 지금 맡은 제품이 어느 쪽인지 알면 어느 축을 더 세게 밀어야 하는지가 보인다.

오른쪽 칸을 먼저 보고 거꾸로 헤드라인을 만들어도 된다. "우리는 돈과 되돌리기가 걸리는구나" 를 알면 "환불이 안 되는 상황" 부터 상상하게 된다.

그리고 이 표에서 하나 더 읽을 것이 있다. 거의 모든 분야에 "되돌리기" 가 들어간다. 사고 자체보다 사고 뒤에 수습이 안 되는 것이 뉴스를 키우기 때문이다. 탐험할 때 "이게 잘못되면 되돌릴 수 있나" 를 습관처럼 묻는 이유다.

거꾸로 읽어 보기 — 실제로 뉴스가 된 것들

이 게임이 억지스럽게 느껴진다면, 이미 일어난 사고를 헤드라인에서 거꾸로 읽어 보면 설득력이 생긴다. 모듈 1 레슨 1에서 본 세 사례다.

세 줄에서 공통으로 보이는 것이 있다. 사후에 보면 전부 "그걸 왜 안 봤지" 싶은 것들이다. 그런데 사전에 케이스 목록을 쓸 때는 아무도 안 적었다.

왜 그런가. 케이스는 "정상적으로 쓰면 어떻게 되는가" 를 적는 문서이기 때문이다. "평소보다 빠르게 누른다", "일부만 배포된 상태로 돌린다" 는 정상적인 사용이 아니라서 목록에 안 들어간다. 머리기사 게임은 정상이 아닌 상황부터 상상하게 만드는 장치다.

세 번째 줄은 특히 QA 에게 시사점이 크다. 코드가 아니라 배포 과정의 결함 이었다. "우리가 시험하는 대상에 배포 자체도 들어가는가" 를 물으면 대부분의 팀에서 답이 "아니오" 다. 그런 공백을 드러내는 것도 이 게임의 몫이다.

나온 차터를 어떤 순서로 하나

30분 워크숍을 돌리면 차터가 열 개쯤 나온다. 전부 할 시간은 없다. 순서를 정하는 기준은 헤드라인 자체에 이미 들어 있다.

세 번째 줄이 자주 간과된다. 화면이 깨지는 결함은 사용자가 바로 신고하지만, 정산이 조금씩 어긋나는 결함은 몇 달 뒤 누적된 다음에야 드러난다. 같은 크기의 결함이면 조용한 쪽이 더 비싸다.

이 기준들은 모듈 4 레슨 2의 리스크 평가와 같은 내용이다. 다만 여기서는 헤드라인을 읽으며 직관적으로 판단하게 된다는 점이 다르다. 숫자를 매기는 대신 "이게 기사로 나가면 어디가 제일 아픈가" 를 묻는 것이다.

혼자 할 때

워크숍을 열 수 없는 상황이 더 많다. 혼자서도 15분이면 된다.

1. 5분 — 세 축(누구에게·언제·무엇이 샜나)을 돌리며 헤드라인을 쏟아낸다. 평가하지 않고 적기만 한다. 열 개를 목표로 한다
2. 5분 — 각각에 "무엇이 깨져야 하나" 를 한 줄씩 붙인다. 모르겠는 것은 물음표로 남긴다 — 그게 개발자에게 물어볼 목록이 된다
3. 5분 — 위 네 기준으로 줄을 세우고 상위 두세 개만 차터로 다듬는다

혼자 할 때의 약점은 분명하다. 내가 모르는 쪽은 안 나온다. 그래서 2번의 물음표 목록을 들고 개발자나 기획자에게 가는 것이 사실상 필수다. "이 중에 실제로 가능한 게 있을까요" 한마디면 충분하고, 대개 그 자리에서 내가 못 떠올린 것 하나를 더 얻는다.

30분 워크숍으로 돌리는 법

실무에서는 보통 릴리즈 전 짧은 워크숍으로 연다. 순서가 정해져 있으면 처음 하는 팀도 돌릴 수 있다.

두 가지가 결과를 가른다.

첫째, 5~12분을 혼자 쓰게 한다. 처음부터 입으로 하면 먼저 말한 사람의 방향으로 전부 쏠린다. 조용히 적게 하면 서로 겹치지 않는 헤드라인이 나온다.

둘째, 12~20분에 평가를 금지한다. "그건 일어날 리 없어요" 한마디가 나오면 그 뒤로 아무도 과감한 것을 안 적는다. 거르는 것은 20분 이후에 해도 늦지 않다.

다른 리스크 발견 방법과 함께 쓰기

이 게임만으로 모든 위험이 나오지는 않는다. 성격이 다른 방법들과 겹쳐 쓸 때 공백이 줄어든다.

가운데 두 줄이 서로를 보완한다. 머리기사는 상상력에 기대고, 결함 이력은 사실에 기댄다. 상상만 하면 엉뚱한 곳을 파고, 이력만 보면 "지난번에 터진 곳" 만 반복해서 본다.

조용히 쌓이는 문제를 놓친다는 점은 특히 기억해 둘 만하다. 이 게임은 극적인 것을 끌어내도록 설계돼 있어서, 뉴스가 안 되는 종류 — 느리게 새는 메모리, 조금씩 어긋나는 정산, 몇 달 뒤 꽉 차는 저장 공간 — 는 거의 안 나온다. 그쪽은 레슨 14의 휴리스틱과 비기능 테스트(모듈 16)가 맡는다.

이 게임이 만드는 다른 효과 — 대화

결함을 찾는 것 말고 부수 효과가 하나 더 있다. 그리고 실무에서는 이쪽이 더 클 때가 있다.

하나, 개발자와 기획자가 위험을 말로 꺼내게 된다. 평소에는 "그거 좀 불안한데" 라고 생각해도 말할 자리가 없다. 헤드라인 게임은 그 말을 꺼내도 되는 자리를 만든다. 실제로 워크숍에서 가장 날카로운 헤드라인은 그 코드를 직접 쓴 개발자에게서 나오는 경우가 많다.

둘, "안 되는 것" 의 목록이 생긴다. 변환 단계에서 "이건 우리가 못 막아요" 가 나오면 그 자리에서 기록된다. 인프라·보안·정책 쪽 공백이 이렇게 드러난다.

셋, 우선순위 대화가 쉬워진다. "이 기능 테스트 더 해야 합니다" 보다 "이게 터지면 '마감일 먹통' 기사가 납니다" 가 훨씬 빨리 통한다. 모듈 26에서 다루는 경영진에게 품질을 말하는 법과 같은 원리다 — 사람은 추상적인 위험보다 구체적인 장면에 반응한다.

이 세 가지 때문에, 결함을 하나도 못 찾은 워크숍도 실패가 아니다. 팀이 무엇을 걱정하는지 한 번 맞춰 본 것만으로도 값을 한다.

실무에서 왜 필요한가

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

헤드라인 목록은 버리지 않는다

워크숍이 끝나면 포스트잇을 치우고 차터만 남기기 쉽다. 헤드라인 목록을 그대로 보관하면 다음 릴리즈부터 값이 붙는다.

• 다음 워크숍의 출발점이 된다. 처음부터 다시 쥐어짜지 않아도 되고, 지난번에 안 나온 축이 무엇인지 보인다
• "그때 나왔었다" 가 확인된다. 실제로 사고가 났을 때 그 헤드라인이 목록에 있었다면, 문제는 발견이 아니라 우선순위 결정이었다는 뜻이다. 이건 팀이 배울 수 있는 종류의 교훈이다
• 반복해서 올라오는 것이 보인다. 세 번 연속 같은 헤드라인이 나왔다면 팀 전체가 같은 곳을 불안해하고 있다는 신호다. 그 영역은 탐험이 아니라 설계를 손봐야 할 수도 있다

보관은 거창할 필요 없다. 차터 목록 옆에 열 하나를 더 두고 어느 헤드라인에서 나왔는지 적어 두면 충분하다. 레슨 2에서 만든 표에 칸 하나를 더하는 정도다.

안 하는 편이 나은 경우

쓸모가 큰 만큼 역효과가 나는 자리도 있다. 세 경우에는 하지 않거나 형태를 바꾼다.

사고 직후. 막 장애를 겪은 팀에서 "최악의 헤드라인을 상상해 보자" 를 하면 책임 추궁처럼 들린다. 이때는 이미 일어난 사고의 회고가 먼저다. 머리기사 게임은 그 뒤에, 다음 릴리즈를 보며 한다.

이름이 거론되는 분위기일 때. "OO 팀이 만든 기능 때문에" 같은 말이 나오기 시작하면 멈춘다. 헤드라인에는 제품만 넣고 사람은 안 넣는다는 규칙을 처음에 못 박아 두면 대부분 예방된다.

실제 사고를 그대로 베낄 때. 다른 회사의 실제 사고를 헤드라인으로 쓰면 "우리는 그런 거 안 해요" 로 닫힌다. 우리 제품의 말로 바꿔 적는다.

채용시장에서의 위치

이 기법 자체를 공고에서 이름으로 찾는 경우는 드물다. 대신 면접에서 거의 같은 질문이 다른 말로 들어온다.

• "테스트 우선순위를 어떻게 정하셨나요?" — "리스크가 높은 것부터" 는 누구나 하는 답이다. "되돌릴 수 없는 것, 사용자가 먼저 아는 것부터" 처럼 구체적인 기준을 말하면 다르게 들린다
• "요구사항이 없는 기능을 어떻게 테스트하셨나요?" — 이 기법이 정확히 그 상황의 답이다. 기준이 없으면 위험에서 거꾸로 만든다
• "팀과 어떻게 협업하셨나요?" — 워크숍을 진행해 본 경험은 혼자 일하지 않는 사람이라는 신호로 읽힌다

리드·매니저 자리에서는 질문이 한 단계 올라간다. "팀의 리스크 발견을 어떻게 운영하셨나요" 를 묻고, 그때 "릴리즈 전 30분 워크숍을 정례로 돌렸고 나온 차터를 우선순위대로 배분했다" 는 답이 그대로 쓰인다.

실습 과제

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

가상의 "병원 예약 앱"에 대해 악몽의 헤드라인을 3개 만든다. 최대한 구체적이고 극적으로 쓴다. 단, 세 축(누구에게·언제·무엇이 샜나)을 각각 다르게 써서 세 개가 서로 다른 종류가 되게 한다.

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

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

과제 3 — 못 다루는 것 가려내기 (10분)

과제 1에서 만든 헤드라인 3개를 다시 보고, 각각이 차터가 되는 것인지 아닌지 판정한다. 안 되는 것은 어디로 가야 하는지를 적는다.

자가 체크리스트

• 악몽의 머리기사 게임의 진행 방법을 설명할 수 있다
• 이 게임이 형식적 리스크 분석과 무엇이 다른지, 왜 보완적인지 설명할 수 있다
• 헤드라인에서 "무엇이 깨져야 이게 일어나는가"를 분석해 차터로 변환할 수 있다
• 이 게임이 팀 단위로 할 때 왜 더 효과적인지 설명할 수 있다
• 센 헤드라인과 약한 헤드라인을 구분하고, 피해자·시점·피해 종류를 넣어 쓸 수 있다
• 막혔을 때 세 축(누구에게·언제·무엇이 샜나)으로 밀어붙일 수 있다
• 30분 워크숍을 진행할 수 있고, 처음 7분을 혼자 적게 하는 이유를 말할 수 있다
• 차터로 못 바꾸는 헤드라인을 가려내 담당자에게 전달할 수 있다
• 이 기법이 놓치는 것(조용히 쌓이는 문제)을 알고 다른 방법으로 메울 수 있다

흔한 실수

• 헤드라인을 너무 얌전하게 쓴다. "버튼이 조금 느리다" 같은 헤드라인은 이 게임의 목적(극단적 리스크를 상상해 진짜 위험을 끄집어내기)에 안 맞는다. 더 과감하고 구체적으로 써야 한다.
• 헤드라인만 만들고 차터로 연결하지 않는다. 헤드라인 자체는 테스트 대상이 아니다 — "무엇이 깨져야 이게 일어나는가"를 분석하는 단계가 빠지면 실제 탐험으로 이어지지 않는다.
• 형식적 리스크 분석(모듈 4)을 완전히 대체한다고 생각한다. 이 게임은 보완 기법이다 — 체계적인 리스크 매트릭스와 함께 쓸 때 가장 효과적이다.
• 처음부터 다 같이 입으로 한다. 먼저 말한 사람 쪽으로 전부 쏠린다. 앞 7분은 각자 조용히 적게 한다.
• 나오는 족족 평가한다. "그건 안 일어나요" 한마디면 그 뒤로 아무도 과감한 것을 안 적는다. 거르는 것은 다 나온 뒤에 한다.
• 차터로 못 바꾸는 것을 그냥 버린다. 우리 범위 밖이라는 사실 자체가 정보다. "그럼 누가 보고 있나요" 를 묻는 것까지가 이 기법이다.
• 극적인 것만 찾다가 지루한 결함을 놓친다. 느리게 새는 메모리, 조금씩 어긋나는 정산은 뉴스가 안 돼서 이 게임에 안 나온다. 다른 방법으로 메운다.

참고 자료

• 이 커리큘럼 안: 레슨 2(차터 작성 — 변환의 도착점), 레슨 14(휴리스틱 — 이 기법이 놓치는 평범한 축을 메운다)
• 이 커리큘럼 안: 모듈 4 레슨 2(리스크 기반 테스트 — 체계적인 쪽), 모듈 50 레슨 1(위협 모델링 — 공격자를 상정한 같은 발상)
• Elisabeth Hendrickson, Explore It! — 악몽의 머리기사 게임을 대중화한 원출처
• Ministry of Testing — Risk Storming — 팀 단위 리스크 발견 워크숍 기법 관련 자료