아날로그 리스크 관측 캘린더: 가장 아찔했던 ‘아차사고’를 잊지 않기 위한 1년짜리 벽의식

어느 팀에나 "그때 진짜 큰일 날 뻔했던" 이야기가 있다.

거의 운영 DB 테이블을 날려버릴 뻔한 데이터베이스 작업. 블랙 프라이데이에 결제 시스템을 거의 멈춰 세울 뻔한 배포. 거의 붙어버렸다가 마지막에 간신히 열렸던 안전밸브.

이런 것들이 바로 아차사고(near miss) 다. 시스템이 실패 쪽으로 크게 휘청였지만, 완전히 망가지기 전에 운이 좋게 혹은 빠른 대응으로 되돌려 놓은 사건들이다.

우리는 보통 안도의 한숨을 쉬고, 눈앞의 문제만 대충 막고, 다음 일로 넘어간다. 하지만 이런 아차사고야말로 금광에 가깝다. 실제 큰 사고가 터졌을 때 치르게 될 막대한 비용과 피해 없이, 우리 시스템의 안전 한계가 어디인지 보여주기 때문이다.

이 글에서는 단순하지만 놀라울 정도로 강력한 도구를 소개한다. 바로 아날로그 리스크 관측(Observatory) 캘린더다. 팀의 가장 아찔했던 아차사고들을 1년 동안 벽에 붙여 놓고, 계속해서 다시 보고, 그 안에서 배우도록 돕는 물리적인 벽 의식이다.

아차사고가 생각보다 훨씬 더 가치 있는 이유

대부분의 조직은 큰 사고에 집착한다. 사고가 터지면 포스트모템, 리더십 리뷰, 대시보드 업데이트, OKR 조정까지 줄줄이 이어진다. 반면 아차사고는 대개 이렇게 남는다.

새벽 2시 슬랙 쓰레드에 남은 이야기
스탠드업에서 나오는 쓴웃음 섞인 농담
회고 시간에 툭 던지는 “이번엔 운 좋았죠” 한마디

그러고는 사라진다.

이건 문제다. 왜냐하면:

아차사고는 리스크에 대한 핵심 인사이트를 제공하면서도, 실제 대형 사고가 주는 사회적·금전적·평판적 비용은 거의 요구하지 않는다.
종종 잠복된 조건(latent conditions)—평소에는 드러나지 않다가 특정 상황이 맞아떨어질 때만 위험을 만드는 오래된 약점—을 가리킨다.
그 조건들이 결국 실제 사고로 이어질 때쯤이면, 이미 “싸게 배울 기회”는 지나가 버린 뒤다.

달리 말하면, “부서진 것”만 분석하면 편향된 표본으로부터 배우게 된다. “부서질 뻔한 것들”에서 나오는 신호들을 놓치는 셈이고, 그 신호들은 훨씬 더 일찍 시스템을 바꿀 수 있었던 기회를 제공했을지 모른다.

아차사고는 하나의 예보(forecast) 다. 그 예보답게 다뤄야 한다.

들쭉날쭉한 ‘무용담’에서 체계적인 신호로

핵심 변화는, 그때그때 우연히 반응하는 즉흥적 대응에서 벗어나 아차사고를 체계적으로 탐지하고 기록하는 쪽으로 옮겨가는 것이다.

무엇인가가 한 번 크게 터졌을 때만 티켓을 만든느 대신, 의도적으로 이런 사건들을 찾아본다.

이번엔 운 좋게 고객 영향은 없었지만, 충분히 그럴 수 있었던 일
온콜 담당자가 개입해서 아슬아슬하게 연쇄 장애를 막은 순간
헐거운 시스템 의존성을 수동으로 메꾸며 가까스로 유지하고 있는 위험한 우회로
배포 직전에 겨우 발견된 구성(컨피그) 실수

그때그때 대응할 때는 이 모든 게 그냥 “아찔했던 한 번”처럼 느껴진다. 하지만 이를 체계적으로 탐지·기록·분류하기 시작하면, 평소에는 보이지 않던 패턴들이 나타난다.

