호스팅 플랜이 아니라 워크로드부터 시작하세요
가치나 위험을 만드는 여정들을 나열하세요: 첫 방문, 검색, 로그인, 상품 상세, 양식 제출, 체크아웃, 에디터 업데이트 또는 API 호출. 각 경로별로 최대 요청량 또는 동시 사용자, 페이로드, 개인화 수준, 의존성, 방문자 지역을 기록하세요. 예약 작업과 관리자 작업도 같은 자원을 소비하므로 포함하세요.
목록을 수용 기준으로 전환하세요. Largest Contentful Paint(LCP)는 주요 콘텐츠 로딩을, Interaction to Next Paint(INP)는 반응성을, Cumulative Layout Shift(CLS)는 예기치 않은 레이아웃 이동을 측정합니다. Google은 좋은 목표로 LCP를 2.5초 이내, INP를 200밀리초 미만, CLS를 0.1 미만으로 제시합니다. 경로 완료, 서버 응답 시간, 오류율 목표도 추가하세요.
빠른 캐시된 페이지를 인증되거나 데이터베이스 기반 트랜잭션의 대체물로 삼지 마세요.
피크 기간, 예상 성장, 캠페인 스파이크, 중첩 배치 작업을 정의하세요.
각 병목 가능 지점이 호스트, 내부 팀 또는 제3자 중 누가 제어하는지 표시하세요.
용량, 한계 및 확장 동작을 비교하세요
오퍼에 숨겨진 한계를 요청하세요: 컴퓨트와 메모리, 스토리지 성능, 데이터베이스 연결, 워커 한계, 네트워크 요금, 요청 제어, 공유 이웃 제약 등. “무제한 대역폭”은 피크 시 uncached 작업을 충분히 처리할 수 있는지를 보여주지 않습니다. 어떤 메트릭을 볼 수 있는지와 얼마나 오래 보존되는지도 확인하세요.
스케일링은 트리거, 지연, 상한 및 가격이 알려질 때만 의미가 있습니다. 자동인지, 세션과 작업이 안전한지, 상한에 도달하면 무슨 일이 발생하는지 확인하세요. 이론적 용량 주장보다 예상 피크 및 그 이상에서의 테스트를 선호하세요. 여유분(headroom)은 보편적 비율이 아니라 비즈니스 결정입니다.
평균만 보지 말고 p95 또는 p99 응답 시간을 비교하세요.
테스트 중 데이터베이스, 큐, 업스트림 API 타이밍을 수집하세요.
확장, 전달, 백업, 보조 리전 비용을 약정 전에 추정하세요.
오리진을 의도적으로 배치하고 전달을 검증하세요
오디언스 위치, 애플리케이션 의존성, 데이터 위치 요구, 운영 접근성을 고려해 오리진 리전을 선택하세요. 대표 지리 및 네트워크 조건에서 테스트하세요. CDN(콘텐츠 전송 네트워크)은 적격 자산을 방문자 근처에서 제공해 오리진 작업을 줄이는 분산 캐시이지만, 건강한 오리진·데이터베이스·애플리케이션을 대체하지는 않습니다.
대시보드 설정뿐 아니라 헤더와 동작을 검사하세요. 버전 관리된 정적 자산은 업데이트 시 새 URL을 가지므로 보통 더 긴 수명을 줄 수 있습니다. 동적·개인화 응답에는 명시적 규칙이 필요합니다. HTTP는 공유 캐시와 개인 캐시를 구분합니다; 계정 상세는 다른 고객이 재사용할 수 없어야 합니다. 캐시 퍼지와 롤백을 리허설하세요.
캐시 상태가 다르므로 첫 방문과 재방문을 캡처하세요.
페이지, 자산, 쿠키, 파라미터, 로케일에 대한 Cache-Control 및 캐시 키를 검증하세요.
권한 있는 직원이 민감한 콘텐츠를 노출하지 않고 유해한 규칙을 비활성화하는 방법을 문서화하세요.
복구 증적을 성능 요건으로 다루세요
무엇이 백업되는지, 복사본이 어디에 있는지, 보존 기간, 복원 권한, 백업이 데이터베이스·업로드·코드·구성·인프라를 모두 포함하는지 물어보세요. RPO(복구 시점 목표)는 시간 단위의 허용 데이터 손실, RTO(복구 시간 목표)는 허용 복구 시간을 의미합니다. 둘 다 패키지 기본값이 아니라 비즈니스 영향을 기준으로 설정하세요.
성공적 백업은 복구 증명이 아닙니다. CISA는 정기적 복구 테스트를 권장하고 AWS는 재해 복구를 평가·테스트할 것을 말합니다. 최근 복사본을 격리된 환경에 복원하고, 중요한 레코드와 미디어를 확인하며, 문서화된 순서를 사용하고, 경과 시간을 기록하세요. 대체 리전은 일부 위험을 줄이지만 비용과 복잡성이 증가합니다.
현재 데이터를 덮어쓰지 않고 파일이나 레코드 하나를 복구하세요.
복원 접근을 제한하고 복구 자격 증명과 런북을 권한 있는 대응자에게 제공하세요.
데이터베이스 스냅샷이 설정, 애플리케이션 버전, 전달 규칙을 재현하지 못할 수 있습니다.
필요할 때를 대비해 지원 및 책임 분담을 평가하세요
지원 범위, 시간, 채널, 에스컬레이션, 플랫폼 사건과 애플리케이션 트러블슈팅의 차이를 비교하세요. 패치, 관리형 데이터베이스, TLS, 방화벽 규칙, 백업 및 복원에 대한 서면 책임을 요구하세요. 현실적인 시나리오에서 소유자와 다음 행동을 명시한 지원 약속이 유용합니다.
접근 역할, MFA, 감사 로그, 비밀 관리, 계정 분리를 검토하세요. 결제 카드나 규제된 민감 데이터는 호스팅 기능만으로 준수를 보장하지 않습니다. 이 비교를 기술 입력으로 사용하고 결제 아키텍처와 적용 의무에 대해 적격한 보안·법무·준수 검토를 받으세요.
복원이 실패했을 때, DB 포화, 또는 유해한 캐시 규칙 발생 시 공급자가 어떻게 처리할지 물어보세요.
누가 프로덕션을 변경하고, 백업을 읽고, 로그를 보고, 자격증명을 생성할 수 있는지 확인하세요.
서비스 크레딧과 관리 범위에는 실질적 조건이 있을 수 있습니다.
현실적이고 안전한 비교 테스트를 실행하고 스코어카드를 유지하세요
모든 후보에 대해 동일한 릴리스, 구성 의도, 테스트 스크립트를 사용하세요. 베이스라인, 예상 피크, 짧은 스파이크, 지속 기간, 안전한 복구 또는 배포 연습을 실행하세요. AWS는 프로덕션과 유사한 환경, 정의된 시나리오, 아키텍처 전체 모니터링, 익명화되거나 합성된 데이터, 정기 재테스트를 권장합니다. 공급자 승인을 받고 테스트 정책을 준수하세요.
제어된 랩 테스트와 출시 후 필드 데이터를 결합하세요. 랩 테스트는 디버깅에 재현 가능하고, 필드 데이터는 실제 기기·네트워크·지리·캐시 상태·행동을 반영합니다. 주요 릴리스나 의존성 변경 후 스코어카드를 재검토하세요. SIU는 발견사항을 출시 전 강화, 소유자 지정 시정, 롤백 준비 개선으로 전환할 수 있습니다.
위치, 동시성, 캐시 상태, 페이로드를 일관되게 유지하세요.
경로 타이밍, 오류, 리소스 메트릭, 버전, 비용, 관찰을 저장하세요.
문서화된 요구를 충족하고 지속 가능한 운영비를 가진 옵션을 선택하세요.