종이 사건 스토리 뱃사공

개발과 온콜 사이 강을 건너는 깨지기 쉬운 문맥을 손수 옮기는 법

모든 팀에는 그 사건이 있다.

딱 떠오를 것이다. 새벽 2시 17분, 프로덕션이 갑자기 이상해지고, 온콜의 페이저는 난리가 나고, 모두가 대시보드와 로그를 뒤지며 아무도 완전히 기억하지 못하는 스토리를 다시 조립하려고 허둥댄다. 어딘가에는 무슨 일이 일어나는지 설명해 둔 설계 문서나 Slack 스레드가 있지만, 그걸 쓴 사람들은 자고 있거나, 휴가 중이거나, 이미 회사를 떠났다.

이 순간에, 문맥(context) 은 시스템에서 가장 깨지기 쉬운 것이다.

강을 건넌다고 생각해 보자. 한쪽 강둑에는 개발이 있다. 티켓, PR, 설계 문서, Slack 대화, 아키텍처 다이어그램이 있다. 다른 쪽 강둑에는 새벽 2시에 빨간 알림과 뿌연 그래프를 바라보고 있는 온콜 엔지니어가 있다. 그 사이에는 시간, 교대, 조직 경계, 반쯤 기억나는 히스토리로 이뤄진 강이 흐른다.

여기에는 뱃사공(ferryman) 이 필요하다. 개발에서 온콜로 깨지기 쉬운 사건 문맥을 안전하게 손수 옮기는 의도적인 방식 말이다.

이 글에서는 그 뱃사공을 어떻게 만드는지 살펴본다. 표준화된 핸드오프, 지속 가능한 온콜 로테이션, SRE 스타일의 런북과 자동화, 그리고 사건 대응을 공정하고 인간적이며 효과적으로 만드는 문화까지.

1. 왜 사건 문맥은 그렇게 쉽게 부서지는가

알림 시스템은 “뭔가 잘못됐다” 를 크게 외치는 데는 아주 뛰어나다.

하지만 “그게 무슨 의미인지, 왜 일어나는지, 그리고 고치는 동안 무엇이 더 망가질 수 있는지” 를 외치는 데는 형편없다.

효과적인 사건 대응은 다음만으로는 절대 충분하지 않다.

• 알림을 트리거한 메트릭
• 원시 에러 메시지
• 실패한 서비스의 이름

진짜로 필요한 건 더 풍부한 스토리다.

• 누가(Who): 이 서비스를 누가 소유하고 있는가? 최근에 이 부분을 건드린 사람은 누구인가? 실패 모드를 잘 아는 사람은 누구인가?
• 무엇(What): 방금 무엇을 배포했는가? 어떤 의존성이 걸려 있는가? 이미 알려진 이슈는 무엇인가?
• 왜(Why): 이 시스템은 부하 상황, 리전 장애 조치, 부분적인 의존성 실패 시에 왜 이런 식으로 동작하는가?
• 현재 가설(Current hypotheses): 지금 무슨 일이 일어나고 있다고 생각하는가? 과거 사건들에서 무엇을 배웠는가?
• 알려진 함정(Known pitfalls): 솔깃하지만 위험한 수정 방법은 무엇인가? 발을 잘못 디디면 터지는 스위치나 설정은 무엇인가?

이 스토리가 없으면, 온콜은 결국 화물 숭배식(cargo-cult) 디버깅으로 전락한다. 눈 감고 토글을 뒤집고, 롤백을 남발하며, 그냥 뭔가 통하기만을 바라는 식이다. 이는 안정성 측면에서 위험할 뿐 아니라, 대응자에게도 부당하다.

목표는 코드를 옮기는 것만큼이나 의도적으로 문맥을 옮기는 것 이다.

2. 표준화된 온콜 핸드오프: 배 운항 시간표를 만들어라

온콜 핸드오프는 결코 사후적이어서는 안 된다.

