고객 결과물을 중심으로 준비 정의하기
인프라 라벨이 아니라 결과물로부터 시작하세요. 도달 가능한 홈페이지가 있다고 해도 방문자가 중요한 과업을 완료할 수 없다면 충분하지 않습니다. 각 중요 여정마다 누가 무엇을 시도하는지, 성공의 정의는 무엇인지, 어떤 결과가 받아들일 수 없는지 명시하세요. 팀이 실제 결정을 내릴 수 있도록 몇 가지 여정으로 시작하세요.
각 단계는 필수(essential), 중요(important), 연기 가능(deferrable)으로 분류하세요. 필수는 해당 단계 없이는 여정이 끝나지 않음을 의미합니다. 중요는 제한적 임시 대체로 허용될 수 있고, 연기 가능은 생략, 지연, 단순화할 수 있습니다. 이는 엔지니어링이 참고하는 제품 결정으로 보편 기술적 순위가 아닙니다.
페이지 응답 목표만 기록하지 말고 주문이 접수되어 확인이 저장되는 등 사용 가능한 결과를 기록하세요.
종속성을 도표화하고 무엇을 저하시킬 수 있을지 결정하기
각 핵심 경로에 대해 호스팅/전달, DNS, 애플리케이션 서비스, 데이터베이스, 인증, 이메일, 결제, 검색, 태그, 동의 툴링, 외부 API를 맵으로 만드세요. 각 항목이 불가용할 때의 소유자, 지원 경로, 관련 한계, 사용자 영향도 기록하세요. OWASP는 소프트웨어 종속성에 대한 통찰을 권장하는데 동일한 소유권 규율이 운영상 종속성에도 도움이 됩니다.
하드 종속성은 실패 시 작업을 중단시킵니다. 소프트 종속성은 부재하거나 오래된 상태여도 핵심 작업이 계속될 수 있습니다. AWS는 우아한 저하(graceful degradation)를 통해 종속성이 비정상일 때 핵심 기능을 유지할 것을 설명합니다. 제품별 선택으로 비필수 위젯을 숨기거나 리포트를 연기하거나 정직한 대체(fallback)를 제시하세요. 재고, 가격, 주문 상태, 결제 결과를 임의로 생성하지 마세요.
각 항목에 대해 목적, 소유자, 알려진 한계, 대체 방법, 변경 연락처, 마지막 테스트 날짜를 캡처하세요.
트래픽 예측을 용량 실험으로 전환하기
단일 트래픽 수치가 아니라 시나리오를 사용하세요. 이벤트, 도착 패턴, 요청 믹스, 로그인 사용자 비율, 지리적 분포, 동시 결제/쓰기 활동, 피크 기간을 명시하세요. 상향 케이스와 가정도 포함하세요. Google은 요청마다 자원 비용이 크게 다를 수 있어 초당 요청 수만으로는 부적절한 용량 모델이 될 수 있음을 지적합니다.
승인과 안전장치를 갖춘, 운영에 가까운 구성에서 지속적이고 대표성 있는 엔드투엔드 트래픽을 테스트하세요. AWS는 구성요소만 테스트하거나 대표성이 없는 요청 하위집합을 사용하거나 예상 부하보다 적은 마진에서 멈추는 것을 경고합니다. 최초 제약이나 느려짐을 문서화하세요. 실사용 환경 테스트는 고객에 영향을 줄 수 있으므로 통제된 환경을 사용하거나 계획된 인력 배치된 연습이어야 합니다.
시나리오, 구성, 요청 믹스, 기간, 관찰된 제약, 용량 변경, 후속 책임자를 기록하세요.
변경·롤백·복구 선택지 준비하기
중요 변경 전에 복원할 아티팩트나 구성, 필요한 승인, 권한 있는 담당자, 검증 방법을 식별하세요. 배포 일시중지, 배포 되돌리기, 기능 플래그 비활성화, 비핵심 통합 축소, 승인된 절차로 데이터 복원 등의 짧은 런북을 준비하세요. 이벤트 전에 절차의 기동을 테스트하세요. 실행해보지 않은 백업이나 롤백 계획은 가정에 불과합니다.
비즈니스 영향으로부터 복구 목표를 설정하세요. 복구 시간 목표(Recovery Time Objective, RTO)는 서비스가 복구되기까지 허용 가능한 최대 지연입니다. 복구 시점 목표(Recovery Point Objective, RPO)는 마지막 복구 시점에서 허용 가능한 최대 데이터 손실입니다. AWS는 임의적이거나 비현실적 목표를 경계하고 종속성 목표가 달성 가능성에 영향을 준다고 지적합니다. 목표는 고객 약속이 아니라 계획 목표로 다루세요.
제한적이고 안전한 롤백 또는 복원을 검증하고, 누가 무엇을 확인했는지 및 발견된 차이를 기록하세요.
긴급 판단이 필요하기 전에 소유권 할당하기
연락처 목록만으로는 소유권이 아닙니다. 각 핵심 경로에 대해 허용 가능한 결과의 비즈니스 소유자, 구현의 기술 소유자, 보호 조치를 결정할 권한이 있는 의사결정 소유자를 할당하세요. 백업을 지정하고 공급업체, 에이전시, 결제사, 내부 팀 중 누가 다음 조치를 책임지는지 명확히 하세요.
트래픽 도달 전에 짧은 준비 리뷰를 진행하세요. 한 가지 종속성 실패를 시연하며 무엇이 남아 있는지, 어떤 수단이 안전한지, 누가 승인하는지, 성공을 어떻게 확인하는지 살펴보세요. 이는 사전 리허설이지 실시간 상태 보고가 아닙니다. 날짜가 있는 조치, 소유자, 기한을 기록하세요.
보호 조치가 불명확한 승인 체인을 기다리지 않도록 적절한 범위 내에서 사전 승인된 안전 조치를 마련하세요.
결제 및 보안 민감 경로는 더 엄격히 다루기
체크아웃 준비는 가용성뿐 아니라 정확성도 보존해야 합니다. 권한 부여를 우회하거나 접근 제어를 약화하거나 자격 증명을 노출하거나 결제 페이지 스크립트를 함부로 변경하지 마세요. PCI SSC 가이던스는 결제 페이지 스크립트와 보안 영향 HTTP 헤더의 권한, 무결성, 변조 탐지에 관해 다룹니다. 카드 결제를 수락하거나 임베디드 결제 프레임을 사용하는 경우 상인, 프로세서, 인수사, 자격 있는 보안 또는 컴플라이언스 자문가에게 중요한 변경을 검토받으세요.
프로덕션 스크립트, 통합, 버전, 계정 소유권의 목록을 유지하고 변경 권한을 제한하세요. OWASP는 종속성 목록과 버전 고정이 빌드에 들어오는 요소의 불확실성을 줄일 수 있고 자동화된 발견은 여전히 수동 검증이 필요하다고 지적합니다. 이러한 관행은 준비를 지원하지만 PCI 준수를 확립하거나 보안 평가를 대체하지 않습니다.
항상 프로세서가 승인하고 검토한 대체 흐름만 사용하세요; 비공식 경로로 카드 정보를 수집하지 마세요.