Claude 사고 후 하드닝 루프

공식 참고 자료: Best Practices · Hooks · Security · GitHub Actions

왜 이 루프가 중요한가

사고 대응은 서비스를 복구합니다. 하드닝은 사고 재발을 줄입니다.

하드닝 루프가 없으면 같은 사고는 계속 비싼 비용으로 반복됩니다.

시간 구간별 하드닝 타임라인

하드닝 백로그 모델

액션을 3개 버킷으로 분류하세요.

• 탐지 가속: 알림 임계치, 대시보드 힌트, 페이저 라우팅
• 재발 방지: 테스트, 정적 체크, 정책 훅
• 복구 가속: 롤백 스크립트 신뢰성, 핸드오프 템플릿, 오너 맵

각 항목에는 반드시 오너 1명과 기한 1개가 필요합니다.

3-레인 하드닝 실행

• Controls 레인: 훅/체크/CI 가드레일 추가
• Quality 레인: 원인 클래스 회귀 커버리지 추가
• Operations 레인: 런북 + 커뮤니케이션 프로토콜 업데이트

가능하면 레인 독립성을 유지해 merge 마찰을 줄이세요.

준비도 스코어카드

행마다 0 또는 1로 기록합니다.

• 원인 클래스가 테스트로 커버됨
• 롤백 경로 리허설 완료
• 에스컬레이션 오너 문서화
• 대시보드/알림 업데이트
• 런북 업데이트 및 확인 완료

점수 4 미만이면 하드닝은 미완료입니다.

종료 의사결정 규칙

아래를 모두 만족해야 하드닝을 종료합니다.

• 스코어카드 목표 달성
• 신규 가드레일이 실제 워크플로우에서 동작
• 후속 오너가 채택 사실을 확인
• 미해결 고위험 항목이 없음

근거 패킷 템플릿

하드닝 종료 시 아래를 보관합니다.

• incident id + 요약
• 구현한 통제 항목
• 테스트 근거 링크
• 런북 diff
• 잔여 작업 오너 + 기한

고급 안티패턴

회고만 쓰고 통제는 미반영

학습이 통제로 연결되지 않으면 리스크는 그대로입니다.

테스트만 추가하고 오너십은 미정리

시스템은 개선돼도 팀 계약은 약한 상태로 남습니다.

채택 확인 전 조기 종료

실제 워크플로우에서 쓰이지 않는 가드레일은 프로덕션을 보호하지 못합니다.

빠른 체크리스트

하드닝 루프 종료 전:

• 자동화 가드레일 1개 이상 머지
• 회귀 테스트 1개 이상 머지
• 런북 업데이트 공개
• 오너 확인 기록

Claude는 복구 속도를 높여줍니다. 신뢰성을 누적시키는 건 하드닝입니다.

하드닝 포트폴리오 우선순위 매트릭스

하드닝 액션은 두 축으로 우선순위를 정합니다.

• 리스크 감소 규모
• 운영 채택까지 걸리는 시간

문장 다듬기보다 P0/P1을 먼저 닫으세요.

하드닝 실험 설계

각 하드닝 액션을 작은 실험으로 운영합니다.

1. 가설: "통제 X를 넣으면 실패 클래스 Y가 Z% 감소한다."
2. 측정: 지표 + 관찰 기간 정의
3. 가드레일: 통제 자체 롤백 조건
4. 오너: 실행 오너 1명 + 검증 오너 1명
5. 리뷰 날짜: 고정 날짜 지정

예시

• 가설: 릴리스 전 롤백 리허설 의무화로 SEV-1 MTTR 편차 감소
• 측정: 다음 4회 사고/드릴의 p95 MTTR
• 가드레일: 릴리스 리드타임 20% 이상 악화가 2회 지속되면 게이트 재보정

오너십 운영 리듬

주간 신뢰성 스탠드업 (20분)

• 기한 초과 하드닝 항목 리뷰
• 근거 링크가 약한 항목 리뷰
• blocked 항목 즉시 재배정
• 증거 링크 없는 항목은 close 금지

