아날로그 인시던트 랜턴 워크

밤에 랜턴을 들고 동네를 걷는다고 상상해보세요.

당신은 서두르지 않습니다. 사이렌을 쫓지도 않습니다. 천천히 움직이며 문과 창문을 살피고, 낯선 소리가 나는지 귀 기울이고, 무언가 이상하다 싶은 기척을 실제로 고장이 나기 전에 미리 알아차립니다. 이것이 바로 **아날로그 인시던트 랜턴 워크(Analog Incident Lantern Walk)**이고, 현대적인 안정성과 온콜(On‑call)을 대하는 방식에 대한 은유입니다.

알람이 터지기를 기다리는 대신, 의도적으로 밤에 시스템을 “돌아다닙니다” — 로그, 대시보드, 큐, 유저 여정(user journey)을 살펴보며, 대형 인시던트가 되기 훨씬 전에 조용히 나타나는 장애의 징후를 찾는 것입니다.

가용성(uptime)만으로는 부족하고 실제 사용자 경험이 진짜 SLA인 시대에는, 이런 의도적이고 차분하며 아날로그적인 태도가 혼란스러운 불 끄기 모드와 지속 가능한 안정성을 가르는 핵심이 되고 있습니다.

불 끄기(Firefighting)에서 랜턴 워크로

전통적인 운영은 주로 장애에 반응하는 방식으로 돌아갔습니다:

• 뭔가 깨짐 → 페이저가 울림 → 모두가 우왕좌왕.

현대적인 SRE 실천은 이를 뒤집습니다:

• 시스템은 완전히 무너지기 훨씬 전부터 조금씩 드리프트하고, 성능이 떨어지고, 이상해집니다.

랜턴 워크 마인드는 인시던트를 바라보는 관점을 바꿉니다:

• 미묘하고 부분적인 장애를 당연하게 예상합니다: 느려진 엔드포인트, 에지에서 올라가는 에러율, 이상한 캐시 미스 패턴 등.
• **저하된 경험(degraded experience)**도 단순한 노이즈가 아니라 진짜 인시던트로 다룹니다.
• “죽었냐 안 죽었냐(Is it down?)”에서 “지금 사용자에게 충분히 좋냐(Is it good for users right now?)”로 질문을 바꿉니다.

여기서 이 비유가 중요해집니다. 소방관은 건물이 이미 불타고 있을 때 뛰어들지만, 밤 순찰자는 랜턴을 들고 다니며 애초에 절반의 화재를 예방합니다.

단순 가용성을 넘어 경험으로: ‘인시던트’ 재정의하기

오랫동안 인시던트 관리는 순수한 가용성 중심이었습니다:

서비스가 200을 반환하면, 우리는 괜찮다.

이제는 낡은 관점입니다. 요즘 사용자들은 다음과 같은 것들을 민감하게 느낍니다:

• 500ms 대신 5초 걸리는 페이지 로딩
• 두 번째 시도에야 성공하는 불안정한 결제
• 트래픽이 몰릴 때 간헐적으로 발생하는 타임아웃

**완전 장애(full outage)**만 인시던트로 취급하면, 실제 피해 대부분을 놓치게 됩니다. 지금의 신뢰성은 **경험 관리(experience management)**에 가깝습니다:

• 지연 시간(latency), 에러율, 핵심 유저 여정을 중심으로 SLO를 정의합니다. 단순 가용성만 보지 않습니다.
• 느리고, 불안정하고, 품질이 떨어진 **저하 경로(degraded path)**도 분석할 가치가 있는 인시던트로 취급합니다.
• 에러 버짓(error budget)을 사용해 언제 기능 개발을 멈추고 안정성에 집중할지 결정합니다.

랜턴 워크는 이런 경험의 드리프트를 발견하는 시간입니다:

