종이 플라이트 레코더: 다음 프로덕션 사고를 위한 로우테크 블랙박스

프로덕션이 불타고 있을 때, 아무도 이렇게 말하지 않습니다. “빨리, 새로운 Confluence 페이지부터 열어!”

실제로 벌어지는 일은 이렇습니다. 사람들은 허겁지겁 콜에 들어오고, 대시보드는 온통 빨갛게 변하고, 채팅은 미친 듯이 올라가고, 누군가는 화면을 공유하고, 여기저기 수첩·터미널·반쯤 쓰다 만 티켓에 메모가 흩어집니다. 사건이 지나고 나면 포스트모템을 쓰라고 하고, 정작 해보면 흐릿한 기억과 일부 로그를 맞춰가며 범죄 현장을 복원하는 기분이 듭니다.

바로 이런 순간에 종이 플라이트 레코더가 빛을 발합니다.

항공기의 블랙박스 개념과 소프트웨어 테스트의 몇 가지 아이디어를 빌려온 종이 플라이트 레코더는, 운영 장애 동안 일어나는 일을 구조적으로 기록할 수 있게 해 주는 로우테크 도구입니다. 복잡한 툴이나 완벽한 기억력에 기대지 않습니다. 모니터링이나 로깅을 대체하려는 것도 아닙니다. 그보다는 실제로 사람들에게 어떤 일이 어떻게 펼쳐졌는지에 대한 이야기를 보존함으로써 이들을 보완합니다.

종이 플라이트 레코더란 무엇인가?

종이 플라이트 레코더는 말 그대로 장애 대응 중에 인시던트 커맨더(incident commander) 또는 지정된 사람이 작성하는 표준화된 인쇄 템플릿 한 장입니다. 프로덕션 환경을 위한 수동 블랙박스라고 생각하면 됩니다.

항공기의 비행 기록 장치처럼, 이 도구는 실시간 내부 메커니즘 전체를 다 추적하려 하기보다는 (a) 입력, (b) 출력, (c) 컨텍스트에 집중합니다.

• 입력 – 우리가 한 일: 실행한 명령, 설정 변경, 기능 플래그 토글, 배포 시작, 롤백 시도 등
• 출력 – 우리가 본 것: 메트릭 변화, 알림 상태 변화, 로그 이상 징후, 사용자 영향, 에러율, 스크린샷 등
• 컨텍스트 – 우리가 어떻게 판단했는지: 가설, 추론, 에스컬레이션, 누가 들어오고 나갔는지, 외부 요인 등

이 템플릿은 사고가 진행되는 동안 작성하는 것이지, 이미 기억이 흐려진 뒤에 나중에 복원하는 용도가 아닙니다.

핵심 아이디어는 단순합니다. 기억을 믿지 말고, 종이를 믿어라.

이렇게 도구가 많은데 왜 굳이 로우테크인가?

“우리에겐 이미 로깅, 트레이싱, 대시보드, 인시던트 채널이 다 있는데, 왜 종이가 필요하지?”라고 생각할 수 있습니다. 이유는 몇 가지가 있습니다.

1. 장애 상황에선 도구들이 정보를 흩어 놓습니다.

   • 알림(alert)은 한 시스템에, 로그는 또 다른 곳에, 배포 이력은 또 다른 곳에, 채팅 내용은 슬랙 같은 협업 도구에 따로 있습니다.
   • 정작 일이 벌어지는 와중에 이 모든 걸 한눈에 보는 사람은 거의 없습니다.

2. 사람이 내리는 중요한 결정은 로그에 남지 않습니다.

   • “지금은 롤백을 하지 않기로 했는데, 그 이유는…”
   • “테스트 차원에서 이 룰을 잠깐 비활성화했습니다.”
   • “X 지표를 보고 데이터베이스는 건강하다고 판단했습니다.” 이런 정보는 일이 왜 그렇게 흘러갔는지 이해하는 데 매우 중요한데, 테슬레메트리(telemetry)에는 거의 남지 않습니다.

