아날로그 인시던트 스토리 온실 랜턴: 내일의 장애를 조용히 막아 주는 손글씨 밤 노트

새벽 3시의 운영실에는 특유의 정적이 흐릅니다.

모니터는 희미하게 빛나고, 대시보드는 각종 그래프와 빨간·노란·초록 지표로 웅웅거립니다. 다행히도 알림은 잠시 조용해진 상태. 어디선가 한 명의 지친 엔지니어가 교대를 끝내기 전에 종이에 몇 줄을 휘갈깁니다.

“데이터베이스 노드 3가 01:07–01:12 사이에 두 번 플랩(flapped) 발생. 결제(Checkout) 서비스 에러율 상승, 원인 조사 중, 캐시 압박 의심. 아직 고객 영향 없음. 페이저 설정 확인 완료. 다음 단계는 이 페이지 뒷면 참고.”

이 손글씨 메모 한 장. 어쩌면 이것이 바로 여러분 팀의 **온실 랜턴(greenhouse lantern)**일 수 있습니다. 눈에 잘 띄진 않지만, 작고 아날로그한 빛 하나가 인시던트가 터지기도 전에 내일의 안정성을 조용히 지켜 주는 셈이죠.

이 글은 이런 “밤 노트(night notes)”가 현대적인 인시던트 관리와 어떻게 연결되는지에 대한 이야기입니다. 온콜(On-call) 인수인계, 런북(runbook), Jira Service Management, 그리고 회복탄력성을 좌우하는 조용한 루틴들까지 함께 살펴보겠습니다.

메이저 인시던트 관리는 생각보다 복잡할 필요가 없다

많은 팀이 “정식” 인시던트 관리 프로세스를 만들기를 주저합니다. 몇 달짜리 프로세스 설계와 툴 커스터마이징이 필요하다고 생각하기 때문입니다. 꼭 그럴 필요는 없습니다.

Jira Service Management 같은 현대적인 플랫폼을 사용하면 다음과 같은 일을 쉽게 시작할 수 있습니다.

기본 제공 워크플로우로 메이저 인시던트 프로세스를 바로 구성
표준화된 인시던트 유형, 우선순위, SLA 사용
별도 커스텀 통합 없이 모니터링 도구로부터의 알림 연동
기본 템플릿으로 사후 인시던트 리뷰(Post-Incident Review) 시작

제대로 동작하는 메이저 인시던트 프로세스는 분기 단위가 아니라 며칠이면 가동할 수 있습니다. 이게 중요한 이유는, 대응 체계를 공식화할수록 “개인의 기억”과 “영웅적인 헌신”에 덜 의존하게 되기 때문입니다.

하지만 여기에는 함정이 하나 있습니다. 좋은 툴은 인시던트 “진행”을 훨씬 매끄럽게 만들어 주지만, 여전히 큰 취약 지점을 남겨둘 수 있습니다. 바로 교대가 바뀌는 순간입니다.

신뢰성이 조용히 무너지는 지점: 인수인계의 공백

인시던트는 예고하고 찾아오지 않습니다. 대개 이런 타이밍에 등장합니다.

교대가 끝나기 바로 직전
복잡한 원인 분석이 한창일 때
신규 배포가 절반쯤 적용된 상태에서

구조화된 온콜 인수인계 프로세스가 없다면 팀은 이런 문제를 겪기 쉽습니다.

맥락 상실: 다음 엔지니어가 이미 알아낸 내용을 다시 처음부터 파악해야 함
인시던트 누락: 알림이나 티켓이 교대 경계에서 통째로 빠져버림
지식 손실: 미묘한 단서, 직관, 부분적인 조사 결과들이 공중분해됨

툴이 아무리 좋아도, 인수인계 방식이 사실상 “뭔가 터지면 슬랙으로 연락해” 수준이라면 이야기를 쉽게 놓치게 됩니다.

이때 등장하는 것이 바로 온실 랜턴 같은 아날로그 습관입니다. 명확하고, 사람 눈으로 읽기 좋고, 오래 남는 메모를 남겨 다음 사람을 안내하는 습관 말입니다.

믿을 수 있는 온콜 인수인계 설계하기

좋은 인수인계는 거창할 필요는 없지만, 의도적으로 설계되어야 합니다. 최소한 다음 세 가지는 갖춰야 합니다.

충분한 문서화
교대 간 오버랩(겹치는) 시간
명시적인 커뮤니케이션 규칙

1. 충분한 문서화: 밤 노트(Night Notes)

인수인계 노트를 “지난 교대의 이야기”라고 생각해 보세요. 대신, 이것을 읽게 될 사람은 반쯤 잠이 덜 깬 상태에서, 인시던트 한가운데에 투입된 사람입니다. 그러니 다음 내용을 담는 것이 좋습니다.