성숙한 사건 운영은 핸드오프를 정기 운항하는 페리처럼 다룬다. 예측 가능하고, 문서화되어 있고, 일관적인 것이다. 이를 위해서는 다음이 필요하다.

2.1 핸드오프를 의식(Ritual)으로 만들기

모든 교대 시점에는 짧고 구조화된 핸드오프가 포함되어야 한다. 예를 들어:

• 시간 제한: 10–15분
• 채널: 전용 Slack/Teams 채널 + 캘린더 이벤트
• 참여자: 현재 온콜, 다음 온콜, 필요하다면 로테이션 리드

2.2 표준 핸드오프 템플릿 사용

최소한 다음을 포함하라.

• 진행 중인 사건(Active incidents)
  • 현재 상태
  • 심각도와 영향 범위
  • 담당자 및 이해관계자
  • 현재 가설과 다음 단계
• 알려진 위험 구간(Known risk windows)
  • 예정된 배포
  • 대규모 마이그레이션이나 인프라 변경
  • 규제 마감일, 비즈니스 이벤트(런칭, 세일 등)
• 숨은 불씨(Smoldering issues)
  • 아직 알림은 안 울리지만 이미 성능 저하가 있는 시스템
  • 임시 워크어라운드가 적용되어 있는 부분
• 소유 경계(Ownership boundaries)
  • 특정 행동(예: 데이터 삭제, 권한 상승, 법무 관련 제약)에 어떤 팀/조직이 반드시 관여해야 하는지

이 템플릿은 런북이나 인시던트 툴에 아예 규격으로 박아 두어라. 새벽 3시에 아무도 즉흥적으로 만들어내지 않도록.

3. 개발에서 온콜로 문맥 옮기기: 알림 그 이상

좋은 사건 대응은 사건이 터지기 훨씬 전에 시작된다.

개발이 새 기능이나 큰 변경을 배포할 때는, 온콜이 미리 문맥을 로드할 수 있게 해야 한다.

3.1 사전 배포 컨텍스트 팩(Pre-Deployment Context Pack)

중요한 변경의 경우, Jira, GitHub, 배포 도구 등에 짧은 “컨텍스트 팩”을 필수로 남기게 하라.

• 변경 요약(Change summary): 무엇이 새로워졌는가? 손대지 않은 것 은 무엇인가?
• 무엇이 깨질 수 있는가(What can break): 예상되는 실패 모드와 의존성에 미치는 영향
• 지켜봐야 할 시그널(Signals to watch): 문제가 생겼음을 알려 줄 핵심 메트릭과 로그
• 안전한 롤백 / 킬 스위치: 변경을 안전하게 되돌리는 법
• 악몽 시나리오(Nightmare scenarios): 데이터 손실, 컴플라이언스 위반, 연쇄 장애를 유발할 수 있는 변경들

가능하다면 이 정보는 알림에서 직접 링크될 수 있게 하라.

3.2 알림 설명을 미니 런북으로 만들기

알림 설명(Alert description)은 문맥을 심어 두기 좋은 황금 공간이다. 여기에 포함하라.

• 짧은 “처음 5분” 체크리스트
• 관련 런북과 대시보드 링크
• 흔한 오탐(false positive)과 그 식별 방법
• 피해야 할 것으로 알려진 위험한 “해결책들”

3.3 개발과 온콜 역할을 페어링하기

위험한 변경을 롤아웃할 때는 다음을 고려하라.

• 기능 개발자 중 한 명을 롤아웃 동안 온콜 섀도(shadow on-call) 로 붙인다.
• 일정 시간 동안 반드시 연락 가능하도록 한다.
• 티켓이나 배포 항목에 명시한다: “지금부터 내일 12:00 UTC까지 X/Y 알림이 발생하면 Alice(기능 개발자)에게 즉시 에스컬레이션할 것”

이렇게 하면 시스템을 만든 사람들이 릴리스라는 강을 건널 때 직접 문맥을 같이 옮겨 주게 된다.

4. 지속 가능한 온콜: 사람을 지키면서 가용성을 지키기