• 특정 리전의 p95 지연 시간이 며칠째 서서히 올라가고 있는 상황.
• 특정 브라우저/OS 조합에서만 전환율이 조용히 무너지고 있는 패턴.
• 백그라운드 잡이 매일 밤 “따라잡는다”고는 하지만 조금씩 더 느려지고 있는 현상.

랜턴으로 이런 것들을 미리 발견하면, 그것들은 새벽 3시의 비상 호출이 되지 않습니다.

나만의 야간 근무 플레이북 만들기

페이저가 정말 울렸을 때, 아드레날린은 올바른 판단의 적입니다. 새벽 2시에 즉흥적으로 대응하고 싶지 않을 것입니다. 스크립트가 필요합니다.

차분하고 일관되게 대응할 수 있도록 개인 온콜 플레이북을 만들어 두세요:

1. 핵심 체크리스트

반쯤 잠든 상태에서도 따라갈 수 있는 작고 집중된 체크리스트를 작성합니다:

• 첫 5분

  • PagerDuty(또는 동급 도구)에서 알림을 확인/승인합니다.
  • 알림 설명과 연결된 런북을 읽습니다.
  • 서비스 대시보드를 확인합니다(지연 시간, 에러, 자원 포화도 등).
  • 현재 사용자가 영향을 받고 있는지 확인합니다(시뮬레이션 모니터, 로그, 상태 페이지 등).

• 첫 15분

  • 지금 바로 **완화(mitigation)**할지, 더 조사할지 결정합니다.
  • 인시던트 채널에 커뮤니케이션합니다: “담당(Own), 평가(Assess), 다음 업데이트 시간(Next Update)”.
  • 필요하다면 추가 역할을 호출합니다(DBA, 네트워크, 애플리케이션 오너 등).

2. 통화 및 채팅 스크립트

스트레스 상황에서는 말을 꺼내는 것조차 어렵습니다. 미리 작성해 두세요:

• 인시던트 채널용 Slack/Teams 템플릿:

  "이번 인시던트의 온포인트입니다. 현재 영향 범위: [X]. 추정 원인: [Y/미상]. 다음 업데이트 시각: [시간]."

• 에스컬레이션 통화 스크립트:

  "안녕하세요, 저는 [서비스] 온콜 담당입니다. [시간]부터 [증상]이 관측되고 있습니다. [구체적인 영역]에 대한 도움이 필요합니다. 런북 링크: [URL]."

이런 스크립트는 인지 부하를 줄이고, 커뮤니케이션을 명확하게 해 줍니다.

3. 작은 실용 팁들

몇 가지 저기술(low‑tech) 트릭도 꽤 큰 도움이 됩니다:

• 하나의 통합 북마크 폴더를 만드세요: 대시보드, 로그 뷰어, 런북, 기능 플래그, 롤백 컨트롤 등을 한곳에 모읍니다.
• 로컬에 “인시던트 스크래치패드” 템플릿을 둡니다: 시간, 증상, 수행한 액션, 가설 등을 바로바로 적습니다.
• 야간에 눈의 피로를 줄이기 위해 다크 모드 대시보드와 큰 글꼴을 미리 설정합니다.

당신의 플레이북은 곧 당신의 랜턴입니다. 주변이 혼란스러울 때도 당신을 안정적으로 이끌어 줍니다.

런북: 피로 쓰고, 평소에 다듬는다

좋은 런북은 MTTR을 줄이고, 스트레스를 낮추며, 혼돈을 체크리스트로 바꿔줍니다.

가장 가치 있는 런북은 대부분 “피로 쓰인(written in blood)” 문서입니다 — 실제로 고통스러운 인시던트 중에 만들어지고, 그 후에 차분한 상태에서 개선된 것들입니다.

좋은 런북의 조건

• 백과사전식이 아니라 실행 가능해야 합니다(Actionable)

  • 트리아지(초기 분류) 플로우로 시작합니다: “알림 X가 뜨면, A, B, C를 수행한다.”
  • 정확한 명령어, 대시보드, 링크를 포함합니다.