월간 통제 감사

• 통제가 실제로 동작 중인지 확인
• 오너가 여전히 유효한지 확인
• 리스크 감소가 없는 통제는 폐기

하드닝 품질 루브릭 (0–2점)

최소 통과 7/10. 미달이면 루프를 닫지 않습니다.

하드닝 백로그 템플릿

### Hardening Item
- Incident reference:
- Failure class:
- Proposed control:
- Priority band: P0/P1/P2/P3
- Execution owner:
- Verifier owner:
- Due date:
- Evidence link(s):
- Adoption check date:
- Status: open | in_progress | verified | retired

하드닝 프로그램의 흔한 실패

• 지표 개선 효과 없이 backlog만 닫힘
• 통제를 추가했지만 운영자에게 전파되지 않음
• 런북만 바꾸고 on-call 체크리스트는 미반영
• 오너가 퇴사/이동했는데 재지정 없음

이 문제는 월간 감사로 해결해야 합니다.

사고 발견사항 → 통제 설계 매핑

이 매핑이 하드닝을 추상화에서 구체화로 바꿉니다.

14일 하드닝 스프린트 템플릿

• 1–2일: 리스크/가역성 기준 우선순위화
• 3–5일: P0/P1 통제 구현
• 6–8일: 검증 커버리지와 근거 링크 추가
• 9–11일: 실운영 채택 체크
• 12–14일: 요약 공개 + 잔여 리스크 오너 확정

일정이 밀려도 검증은 줄이지 마세요.

잔여 리스크 레지스터 형식

### Residual Risk
- Risk statement:
- Why not fully solved yet:
- Temporary control in place:
- Trigger for re-prioritization:
- Owner:
- Target resolution date:

트리거/기한 없는 잔여 리스크는 미관리 리스크입니다.

통제 경제성 프레임워크

모든 하드닝 통제에는 비용이 있습니다. 트레이드오프를 명시하세요.

먼저 신뢰성 대비 효율이 높은 통제를 선택하세요.

채택 하드닝 체크리스트

머지 시점은 완료가 아닙니다. 채택을 별도로 검증해야 합니다.

• 오너가 사이드채널 지식 없이 통제를 실행할 수 있는가
• 통제 자체 실패 경로가 문서화되어 있는가
• on-call 체크리스트에 새 통제 포인트가 반영되었는가
• 로그/대시보드 근거로 통제 실행이 확인되는가

머지됐지만 쓰이지 않는 통제는 거짓 확신입니다.

하드닝 QA 게이트

verified 전 반드시 확인:

1. 구현 근거 (diff + 명령 출력)
2. 행동 근거 (드릴/리플레이 신호)
3. 오너십 근거 (실행 오너 + 검증 오너 승인)

하나라도 빠지면 in_progress 유지.

통제 Sunset 프로토콜

통제는 기본적으로 영구 유지 대상이 아닙니다.

폐기 조건:

• 목표 지표 개선 효과 없음
• 더 강한 통제와 중복
• 운영 비용이 리스크 감소 대비 과도

폐기 시 대체안 또는 사유 노트를 남기세요.

통제 롤아웃 시퀀싱

새 통제를 3단계로 배포합니다.

1. Shadow mode — 차단 없이 동작 관찰
2. Warn mode — 위반 노출 + 오너 귀속
3. Enforce mode — 정의된 고위험 조건에서 차단

급격한 운영 충격 없이 안전성을 올릴 수 있습니다.

하드닝 채택 점수

채택 점수(0–5)로 관리합니다.

• 대상 환경에서 통제가 활성화됨
• 오너가 학습/확인 완료
• 런북 실행 절차 반영
• 대시보드 신호로 런타임 실행 확인
• 실제 사고/드릴 1회 이상 적용

4 미만이면 채택 미완료입니다.

신뢰성 부채 레저

연기된 하드닝 작업은 별도 레저에 기록:

재검토 날짜 없는 연기는 상시 리스크가 됩니다.