사고 중에 가장 좋은 행동은 고치는 것이 아니라 멈추는 것입니다

🎧 ▶ 5분 브리핑으로 듣기

NotebookLM 오디오 개요 (AI 생성)

📕 전자책 전문 읽기 복구의 엔지니어 · 30쪽

이 글은 요약해 다시 쓴 것이고, PDF가 전문입니다.

서비스를 혼자 돌리거나, 부서졌을 때 책임져야 하는 소규모 팀의 일원입니다. 이 글은 대시보드가 깜빡이기 시작하는 순간을 위한 행동 원칙 하나를 줍니다. 사고 중에 가장 좋은 행동은 고치는 것이 아니라, 멈추는 것입니다.

이건 직관에 반합니다. 목요일 밤 11시에 서비스가 반쪽이 되면, 첫 번째로 움직이는 손은 재시작 버튼이나 스케일업 슬라이더를 잡게 됩니다. 고치는 것은 일처럼 보이고 멈추는 것은 포기처럼 보입니다. 그런데 사고 직후 몇 분간은 원인을 알지 못합니다. 모른 채로 넣은 변화 하나하나가, 읽으려는 증거를 오염시킵니다.

그러니 이 글은 한 가지만 논증합니다. 먼저 고치는 것이 왜 위험한지, 멈추기가 실제로 무엇을 뜻하는지, 부분 복구가 왜 충분한지, 처음 5분은 무엇을 위해 쓰는 것인지, 무엇을 했는지 어떻게 적어야 하는지, 그리고 사고가 끝났다는 것을 어떻게 아는지. 목표는 사고를 막는 것이 아닙니다. 사고는 옵니다. 목표는 첫 30분을 학습 가능한 시간으로 만드는 것입니다.

사고 중에 가장 좋은 행동은 고치는 것이 아니라 멈추는 것입니다 개념을 형상화한 이미지 글의 핵심 개념을 형상화했습니다.

먼저 고치는 것이 함정인 이유

진단과 치료는 반대 방향의 작업입니다. 진단은 시스템을 읽는 일이고 치료는 시스템을 바꾸는 일입니다. 바꾸는 순간, 읽으려던 시스템은 더 이상 같은 시스템이 아닙니다. 그래서 증상을 보는 대로 손을 대면 치료와 진단이 섞이고 그다음부터는 어떤 관찰이 치료 전의 상태고 어떤 것이 치료 후의 상태인지 구별할 수 없게 됩니다.

가장 전형적인 오염은 “재시작하고 나니까 에러가 줄었는데”입니다. 재시작이 효과가 있었는지, 아니면 그냥 시간이 지나면서 나아졌는지는 그때부터 영구히 답이 없는 질문이 됩니다. 이 구별은 나중에 어떤 변화를 되돌릴지를 고르는 기준인데, 사고 열기 속에서 그 기준을 잃는 것은 비싼 손실입니다.

1인 개발자에게 이 실수는 더 비쌉니다. 팀이 있으면 “잠깐, 그게 진짜 원인 맞아요?”라고 물어줄 사람이 있습니다. 혼자라면 그 질문은 나에게만 의존합니다. 그리고 방금 알림에 깨진 상태의 나는, 긴장 때문에 가장 눈에 보이는 버튼부터 누르는, 판단력이 가장 낮은 순간의 나입니다.

목요일 밤 11시를 떠올려 봅시다. 결제 API 타임아웃이 늘었고 CPU 사용률이 올라갔으며 주문이 안 된다는 사용자 메일이 왔고 에러율은 34%입니다. 네 가지입니다. 그런데 실제로는 한 문제입니다. 직관적인 대응은 제일 눈이 가는 것부터 손대는 것입니다. CPU가 올라왔으니 인스턴스를 키우고 결제가 안 되니 라우트를 재시작하게 됩니다. 30분 뒤 서비스는 여전히 반쪽입니다. 시스템에는 이제 두 개의 “나”가 남긴 변화가 들어와 있습니다. 원인을 찾기는 처음보다 더 어려워졌습니다.

