AWS 백엔드 운영 체크리스트

Overview

운영 체크리스트는 기억을 대신하는 품질 장치다. 특정 고객 환경의 명령과 주소가 아니라 변경 전 가설, 실행, 관측, 중단, 복구 조건을 표준화한다.

한 문장 설명: 좋은 운영 절차는 정상 실행 방법뿐 아니라 실패를 알아채고 되돌리는 방법까지 포함한다.

왜 필요한가

설치와 배포는 여러 서비스와 담당자를 가로지른다. 확인 항목이 사람 머릿속에만 있으면 Secret 누락, SG 미개방, Health 오판, Rollback 지연이 반복된다. Checklist는 빠뜨림을 줄이고 사후 학습을 다음 변경에 반영한다.

핵심 원리

변경마다 Owner, 영향 범위, 의존성, 성공 지표, 중단 기준, Rollback, 소통 채널을 정한다. Production 비밀값과 고객 식별 정보는 티켓·Wiki에 평문으로 남기지 않는다. 한 번에 여러 변수를 바꾸지 않고 관측 가능한 작은 단위로 진행한다.

내부 동작

flowchart LR; P[사전 점검] --> C[변경 승인]; C --> D[점진 배포]; D --> O{지표 확인}; O -->|정상| F[완료·기록]; O -->|중단 기준 초과| R[Rollback]; R --> V[복구 검증·회고]

배포 전에는 Artifact와 Config 차이, Migration 호환성, Capacity를 확인한다. 배포 중에는 Error Rate, Latency, Saturation과 Business 지표를 본다. 배포 후에는 Target/Consumer/DB 상태와 Alarm을 확인하고 변경 기록을 남긴다.

쉬운 비유

항공기 Checklist는 조종사를 못 믿어서가 아니라 반복 작업에서도 치명적인 한 항목을 빠뜨릴 수 있기 때문에 쓴다. 운영도 숙련도와 무관하게 동일하다.

Example

사전: Backup 복원 가능성, 인증서, Secret 권한, SG 관계, DB Migration의 하위 호환성을 확인한다.
중간: Canary 비율과 중단 임계치, 담당자를 확인한다.
사후: Error Budget 영향, 비용 증가, 로그의 개인정보 노출, 임시 Rule 제거를 확인한다.

실무에서 발생하는 문제

Rollback 불가능한 DB Migration, 과도한 IAM/SG 임시 권한, 관측 없는 심야 변경, 담당자 없는 Alarm이 흔하다. 문서가 너무 길고 실제 순서와 다르면 Checklist가 형식으로 전락한다.

Trade-off

승인과 점검은 속도를 늦출 수 있지만 장애 복구 비용을 줄인다. 모든 변경에 같은 무게를 적용하지 말고 위험도에 따라 자동화와 승인 수준을 다르게 한다. 긴 Runbook은 상세 참고용, 실행 Checklist는 짧게 분리한다.

흔한 오해

Backup 존재와 복원 가능은 다르다.
Rollback Script가 있다는 것과 제한 시간 안에 복구 가능한 것은 다르다.
Managed Service도 Patch, Capacity, 비용, 권한 검토가 필요하다.
임시 허용 Rule은 자동 만료 장치가 없으면 영구 Rule이 되기 쉽다.

Production Considerations

정기적으로 복원, Zone 장애, Dependency Timeout, On-call 연락을 연습한다. IaC Drift와 미사용 자원, 비용 이상을 검사한다. 회고 Action에는 Owner와 완료 기한을 두고, Runbook 마지막 검증일을 기록한다.

Interview Questions / Follow-up Questions

배포 중단 기준에는 어떤 지표가 필요한가?
DB Migration을 안전하게 Rollback하기 어려운 이유는?
후속: 임시 보안 Rule을 안전하게 관리하는 방법은?
후속: Backup 복원 훈련에서 무엇을 측정하는가?

AWS 운영 지도, Incident Response, Observability를 실행 절차로 연결한다.