골판지 사건: Ferris Dock는 어떻게 ‘빙빙 도는 장애’를 신뢰성 도약의 발판으로 만들었나

가상의 회사지만 너무나도 익숙하게 느껴지는 Ferris Dock에는 전설처럼 내려오는 한 가지 사건이 있습니다.

사람들은 그것을 **“골판지 사건(The Cardboard Incident)”**이라고 부릅니다.

겉으로 보면 그냥 또 하나의 장애에 불과했습니다. 화면에서 빙글빙글 도는 로딩 아이콘, 쌓여만 가는 고객 문의, 동시에 열리는 엔지니어들의 노트북…. 하지만 이 사건이 특별했던 이유는 장애 그 자체가 아니었습니다. 진짜 중요했던 건 그 이후에 벌어진 일이었습니다.

Ferris Dock는 이 장애를 계기로, 신뢰성·사고 대응·학습 방식을 근본적으로 바꿨습니다. 이 글은 그들이 어떻게 해냈는지, 그리고 여러분 조직도 어떻게 같은 길을 걸을 수 있는지에 대한 이야기입니다.

골판지 사건: 짧은 이야기

Ferris Dock는 수천 개 창고에서 사용하는 물류·도킹 플랫폼을 운영하고 있었습니다. 어느 화요일 오후, 코드 배포 하나가 연쇄적인 성능 저하를 불러왔습니다. 요청이 빠르게 실패하는 것도 아니고, 그냥… 무한 로딩만 돌았습니다.

상태 페이지는 한참 동안이나 초록불(정상)을 유지했습니다. 모니터링 임계값이 "부분적인 성능 저하"를 제대로 감지하지 못하도록 설정되어 있었기 때문입니다. 고객들은 자기 브라우저나 와이파이가 문제라고 생각하며 새로 고침만 반복했습니다.

사고가 온전히 인지되었을 때는 이미 여러 고객사에서 운영 차질이 발생한 뒤였습니다. 한 물류 창고 관리자는 더 이상 참지 못하고 Ferris Dock 대시보드를 인쇄해 골판지에 붙이고, 빨간 매직으로 크게 "시스템 또 다운(SYSTEM DOWN AGAIN)"이라고 써서 상·하차장에 걸어 두었습니다.

그 골판지 안내판 사진이 Ferris Dock로 전달됐습니다.

그리고 이 사진은 곧 하나의 상징이 되었습니다.

경영진은 이 사건을 덮으려 하지 않고, 그 사진을 출력해 장애 리뷰 회의실 벽에 붙였습니다. 그 골판지는 더 이상 ‘망신’이 아니라, 다짐의 상징이 되었습니다. “다시는 장애를 허투루 버리지 말자, 다시는 아무것도 배우지 못한 채 빙빙 돌기만 하지 말자.”

1단계: 모든 장애를 ‘학습 자산’으로 취급하라

Ferris Dock의 첫 번째 변화는 ‘마인드셋’이었습니다. 규모와 상관없이, 모든 장애는 시스템과 조직을 개선할 수 있는 기회라는 인식이 자리 잡기 시작했습니다.

이를 위해 다음과 같은 것들을 없앴습니다.

• 책임 추궁 중심의 리뷰
• “사소한” 장애는 넘어가는 문화 (포스트모템 생략)
• “다음엔 더 조심하겠습니다” 같은 모호한 결론으로 회의를 끝내는 방식

대신 그들이 채택한 원칙은 단순했습니다.

사람을 깨웠다면, 그 장애는 반드시 우리에게 무언가를 가르쳐야 한다.

이 원칙을 실제로 적용하기 위해, Ferris Dock는 구조화되고 반복 가능한 포스트모템 프로세스를 만들었습니다.

2단계: 명확하고 반복 가능한 장애 분석 프로세스를 만들라

Ferris Dock의 장애 포스트모템 템플릿은 네 가지 핵심 부분으로 구성되어 있습니다.

1. 사실 기반 타임라인(Factual Timeline)

먼저, 분 단위(또는 단계별)로 무엇이 일어났는지를 나열한 타임라인입니다.

• 문제가 언제 시작되었는지
• 사용자는 무엇을 경험했는지
• 어떤 알람이 울렸는지(또는 울리지 않았는지)
• 누가, 언제, 무엇을 했는지