3. 고스트레스 상황에서는 기억력이 급격히 나빠집니다.

   • 시간 감각이 뒤틀립니다.
   • 누가 어떤 순서로 무엇을 했는지 서로 기억이 다릅니다.
   • “10:14에 잠깐 스파이크가 있었음” 같은 중요한 디테일은 쉽게 사라집니다.

4. 종이는 튼튼하고 마찰이 없습니다.

   • 크래시도, 타임아웃도, 인증(auth)도 필요 없습니다.
   • 누구나 그냥 한 장 집어 들고, 바로 쓰고, 다른 사람에게 넘길 수 있습니다.
   • 책상 위나 벽에 붙여 두면, 모두가 함께 참조하는 공용 뷰가 됩니다.

종이 플라이트 레코더는 의도적으로 지루할 정도로 단순한 기술입니다. 진짜 가치는 그 안에 담긴 규율과 구조에 있습니다.

무엇을 기록할까: 혼란을 스토리로 바꾸기

목표는 소설을 쓰는 게 아닙니다. 목표는 시간 순서가 분명한 사건의 이야기를 남기는 것입니다. 잘 만든 종이 플라이트 레코더 템플릿은 다음과 같은 기록을 자연스럽게 유도합니다.

1. 기본 인시던트 메타데이터

• 인시던트 이름/ID
• 시작 일시 (첫 알림 / 첫 사용자 제보 시각)
• 최초 제보자 (누가 처음 알아챘는지)
• 인시던트 커맨더 또는 주요 대응자

별 것 아닌 것처럼 보이지만, 나중에 “이 슬랙 스레드는 세 번 있었던 비슷한 장애 중 어느 건에 대한 거였지?”를 복원하려고 할 때 꽤 중요해집니다.

2. 타임라인과 액션

가장 효과적인 형식은 단순한 표입니다.

여기에 kubectl 전체 커맨드까지 다 적을 필요는 없습니다. 단지 무슨 일이 어떤 순서로 일어났는지를 다시 그릴 수 있을 만큼만 적으면 됩니다.

3. 시스템 상태 스냅샷

중요한 시점마다 시스템이 어떻게 보였는지 적어 둡니다.

• 에러율
• CPU/메모리 사용량
• 큐 길이
• 데이터베이스 상태 지표
• 외부 의존성 상태 (결제사, DNS, 서드파티 API 등)

비행기의 계기판을 떠올리면 됩니다. 특정 지점에서의 계기판 판독값: 어떤 변경을 하기 전, 변경을 한 직후, 새로운 증상이 나타났을 때 등.

4. 결정과 가설

이 부분이 플라이트 레코더의 진짜 가치를 만듭니다. 중요한 결정마다 다음을 적습니다.

• 우리는 당시 무엇이 일어나고 있다고 믿었는가?
• 우리는 무엇을 하기로(혹은 하지 않기로) 결정했는가?
• 왜 그렇게 선택했는가? (가정, 제약, 트레이드오프)

예시 기록:

10:15 – 가설: 최근 payment-service 배포로 인해 latency 스파이크 발생. 결정: 인프라를 확장하기 전에 이전 버전으로 롤백. 롤백이 더 빠르고 리스크가 낮다고 판단.

이런 메모는 나중에 무슨 일이 있었는지뿐 아니라, 당시 기준으로 왜 그게 합리적인 선택이었는지까지 설명해 줍니다.

5. 복구 및 해소(Resolution)

마지막으로 다음을 기록합니다.

• 서비스가 정상화된 시각 / 영향이 확산되지 않게 된 시점
• 안정화와 상관 있어 보이는 변경이나 사건
• 여전히 남아 있는 임시 완화 조치나 우회 구성

이를 통해 “도대체 뭐가 진짜 문제를 해결한 거지?”라는 질문에 답을 찾는 데 도움이 됩니다. 장애 한가운데에서는 이 부분이 생각보다 훨씬 모호해집니다.

