연필로 그려 넣은 사고 등대 지도: 조용한 아슬아슬함을 가장 강력한 조기 경보 시스템으로 바꾸기

연필로 그려 넣은 등대 지도: 폭풍이 생기기 전에 미리 보기

옛날 바다 항해 지도를 떠올려 보세요. 어떤 선장이 한 번은 아슬아슬하게 좌초할 뻔한 지점을 기억해 두기 위해, 그 근처에 작은 등대를 연필로 살짝 그려 넣었습니다. 큰 난파도, 신문 헤드라인도 없었지만, 조용한 ‘거의 재난’이 있었던 자리입니다. 그 연필로 그려 넣은 등대 하나가 이후 그 항로를 지나는 모든 배에게 중요한 경고가 됩니다.

현대 소프트웨어 시스템에서 니어미스(near miss) 는 바로 그 연필 자국과 같습니다. 막판에 가까스로 피한 거의 장애 상황, 내부에서 간신히 잡힌 실패, 적용 직전에 롤백된 잘못된 설정들. 상태 페이지에는 올라오지 않지만, 제대로 포착하고 학습만 한다면 엄청나게 가치 있는 신호입니다.

이 글에서는 다음을 다룹니다:

니어미스를 운 좋게 넘어간 일이 아니라 조기 경보 신호로 다루는 방법
항공 분야의 니어미스 보고 관행을 차용해 소프트웨어 신뢰성을 높이는 방법
사람들이 마음 놓고 말할 수 있는 무책임(no-blame) 보고 문화 만들기
구조화된 포스트모템 도구와 5 Whys 분석으로 경험담을 통찰로 바꾸는 방법
상관관계(correlation) 엔진과 설정(configuration) 검증으로 폭풍이 되기 전에 문제를 잡는 방법

소프트웨어 시스템에서 니어미스란 무엇인가?

니어미스(near miss) 는 원래라면 인시던트나 장애로 이어질 수 있었지만, 실제로는 그렇지 않았던 사건을 말합니다. 우연, 막판의 개입, 혹은 제대로 작동한 안전장치 덕분에 비껴간 경우죠.

예를 들어:

트래픽의 80%를 날려버릴 뻔한 설정 변경이 배포 검증 단계에서 잡힌 경우
잘못된 설정 때문에 백그라운드 잡이 몇 시간 동안 조용히 재시도만 반복하다가, 간신히 데이터 손실을 피한 경우
써드파티 의존성이 느려져 요청 지연 시간이 SLO 경계까지 갔다가, 임계치를 넘기기 직전에 회복된 경우

니어미스는 시스템이 우리가 생각하는 것보다 훨씬 경계선에 가까이 가 있었다는 조기 경보 신호입니다. 이런 신호를 무시하는 것은, 항해 일지에 적힌 “여기서 거의 무언가에 부딪칠 뻔했다”는 기록을 무시하는 것과 같습니다.

반대로, 니어미스를 체계적으로 수집하고 분석하면:

아직 드러나지 않은 잠재적 시스템 취약성을 찾아낼 수 있고
가드레일(guardrail) 과 안전장치를 강화할 수 있으며
기술적 복원력과 운영 인식(operational awareness) 모두를 높일 수 있습니다.

항공이 소프트웨어에 알려줄 수 있는 니어미스 교훈

항공 분야는 수십 년에 걸쳐 성숙한 니어미스 보고 문화를 쌓아 왔습니다. 조종사들은 실제 사고로 이어지진 않았지만, 충분히 그럴 수 있었던 사건에 대해 보고서를 작성합니다.

소프트웨어가 배워야 할 핵심 관행은 다음과 같습니다:

비징벌적(non-punitive) 보고
항공 안전 시스템이 작동하는 이유는, 조종사들이 솔직한 실수나 아찔한 경험을 보고했다고 해서 처벌받지 않는다는 신뢰가 있기 때문입니다. 목표는 학습이지, 처벌이 아닙니다.
중앙집중식·구조화된 데이터
보고서는 중앙 시스템에 모이고, 맥락·환경·기여 요인 등 일관된 필드 구조를 갖습니다. 덕분에 수천 건의 비행 데이터에서 패턴을 찾아낼 수 있습니다.
개인이 아니라 시스템에 초점 맞추기
문제가 발생했거나(혹은 거의 발생했거나) 할 때, 조사자들은 사람이 아니라 시스템을 봅니다. 절차, 인터페이스, 교육, 커뮤니케이션, 자동화 같은 것들입니다.

이 마인드셋을 소프트웨어 엔지니어링에 적용한다는 것은 곧:

니어미스를 개인의 실패가 아닌 안전 데이터로 취급하고
고객에게 직접 영향이 없었어도 공유 저장소에 기록하며
“누가 잘못했나?” 대신 “우리 시스템이 왜 이런 상황을 만들기 쉬웠나?”를 묻는다는 뜻입니다.

무책임(No-Blame) 니어미스 문화를 만드는 법

사람들이 이야기를 꺼내기 두려워한다면, 니어미스는 절대 수면 위로 올라오지 않습니다.

보고를 장려하기 위한 구체적인 방법은 다음과 같습니다:

1. 성공의 정의를 다시 쓰기

문제를 일찍 발견해 막아낸 것 자체가 성공임을 분명히 선언해야 합니다. 다음과 같은 행동을 공개적으로 인정하고 칭찬하세요.

미묘한 메트릭 변화 하나를 보고 위험한 배포를 중단한 사람
티켓 패턴에서 이상 징후를 읽고, 눈덩이처럼 불어나기 전에 문제를 제기한 지원 엔지니어
“방금 나쁜 마이그레이션을 거의 푸시할 뻔했는데, 이게 그걸 막아줬다”고 솔직히 공유한 개발자

2. “거의 그랬다”는 이야기의 일상화

정기적인 공유 자리를 만드세요.