• 결과 지향적이어야 합니다(Outcome‑focused)

  • "목표: 지연 시간을 300ms 이하로 복구"처럼 목적을 분명히 하고, "이 스크립트를 아무 이유 없이 돌려라" 식이 되지 않게 합니다.

• 불확실성을 솔직하게 드러냅니다

  • 위험한 스텝을 명시합니다: “이 작업은 클러스터를 재시작합니다. 약 30초간 부분적인 영향이 발생할 수 있습니다.”

• 지속적으로 개선됩니다

  • 매 인시던트 이후 다음을 추가합니다:
    • 효과가 없었던 조치와 이유
    • 더 일찍 감지하는 데 도움이 되었을 신규 시그널
    • 더 안전하거나 자동화된 완화 방법

런북은 박물관 전시품이 되어서는 안 됩니다. 이것은 살아 있는 문서이며, SRE 팀의 집단 기억 자체입니다.

SRE 온콜 vs. 전통적인 운영: 다른 계약

SRE 온콜은 단순히 “페이저 울리면 나가서 재시작하는 사람”이 아닙니다.

여기에는 다른 **암묵적 계약(implicit contract)**이 있습니다:

• SRE는 운영 환경의 ‘지원’이 아니라 ‘소유’를 합니다.

  • SLO를 통해 무엇이 “충분히 안정적인 상태”인지 정의합니다.
  • 에러 버짓이 타들어가면, 제품 개발에 제동을 겁니다.

• 인시던트는 비난이 아니라 시스템 개선의 계기입니다.

  • 사후 인시던트 리뷰(post‑incident review)를 통해, 더 나은 자동화, 더 안전한 릴리스, 더 강력한 관측 가능성(observability) 같은 엔지니어링 작업이 도출됩니다.

• 반복되는 고통에 대한 기본 대응은 자동화입니다.

  • 같은 수동 조치를 세 번 반복했다면, 이제는 코드를 작성해야 할 때입니다.

이렇게 되면 온콜은 비용 센터가 아니라, 엔지니어링 전문 분야가 됩니다. 시스템이 우아하게 실패하고 빠르게 복구되도록 설계하는 영역입니다.

현대 도구와 런북 통합하기

당신의 랜턴은 도구들과 연결되어 있어야 합니다.

단순히 런북을 작성하는 데서 끝내지 말고, 인시던트가 발생했을 때 원클릭으로 접근하고, 안전한 자동화를 트리거할 수 있도록 스택에 깊이 통합하세요.

알림 및 인시던트 관리 도구

• PagerDuty, Opsgenie 등
  • 각 알림에 구체적인 런북을 연결합니다.
  • Response play를 사용해 인시던트 채널 생성, 역할 지정, 컨텍스트 첨부를 자동화합니다.

오케스트레이션 & 자동화

• Rundeck, AWS Systems Manager(SSM), 자체 도구 등
  • 자주 쓰는 완화 작업을 안전하고 감사(audit) 가능한 Job으로 만듭니다:
    • 특정 서비스 재시작
    • 읽기 전용 복제본(read replica) 페일오버
    • 특정 오토스케일 그룹 확장
  • RBAC와 승인 절차로 접근을 통제합니다.

Observability

• 알림과 런북에 대시보드 링크와 **저장된 쿼리(saved query)**를 바로 연결합니다.
• 로그인, 검색, 결제 같은 실제 유저 여정에 대응하는 Synthetic 체크를 구성해, 한눈에 경험 수준의 건강 상태를 볼 수 있게 합니다.

목표는 간단합니다. 알림이 울렸을 때 온콜 담당자 앞에는 이미 모든 것이 준비되어 있어야 합니다 — 무슨 일이 벌어지고 있는지, 왜 그럴 수 있는지, 어떻게 안전하게 완화할 수 있는지까지.

인간적인 온콜 로테이션 설계하기

