연필로 그린 실패 온실: 사라지기 전에 ‘아슬아슬 실패 징후’를 키우는 법

대부분의 조직에서 심각한 장애는 늘 ‘갑작스러운 사고’처럼 찾아옵니다. 하지만 큰 사고가 터지기 전 몇 주, 몇 달을 자세히 들여다보면 거의 언제나 이런 흔적이 남아 있습니다. 바로 니어미스(near miss)—거의 사고로 이어질 뻔했지만, 간신히 넘어간 작은 아슬아슬 상황들입니다.

이 니어미스는 마치 미래 재앙을 연필로 스케치해 둔 것과 같습니다. 흐릿하고, 쉽게 지워지고, 자주 무시됩니다. 하지만 이를 보호하고 키워낼 수 있는 일종의 ‘온실’을 잘 만들어 두면, 가장 강력한 조기 경보 시스템으로 바뀝니다.

이 글에서는 그 온실을 설계하는 방법, 즉 연약한 니어미스 단서를 운영 현장의 소음 속에 묻히기 전에 포착·증폭·분석하는 체계를 어떻게 만들 수 있는지 설명합니다.

우리가 생각하는 것보다 니어미스가 훨씬 중요한 이유

**니어미스(near miss)**란, 실제로는 피해·손실·다운타임으로 이어지지는 않았지만, 그럴 가능성이 충분히 있었던 사건을 말합니다. 운 좋게, 혹은 중복 설계나 누군가의 마지막 순간의 해결 덕분에 피해가 나지 않았을 뿐입니다.

조직은 보통 니어미스에 과소 반응합니다.

“실제로 망가진 건 없잖아요.”
“다운된 시간도 1분밖에 안 됐는데요.”
“운영자가 제때 잡았으니까 괜찮죠.”

하지만 바로 그 점 때문에 니어미스는 더 가치 있습니다.

큰 참사를 치르지 않고도 시스템 취약성을 드러내 준다.
대형 장애보다 훨씬 자주 발생하므로, 더 많은 데이터 포인트를 제공한다.
테스트로는 잘 드러나지 않는 엣지 케이스와 인간–시스템 상호작용을 노출시킨다.

실패만으로 학습하는 조직은 결국 이렇게 말하는 셈입니다.
“진짜 아프게 당할 때까지는 이 문제를 진지하게 보지 않겠다.”
니어미스 분석은 여기에 맞서 사후 학습에서 사전 학습으로 전환하는 일입니다.

보이지 않는 절반: 사건만 보지 말고 ‘사람’을 같이 보라

대부분의 인시던트 리포트는 기술적인 사건 연쇄에서 끝납니다.

서비스 X가 서비스 Y를 호출하려 했고, 인증이 실패하면서 재시도 폭증이 일어나 부분 장애로 이어졌다.

유용하지만, 이것만으로는 불완전합니다. 모든 니어미스에는 인간의 층위가 함께 존재하고, 이를 무시하면 재발 위험을 크게 과소평가하게 됩니다.

니어미스가 발생했을 때 그 시점의 작업자 상태를 함께 기록해야 하는 핵심 요소는 다음과 같습니다.

주의력 & 인지 부하
- 담당자가 멀티태스킹 중이었나요? 여러 시스템에 동시에 온콜이었나요?
- Slack, 전화, 찾아오는 요청 등 방해가 잦았나요?
경험 & 친숙도
- 신규 입사자였나요? 해당 시스템이나 도구는 처음이었나요?
- 이 작업을 처음 단독으로 수행한 건가요?
업무량 & 시간 압박
- 교대 근무 끝무렵이었나요? 마감 시간에 쫓기고 있었나요?
- 초과 근무 중이었나요? 타임존을 가로질러 일하고 있었나요?
교육 & 멘탈 모델
- 이 시나리오나 도구에 대해 사전에 교육이나 문서로 접한 적이 있나요?
- 머릿속에 갖고 있던 시스템 모델과 실제 시스템 동작이 얼마나 일치했나요?