여러 개의 변화가 주는 피해는, 그 변화들이 하나하나 다 틀리기 때문이 아닙니다. 각자 합리적인 변화를 합치면 귀속이 불가능해집니다. 원인이 밝혀졌을 때 “그때 한 것 중 무엇이 효과가 있었지?”에 답하지 못하면, 그 30분은 학습 대신 소모였습니다. 다음 사고는 지난 사고와 똑같이 준비되지 않은 상태로 옵니다.

핵심 개념 요약 인포그래픽 1 NotebookLM이 소스를 종합해 생성한 인포그래픽입니다.

멈추기는 원인을 몰라도 된다

고치기와 멈추기를 가르는 선은 이렇습니다. 고치기는 원인이 필요합니다. 멈추기는 원인이 필요 없습니다. 외부 결제사가 왜 느린지는 모릅니다. 그러나 “결제 요청을 지금 당장 10%만 보내고 나머지는 대기시킨다”는 일은 원인을 모르고도 할 수 있습니다. 그 하나면 재시도 폭주는 사라지고 CPU는 내려오고 내 서비스는 죽지 않습니다. 결제는 여전히 느립니다. 하지만 느린 서비스와 죽은 서비스는 다른 문제입니다. 느린 서비스는 사용자가 기다릴 수 있고 죽은 서비스는 아무것도 할 수 없습니다.

“멈추기”는 하나의 기술이 아닙니다. 트래픽을 줄이고 부하를 떨어뜨리고 최근 변경을 되돌리고 캐시로 답하고 쓰기를 대기열에 넣고 읽기 전용으로 강등합니다. 전부 멈추기입니다. 공통점은 원인을 모른 채로 손실을 줄인다는 것입니다. “왜 이러느냐”의 답이 필요한 행위가 하나도 없습니다.

재시작을 멈추기로 오해하는 경우가 많습니다. 재시작은 원인을 모를 때의 치료입니다. 시스템은 바뀌지만 왜 바뀌었는지는 더 알 수 없게 됩니다. 재시작 이후의 지표는 재시작한 상태의 지표입니다. 원래 상태의 지표는 아닙니다. 그래서 재시작은 분류가 끝난 뒤, 고른 멈추기가 효과가 없었을 때의 대안으로 써야 합니다. 가장 눈에 보이는 버튼이 가장 싼 버튼은 아닙니다.

멈추기의 목표는 손실을 줄이는 것입니다. 완벽하지 않아도 됩니다. “부분적”이라는 이유로 비하할 이유가 없습니다. 사고 도중에 100% 회복은 대부분 불가능합니다. 70%를 5분 안에 세우는 것과 100%를 2시간 만에 세우는 것, 사용자가 기다려 주는 쪽은 전자입니다. 피해의 단위 사용자는-분입니다. 사고 중에 “원인을 찾자”에 쓰는 매 분마다 사용자의 피해분이 늘어나고 멈추기는 그 증가를 끊는 행위입니다.

다만 예외가 하나 있습니다. 멈추기는 사고의 축으로 고르지, 원인으로 고르지 않습니다. 반쯤 커밋된 결제 자체가 피해인 정확성 사고라면, 속도를 늦추는 트로틀링은 오히려 틀린 멈추기입니다. 그 축의 멈추기는 쓰기를 격리하는 것입니다. 느리게 하는 게 아니라, 멈추게 하는 것. 축이 행동을 정하고 원인은 나중에 어디를 볼지를 정할 뿐입니다.

축	첫 멈추기	고치기의 의미	회복 지표
가용성	부하 떨어뜨리기, 롤백	죽은 구성요소 제거	에러율, 요청 성공률
성능	트로틀링, 대기열	요청당 부하 감소	P95 지연
정확성	쓰기 격리	잘못된 데이터 원천 차단	정답 확인 비율
데이터	동기화 동결	불일치 지점 찾기	불일치 건수

처음 5분은 고치는 시간이 아니라 고칠 방향을 고르는 시간

그럼 처음 5분은 뭘 하는가. 시스템에는 손을 대지 않는 것. 이 5분은 고칠 방향을 고르는 시간입니다. 답할 질문은 셋입니다. 이 사고는 어느 축인가, 가용성이냐, 성능이냐, 정확성이냐, 데이터가냐. 최근 변경이 있었는가. 의존 서비스가 느린 것인가.

