골판지 인시던트 관측 트램: 시스템의 가장 조용한 근접 사고를 따라가는 종이 노선

도시 전역을 도는 관측용 트램을 골판지로 만든다고 상상해보세요.

이 트램은 태풍은커녕, 센 바람에도 버티지 못할 겁니다. 완성품도 아닙니다. 이건 종이로 된 노선에 가깝습니다. 연약하고 임시적이지만, 일부러 천천히 시스템 풍경을 지나가며 평소에는 너무 빨리 지나쳐서 보지 못하는 것들을 눈에 담게 해주는 도구입니다.

소프트웨어 시스템에서 근접 사고(near miss) 관측·학습 관행이 바로 이런 역할을 할 수 있습니다.

대부분의 팀은 심각한 인시던트—장애, 보안 침해, 데이터 손실—가 터졌을 때만 ‘세상을 멈추고’ 대응합니다. 하지만 그 훨씬 이전부터 시스템은 계속 속삭이고 있습니다. 여기선 이상한 로그 한 줄, 저기선 재시도 폭주, 화요일에만 실패하는 플래키 테스트 같은 것들로요.

이런 것들이 바로 근접 사고입니다. 큰 피해로 이어지기 전에 잡힌 문제들이죠. 그리고 이건 보안, 복원력, 안전 문화를 개선하는 데 있어 금광 같은 자원입니다.

이 글은 그런 “골판지 트램”을 만드는 이야기입니다. 가볍고, 눈에 잘 보이고, 문화적으로도 받아들여지는 시스템을 만들어, 조용히 지나가는 근접 사고들을 정기적으로 함께 돌아보며, 그게 뉴스거리가 되기 전에 배움을 끌어내는 방법에 대한 이야기입니다.

근접 사고가 생각보다 훨씬 중요한 이유

근접 사고(near miss) 는 무언가 잘못될 뻔했지만 실제로는 일이 터지지 않은 사건입니다. 운이 좋았거나, 부분적인 방어 장치 덕분이거나, 누군가 마지막에 눈치껏 잡아냈기 때문일 때가 많습니다.

예를 들면:

• 배포 몇 분 전에 리뷰에서 걸러진, 잘못 설정된 방화벽 규칙
• 테이블을 한 시간 동안 락 걸어버릴 뻔한 DB 마이그레이션을, 눈 밝은 엔지니어가 실행 계획을 보고 롤백한 경우
• 하루에 200번씩 조용히 재시도만 하고, 완전히 실패하지도 성공하지도 않는 백그라운드 잡

이 중 어느 것도 공식 인시던트로 분류되지 않았습니다. 상태 페이지를 올릴 일도 없었고, 고객 불만도 없었죠.

하지만 이런 조용한 ‘거의-문제’들 안에는 다음과 같은 것들이 숨어 있습니다.

• 부서지기 쉬운 가정(brittle assumptions)의 증거
• 숨겨진 단일 장애점(single point of failure)
• 개인의 ‘영웅적 행동’에 의존했던 설계의 빈틈

방어선을 뚫고 나온 몇 번의 대형 인시던트만 분석한다면, 매일같이 쌓이고 있는 약한 신호들—즉, 시스템이 실제로 어떻게 작동하고 있는지를 보여주는 방대한 데이터—를 모두 놓치게 됩니다.

항공 산업은 이 사실을 오래전에 깨달았습니다.

항공에서 배우기: 근접 사고 보고를 안전 엔진으로 사용하는 법

상업 항공이 놀라울 정도로 안전한 이유는 비행기가 절대 고장 나지 않아서가 아니라, 업계 전체가 작은 실패와 근접 사고 하나하나에서 집요하게 학습하기 때문입니다.

조종사, 승무원, 관제사는 다음과 같은 상황을 보고하도록 장려되거나, 심지어 법적으로 의무화되어 있습니다.

• “착륙할 활주로를 잘못 정렬할 뻔했다.”
• “최소 안전 고도 아래로 잠깐 내려갔다.”
• “관제 지시를 잘못 알아듣고, 승인 없이 이륙할 뻔했다.”

이 중 대부분은 실제 사고로 이어지지 않습니다. 하지만 이 보고들은 체계적인 학습 기계로 흘러 들어갑니다. 데이터베이스, 안전위원회, 항공사 간 리뷰, 튼튼한 의미 만들기(sensemaking) 프로세스의 연료가 되죠.