겉으로 보기엔 똑같은 기술적 사건이라도, 맥락에 따라 위험 신호의 크기는 완전히 달라집니다.

잘 쉬었고 숙련된 엔지니어가 거의 장애를 낼 뻔했다면, 시스템 자체가 상당히 취약할 수 있습니다.
신규이면서 과부하 상태인 엔지니어가 혼란스러운 인수인계 중에 실수했다면, 교육과 프로세스 설계의 문제일 가능성이 큽니다.

이런 인간 요인까지 포함해서 니어미스를 분석하면 위험 평가의 질이 크게 향상됩니다.
어떤 유형의 실수가, 어디에서, 누구에게서 반복될지 훨씬 선명하게 보입니다.

실패 온실: 단순하지만 구조화된 템플릿이 필요한 이유

니어미스는 대부분 작고, 빨리 지나가고, 금방 잊혀집니다.
하루 일이 끝날 즈음이면 이미 세부 기억은 흐려져 있습니다. 구조 없이 구두 보고와 기억에만 의존하면, 결국 아무것도 남지 않습니다.

그래서 인시던트 관리 템플릿이 필요합니다. 이 템플릿은 다음과 같아야 합니다.

누구나 쉽게 찾을 수 있어야 합니다. (채팅방 상단 고정, 대시보드, 온콜 런북에 링크 등)
작성에 5–10분 이상 걸리지 않아야 합니다.
기술적 맥락과 인간·업무 맥락을 모두 담아야 합니다.
팀이 달라도 일관된 형식으로 작성되어, 사건들을 서로 비교할 수 있어야 합니다.

실무에서 쓸 수 있는 니어미스 기록 템플릿 예시는 다음과 같습니다.

기본 메타데이터
- 날짜, 시간, 시스템/서비스, 환경(프로덕션/스테이징/개발), 보고자
간단 분류(체크박스)
- 유형: 성능 / 데이터 / 보안 / 안전 / 사용성 / 프로세스
- 위치: 인프라 / 애플리케이션 / 통합·연동 / 인간–컴퓨터 상호작용(HCI)
- 만약 잡지 못했다면 발생할 잠재적 영향: 다운타임, 데이터 손실, 안전, 비용 등
서술형 스냅샷(3–5문장)
- 무엇을 하려고 했나요?
- 무엇이, 어떻게 잘못되었거나 잘못될 뻔했나요?
- 어떻게 발견했고, 어떻게 멈추거나 되돌렸나요?
인간 & 맥락 요소
- 이 시스템/작업에 대한 경험 수준 (신규 / 중간 / 전문가)
- 당시 업무량 (정상 / 높음 / 한계치)
- 방해나 컨텍스트 스위칭이 있었나요? (예/아니오 + 간단 메모)
- 문서/교육에서 이 시나리오를 본 적이 있었나요? (예/아니오)
즉각 후속 조치
- 바로 적용한 조치가 있었나요? (설정 변경, 롤백, 절차 수정 등)
- 더 깊은 리뷰가 필요해 보이나요? (예/아니오/가능성 있음)

이 템플릿이 바로 **‘연필로 그린 온실’**입니다. 가볍지만 구조화되어 있어, 운영 소음이 모든 것을 지워버리기 전에 연약한 단서들을 안전하게 보존해 줍니다.

가장 중요한 앞단: 보고, 트리아지, 분류

전체 포스트모템(postmortem)까지 올라오는 사건은 이미 “시끄러운” 장애입니다.
니어미스 데이터의 운명은 훨씬 더 앞단에서—다음 세 단계에서—결정됩니다.

