아날로그 장애 퍼펫 옷장: 장애 이후 ‘블레임스톰’을 무력화하는 종이 페르소나

장애는 스트레스 그 자체입니다. 시스템은 멈추고, 고객은 화를 내고, 리더들은 답을 요구하며, 엔지니어들은 후폭풍을 각오합니다. 그 다음에 열리는 회의—포스트모템, 인시던트 리뷰, RCA(근본 원인 분석) 뭐라고 부르든—는 학습과 회복탄력성을 가속할 수도 있고, 방어적이고 정치적인 블레임스톰(blamestorm) 으로 전락할 수도 있습니다.

이 글에서는 여러분을 첫 번째 방향으로 확실히 잡아줄 의외로 저기술(로우테크) 도구를 소개합니다. 바로 아날로그 장애 퍼펫 옷장(Analog Incident Puppet Closet) 입니다. 벽에서 실제로 뽑아 들어 올리고, 그걸 ‘통해 말하는’ 종이 페르소나 세트를 이용해, 팀이 실패에 대해 이야기하는 방식을 바꾸는 방법입니다.

왜 블레임리스 포스트모템이 실전에서는 그렇게 어려울까

많은 조직이 말로는 블레임리스 포스트모템을 한다고 합니다. 하지만 실제로 그렇게 하는 곳은 훨씬 적습니다. 장애가 매출에 타격을 주는 순간, “누가 잘못한 거야?” 라는 중력은 엄청나게 강하게 끌어당깁니다.

하지만 효과적인 포스트모템의 초점은 전혀 다릅니다.

단일 루트 코즈(root cause) 가 아니라, 기여 요인(contributing causes) 을 찾는다
무엇이, 어떻게, 왜 일어났는지를 탐구한다
개인에게 책임을 묻기보다, 시스템, 프로세스, 인센티브, 정보 흐름을 들여다본다
“더 조심해야 한다” 같은 이름뿐인 대책이 아니라 구체적인 학습과 개선 사항을 남긴다

여기서 진짜 막히는 건 프로세스가 아니라 심리적 안전감(psychological safety) 입니다.

사람들이 망신, 징계, 평판 손상, 은근한 커리어 불이익을 두려워한다면, 그들은 이렇게 행동합니다.

정보를 숨기고
자신이 사건에 기여한 부분을 축소하고
“바보 같은 질문”을 피하고
공동 학습보다 자기 보호에 에너지를 쏟습니다.

블레임리스 포스트모템은 사람들이 실수, 불확실성, 아슬아슬했던 순간(near‑miss) 을 편하게 인정할 수 있을 때만 작동합니다. 바로 여기서 퍼펫 옷장이 힘을 발휘합니다.

퍼펫 옷장의 등장: 심리적 안전감을 위한 저비용 해킹

아날로그 장애 퍼펫 옷장은 말 그대로, 혹은 비유적인 의미로, 상자/옷장/벽 한쪽에 보관해 두는 종이 페르소나 세트입니다. 장애에 관여하는 실제 이해관계자의 관점을 대표하는, 간단하고 이름이 붙은 캐릭터들이죠.

예를 들면 이런 식입니다.

Ops 올리비아(Ops Olivia) – 각종 알람을 동시에 처리하는 온콜 엔지니어
Dev 댄(Dev Dan) – 마감 압박을 받으며 기능을 개발·배포하는 개발자
SRE 샘(SRE Sam) – SLI/SLO를 모니터링하는 SRE/신뢰성 엔지니어
Product 프리야(Product Priya) – 로드맵과 리스크를 저울질하는 프로덕트 매니저
Customer 케이시(Customer Casey) – 장애의 영향을 직접 겪는 외부 고객
Support 사미라(Support Samira) – 고객의 불만과 고통을 최전선에서 받는 지원 담당자
Exec 일라이(Exec Eli) – 로그가 아닌 대시보드와 헤드라인만 보는 임원

이 캐릭터들은 재미로 만든 만화가 아니라, 사람 중심의 도구입니다. 목표는 다음과 같습니다.

이해관계자의 니즈와 압박을 눈에 보이게 만든다
실제 사람과 이야기 사이에 적당한 거리감을 만들어 준다
대화를 “왜 당신이 그렇게 했나요?” 에서 “이 순간에 올리비아는 무엇을 겪었을까?” 로 옮겨 간다

즉, 당신과 당신의 실수에 대해 직접 이야기하는 대신, 그 역할과 맥락을 대표하는 페르소나를 통해 이야기할 수 있게 됩니다.

페르소나가 블레임스톰을 무력화하는 방식

페르소나는 디자인·프로덕트 분야에서 사람 중심의 니즈를 잊지 않게 하는 도구로 널리 쓰입니다. 같은 개념을 인시던트 분석에 가져오면 놀랄 만큼 잘 맞아 들어갑니다.

1. ‘악당 찾기’에서 ‘시스템 보기’로 초점을 옮긴다

장애를 페르소나의 시각으로 풀어 보면 자연스럽게 이런 질문을 하게 됩니다.

