브라운 페이퍼 리라이어빌리티 바자: 의도적으로 ‘마찰이 있는’ 인시던트 운영 만들기

운영(Operations), SRE, 혹은 플랫폼 엔지니어링 일을 하고 있다면, 뭐든 더 매끄럽게, 더 빠르게, 더 “자동화해서 없애버리라”는 압박을 느껴봤을 겁니다. 인시던트는 드물어야 하고, 감지는 즉각적이어야 하며, 대응은 유려하게 흘러가야 하고, 복구는 고통 없이 이루어져야 한다고 말이죠.

겉으로는 완벽해 보입니다. 하지만 그렇게 하다 보면, 어느 순간 조용히 취약해집니다.

이 글은 언뜻 역행처럼 들리는 이야기를 다룹니다. 바로 인시던트 운영에 일부러 마찰을 추가하는 것입니다. 모든 것을 한 번에 펼쳐놓는 **“브라운 페이퍼 리라이어빌리티 바자(Brown Paper Reliability Bazaar)”**를 떠올려 보세요. 프로세스, 실수, 기묘한 엣지 케이스까지 몽땅 드러내 놓고, 사람들이 공개된 자리에서, 서두르지 않고, 호기심을 갖고 천천히 들여다보게 하는 겁니다.

이 글의 논지는 이렇습니다. 신뢰성은 속도와 업타임만의 문제가 아니다. 신뢰성이란 조직이 시간에 걸쳐 불확실성을 어떻게 다루느냐의 문제다. 그리고 그 능력은 툴과 수학만큼이나, 아니 그 이상으로 조직 문화와 실천 방식에 달려 있습니다.

신뢰성은 단지 “안 내려가게 유지하는 것”이 아니다

리라이어빌리티 엔지니어링은 종종 “절대 다운되면 안 되게 하는 것” 정도로 오해됩니다. 실제로는 이 정의에 더 가깝습니다.

시스템의 전체 수명에 걸쳐, 불확실성과 실패 위험을 관리하는 일.

여기에는 다음과 같은 것들이 포함됩니다.

시스템이 드물고 이상한 상황에서 어떻게 동작하는지
사람들이 그 시스템을 어떻게 이해하고, 어떻게 운영하는지
실패와 아슬아슬한 근접 사고(near-miss)로부터 무엇을 어떻게 학습하는지
시스템과 조직이 변함에 따라, 운영 관행이 어떻게 진화하는지

MTBF, SLO, 리라이어빌리티 함수, 고장 확률 같은 수학·통계 모델은 강력한 도구입니다. 이들은 리스크를 사고하고, 트레이드오프를 판단하는 데 큰 도움을 줍니다. 하지만 지속 가능한 신뢰성은 수학과 인간의 실천이 만나는 지점에서 나온다는 점이 중요합니다.

예를 들어:

인시던트는 재빨리 감지되나요, 아니면 고객이 먼저 불평해야 알게 되나요?
알람이 뜨면, 사람들은 무엇을 해야 하는지 알고 있나요?
압박이 심한 상황에서, 인시던트 역할과 권한이 명확하게 정해져 있나요?
인시던트로부터 배운 것을 실제로 조직 차원에서 실행에 옮기고 있나요?

이 지점에서 잘 설계된 인시던트 대응 계획(Incident Response Plan, IRP) 이 필수적이 됩니다.

효과적인 인시던트 대응 계획이 실제로 하는 일

인시던트 대응 계획(IRP)은 위키에 올려 둔 런북(runbook)만을 의미하지 않습니다. 제대로 된 IRP는 다음에 대한 명확하고 실행 가능한 지침을 제공합니다.

인시던트 감지(Detecting)
- 무엇을 보고 “문제가 생겼다”고 판단하나요?
- 어떤 임계값, 알람, 시그널이 진짜로 중요한가요?
인시던트 대응(Responding)
- 누가 책임자(Incident Commander)인가요?
- 내부·외부 커뮤니케이션은 어떻게 하나요?
- 어떤 조치를 먼저 취할지 어떻게 결정하나요?
인시던트 복구(Recovering)
- 어떻게 서비스를 안전하게 복구하나요?
- 시스템이 다시 안정적이라는 것을 어떻게 검증하나요?
- 복구 과정에서 더 큰 피해를 내지 않으려면 어떻게 해야 하나요?

