AWS Well-Architected Framework의 여섯 원칙을 정의하는 것만으로 시스템은 바뀌지 않는다. 목적은 현재 구성의 위험과 의사결정 근거를 찾아 우선순위가 있는 개선 작업으로 만드는 것이다. 이 글은 EC2 한 대, Nginx·PHP-FPM, MariaDB와 S3를 사용하는 소규모 서비스를 가정한 자체 점검 방법을 다룬다.
AWS의 질문과 권장사항은 갱신될 수 있다. 이 글은 2026-08-11에 공식 문서를 확인했으며 실제 검토에서는 최신 AWS Well-Architected Tool의 질문을 기준으로 다시 확인한다.
1. 검토 범위를 먼저 고정
워크로드:
사용자와 핵심 기능:
운영 리전:
구성 요소: DNS / EC2 / EBS / S3 / MariaDB
데이터 중요도와 복구 목표:
최근 장애·변경:
검토 참여자:
검토일:회사 전체 클라우드를 한 번에 검토하지 않는다. 사용자가 경험하는 하나의 기능과 그 기능을 지탱하는 구성으로 범위를 정한다.
2. 여섯 관점에서 증거 찾기
| 관점 | 소규모 서비스에서 확인할 증거 |
|---|---|
| 운영 우수성 | 배포·롤백 런북, 알람, 장애 기록과 담당자 |
| 보안 | IAM 최소 권한, 비밀 저장 위치, TLS, 패치 기록 |
| 신뢰성 | 백업 복원 시험, 단일 장애 지점, 헬스체크 |
| 성능 효율성 | 응답 시간, 자원 사용량, 인스턴스 선택 근거 |
| 비용 최적화 | 월별 비용, 미사용 리소스, 보존·수명 주기 |
| 지속 가능성 | 과다 할당, 불필요한 데이터 처리·전송·보존 |
3. “설정됨”이 아니라 복구 증거 확인
백업 옵션이 켜져 있다는 답변만으로 신뢰성을 확인할 수 없다. 다음처럼 결과를 요구한다.
- 마지막 복원 시험 날짜와 걸린 시간
- 복원된 DB의 행 수·제약조건·애플리케이션 연결 검증
- EC2 교체 시 필요한 설정과 소요 시간
- 담당자가 없어도 실행할 수 있는 복구 절차
- 복구 목표를 만족하지 못했을 때의 개선 항목
4. 발견 사항 기록표
ID: REL-01
관점: 신뢰성
현재 상태: DB 백업은 있으나 복원 시험 기록 없음
사용자 영향: 장애 시 복구 시간과 성공 여부를 예측할 수 없음
근거: 백업 설정 화면 / 복원 기록 부재
개선 작업: 격리 환경 복원 후 무결성·접속 검증
담당자:
기한:
완료 증거:
잔여 위험:“고가용성 강화”처럼 완료를 판정할 수 없는 문구를 피한다. 변경 대상, 완료 조건과 증거를 한 항목에 담는다.
5. 우선순위 정하기
| 우선순위 | 판단 | 예시 |
|---|---|---|
| P0 | 즉시 악용·데이터 손실 가능 | 공개 비밀키, 복구 불가능한 중요 데이터 |
| P1 | 핵심 기능 장시간 중단 가능 | 검증되지 않은 백업, 단일 디스크 의존 |
| P2 | 성능·운영·비용 비효율 | 알람 부재, 과다 할당 인스턴스 |
| P3 | 장기 개선 | 자동화 확대, 문서 정리 |
여섯 관점을 균등하게 한 번에 개선할 필요는 없다. 사용자 영향과 복구 난이도가 큰 항목부터 처리한다.
6. 검토를 반복 가능한 운영 작업으로 만들기
- 큰 배포나 아키텍처 변경 후 기존 답변을 갱신한다.
- 장애 회고에서 새로 드러난 위험을 발견 사항에 추가한다.
- 완료 항목은 설정 화면이 아니라 테스트 결과로 닫는다.
- 분기별로 미완료 고위험 항목과 비용 변화를 확인한다.
- AWS 공식 질문과 문서의 변경 여부를 확인한다.
정리: Well-Architected 검토의 결과물은 여섯 원칙의 요약이 아니라 범위, 근거, 사용자 영향, 담당자와 완료 증거가 있는 개선 작업 목록이어야 한다.
댓글 0