Ops 올리비아는 03:12에 무엇을 보고 있었나?
Dev 댄은 그 변경을 배포할 때 어떤 정보만 가지고 있었나?
Product 프리야는 그 의사결정을 내릴 때 어떤 압박을 받고 있었나?

그러면 대화는 다음과 같이 바뀝니다.

"알렉스가 런북을 무시했어."

에서,

"Ops 올리비아는 세 개 서비스에서 동시에 페이징을 받고 있었고, 런북은 오래됐고 찾기도 어려웠다. 그러니 7번 단계를 놓친 게 이상하지 않다."

로 달라집니다.

사람들은 더 이상 ‘가해자’를 찾지 않고, 상호작용하는 조건들—나쁜 가시성, 모호한 오너십, 도구 사용의 마찰, 인센티브 불일치—를 보기 시작합니다.

2. 사실을 끝까지 말하기가 쉬워진다

이렇게 말하는 건 무섭습니다.

"저는 너무 피곤해서 체크리스트 항목 하나를 그냥 건너뛰었습니다."

하지만 이렇게 말하는 건 훨씬 수월합니다.

"올리비아 입장이라면, 온콜 19시간 차에, 동시에 세 건의 인시던트를 처리하다 보면, 눈에 잘 안 띄는 체크리스트 항목은 건너뛰었을 가능성이 큽니다."

여전히 현실을 이야기하고 있지만, 보호막 역할을 하는 레이어를 하나 두었기 때문에 수치심이 줄어듭니다. 이 심리적 버퍼 덕분에 더 정직하고, 더 자세한 스토리텔링이 가능합니다.

3. 역할과 기대치를 분명하게 한다

인시던트는 종종 역할 혼선을 드러냅니다.

고객 커뮤니케이션은 누가 책임지나?
롤백(rollback) 결정은 누가 내리나?
언제, 누가 리더십 층에 에스컬레이션(escalation)할 수 있나?

페르소나를 기준으로 이렇게 물어볼 수 있습니다.

장애 상황에서 Support 사미라는 자신의 책임이 어디까지라고 믿을까?
Exec 일라이는 인시던트 채널에서 무엇을 기대할까?

이렇게 하면 모호했던 불만이 구체적인 역할·태스크 명료화로 변하고, 다음 인시던트에서의 협업이 개선됩니다.

퍼펫 옷장 만들기: 쓸모 있는 페르소나 설계하기

UX 리서치 조직이 따로 필요하지 않습니다. 이미 팀 안에 있는 경험만으로도, 정성적으로(qualitatively) 페르소나를 만들고 검증할 수 있습니다.

1단계: 이해관계자 파악하기

장애 상황에 자주 등장하거나 영향을 받는 사람들을 모두 적어 봅니다.

온콜 엔지니어
기능 개발자
SRE / 플랫폼 팀
프로덕트 매니저
고객 지원 / 커스터머 석세스
인시던트 커맨더(incident commander) 역할
보안 / 컴플라이언스
임원 및 경영진

이들을 서로 다른 관점과 니즈를 가진 분명한 역할 그룹으로 묶습니다.

2단계: 페르소나 공동 제작하기

짧은 워크숍을 진행합니다. 각 페르소나에 대해 다음을 정리합니다.

이름과 짧은 소개
인시던트에서의 주요 목표 (예: "서비스를 빨리 복구", "데이터 손실 방지", "사용자 혼란 최소화")
제약과 압박 요인 (데드라인, 온콜 부담, KPI, SLA 등)
주로 보는 정보 소스 (대시보드, 로그, Slack, 티켓 시스템 등)
인시던트 중 대표적인 페인 포인트(pain points)

이 내용을 한 장짜리 템플릿에 담습니다. 프린트해서 붙이고, 원하면 간단한 얼굴도 그려 넣습니다. 물리적으로, 눈에 보이게 만드는 게 중요합니다.

3단계: 정성적 검증하기

그 역할을 실제로 맡고 있는 사람들에게 페르소나를 보여 줍니다.

이렇게 묻습니다: "이게 당신 같나요? 뭐가 빠졌거나 틀린 게 있나요?"
피드백을 반영해 수정합니다.

페르소나는 통계적 정밀함이 필요 없습니다. “아, 이거 내 얘기 같다” 하고 느낄 만큼 인식 가능하고, 그럴듯하며, 공감되는 상태면 충분합니다. 그래야 솔직한 대화를 떠받쳐 줄 수 있습니다.

포스트모템에서 퍼펫 옷장 활용하기

이제 이 페르소나들을 인시던트 리뷰 루틴 속에 녹여 넣을 차례입니다.

1. 퍼실리테이터부터 정하기 (가능하면 외부인)

먼저 퍼실리테이터(facilitator) 를 정합니다. 이상적으로는 해당 인시던트에 직접 관여하지 않은 사람, 특히 사건의 파급력이 크다면 팀 바깥 사람도 좋습니다. 그들의 역할은 다음과 같습니다.

초점을 누가(who) 가 아니라 무엇·어떻게·왜(what, how, why) 에 두게 한다
대화가 다시 비난으로 흐르려 할 때 개입한다
말이 적은 사람에게 발언 기회를 열어 준다
학습과 시스템 개선으로 대화를 이끈다