사람을 소진시키는 온콜 시스템은 언젠가 반드시 안정성도 무너뜨린다.

지속 가능한 로테이션에는 공통적인 특징이 있다.

4.1 명확한 에스컬레이션 티어

누가 무엇을 언제 하는지 정의하라.

• 1차(Tier 1, 프런트라인): 트리아지, 단순 런북 작업, 기본적인 완화 조치
• 2차(Tier 2, 서비스 전문가): 심층 디버깅, 복잡한 완화, 비사소한 설정 변경
• 3차(Tier 3, 도메인 스페셜리스트 / 리더십): 조직 간 의사결정, 메이저 인시던트 커맨드, 고객 커뮤니케이션

그리고 다음을 명확히 문서화하라.

• 언제 에스컬레이션해야 하는지
• 어떻게 에스컬레이션하는지(도구, 채널, 경로)
• 각 티어가 가진 권한: 예를 들어 롤백, 트래픽 전환, 데이터 접근 등

4.2 예측 가능한 스케줄과 용량 계획

• 최소 4–6주 앞을 내다본 공개 온콜 캘린더 사용
• 시간대와 현지 노동 규정 을 존중
• 온콜 담당자의 스프린트 용량을 조정 하여 집중 시간을 보호
  • 예: 온콜 엔지니어는 평소의 60–70% 정도만 스프린트 업무에 커밋
  • 인시던트 대응을 보이지 않는 잡무가 아니라, 정당한 업무로 취급

4.3 시간, 작업, 보상을 공정하게 관리

특히 소규모 DevOps/SRE 팀에서는 온콜 작업이 쉽게 공중 분해된다. 이를 가시화 하라.

• 다음을 추적하라.
  • 인시던트 대응에 쓴 시간
  • 근무 시간 외 호출과 방해
  • 인시던트 후속 작업
• 이 데이터를 다음에 활용하라.
  • 보상 또는 대체 휴가 산정
  • 로테이션 조정
  • 인력 충원, 툴 도입 같은 투자 근거

장기적인 지속가능성을 위해서는 이런 투명성이 필수다.

5. SRE 실천: 아무도 맨바닥에서 다시 시작하지 않게 만드는 법

구글식 SRE 실천은 본질적으로, 입에서 입으로 전해지던 지식을 시스템 안에 녹여 넣는 작업이다.

5.1 런북을 일급 아티팩트로 대우하기

런북(runbook)은 다음 조건을 만족해야 한다.

• 발견 가능성(Discoverable): 알림과 대시보드에서 바로 링크
• 구체성(Specific): 그냥 “로그를 확인하라”가 아니라 어떤 로그를, 어떤 패턴을
• 유지 관리됨(Maintained): 사건 하나 겪을 때마다 배운 점을 반영해 업데이트
• 적절한 범위(Scoped): 한 가지 증상 또는 사건 유형당 런북 하나. 50페이지짜리 대형 문서 한 개가 아님

팀이 어떤 작업을 두 번 이상 수동으로 수행한다면, 항상 이렇게 물어보도록 훈련하라. “이거, 런북 어디에 있지?”

5.2 영웅주의보다 가드레일과 자동화

반복되는 수동 작업이 보이면, 다음 중 하나로 전환할 수 있는지 고민하라.

• 스크립트 나 ChatOps 명령 으로 만들기
• 안전한 파라미터화된 오퍼레이션 으로 감싸기(“리전 X에서 트래픽 드레인”, “서비스 Y 롤백”)
• 아예 셀프 힐링 워크플로우 로 자동화하기

이렇게 하면 토일(toil) — 반복적이고, 수동이며, 부가가치가 낮은 작업 — 을 줄일 수 있다. 토일은 용량과 사기를 좀먹는다.

안전하고 지루한 작업을 많이 자동화할수록, 어려운 문제에 쓸 에너지가 더 남는다.

6. 문화: 블레이멀리스, 호기심, 그리고 현실 제약 인식