그리고 이 모든 것은 단 하나의 명시적인 목표를 향합니다.

조직 전체에 미치는 영향을 최소화한다.

이 “영향”은 단지 업타임만이 아닙니다. 여기에 포함되는 것은:

고객 신뢰
운영 비용과 번아웃
평판 리스크
규제 및 컴플라이언스 리스크 노출

좋은 IRP는 모든 것이 혼란스럽게 느껴질 때 사람들이 붙잡을 수 있는 기준점이 되어 줍니다. 하지만 IRP를 정적인 문서, 즉 한 번 만들어 놓고 “완료”하는 것으로 취급하면, 그 가치는 금방 퇴색합니다.

바로 여기서 ‘마찰이 있는(friction‑full)’ 운영 관행이 필요해집니다.

왜 ‘마찰이 있는’ 운영 관행이 필요한가

대부분의 조직은 본능적으로 마찰을 제거하려 합니다.

단계 줄이기
점검 줄이기
승인 절차 줄이기
더 많은 자동화

그중 일부는 분명히 건강한 방향입니다. 하지만 모든 마찰을 제거하는 것은 위험합니다. 그 말은 종종 곧 다음을 의미하기 때문입니다.

정말로 인간의 판단이 필요한 순간에도 그 판단을 우회하거나 생략하고
사람들이 제대로 이해하지 못한 도구 뒤로 복잡성을 숨기고
원래는 더 신중하게 생각해야 할 상황을, 너무 빠르게 밀고 지나가 버리는 것

‘마찰이 있는’ 운영 관행이란, 워크플로우 안에 ‘생각하게 만드는 저항’을 의도적으로 집어넣는 것을 말합니다. 그냥 형식적인 관료주의가 아니라, 복잡성과 불확실성을 외면하고 지나치지 못하게 붙잡아 두는 구조입니다.

예를 들면 이런 것들입니다.

고위험 작업용 체크리스트
(예: 페일오버, 스키마 마이그레이션, 긴급 패치)
중요 변경 사항에 대한 사전 검토(Pre‑flight Review)
공식 인시던트 역할 할당
(인시던트 커맨더, 기록자(scribe), 커뮤니케이션 담당 등)
티켓을 완전히 닫기 전에 진행하는 의무적인 포스트 인시던트 리뷰

이런 것들이 존재하는 이유는 단순히 속도를 떨어뜨리기 위함이 아닙니다. 그 목적은:

숨어 있는 가정을 드러나게 만들고
압박 상황에서도 공통된 이해를 만들며
가장 싸고 가장 쉽게 바로잡을 수 있을 때 오류를 발견하게 하는 데 있습니다.

항공 분야를 떠올려 보세요. 파일럿들은 고도로 훈련받은 전문가이지만, 여전히 체크리스트를 씁니다. 그 이유는 무능력을 보완하기 위해서가 아니라, 복잡하고 고위험인 시스템 안에서 “인간”이라는 존재의 한계를 보완하기 위해서입니다.

브라운 페이퍼 리라이어빌리티 바자

다음과 같은 실험을 상상해 봅시다.

큰 인시던트가 하나 지나간 뒤, 관련된 메트릭, 로그, 타임라인, 슬랙 스레드, 스크린샷, 그래프를 전부 출력합니다.
이걸 커다란 벽 전체에 빼곡히 붙입니다. 말 그대로 ‘브라운 페이퍼’ 스타일이죠.
인시던트에 참여했던 사람들(그리고 몇 명의 외부인도)을 초대해서, 다 같이 그 이야기를 따라 걸어가며 되짚어 봅니다.

그리고 이런 질문을 던집니다.