종이에서 포스트모템까지: 더 나은 원인 분석의 연료

인시던트가 끝나면, 종이 한 장이 매우 질 좋은 포스트모템 및 근본 원인 분석(RCA, Root Cause Analysis)의 입력 자료가 됩니다.

많은 팀이 이런 경험을 해 봤을 겁니다. 포스트모템을 쓰러 모였는데, 회의 시간 절반을 “타임라인이 정확히 어떻게 됐더라?”를 두고 논쟁하며 보냅니다. 종이 플라이트 레코더가 있으면 이미 다음이 준비되어 있습니다.

• 주요 행동들이 정리된 시간 순 내러티브
• 중요 시점의 시스템 상태 스냅샷
• 사람들이 무엇을 어떻게 믿고 행동했는지를 보여 주는 의사결정 기록

이건 5 Whys 같은 구조화된 RCA 기법을 쓰기에도 딱 맞는 재료입니다.

예시: 5 Whys를 돕는 타임라인

예를 들어, 체크아웃 요청이 30분 동안 실패한 장애가 있다고 합시다. 기록된 타임라인을 가지고 5 Whys를 하면 이렇게 진행될 수 있습니다.

1. 왜 체크아웃이 실패했는가?
   payment-service가 500 에러를 반환했기 때문이다.

2. 왜 payment-service가 500을 반환했는가?
   트래픽 스파이크 상황에서 DB 커넥션을 소진했기 때문이다.

3. 왜 DB 커넥션을 소진했는가?
   10:02에 배포된 새 버전이 요청당 DB 사용량을 증가시켰기 때문이다.

4. 왜 그 새 버전이 DB 사용량을 증가시켰는가?
   새 기능이 트랜잭션당 중복 쿼리를 여러 번 수행하게 설계되었기 때문이다.

5. 왜 그런 변경이 사전에 감지되지 않고 프로덕션까지 올라갔는가?
   퍼포먼스 회귀 테스트나 현실에 가까운 부하 테스트가 CI 파이프라인에 없었기 때문이다.

종이 기록은 각 단계를 검증하는 데 도움이 됩니다.

• 10:02에 배포가 있었다는 기록
• 10:04에 DB 커넥션이 한계까지 찼다는 기록
• 10:07에 롤백과 그 영향이 기록되어 있음

이제 우리는 직접적(근접) 원인(배포로 인한 DB 부하 증가)과 시스템적 원인(이를 잡아낼 가드레일 부재)을 구분할 수 있고, RCA의 진짜 목적은 바로 이 시스템적 원인을 찾는 데 있습니다.

로그로는 잘 안 보이는 설계의 약점을 드러내기

로그와 메트릭은 시스템이 무엇을 했는지를 말해 주는 데 탁월합니다. 하지만 시스템이 무엇을 허용했는지, 조직이 무엇을 장려하거나 방치했는지를 설명하는 데는 약합니다.

종이 플라이트 레코더를 꾸준히 쓰다 보면 다음과 같은 패턴이 드러나기 쉽습니다.

• 빠져 있던 안전장치
  “장애 중에 우리가 이 설정을 수동으로 바꾸다가, 이게 사실상 데이터 손실을 막는 유일한 보호막이라는 걸 알게 됐다. 왜 자동화된 가드레일이 없지?”

• 조용히 깨지고 있던 설계 가정
  “이 서비스는 트래픽 2배까지는 버틸 거라 가정했는데, 기록을 보니 1.2배에서 이미 무너졌다. 용량 모델이 틀렸다.”

• 조직적 단절
  “롤백 승인자가 누군지 몰라서 10분을 허비했다.”

• 불분명한 오너십
  “10:10에 콜에 있던 누구도 컴포넌트 X를 제대로 이해하고 있지 않다는 걸 알게 됐다. 왜 이 컴포넌트에 대한 온콜 담당자가 없지?”