이 타임라인에는 해석이나 추측이 없습니다. 로그, 알람, 채팅 기록, 배포 기록 등에서 모은 사실만 담습니다.

2. 다중 원인 기반 Root Cause 분석

Ferris Dock는 하나의 **“단일 루트 원인(the root cause)”**을 찾는 대신, 여러 층위의 원인을 함께 살펴봅니다.

• 유발 원인(Triggering causes): 예) 설정 변경, 잘못된 배포
• 기여 원인(Contributing causes): 예) 빠진 알람, 시끄럽기만 한 대시보드, 애매한 런북(runbook)
• 시스템적 원인(Systemic causes): 예) 취약한 아키텍처, 모호한 오너십, 부족한 테스트

이를 위해 5 Whys(5번의 왜) 나 인과관계 트리(causal tree) 같은 분석 기법을 사용하지만, 한 가지 강력한 원칙을 둡니다.

Root cause 분석은 절대 ‘사람’에서 끝나서는 안 된다.

개인을 탓하기 시작하면 그 순간부터 배움은 멈춥니다. Ferris Dock는 다음과 같은 것에 집중했습니다.

• 프로세스의 빈틈
• 도구와 자동화의 한계
• 아키텍처 구조의 취약점
• 커뮤니케이션 실패

3. 구체적이고 추적 가능한 액션 아이템

모든 장애는 규모와 상관없이 우선순위가 매겨진, 짧지만 집중적인 개선 과제 목록으로 이어집니다. 예를 들면:

• 아키텍처 개선: 캐시 추가, 단일 장애 지점 제거 등
• Observability(가시성) 개선: 빠진 메트릭, 깨진 대시보드 수정 등
• 런북 업데이트: 절차 명확화, 에스컬레이션 경로 정비 등
• 가드레일(Guardrail) 추가: 배포 전 체크, 피처 플래그, 자동 롤백 등

각 액션 아이템에는 반드시 다음이 포함됩니다.

• 담당 오너 지정
• 완료 기한 설정
• 기존 업무 관리 시스템(Jira 등)에 등록해 일반 업무와 함께 추적 (어딘가 문서에만 적어두고 잊지 않기)

4. 공유되고 찾기 쉬운 문서화

포스트모템 문서는 결코 묻혀 있지 않습니다. Ferris Dock에서는 이를 다음과 같이 관리합니다.

• 검색 가능하게 인덱싱
• 빠르게 훑어볼 수 있도록 구조화
• 시스템, 서비스, 장애 유형별로 태깅

신입 엔지니어는 온보딩 과정에서 과거 장애 보고서를 읽는 것을 권장받습니다. “네가 직접 같은 고통을 겪기 전에, 이미 겪어 본 사람들의 경험에서 먼저 배워라.”

3단계: 완벽을 설계하지 말고, 실패를 설계하라

골판지 사건이 남긴 진짜 교훈은 “다음에는 이 버그만은 꼭 막자”가 아니었습니다. 훨씬 더 근본적인 메시지였습니다.

시스템은 언젠가 반드시 실패한다. 실패를 예상하고, 실패를 가두고, 쉽게 복구할 수 있도록 설계하라.

Ferris Dock는 아키텍처와 실패 친화적인 설계를 중심으로 선제적인 장애 예방에 투자하기 시작했습니다.

• 중복성과 우아한 강등(Graceful Degradation): 서비스가 완전히 죽는 대신, 일부 기능만 줄어든 상태로라도 동작하도록 설계
• 타임아웃과 폴백(Fallback): 끝없이 로딩만 돌던 요청은 이제 일정 시간 뒤 빠르게 실패하고, 의미 있는 에러 메시지를 반환
• 벌크헤드(Bulkhead)와 Rate Limit: 특정 클라이언트나 기능 하나가 전체 서비스를 끌어내리지 못하도록 격리
• 명확한 오너십: 모든 핵심 컴포넌트에는 책임 팀(Directly Responsible Team)이 명시

예방의 목적은 “위험한 변경은 절대 배포하지 않는다”가 아닙니다. 현실을 인정하는 방식으로 배포하는 것입니다. 네트워크는 끊기고, 디스크는 죽고, 사람은 실수한다는 사실을 전제로 삼는 것입니다.

4단계: 강력한 Observability에 투자하라

