리소스 우선순위: SLA 먼저, 비용은 그다음

리소스 우선순위, 뭐부터 정해야 할까?

결론부터 쓴다. 비용표를 열기 전에 SLA(지연시간·가용성·중단 허용도)를 먼저 고정해야 한다. 2026년 기준으로 판교에서 두 번의 "비용 최적화 스프린트"를 돌려보니, 컴퓨트 단가부터 건드린 쪽은 거의 매번 설계를 다시 뜯었다. 리소스 우선순위는 SLA → 비용 지배항목 → 컴퓨트 단가, 이 순서로 내려가야 재작업이 줄었다.

• SLA가 깨지면 손해가 큰 워크로드(동기식 API, 엄격한 P99)는 스팟·콜드스타트 허용 대상에서 먼저 제외한다
• 비용표를 보기 전에 "이 트래픽에서 전송비가 지배항목인지, 요청 수가 지배항목인지"부터 확인한다
• 캐시 적중률 90%를 가정한 공식 비용 예시도 적중률이 무너지면 구조가 바뀐다
• 커밋형 할인은 30~60일 사용량 기준선 없이 들어가면 손해로 돌아올 수 있다
• 오토스케일은 비용 절감 도구가 아니라 SLA 제어면으로 먼저 설계해야 한다

SLA 기준선부터 고정해야 비용 계산이 의미가 있는 이유는?

비용 숫자는 SLA 조건이 고정됐을 때만 비교 가능하기 때문이다. AWS의 이미지 변환 파이프라인 비용 예시는 평균 이미지 45KB, 처리시간 350ms, 캐시 적중률 90%라는 조건을 못 박아야만 CloudFront 1,200달러, Lambda 10.93달러, S3 10.40달러라는 숫자가 성립한다. 이 조건 중 하나라도 바뀌면 — 예를 들어 캐시 적중률이 90%에서 70%로 떨어지면 — 원본 S3 요청, 함수 실행, 원본 리전 전송이 동시에 늘어나 총비용 1,203.48달러는 더 이상 유효하지 않다출처: AWS 공식 문서.

실무에서는 평균 적중률만 대시보드에 찍고 넘어가는 경우가 많은데, 콘텐츠 유형별 적중률과 P95·P99 원본 회귀율을 따로 측정하지 않으면 캐시 정책을 바꾼 뒤 비용이 왜 올랐는지 설명하지 못한다. SLA를 먼저 고정한다는 건 결국 "이 시스템이 몇 ms 안에, 몇 % 확률로 응답해야 하는가"를 숫자로 박아두고, 그 숫자를 깨지 않는 범위 안에서만 컴퓨트·전송 선택지를 비교한다는 뜻이다.

컴퓨트는 온디맨드·서버리스·스팟 중 뭘 써야 할까?

답은 "중단 허용도"에 달려 있다. 2025년 시뮬레이션 벤치마크에서 Aurora Serverless v2는 버스트 워크로드 조건에서 RDS PostgreSQL 대비 최대 45% 비용 절감(월 75.20달러 대 105달러)을 보였고, 최대 부하에서 처리량은 약 940 QPS까지, 쿼리 지연시간은 조건에 따라 최대 30~40% 낮아졌다. 다만 같은 연구에서 콜드 스타트와 스토리지 재수화에 따른 지연 비용이 함께 확인됐다출처: 시뮬레이션 벤치마크. 즉 트래픽이 들쭉날쭉한 배치성 워크로드에는 유리하지만, 콜드 스타트가 SLA를 침범하는 동기식 API에는 그대로 적용하기 어렵다.

서버리스 플랫폼 간 차이도 있다. 2025년 서버리스 인프라 연구는 HTTP 서버 방식 플랫폼(GCP·Azure 경향)이 API 폴링·바이너리 실행 방식보다 오버헤드가 높고, 평균 지연 오버헤드가 최대 5.93ms로 측정됐다고 보고한다출처: arXiv 연구. 짧은 요청이 초당 수백~수천 건 몰리는 API라면 이 수치가 P99 지연과 호출당 과금에 누적된다. 스팟 인스턴스는 가격만 보고 고르기보다, 재시작 가능한 배치·CI·분산 학습처럼 중단을 흡수할 수 있는 작업과 엄격한 P99 SLA를 요구하는 작업을 먼저 분리하는 편이 안전하다. 2025~2026년 구간의 스팟 중단률을 일반화할 만큼 신뢰도 높은 공식 실측치는 확인되지 않았으므로, 이 글에서도 특정 절감률을 단정하지 않는다.