야간 랜턴 워크를 지속하려면, 밤 순찰자가 지쳐 있지 않아야 합니다.

인간적인 온콜은 개인 의지력 테스트가 아니라 설계 문제입니다.

인력과 스케줄을 신중하게 설계하기

• 충분한 커버리지

  • 중요한 시스템을 한 사람에게만 의존하지 마세요.
  • 교차 교육(cross‑training)을 통해 “부족한 사람만 아는 지식(tribal knowledge)”의 병목을 제거합니다.

• 예측 가능한 로테이션

  • 주 단위와 같이 고정된 예측 가능한 스케줄을 사용해, 사람들이 온콜에 맞춰 삶을 계획할 수 있게 합니다.
  • 백업 없이 끝없는 24/7 1차 온콜 구조는 피합니다.

알림 위생(Alert Hygiene)

• 시끄러운 알림은 사기를 갉아먹는 세금입니다.

  • 정기적으로 다음과 같은 알림을 검토하고 정리(prune)하세요:
    • 실제 액션으로 이어진 적이 없는 알림
    • 늘 무시되는 알림
    • 다른 시그널과 중복되는 알림

• 저수준에서 출렁이는 메트릭보다, 사용자 영향에 기반한 증상 중심(symptom‑based) 알림을 우선합니다.

회복 시간과 보상

• 심야 인시던트 이후에는 **회복 시간(recovery time)**을 줍니다(밤샘 → 늦은 출근 또는 휴가 등).
• 온콜은 실질적인 비용이 있다는 점을 인정하고, 그에 맞는 보상 혹은 업무 경감이 필요합니다.

인간적인 로테이션은 단지 친절함의 문제가 아니라, 곧 신뢰성 전략입니다. 번아웃된 엔지니어는 새벽 3시에 더 나쁜 결정을 내립니다. 잘 쉬고 있는 야간 순찰자는 더 많은 작은 불씨를 큰 불이 되기 전에 잡아냅니다.

랜턴 워크를 실무에 들여오기

이걸 시작하기 위해 대규모 조직 개편이 필요한 것은 아닙니다.

앞으로 몇 주 동안 다음을 시도해볼 수 있습니다:

1. 당신의 시스템에서 ‘경험 실패(experience failure)’가 무엇인지 정의합니다.
   • 유저 여정과 직접 연결된 1~2개의 SLO를 정합니다.
2. 주 1회 ‘랜턴 워크’ 시간을 잡습니다.
   • 피크 이후 30–60분을 정해, 대시보드, 로그, 큐, 유저 여정을 훑어봅니다.
   • "뭔가 좀 이상한데" 싶은 관찰을 기록하고, 후속 작업으로 전환합니다.
3. 주당 핵심 런북 하나를 만들거나 업데이트합니다.
   • 가장 자주 뜨는 알림이나, 가장 심각도가 높은 알림부터 시작하세요.
4. 개인 온콜 플레이북을 만듭니다.
   • 체크리스트, 스크립트, 북마크 등을 가볍고 실용적으로 정리해 가까운 곳에 둡니다.
5. 반복되는 수동 작업 하나를 골라 자동화합니다.
   • 적절한 안전장치를 갖추어 인시던트 도구와 연결합니다.

시간이 지나면, 온콜은 만성적인 스트레스의 원인이 아니라, 당신이 **꾸준히 실력을 키울 수 있는 장인정신(craft)**에 가까워집니다. 더 일찍 알아차리고, 더 차분하게 대응하며, 더 우아하게 실패하는 시스템을 설계하는 능력이 쌓입니다.

결국 아날로그 인시던트 랜턴 워크는 프로세스 이전에 **자세(posture)**의 문제입니다. 충분히 자주, 충분히 천천히, 충분히 깊이 시스템을 거닐어, 어둠 속에서 장애가 당신을 기습할 기회를 주지 않는 그런 자세 말입니다.