골판지 사건 스토리 관측 타워

소음 위에서 신뢰성 패턴을 바라보는 종이 계단 오르기

신뢰성 업무는 종종 퍼레이드가 한창인 거리 한가운데에서 도시를 연구하려는 느낌과 비슷합니다. 소음과 혼란, 서로 엇갈리는 관점들뿐이죠. 각 사건(incident)은 누군가가 길 한복판에 떨어뜨린 골판지 상자 같습니다. 지저분하고, 다루기 어색하고, 쉽게 피해 지나가 잊어버리게 됩니다.

하지만 그 상자들을 버리지 않고 모은다면—차곡차곡 쌓고, 라벨을 붙이고, 정리한다면—천천히 골판지로 된 관측 타워가 세워집니다. 사건 스토리 하나하나가 모여 종이 계단이 만들어지고, 그 계단을 오르면 소음 너머를 볼 수 있게 됩니다. 패턴이 드러나고, 보이지 않던 사각지대가 눈에 들어옵니다. 신뢰성은 더 이상 그때그때 불을 끄는 소방 훈련의 연속이 아니라, 연습되고 진화하는 하나의 전문적인 실천 영역이 됩니다.

좋은 사이트 신뢰성 엔지니어링(Site Reliability Engineering, SRE)은 사건을 이렇게 다룹니다.

이 글에서는 비난 없는 포스트모템, 프리모템, 옵서버빌리티, 그리고 구조화된 분석 도구가 어떻게 이런 타워를 쌓게 해 주는지 살펴봅니다. 각각의 골판지 사건 스토리가 어떻게 더 안전하고 탄력적인 시스템으로 가는 계단 한 칸이 되는지 이야기합니다.

개별 사건에서 ‘스토리 타워’로

대부분의 조직은 사건을 매우 좁은 시야로 바라보며 시작합니다.

• 뭔가 고장난다.
• 사람들이 급히 모여 해결한다.
• 간단한 회고 글이 올라오거나(혹은 아예 안 올라오거나) 한다.
• 모두 잊고 다음 일로 넘어간다.

이것이 바로 거리 수준에 머무르는 방식입니다. 각 사건을 타워에 붙일 수 있는 또 한 장의 이야기(골판지)로 보지 않고, 그때그때의 고립된 이벤트로만 취급하는 것이죠.

그러나 항공, 원자력, 대규모 인터넷 서비스(대략 1995–2020년)에 이르기까지 다양한 도메인에서 쌓인 장기적인 신뢰성 실천 경험은 한 가지 일관된 교훈을 보여 줍니다.

사건에 대한 체계적이고 구조화된 분석이, 시스템을 더 안전하고 더 탄력적으로 만드는 주된 엔진이다.

‘골판지 사건 스토리 관측 타워’는 바로 그 구조를 설명하는 메타포입니다.

• 각 사건 스토리 = 문서화된 포스트모템 한 편
• 각 스토리가 비슷한 형태를 가진다 = 표준 템플릿과 공통 데이터 구조
• 스토리들끼리 비교가 가능하다 = MTTR 같은 공통 지표와 반복되는 원인 패턴
• 스토리가 쉽게 공유된다 = Slack 같은 협업 도구를 통한 학습 확산

스토리가 충분히 쌓이면, 무엇이 왜 실패하는지에 대한 패턴이 보이기 시작합니다.

비난 없는 포스트모템: 타워의 핵심 블록

타워의 중심에는 *비난 없는 포스트모템(blameless postmortem)*이 있습니다.

비난 없는 포스트모템이란?

비난 없는 포스트모템은 사건에 대한 구조화된, 평가·징계 목적이 아닌 분석입니다. 목적은 처벌이 아니라 학습입니다. “누가 실수했나?” 대신 다음과 같은 질문을 던집니다.