우리가 가장 먼저 눈치챈 것은 무엇이었나?
이 시점에 우리는 무엇을 당연하게 여기고 있었나?
어디에서 ‘추측’을 했고, 그게 그때는 왜 합리적으로 느껴졌나?
툴이나 알람 설계 방식 때문에, 어떤 신호를 보지 못했나?

이게 바로 **리라이어빌리티 바자(Reliability Bazaar)**입니다. 조직이 한곳에 모여, 이야기를 교환하고, 가정을 드러내고, 함께 학습하는 구조화되고 공유된, 마찰이 있는 공간입니다.

꼭 종이로 할 필요는 없습니다. 중요한 것은 다음 세 가지입니다.

눈에 보이게 만들 것 (티켓 코멘트 속에만 숨겨 두지 말고)
협업적으로 진행할 것 (한 사람이 템플릿만 채워 넣고 끝내지 말고)
구조를 가질 것 (비난이 난무하는 자유 토론이 아니라, 가이드된 질문과 흐름을 가진 리뷰)

이것이 바로, 포스트 인시던트 리뷰를 컴플라이언스 체크리스트가 아니라 학습 이벤트로 대할 때의 모습입니다.

인시던트를 ‘수정’이 아닌 ‘학습’의 기회로 바꾸기

구조화된 포스트 인시던트 리뷰에는 몇 가지 양보할 수 없는 특징이 있습니다.

블레이믈리스(blameless)하지만, 책임은 있는 방식
누구를 탓할지를 찾는 데 집중하지 않습니다. 당시 사람들이 가진 정보, 도구, 압박 환경 속에서 왜 그런 행동이 “그때는 합리적으로 보였는지”를 이해하려고 합니다. 책임은 “누가 혼나는가”가 아니라, 조직이 무엇을 어떻게 바꾸는가에서 드러나야 합니다.
타임라인 재구성
실제로 어떤 일이 벌어졌는지를 다시 짚어 봅니다. 알람, 의사결정, 액션, 커뮤니케이션 흐름 등을 모두 정리하면서, 숨은 의존성과 오해를 드러냅니다.
다양한 관점 수렴
온콜 엔지니어뿐만 아니라, 프로덕트, 고객 지원, 영향받은 다른 팀도 포함해야 합니다. 인시던트는 사회기술적(sociotechnical) 현상입니다. 시스템과 사람의 교차점에서 발생합니다.
구체적인 개선 사항 도출
“더 주의하자” 같은 말로 끝내지 않고, 실제 액션 아이템을 남겨야 합니다. 알람 튜닝, 런북 개선, 교육/훈련, 코드 변경, 프로세스 조정 등 구체적인 변화로 이어져야 합니다.

리뷰를 잘하면, 이 작업은 두 가지 효과를 동시에 가져옵니다.

다음 인시던트에서의 대응 능력 향상
(역할 수행이 매끄러워지고, 커뮤니케이션이 개선되고, 신호가 더 명확해집니다.)
시스템 전체의 회복 탄력성(resilience) 강화
(더 나은 설계, 더 안전한 디폴트, 더 현실적인 훈련으로 이어집니다.)

핵심은 지속성입니다. 1년에 한 번 하는 멋진 리뷰 하나보다, 의미 있는 인시던트와 근접 사고마다 “적당히 괜찮은 리뷰”를 꾸준히 하는 편이 훨씬 더 값집니다.

인시던트 운영을 지속적·반복적인 루프로 만들기

가장 성숙한 조직은 인시던트 관리를 **일회성 소방전이 아니라, 지속적·반복적인 실천(practice)**으로 취급합니다. 각 인시던트에서 얻은 교훈을 다음에 반복해서 반영합니다.