신속한 보고
- 니어미스 보고를 **‘자백’이 아니라 ‘당연한 일’**로 만드십시오.
- 이런 표현을 조직 문화로 만듭니다: “장애로 이어지진 않았는데, 뭔가 이상했습니다.”
- 언어에서 비난을 제거하고, 사람보다 상황과 조건에 초점을 맞춥니다.
트리아지(Triage)
- 온콜 리드, 안전 담당자, SRE 리드 등 누군가가 당일에 1차 분류를 합니다.
  - 단순 오타 한 번인지, 이미 몇 번 반복된 패턴인지?
  - 같은 조건이 다른 곳에서도 쉽게 재현될 수 있는지?
- 각 보고를 “기록만”, “간단 조치”, “심층 분석 필요” 중 하나로 태깅합니다.
분류(Classification)
- 일관된 카테고리와 심각도(severity) 구간을 사용합니다.
- 실제 발생한 영향만 보지 말고, 잠재적 영향도 반드시 태깅합니다.
- 이 분류가 나중에 패턴을 찾아내는 기반이 됩니다.

보고가 번거롭고, 트리아지가 즉흥적이며, 분류 기준이 제각각이면, 니어미스 데이터는 금세 소음 속으로 녹아 사라집니다.
기록은 있는 것 같지만, 실제로는 아무 신호도 읽어낼 수 없는 상태가 됩니다.

소음 속 약한 실패 신호 찾기: 락인 앰프에서 배우기

운영 데이터는 본질적으로 시끄럽습니다. 지연 시간의 작은 출렁임, 미세한 에러 스파이크, 독특한 사용자 행동, 사람들의 임시방편 대응까지 온갖 변화가 섞여 있습니다.
이 중에서 의미 있는 약한 신호를 찾으려면, 전자 공학의 **락인 앰프(lock‑in amplifier)**처럼 생각해 보는 게 도움이 됩니다.

락인 앰프는 매우 잡음이 큰 배경 속에서도, 주파수가 미리 알려진 매우 약한 신호만 골라서 추출하는 장치입니다.

이를 니어미스 분석에 적용하면 이렇게 됩니다.

먼저 찾고 싶은 패턴을 정의합니다.
무엇을 탐지하려는지 미리 정합니다. 예를 들어:
- 인증 관련 니어미스?
- 설정(Configuration) 드리프트 사건?
- 교대 시간대 인수인계 오류?
템플릿 태그를 일관되게 사용해, 그 패턴에 ‘튜닝’할 수 있도록 합니다.
체크박스와 카테고리가 곧 ‘주파수’ 역할을 합니다.
니어미스와 운영 데이터를 연계해 봅니다.
예를 들어 이런 상관관계를 찾습니다.
- 항상 CPU 사용률이 높거나 배포(Deploy) 윈도우에만 발생하는 니어미스
- 특정 상호작용(예: UI 단계, 시스템 간 핸드오프 경계) 부근에 몰려 있는 사건들

이런 ‘락인’ 관점은 단순히 대시보드 숫자에 휩쓸리는 상태에서 벗어나,
좁지만 위험한 약한 신호들을 의도적으로 탐색하는 모드로 우리를 전환시켜 줍니다.

스펙트럼으로 생각하기: 인시던트 ‘주파수’를 나눠 보는 시각화

모든 인시던트가 똑같은 종류의 소음은 아닙니다. 대략 이런 식으로 나뉩니다.

발생 빈도는 높지만 영향은 작은 이슈들 (자잘한 불편, 짧은 장애)
중간 빈도, 중간 영향 이슈들 (재작업, 소규모 다운타임 등)
발생 빈도는 낮지만 영향이 치명적인 사건들 (대규모 블랙아웃, 안전 위협 등)

니어미스 분석에는, 신호를 주파수별로 쪼개서 보여주는 스펙트럼 분석기(spectrum analyzer) 같은 관점이 필요합니다.

스펙트럼 분석기는 복잡한 신호를 여러 주파수 대역으로 분해해, 어떤 대역이 우세한지 보여줍니다.

이를 운영에 적용하면 예를 들어 다음과 같습니다.