• 실제로 무엇이 어떻게 일어났는가(타임라인)?
• 시스템은 어떻게 동작했고, 그 이유는 무엇인가?
• 이 실패가 가능하거나 일어나기 쉬웠던 조건은 무엇인가?
• 같은 일이 다시 일어나지 않게, 혹은 덜 피해를 주게 하기 위해 시스템이나 프로세스 차원에서 무엇을 바꿀 수 있는가?

왜 ‘비난 없음’이 중요한가

비난은 데이터를 왜곡합니다.

• 사람들은 자신을 보호하기 위해 세부 사항을 누락합니다.
• 위험하지만 필수적인 작업은 음지에서 이루어지게 됩니다.
• 아슬아슬하게 넘긴 ‘니어미스(near miss)’는 보고되지 않습니다.

반대로 비난 없는 포스트모템은 다음을 촉진합니다.

• 정직성: 무엇을 시도했고, 무엇을 건너뛰었으며, 무엇이 헷갈렸는지에 대한 솔직한 기록
• 호기심: 도덕적 판단 대신 시스템이 왜 그런 행동을 했는지에 대한 기술적 궁금증
• 시스템적 사고: 개인이 아닌 가드레일, 툴링, 프로세스에 대한 관점

시간이 지나면, 각 사건은 더 이상 커리어 리스크가 아니라, 타워에 추가되는 골판지 한 장이 됩니다.

프리모템: 타워가 필요해지기 전에 보강하기

포스트모템이 무엇이 실제로 일어났는지를 이해하는 작업이라면, 프리모템(premortem)은 무엇이 일어날 수 있는지를 미리 탐색하는 작업입니다.

프리모템이란?

프리모템은 설계나 기획 단계에서 진행하는 구조화된 연습입니다. 다음과 같이 진행합니다.

1. 새 시스템이나 기능이 프로덕션에서 spectacular하게 실패했다고 가정합니다.
2. 마치 그 실패가 이미 일어난 것처럼, “무슨 일이 잘못됐을까?”를 묻습니다.
3. 그럴듯한 실패 시나리오, 기여 요인, 약한 고리들을 브레인스토밍합니다.

왜 프리모템이 포스트모템을 보완하는가

프리모템은 다음과 같은 역할을 합니다.

• 학습을 미래로 전파: 과거 포스트모템에서 얻은 인사이트와 패턴을, 새로운 설계에서 비슷한 실패를 미리 예상하는 데 활용합니다.
• 숨겨진 가정을 드러냄: “서비스 X는 항상 떠 있을 거야”, “저 플래그를 잘못 설정할 사람은 없겠지” 같은 가정을 의심하게 만듭니다.
• 더 안전한 아키텍처 설계: 한 번 상상한 실패 경로는 서킷 브레이커, 폴백, 피처 플래그, 런북(runbook) 등으로 완화할 수 있습니다.

프리모템은 사건이 실제로 도착하기 전에 상자에 미리 라벨을 붙이고, 구조를 보강해 두는 것과 같습니다. 덕분에 타워는 처음부터 더 단단해집니다.

옵서버빌리티: 좋은 스토리를 위한 원자재

번진 글씨가 가득한 골판지로는 튼튼한 타워를 만들 수 없습니다. 마찬가지로, 신뢰할 수 있는 데이터 없이는 효과적인 포스트모템을 작성할 수 없습니다.

왜 옵서버빌리티가 중요한가

사후 분석은 시스템에서 나오는 고품질 시그널에 의존합니다. 예를 들어 다음과 같은 도구들은

• Prometheus (메트릭과 알림)
• New Relic (APM, 트레이스, 대시보드)
• 로그 집계 플랫폼

과 같은 형태로 타임라인, 메트릭, 트레이스를 제공하여 다음과 같은 질문에 답해 줍니다.

• 사건이 시작되기 직전에 무엇이 변경되었는가?
• 어떤 컴포넌트가 먼저 열화(degradation)를 보였는가?
• 시스템은 무슨 일이 벌어지고 있다고 생각했는가? (예: 에러 메시지, 재시도, 백프레셔 등)