진행 중인 인시던트
- 무엇이 발생했는지
- 현재 상태
- 지금까지 시도한 것들
- 어떤 가설이 유력/비유력해 보이는지
위험 및 관찰 포인트(Watchpoint)
- “서비스 X 에러율은 정상 범위지만 점진적으로 상승 중”
- “리전 Y에서 축소된 중복 구성으로 운영 중”
대기 중인 액션
- “06:00 배치 작업 이후 페일오버 상태 정상 여부 확인 필요”
- “네트워크 이슈 관련 벤더 답변 대기 중”

이 기록을 Jira Service Management의 인시던트 티켓에 남겨도 좋고, 운영 콘솔 옆 종이에 적어도 상관 없습니다. 중요한 것은 항상 같은 방식으로 작성되고, 나중에 쉽게 찾을 수 있어야 한다는 점입니다.

간단한 템플릿 하나만 있어도 큰 도움이 됩니다.

HANDOFF NOTES – [날짜] [교대]

1) 진행 중인 인시던트
- 인시던트 ID / 링크:
- 요약:
- 현재 상태:
- 지금까지의 조치:
- 다음 단계:
- 주의 깊게 볼 것:

2) 인지된 위험(아직 인시던트는 아님)
- 위험 내용:
- 왜 중요한지:
- 무엇을 모니터링할지:

3) 완료된 운영 점검
- 알림 확인 여부:
- 대시보드 점검 여부:
- 접근(Access) 확인 여부:

2. 오버랩 시간: 교대 사이의 공유된 빛

교대 간 공백 시간이 0분이라면, 맥락이 사라지는 것은 거의 필연적입니다. 15–30분 정도의 오버랩 시간만 있어도 다음과 같은 일이 가능합니다.

현재 인시던트를 실시간으로 함께 훑어보기
헷갈리는 노트를 직접 물어보고 바로 정리하기
툴에는 남기 힘든 “감(直感)”과 미묘한 정황을 말로 전하기

이 오버랩 동안에는, 나가는 사람을 “해설자”, 들어오는 사람을 “적극적인 청자”로 설정하는 것이 좋습니다.

나가는 사람: “지금 이런 상황이고, 내가 보기에는 이런 원인이 유력해 보여요.”
들어오는 사람: “제가 이해한 건 이렇습니다. 그래서 다음엔 이렇게 진행할게요.”

이 짧은 대화 하나가, 정적인 텍스트를 **공유된 이해(shared understanding)**로 바꿔 줍니다.

3. 명시적인 커뮤니케이션 규칙

언제, 어떤 방식으로 인수인계를 해야 하는지 애매하지 않게 정해 두어야 합니다.

채널: “모든 인수인계는 #oncall-handoff 슬랙 채널과 인시던트 티켓에 남긴다.”
타이밍: “교대 종료 최소 30분 전까지 인수인계 노트를 업데이트한다.”
에스컬레이션: “P1 또는 P0 인시던트가 진행 중일 때는 반드시 실시간(콜)으로 인수인계를 진행한다.”

이 규칙들을 문서화하세요. 런북과 온보딩 자료에 포함시키고, 새 인원이 들어오면 항상 이 부분을 훈련하세요. 특히 피곤한 상태에선 즉흥 대응보다 **의식적인 의례(ritual)**가 훨씬 안전합니다.

검증(Verification): 대부분의 팀이 건너뛰는 부분

인수인계는 노트를 “작성”했다고 끝나는 것이 아닙니다. 받는 사람이 실제로 운영 가능한 상태가 되었을 때 비로소 완료됩니다.

모든 인수인계에 다음 검증 단계를 포함해 보세요.

이해 내용 확인
- 들어오는 엔지니어가 요약해서 말하게 합니다.
  - 예: “지금 결제 서비스에 캐시 압박으로 보이는 간헐적 장애가 있고, 아직 고객 영향은 없으며, 제가 다음으로 해야 할 일은 … 이 맞죠?”
접근 권한 확인
- 새 온콜 담당자가 다음에 모두 접근 가능한지 확인합니다.
  - VPN / 베스천(bastion) 접속
  - Jira Service Management, 모니터링, 로그 툴 접근
  - 재기동, 페일오버 등 필요한 조치를 실행할 수 있는 권한
알림 체계 점검
- 가능하다면 테스트 알림을 발생시키거나 기존 설정을 검증합니다.
- 페이저와 알림이 올바른 디바이스와 채널로 전달되는지 확인합니다.

이 과정이 다소 절차적으로 느껴질 수 있습니다. 하지만 이런 체크리스트 방식의 사고가, 예상치 못한 장애 상황에서 여러분의 온실 랜턴이 꺼지지 않게 만드는 힘입니다.

런북: 어둠 속을 위한 템플릿 기반 지도

인수인계가 사람과 사람 사이에 “이야기”를 넘기는 일이라면, **런북(runbook)**은 그 사람들에게 건네는 “지도”입니다.

좋은 인시던트 대응 런북의 특징은 다음과 같습니다.