시스템 설계
- 더 안전한 아키텍처나 패턴을 도입할 수 있을까?
- 블라스트 레디우스(영향 범위)를 더 잘 격리하거나 제한할 수 있을까?
운영과 툴링
- 대시보드와 알람은, 실제로 압박 속에 있는 사람이 필요한 정보를 보여주고 있는가?
- 런북은 새벽 3시에 봐도 찾기 쉽고, 정확하고, 사용할 만한가?
교육과 온보딩
- 신규 엔지니어들은 과거 인시던트 사례를 체계적으로 접하고 있는가?
- 인시던트 역할을 연습하는 드릴(drill)이나 게임데이(game day)를 진행하고 있는가?
문화와 의사결정
- 사람들이 “뭔가 이상하다”고 느낄 때, 일찍 문제를 제기해도 안전하다고 느끼는가?
- 리더들은 “느낌이 안 좋을 때 잠시 속도를 늦추는 선택”을 장려하고 보상하는가?

시간이 지나면, 이 루프는 인시던트를 개별적인 재난이 아니라, 시스템 설계·구현·운영 방식을 형성하는 정기적인 입력 신호로 바꿉니다. 이것이 바로 장기적인 불확실성을 관리하는 방법입니다.

올바른 종류의 마찰을 추가하는 법: 어디서 시작할까

현재 인시던트 운영이 대부분 즉흥적(ad‑hoc)이라면, 다음과 같은 실질적인 출발점을 고려해 볼 수 있습니다.

최소한의 IRP 정의하기
- 인시던트 심각도(Severity) 레벨과, 각 레벨에서 누가 호출(paging)되는지 정합니다.
- 기본 역할을 정의합니다: 인시던트 커맨더, 커뮤니케이션 담당, 기록자 등.
- “우리가 인시던트를 이렇게 운영한다”는 내용을 한 페이지짜리 가이드로 정리합니다.
가벼운 체크리스트 도입하기
- 인시던트를 공식적으로 선언(Declare)할 때 사용하는 체크리스트.
- 인시던트를 종료(Close)할 때 사용하는 체크리스트(포스트 인시던트 리뷰 일정 잡기 포함).
구조화된 포스트 인시던트 리뷰 진행하기
- 인시던트 후 1주일 이내에, 60~90분 정도로 진행합니다.
- 매번 같은 템플릿과 같은 진행 방식(퍼실리테이션 스타일)을 사용합니다.
- 비난이 아닌 **맥락(context)**에 집중합니다.
학습 내용을 눈에 보이게 만들기
- 정기적인 “리라이어빌리티 리뷰” 미팅이나 엔지니어링 뉴스레터 형태로 공유합니다.
- 반복해서 등장하는 패턴과 테마는 플랫폼/프로덕트 팀의 백로그 아이템으로 전환합니다.
의도적으로 점진 개선하기
- 분기마다, 인시던트 자체가 아니라 인시던트 운영 프로세스를 리뷰합니다.
- 이렇게 질문해 보세요: 무엇이 너무 무거웠나? 무엇은 너무 느슨했나? 어디에 더 많은 마찰이 필요했고, 어디에는 마찰을 줄여야 했나?

목표는 완벽한 프로세스가 아닙니다. 목표는 **시스템과 사람에 맞춰 계속 진화하는 살아 있는 실천(practice)**입니다.

결론: 신뢰성은 장기전이다

빠른 감지와 신속한 복구는 앞으로도 언제나 중요합니다. 하지만 속도와 ‘매끄러움’만을 최적화하다 보면, 어느새 조직이 자기 시스템의 진짜 복잡성을 이해하고 다룰 수 있는 능력을 갉아먹게 됩니다.

“브라운 페이퍼 리라이어빌리티 바자”라는 사고방식은 이렇게 말합니다.

인시던트의 실제 모습을 있는 그대로 드러내라.
이해를 깊게 하고, 장기적 리스크를 줄이는 데 도움이 되는 의도적이고 사려 깊은 마찰을 추가하라.
모든 인시던트와 근접 사고를, 미래 회복 탄력성에 대한 투자 기회로 취급하라.

다시 말해, 불을 끄는 데서 멈추지 말고, 그 불을 연구하라. 시간이 지나면, 이런 태도가 시스템과 팀을 이렇게 바꿉니다. 단지 장애가 덜 나는 수준을 넘어,

실패가 일어날 때 더 우아하게 실패하고,
더 지혜롭게 복구하며,
매번 그 경험에서 더 깊이 배우는 조직으로 말입니다.