소프트웨어 엔지니어링은 이런 엄밀함이 부족한 경우가 많습니다. 많은 팀이:

• P0/P1 인시던트만 공식적으로 추적하고,
• “거의 문제 될 뻔한 것들”은 잡음 또는 국지적 특이 케이스로 치부하고,
• 구조화된 학습 대신, 기억과 복도 대화에 의존합니다.

하지만 우리 시스템도 항공과 비슷한 복잡한 사회-기술(socio-technical) 환경입니다. 마찬가지로, 우리는 이런 것들을 위한 체계적인 방식이 필요합니다:

• 약한 신호를 포착하고
• 팀 간에 공유하며
• 이를 설계, 도구, 프로세스 개선으로 전환하는 것

여기서 골판지 인시던트 관측 트램(Cardboard Incident Observatory Tram) 이 등장합니다.

골판지 트램: 가볍고, 눈에 잘 보이는 학습 시스템이라는 은유

근접 사고 관행을 골판지 트램처럼 떠올려 보세요.

• 무거운 거버넌스 프로세스가 아닙니다.
• 실험적이고, 쉽게 모양을 바꿀 수 있습니다.
• 일부러 느립니다. 주변을 둘러볼 수 있게 하기 위해서죠.
• 모두가 보고, 참여할 수 있는 눈에 보이는 레일 위를 달립니다.

실무적으로는 다음과 같이 보일 겁니다.

1. 근접 사고와 약한 신호를 의도적으로 포착하기
2. 이를 공유된 시스템에서 시각화하기
3. 팀이 정기적으로 함께 돌아보며, 패턴을 해석하고, 행동으로 옮기기

하나씩 살펴보겠습니다.

1단계: 근접 사고를 ‘보고 가능한 것’으로, 그리고 ‘안전한 것’으로 만들기

보이지 않으면, 배울 수도 없습니다.

먼저 우리가 중요하게 여기는 대상을 명시적으로 정의합니다.

“근접 사고는, 아무것도 실제로 깨지지 않았고, 고객도 눈치채지 못했더라도, 뭔가 이상하거나, 놀랍거나, 위험하게 느껴졌던 모든 사건이다.”

다음과 같은 것들의 보고를 장려하세요.

• 수상한 패턴: 스스로 회복되었지만 묘하게 찜찜한 레이턴시 스파이크
• 우연한 세이브: “실수로 프로덕션에 배포할 뻔 했는데, 스테이징인 줄 알고 버튼을 눌렀다.”
• 불편한 의존성: “이 잡이 실패해도, 우리는 그걸 알려주는 알림이 전혀 없다.”
• 설계에 대한 불안감: “이 코드를 건드릴 때마다 니트로글리세린 만지는 느낌이다.”

이를 뒷받침하기 위해 다음을 준비합니다.

• 블레이멀리스(blameless) 프레이밍: 누가 실수했는지가 아니라, 어떤 조건과 시스템이 그 상황을 만들었는지에 초점을 맞춥니다.
• 저마찰 캡처 방식: 긴 인시던트 리포트보다는 짧은 폼, 슬랙 이모지 리액션, 간단한 티켓 템플릿이 훨씬 낫습니다.
• 리더십의 시그널링: 테크 리드와 매니저가 스스로의 근접 사고를 자주 공유해야 합니다. 예: “거의 시크릿을 푸시할 뻔했는데, 이런 게 날 막아줬다.”

목표는 단순합니다. “거의 문제가 될 뻔한 것들”을 실제 장애만큼이나 사회적·절차적으로 중요하게 만드는 것입니다.

2단계: 시각화 시스템으로 약한 신호를 ‘보이는 것’으로 만들기

근접 사고가 보고되기 시작하면, 그것들이 눈에 보이는 아티팩트가 되어야 합니다. 잊혀지는 채팅 로그로 남아서는 안 됩니다.

효과적인 시각화 도구 몇 가지를 소개합니다.

1. 근접 사고 칸반 보드

간단한 칸반 보드를 하나 만듭니다. 예를 들어 이런 컬럼으로 구성할 수 있습니다.

• Spotted (발견) – 아직 분류되지 않은, 날 것의 근접 사고들
• Sensemaking (해석 중) – 논의와 탐색이 진행 중인 항목
• Decisions (결정) – 무엇을 바꿀지(또는 의도적으로 바꾸지 않을지)
• In Progress (진행 중) – 대응·완화 작업이 진행 중인 것들
• Learned (학습 완료) – 인사이트가 정리되고, 관행이나 문서가 업데이트된 것들