이 장애를 통해 Ferris Dock는 자사 대시보드가 보기에는 화려하지만, 실제로는 별로 쓸모 없었다는 사실을 깨달았습니다. 중요한 건 “재미있는 수치”가 아니라 사용자 경험을 진짜로 대변하는 신호였습니다.

Ferris Dock는 Observability 체계를 재구축하면서 세 가지 질문을 기준으로 삼았습니다.

1. 사용자가 화난 이메일을 보내기 전에, 우리가 먼저 문제를 감지할 수 있는가?
2. 메트릭, 로그, 트레이스만 보고도 무슨 일이 일어나는지 이해할 수 있는가?
3. 신속하고 자신 있게 대응할 수 있는가?

구체적으로 그들이 한 일은 다음과 같습니다.

• 주요 서비스별로 골든 시그널(Golden Signals) 구축: 지연(latency), 트래픽(traffic), 에러(errors), 포화도(saturation)
• 사용자 중심 메트릭 추가: CPU 사용률 대신 “분당 성공적인 체크아웃 수” 같은 지표에 집중
• 서비스 전반에 표준화된 구조적 로그(Structured Logging) 도입
• **분산 트레이싱(Distributed Tracing)**을 도입해 마이크로서비스 간 요청 흐름을 가시화

결과적으로 “정체불명 장애(Mystery Outage)”가 줄어들었고, 장애 분석과 초기 트리아지 속도가 크게 빨라졌습니다.

5단계: 카오스 엔지니어링과 SLO로 약점을 미리 찾아라

Ferris Dock는 그동안 자신들이 일종의 “비자발적 카오스 실험”을 운영하고 있었다는 사실을 깨달았습니다. 세상에서는 이것을 그냥 장애라고 부릅니다.

그래서 그들은 의도적인 카오스 실험을 하기 시작했습니다.

카오스 엔지니어링(Chaos Engineering)

통제된 환경에서 Ferris Dock는 다음과 같은 실험을 수행했습니다.

• 인스턴스를 강제로 종료시키기
• 인위적으로 지연(latency) 주입하기
• 네트워크 링크를 끊어 보기
• 의존성 서비스 장애를 시뮬레이션하기

그리고 동시에 다음을 관찰했습니다.

• 시스템이 계속 정상 동작하거나, 최소한 우아하게 성능을 낮추며(degrade gracefully) 버틸 수 있는가?
• 알람은 적절한 시점에 울리는가?
• 런북은 실제로 엔지니어의 빠른 대응에 도움이 되는가?

카오스 실험에서 발견한 실패는, 고객이 먼저 발견한 실패보다 훨씬 덜 고통스럽습니다.

SLO: 서비스 수준 목표(Service Level Objectives)

Ferris Dock는 신뢰성에 대한 기대치를 수치로 표현하기 위해 **SLO(Service Level Objective)**도 정의했습니다. 예를 들어:

• “체크인 API 요청의 99.9%는 30일 기준 500ms 이내에 성공적으로 완료되어야 한다.”

SLO를 추적하면서 그들은 다음을 할 수 있게 되었습니다.

• 개별 장애가 아니라 장기적인 신뢰성 추세를 파악
• 언제 신뢰성 개선을 기능 개발보다 우선해야 할지 판단
• 포스트모템 이후의 개선 조치가 실제로 효과가 있는지 측정

6단계: 지속 학습 문화를 만들어라

기술적인 변화만으로는 충분하지 않았습니다. Ferris Dock에는 문화적인 전환이 필요했습니다.

그들은 다음과 같은 실천을 통해, 크고 작은 모든 장애가 신뢰성 향상으로 이어지도록 만들었습니다.

• 블레이멀리스 포스트모템(Blameless Postmortem): 개인이 아니라 시스템 설계에 집중
• 정기적인 장애 리뷰 미팅: 각 팀이 최근 장애를 함께 훑어보는 짧고 반복적인 세션
• 심리적 안전(Psychological Safety) 확보: 아슬아슬하게 넘어간 사건, “운 좋게 안 터진” 약점, 불안 요인을 엔지니어가 편하게 제기하도록 장려
• 영웅담이 아니라 ‘수리’와 ‘예방’을 칭찬: 새벽에 불 끄러 뛰어든 영웅보다, 그런 일이 없도록 조용히 개선한 사람을 드러내고 인정

