Files
llm-wiki/raw/company-tech-blogs/runbook-woowahan-incident-techblog.md
T

8.8 KiB

title, source_type, url, archive_url, status, confidence, tags, related_branches, related_projects, created, last_reviewed
title source_type url archive_url status confidence tags related_branches related_projects created last_reviewed
우아한형제들 — 장애 대응 회고와 runbook 운영 company-tech-blog https://techblog.woowahan.com/2611/ raw low
ca-operational-runbook
woowahan
incident
postmortem
korean
feature-operational-runbook-contract
ca-skeleton-operational-contract
2026-05-22 2026-05-27

우아한형제들 — 장애 대응 회고와 runbook 운영

Layer: raw/company-tech-blogs/ — 우아한형제들 기술블로그 장애 대응 사례. 2026-05-27 fetch 확인 시 등록된 URL techblog.woowahan.com/2611/ 의 실제 페이지 제목은 "REMOTE CONFIG SERVER" (2019-02-18, 강홍구) 로 본 raw 의 주제와 일치하지 않음. 원래 raw 본문에 적힌 5개 인용은 해당 URL 에서 verbatim 재확보 실패 → unverified. 후보 대체 URL: techblog.woowahan.com/4886/ ("우아~한 장애대응", 2021-06-30, 박주희) 등. 본 migration 에서는 자동 URL 교체 금지 (사용자 확인 필요), 현재 URL 유지 + 한계 명시.

Parent / 활용 branch (필수)

Branch 이 자료가 정당화하는 결정
raw/branch-notes/feature-operational-runbook-contract ca-tmpl Error Registry ↔ Runbook Coverage CI gate 와 한국 사례 (장애 유형별 runbook 분리 + postmortem 반영) 비교 근거
raw/project-notes/ca-skeleton-operational-contract §18. Control Plane Contract (Operational Runbook) 의 보조 사례

컨텍스트 / 왜 저장했는지

ca-tmpl이 결정한 "alert에 operation, dependency, error.category, error.code, retryable, runbook link 가 연결되어야 함" + "dependency 장애, DB unavailable, auth failure spike, 5xx spike, queue lag, cache unavailable 별 1차 대응 기준"의 국내 사례 근거 (의도). 단 본 raw 의 URL 재확인 결과 매칭 실패 (위 §Layer 주석 참조).

출처 / Source

핵심 인용 / Key quotes (verbatim)

2026-05-27 fetch 시점: 등록 URL 2611 페이지에서 장애 대응 / runbook 관련 verbatim 인용 추출 불가 (페이지 주제 = remote config server). 원래 raw 본문에 적혀 있던 5개 한글 인용 ("장애가 발생했을 때 가장 빠르게 1차 확인할 dashboard..." 등) 은 출처 verbatim 으로 재확인되지 않음 → 본 섹션에 정식 quote 로 둘 수 없음.

[§등록 URL 2611 의 유일한 직접 확보 가능 sentence — 장애 관련 표현] "배달의민족앱이 정상동작 되지 않는다면 배달의민족이 제공하는 어떠한 서비스도 정상적으로 이용이 불가능하기 때문에 장애상황이 발생했을때, 최대한 빠르게 이슈를 파악하고 대응을 할 수 있어야 합니다." — 본 문장은 remote config server 페이지의 도입부 동기 서술이며, ca-tmpl runbook contract 직접 증거가 되지 못함.

참고 (대체 후보 URL 4886 에서 fetch 한 verbatim 일부 — 본 raw 의 정식 인용 아님, 사용자가 URL 교체 결정 후 별도 raw 또는 갱신 raw 로 이동 필요):

  • "장애는 서비스의 성장, 서비스의 변화 등 다양한 과정 중에서 발생하는 성장통"
  • "확인된 최소의 정보만 가지고 빠르게 공지하도록 권고"
  • "장애 복구와 장애 전파를 같은 사람이 하지 않도록 가이드"
  • "서비스 정상화는 원인 파악보다 우선됩니다"
  • "5whys라는 기법을 사용해 정확하게 원인을 찾기 위함"

Claims Extracted / 추출된 주장