회의 시작 때, 퍼실리테이터가 실제로 퍼펫 옷장을 열고 관련 페르소나들을 테이블이나 벽면에 꺼내 놓습니다.

2. 타임라인을 페르소나의 시선으로 재구성하기

타임라인을 따라가며 반복해서 묻습니다.

이 시점에서 Ops 올리비아는 무엇을 보고 있었나?
Dev 댄에게는 어떤 시그널만 들어와 있었나?
해당 시점의 Customer 케이시는 상황을 어떻게 경험했을까?
Exec 일라이의 대시보드에는 무엇이 떠 있었나?

이 구조를 통해,

결과를 단죄하기보다 당시에 존재했던 맥락을 재구성하도록 유도하고
서로의 시각이 어긋났던 지점을 드러낼 수 있습니다. (예: 프로덕트 쪽은 영향이 경미하다고 느꼈지만, 지원팀은 티켓 폭주를 보고 있었다든지)

3. 감정을 ‘발견 사항’으로 번역하기

페르소나를 활용해, 감정 반응을 시스템 인사이트로 바꿉니다.

"올리비아는 공황 상태에 가까웠다" → 알람이 너무 시끄럽고(priority 부족), 우선순위가 명확하지 않았다.
"사미라는 모호한 상태 업데이트를 고객에게 설명해야 해서 무력감을 느꼈다" → 더 나은 커뮤니케이션 런북과 명확한 오너십이 필요하다.
"프리야는 뒤통수를 맞은 느낌이었다" → 프로덕트 팀에 대한 사전 인시던트 알림과 상황 공유 프로세스를 개선해야 한다.

이렇게 정리된 내용은 사람의 성격을 탓하는 대신, 구체적인 개선 아이템으로 이어집니다.

4. 학습과 실행 약속을 기록하기

주요 기여 요인(contributing factor)마다 다음을 명확히 적습니다.

어떤 페르소나가 영향을 받았는지
무엇이 그들을 실패하게 만들었는지 (툴링, 프로세스, 지식, 문화 등)
다음에는 그 페르소나의 경험이 어떻게 더 나아지도록 바꿀 것인지

예를 들면:

Ops 올리비아: 알람 노이즈를 줄이고, 알람 메시지 첫 줄에 최신 런북 링크를 노출한다.

Support 사미라: 인시던트 선언 후 15분 이내에 사용할 수 있는 표준화된 상태 공지 템플릿을 제공한다.

부수 효과: 단순한 프로세스 변경보다 강력한 문화 변화

시간이 지나면 강력한 변화 몇 가지가 나타납니다.

공감 증대: 엔지니어는 프로덕트의 제약을, 프로덕트는 온콜의 고통을, 리더십은 현장의 실제 경험을 더 잘 이해합니다.
실패의 정상화: 페르소나를 통해 실수를 이야기하면, 그 맥락에 놓인 누구라도 같은 실수를 할 수 있었음을 보여 줍니다. 그 결과, 수치심과 방어심이 줄어듭니다.
시스템적 사고 강화: 팀은 자연스럽게 "왜 올리비아가 우리를 실망시켰나?" 가 아니라 "우리는 어떻게 올리비아가 실패할 수밖에 없는 환경을 만들었나?" 를 묻게 됩니다.
이해관계자 만족도 향상: 페르소나 덕분에 사람들의 니즈가 계속 전면에 유지되기 때문에, 인시던트 프로세스가 사용자·지원팀·리더십 모두에게 더 인도적이고 효과적으로 바뀝니다.

결국 여러분의 포스트모템은 이름뿐인 블레임리스가 아니라, 진짜로 블레임리스한 실천이 됩니다.

결론: 종이 인형이 만들어 내는 진지한 학습 문화

회복탄력성 있는 시스템은, 회복탄력성 있는 학습 문화를 전제로 합니다. 툴, 런북, 자동화가 중요한 만큼, 우리가 실패에 대해 말하는 방식도 그에 못지않게 중요합니다.

아날로그 장애 퍼펫 옷장은 의도적으로 단순합니다.

몇 장의 종이 페르소나
블레임리스 질문을 지키는 퍼실리테이터
누가(who) 가 아닌, 무엇·어떻게·왜(what, how, why) 에 초점을 맞추는 구조

하지만 이 작은 의식(ritual)이 블레임스톰을 극적으로 줄이고, 심리적 안전감을 높이며, 장애 이후의 대화를 원래 그래야 할 모습으로 되돌려 줍니다. 바로 정직하고, 시스템을 바라보며, 내일의 인시던트를 더 드물고 다루기 쉽게 만드는 탐구의 장으로요.

이걸 시작하는 데 허락은 필요 없습니다. 다음 인시던트 리뷰 전에, 첫 번째 페르소나를 하나 그려 벽에 붙이고 이렇게 물어보세요.

"이 사람이 이번 장애 동안 무엇을 경험했을까? 그리고 다음에는 그 경험을 어떻게 더 낫게 만들 수 있을까?"

진짜 학습은 바로 거기서 시작됩니다.