세 가지 신호 중 가장 싼 것은 “최근 변경”입니다. 지난 1시간 안의 배포, 설정값 변경, 트래픽 급증, 의존 서비스 버전 상승. 최근 변경이 하나라도 있으면, 기본 첫 행동은 그것을 되돌리는 것입니다. 롤백은 멈추기이면서 동시에 고치기인 특수한 행동입니다. 최근 변경을 없애고 대신에 시스템을 깨끗하게 관찰할 시간을 사는 것입니다.

두 번째 신호는 의존 서비스입니다. 내 서비스가 느리면, 내 코드가 느리다기보다 느린 것을 기다리고 있을 확률이 높습니다. 외부 API 응답 시간, 데이터베이스 쿼리 시간, 메시지 큐 적체량. 이 셋 중 하나가 늘었다면 문제는 내 코드보다 관계에 있습니다. 이 세 수치를 내 로그보다 먼저 보는 것이 가장 빠른 분류입니다. 그리고 이 경우의 멈추기는 내 코드 대신 그 관계에 기대는 양을 줄이는 트로틀링입니다.

롤백에는 다른 고치기에는 없는 두 가지 장점이 있습니다. 첫째, 결과가 분 단위로 보입니다. 원인이 그 변경이면 지표가 거의 즉시 내려옵니다. 둘째, 실패해도 되돌릴 수 있습니다. 롤백이 오히려 나쁘게 만들면, 다시 원래로 돌려보내면 됩니다. 핫픽스나 튜닝, 스키마 변경은 이런 성질이 없습니다. 효과가 있는지를 알아차리려면 기다려야 하고 틀렸을 때의 비용은 높습니다.

다만 순서가 중요합니다. 먼저 분류하고 그다음에 롤백합니다. 잘못된 것을 되돌리는 것도 여전히 변화이며 진단을 똑같이 오염시킵니다. 알림이 네 개 터져 있는 상황에서 첫 행동은 버튼이 아니라 축입니다. 축이 멈추기를 정하고 멈추기가 어디를 볼지를 정합니다. 이 순서 하나가 첫 30분을 깨끗하게 남기는 일입니다.

1인 개발자가 사고 중에 가까이 두는 도구가 하나라면, 디버거보다 변경 이력입니다. 디버거는 “어떻게 고장 났나”에 답하고 이력은 “무엇이 바뀌었나”에 답합니다. 처음 5분에 실제로 쓰는 질문은 후자입니다.

말하기 전에, 한 줄부터 쓴다

사고가 터지면 사람은 두 가지를 잃습니다. 판단력과 시간. 이 둘을 다시 사는 가장 싼 방법은 쓰기입니다. 말은 빠릅니다. 메신저에 “지금 에러나고 있습니다”를 치는 데 5초가 걸립니다. 그런데 그 5초의 말이 이후의 모든 판단을 오염시킵니다. “에러가 나고 있다”는 사실이지만 동시에 “원인을 안다”는 인상을 줍니다. 상대방은 “원인 뭐야?”라고 묻고 당신은 원인을 모른 채 답해야 하는 위치에 놓이게 됩니다.

쓰기의 규율은 단순합니다. 말하기 전에, 시간선 파일에 한 줄을 적습니다. 한 줄은 세 요소로 고정됩니다. 시간, 관찰, 행동.

50 - 결제 API 타임아웃 증가 관찰, 에러율 34%
52 - 결제 라우트 레이트 리미트 50% 적용
55 - 에러율 21%로 하락

이 세 줄이 있을 때 말하는 것과 없을 때 말하는 것은 다릅니다. 있으면 “22:50에 시작했고, 22:52에 레이트 리미트를 걸었고, 효과가 있었다”고 말할 수 있습니다. 없으면 “요즘 좀 불안정했어요” 수준으로 말할 수밖에 없습니다. 전자는 결정의 시작이고 후자는 소문의 시작입니다.