템플릿 기반 — 매번 새로운 변종 인시던트가 나올 때마다 처음부터 만들지 않도록
구체적인 예시 포함 — 실제 명령어, 실제 스크린샷, 실제 로그 예시
**MTTA(Mean Time to Acknowledge, 인지까지의 평균 시간)**와 MTTR(Mean Time to Resolve, 복구까지의 평균 시간) 모두를 다룸

실제 운영에서 런북은 다음 두 단계를 도와야 합니다.

탐지 & 트리아지(Detection & Triage, MTTA)
- “시스템 Y에서 알림 X를 받으면, 5분 이내에 Z를 수행한다.”
진단 & 복구(Diagnosis & Repair, MTTR)
- “DB 커넥션이 포화 상태라면, 다음 명령어를 실행해 보고, 이 대시보드를 확인하고, 아래 순서대로 조치한다.”

런북과 인수인계를 연결하기

런북을 교대 간의 공통 언어로 사용해 보세요. 인수인계 노트에서 런북을 직접 참조하는 식입니다.

“DB-02: Read Replica Latency 런북을 기준으로 진행 중이며, 현재 4단계까지 완료.”
“패킷 손실이 계속되면 NET-07: VPN Degradation 런북의 다음 단계를 진행해 주세요.”

이런 식이면, 새로 온 온콜 담당자는 아무 맥락도 모른 채 수사를 다시 시작해야 하는 탐정에서, 잘 구조화된 소설의 6장을 이어 읽는 독자로 바뀝니다.

또한 Jira Service Management 내에서 인시던트 티켓에 런북 링크를 직접 걸어 두면, 맥락·이력·절차가 한 곳에 모여 있게 됩니다.

회복탄력성 구축: 예측 가능하고, 반복 가능한 대응

회복탄력성(resilience)은 단순히 “얼마나 빨리 고치는가”의 문제가 아닙니다. 인시던트가 예고 없이 찾아왔을 때, 얼마나 예측 가능한 방식으로 대응하는가의 문제이기도 합니다.

잘 설계된 런북과 인수인계 노트는 다음과 같은 효과를 줍니다.

예측 가능성 – 비슷한 유형의 인시던트는 비슷한 흐름으로 대응
반복 가능성 – 팀 어느 누구나 같은 플레이북을 실행 가능
인지 부하 감소 – 온콜 엔지니어가 “프로세스를 어떻게 밟아야 할지”가 아니라 “인시던트 자체를 어떻게 이해하고 해결할지”에 집중

여기에 Jira Service Management의 기본 제공 인시던트 관리 기능을 더하면, 다음을 이룰 수 있습니다.

메이저 인시던트 프로세스를 빠르게 구축
여러 팀 간 인시던트 대응 방식을 표준화
작은 장애가 대형 서비스 중단으로 번지는 예상치 못한 사고를 줄이기

손글씨 메모, 짧은 오버랩 시간, 체크리스트형 검증 같은 것들은 겉으로 보기엔 매우 단순하고 조용한 습관에 불과합니다. 하지만 시간이 지날수록 실제 고객 피해를 줄이는 데 결정적인 역할을 합니다.

모두 연결하기: 지금 당장 할 수 있는 다음 단계

여러분 팀의 온실 랜턴에 불을 밝히는 일은, 거창한 프로그램이 필요하지 않습니다. 다음 세 가지 작은 실천부터 시작해 보세요.

기본 메이저 인시던트 워크플로우를 활성화하세요.
- Jira Service Management나 사용 중인 툴에서 기본 템플릿을 활용하고, 처음부터 과도하게 설계하려 들지 마세요.
가벼운 인수인계 템플릿을 만들고, 모든 온콜 교대에 이를 의무화하세요.
- 작성하기 쉽고, 나중에 누구나 쉽게 찾을 수 있도록 하는 것이 핵심입니다.
표준 인수인계 의식(ritual)을 정의하고 연습하세요.
- 15–30분 오버랩
- 진행 중인 인시던트가 있을 경우, 작성된 노트 + 실시간(콜) 인수인계 병행
- 이해 내용, 접근 권한, 알림 설정을 반드시 검증

그다음, 팀에서 가장 자주 반복되는 인시던트 유형 상위 5개에 대해 템플릿 기반 런북을 작성하세요. 모든 인시던트 티켓과 인수인계 노트에서 이 런북을 참조하도록 만듭니다.

시간이 지나면 이런 변화들을 체감하게 될 것입니다.

“원인을 도저히 모르겠는 미스터리 장애” 감소
같은 문제를 다시 조사하는 재작업(rework) 감소
“로그오프한 뒤에 무슨 일이 벌어질까?”에 대한 불안 감소

툴은 중요합니다. 대시보드도 중요합니다. 하지만 때로는 내일의 가용 시간을 조용히 지켜 주는 힘이, 아주 인간적인 단 하나의 습관에서 나오기도 합니다.

새벽 3시, 한 명의 지친 엔지니어가, 다음 사람을 위해 잠시 멈춰 짧지만 정성스러운 메모를 남기는 것.

그것이 여러분 팀의 온실 랜턴입니다. 그 불을 꺼뜨리지 마세요.