인시던트
Incident
개념
서비스를 쓰던 사람이 하려던 일을 못 하게 만든 사고로, 누구를 언제 부를지 정하는 기준이 됩니다.
등장 배경
서버 로그에는 하루에도 오류가 수천 줄씩 쌓입니다. 그 가운데 사람을 새벽에 깨워야 하는 것은 몇 건 되지 않습니다. 이 둘을 가르는 이름이 없던 팀에서는 모든 이상이 같은 무게로 다뤄졌고, 그 결과는 두 방향으로 어긋났습니다. 모든 알림에 전원이 달려들면 사람이 금세 지쳐 정작 큰 사고에 반응이 느려지고, 반대로 모든 알림을 가볍게 넘기면 큰 사고를 한참 뒤에 알아챕니다.
실제로는 이런 대화로 나타났습니다. 누군가 단체 대화방에 "지금 이거 장애 맞아요?" 라고 물으면 답이 사람마다 달랐습니다. 한 명은 사용자 한 명이라도 불편을 겪었으면 장애라고 했고, 다른 한 명은 결제 화면이 멈춰야 장애라고 했습니다. 기준이 다르니 대응도 갈렸습니다. 어떤 날은 글자 색이 깨진 일로 열 명이 새벽까지 붙어 있었고, 어떤 날은 절반의 사용자가 문서를 저장하지 못하는 동안 아무도 호출되지 않았습니다. 분기 말에 "이번 분기 장애가 몇 건이었나" 를 세려고 해도 세는 사람마다 숫자가 달랐습니다.
인시던트는 이 판정을 그때그때의 대화에서 꺼내 미리 정해 둔 기준으로 옮기려고 둔 이름입니다. 서비스에 실제로 영향을 준 사고만 이 이름으로 부르고, 이름이 붙는 순간 정해진 절차가 시작됩니다. 오류가 곧 사고는 아니라는 구분이 이 이름 하나에 담겨 있습니다.
작동 방식
인시던트는 선언·등급·대응·종료의 네 단계로 돌아갑니다.
- 선언 — 누군가 이 상황을 인시던트라고 부르는 순간 시작됩니다. 선언하는 권한은 일부러 넓게 열어 둡니다. 아니었을 때 치르는 비용은 회의 한 번이지만, 선언하지 않고 넘긴 것이 진짜 사고였을 때 치르는 비용은 몇 시간의 서비스 중단이기 때문입니다.
- 등급 — 심각도를 매겨 무게를 정합니다. 전체 사용자가 저장을 못 하면 1등급, 특정 브라우저에서만 글자가 깨지면 3등급 하는 식입니다. 기준은 영향 범위와 업무 차질의 정도이지 고치기 어려운 정도가 아닙니다. 한 줄만 고치면 되는 문제라도 전원이 로그인을 못 하고 있다면 1등급입니다.
- 대응 — 등급이 누구를 부를지 결정합니다. 3등급은 온콜 당번 한 사람이 업무 시간에 처리하고, 1등급은 당번이 즉시 응답한 뒤 정해진 시간 안에 풀리지 않으면 에스컬레이션 절차를 타고 위로 올라갑니다. 대응 중에는 한 사람이 지휘를 맡고 나머지가 조사를 나눠 맡습니다.
- 종료 — 사용자가 다시 정상적으로 쓸 수 있게 된 시점에 닫습니다. 시작·탐지·복구 시각을 각각 남기는데, 이 세 값이 있어야 나중에 MTTR 같은 숫자를 계산할 수 있습니다.
쓰이는 곳
이 이름이 실제로 오가는 자리는 셋입니다. 첫째는 알림이 울린 직후의 판정입니다. 당번이 화면을 보고 "인시던트로 올리겠습니다" 라고 말하면 그때부터 대화방이 따로 열리고 다른 일이 뒤로 밀립니다.
둘째는 불이 꺼진 뒤의 기록입니다. 한 건이 닫히면 포스트모템을 씁니다. 언제 시작돼 언제 알아챘고 무엇을 해서 돌아왔는지를 시간 순으로 적고, 마지막에 무엇을 고칠지와 누가 언제까지 할지를 적는 문서입니다. 그 안에서 근본 원인 분석으로 증상 뒤의 원인까지 내려갑니다. 디스크가 가득 차 멈췄다는 답에서 멈추지 않고 왜 차기 전에 아무도 몰랐는지까지 묻는 방식입니다. 이 과정이 굴러가려면 책임 추궁 없는 회고가 함께 있어야 합니다. 실수한 사람이 불려 나가는 자리를 한 번 겪으면 다음 사람은 자기가 무엇을 눌렀는지 정확히 적지 않고, 부정확한 기록에서는 원인이 나오지 않습니다.
셋째는 숫자를 세는 자리입니다. 분기마다 등급별 건수를 세고, 고객과 맺은 SLA에 적힌 가동률을 지켰는지 확인합니다. 이때 앞에서 정한 판정 기준이 없으면 숫자 자체가 성립하지 않습니다. 세는 사람마다 다른 것을 세기 때문입니다. 같은 분기를 두고 한쪽은 여섯 건, 다른 쪽은 스물세 건이라고 보고하면 어느 숫자로도 결정을 내리지 못합니다.
실무 용례
"이거 인시던트로 올릴까요, 아니면 그냥 티켓으로 둘까요?"
지금 대응 절차를 시작할 일인지, 평소 작업 목록에 넣어 둘 일인지를 묻는 말입니다.
"2등급으로 잡고 대화방 열었습니다. 지휘는 제가 보겠습니다."
무게를 정했고 누가 상황을 총괄하는지 밝힌 선언입니다.
"복구는 됐는데 아직 안 닫았어요. 원인이 안 나왔습니다."
사용자는 다시 쓸 수 있지만 같은 일이 또 날 수 있어 기록을 열어 둔 상태라는 뜻입니다.
페이지덱에서 문서 자동 저장이 12분 동안 실패한 날이 그랬습니다. 태오가 알림을 받고 오분 만에 인시던트를 선언했고, 저장이 걸린 사용자 비율을 확인한 뒤 1등급으로 올렸습니다. 지현은 그동안 고객에게 나갈 공지 문구를 썼습니다. 복구된 뒤에는 태오가 기록을 맡고 지현이 문의로 들어온 고객 목록을 정리했습니다.
여기서 등급이 한 일은 우선순위를 정한 것뿐입니다. 1등급이 붙는 순간 그날 잡혀 있던 배포가 멈추고 회의 두 개가 미뤄졌습니다. 이름과 등급이 없으면 그 판단을 매번 처음부터 합의해야 합니다.
흔한 오해
인시던트가 열렸다는 것을 누군가 실수했다는 뜻으로 읽는 경우가 많습니다. 사고가 났으니 잘못한 사람이 있으리라 짐작하기 쉽기 때문입니다. 하지만 이 이름이 가리키는 것은 사용자가 겪은 영향이지 원인이 아닙니다. 외부 결제사가 멈춰도, 예상보다 사용자가 몰려도 인시던트입니다. 이 구분이 흐려지면 선언 자체가 눈치 보이는 일이 되고, 선언이 늦어진 만큼 복구도 늦어집니다.
건수를 0으로 만드는 것을 목표로 삼는 것도 같은 자리에서 생기는 오해입니다. 숫자가 줄면 서비스가 튼튼해진 것처럼 보이지만, 줄이는 가장 쉬운 방법은 선언을 안 하는 것입니다. 목표가 내려온 팀은 대개 애매한 건을 티켓으로 돌리는 쪽으로 움직이고, 그러면 기록이 남지 않아 개선도 없습니다. 볼 것은 건수가 아니라 등급별 분포와 복구까지 걸린 시간입니다. 1등급이 분기에 한 건에서 없음으로 줄었는데 3등급이 스무 건에서 서른 건으로 늘었다면, 그건 나빠진 것이 아니라 작은 이상까지 제때 잡아내고 있다는 신호로 읽습니다.
자주 헷갈리는 용어
| 용어 | 무엇을 가리키는가 | 인시던트와의 차이 |
|---|---|---|
| 버그 | 의도와 다르게 동작하는 결함 자체 | 원인 쪽 이름입니다. 버그가 있어도 아무도 그 화면을 쓰지 않으면 인시던트가 아니고, 버그 없이 트래픽만 몰려도 인시던트입니다 |
같이 보면 좋은 페이지
연관 용어
마지막 업데이트 2026-09-16