특정 서비스가 여러 아차사고에 반복적으로 등장한다.
특정 시간대(예: 금요일 배포)와 자주 겹친다.
특정 팀이나 도구 사이의 핸드오프 구간에서 위험이 자주 생긴다.
늘 아차사고 전에 나타나는 공통적인 전조 신호들이 있다.

여기서 아날로그 리스크 관측 캘린더의 역할이 시작된다.

아날로그 리스크 관측 캘린더란 무엇인가?

한눈에 12개월이 다 보이는, 큰 사이즈의 벽걸이 연간 캘린더를 떠올려보자. 그 캘린더 위에 팀이 경험한 의미 있는 모든 아차사고를 핀으로 꽂거나 메모로 남기는 것이다.

이건 프로젝트 플랜도 아니고, 딜리버리 로드맵도 아니다.

이건 팀의 리스크 일기예보 지도다.

누구든 벽 앞으로 걸어가서 이런 것들을 바로 볼 수 있다.

어느 시기에 아차사고가 몰려 있는지
어떤 유형의 위험이 반복되는지
어떤 시스템·팀·맥락이 자주 등장하는지
시간이 지나며 대응 방식과 설계가 어떻게 바뀌었는지

이걸 ‘관측소(observatory)’라고 부르는 이유는, 말 그대로 시간을 가로질러 리스크 풍경을 관찰하기 위해서지, 오늘 불이 난 곳만 쫓아다니기 위해서가 아니기 때문이다.

아차사고 주변의 “중요한 층위”에 집중하기

아차사고는 사건 하나로 끝나지 않는다. 그 주변에는 그 사건을 진짜 유의미하게 만들어주는 여러 층위의 데이터가 함께 있다.

컨텍스트(Context) – 시스템과 조직에 무슨 일이 벌어지고 있었나?
- 마이그레이션 도중이었는가, 촉박한 마감 시한이 있었는가, 다른 곳에서 이미 사고가 나 있던 상황이었는가?
- 인력 부족, 교대 인수인계 문제, 평소와 다른 고객 행동이 있었는가?
신호(Signals) – 어떤 초기 경고 신호들이 있었나?
- 알람, 로그, 사용자 불만, 성능 이상 징후
- 나중에 보니 중요해 보이는 약한 신호(weak signal) 가 있었는가?
타이밍(Timing) – 언제 발생했고, 그 전에 무엇이 있었나?
- 배포, 설정 변경, 시장 이벤트, 트래픽 급증
- 분기 말/월말 등 이미 위험하다고 알려진 패턴과 겹쳤는가?
결과(Outcomes) – 실제로는 무엇이 일어났고, 최악의 경우 어떤 일이 가능했는가?
- “일부 구성요소의 이중화는 잃었지만, 고객 영향은 없었다.”
- “에러 버짓은 다 소모했지만, 장애로 이어지지는 않았다.”

이런 층위들에 주의를 기울이도록, 인간 리뷰 의식이든, 메트릭 대시보드든, ML 기반 도구든 어떤 ‘주의 메커니즘’이든 이 층위들에 맞춰 튜닝되어 있어야 한다.

캘린더 위에서는 이 층위들이 다음과 같은 방식으로 시각화된다.

색깔 코딩(시스템, 심각도, 실패 양상별)
짧은 주석(“수동 롤백으로 겨우 복구”, “알람 피로로 대응 지연” 등)
반복되는 테마에 대한 심볼·스티커(예: 🔁 배포 리스크, 🧩 통합 이슈)

단순히 사건을 기록하는 것이 아니라, 그 맥락까지 함께 지도 위에 펼쳐 놓는 셈이다.

나만의 아차사고 벽 의식 만들기

작게 시작해도 충분한 가치를 얻을 수 있다. 여기서는 아날로그 리스크 관측 캘린더를 도입하는 실용적인 방법을 제안한다.

1. 물리적 공간 준비하기