진짜 비용을 갉아먹는 건 컴퓨트가 아니라 전송일까?

트래픽이 커질수록 그렇다. AWS 예시에서 1,000만 장 처리 시 총비용 1,203.48달러 중 CloudFront가 1,200달러, Lambda는 10.93달러였다. 트래픽이 5억 장으로 늘어나면 총비용은 11,192.13달러까지 올라가는데, 그중 CloudFront가 11,000달러, Lambda는 146.46달러, S3는 120달러, CloudWatch는 175.67달러다출처: AWS 공식 문서. 함수 실행시간이 아니라 전송량과 요청 수가 비용 구조를 지배한다는 뜻이다. 이 조건에서는 Lambda 메모리를 아무리 튜닝해도 전체 비용은 크게 움직이지 않는다.

반대로 소형 객체가 많을 때는 전송비가 아니라 요청·메타데이터 비용이 지배항목이 된다. AWS Data Transfer Hub 사례에서 평균 파일 크기 50MB로 1TB를 전송하면 총비용 94.48달러 중 92.16달러가 전송비였지만, 평균 파일 크기가 10KB로 작아져 파일 수가 약 1억 740만 개로 늘면 총비용이 1,113.87달러로 뛰고 그중 S3 요청 622.34달러, DynamoDB 268.25달러, SQS 85.92달러가 전송비 92.16달러보다 커졌다출처: AWS 공식 문서. 즉 대용량 파일 파이프라인에서는 전송 단가를, 소형 객체 다수 처리에서는 객체 병합·배치 처리·요청 수 감소를 먼저 검토할 근거가 있다.

오토스케일 정책을 비용 절감 도구로만 써도 될까?

그렇게 쓰면 절반만 맞는다. 오토스케일링은 비용 최적화보다 SLA 제어면으로 설계해야 효과가 분명하다. 2026년 클라우드 비용 분석 자료는 마이그레이션 단계부터 오토스케일링을 구성하고, 중앙 인스턴스 기준선을 중간 부하에 맞춘 뒤 피크를 스케일러가 처리하는 방식을 제안한다출처: 클라우드 마이그레이션 ROI 분석. 다만 "중간 부하 기준"을 정답으로 못 박기보다, CPU·메모리·큐 길이·요청 지연시간별 스케일아웃 조건과 안정화 시간(cooldown)을 각각 기록해야 재현 가능한 정책이 된다.

같은 자료는 커밋형 할인(AWS Compute Savings Plans, Azure Reserved VM Instances, GCP Committed Use Discounts)이 안정적인 워크로드에서 약 30~60% 비용 절감 효과를 낼 수 있다고 설명하면서, 커밋 전 30~60일의 사용량 기준선 확보를 권고한다. 평균 사용량이 아니라 최소 보장 사용량, 피크 비율, 마이그레이션 후 인스턴스 타입 변경 가능성을 함께 기록하지 않으면 커밋이 오히려 과금 바닥을 깔아버린다.

실측 수치로 보면 지배항목이 어떻게 갈릴까?

같은 시스템이라도 트래픽 규모와 리전에 따라 지배항목이 뒤바뀐다. 리전 선택도 비용과 SLA 경로를 동시에 바꾸는데, AWS는 2025년 3월 기준 미국 리전에서 인터넷으로 나가는 CloudFront 데이터 전송을 첫 10TB에 0.085달러/GB, 인도 리전은 0.109달러/GB로 제시했다출처: AWS 네트워킹 블로그. 동일한 캐시 적중률과 트래픽이라도 사용자 분포와 서빙 리전에 따라 전송비가 달라지므로, 비용 비교에는 리전·사용자 위치·트래픽 방향을 고정해 기록해야 한다.

처리량	CloudFront	Lambda	S3	총비용
1,000만 장	1,200달러	10.93달러	10.40달러	1,203.48달러
1억 2,500만 장	-	-	-	1,249.25달러
5억 장	11,000달러	146.46달러	120달러	11,192.13달러