각 카드에는 다음 정보를 담습니다.

• 근접 사고를 이해하기 쉬운 자연어로 설명
• 어디에서 포착되었는지(모니터링, 코드 리뷰, “이상한 느낌”, 등)
• 영향을 받은 시스템, 팀, 리스크 유형(보안, 신뢰성, 데이터, UX 등) 태깅

이 보드가 바로 여러분의 골판지 트램 레일입니다. 시스템 곳곳의 조용한 이상 징후를 따라 이어지는 눈에 보이는 노선이죠.

2. 인시던트 & 근접 사고 맵

시간 또는 시스템 축을 기준으로 한 지도를 만듭니다. 여기에 다음을 함께 표시합니다.

• 대형 인시던트
• 소규모 인시던트
• 근접 사고와 반복되는 약한 신호들

그러면 이런 패턴이 눈에 띄기 시작합니다.

• “이 모든 게 인증(auth) 서비스 주변에 몰려 있다.”
• “근접 사고의 절반은 데이터 마이그레이션과 관련 있다.”
• “분기 말마다 레이트 리밋 경고가 나는데, 실제로 장애가 나지는 않는다.”

지도는 막연한 불편함을 구체적이고 논의 가능한 리스크 지형도로 바꿔줍니다.

3단계: 함께 타는 해석 의식 – 트램을 함께 타고 돌아보기

이벤트를 수집하는 것만으로는 충분하지 않습니다. 진짜 힘은 의미 만들기(sensemaking) 에서 나옵니다. 약한 신호를 함께 해석하고, 여러 이야기를 탐색하고, 그게 무엇을 시사하는지 합의해 나가는 과정입니다.

정기적인 의식을 하나 추가해 보세요.

근접 사고 트램 라이드(Near-Miss Tram Ride) – 4560분, 24주마다 한 번

참석 대상: 엔지니어, SRE, 보안, 프로덕트, 필요하다면 고객 지원까지—실제 시스템의 행동을 가까이에서 보는 사람이라면 누구나.

예시 아젠다는 다음과 같습니다.

1. 보드/맵 리뷰

   • 최근 Spotted와 Sensemaking에 새로 들어온 것은 무엇인가?
   • 군집이나 반복되는 테마가 있는가?

2. 비난이 아닌 스토리텔링

   • “우리에게 무엇이 놀라웠나?”, *“이 일이 가능하도록 만든 조건은 무엇이었나?”*를 묻습니다.
   • 온콜 부담, 도구의 빈틈, 설계 제약 등 맥락을 함께 탐색합니다.

3. 지시가 아닌 가설과 실험

   • 작은 완화책, 탐침(probe), 관측성(observability) 개선 아이디어를 검토합니다.
   • 여전히 불확실한 부분을 명시적으로 남겨둡니다—이 자체가 중요한 신호입니다.

4. 결정과 비결정 모두 기록

   • “지금은 이걸 고치지 않기로 했다, 그 이유는 …” 같은 선택도 중요한 학습 아티팩트입니다.

여기에서 **실패에 대한 ‘집요한 관심(preoccupation with failure)’**이 살아납니다. 큰 소리로 난리가 나기 전에, 가장 작은 힌트들을 바탕으로 다음에는 무엇이 어떻게 망가질 수 있는지에 대해 차분하고 호기심 어린 주의를 기울이는 시간입니다.

변화와 고통의 시기에 의식을 다듬기

근접 사고 관행을 다듬기에 가장 좋은 시기는 다음과 같습니다.

• 아키텍처가 크게 변하고 있을 때 (클라우드 마이그레이션, 모놀리식 → 서비스, AI 기능 도입 등)
• 팀이 고통을 느끼고 있을 때 (온콜 번아웃, 반복되는 혼란, 특정 서비스 주변의 잦은 마찰 등)

이럴 때 다음 질문을 던져보세요.

• 우리가 지금 무시하고 있는 약한 신호는 무엇인가?
• 어떤 의식/회의가 형식적이기만 하고, 실제로는 비어 있는가?
• 어디에 더 가볍고 솔직한 포럼을 만들 수 있을까?

예를 들어 이렇게 해볼 수 있습니다.

• 기존 인시던트 리뷰 미팅 안에 근접 사고 리뷰를 접목하기
• 회고(레트로스펙티브) 안에 “이번 주 근접 사고 있었나요?”라는 짧은 섹션 추가
• 3개월 한정 실험으로 트램을 도입해 보고, 그 후에 재평가하기