12개월이 한눈에 보이는 큰 벽걸이 연간 캘린더를, 모두가 자주 지나다니는 공용 공간에 붙인다. (혹은 큰 화이트보드를 12개월로 나눠도 된다.)
엔지니어·운영·분석 인력이 자연스럽게 모이는 곳 근처가 좋다.
마커펜, 포스트잇, 간단한 범례(legend)를 함께 비치한다.

2. 무엇을 ‘아차사고’로 볼지 정의하기

팀 차원에서 최소한의 공통 정의를 맞춰 둔다. 예를 들면 다음과 같다.

“공식 인시던트(사고)로 선언되지는 않았더라도, 우리가 편안하게 받아들일 수 있는 수준보다 고객 영향이나 안전 리스크에 의미 있게 가까이 갔던 모든 사건.”

초기에는 넉넉하게 포함(Over-inclusion) 하는 쪽을 권장한다. ‘너무 많이 기록했다’는 건 나중에 조정하면 되지만, 놓쳐버린 신호는 다시 가져올 수 없다.

3. 가벼운 기록 템플릿 만들기

각 아차사고마다 포스트잇 한 장에 다음 정도만 적는다.

날짜와 시간
관련된 시스템 / 서비스 / 프로세스
매우 짧은 설명 (1–2줄)
주요 리스크 유형 (가용성, 무결성, 안전, 컴플라이언스 등)
(선택) 컨텍스트, 전조 신호, 완화 전략 태그

핵심은 속도와 가시성이지, 완벽한 보고서가 아니다.

4. 기존 워크플로에 녹여 넣기

이걸 따로 떨어진 ‘사이드 프로젝트’로 만들지 말고, 기존 작업 흐름 속에 끼워 넣는다.

스탠드업 – “어제 이후로 아차사고 있었나요?”라는 질문을 추가한다.
온콜 교대 인수인계 – 지난 근무 동안 있었던 아찔했던 순간을 기록한다.
사고 리뷰(포스트모템) – 공식 인시던트 문턱을 넘지 않았지만, 관련된 아차사고도 함께 문서화한다.
스프린트 리뷰 / 운영 리뷰 – 최근 캘린더에 추가된 항목을 짧게 훑어본다.

목표는, 아차사고 기록이 티켓 업데이트만큼 당연한 루틴이 되도록 만드는 것이다.

5. 정기적으로 캘린더 리뷰하기

캘린더를 살아 있는 산출물(living artifact) 로 사용해야지, 포스트잇 무덤으로 방치해서는 안 된다.

월간 리뷰(30–45분)
- 아차사고를 테마별로 묶어본다.
- “어떤 패턴이 보이나?”, “가장 의외였던 건 무엇인가?”를 같이 묻는다.
- 1–3개의 작지만 구체적인 설계/프로세스 변경을 결정한다.
분기별 리뷰(60–90분)
- 한 걸음 물러서서 계절성·시기성을 살펴본다.
- 대형 프로젝트, 인력 변화, 인프라 전환 등과 아차사고를 연결해본다.
- 더 깊은 분석이나 투자가 필요한 부분을 찾는다.

시간이 쌓이면, 벽에는 눈에 보이는 살아 있는 학습의 연대기가 남는다.

일회성 리스크 분석이 아닌 ‘습관’으로 만들기

많은 팀은 뭔가 크게 터지고 나서야 리스크 이야기를 한다. 캘린더 의식은 이 패턴을 바꾼다.

리스크 대화를 일상적인 대화의 일부로 만든다. 더 이상 가끔 열리는 특별행사가 아니다.
과거의 아찔했던 순간들을 항상 눈앞에 두어, 알람만 조용해지면 곧바로 잊어버리는 일을 막는다.
“큰 사고가 터졌을 때만 포스트모템”이 아니라, 작게·지속적으로 배우는 문화를 만든다.

아날로그 캘린더는, 항상 눈에 보이는 물리적 존재로서 끊임없이 이렇게 상기시킨다.

이 시스템은 복잡하고, 우리가 아직 다 모르는 실패 방식이 항상 새로 발견되고 있다.