이런 것이 없다면, 포스트모템은 다음과 같은 모호한 서사로 남습니다.

“트래픽이 급증했고, 서비스가 느려졌고, 재시작을 했더니 나아졌다.”

하지만 옵서버빌리티가 잘 되어 있으면, 이렇게 말할 수 있습니다.

• “10:02에, 잘못 설정된 캐시 퍼지(cache purge) 때문에 엣지에서 요청 레이턴시가 세 배로 증가했다.”
• “10:04에, 재시도 정책이 부하를 증폭시키면서 데이터베이스 커넥션 풀 고갈이 발생했다.”
• “10:08에, 수동 재시작이 근본적인 설정 드리프트(configuration drift)를 가려 버렸다.”

이런 수준의 디테일은 설계 변경, 알림 규칙 개선, 런북 업데이트로 이어질 수 있는 실행 가능한 정보입니다.

MTTR와 ‘희생양 찾기’가 아닌 시스템에 대한 집중

구조화된 사건 분석의 핵심 결과 중 하나는 **MTTR(Mean Time to Recovery, 평균 복구 시간)**을 줄이는 것입니다. 즉, 무언가 고장났을 때 서비스를 복구하는 데 걸리는 시간을 줄이는 것이죠.

질문의 관점을 바꾸기

“왜 Alice가 그 잘못된 설정을 배포했지?”라고 묻는 대신, 다음을 묻습니다.

• 왜 단일 설정 변경이 프로덕션 전체를 다운시킬 수 있었는가?
• 왜 우리의 옵서버빌리티와 알림은 블라스트 레이디우스(blast radius)를 더 빨리 보여 주지 못했는가?
• 왜 롤백 절차가 느리거나 불분명했는가?
• 왜 온콜이 적절한 대시보드나 런북을 찾는 데 30분이나 걸렸는가?

이처럼 시스템에 초점을 맞추면, 실제로 MTTR을 줄일 수 있는 레버들이 드러납니다.

• 더 안전한 롤아웃 메커니즘(피처 플래그, 카나리 배포 등)
• 더 나은 알림 라우팅과 명확한 오너십
• 가능한 곳에서의 셀프 힐링(self-healing) 패턴
• 잘 연습된 런북과 인시던트 대응 절차

사람은 언제나 실수합니다. 좋은 SRE 실천은 개개인의 실수가 쉽게 장기 장애로 이어지지 않도록 시스템을 설계하는 데 있습니다.

템플릿: 모든 스토리를 서로 비교 가능하게 만들기

타워를 쌓으려면, 골판지 층들이 최소한 비슷한 크기와 모양을 가져야 합니다. 이것이 바로 표준화된 인시던트 템플릿이 제공하는 가치입니다.

좋은 포스트모템 템플릿은 보통 다음을 포함합니다.

• 요약(Summary): 한 문단 정도의 사건 개요
• 영향(Impact): 사용자에게 보인 현상, SLO/SLA 위반, 비즈니스 영향
• 타임라인(Timeline): 사건과 조치의 구체적인 시간 순서
• 근본 원인(Root cause)들: 단일 트리거가 아니라, 시스템적인 기여 요인들
• 탐지(Detection): 어떻게 이슈를 인지했는지(알림, 고객 문의, 우연한 발견 등)
• 대응(Response): 대응자들이 무엇을 했고, 그 효과는 어땠는지
• 교훈(Lessons learned): 아키텍처, 프로세스, 툴링에 대한 인사이트
• 액션 아이템(Action items): 구체적이고 우선순위가 있는 후속 작업과 책임자

표준 템플릿은 사건을 다음과 같이 만들어 줍니다.

