Gemini 사고 후 하드닝 루프

공식 참고 자료: Get Started · CLI Commands · Sub-agents · Skills

왜 이 루프가 중요한가

사고는 몇 시간 안에 복구해도, 다음 주에 같은 방식으로 다시 발생할 수 있습니다. 재발을 줄이는 루프가 하드닝입니다.

하드닝 시간 구간

구간	우선순위	필수 산출물
0–24시간	근거 품질 보존	타임라인 + 레인 의사결정 기록
24–72시간	지배적 실패 모드 차단	자동화 가드레일 1개 + 회귀 테스트 1개
3–14일	운영 계약 강화	런북/프로세스 업데이트 + 오너 채택 확인

통제 백로그 버킷

탐지: 알림 규칙, 트리아지 가시성, 오너 라우팅
예방: 정책 체크, 정적 체크, 테스트 커버리지
복구: 롤백 신뢰성, 핸드오프 템플릿, 에스컬레이션 맵

모든 백로그 항목에 오너/기한/검증 조건을 넣으세요.

하드닝 레인 아키텍처

Controls 레인: 가드레일 및 정책 강제
Quality 레인: 회귀 및 재현성 개선
Operations 레인: 런북/커뮤니케이션 업데이트

공유 파일 충돌은 merge owner 지정 전까지 피하세요.

신뢰성 스코어카드

각 통제 항목을 0/1로 기록합니다.

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

5/5가 이상적이며, 종료 최소 기준은 4/5입니다.

종료 게이트

아래 조건을 모두 만족할 때만 종료합니다.

스코어카드 기준 충족
통제가 일상 워크플로우에서 실제 동작
후속 오너가 채택 확인
미해결 고위험 항목 없음

근거 번들

하나의 완료 번들을 남기세요.

incident id + 요약 내러티브
반영된 통제 항목
테스트 근거 링크
런북 diff 참조
잔여 항목 오너 + 기한

고급 안티패턴

"프로덕션은 이미 고쳤다"

프로덕션 복구는 recovery이고, hardening은 아닙니다.

오너십 없는 통제 항목

오너 없는 가드레일은 조용히 붕괴합니다.

채택 증거 없는 종료

팀이 사용하지 않으면 리스크는 그대로입니다.

빠른 체크리스트

종료 전:

자동화 통제 1개 이상 머지
회귀 테스트 1개 이상 머지
런북 업데이트 공유
오너 채택 확인 기록

Gemini CLI는 복구 속도를 높입니다. 그 속도를 신뢰성으로 바꾸는 단계가 하드닝입니다.

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

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

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

우선순위	리스크 감소	채택 속도	대표 액션
P0	높음	빠름	차단 정책 체크, 롤백 검증 게이트
P1	높음	중간	원인 클래스 회귀 테스트 추가
P2	중간	빠름	런북/핸드오프 템플릿 개선
P3	중간/낮음	느림	구조적 리팩터링

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

하드닝 실험 설계

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

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

예시

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

오너십 운영 리듬

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

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

월간 통제 감사

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

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

항목	0	1	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 체크리스트는 미반영
오너가 퇴사/이동했는데 재지정 없음

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

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

발견 유형	통제 후보	검증 방식
탐지 누락	알림 규칙 + 라우팅 개선	synthetic alert replay
의사결정 지연	체크포인트 SLA + commander 스크립트	드릴 타이밍 감사
복구 지연	롤백 리허설 게이트	timed rollback run
반복 회귀	테스트 하네스 + 정책 체크	회귀 스위트 추세

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

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:

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

통제 경제성 프레임워크

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

통제 유형	신뢰성 개선 시점	운영 비용	권장 사용 상황
차단 정책 게이트	즉시	중간	고심각도 반복 실패
회귀 스위트 확장	단기/중기	중간/높음	원인 클래스 재발
런북/템플릿 개선	단기	낮음	오너십 모호성
구조 단순화	중기/장기	높음	만성 복합 장애