이런 통찰이야말로 신뢰성을 진짜로 개선하는 데 필요한 것들입니다. 하지만 이런 내용은 로그 라인 한 줄에 담겨 나오지 않습니다.

나만의 종이 플라이트 레코더 설계하기

완벽할 필요는 없습니다. 작고 표준화되어 있어서 사람들이 실제로 쓰게 되는 것이 중요합니다. A4나 Letter 사이즈 한 장이면 충분합니다.

추천 섹션은 다음과 같습니다.

1. 헤더(Header)

   • 인시던트 ID / 이름
   • 날짜
   • 시작 시각
   • 인시던트 커맨더

2. 초기 영향(Impact) 개요

   • 영향받은 시스템
   • 사용자 관점에서 보이는 증상
   • 심각도 추정 (예: SEV-1/2/3)

3. 타임라인 표 시간, 주체(Actor), 행동/관찰, 비고 컬럼을 둔 표

4. 주요 결정 & 가설 짧은 불릿 형식:

   • 시각
   • 결정 내용
   • 그 결정의 이유

5. 시스템 상태 스냅샷 중요한 시점에 메트릭을 적어 둘 수 있는 몇 줄

6. 해결(Resolution) 요약

   • 안정화 시각
   • 문제를 고친 것으로 보이는 변경 / 조치
   • 남아 있는 위험이나 임시 완화책

이 템플릿을 여러 장 인쇄해, 인시던트를 다루는 사람들이 있는 자리 근처에 쌓아 두세요. 원격 팀이라면 같은 구조를 가진 디지털 버전(예: 스프레드시트, 템플릿 문서)을 함께 만들어 두는 것도 좋습니다.

신뢰성 문화의 한 부분으로 만들기

종이 플라이트 레코더는 만능 해결책이 아닙니다. 다만, 꾸준히 사용하면 더 큰 개선을 가능하게 해 주는 작은 실천입니다.

효과적으로 도입하려면 다음을 시도해 보세요.

• 인시던트마다 기록 담당 역할을 명확히 지정합니다. (보통 인시던트 커맨더나 전담 서기 역할)
• 온콜 온보딩 세션에서 5~10분 정도만 투자해 사용법을 간단히 교육합니다.
• 포스트모템에서 타임라인을 정리할 때, 종이 기록을 1차 출처로 삼습니다.
• 몇 번 사용한 뒤 템플릿을 반복 개선합니다. 아무도 안 쓰는 필드는 제거하고, 반복적으로 빠지는 정보는 새 프롬프트로 추가합니다.
• 기존 도구를 대체하려 하지 말고 보완재로 사용합니다. 대시보드나 채팅 로그를 대신하는 게 아니라, 그 모든 것을 하나의 이야기로 엮어 주는 역할을 맡깁니다.

시간이 지나면 인시던트가 점점 순간적인 혼돈이 아니라 구조화된 조사 과정처럼 느껴지기 시작할 것입니다.

결론: 아직 생생할 때, 그냥 적어 두자

프로덕션 인시던트는 스트레스가 크고, 지저분하며, 무척 빠르게 진행됩니다. 그중에서도 정말 학습에 중요한 디테일—사람들이 무엇을 보고 무엇이라 생각했으며 어떤 결정을 내렸는가—이 가장 먼저 잊히기 마련입니다.

종이 플라이트 레코더는 그런 이야기를 실시간으로, 단순하고 튼튼한 방식으로 붙잡아 두는 로우테크 도구입니다. 흐릿한 장애 경험을 다시 꺼내 쓸 수 있는 내러티브로 바꾸어, 더 나은 포스트모템, 더 깊은 근본 원인 분석, 그리고 시스템과 프로세스의 구체적인 개선으로 이어지게 합니다.

당신의 머신은 이미 로그와 메트릭이라는 블랙박스를 가지고 있습니다. 이제 사람들을 위한 블랙박스도 하나 만들어 주세요. 필요한 건 복잡한 툴이 아니라, 종이 한 장과 펜 한 자루뿐입니다.