포스트잇 플라이트 데크: 손으로 쓴 ‘비행 계획’ 벽으로 인시던트 커맨드 운영하기
항공 분야의 Threat and Error Management(TEM) 모델과 SRE 신뢰성 원칙을 바탕으로, 포스트잇으로 만든 저기술·고가시성 ‘플라이트 데크’가 어떻게 인시던트 커맨드를 바꾸고, 토일을 줄이며, 대규모 장애 복구를 가속할 수 있는지 살펴봅니다.
포스트잇 플라이트 데크: 손으로 쓴 ‘비행 계획’ 벽으로 인시던트 커맨드 운영하기
치명적인 시스템이 다운되면 대부분의 팀은 본능적으로 더 많은 도구를 찾습니다. 대시보드, 챗옵스, 런북, 티켓 시스템, 페이징 플랫폼, 워 룸, 상태 페이지, 끝없이 열린 브라우저 탭까지. 하지만 가장 크고 스트레스가 큰 인시던트일수록, 이 모든 기술이 점점 소음처럼 느껴지기 시작합니다.
만약 더 나은 인시던트 커맨드의 열쇠가 ‘더 많은 도구’가 아니라, 손으로 쓴 포스트잇으로 빼곡한 저기술·고시각성 “플라이트 데크” 벽이라면 어떨까요? 인시던트를 위한 실제 “비행 계획”들을 손글씨로 적어 붙여놓은 보드 말입니다.
항공 분야의 Threat and Error Management(TEM) 모델과 핵심 Site Reliability Engineering(SRE) 실천을 차용하면, 화이트보드와 포스트잇 같은 단순한 도구만으로도 적응적이고 회복력 있는 인시던트 관리를 운영할 수 있습니다. 물론, 뒤에서는 여전히 현대적인 도구들과 통합된 상태로 말이죠.
이 글에서는 포스트잇 플라이트 데크가 어떻게 할 수 있는지 살펴봅니다.
- 인지 부하와 조정(toil) 업무를 줄이고
- 압박 상황에서 공통 상황 인식(shared situational awareness)을 높이며
- 빠르게 변하는 환경에서도 구조화된, 반복 가능한 워크플로를 녹여내고
- 2023–2025년에 우리가 수없이 봐온 것 같은 대규모 장애에서 더 빨리 복구하도록 돕는 방법
왜 요즘 인시던트는 점점 더 어렵게 느껴질까
2023–2025년 동안 우리는 헤드라인을 장식하는 크고 작은 장애들을 봐왔습니다. 전 세계 항공사 마비, 클라우드 사업자 인시던트, DNS 장애, CDN 문제, 시간당 수백만 달러 손실을 야기한 핀테크·리테일 다운타임까지. 패턴은 분명합니다.
- 시스템은 더 복잡해졌습니다. 마이크로서비스, 분산 데이터, 피처 플래그, CI/CD, 멀티 클라우드는 모두 잠재적인 장애 모드를 층층이 쌓습니다.
- 변화 속도는 더 빨라졌습니다. 하루에 수십, 많게는 수백 번의 배포가 일어나며, 지금 디버깅하는 시스템은 어제 존재하지 않았을 가능성이 큽니다.
- 의존성은 더 깊고 더 불투명해졌습니다. 서드파티 API, SaaS 플랫폼, 인프라 제공업체는 우리가 직접 통제하기 어려운 취약한 연결 고리를 도입합니다.
전통적인 선형 인시던트 프로세스와 툴 중심 접근 방식은 이런 속도를 따라가기 어렵습니다. 지금 필요한 것은, 다음을 만족하는 적응형 인시던트 매니지먼트입니다.
- 변화하는 컨텍스트를 빠르게 인지하고,
- 수많은 사람과 도구를 혼돈 없이 조율하며,
- 비난과 허구의 ‘확실성’보다 학습과 회복력에 초점을 두는 것.
여기서 항공 분야의 Threat and Error Management 철학과 의도적으로 단순한 시각적 시스템이 빛을 발합니다.
조종석에서 컨트롤 룸까지: Threat and Error Management(TEM)
항공 산업은 수십 년에 걸쳐, 사람이 어떻게 복잡하고 고위험 시스템을 관리하는지 다듬어 왔습니다. 그 핵심 프레임워크 중 하나가 바로 Threat and Error Management(TEM) 입니다. 요약하면 다음과 같습니다.
- 위협(Threat) 을 문제가 되기 전에 예상하고,
- 에러(Error) 가 발생하면 최대한 일찍 포착하며,
- 원치 않는 상태(Undesired state) 에서 빠르게 회복한다.
이걸 SRE와 인시던트 대응에 적용해 보면:
- 위협(Threat) 은 장애 확률을 높이는 조건입니다. (예: 고부하, 최근 켜진 피처 플래그, 성능이 저하된 클라우드 리전)
- 에러(Error) 는 의도와 다른 결과를 낳는 사람 또는 시스템의 행동입니다. (예: 잘못된 설정, 불완전한 롤아웃, 빠진 알림 커버리지)
- 원치 않는 상태 는 실제 사용자들이 체감하는 장애와 성능 저하입니다.
TEM은 “에러를 시스템에서 완전히 제거할 수 있다”고 가정하지 않습니다. 오히려 이렇게 전제합니다.
에러는 필연적이다. 중요한 것은 얼마나 빨리 그것을 발견하느냐, 그리고 얼마나 효과적으로 회복하느냐 다.
이 사고방식은 SRE 팀이 실제로 겪는 현실과 자연스럽게 맞닿아 있습니다. 그리고 인시던트 중에 우리가 “단 하나의” 근본 원인(root cause)을 찾는 데 집착하기보다, 다음에 집중해야 함을 시사합니다.
- 위협을 더 일찍 드러내고
- 에러를 더 쉽게 포착하며
- 복구 절차를 빠르고, 안전하고, 반복 가능 하게 구조화하는 것
플라이트 데크를 고정하는 7가지 핵심 SRE 신뢰성 질문
빠르게 전개되는 인시던트 상황에서는 철학적 논쟁을 할 시간이 없습니다. 필요한 건 행동을 이끄는, 작고 믿을 만한 질문 세트입니다.
플라이트 데크 벽 상단에 그대로 붙여둘 수 있는 7가지 SRE 신뢰성 질문은 다음과 같습니다.
-
무엇이, 누구에게, 어떻게 망가졌는가?
구체적으로 말합니다. 어떤 사용자 플로우, 어떤 리전, 어떤 테넌트, 어떤 SLI가 영향을 받는가? -
얼마나 심각하고, 얼마나 빠르게 변화하고 있는가?
에러율은 안정적인가, 개선 중인가, 악화 중인가? 지금 SLO를 실제로 위반하고 있는가, 아니면 위반을 향해 가고 있는가? -
사용자 영향도를 줄이기 위한, 가장 안전하고 가장 빠른 경로는 무엇인가?
아직 “모두 고치기”가 아닙니다. 우선은 “출혈을 멈추는 것”입니다. 피처 킬 스위치? 롤백? 트래픽 라우팅 변경? -
우리는 시스템이 지금 어떻게 동작한다고 ‘믿고’ 있으며, 어디에서 가장 확신이 부족한가?
지식 공백을 식별합니다. 그곳이 바로 탐색과 계측이 필요한 지점입니다. -
다음으로 실행할 수 있는 실험이나 액션은 무엇이며, 그 위험도는 어떤가?
가설 기반 대응(hypothesis-driven response)을 하되, 명시적으로 블라스트 레이디우스(영향 범위)를 평가합니다. -
사람과 도구 사이의 작업을 어떻게 조율하고 있는가?
누가 무엇을 책임지는가? 중복 작업을 어떻게 피하는가? 지금 이 순간의 단일 진실 공급원(single source of truth)은 어디인가? -
향후 토일과 영향도를 줄이기 위해, 이번 인시던트에서 반드시 배워야 할 것은 무엇인가?
단순한 “루트코즈”가 아니라, 조건(conditions) 과 패턴(patterns) 에 집중합니다. 알림 품질, 런북의 빈틈, 위험한 디폴트값 등.
이 질문들은 SRE 사고방식을 잘 담고 있으면서도, 지나치게 경직된 선형 템플릿에 가두지 않습니다. 플라이트 데크를 위한 하나의 항법 장치(navigation aid), 즉 정신적 체크리스트에 가깝습니다.
포스트잇 플라이트 데크: 저기술 컨트롤 타워
그렇다면 “포스트잇 플라이트 데크”는 실제로 어떤 모습일까요?
물리적 혹은 가상 공간에 명확히 라벨링된 레인(열) 이 나뉘어 있는 벽을 떠올려 보세요. 각 포스트잇은 하나의 작은, 추적 가능한 “비행 계획(flight plan)”입니다. 하나의 작업, 결정, 혹은 가설을 나타냅니다.
예를 들어, 벽을 다음과 같은 컬럼으로 나눌 수 있습니다.
-
Incoming Signals(들어오는 신호)
새 알림, 사용자 제보, 서드파티 상태 변경. 각 노트에는 다음을 적습니다: 출처, 시간, 1차 평가. -
Threats & Constraints(위협과 제약)
최근 배포, 이미 알려진 리스크 컴포넌트, 용량 우려, 메인터넌스 윈도, 벤더 이슈 등. -
Active Flights (진행 중 작업)
각 노트는 명확히 범위가 정의된 태스크 혹은 실험입니다.- “리전 A에서 서비스 X를 버전 1.2.3으로 롤백”
- “피처 플래그 Y를 전체 사용자 100%에 대해 비활성화”
- “서비스 Z 재시작 전 로그 캡처”
-
Decisions & Checkpoints(결정과 체크포인트)
핵심 결정을 기록하는 노트입니다.- “에러율이 빠르게 증가해, 카나리 대신 롤백 선택”
- “DB 팀으로 에스컬레이션; 온콜 DBA 호출 완료”
-
Mitigations & Recoveries(완화 조치 및 복구)
사용자 영향도를 줄인 액션들입니다.- “비핵심 API 호출을 30% 레이트 리미팅”
- “배치 작업을 비피크 시간대로 이동”
-
Follow-Up & Learning(후속 조치와 학습)
사후 분석, 런북 업데이트, 알림 튜닝, 아키텍처 개선 작업 등.
이 보드는 인시던트의 공유된 두뇌(shared brain) 가 됩니다. 방에 막 들어온 사람(혹은 원격에서 가상 보드에 접속한 사람) 누구든 바로 다음을 파악할 수 있습니다.
- 지금 무슨 일이 벌어지고 있는지
- 지금까지 무엇을 시도했는지
- 우리가 시스템이 어떻게 동작한다고 ‘생각’하는지
- 어디에 가장 큰 불확실성과 리스크가 있는지
극도의 스트레스 상황에서는, 이런 시각적·촉각적 접근이 개개인의 “영웅적인 기억력”에 대한 의존을 줄여줍니다. 또한 새로운 대응자가 합류하는 데 필요한 온보딩 시간을 크게 단축합니다.
왜 고스트레스 상황에서는 하이테크보다 로우테크가 유리할까
툴링은 가시성과 자동화를 위해 필수적입니다. 하지만 강도 높은 장애 상황에서는, 하이테크 인터페이스가 탭과 필터, 스크롤되는 로그 속에 중요한 정보들을 숨겨버리기도 합니다.
포스트잇 플라이트 데크는 다음과 같은 장점을 가집니다.
-
급진적인 가시성(Radical visibility)
모든 것이 한곳에 있습니다. “최신 상태가 어디에 있지?”, “누가 뭘 하고 있지?” 같은 질문을 할 필요가 없습니다. -
공유된 상황 인식(Shared situational awareness)
벽은 모든 사람에게 동시에 정보를 전달합니다. 논의를 고정(anchor)시키고, 오해와 불일치를 줄입니다. -
인지 부하 감소(Lower cognitive load)
물리적 아티팩트(또는 잘 설계된 가상 보드)는 기억을 외부로 꺼내어 줍니다. 대응자는 기억하느라 애쓸 필요 없이 ‘생각’하는 데 집중할 수 있습니다. -
구조화된, 반복 가능한 워크플로(Structured, repeatable workflow)
레인과 노트 포맷 자체가 워크플로를 내포합니다. 상황에 따라 즉흥적으로 조정하더라도, 항상 “기본적으로 따를 수 있는 길(default way)”이 존재합니다. -
유연성과 속도(Flexibility and speed)
포스트잇 하나 만드는 데 몇 초면 됩니다. 옮기거나 없애는 것도 마찬가지입니다. 스키마 변경도, 권한 문제도 없습니다.
중요한 점은, 플라이트 데크가 기존 도구를 대체하는 것이 아니라는 것입니다. 오히려 도구들을 오케스트레이션(orchestrate) 합니다.
- 각 노트는 관련 런북, 그래프, 알림 ID를 참조할 수 있습니다.
- 보드에 기록된 액션은 나중에 티켓이나 리포트로 동기화할 수 있습니다.
- 모니터링·관측(Observability) 플랫폼은 “Incoming Signals”를 채우고, 결정과 맥락은 벽 위에 남습니다.
토일 줄이기와 ‘루트코즈’의 재정의
SRE에서 자주 나오는 개념이 토일(toil) 입니다. 시스템 규모에 비례해 선형으로 증가하면서, 장기적인 가치가 거의 없는 반복적·수동적 작업을 의미합니다. 관리되지 않은 인시던트에는 토일이 가득합니다.
- 새로 합류한 대응자에게 상황을 매번 처음부터 설명하는 일
- 동일한 위험한 수동 작업을 인시던트마다 다시 반복하는 일
- 뒤늦게 타임라인을 재구성하기 위해 애매한 채팅 로그를 파고드는 일
- 복잡한 사회-기술 시스템에서 “진짜” 루트코즈를 찾겠다며 헤매는 일
구조화된 플라이트 데크는 이런 토일을 정면으로 줄여줍니다.
- 컨텍스트가 보드 한곳에 집중 되어, 같은 설명을 반복할 필요가 줄어듭니다.
- 반복 가능한 워크플로(예: 표준 완화 플레이북)를 카드나 템플릿 형태로 보드에 박아둘 수 있습니다.
- 연대기(Chronology) 가 시각적으로 드러납니다. 신호 → 액션 → 완화 → 후속 조치로 노트가 이동하면서 자연스러운 타임라인이 만들어집니다.
그리고 루트코즈(root cause) 에 관해서도 짚고 넘어가야 합니다. 큰 인시던트는 깔끔하게 하나로 떨어지는 원인을 갖는 경우가 거의 없습니다. 대신 다음과 같은 조건들이 겹겹이 쌓여 나타나곤 합니다.
- 위험한 배포
- 빠졌거나 시끄러운(noisy) 알림
- 취약한 의존성
- 시간 압박을 받는 과부하 팀
플라이트 데크는 팀이 “단 하나의 루트코즈가 무엇인가?”에서 벗어나, “주요 기여 요인이 무엇이었고, 앞으로 토일과 영향을 줄이기 위해 어떤 조건들을 바꿔야 하는가?” 로 시선을 옮기도록 돕습니다.
후속 조치 노트는 비난(blame)이 아니라, 다음에 초점을 맞춰야 합니다.
- 더 나은 가드레일 (예: 더 안전한 디폴트, 사전 점검(pre-flight check))
- 더 나은 가시성 (예: 더 풍부한 알림, 더 나은 대시보드)
- 더 적은 수동 단계 (예: 자동화, 더 안전한 롤백 메커니즘)
실제로 도입하기: 우리만의 플라이트 데크 시작하기
대단한 프로그램이 필요하지 않습니다. 필요한 것은 다음뿐입니다.
- 모든 인시던트 참여자가 볼 수 있는 물리적 또는 가상 보드
- 팀의 워크플로를 표현하는, 작지만 안정적인 레인(컬럼) 세트
(앞서 예로 든 구조처럼 시작해도 좋습니다.) - 가벼운 포스트잇 템플릿 예를 들면:
- 태스크 노트: 액션, 오너, ETA, 리스크 레벨, 증거 링크
- 신호 노트: 출처, 영향, 발생 시각, 신뢰도(확신 수준)
- 결정 노트: 선택한 옵션, 고려했던 대안, 선택 이유
- 지정된 인시던트 커맨더(Incident Commander, IC)
이 사람은:- 인시던트 동안 보드를 책임지고
- 변경 사항을 소리 내어(혹은 채널에) 계속 내레이션하며
- 진행 중 작업 수를 제한해 팀이 분산되지 않게 합니다.
- 짧은 회고(레트로) 의식
여기에서:- 보드를 왼쪽에서 오른쪽으로 훑어보며
- 예상하지 못한 위협이 어디에 있었는지
- 에러가 일찍 포착되지 못한 지점은 어디였는지
- 학습 중심의 후속 과제를 정리합니다.
시간이 지나면서 다음을 시도해 볼 수 있습니다.
- 팀이 실제로 하는 일에 맞춰 레인과 노트 패턴을 조정
- 디지털 도구와의 통합: 노트를 티켓과 동기화하고, 인시던트 타임라인과 연결
- 레인별 체류 시간, 버려진 태스크 개수 같은 보드 메트릭을 활용해 프로세스를 개선
결론: 회복력은 ‘제품’이 아니라 ‘연습’이다
2023–2025년의 대규모 장애들은 하나의 불편한 진실을 다시 확인시켜 줍니다. 우리는 툴만으로 복잡성을 이겨낼 수 없다 는 사실입니다. 대시보드, AIOps, 자동화는 중요하지만, 다음을 대체할 수는 없습니다.
- 명확하고 적응적인 인시던트 커맨드
- 스트레스 상황에서의 공통 상황 인식
- 사람 중심으로 설계된 사려 깊은 워크플로
포스트잇 플라이트 데크 는 언뜻 보기엔 매우 단순해 보이지만, 그 뒤에는 정교한 사고방식이 자리하고 있습니다.
- 항공의 Threat and Error Management 를 바탕으로, 위협을 예상하고(anticipate), 에러를 포착하며(trap), 빠르게 회복(recover)하는 프레임을 가져오고,
- 허구의 단일 루트코즈를 쫓기보다 7가지 핵심 SRE 신뢰성 질문을 중심에 두며,
- 시각적이고 저기술인 도구 로 구조화된, 반복 가능한 워크플로를 구현해 토일을 줄이고 해결 속도를 높입니다.
회복력(resilience)이란 결코 실패하지 않는 능력이 아닙니다. 실패가 언젠가 반드시 찾아왔을 때, 어떻게 대응하고(coordination), 어떻게 함께 움직이며(communication), 무엇을 배우느냐(learning) 의 문제입니다.
어쩌면 인시던트 매니지먼트를 진짜로 업그레이드하는 것은 더 많은 화면이 아니라, 모두가 함께 같은 비행기를 조종하고 있다는 감각을 주는 하얀 벽, 마커, 그리고 포스트잇 더미일지도 모릅니다.