주간 신뢰성·플랫폼 회의에서 하는 니어미스 라운드업(near-miss roundup)
니어미스만 기록하는 전용 슬랙 채널 (예: #near-miss-log)
엔지니어링 뉴스레터에 실리는 짧은 니어미스 회고 글

니어미스가 자주, 공개적으로 논의될수록 낙인과 부끄러움은 줄어듭니다.

3. 두려움과 비난 제거하기

리더십은 반드시 다음을 실천해야 합니다.

인시던트/니어미스 리뷰에서 비난 없는 언어를 공공연히 지지하고
“왜 그렇게 했어요?” 같은 평가성 질문 대신, 상황과 시스템에 초점을 맞춘 질문을 하고
솔직한 실수를 디자인 문제로 간주하고, 개인 성과 문제로 끌고 가지 않기

이 기반이 마련되지 않으면, 이후 어떤 프로세스를 도입해도 잠재력을 제대로 발휘하지 못합니다.

구조화된 포스트모템 도구: 연필로 그려 넣는 사고 등대 지도

인시던트와 니어미스 분석이 여기저기 흩어진 문서, 채팅 로그, 개인 기억 속에만 남아 있다면, 우리는 위험 지점을 표시한 일관된 “지도”를 만들 수 없습니다.

인시던트 뿐 아니라 니어미스에도 쓸 수 있는 구조화 가능·커스터마이즈 가능한 포스트모템 템플릿을 사용하세요. 좋은 템플릿은 대략 이런 항목을 포함합니다.

요약: 무슨 일이 있었는가? 그리고 무슨 일이 ‘거의’ 일어날 뻔했는가?
영향: 사용자에게 직접 영향이 없었다 해도, 내부적으로 어떤 영향이 있었는가? (예: 페이징, 수작업 개입, 리스크 노출 등)
타임라인: 트리거 → 감지 → 대응 → 해결까지의 순차적 흐름
감지 경로: 어떻게 니어미스를 발견했는가? 알람? 사람의 직관? 순전한 우연?
기여 요인: 기술적, 조직적 요인 모두
배운 점: 이전에는 몰랐지만, 이번 일을 통해 새로 알게 된 것은?
액션 아이템: 구체적인 후속 조치, 담당자, 마감 기한

인시던트와 니어미스 모두에 같은 구조를 적용하면:

전체 기록을 대상으로 쿼리를 돌릴 수 있고
“피크 시간대 설정 변경”처럼 자주 반복되는 패턴을 찾을 수 있으며
이 데이터를 상관관계·분석 도구로 흘려보낼 수 있습니다.

이 템플릿들이 곧 여러분의 연필로 그려 넣은 등대 지도입니다. 각 기록은 “미래에 폭풍이 될 수도 있었던 자리”를 지도 위에 표시하는 행위입니다.

더 나은 질문 던지기: 5 Whys 활용법

5 Whys(5번 왜?를 묻는 기법) 은 겉으로 드러난 원인에서 멈추지 않도록 도와줍니다.

예시 니어미스 상황:

설정 변경 한 번으로, 거의 모든 트래픽이 존재하지 않는 백엔드로 라우팅될 뻔했다.

5 Whys로 살펴보면:

왜 설정이 거의 모든 트래픽을 잘못된 곳으로 라우팅하려 했는가?
→ 새로운 호스트 그룹 이름을 오타 냈기 때문이다.
왜 오타 난 호스트 그룹 이름이 설정 검증을 통과할 수 있었는가?
→ 검증이 문법(syntax)만 체크하고, 실제 존재 여부는 확인하지 않았기 때문이다.
왜 검증은 문법만 체크하고 의미(semantics)는 확인하지 않는가?
→ 동적 호스트 그룹을 도입한 이후, 검증 규칙을 업데이트하지 않았기 때문이다.
왜 인프라가 바뀌었는데도 검증 규칙은 따라가지 못했는가?
→ 검증 로직을 업데이트하는 일에 대해 명확한 오너나 프로세스가 없기 때문이다.
왜 이런 검증·안전성의 오너십과 프로세스가 없는가?
→ 설정 안전성을 어느 팀의 책임인지 명확히 정의하지 않았기 때문이다.

이제 해결책은 “타이핑 좀 더 조심하자”가 아니라:

설정 안전성에 대한 명확한 오너십 지정
호스트 그룹 존재 여부까지 확인하는 설정 검증 강화
배포 전 안전 점검·드라이런(dry run) 추가

와 같이, “사람이 실수했다” 수준을 넘어선 시스템 설계 개선으로 이어집니다.

미묘한 신호 찾기: 상관관계 엔진과 조기 탐지

사람은 이야기를 만들고 해석하는 데 강하지만, 로그·트레이스·메트릭 속에 숨어 있는 미세한 패턴을 찾아내는 일은 머신이 더 잘합니다.

고급 상관관계(correlation) 엔진은 다음과 같은 일을 할 수 있습니다.

특정 에러 스파이크 + 지연(latency) 증가 + 캐시 미스 패턴처럼, 장애 직전에 자주 함께 나타나는 신호 조합을 찾아냅니다.
임계치 기반 알람으로는 잡히지 않을 약한 신호(weak signal) 를 표면 위로 끌어냅니다.
오늘의 니어미스와 몇 달 전의 비슷한 사건을 연결해 줍니다.

니어미스 탐지에 이를 활용하면:

사람의 서술뿐 아니라, 과거 니어미스와 높은 상관관계를 가진 데이터 패턴으로 니어미스를 정의할 수 있고
그 패턴이 다시 나타날 때 시스템이 “지금 위험 구역에 들어왔다”고 경고해 줄 수 있으며
시간이 지날수록 여러분 조직만의 이력에 기반한 자동 조기 경보 레이어를 구축할 수 있습니다.

이를 위해서는:

인시던트와 니어미스 기록을 관측성(observability)·분석 스택에 흘려보내고
이벤트에 서비스, 설정, 기능, 시간대 등 맥락 태그를 붙여 저장하고
상관관계 도구를 사용해 여러 이벤트 간 공통 선행 패턴(precursor) 을 찾아야 합니다.

이렇게 할수록 지도 위의 선이 점점 짙어집니다. 각 니어미스가 모여, 우리가 볼 수 있는 패턴을 더 풍부하게 만들어 줍니다.

설정(Configuration): 수많은 니어미스의 조용한 배후

업계 전반에서 설정 오류는 장애의 주요 원인이며, 공식 장애 통계보다도 훨씬 많은 니어미스의 배후에 숨어 있습니다.

설정이 위험한 이유는:

종종 “그냥 데이터”처럼 취급되지만, 실제로는 코드만큼이나 강력한 효과를 내기 때문이고
코드 리뷰·테스트·스테이징 같은 엄격한 절차를 우회하는 경우가 많고
“이 플래그만 살짝 바꾸면 돼” 같은 압박 속에서, 급하게 변경되는 일이 잦기 때문입니다.

설정 관련 니어미스를 줄이는 방법은 다음과 같습니다.

1. 설정을 코드처럼 다루기

설정을 버전 관리 시스템에서 관리하고
변경에 대해 코드 리뷰와 승인을 요구하며
자동화된 체크가 붙은 Pull Request 기반 워크플로를 사용하세요.

2. 강력한 검증 체계 구축

단순 문법(syntax) 검사뿐 아니라 “이 참조는 실제로 존재하는가?” 같은 의미(semantics) 검증까지 수행하고
배포 전 드라이런, 섀도 트래픽, 스테이징 테스트 같은 사전 검증을 실행하고
설정 포맷에 대해 스키마 기반 검증을 도입하세요.

3. 가드레일과 안전한 배포 패턴 추가

카나리(canary), 리전별 점진 롤아웃, 킬 스위치가 있는 기능 플래그 등 점진적 배포 전략을 사용하고
에러율·지연이 악화되면 자동 롤백되도록 구성하고
위험한 설정 변경에 대해 명확한 변경 윈도우와 가시성을 확보하세요.

설정 덕분에 장애를 피한 모든 사례는 꼭 기록해야 할 니어미스이며, 더 나은 검증 체계에 투자해야 할 강력한 근거가 됩니다.

모두 엮어서: 조용한 아슬아슬함을 집단 지혜로 바꾸기

여러분만의 "연필로 그려 넣은 사고 등대 지도"를 소프트웨어 세계에 구축하려면, 다음을 실천해야 합니다.

니어미스에 이름을 붙이고 가치를 부여하세요. 부끄러운 실수가 아니라, 중요한 안전 정보로 다루세요.
무책임(no-blame) 보고 문화를 만드세요. 조기 발견과 투명한 공유를 보상하세요.
인시던트와 니어미스 모두에 구조화된 템플릿을 사용해, 교훈을 검색 가능하고 비교 가능하게 만드세요.
5 Whys를 적용해 피상적인 원인에서 멈추지 말고, 시스템 수준의 원인을 찾아내세요.
상관관계 엔진을 활용해 과거 사건에서 공통 선행 패턴과 미묘한 신호를 발굴하세요.
설정 안전성에 아낌없이 투자하세요. 검증, 오너십, 배포 가드레일까지 포함해서요.

시스템은 앞으로도 폭풍을 맞이할 것입니다. 하지만 니어미스를 하나씩 포착하고 분석할수록, 지도는 더 선명해지고, 등대는 더 밝아지며, 승무원들은 더 잘 대비하게 됩니다. 시간이 지나면 놀랄 일은 점점 줄어들 것입니다. 운이 좋아서가 아니라, 조용한 아슬아슬함을 신뢰성 향상을 위한 가장 강력한 학습 엔진으로 바꾸어 놓았기 때문입니다.