• 반복 가능: 팀이 어떻게 포스트모템을 진행하고 작성해야 하는지 명확해집니다.
• 비교 가능: 여러 사건을 훑어보며 반복되는 패턴을 찾을 수 있습니다.
• 검색 가능: 과거에 비슷한 실패가 있었는지 더 쉽게 찾아볼 수 있습니다.

시간이 지나면, 이런 데이터에 대한 메타 분석도 가능합니다.

• “우리 주요 사건의 30%는 설정 드리프트와 관련 있다.”
• “심각도 높은 인시던트의 절반은 고객이 먼저 발견했다.”

이런 것은 충분한 수의 일관된 스토리가 쌓였을 때만 보이는, 일종의 타워 레벨 인사이트입니다.

타워를 공유하기: Slack과 신뢰성의 사회적 측면

관측 타워가 있어도, 극소수만 올라간다면 큰 의미가 없습니다. 신뢰성이란 역량은, 인시던트에서의 학습이 쉽게 공유될 때 비로소 팀과 조직 전체의 능력이 됩니다.

Slack, Microsoft Teams 같은 협업용 채팅 도구는 다음과 같은 데 매우 적합합니다.

• 새 포스트모템 공지: 전용 신뢰성 채널이나 #incidents 채널에 공유
• 교훈 논의: 플랫폼, 프로덕트, 보안 팀 등 여러 팀이 함께 논의
• 반복 패턴과 횡단 액션 아이템 강조
• 신입 엔지니어 온보딩: 대표적인 “클래식” 인시던트와 포스트모템을 소개

이렇게 하면 개별적인 학습이 분산된 조직적 실천으로 변합니다. 관측 타워는 뒷방 아카이브에 숨은 문서 더미가 아니라, 일상적인 엔지니어링 대화의 일부가 됩니다.

25년간의 신뢰성 실천에서 얻은 교훈

지난 수십 년 동안 다양한 고신뢰(high-reliability) 도메인에서 반복적으로 나타난 몇 가지 공통 주제가 있습니다.

1. 사건은 피할 수 없지만, 무지의 반복은 선택 사항이다.
2. 구조화된, 비난 없는 분석이 같은 실패를 반복하느냐, 그걸 발판 삼아 진화하느냐를 가르는 차이점이다.
3. 고품질 옵서버빌리티는 흐릿한 이야기(story)를 정밀한 엔지니어링 데이터로 바꿔 준다.
4. 표준화와 툴링(템플릿, 런북, 대시보드 등)이 신뢰성 업무를 확장 가능하게 만든다.
5. 협업 도구를 통한 학습의 사회화가 개인의 인사이트를 조직의 지식으로 전환한다.

이런 것들을 1995–2020년 동안, 혹은 2020–2045년까지 일관되게 실천하면, 시스템과 팀은 복잡성이 증가하더라도 꾸준히 더 안전하고 더 탄력적으로 진화합니다.

결론: 종이 계단을 계속 올라가기

각 사건은 골판지에 쓰인 하나의 이야기입니다. 불을 끈 순간 그 종이를 버려 버릴 수도 있고, 라벨을 붙여 관측 타워에 추가할 수도 있습니다.

비난 없는 포스트모템과 탄탄한 옵서버빌리티, 실패를 미리 상상하는 프리모템, 표준화된 템플릿, 그리고 Slack 같은 도구를 통한 개방적인 공유는 모두 함께 작동해, 꾸준히 올라갈 수 있는 종이 계단을 만들어 줍니다.

타워 꼭대기에 오르면, 개별 장애의 소음은 잦아들고, 신뢰성과 취약성의 패턴이 또렷해집니다. 이런 시야를 통해, 우리는 사건을 그때그때 버티는 수준을 넘어, 애초에 설계 단계부터 체계적으로 탄력성을 주입하는 방향으로 나아갈 수 있습니다.

골판지는 이미 여러분 조직 안에 있습니다. 질문은 이것뿐입니다. 그걸 쌓고 있습니까?