이렇게 해서 리스크 분석은, 그때그때 불 끄러 다니는 일이 아니라 선제적인 회복탄력적 시스템 설계로 전환된다.

“겨우 넘겼다”가 아니라 “잘 발견했다”를 칭찬하기

“운 좋게 넘어갔다”고 솔직하게 말하는 순간에 비난받을 것 같다면, 사람들은 아차사고 이야기를 아예 하지 않게 된다.

회복탄력적인 문화를 만들려면 다음이 필요하다.

아차사고를 발견하고 보고한 행위 자체를, 실제 인시던트 대응만큼이나 인정해줘야 한다.
희미한 신호를 일찍 눈치챈 사람들을 칭찬해야 한다.
아차사고 보고를 고백이 아니라 프로페셔널리즘의 표현으로 다뤄야 한다.

실천 방법 예시는 다음과 같다.

전체 회의(All-hands)에 “이달의 아차사고” 코너를 만들어 공유한다.
눈에 잘 띄지 않던 리스크를 찾아낸 개인/팀을 공식적으로 인정한다.
그 경험에서 무엇을 배웠고 무엇이 바뀌었는지 짧은 글로 공유한다.

조직이 보내는 메시지는 분명해야 한다.

우리는 숨기는 것이 아니라 배우는 것을 가치 있게 본다.

인시던트 관리에서 아차사고를 ‘1급 시민’으로 대우하기

아날로그 리스크 관측 캘린더에서 최대의 효과를 얻으려면, 아차사고를 인시던트 관리 체계의 부가 옵션이 아니라 정식 구성원으로 취급해야 한다.

그 말은 곧:

인시던트 분류 체계(Severity, 카테고리, 담당 조직 등) 에 아차사고를 포함한다.
아차사고 역시 실제 인시던트처럼 개선 조치의 트리거가 되도록 한다. (런북 추가, 테스트 보강, 설계 변경 등)
캘린더를 바탕으로 인시던트 시뮬레이션/게임데이를 설계한다. (예: “이 아차사고가 계속 반복된다—이 시나리오를 직접 연습해보자.”)

이런 마인드셋 전환을 통해, 팀은 ‘피해가 발생한 뒤에만 반응하는 세계’에서 벗어나, 아직 터지지 않은 실패의 증거를 바탕으로 미리 회복탄력성을 설계하는 세계로 옮겨간다.

결론: 정말 필요해지기 전에, 관측소부터 만들어라

아차사고는 우주가 우리에게 “미래의 대형 사고를 싸게 막을 수 있는 기회”를 주는 방식이다.

아날로그 리스크 관측 캘린더는 매우 단순하고 로우테크이지만, 다음과 같은 효과를 낸다.

아차사고 스토리를 눈에 보이게, 기억에 남게 만든다.
컨텍스트·신호·타이밍·결과의 패턴을 드러낸다.
아차사고 리뷰를 일상적인 워크플로에 녹여 넣는다.
솔직한 보고와, “잘 발견했다”는 인정의 문화를 만든다.
뒷불만 끄는 조직에서 선제적인 회복탄력 설계로 전환하게 돕는다.

새로운 툴이나 복잡한 플랫폼이 꼭 필요한 건 아니다. 필요한 것은:

벽 한 면
연간 캘린더 하나
약간의 포스트잇
그리고 가장 아찔했던 ‘거의 사고’들을 가장 소중한 교사로 대하겠다는 의지다.

캘린더를 붙인다. 다음 아차사고를 기록한다. 그리고 리스크 풍경을, 흩어진 개별 폭풍들이 아니라 1년 단위의 날씨 시스템으로 본다. 관측하고, 이해하고, 조금씩 바꿔갈 수 있는 대상으로 말이다.

그렇게 해야 당신은 가장 무서웠던 아차사고들을 잊지 않고, 오히려 그것들을 발판 삼아 무슨 일이 오더라도 버틸 수 있는 시스템을 만들어갈 수 있다.