Claim ID Claim (이 자료가 직접 말하는 것) Evidence quote Strength Applies to Does not prove
WW-RB-C1 등록된 URL (2611) 페이지에서 runbook / 장애 회고 / alert dashboard 관련 verbatim 인용 추출 불가 (페이지 주제 불일치) (fetch 결과 자체가 claim) needs-confirmation 본 raw 전체 — URL 교체 / 별도 raw 분리 결정 보류 우아한형제들 기술블로그에 runbook 관련 글이 없다는 뜻은 아님. 단지 등록 URL 이 잘못 짝지어졌을 가능성
WW-RB-C2 (대체 후보 4886, 본 raw 정식 인용 아님) 장애 복구와 장애 전파를 같은 사람이 하지 않도록 가이드 [§우아~한 장애대응] "장애 복구와 장애 전파를 같은 사람이 하지 않도록 가이드" needs-confirmation 우아한형제들 사례 — 단 URL 교체 후 별도 raw 에서 정식 인용 처리 필요 모든 조직이 이렇게 분리해야 한다는 best practice 가 아님 (회사 사례)
WW-RB-C3 (대체 후보 4886) 서비스 정상화는 원인 파악보다 우선 [§우아~한 장애대응] "서비스 정상화는 원인 파악보다 우선됩니다" needs-confirmation 우아한형제들 incident triage priority 모든 도메인이 정상화 우선 정책을 따라야 한다는 일반 권고 아님
WW-RB-C4 (대체 후보 4886) 5whys 기법으로 근본원인 분석 [§우아~한 장애대응] "5whys라는 기법을 사용해 정확하게 원인을 찾기 위함" needs-confirmation postmortem 기법 사례 5whys 가 항상 최선의 RCA 방법이라는 뜻 아님
WW-RB-C5 원래 raw 본문에 있던 5개 한글 인용 ("runbook은 장애 발생 후가 아니라 alert을 만들 때 함께 작성합니다" 등) 은 출처 verbatim 으로 재확인 실패 (verbatim 미확보) needs-confirmation 본 raw 의 ca-tmpl 비교 메모 전체 우아한형제들이 그런 정책을 갖지 않는다는 뜻은 아님 — 단지 본 raw 의 인용 출처 부정확

Usage Boundaries / 적용 경계

  • 이 자료가 직접 증명하는 것:
    • WW-RB-C1: 등록 URL 이 본 raw 주제와 불일치하다는 메타 사실
  • 이 자료가 증명하지 않는 것:
    • WW-RB-C2~C4: 본 raw 정식 인용 아님 — 대체 URL 4886 에서 verbatim 확보되었으나 본 raw 의 URL 교체는 사용자 결정 보류
    • WW-RB-C5: "alert 만들 때 runbook 동시 작성", "장애 유형별 runbook 분리", "postmortem → runbook update" 등 ca-tmpl 비교의 핵심 인용 — 본 raw 의 등록 URL 에서 verbatim 부재
  • 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
    • 본 raw 의 URL 을 4886 등 실제 장애 대응 글로 교체할지 / 별도 raw 로 분리할지 결정 필요
    • URL 교체 후 ca-tmpl 비교 메모 (장애 유형별 분리, postmortem → runbook update 정합) 의 인용 정합성 재검증

메모 / Notes (내 프로젝트 해석)

본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석. 위 §Claims 의 C1/C5 한계 위에서 작성됨 — ca-tmpl 결정의 단일 근거로 사용 불가.

  • runbook 분리 단위 (가설):
    • 우아한형제들 추정: 장애 유형별 (DB / queue / 외부 API / auth) 분리.
    • ca-tmpl: 같은 유형 분리 + runbook://{area}/{scenario} scheme로 hierarchical naming.
    • 양쪽 모두 단일 mega-runbook 금지 철학 추정.
    • 본 raw 등록 URL 에서 직접 증명 불가 → 별도 출처 필요.
  • alert ↔ runbook 결합 시점 (가설):
    • 우아한형제들 추정: "alert 만들 때 runbook 동시 작성" 원칙.
    • ca-tmpl: Error Registry ↔ Runbook Coverage CI gate — retryable=false + 특정 category row 는 runbook link 필수, 누락 시 release-block.
    • ca-tmpl 의 CI gate 가 더 강제력 강한 것은 사실. 우아한형제들 측 verbatim 은 본 raw 에 없음.
  • postmortem 반영 (가설): 본 raw 등록 URL 에 verbatim 없음.
  • ca-tmpl 과의 차이 (가설): 우아한형제들은 프로세스/문화 중심, ca-tmpl 은 계약/CI gate 중심으로 추정 — 검증 보류.