이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- 운영 점검 체크리스트는 어떤 주기로 나눠 관리해야 하는가?
- 배포 전, 일일, 주간, 장애 후 점검은 각각 무엇을 확인하는가?
- 체크리스트가 형식 문서가 되지 않게 하려면 무엇이 필요한가?
목적
운영 점검 체크리스트는 반복 작업에서 빠뜨리기 쉬운 항목을 줄이는 문서다.
장애 중 Runbook이 “무엇을 할지”를 알려 준다면, 체크리스트는 평소에 “문제가 커지기 전에 무엇을 확인할지”를 알려 준다.
체크리스트는 한 번 만들고 끝나는 문서가 아니다.
마지막 검증일, 소유자, 주기, 실패 시 조치가 있어야 한다.
체크리스트 구성 원칙
좋은 체크리스트는 다음 조건을 가진다.
- 예/아니오로 답할 수 있다.
- 확인 위치가 명확하다.
- 실패했을 때 다음 행동이 있다.
- 소유자와 주기가 있다.
- 마지막 검증일이 남는다.
- 장애 후 새 항목이 반영된다.
나쁜 체크리스트는 “모니터링 확인”, “로그 확인”, “보안 확인”처럼 모호하다.
좋은 항목은 “주문 API 5xx 알림이 지난 7일간 정상 발송되었는가”처럼 확인 가능한 형태다.
배포 전 점검
배포 전에는 변경이 장애로 이어질 수 있는 경계를 확인한다.
- artifact version과 commit이 배포 대상과 일치하는가?
- profile과 환경 변수가 대상 환경에 맞는가?
- DB migration이 이전 버전과 새 버전 모두와 호환되는가?
- feature flag 기본값이 확인되었는가?
- smoke test 계정과 테스트 데이터가 준비되었는가?
- Rollback 가능 조건이 확인되었는가?
- 배포 후 관찰할 오류율, 응답 시간, 핵심 이벤트가 정해졌는가?
- 담당자와 승인자가 정해졌는가?
하나라도 아니오라면 배포를 미루거나 risk를 명시하고 승인받는다.
일일 점검
일일 점검은 작은 이상 신호를 빨리 발견하기 위한 것이다.
- 핵심 API 오류율이 기준 안에 있는가?
- p95 응답 시간이 평소 범위 안에 있는가?
- 배치와 스케줄 작업이 성공했는가?
- DB connection pool, queue depth, 외부 API 오류가 평소 범위 안인가?
- 디스크, memory, CPU 사용량이 급증하지 않았는가?
- 알림이 울렸는데 처리되지 않은 항목이 없는가?
- 전날 배포 후 사용자 문의가 늘지 않았는가?
일일 점검은 긴 분석이 아니라 이상 신호를 발견하는 데 집중한다.
주간 점검
주간 점검은 운영 체계가 낡지 않았는지 확인한다.
- Runbook의 마지막 검증일이 오래되지 않았는가?
- 백업 성공과 복원 리허설 기록이 있는가?
- Secret 회전 대상이 밀려 있지 않은가?
- dependency나 base image 보안 업데이트가 밀려 있지 않은가?
- 비용이나 사용량이 예상 범위를 벗어나지 않았는가?
- 알림 noise가 증가하지 않았는가?
- 장애 후 action item이 기한 안에 진행되고 있는가?
- 권한이 퇴사자나 불필요한 계정에 남아 있지 않은가?
주간 점검은 실행보다 정비에 가깝다.
장애 후 점검
장애가 끝난 뒤에는 체크리스트 자체를 업데이트해야 한다.
- 탐지가 늦어진 신호가 있었는가?
- Runbook에서 빠진 단계가 있었는가?
- 권한이나 접근 경로 때문에 조치가 지연되었는가?
- 완화 조치의 기대 신호가 불명확했는가?
- 복구 후 안정화 관찰 시간이 충분했는가?
- Postmortem action item이 체크리스트나 Runbook에 반영되었는가?
- 같은 장애를 다시 만나면 더 빨리 대응할 수 있는가?
장애 후 점검이 없으면 체크리스트는 경험을 학습하지 못한다.
점검 기록 예시
## 운영 점검 기록
- 날짜: 2026-07-01
- 점검자: 김민수
- 범위: order-api prod
- 배포 전 점검: PASS
- 일일 점검: WARN
- WARN 항목: payment API timeout 0.8% 증가
- 조치: 외부 API dashboard 확인, rate limit 변화 없음
- 다음 확인: 2026-07-02 09:30점검 기록은 장애 보고서보다 짧아도 된다.
중요한 것은 이상 신호와 다음 행동이 남는 것이다.
장애 신호
- 체크리스트 항목이 모두 추상적이라 실제로 확인할 수 없다.
- 마지막 검증일이 오래되었다.
- 실패 항목이 있어도 다음 행동이 없다.
- 장애 후 같은 누락이 반복된다.
- 한 사람만 점검 방법을 안다.
- 점검은 했지만 기록이 없어 추세를 볼 수 없다.
이 신호는 체크리스트가 운영 품질을 높이지 못하고 있다는 뜻이다.
안전한 개선 조치
- 항목을 예/아니오 질문으로 바꾼다.
- 각 항목에 확인 위치와 owner를 붙인다.
- 실패 시 연결할 Runbook 링크를 추가한다.
- 오래된 항목은 최근 장애 기준으로 정리한다.
- 자동화 가능한 항목은 알림이나 dashboard로 옮긴다.
- 수동 판단이 필요한 항목은 이유와 기준을 남긴다.
하지 말아야 할 대응
- 모든 항목을 매일 확인하게 만들어 아무도 지키지 못하게 하지 않는다.
- “확인함”만 남기고 근거를 남기지 않는다.
- 실패 항목을 다음 행동 없이 PASS 처리하지 않는다.
- 장애 후 체크리스트를 업데이트하지 않은 채 닫지 않는다.
- 권한이 없는 사람이 실행해야 하는 항목을 필수 점검으로 두지 않는다.
인프라 담당자와 공유할 자료
- 체크리스트 주기와 소유자
- 실패한 항목과 확인 위치
- 관련 dashboard, log query, runbook 링크
- 최근 변경과 장애 이력
- 자동화할 수 있는 점검 항목
- 권한이나 접근 경로 문제
종료 조건
체크리스트 점검은 다음 상태가 되어야 완료다.
- 모든 항목이 PASS, WARN, FAIL 중 하나로 기록됐다.
- WARN/FAIL 항목의 다음 행동과 담당자가 정해졌다.
- 장애로 이어질 수 있는 항목은 관련 Runbook으로 연결됐다.
- 오래된 항목 또는 중복 항목을 정리할 작업이 생겼다.
- 다음 점검 시각이 정해졌다.
확인 질문
확인 질문
- 체크리스트 항목이 실무적으로 유효하려면 무엇이 필요한가?
- 확인 위치, 기대 상태, 실패 시 다음 행동, 소유자, 주기가 필요하다.
- 배포 전 점검과 일일 점검의 차이는 무엇인가?
- 배포 전 점검은 변경 위험을 확인하고, 일일 점검은 운영 중 이상 신호를 찾는다.
- 장애 후 체크리스트를 업데이트해야 하는 이유는 무엇인가?
- 실제 장애에서 빠진 단계와 지연 원인을 다음 점검에 반영해야 반복을 줄일 수 있기 때문이다.
리뷰 체크포인트
- 점검 주기가 배포 전, 일일, 주간, 장애 후로 나뉘어 있는가?
- 각 항목이 예/아니오로 답할 수 있는가?
- WARN/FAIL의 다음 행동이 있는가?
- 마지막 검증일과 소유자가 있는가?
- 장애 후 업데이트 절차가 포함되어 있는가?