여기서 골판지 비유가 중요합니다. 이 프로세스는 처음부터 완벽할 필요가 없습니다. 존재하고, 눈에 보이고, 조정 가능하기만 하면 됩니다.

근접 사고 문화를 운영상의 강점으로 바꾸기

‘거의 문제 될 뻔한 것들’을 보고하고 탐구하는 문화를 의도적으로 키우면, 다음과 같은 변화가 일어납니다.

• 보안이 좋아집니다. 잘못된 설정, 안전하지 않은 디폴트, 서서히 쌓이는 권한 남용(access creep)을 악용되기 전에 발견할 수 있습니다.
• 복원력이 높아집니다. 스트레스 패턴, 용량 절벽, 부서지기 쉬운 의존성을 실제 붕괴 훨씬 전에 감지합니다.
• 안전 문화가 깊어집니다. 사람들이 문제를 일찍 드러내는 걸 더 안전하게 느낍니다. 이야기가 비난이 아니라 실제 변화로 이어지는 걸 보기 때문입니다.
• 학습 속도가 빨라집니다. 새 팀원들은 잘 다듬어진 아키텍처 다이어그램만 보는 게 아니라, “어디가 어떻게 거의 부러졌었는지”에 대한 풍부한 역사에 노출됩니다.

시간이 지나면, 가장 조용한 약한 신호들이 전략적 자산이 됩니다. 시스템이 앞으로 어디에서, 어떤 방식으로 여러분을 다치게 만들 가능성이 가장 높은지 보여주는, 살아 있는 지도로 바뀌죠.

앞으로 30일 안에 시작하는 방법

처음부터 거창한 프로그램이 필요하지 않습니다. 이렇게 시작해 보세요.

1. 1주차 – 실험 선언하기

   • 여러분 조직에 맞는 “근접 사고” 정의를 공유합니다.
   • 간단한 폼이나 티켓 템플릿을 만듭니다.
   • 리더들이 자신의 실제 사례 몇 가지를 먼저 공개합니다.

2. 2주차 – 시각화 도구 세우기

   • 근접 사고 칸반 보드를 만듭니다.
   • 최근 사례 3~5개를 먼저 올려 씨드로 사용합니다.

3. 3주차 – 첫 트램 라이드 진행

   • 45분, 소규모 그룹으로 진행합니다.
   • 비난이 아닌 스토리텔링과 호기심에 집중합니다.

4. 4주차 – 골판지 다듬기

   • 무엇이 유용했고, 무엇이 무겁게 느껴졌는지 묻습니다.
   • 마찰을 줄입니다. 템플릿을 줄이고, 포커스를 좁힙니다.

도움이 된다면, 이걸 분명한 실험으로 선언하세요.

“우리는 골판지 인시던트 관측 트램을 만들고 있습니다. 처음엔 좀 덜컹거릴 수 있습니다. 괜찮습니다. 우리 눈을 더 잘 뜨게 도와주는 부분만 골라서 보강해 나가면 됩니다.”

결론: 큰 ‘추락’을 기다리지 말 것

대형 인시던트는 언제나 우리의 관심을 빼앗을 겁니다. 크고, 아프고, 비용도 많이 듭니다.

하지만 가장 강력한 학습 기회는 종종 시스템의 조용하고 애매한 구석에 숨어 있습니다. 거의 타임아웃 날 뻔한 체크아웃, 거의 새 나갈 뻔한 시크릿, 거의 디스크를 가득 채울 뻔한 크론 잡 같은 것들이죠.

골판지 인시던트 관측 트램을 만든다는 건 다음을 의미합니다.

• 이런 근접 사고들을 눈에 보이게 만들고,
• 팀에 시간과 공간을 줘서 함께 해석하게 하고,
• 약한 신호를 의도적인 설계·도구·문화 개선으로 전환하는 것.

완벽한 프로세스는 필요 없습니다. 필요한 건, 그 종이 트램을 꾸준히 시스템 안으로 몰고 들어가, 함께 창밖을 내다보며 이렇게 말할 의지입니다.

“우리는 여기서 거의 문제를 겪을 뻔했다. 이게 우리에게 무엇을 말해주려는 걸까?”

이렇게 할 때, 가장 조용했던 근접 사고들은 결국 가장 큰 인사이트의 원천으로 바뀌게 됩니다.