표에서 보이듯 처리량이 50배 늘 때 Lambda 비용은 약 13배 늘지만 CloudFront는 거의 9배 늘어나 비중이 더 커진다출처: AWS 공식 문서. 실측 보고서를 쓸 때는 제품명·버전, 리전, 메모리·CPU 설정, 캐시 적중률, 동시 요청 수, 측정 기간, 평균·P95·P99 지연시간, 오류율, 비용 산식을 함께 남겨야 다른 조건에서 재검증할 수 있다.

이 선택에서 자주 놓치는 함정은?

가장 흔한 함정은 네트워크 경로다. 프라이빗 서브넷의 EC2가 NAT Gateway를 통과해 S3에 접근하면 처리 데이터 1GB마다 0.045달러의 NAT 데이터 처리 요금이 추가될 수 있는데, 이 비용은 애플리케이션 비용표에 바로 드러나지 않는다출처: Cloudburn 비용 분석. S3 VPC 엔드포인트를 검토하지 않으면 몇 달 뒤 청구서에서야 발견하는 경우가 많다.

두 번째 함정은 "CDN이면 항상 싸다"는 단정이다. 같은 분석 사례는 월 1TB 공개 콘텐츠를 S3에서 직접 제공하면 전송비가 약 83달러, CloudFront를 경유해 90%를 캐시하면 CloudFront 전송비가 약 78달러로 산정된다고 제시한다. 차이가 크지 않은데도 캐시 미스가 늘거나 요청 요금이 더해지면 역전될 수 있으므로, 캐시 적중률과 전송 경로를 구체적으로 계산하지 않고 "CDN 도입=비용 절감"으로 단정하면 안 된다. 리전 간 복제도 마찬가지다. 저장공간이 두 배가 되고 미국 리전 간 CRR에서 0.02달러/GB의 전송비가 추가될 수 있는데, 장애 복구 목표(RPO·RTO)가 명확하지 않은 상태에서 다중 리전 복제부터 넣으면 복구력 개선 없이 비용만 늘어난다.

결론: 어떤 상황에 무엇을 고르나?

정리하면 리소스 우선순위는 세 단계로 내려간다. 먼저 SLA(지연시간·가용성·중단 허용도)를 숫자로 고정하고, 그다음 이 트래픽에서 비용의 지배항목이 전송인지 요청 수인지 컴퓨트인지 찾은 뒤, 마지막으로 컴퓨트 단가(온디맨드·스팟·서버리스)를 고른다.

• 동기식 API처럼 P99가 엄격하면 스팟·콜드스타트 허용 영역에서 제외하고, 배치·CI·분산 학습처럼 재시작 가능한 작업에 스팟을 우선 배치한다
• 트래픽이 커질수록(수억 건 단위) 전송·CDN 비용이 컴퓨트 비용을 압도할 수 있으니 함수 메모리 튜닝보다 캐시 적중률과 전송 경로를 먼저 본다
• 소형 객체가 많은 파이프라인에서는 전송비보다 요청·메타데이터 비용이 커질 수 있어 객체 병합·배치 처리를 먼저 검토한다
• 커밋형 할인과 다중 리전 복제는 30~60일 기준선과 명확한 RPO·RTO 없이 들어가면 비용만 늘 수 있다
• 오토스케일 정책은 비용 절감이 아니라 SLA 제어면으로 설계하고, 스케일아웃 조건과 안정화 시간을 CPU·큐 길이·지연시간별로 따로 기록한다

핵심 정리

• 리소스 우선순위는 SLA 고정 → 비용 지배항목 파악 → 컴퓨트 단가 최적화 순서로 내려가야 재작업이 줄어든다
• 트래픽 규모가 커질수록(1,000만 장 → 5억 장) Lambda 컴퓨트보다 CloudFront 전송비 비중이 커진다(1,200달러 → 11,000달러)
• 평균 파일 크기가 작아지면(50MB → 10KB) 전송비가 아니라 S3 요청·DynamoDB·SQS 등 요청·메타데이터 비용이 지배항목이 된다
• 커밋형 할인과 다중 리전 복제는 30~60일 사용량 기준선, 명확한 RPO·RTO 없이 들어가면 비용만 증가할 수 있다
• 스팟 인스턴스는 절감률보다 중단 허용도로 배치 대상을 가르는 편이 안전하다