회의실 벽에 걸린 골판지 사진은 늘 같은 메시지를 상기시켜 줍니다.

학습하지 않은 비용은 고스란히 사용자들이 대신 치른다.

7단계: 사용자에게 투명하게 소통하라

골판지 사건이 남긴 또 하나의 뼈아픈 교훈은, 사용자들이 너무 오랫동안 상황을 알 수 없었다는 점이었습니다. 사용자들은 다음을 전혀 확신할 수 없었습니다.

• 시스템이 완전히 내려갔는지, 단순히 느린 것인지
• 자신의 데이터는 안전한지
• 다시 시도해야 할지, 기다려야 할지

더 나쁜 일도 벌어졌습니다. 혼란을 틈탄 피싱 공격이 등장한 것입니다. 사기꾼들이 Ferris Dock 지원팀을 사칭해 고객에게 메일을 보내, 계정 정보를 요구하기 시작했습니다.

Ferris Dock는 이에 대응하여 장애 커뮤니케이션 전략을 공식화했습니다.

• 실시간 상태 페이지: (조사 중, 원인 파악, 모니터링 중, 해결됨 등) 명확한 장애 상태 단계와 함께 수시 업데이트
• 쉬운 언어로 된 안내문: 예) “예약 페이지에서 로딩이 길어질 수 있습니다. 데이터는 안전하게 보관되고 있습니다.”
• 장애 중·이후에 반복해서 제공하는 보안/피싱 주의 안내:
  • “우리는 이메일이나 채팅으로 비밀번호나 2FA 코드를 요구하지 않습니다.”
  • “장애와 관련한 수상한 메일이나 메시지를 받으시면 security@… 로 전달해 주세요.”
• 장애 종료 후 제공하는 사후 보고(Post-Incident Summary):
  • 무슨 일이 있었는지(비전문가도 이해할 수 있는 수준으로)
  • 어떤 영향이 있었는지
  • 다시 발생하지 않도록 무엇을 하고 있는지

이런 투명한 소통 덕분에, 장애는 단순한 부정적인 사건이 아니라, 솔직함과 책임감을 통해 신뢰를 쌓는 기회가 되었습니다.

마무리: 모든 것을 하나로 묶으면

골판지 사건은 Ferris Dock에게 “잘못된 배포 하나”만 알려준 것이 아니었습니다. 그보다는 신뢰성에 대한 이들의 사고방식을 통째로 바꿔 놓았습니다.

• 장애는 숨겨야 할 흑역사가 아니라, 학습 자산이 되었습니다.
• 포스트모템은 책임 추궁 자리가 아니라, 구조화된 실행 계획의 출발점이 되었습니다.
• 아키텍처는 실패를 부정하는 대신, 실패를 전제로 설계되기 시작했습니다.
• Observability는 성숙해져, 엔지니어가 빠르게 문제를 보고 이해하고 해결할 수 있게 되었습니다.
• 카오스 엔지니어링과 SLO는 고객에게 피해가 가기 전에 약점을 드러내 주었습니다.
• 문화는 지속 학습·안전·책임을 향해 이동했습니다.
• 사용자 커뮤니케이션은 한층 투명해졌고, 상태 공유뿐 아니라 보안과 피싱 주의까지 포함하게 되었습니다.

내부 워룸에 걸린 그 골판지 안내판은 이제 실패의 상징이 아닙니다. 대신 하나의 다짐을 상기시키는 상징입니다.

장애는 언제나 일어난다. 빙빙 도는 건 선택이지만, 배우지 않는 건 선택이 아니다.

여러분의 조직이 아직도 장애 때마다 그저 ‘빙빙 돌고’만 있다면, Ferris Dock의 이야기에서 한 장만 빌려 가도 좋습니다. 아주 작은 것부터 시작해 보세요. 포스트모템 한 번을 구조화해서 진행해 보고, SLO 하나를 정의해 보고, Observability의 빈 구석 하나를 메우는 것만으로도 충분합니다.

그리고 그 이후에 일어나는 모든 장애—크든 작든—가 여러분을 조금씩 더 탄탄하고, 신뢰할 수 있고, 사용자가 안심하고 맡길 수 있는 시스템으로 이끌도록 만드세요.