인시던트를 단순 합계로 보여주는 대신, 유형·발생 위치·심각도 구간별로 분리해 보여주는 대시보드
다음과 같이 서로 다른 ‘주파수’를 나눠 보여주는 시각화:
- 인간–컴퓨터 상호작용(HCI) 관련 이슈 vs. 순수 인프라 이슈
- 신규 인력 관련 사건 vs. 숙련자 관련 사건
- 평상시 부하 vs. 피크 부하 상황에서 발생한 사건

이렇게 자신의 ‘인시던트 스펙트럼’을 눈으로 볼 수 있게 되면:

신규자 관련 이슈가 몰려 있는 구간에는 교육 프로그램을,
피로 관련 오류가 많은 구간에는 자동화·휴식 정책을,
UI 혼란이 잦은 구간에는 제품·UX 개선을 투입하는 등 정밀 타겟팅된 개입을 설계할 수 있습니다.
시끄럽지만 위험은 낮은 고빈도 이슈에 과잉 반응하면서,
조용하지만 치명적인 저빈도 니어미스를 무시하는 함정을 피할 수 있습니다.

모두 합치기: 나만의 실패 온실을 만드는 방법

니어미스를 사소한 에피소드가 아니라 조직의 자산으로 바꾸려면 다음이 필요합니다.

이 관행에 이름을 붙이십시오.
“니어미스 포착(near-miss capture)”, “약한 신호 분석(weak-signal analysis)” 같은 말을 공개적으로 쓰며,
조직이 이 활동을 공식적으로 중요하게 여긴다는 신호를 보내십시오.
연필로 그린 듯한, 마찰이 최소인 템플릿을 배포하십시오.
완벽함을 목표로 하지 말고, 빠르고 일관된 기록을 목표로 하십시오.
기술적 맥락과 인간·업무 맥락을 둘 다 담는 것이 핵심입니다.
앞단에 투자하십시오.
보고는 쉽게, 트리아지는 빠르게, 분류는 구조화해서 수행하십시오.
이 세 단계에서, 데이터가 인사이트로 이어질지, 그냥 사라질지가 갈립니다.
락인 스타일 사고방식을 도입하십시오.
우선순위가 높은 패턴을 몇 개 정하고,
그 패턴을 소음 속에서 탐지할 수 있도록 분석 도구와 태그 체계를 튜닝하십시오.
자신만의 인시던트 스펙트럼을 시각화하십시오.
사건을 유형, 발생 위치, 인간·업무 맥락에 따라 분리해서 보여주는 간단한 뷰를 만들고,
이를 바탕으로 더 정밀한 개선을 설계하십시오.
루프를 닫으십시오.
팀 미팅에서 정기적으로 니어미스 패턴을 리뷰하고,
그 결과로 무엇이 실제로 바뀌었는지 공개적으로 공유하십시오.
그래야 사람들이 “보고해도 아무 일도 안 일어난다”는 냉소 대신, 보고하면 바뀐다는 경험을 갖게 됩니다.

결론: 연필선을 지워버리지 말라

모든 대형 장애는 한때 희미한 연필선 몇 줄에 불과했습니다.
작은 불일치, 어색한 임시방편, 조용한 ‘거의 사고 날 뻔한 상황’들이 있었지만,
대부분은 무시되거나 기억 속에서 사라졌습니다.

실패 온실—간단한 템플릿, 비난 없는 보고 문화, 락인 스타일 패턴 탐지, 스펙트럼 기반 시각화—를 만들어 두면,
이 연약한 니어미스 단서들이 자라나 명확하고 실행 가능한 인사이트로 변할 수 있습니다.

더 많은 대시보드나 더 강한 비난이 필요한 게 아닙니다.
이미 매일 시스템이 내고 있는 약한 신호를 눈여겨보고, 키우고, 증폭하는 더 좋은 방식이 필요할 뿐입니다.
운영 소음이 완전히 지워버리기 전에 말입니다.