시간선은 한 파일에만 적습니다. 메신저 스레드, 메모 앱, 대시보드 주석에 흩어지면 합치기가 어렵고 합치는 동안 정보가 빠집니다. 1인이라면 로컬 텍스트 파일이면 됩니다. incident-2026-08-23.md 같은 이름을 붙여 두고 사고가 끝날 때까지 닫지 않습니다. 그 파일이 포스트모템의 입력이 됩니다. 기록이 없으면, 복구된 뒤에도 “그때 한 것 중 뭐가 효과가 있었지”를 알 수 없습니다. 포스트모템을 하는 사람은 그 밤의 내가 아닙니다. 다음 날 밤을 배우려는 나입니다. 시간선은 그 둘 사이를 잇는 다리입니다.

소규모 팀이라면 시간선이 역할을 나눕니다. 한 명이 시스템에 손을 대는 동안, 다른 한 명은 한 줄씩 적습니다. 쓰는 사람의 질문, “잠깐, 지금 뭘 하고, 왜 그래?”가 사고 중에 가장 필요한 외적 통제입니다. 손을 대는 사람은 그 질문을 받아쳐야 하고 받는 대로 시간선에 적어야 합니다. 2명이면 충분합니다. 1명이면 그 질문을 일정 간격으로 자신에게 던지는 것으로 대체합니다. 던질 수 없다면, 아직 준비가 되지 않은 것입니다.

회복은 느낌으로 선언하지 않는다

23:05. 외부 결제사 API가 복구됐습니다. 에러율은 21%에서 4%로 내려왔습니다. “되셨네”라고 생각하는 순간, 이 밤에서 가장 차가운 머리가 필요합니다. 회복했다고 느끼는 것과 회복한 것은 다른 일입니다. 4%는 여전히 사고 전의 0.5%보다 훨씬 높습니다. “4%면 괜찮지”라고 넘기면, 남은 4%는 조용히 계속 발생합니다. 사용자는 그 4% 안에 있습니다.

“4%가 괜찮다면 1%는? 1%가 괜찮다면 0%를 기대하는 것은 불합리한가?” 이 질문을 사고 도중에 답하면, 회복의 기준이 숫자로 세워집니다. 기준은 세 요소로 고정됩니다. 어떤 지표, 어떤 범위, 얼마나 오래.

지표는 축이 정합니다. 가용성 사고면 에러율과 요청 성공률. 성능 사고면 P95 지연. 정확성 사고면 정답으로 확인되는 비율. 데이터 사고면 불일치 건수. 처음 5분에 분류한 축이 여기에서 쓰입니다. 분류는 형식적 절차라기보다 회복 기준의 입력입니다.

범위는 “작동했던 과거”를 기준으로 삼습니다. “완벽한 과거”가 아닙니다. 하루 전부터 이미 느려지고 있었다면, 그 느려진 상태가 새 기준이 됩니다. 사고 전의 수치가 기억에만 남아 있으면, 대시보드의 24시간 뷰를 봅니다. 완벽함에 집착하면 회복이 영영 선언되지 못하고 사고가 열려 있는 채로 남습니다. 그 자체가 또 다른 피해입니다.

오래 유지했느냐입니다. 한 번의 확인으로 회복을 선언하지 않습니다. 관례는 지표를 기준 안에 30분가량 유지한 뒤 선언하는 것인데, 30분은 서비스와 팀에 따라 조정할 값이지 법이 아닙니다. 중요한 것은 “잠시”보다 “계속”입니다. 5분간 좋았던 지표는 5분 뒤에 다시 나빠질 수 있고 특히 트래픽을 줄였다가 다시 올리는 순간 지표가 흔들립니다. 그 흔들림을 보는 시간이 기준의 지속시간입니다. 회복을 선언하는 것은, 더 이상 지켜볼 필요가 없다는 순간입니다. 그러니 기준은 일정 시간 계속 바라볼 수 있는 것이어야 합니다. 그 숫자가 있으면 사고는 기록으로 끝나고 없으면 느낌으로 끝납니다. 전자는 학습 가능하고 후자는 아닙니다.

분류와 통신, 수치 회복 기준을 포함한 사고 첫 30분 규율을 한 단계 더 깊이 보고 싶다면, 이 글 옆에 있는 전자책이 참고서입니다.