아무리 훌륭한 프로세스도, 실수를 처벌하거나 현실 제약을 무시하는 문화에서는 망가진다.

6.1 비난 없는(Blameless), 호기심 중심의 학습

사건 이후에는 개인 이 아니라 시스템 에 초점을 맞추어라.

• 블레이멀리스 포스트모템(blameless postmortem) 을 통해 다음을 묻는다.
  • 이 실패를 가능하게 만든 것은 무엇인가?
  • 발견·완화를 어렵게 만든 것은 무엇인가?
  • 우리가 가졌던 어떤 가정이 틀렸는가?
• 아슬아슬하게 넘어간 사건(near-miss)과 불편한 진실을 드러낸 사람을 오히려 칭찬하라.
• 각 배움을 다음으로 연결하라.
  • 런북 업데이트
  • 새로운 알림이나 대시보드
  • 리스크를 줄이는 설계 변경

개인을 처벌하면 보고와 학습이 멈춘다. 호기심을 유지해야 문맥의 강이 계속 흐른다.

6.2 조직·법적 경계를 존중하기

인시던트 플레이북은 다음과 같은 제약을 반드시 고려해야 한다.

• 위치와 시간대: 누가 어느 시간에 현실적으로 대응 가능한지
• 규제(Regulations): 데이터 보관 지역, 접근 통제, 감사 가능성
• 소유권(Ownership): 팀, 벤더, 클라우드 제공자 사이의 명확한 경계

이 제약을 문서로 명시하라.

• 어떤 행동에 승인이 필요한지(예: 고객 데이터 삭제)
• 누가 어떤 환경에 접근할 수 있는지(예: 프로덕션 DB vs 로그)
• 어떤 행위가 컴플라이언스를 위해 반드시 로깅되어야 하는지(예: PII 접근)

응답자가 “내가 이 큰 빨간 버튼을 눌러도 되는지” 를 추측해야 하는 상황이 와서는 안 된다.

7. 뱃사공의 체크리스트

개발과 온콜 사이에서 사건 문맥이 가라앉지 않도록 하려면, 다음을 갖추었는지 확인하라.

1. 표준화된 온콜 핸드오프
   • 모든 교대마다 일정, 구조, 문서가 갖춰진 핸드오프
2. 개발→온콜 컨텍스트 팩
   • 위험한 변경에 대해 명확한 실패 모드와 롤백 지침 포함
3. 풍부한 알림 설명
   • 최초 액션, 핵심 링크, 알려진 함정을 알림에 함께 포함
4. 지속 가능한 로테이션
   • 명확한 티어, 예측 가능한 스케줄, 스프린트 용량 조정
5. 공정한 추적과 보상
   • 인시던트 시간, 방해, 후속 작업이 모두 가시화
6. 런북, 가드레일, 자동화
   • 토일과 영웅주의를 줄이는 운영 지식의 제도화
7. 블레이멀리스이면서 제약을 인지한 문화
   • 학습 중심, 법적·조직적 제약을 준수하고, 소유권이 분명한 환경

결론: 홍수 나기 전에 배부터 만들어라

사건 자체를 막을 수는 없다. 하지만 매번 사건이 터질 때마다, 온콜이 고고학자처럼 시스템의 실제 동작 방식을 알아내기 위해 과거의 층위를 파헤치는 상황은 막을 수 있다.

진짜 안정성의 우위는 모니터링 스택이나 배포 파이프라인에만 있지 않다. 개발과 온콜 사이 강을 건널 때 얼마나 잘 문맥을 옮겨 싣는지 에 있다.

핸드오프, 온콜 구조, SRE 실천, 문화를 의도적으로 설계하면, 더 이상 영웅주의나 누군가의 기억력에 기대 새벽 2시를 넘기지 않아도 된다.

당신은 이미 뱃사공을 만들어 둔 셈이다.

다음 번 페이저가 울릴 때, 온콜이 손에 쥐고 있는 것은 단순한 알림 한 줄이 아니라, 곧바로 행동할 수 있는 스토리 가 될 것이다.