EKS vs AKS vs GKE 비용 비교 2026: 운영 난이도와 숨은 비용까지 정리

EKS, AKS, GKE 중 어떤 쿠버네티스 서비스를 선택할지는 단순 기능보다 운영 난이도와 총비용을 함께 봐야 결정할 수 있습니다. 이 글에서는 2026년 기준으로 관리비, 업그레이드 책임, 권한 체계, 숨은 비용까지 실무 관점에서 비교합니다.

“어차피 쿠버네티스면 다 같은 거 아니야?”

EKS AKS GKE 비용에 대한 이야기를 해 보고자 합니다. 쿠버네티스 API는 비슷해도, 운영 난이도와 비용이 갈리는 지점은 ‘관리형이 어디까지 관리해 주느냐’입니다. 그리고 그 차이가 바로 장애 빈도, 운영 인력 투입, 그리고 청구서로 이어집니다. 이번 글에서는 2026년 기준으로 EKS(AWS) vs AKS(Azure) vs GKE(GCP)를 운영 난이도(운영자가 뭘 책임져야 하는지) / 비용(클러스터 관리비 + 숨은 비용) 관점에서 비교해볼게요.


먼저 결론: 어떤 팀에 어떤 선택이 “후회가 덜한가”

✅ 운영을 최대한 “서비스처럼” 쓰고 싶다

  • GKE Autopilot: 노드/노드풀을 Google이 항상 만들고 관리(오토 생성/관리)해주는 구조라 운영 난이도를 크게 낮추는 방향입니다.
  • AKS Automatic: 노드풀 수동 생성 없이 노드 관리/스케일링/자동 업그레이드/노드 리페어 등을 “기본 탑재”로 가져가는 쪽입니다.
  • EKS Auto Mode: 컴퓨트/스토리지/네트워크를 자동화하고 OS 패치·핵심 애드온 관리까지 AWS가 오프로딩하겠다는 방향입니다.

👉 결론적으로 “플랫폼팀이 얇고, 쿠버네티스 전문성이 부족한데도 K8s를 써야 한다”면 Autopilot/Automatic/Auto Mode 계열이 운영 난이도 최저입니다.

EKS AKS GKE 비용

✅ 세밀한 통제(노드 타입, 네트워크, 애드온, 비용 최적화)를 직접 하고 싶다

  • EKS(표준 모드): 가장 AWS답게 “부품 조립형”이라 자유도가 높습니다. 대신 운영자가 챙길 포인트도 많습니다(장점이자 단점).
  • GKE Standard / AKS Standard(일반 노드풀)도 통제가 가능하지만, 각 클라우드의 “권장 레일”을 벗어날수록 운영 난이도가 올라갑니다.

1) 운영 난이도 비교: 실무에서 힘든 6가지 포인트로 보자

아래 6개가 실제 운영 난이도를 결정합니다.

  1. 클러스터 생성/기본 구성
  2. 노드/노드풀 운영(프로비저닝, 스케일링, OS 패치, 업그레이드)
  3. 업그레이드/버전 지원 정책
  4. 권한·인증(IAM/ID 연동)
  5. 네트워킹/인그레스/로드밸런서
  6. 관측성(로그/메트릭/트레이싱) + 운영 표준화

2) 노드 운영 책임: “가장 많이 터지는” 차이

EKS: 관리형 노드 그룹이어도 “노드 업그레이드/전개는 내 책임”

AWS 문서에서 EKS Optimized AMI는 AWS가 최신 패치 버전을 만들지만, Managed Node Group 사용 고객은 최신 AMI로 노드그룹 업그레이드를 수행해야 한다고 명시합니다.

  • 장점: 내가 원하는 타이밍/전략(블루그린/카나리/서지)으로 통제 가능
  • 단점: “컨트롤 플레인 올렸는데 워커노드 안 올려서” 호환성 이슈/보안 공백이 생기기 쉬움

✅ 운영 난이도 줄이고 싶으면: EKS Auto Mode로 오프로딩 범위를 넓히는 선택지가 있습니다. (단, 비용 구조는 아래에서 같이 봅니다.)


GKE Autopilot: 업그레이드·유지보수까지 Google이 자동 관리

GKE Autopilot 개요 문서에 Autopilot은 컨트롤 플레인과 워커 노드 모두의 업그레이드 및 유지보수를 자동으로 관리한다고 안내합니다.

  • 장점: 운영 인력 투입이 확 줄어듦(특히 패치/업그레이드 영역)
  • 단점: “내가 노드를 마음대로 만지는” 영역은 제한될 수 있음(완전 통제보다는 관리형 철학)

AKS Automatic: 노드풀 수동 운영 부담을 줄이는 “기본 탑재형”

AKS Automatic 소개 문서에 노드 관리가 자동이며, 수동 노드풀 생성 없이 스케일링/자동 노드 리페어/자동 업그레이드 등이 구성된다고 설명합니다.

또한 Azure의 AKS 가격 페이지는 Automatic은 노드를 관리해 주고, Standard는 사용자가 노드풀을 만들고 관리한다는 비교를 보여줍니다.


3) 인증/권한(IAM) 난이도: 팀 문화에 따라 체감이 갈린다

EKS: “AWS IAM ↔ Kubernetes RBAC” 매핑이 핵심

EKS는 aws-auth ConfigMap이 AWS IAM 사용자/역할을 Kubernetes RBAC 권한으로 매핑한다고 명시합니다.

  • AWS IAM 중심 조직(보안/감사 체계가 IAM 기준인 팀)에게는 강점
  • 반대로 “쿠버네티스 RBAC만 알던 팀”은 초기에 낯설 수 있음

AKS: Microsoft Entra ID(구 AAD) + Kubernetes RBAC

AKS 문서에서 Microsoft Entra 통합 + Kubernetes RBAC 흐름을 안내하고, 생성 시 RBAC가 기본 활성화된다고 설명합니다.

  • MS 생태계(Entra, M365, AD/그룹 기반 권한 관리)가 강한 조직이면 운영 난이도가 확 내려감

GKE: Workload Identity Federation이 “권장(Recommended)”

Google 문서에서 Workload Identity Federation for GKE가 대부분의 경우 권장되는 방식이라고 명확히 말합니다.

  • 장점: 워크로드가 Google Cloud API에 접근할 때 “키 파일/시크릿 관리” 부담을 줄이는 방향(보안·운영 측면에서 유리)

4) 운영 난이도 총평(체감 순위)

운영 난이도는 “어떤 모드로 쓰느냐”까지 포함해서 보는 게 현실적입니다.

운영 부담이 낮은 쪽 ←추천 조합(대표)→ 운영 통제가 강한 쪽
GKE Autopilot(Google이 노드/업그레이드 관리)GKE Standard
AKS Automatic(기본 운영 자동화 탑재)AKS Standard
EKS Auto Mode(AWS가 더 많이 오프로딩)EKS 표준(Managed Node Group/Karpenter 등)

5) 비용 비교: “클러스터 관리비 + 데이터 플레인 + 숨은 비용”으로 나눠라

쿠버네티스 비용을 한 줄로 요약하면 이렇게 됩니다.

총비용 = (클러스터 관리비) + (노드/파드 컴퓨트) + (LB/스토리지/로그/네트워크) + (버전 지원/옵션 과금)

여기서 많은 팀이 클러스터 관리비(컨트롤 플레인 비용)를 놓치거나,
반대로 관리비만 보고 “싸다/비싸다”를 결론냅니다.

실제는 노드/네트워크/로그가 더 크게 나오는 케이스가 많아요.


6) 클러스터 관리비(컨트롤 플레인 비용) 2026년 기준

✅ EKS

  • 표준 지원 Kubernetes 버전: $0.10 / 클러스터·시간
  • 확장 지원(Extended support): $0.60 / 클러스터·시간 (표준 $0.10 + 추가 $0.50)

또한 EKS는 “Provisioned Control Plane(더 큰 티어)”를 선택하면 $1.65/hr(또는 그 이상) 같은 별도 과금이 추가됩니다.


✅ GKE

  • 클러스터 관리비: $0.10 / 클러스터·시간 (모드/토폴로지와 무관)
  • 무료 티어 크레딧:$74.40 (대략 “zonal Standard 1개 또는 Autopilot 1개” 수준)
  • 확장(extended support) 기간 추가 관리비: 추가 $0.50/hr → 총 $0.60/hr

✅ AKS

AKS는 Free(무 SLA), Standard(SLA), Premium(SLA+LTS) 형태로 “클러스터 관리 티어”가 나뉩니다.

Azure 가격 페이지 검색 스니펫 기준으로는(표시 단위 Month):

  • Free: 관리비 Free(리소스만 과금)
  • Standard(SLA): $73 / 클러스터·월
  • Premium(SLA+LTS): $438 / 클러스터·월

참고: $73/월, $438/월은 “월 730시간 기준”으로 환산하면 각각 대략 $0.10/hr, $0.60/hr 수준입니다(단순 계산).

또한 Microsoft 문서에서 Standard/Premium은 Uptime SLA가 기본 포함이며, AZ 사용 시 99.95%, 미사용 시 99.9%를 안내합니다.


7) “관리비만” 놓고 보면 현실은 이렇다

  • EKS 표준 vs GKE 표준: 둘 다 $0.10/hr(대략 월 $72~$74)로 비슷합니다.
  • AKS Free tier: 관리비가 0이라 개발/학습에는 유리하지만, Azure도 Free tier는 대규모/고가용성 용도가 아니다라고 FAQ에서 분명히 선을 긋습니다(>10 노드 규모/HA 요구 비권장).
  • 버전 업그레이드 미루면 “확장 지원비” 폭탄: EKS는 Extended support가 $0.60/hr로 뛴다고 명시되어 있습니다. GKE도 extended support 기간 추가 관리비로 총 $0.60/hr가 됩니다.

8) 데이터 플레인(노드/파드) 과금: “어떻게 청구되느냐”가 다르다

EKS

  • 기본은 EC2 인스턴스 비용(노드) + EKS 관리비
  • EKS Auto Mode는 Auto Mode가 런칭/관리한 EC2의 “추가 과금(EC2 비용 외 별도)”이 붙고, 초 단위(1분 최소) 청구라고 안내합니다.

즉, “운영을 덜어주는 만큼” 비용 구조가 추가로 생길 수 있습니다.


GKE

  • Standard 노드풀: 노드의 Compute Engine 인스턴스 비용을 그대로 냅니다.
  • Autopilot(파드 기반): 실행 중인 파드가 요청(request)한 CPU/메모리/임시 스토리지 기준으로 과금되는 Pod-based billing을 설명합니다.

운영자 관점에서 중요한 포인트는 이거예요.

Autopilot은 “노드 빈 공간”을 줄일 수 있지만,
리소스 request를 크게 잡으면 그대로 과금이 커진다.


AKS

  • 기본적으로는 VM(노드) 비용 + 네트워크/스토리지 + (선택한 티어의 관리비) 구조입니다.
  • AKS Automatic은 노드 운영을 더 오프로딩하지만, 비용 자체는 결국 노드/리소스 사용량에 크게 좌우됩니다.

9) 숨은 비용 Top 6: “K8s는 공짜인데 청구서가 왜 이래?”의 정체

클라우드 K8s 비용이 튀는 흔한 원인은 보통 여기서 나옵니다.

  1. 로드밸런서(LB) 남발: 서비스마다 LB 붙이면 비용이 기하급수
  2. NAT/이그레스(외부 트래픽) 비용: 크롤러/이미지/다운로드 트래픽이 크면 바로 티가 남
  3. 로그 폭탄: 컨테이너 stdout을 무한정 쌓으면 로그 비용이 월 비용 1등이 되기도 함
  4. 스토리지(PV) 방치: 볼륨/스냅샷/백업 정책 미정리
  5. 클러스터를 환경별로 너무 많이 만들기: “dev/stage/prod + 팀별”로 늘어나면 관리비와 운영비가 같이 늘어남
  6. 버전 업그레이드 지연 → 확장 지원비(특히 EKS/GKE)

10) 비용 예시로 감 잡기: “클러스터 1개를 24/7로 돌리면?”

컨트롤 플레인/관리비만 단순 계산해보면:

  • $0.10/hr × 744시간(31일) = $74.40/월
  • $0.60/hr × 744시간(31일) = $446.40/월

이게 왜 중요하냐면,

“클러스터 수를 줄이는 것”과
“버전 업그레이드를 제때 하는 것”이
운영 노력 대비 비용 절감 효과가 엄청 큰 레버이기 때문입니다.

EKS는 표준 $0.10/hr, 확장 $0.60/hr를 명시합니다.
GKE도 $0.10/hr 관리비, 확장 기간 추가로 총 $0.60/hr 구조를 안내합니다.
AKS는 월 표시 기준 Standard $73/월, Premium $438/월로 안내됩니다.


11) 그래서 무엇을 선택해야 하나: 체크리스트로 결정하자

아래 10개 중 “YES”가 많은 쪽이 정답일 확률이 높습니다.

EKS가 유리한 경우

  • 이미 AWS에 데이터/보안/네트워크가 깊게 묶여 있다
  • IAM 중심으로 권한/감사 체계를 운영한다
  • 노드 타입(Graviton/Spot/특수 인스턴스)까지 세밀하게 최적화하고 싶다
  • 쿠버네티스 운영 경험자(플랫폼팀)가 있다
  • 필요하면 Auto Mode로 운영 부담을 낮추는 선택지도 고려 가능

AKS가 유리한 경우

  • 조직이 Microsoft Entra(AD), Windows, .NET, MS 생태계 중심이다
  • 운영은 단순하게 가고 싶고(Automatic), 그래도 Azure 네이티브로 가고 싶다
  • Free/Standard/Premium 티어로 SLA·지원 기간을 계약적으로 정리하고 싶다

GKE가 유리한 경우

  • 쿠버네티스를 가장 “쿠버네티스답게” 굴리고 싶다(표준/문서/운영 도구 성숙도)
  • Autopilot로 노드 관리·업그레이드 부담을 크게 줄이고 싶다
  • Google Cloud API 접근을 Workload Identity로 깔끔하게 운영하고 싶다
  • 관리비 구조가 명확하고(클러스터당 $0.10/hr), 무료 티어로 1개 클러스터는 상쇄하고 싶다

12) 운영 난이도 & 비용, 한 줄 요약

  • 운영 난이도 최저(관리형 극대화): GKE Autopilot / AKS Automatic / EKS Auto Mode
  • 운영 통제 최강(부품 조립형): EKS 표준(Managed node group 중심) — 대신 노드 업그레이드 같은 책임이 남음
  • 관리비만 보면: EKS와 GKE는 $0.10/hr로 비슷, AKS는 티어에 따라 Free/유료로 갈림
  • 진짜 비용은: 노드/네트워크/로그/버전 지원(확장 지원비)에서 크게 갈린다

FAQ (구글 SEO용)

Q1. EKS/AKS/GKE 중 “무조건 제일 싼” 건 뭔가요?

“클러스터 관리비”만 보면 EKS/GKE는 $0.10/hr 수준으로 비슷하고 , AKS는 Free/Standard/Premium 티어 선택에 따라 달라집니다.
하지만 실제 총비용은 노드/네트워크/로그가 더 큰 비중을 차지하는 경우가 많아서, 워크로드 패턴(트래픽·CPU·메모리·이그레스) 기반으로 비교하는 게 맞습니다.

Q2. GKE Autopilot은 왜 운영이 쉬운가요?

Google 문서에서 Autopilot은 컨트롤 플레인과 워커 노드의 업그레이드/유지보수를 자동 관리한다고 안내합니다.
또한 Autopilot 모드에서는 노드와 노드풀을 GKE가 생성/관리합니다.

Q3. AKS Free tier로 운영(프로덕션)해도 되나요?

Azure는 Free tier가 “실험/개발”에 적합하며, 규모(>10 노드)나 고가용성을 요구하는 용도가 아니라고 FAQ에서 설명합니다.
프로덕션이라면 보통 Standard(SLA) 이상을 고려하는 게 안전합니다.

Q4. EKS에서 왜 노드 업그레이드가 자주 문제가 되나요?

AWS는 패치된 AMI를 제공할 수 있지만, Managed Node Group 고객이 노드그룹을 최신 AMI로 업그레이드하는 책임이 있다고 안내합니다.
컨트롤 플레인만 올리고 노드를 방치하면 호환성/보안 이슈가 생길 수 있어요.

Q5. 세 클라우드 모두 “버전 지원비 폭탄”이 있나요?

  • EKS는 Kubernetes 버전이 표준 지원을 벗어나면 Extended support로 $0.60/hr가 된다고 명시합니다.
  • GKE도 extended support 기간에 추가 관리비가 붙어 총 $0.60/hr가 될 수 있습니다.
  • AKS는 Premium에서 LTS(장기 지원)를 제공하는 구조가 있습니다.

원하시면, (1) 월 트래픽/피크, (2) 평균 파드 수·리소스 request, (3) 멀티 AZ/멀티 리전 여부만 기준으로
EKS/AKS/GKE 각각에서 월 비용이 어디서 터질지(로그/LB/NAT/관리비/노드)를 “예산 시뮬레이션 형태”로 더 구체적으로 잡아드릴게요.

EKS AKS GKE 비용 비교
AX 100배의 법칙
AX 100배의 법칙
– 나와 조직의 능력을 100배 높이는 AI 경영의 실제

도서 구매

함께 읽으면 좋은 글:

디지털 트랜스포메이션: 조직의 습관을 바꾸는 일, 도서 구매

. .


함께 읽으면 좋은 글

AWS vs Azure vs GCP 비교 2026: 어떤 클라우드가 우리 조직에 맞을까?

AWS, Azure, GCP를 비교할 때는 단순 점유율이나 기능 수보다 비용 구조, AI 활용, 쿠버네티스 운영, 데이터 플랫폼, 기존 조직 생태계까지 함께 봐야 합니다. 이 글에서는 2026년 기준으로 세 클라우드를 실무 관점에서 비교합니다.


2026 클라우드 비교 결론만 먼저

  • AWS: 서비스 폭이 매우 넓고(200+ 서비스), 인프라 선택지가 많아 “클라우드 종합마트”에 가깝습니다. 대신 설계가 복잡해지기 쉽습니다. (Amazon Web Services, Inc.)
  • Azure: 기업/조직(특히 Microsoft 스택)과 하이브리드 운영에 강합니다. ID 체계(Entra)와 관리 체계(Arc)가 “기업 운영 표준”에 가깝습니다. (Microsoft Learn)
  • GCP: 데이터/분석(BigQuery)·Kubernetes(GKE)·서버리스(Cloud Run)를 깔끔하게 가져가고 싶을 때 매력적입니다. 인프라 규모도 2026년 1월 기준 42 리전/127 존으로 강력합니다. (Google Cloud)
2026 클라우드 비교

2026 AWS vs Azure vs GCP 한눈에 비교표

구분 AWS Azure GCP
글로벌 인프라(공식 수치) 38 리전 / 120 AZ(추가 3개 리전·10 AZ 계획 발표) 70+ 리전 / 400+ 데이터센터 42 리전 / 127 존(2026-01-08 업데이트 표기)
강한 이미지 “가장 폭넓은 서비스” “기업/조직 친화·하이브리드 강자” “데이터·K8s·서버리스가 깔끔”
대표 Kubernetes EKS(+ 자동화 모드 강조) AKS GKE(+ Autopilot)
대표 서버리스 Lambda / Fargate Azure Functions Cloud Run / Cloud Run functions
데이터 분석 축 Redshift(서버리스 포함) Synapse → Fabric 중심 재편 흐름 BigQuery(완전 서버리스 EDW)
생성형 AI 축 Bedrock(다양한 FM, 통합 API) Azure OpenAI(엔터프라이즈 보안 약속) Vertex AI(Gemini + Model Garden)
하이브리드/멀티 Outposts Azure Arc Anthos

인프라/리전 수치는 각 사 공식 페이지 기준입니다. (Amazon Web Services, Inc.)
AWS의 “추가 리전 발표(사우디·칠레·EU Sovereign Cloud)”도 공식에 명시돼 있습니다. (Amazon Web Services, Inc.)


1) 인프라(리전/가용영역/존): “가까운 곳에 깔면 끝”이 아니다

클라우드는 결국 거리(지연시간) + 장애 격리 + 데이터 레지던시 문제로 귀결됩니다.
여기서 3사의 구조가 비슷하면서도 다릅니다.

  • AWS: Region 안에 Availability Zone(AZ) 여러 개
  • Azure: Region 개념 + (리전에 따라) Availability Zone 구성
  • GCP: Region 안에 Zone 여러 개

2026년 기준 공식 인프라 수치

한국(대한민국) 리전 관점 체크(국내 서비스라면 꽤 중요)

  • AWS: Asia Pacific (Seoul) = ap-northeast-2, 4 AZ 표기 (AWS Documentation)
  • Azure: Korea Central(Seoul), Korea South(Busan) (Microsoft Learn)
  • GCP: Seoul region(asia-northeast3) (3개 존으로 시작했다고 공식 블로그에서 설명) (Google Cloud)

👉 결론: “한국 사용자 대상”이면 셋 다 선택지는 충분합니다. 다만 서비스별 제공 여부(예: 특정 AI 모델, 특정 DB, 특정 GPU)는 리전마다 다르니, 최종 확정 전엔 “제품이 리전에 있냐”를 반드시 확인해야 합니다(이게 이직/이전 비용을 갈라요).


2) 서비스 폭 vs 운영 난이도: AWS가 “기능이 많다”는 말의 진짜 의미

AWS는 공식적으로 200+ 서비스를 강조합니다. (Amazon Web Services, Inc.)
Azure도 200+ 제품/서비스를 언급합니다. (Microsoft Azure)

그런데 중요한 포인트는 “숫자”가 아니라 조립 방식입니다.

  • AWS는 작은 부품(서비스)을 조합해 아키텍처를 만드는 느낌이 강합니다. 잘 만들면 최적화가 끝내주지만, 팀 경험이 부족하면 서비스 선택 자체가 리스크가 됩니다.
  • Azure는 기업에서 익숙한 운영 방식(조직/권한/정책/하이브리드)을 “플랫폼 운영 표준”처럼 제공하려는 색이 강합니다.
  • GCP는 핵심 제품군(데이터·K8s·서버리스)을 비교적 단정하게 묶어 “복잡도 대비 효율”을 노리기 좋습니다.

3) Kubernetes(컨테이너): EKS vs AKS vs GKE의 체감 차이

Kubernetes를 “그냥 컨테이너 돌리는 도구”로 보면 셋이 비슷해 보이지만, 실제 운영에선 다음이 갈립니다.

GKE: “Kubernetes 본가 느낌” + Autopilot

GCP 문서에서 Kubernetes가 Google에서 개발되었다고 명시합니다. (Google Cloud Documentation)
또한 GKE Autopilot은 노드/스케일링/보안 등 인프라 구성을 Google이 관리하는 모드라고 설명합니다. (Google Cloud Documentation)

➡️ 운영 인력을 최소화하고 싶거나, 표준화된 K8s 운영을 원하면 GKE가 강점이 됩니다.

EKS: AWS 생태계에 가장 자연스럽게 붙는 K8s

EKS는 AWS의 관리형 Kubernetes 서비스로 설명되며, “어디서든(K8s) 운영”을 강조합니다. (Amazon Web Services, Inc.)

➡️ 이미 AWS를 쓰고 있거나, IAM/네트워킹/관측(CloudWatch 등)까지 AWS로 통일하고 싶으면 EKS가 자연스럽습니다.

AKS: 기업 조직/정책/하이브리드와 결합이 쉬운 K8s

AKS는 관리형 Kubernetes 서비스로 운영 오버헤드를 줄인다고 설명합니다. (Microsoft Learn)

➡️ 특히 조직이 Microsoft 기반(Windows/AD/Entra/Power Platform/DevOps/GitHub)일수록 “기업 운영 표준”이 빠르게 잡힙니다.


4) 서버리스: Lambda vs Functions vs Cloud Run — 2026에 더 중요한 이유

생성형 AI 시대에 서버리스가 다시 뜨는 이유는 단순합니다.

  • 트래픽이 출렁인다(이벤트/배치/에이전트 호출)
  • PoC를 빠르게 해야 한다
  • “항상 켜둔 서버”가 돈을 먹는다

AWS Lambda

Lambda는 “서버를 프로비저닝/관리 없이 코드 실행, 사용한 만큼 과금”으로 설명됩니다. (Amazon Web Services, Inc.)

Azure Functions

Azure Functions도 “서버리스로 코드/인프라를 줄이고 비용을 낮춘다”고 공식 문서가 설명합니다. (Microsoft Learn)

GCP Cloud Run (+ Cloud Run functions)

Cloud Run은 “코드/함수/컨테이너를 구글 스케일 인프라 위에서 실행”하는 완전 관리형 플랫폼입니다. (Google Cloud Documentation)
그리고 중요한 변화: Google Cloud Functions가 ‘Cloud Run functions’로 통합되었다고 Google이 공식 발표했습니다. (Google Cloud)

➡️ 2026 관점에서 “서버리스 = 함수”가 아니라, 서버리스 = 컨테이너까지 자연스럽게 가는 흐름이 강해졌고, 이 지점에서 Cloud Run의 존재감이 큽니다.


5) 데이터/분석: BigQuery vs Redshift vs (Synapse→)Fabric, 무엇이 다른가

GCP BigQuery: “완전 서버리스 EDW”를 원하면

BigQuery는 공식적으로 “완전 관리형 & 완전 서버리스 엔터프라이즈 데이터 웨어하우스”라고 소개합니다. (Google Cloud)

➡️ 운영 부담(클러스터/노드 관리)을 줄이고, SQL 기반 분석을 빠르게 돌리는 팀에 강합니다.

AWS Redshift: “DW도 서버리스로” + AWS 생태계 결합

Redshift는 “빠르고 완전 관리형 클라우드 데이터 웨어하우스”로 소개되며, Redshift Serverless도 함께 강조합니다. (Amazon Web Services, Inc.)

➡️ 이미 S3/Glue/Lambda 등 AWS 분석 스택을 깔아두었다면 Redshift가 결합이 쉽습니다.

Azure: Synapse에서 Fabric 중심으로 재편되는 흐름

Azure Synapse 페이지 자체에 “Migrate to Microsoft Fabric” 메시지가 보입니다. (Microsoft Azure)
또 Microsoft는 Fabric을 엔드-투-엔드 분석 플랫폼으로 설명합니다. (Microsoft Learn)

➡️ Power BI/Office/조직 계정 기반 분석 문화가 있는 회사는 Fabric이 “조직 도입 속도”가 빠를 가능성이 큽니다.


6) 생성형 AI: Bedrock vs Azure OpenAI vs Vertex AI — “모델”보다 “운영 방식”이 갈린다

AWS Bedrock: 모델 선택 폭 + 통합 API

Bedrock은 “여러 회사/아마존의 파운데이션 모델을 통합 API로 제공하는 완전 관리형 서비스”라고 설명합니다. (AWS Documentation)
또 Bedrock Marketplace로 100+ 파운데이션 모델 접근을 강조한 발표도 있습니다. (Amazon Web Services, Inc.)

➡️ “특정 모델에 올인하기 싫다”, “여러 모델을 바꿔 끼우며 최적화하고 싶다”에 강합니다.

Azure OpenAI: 엔터프라이즈 보안/거버넌스 + OpenAI 모델

Azure OpenAI는 “OpenAI 최신 모델을 Azure의 보안/엔터프라이즈 약속과 함께 제공”한다고 FAQ에서 설명합니다. (Microsoft Learn)

➡️ 조직이 이미 Azure 보안/정책 체계를 갖고 있다면, GenAI도 같은 운영 체계로 넣기 쉬워집니다.

Google Vertex AI: Gemini + Model Garden + 플랫폼 통합

Vertex AI는 “완전 관리형 통합 AI 개발 플랫폼”이며 200+ 파운데이션 모델 접근을 언급합니다. (Google Cloud Documentation)

➡️ 데이터(BigQuery 등)와 AI를 한 플랫폼에서 빠르게 연결하려는 팀에 강합니다.


7) 하이브리드/멀티클라우드: “클라우드는 결국 혼합형”이 됐다

2026년 현실은 이렇습니다.
완전 올-인 클라우드는 줄고, “기존 레거시 + 일부 클라우드 + 엣지”가 더 흔해지고 있습니다.

  • AWS Outposts: AWS 서비스를 온프레미스/엣지로 확장하는 완전 관리형 하이브리드로 소개됩니다. (Amazon Web Services, Inc.)
  • Azure Arc: 온프레미스/멀티클라우드 리소스를 Azure에 “투영”해서 단일 제어면으로 관리한다고 설명합니다. (Microsoft Azure)
  • Google Anthos: 하이브리드/멀티클라우드 환경에서 “일관된 플랫폼”을 제공한다고 소개합니다. (Google Cloud)

➡️ 하이브리드 운영이 중요할수록 Azure Arc의 존재감이 커지는 편이고, 컨테이너 기반 표준화를 강하게 밀면 Anthos도 후보가 됩니다. AWS는 Outposts로 “AWS 운영 모델을 그대로 온프레로” 가져가는 느낌이 강합니다.


8) 비용(클라우드 요금) 차이: “어디가 싸냐”보다 “어떻게 사느냐”가 갈린다

요금 비교 글에서 흔히 하는 실수:
온디맨드 단가만 비교하고 결론 내리기.

2026년에는 셋 다 “약정 할인/자동 할인/추천”이 촘촘해서, 실제 청구서는 이렇게 갈립니다.

대표 할인/절감 메커니즘(공식)

계산기는 “필수”

비용 가시화 도구(운영 단계에서 중요)


9) 보안/ID/거버넌스: 2026 선택의 “숨은 승부처”

클라우드는 “기술 선택”이 아니라, 결국 조직 운영 모델입니다.
즉, 권한/정책/감사/계정 구조가 늦게 잡히면 비용과 사고가 같이 터집니다.

  • AWS IAM: AWS 리소스 접근을 중앙에서 제어하는 서비스로 공식 문서가 설명합니다. (AWS Documentation)
  • AWS Control Tower: 멀티 계정 거버넌스(landing zone, account factory 등)를 제공한다고 설명합니다. (AWS Documentation)
  • Microsoft Entra ID: Azure AD의 새 이름(Entra ID)로 안내됩니다. (Microsoft Learn)
  • Google Cloud IAM: 권한을 통합 관리하는 IAM 문서가 제공됩니다. (Google Cloud Documentation)
  • Google Cloud Resource hierarchy: 조직/폴더/프로젝트 구조로 거버넌스를 잡는 리소스 계층 개념이 문서화돼 있습니다. (Google Cloud Documentation)

➡️ 실무 조언: “계정 구조/조직 정책을 먼저” 잡고 서비스 고르는 게, 반대로 하는 것보다 거의 항상 싸게 먹힙니다.


그래서… 2026년에 뭘 고르면 좋을까? (상황별 추천)

AWS가 유리한 경우

  • “우리는 가능한 모든 옵션이 필요하다(서비스 폭/기능 다양성)”
  • 인프라 설계/운영에 강한 팀이고, 최적화(네트워킹/보안/관측)까지 세밀하게 하고 싶다
  • 글로벌 AZ/리전 전략을 촘촘하게 가져가야 한다 (Amazon Web Services, Inc.)

Azure가 유리한 경우

  • Microsoft 기반 조직(계정/정책/업무도구)과 자연스러운 결합이 중요하다
  • 하이브리드/멀티 환경을 하나의 제어면으로 운영하고 싶다(Azure Arc) (Microsoft Azure)
  • GenAI를 “기업 보안 약속” 기반으로 도입하고 싶다(Azure OpenAI) (Microsoft Learn)

GCP가 유리한 경우

  • 데이터/분석을 서버리스로 빠르게(=BigQuery) 굴리고 싶다 (Google Cloud)
  • Kubernetes 운영을 최대한 단순화하고 싶다(GKE Autopilot) (Google Cloud Documentation)
  • 서버리스/컨테이너 중심 개발(Cloud Run)에 팀이 익숙하다 (Google Cloud Documentation)
  • 2026-01 기준 인프라 규모(42 리전/127 존)도 충분히 강력하다 (Google Cloud)

최종 선택 체크리스트(10분만 투자하면 실패 확률 확 줄어듦)

  1. 주요 고객 국가/리전이 어디인가? (지연시간/데이터 레지던시)
  2. 필수 서비스(AI 모델, GPU, DB)가 해당 리전에 존재하는가?
  3. 운영 인력은 충분한가? (K8s/네트워크/보안 전문성)
  4. ID/권한 체계를 무엇으로 표준화할 것인가? (IAM/Entra/IAM)
  5. 비용은 “온디맨드”가 아니라 약정/자동할인/조직 정책까지 포함해 산정했는가? (Amazon Web Services, Inc.)
  6. 멀티클라우드가 진짜 필요한가, 아니면 “벤더 2개로 복잡도만 2배”가 되는가?
  7. 1~2년 뒤 이전(마이그레이션) 비용까지 감당 가능한가?

FAQ (구글 SEO용 Q&A)

Q1. 2026년 기준 AWS·Azure·GCP 중 점유율 1위는 어디인가요?

Synergy Research의 2025년 Q3 자료에서는 AWS 29%, Microsoft 20%, Google 13%로 제시합니다. (Synergy Research Group)

Q2. “리전 수”는 Azure가 많은데, 그럼 Azure가 무조건 좋은가요?

리전 수는 중요하지만 “내가 쓰려는 서비스가 그 리전에 있느냐”가 더 중요합니다. Azure는 70+ 리전을 강조합니다. (Microsoft Azure)

Q3. 한국(서울/부산) 리전이 필요한데 3사 모두 있나요?

네. AWS는 Seoul(ap-northeast-2), Azure는 Korea Central/ South, GCP는 Seoul(asia-northeast3)을 공식 문서/블로그에서 확인할 수 있습니다. (AWS Documentation)

Q4. 생성형 AI는 어디가 제일 좋나요?

“무조건 1등”은 없고 운영 방식이 다릅니다.

Q5. Kubernetes는 GKE가 더 좋다는 말이 많은 이유가 뭔가요?

GCP 문서에서 Kubernetes가 Google에서 개발되었다고 설명하고, GKE는 관리형 구현이라고 설명합니다. 또한 Autopilot으로 운영 부담을 줄이는 선택지도 명확합니다. (Google Cloud Documentation)

Q6. 서버리스는 2026년에 뭐가 핵심인가요?

함수만이 아니라 “컨테이너까지 서버리스로”가 핵심입니다. Google은 Cloud Functions가 Cloud Run functions로 통합됐다고 공식 발표했습니다. (Google Cloud)

Q7. 클라우드 비용 폭탄을 피하려면 뭘 먼저 해야 하나요?

온디맨드 비교보다, 약정 할인(예: AWS Savings Plans, Azure savings plan, GCP CUDs) + 자동할인(SUDs) + 비용 가시화 도구를 먼저 설계하세요. (Amazon Web Services, Inc.)

Q8. 멀티클라우드는 꼭 해야 하나요?

규제/벤더 리스크/특정 서비스 이유가 명확하면 가치가 있지만, 이유 없이 시작하면 운영 복잡도와 비용만 커지기 쉽습니다. 멀티/하이브리드 관리 도구(Azure Arc, Anthos, Outposts)로 “관리 전략”부터 잡는 게 안전합니다. (Microsoft Azure)

AX 100배의 법칙 AX 100배의 법칙
– 나와 조직의 능력을 100배 높이는 AI 경영의 실제

도서 구매

함께 읽으면 좋은 글:

디지털 트랜스포메이션: 조직의 습관을 바꾸는 일, 도서 구매







. .


함께 읽으면 좋은 글

핵심 요약

  • AWS는 선택지가 넓고, Azure는 조직 통합이 강하며, GCP는 데이터·AI 워크로드에서 강점을 보입니다.
  • 비용, 운영 난이도, 기존 생태계 적합성을 함께 봐야 실제 선택 실수가 줄어듭니다.
  • 이후에는 쿠버네티스, 스토리지, 비용 운영 글로 세부 비교를 이어가면 좋습니다.

자주 묻는 질문

처음 멀티클라우드 비교를 할 때 무엇을 가장 먼저 봐야 하나요?

기존 조직의 기술 스택, 운영 인력 수준, 비용 구조, 데이터·AI 요구사항을 먼저 정리해야 합니다.

이 글 하나만 읽고 결정해도 되나요?

방향성 파악에는 충분하지만, 실제 선택 전에는 쿠버네티스·스토리지·FinOps 글까지 함께 보는 편이 안전합니다.

재해복구 DR 전략: RTO/RPO 기준으로 설계하는 2026 실무 가이드

재해복구 DR 전략을 세울 때 가장 흔한 실패는 이거예요.

기술(스냅샷, 복제, 이중화)부터 고르고
나중에 “우리 RTO/RPO가 뭐였지?”를 묻는 것.

반대로 성공하는 팀은 순서가 정반대입니다.

  1. 업무가 버틸 수 있는 시간/데이터 손실 한계를 먼저 정하고(RTO/RPO)
  2. 그 목표를 만족하는 DR 전략(아키텍처)을 고르고
  3. 마지막에 도구/서비스(AWS/Azure/GCP)를 끼워 넣습니다.

오늘 글은 이 “역산 설계”를 그대로 따라갈 수 있게 만든 실무 가이드입니다.


1) RTO/RPO/MTD: 재해복구 DR 전략의 핵심 용어 정리

RTO(Recovery Time Objective)

NIST 용어집 기준으로 RTO는 “복구 단계에 있을 수 있는 전체 시간(그 이상이면 조직의 미션/업무에 악영향)”을 뜻합니다. (NIST Computer Security Resource Center)

RPO(Recovery Point Objective)

NIST 용어집 기준으로 RPO는 “장애 이후 데이터가 복구되어야 하는 시점(포인트)”입니다. 쉽게 말해 “얼마나 과거까지 롤백해도 괜찮나”예요. (NIST Computer Security Resource Center)

MTD(Maximum Tolerable Downtime)

NIST SP 800-34에서는 MTD를 “업무/미션 중단을 조직이 감내할 수 있는 총 시간”으로 설명합니다. (NIST Publications)
실무적으로는 이런 관계로 이해하면 편합니다.

  • MTD(조직이 버틸 수 있는 최대치)RTO(IT가 목표로 하는 복구 시간)
  • RTO는 MTD를 만족시키기 위한 “IT 측 목표치”로 잡는 경우가 일반적입니다. (NIST Publications)

2) 백업 vs DR vs 고가용성(HA): 재해복구 설계의 첫 구분

Azure의 개념 문서는 BCDR 맥락에서 RTO/RPO를 정의하면서, 비즈니스 연속성/고가용성/재해복구를 구분해 설명합니다. (Microsoft Learn)
이를 실무 언어로 바꾸면 이렇습니다.

  • 백업(Backup): 데이터 되돌리기(랜섬웨어/실수 삭제/데이터 손상에 강함). 보통 RTO가 길어질 수 있음. DB 백업 전략은 관리형 DB 선택 가이드 참고.
  • 고가용성(HA): “죽지 않게” 버티기(단일 장애/존 장애 등). RTO는 짧지만 ‘데이터 논리 오류’는 그대로 복제될 수 있음.
  • DR(재해복구): “큰 사고(리전 장애/대규모 장애)에서도 서비스 재개”가 목표. RTO/RPO 목표를 만족시키도록 전체를 준비.

정리하면, HA는 ‘멈춤 최소화’, 백업은 ‘되돌리기’, DR은 ‘재시작 계획’입니다. 셋은 서로 대체가 아니라 조합이에요.


3) RTO/RPO를 어떻게 정할까: DR 전략 수립 5단계

Azure Well-Architected(재해복구 전략) 문서는 업무 가치와 기대치에 맞춰 명확한 RTO/RPO 타깃을 도출하라고 안내합니다. (Microsoft Learn)
이걸 실무 플로우로 바꾸면 아래 5단계가 가장 무난합니다.

1) 장애 시나리오를 3개로 고정한다

RTO/RPO는 “무슨 사고” 기준인지가 없으면 의미가 흐려집니다.

  • 시나리오 A: 데이터 손상/오삭제/랜섬웨어(복구 포인트가 중요)
  • 시나리오 B: 단일 리전 장애(다른 리전에서 서비스 재개)
  • 시나리오 C: 클라우드/네트워크 대규모 장애(대체 경로/수동 운영까지 포함)

2) 시스템을 “업무 중요도 티어”로 나눈다

예: Tier 0(결제/로그인), Tier 1(핵심 API), Tier 2(리포트/배치), Tier 3(내부관리).

3) 티어별로 RTO/RPO를 숫자로 박는다(예: 15분/1시간/24시간)

정성(“빠르게”)이 아니라 정량(“30분”)으로 고정해야 아키텍처가 정해집니다.

4) “현재 우리 실력”으로 가능한 실제 RTO/RPO를 측정한다

대부분 여기서 갭이 나옵니다.
문서상의 RTO/RPO가 아니라 실제로 복구해본 RTO/RPO를 기준으로 해야 합니다.

5) 갭을 비용으로 환산해 “구간 선택”을 한다

RTO/RPO를 줄일수록(더 빡세질수록) 비용이 늘어납니다.
그래서 아래 DR 전략 4단계(모델) 중 어디로 갈지 결정하게 됩니다.


재해복구 DR 전략 RTO RPO 서버 이중화

4) RTO/RPO에 따라 DR 전략은 4단계로 갈린다

AWS는 클라우드 DR 옵션을 Backup & Restore → Pilot Light → Warm Standby → Multi-site Active/Active 형태의 단계로 정리해 설명합니다. (AWS Documentation)
(이 4단계는 업계에서 가장 널리 쓰이는 DR 모델이기도 합니다.)

아래 표는 실무에서 “설계 판단”에 바로 쓰기 좋게 정리한 버전입니다.

RTO/RPO 목표별 추천 DR 모델(실무용 맵)

목표 수준(예시)RTORPO추천 DR 전략비용/운영 난이도
1단계: 복구가 느려도 됨8~48시간4~24시간Backup & Restore (AWS Documentation)비용↓ / 운영↓
2단계: “서비스는 살려야”1~4시간15~60분Pilot Light (Amazon Web Services, Inc.)비용↗ / 운영↗
3단계: “꽤 빨리” 복구10~60분1~15분Warm Standby (AWS Documentation)비용↑ / 운영↑
4단계: 거의 무중단에 가까움수분~수십분수초~수분Multi-site Active/Active (Amazon Web Services, Inc.)비용↑↑ / 운영↑↑

숫자 구간은 “흔한 예시”이고, 실제는 워크로드/조직 역량에 따라 달라집니다.
중요한 건 RTO/RPO가 빡셀수록 ‘항상 켜져 있는 것’이 많아져서 비용이 급상승한다는 점입니다.


5) RTO/RPO로 역산하는 재해복구 DR 설계 공식

RPO 설계 공식: “데이터 보호 주기”를 먼저 정한다

  • RPO가 15분이면: 최소 15분보다 촘촘한 백업/복제가 있어야 합니다.
  • RPO가 0에 가까우면: 동기(또는 준동기) 복제 + 설계적 일관성까지 고려해야 합니다(난이도와 비용이 확 올라갑니다).

RTO 설계 공식: “복구 절차의 합”이 RTO를 만든다

RTO는 그냥 “서버 켜는 시간”이 아니라 보통 아래 합입니다.

  • 장애 감지/선언 시간 + 사람 호출/승인 시간
  • 인프라 기동 시간(네트워크/컴퓨트/DB)
  • 데이터 복구/재동기화 시간
  • 애플리케이션 배포/설정 적용 시간
  • 트래픽 전환(DNS/LB) + 검증(스모크 테스트) 시간

정리하면, RTO를 줄이려면:

  • 사람 의존(수동)을 줄이고 자동화해야 하고
  • 항상 준비된 리소스(웜/핫)가 많아져야 합니다.

백업 DR 전략 불변 스토리지 HDD

6) 랜섬웨어·오삭제까지 고려한 백업 DR 전략 핵심 3가지

DR을 설계할 때 요즘은 “리전 장애”만 보면 반쪽짜리입니다.
실제 사고는 랜섬웨어/권한 탈취/실수 삭제가 더 자주 터지니까요.

1) 백업은 ‘불변(Immutable)’이 되어야 한다

AWS Backup의 Vault Lock 문서는 일정 시점 이후 백업 볼트가 immutable(변경/삭제 불가)가 된다고 설명합니다. (AWS Documentation)
즉, “백업이 있어도 공격자가 지우면 끝”인 문제를 줄이는 장치입니다.

2) 백업은 단일 리전에만 두지 않는다(교차 리전/교차 계정)

AWS Backup은 교차 리전 백업 복사(cross-Region copy) 설정 흐름을 공식 문서로 제공합니다. (AWS Documentation)
실무에서는 “운영 계정과 다른 계정에 백업을 보관”하는 형태를 많이 씁니다(권한 사고 격리).

3) “백업 시스템 자체”도 DR 관점으로 본다

Google Cloud의 Backup and DR Service는 중앙 관리형 백업/복구 서비스이며, 악의적 또는 우발적 삭제로부터 백업 데이터를 보호한다고 설명합니다(단일/멀티리전 언급 포함). (Google Cloud)


7) 클라우드별 재해복구 DR 구현 예시: AWS·Azure·GCP

여기서는 “RTO/RPO 목표”를 먼저 두고 클라우드별로 어떤 서비스 조합이 자연스러운지 예시를 들어볼게요. AWS·Azure·GCP 전반적인 비교는 AWS vs Azure vs GCP 비교 2026을 참고하세요.


예시 1) RTO 24시간 / RPO 24시간: “가장 현실적인 저비용 시작점”

추천 모델: Backup & Restore

  • 핵심: 백업 주기(=RPO) + 복구 절차(=RTO) 문서화
  • 장점: 비용이 낮고 시작이 쉽다.
  • 단점: 복구는 느릴 수 있다.

구현 포인트

  • 백업 스케줄/보관 정책
  • 복구 리허설(정기 테스트)로 “진짜 RTO”를 측정
  • 백업 불변성(Vault Lock 등) 검토 (AWS Documentation)

예시 2) RTO 1시간 / RPO 5~15분: “대부분 SaaS가 여기서 승부”

추천 모델: Warm Standby 또는 Pilot Light + 빠른 데이터 복제

AWS/Azure 모두 이 구간에서 “복제 기반 DR” 서비스가 실무적으로 자주 선택됩니다.

  • AWS Elastic Disaster Recovery(DRS)는 “RPO seconds, RTO minutes”를 전면에 내세웁니다. (Amazon Web Services, Inc.)
  • Azure Site Recovery(ASR)는 조직의 RTO/RPO 목표를 맞추는 데 도움을 주며, Hyper-V의 경우 복제 주기가 30초까지 낮아질 수 있다고 설명합니다(대상/구성에 따라 다름). (Microsoft Learn)

포인트: 이 단계부터는 “백업만”으로는 RPO를 맞추기 어려워져서, 지속 복제(continuous replication) 같은 접근이 들어오는 경우가 많습니다. (Microsoft Learn)


예시 3) RTO 수분~수십분 / RPO 수초~수분: “진짜 DR이 비싸지는 구간”

추천 모델: Multi-site Active/Active

AWS는 이 전략을 “두 개 이상의 독립된 사이트에서 동시에 요청을 처리하는 Active/Active”로 설명합니다. (Amazon Web Services, Inc.)

이 구간의 현실

  • 비용이 급증합니다(리소스를 “두 군데에서 상시 운영”).
  • 운영 난이도가 크게 올라갑니다(데이터 일관성/충돌/분산 트랜잭션/관측성 등).
  • 그래서 보통 Tier 0 일부(예: 결제/인증)만 Active/Active로 가고, 나머지는 Warm Standby로 섞는 “혼합형”이 많습니다.

8) RTO/RPO 기반 재해복구 DR 설계 템플릿

(1) 워크로드별 목표 정의 표

시스템중요도장애 시나리오목표 RTO목표 RPO현재 RTO/RPO갭(리스크)선택 전략
결제Tier 0리전 장애15분1분2시간/15분Warm/Active
로그인Tier 0권한 탈취30분5분미측정Backup+불변
관리자Tier 2리전 장애24시간24시간12시간/24시간작음Backup&Restore

(2) DR 실행(runbook) 최소 구성

  • 장애 선언 기준(누가/언제/어떤 조건에서)
  • 복구 절차 단계(순서가 핵심): 데이터 → 앱 → 트래픽 → 검증
  • 롤백/재난 해제 절차
  • 테스트 계획(분기 1회, 최소 연 2회는 권장)

9) 비용을 낮추면서 RTO/RPO를 줄이는 6가지 레버

  1. 티어링: 전 시스템을 Tier 0로 만들지 말기(비용 폭탄 방지 — 클라우드 비용 최적화(FinOps) 입문 참고) (Microsoft Learn)
  2. 혼합형 DR: 핵심만 Warm/Active, 나머지는 Backup/Pilot
  3. 자동화: 수동 승인/수동 배포 제거(사람이 RTO를 늘립니다)
  4. 트래픽 전환 설계: DNS/LB 전환을 문서화하고 반복 훈련
  5. 백업 불변성/격리: 랜섬웨어 대응(삭제 불가 + 다른 계정/리전) (AWS Documentation)
  6. 테스트로 측정: 목표 RTO/RPO는 “종이”가 아니라 “리허설 결과”로 관리

자주 묻는 질문 (FAQ)

Q1. RTO와 RPO 차이를 한 문장으로 말하면?

  • RTO는 “얼마나 빨리 서비스/시스템을 복구해야 하는가”이고, NIST 정의로는 “복구 단계에 있을 수 있는 전체 시간”입니다. (NIST Computer Security Resource Center)
  • RPO는 “얼마나 최근 시점까지 데이터가 복구돼야 하는가”이며, NIST 정의로는 “장애 후 데이터가 복구되어야 하는 시점”입니다. (NIST Computer Security Resource Center)

Q2. MTD는 뭐고 왜 필요하죠?

NIST SP 800-34는 MTD를 “업무 중단을 감내할 수 있는 총 시간”으로 설명합니다. (NIST Publications)
RTO는 보통 이 MTD를 넘지 않게 잡는 IT 목표치라서, 경영진/업무부서와 합의할 때 MTD가 기준점이 됩니다.

Q3. DR 전략(Backup/Pilot/Warm/Active-Active)은 뭘 기준으로 고르나요?

AWS는 클라우드 DR 옵션을 Backup & Restore, Pilot Light, Warm Standby, Multi-site Active/Active로 정리해 설명합니다. (AWS Documentation)
실무에서는 목표 RTO/RPO가 빡셀수록 더 “항상 준비된(상시 운영)” 자원이 필요해서 비용이 증가합니다.

Q4. 백업만 잘하면 DR은 필요 없나요?

보통은 아닙니다. 백업은 데이터 복구에 강하지만, 서비스 재개(RTO)를 빠르게 보장하려면 복제/대기 환경/자동 전환 등 DR 설계가 필요합니다. (BCDR에서 RTO/RPO를 기준으로 전략을 고르라고 하는 이유가 여기 있습니다.) (Microsoft Learn)

Q5. 클라우드에서 RTO/RPO를 빨리 맞추는 서비스 예시가 있나요?

  • AWS Elastic Disaster Recovery는 “RPO seconds, RTO minutes”를 내세웁니다. (Amazon Web Services, Inc.)
  • Azure Site Recovery는 복제를 통해 목표 RTO/RPO를 맞추는 데 도움을 주며, Hyper-V 복제 주기가 30초까지 가능하다고 설명합니다. (Microsoft Learn)

Q6. 랜섬웨어까지 고려하면 무엇이 핵심인가요?

백업이 “있다”보다 백업이 지워지지 않는다(불변성)가 중요해졌습니다. AWS Backup Vault Lock은 일정 시점 이후 백업 볼트를 변경/삭제할 수 없게 하는 불변성을 설명합니다. (AWS Documentation)
Google Cloud Backup and DR Service도 백업 데이터의 악의적/우발적 삭제 방지를 강조합니다. (Google Cloud)


AX 100배의 법칙
AX 100배의 법칙
– 나와 조직의 능력을 100배 높이는 AI 경영의 실제

도서 구매

함께 읽으면 좋은 글:

디지털 트랜스포메이션: 조직의 습관을 바꾸는 일, 도서 구매

. .

AI 에이전트 카오스 시대: Claude·OpenClaw가 흔드는 2026 IT 지형

AI 에이전트 카오스가 시작됐습니다. 2022년 ChatGPT의 등장이 단순한 질문-답변의 시대를 열었다면, 2026년은 자율 AI 에이전트가 우리의 받은편지함, 계약서, 일정, 코드까지 직접 관리하는 시대로 접어들었습니다. 그 한가운데에 있는 두 이름이 바로 Anthropic의 Claude Cowork와 오픈소스 진영의 OpenClaw입니다.

(본 글은 AI 에이전트 수준 검증을 위해 100% AI로 작성된 글입니다. 내용에 대해 살펴보시지요)


1. AI 에이전트 시대의 시작점: ChatGPT에서 OpenClaw까지

“2022년 ChatGPT와의 순진한 질의응답에서 시작된 것이 이제는 실존적 논쟁이 됐다.” 4년 만에 우리가 도달한 자리는 단순한 챗봇이 아니라, 사용자의 시스템에 직접 접근해 반복 업무를 수행하는 자율 에이전트의 시대입니다.

이 변화의 폭발점에는 두 사건이 겹쳐 있습니다. 하나는 Anthropic이 출시한 Claude Cowork — 법률 업무를 자동화하는 AI 에이전트 — 이고, 또 하나는 같은 시기에 GitHub에서 폭발적으로 확산된 OpenClaw입니다. AI 에이전트 카오스는 결국 기술적 가능성과 경제적 충격, 거버넌스 공백이 동시에 부딪치며 만들어진 결과물입니다. 젠슨 황의 CES 2026 키노트에서 강조된 Agentic AI 흐름이 본격 산업 충격으로 이어진 셈입니다.


2. OpenClaw 폭발적 성장: 48시간 만에 GitHub 100,000 stars

image

AI 에이전트 카오스의 기술적 상징은 단연 OpenClaw입니다. 오스트리아 개발자 Peter Steinberger가 2025년 11월 Clawdbot이라는 이름으로 처음 공개한 이 오픈소스 프로젝트는, Moltbot을 거쳐 OpenClaw로 리브랜딩한 뒤 짧은 기간 안에 GitHub 역사상 가장 빠른 성장세를 보였습니다.

2.1. 숫자로 보는 OpenClaw 확산 속도

  • 2026년 3월 2일 기준 GitHub 스타 247,000개, 포크 47,700개
  • 피크 구간 기준 100,000 스타 도달까지 48시간 미만 — GitHub 역사상 최단 기록 중 하나
  • 로컬 머신에서 직접 실행되는 오픈소스 자율 AI 에이전트
  • Telegram·Discord 같은 메시징 플랫폼이 주된 사용자 인터페이스

2.2. OpenClaw가 실제로 하는 일

OpenClaw가 매력적인 이유는 추상적인 데모가 아니라 실제 일상 업무를 자동화한다는 점입니다. 대표적인 활용 사례는 다음과 같습니다.

  • 받은편지함 분류와 자동 회신
  • 콘텐츠 큐레이션과 요약
  • 여행 일정 계획과 예약 보조
  • 로컬 시스템 접근이 필요한 반복 업무

도구에게 더 많은 권한을 줄수록 더 강력해지지만, 동시에 위험도 함께 커집니다. 결국 이 균형이 모든 도입 결정의 분기점입니다.


3. Anthropic Cowork와 SaaSpocalypse: 에이전트 AI의 시장 충격

image 1

Anthropic이 발표한 Claude Cowork는 계약서 검토와 NDA 분류 같은 법률 업무를 AI 에이전트에게 맡기는 서비스입니다. 발표 직후 시장의 반응은 즉각적이었습니다 — legal-tech와 SaaS(서비스형 소프트웨어) 업체들의 주가가 큰 폭으로 빠지면서 일부 매체는 이 사건을 SaaSpocalypse(사스 종말)라고 부르기 시작했습니다.

이번 사건이 단지 개발자 커뮤니티의 이야기가 아니라, 자본 시장과 산업 구조까지 흔드는 사건이라는 점이 확인된 순간입니다. SaaS 비즈니스 모델은 지난 10년간 IT 업계의 표준이었기 때문에, “AI 에이전트가 같은 일을 더 싸게 한다면 우리는 무엇을 팔아야 하는가”라는 질문은 더 이상 미룰 수 없게 됐습니다.


4. Anthropic의 OpenClaw 차단: 4월 4일 정오에 일어난 일

image 2

갈등이 한층 격해진 분기점이 2026년 4월 4일에 있었습니다. Anthropic은 같은 날 정오(태평양 시간) 이후 Claude 구독자가 OpenClaw를 비롯한 서드파티 하네스에 자신의 Claude 구독 한도를 사용할 수 없도록 정책을 변경했습니다.

4.1. 사용자 비용 최대 50배 증가

이 결정의 충격은 컸습니다. 그동안 Claude Code 구독료 안에서 OpenClaw를 함께 사용하던 수천 명의 사용자가, 하루아침에 별도 API 요금을 부담해야 했고, 일부 사용자는 월간 비용이 기존 대비 최대 50배까지 늘어나는 상황에 놓였습니다. Hacker News에 공유된 Anthropic 고객 이메일이 이 소식을 처음 확산시켰습니다.

4.2. 오픈소스 진영의 반발

OpenClaw 창시자 Peter Steinberger는 2026년 2월 OpenAI에 합류한 상태였는데, Anthropic의 결정을 두고 “오픈소스 개발자에 대한 배신”이라고 강하게 비판했습니다. 한쪽에서는 비용 통제를 명분으로(2026년 AI 트렌드 6가지도 함께 참고), 다른 쪽에서는 오픈 생태계의 자유를 명분으로, 이 갈등은 정책과 라이선스 싸움으로 빠르게 번지고 있습니다.


5. AI 에이전트 시장이 만드는 새로운 변종: NanoClaw, Claude Code Channels

OpenClaw 차단 이후 곧바로 새로운 시도가 등장했습니다. 보안 이슈를 보완한 NanoClaw는 OpenClaw의 가장 큰 보안 문제 중 하나를 해결했다고 알려졌고, Anthropic은 곧이어 Claude Code Channels를 발표해 Telegram과 Discord에서 직접 Claude에 메시지를 보낼 수 있도록 했습니다. 이는 사실상 OpenClaw의 핵심 가치 제안을 Anthropic이 공식 채널로 흡수한 형태입니다.

여기에 Claude Code 소스 유출 의혹까지 더해지면서, AI 에이전트 카오스는 단순한 기술 경쟁이 아니라 거버넌스, 보안, 비즈니스 모델이 동시에 흔들리는 복합 사건이 됐습니다.


6. 한국 IT 업계가 AI 에이전트 시대에 주목해야 할 5가지

이 변화는 미국 시장에서 시작됐지만, 한국 기업과 개발자에게도 의미가 작지 않습니다. 다음 5가지를 꼭 확인해 두시길 권합니다.

  1. SaaS 비즈니스 재정의 — Cowork 사례는 “AI 에이전트가 같은 가치를 더 싸게 만들 수 있는 영역”을 시장이 즉시 가격에 반영한다는 신호입니다.
  2. 법률·반복 업무 자동화 도입 — 계약 검토, NDA 분류 등은 한국 기업도 즉시 시도할 수 있는 영역입니다.
  3. 구독 정책 리스크 — Claude·OpenAI 구독에 의존한 워크플로우는 정책 변경 한 번에 비용이 수십 배 늘 수 있습니다. 이중화 전략이 필요합니다.
  4. 오픈소스 거버넌스 — OpenClaw처럼 중앙 통제가 없는 도구는 사내 도입 시 보안·법무 검토가 선행돼야 합니다.
  5. 로컬 실행 에이전트의 부상 — 데이터 주권과 규제 측면에서 한국은 로컬 실행형 에이전트가 오히려 유리할 수 있습니다.

7. 에이전트 AI와 AGI: 정말 가까워졌을까

AGI(범용 인공지능) 도달에 대한 우려도 다시 떠오르고 있습니다. Claude Cowork와 OpenClaw처럼 시스템에 직접 접근하는 자율 에이전트가 등장하면서, “강력한 자율 에이전트가 곧 AGI에 가까워지는 것 아닌가”라는 질문이 더는 학계의 사변이 아니라 기업 의사결정 변수에 들어오기 시작했습니다.

다만 진짜 쟁점은 “AGI 도달 여부”(자세한 내용은 하사비스 vs 아모데이 AGI 전망 비교 참고)가 아니라, 지금 당장 발생하고 있는 일자리 영향과 거버넌스 공백입니다. 이 변화의 진짜 비용은 미래의 AGI가 아니라, 오늘의 SaaS·법률·고객지원 산업에서 이미 청구되고 있다는 진단입니다.


8. AI 에이전트 카오스 시대를 맞는 우리의 자세

정리하면 2026년의 AI 에이전트 시장은 세 가지 축으로 움직이고 있습니다. 첫째, OpenClaw 같은 오픈소스가 빠르게 확산되며 기술 진입 장벽을 낮추고 있고, 둘째, Anthropic의 정책 변경처럼 상용 사업자가 비용·통제 카드를 쥐고 흔들고 있으며, 셋째, SaaSpocalypse처럼 시장이 즉각 가격으로 반응하고 있습니다.

지금 한국 기업과 개발자에게 필요한 것은 어느 한쪽에 줄을 서는 결정이 아니라, 변화의 속도와 방향을 빠르게 학습하고 작은 단위로 실험을 시작하는 것입니다. 한 달 뒤에 어떤 도구가 표준이 될지 아무도 단언할 수 없는 시기일수록, 직접 만져보고 비교한 사람만이 다음 라운드에서 살아남을 수 있습니다. AI 에이전트 카오스는 이미 시작됐습니다.


AI 에이전트 카오스 FAQ: 자주 묻는 질문

Q1. OpenClaw는 정확히 어떤 도구인가요?

OpenClaw는 오스트리아 개발자 Peter Steinberger가 만든 오픈소스 자율 AI 에이전트입니다. 2025년 11월 Clawdbot이라는 이름으로 처음 공개됐고, 로컬 머신에서 직접 실행되며 Telegram·Discord 같은 메시징 플랫폼을 인터페이스로 사용합니다.

Q2. Claude Cowork와 OpenClaw는 경쟁 관계인가요?

출발점은 다릅니다. Claude Cowork는 Anthropic이 출시한 상용 법률 업무 자동화 에이전트이고, OpenClaw는 누구나 가져다 쓸 수 있는 오픈소스 프레임워크입니다. 다만 두 도구가 같은 사용자층을 두고 경쟁하면서, 결국 Anthropic이 OpenClaw에 대한 Claude 구독 사용을 차단하는 결정으로 이어졌습니다.

Q3. SaaSpocalypse는 무엇을 의미하나요?

Anthropic Cowork 발표 직후 legal-tech와 SaaS 기업들의 주가가 큰 폭으로 빠진 사건을 가리키는 신조어입니다. 이 사건이 자본 시장에 즉각 반영된 첫 사례로 평가됩니다.

Q4. 한국에서도 OpenClaw를 쓸 수 있나요?

오픈소스이므로 GitHub에서 누구나 내려받아 사용할 수 있습니다. 다만 사내 도입 시에는 데이터 보안, 사내 네트워크 정책, 그리고 사용 중인 LLM 제공자(예: Claude 또는 OpenAI)의 정책 변경 위험을 함께 검토하는 것을 권장합니다.

Q5. Anthropic이 OpenClaw 사용자를 다시 허용할 가능성은 있나요?

현재 시점 기준으로 Anthropic은 4월 4일 차단 정책을 유지하고 있습니다. 다만 이후 Claude Code Channels처럼 공식 채널을 확장하는 움직임이 있어, 향후 정책이 변동될 가능성은 열려 있습니다.


참고 글: Claude, OpenClaw and the new reality: AI agents are here — and so is the chaos (VentureBeat, 2026-04-06)

AX 100배의 법칙
AX 100배의 법칙
– 나와 조직의 능력을 100배 높이는 AI 경영의 실제

도서 구매

함께 읽으면 좋은 글:

디지털 트랜스포메이션: 조직의 습관을 바꾸는 일, 도서 구매

. .

관리형 DB 추천: RDS vs Cloud SQL vs Cosmos DB, 목적별 선택 가이드(2026)

관리형 DB 추천은 클라우드 인프라 설계에서 가장 중요한 결정 중 하나입니다. AWS RDS, Google Cloud SQL, Azure Cosmos DB 중 어떤 서비스가 우리 팀에 맞는지, 목적별로 정리합니다. 클라우드 플랫폼 자체를 먼저 비교하고 싶다면 AWS vs Azure vs GCP 비교 2026 글도 함께 참고하세요.

관리형 DB 추천이 고민되시나요? 먼저 중요한 한 줄부터 정리할게요.

RDS와 Cloud SQL은 “관리형 관계형 DB(RDBMS)”이고, Cosmos DB는 “글로벌 분산 NoSQL(다중 API)”입니다.
그래서 셋을 단순히 “가격/성능”으로 1:1 비교하면 거의 항상 결론이 틀어집니다. (Amazon Web Services, Inc.)

이 글은 “누가 더 좋다”가 아니라, 어떤 목적이면 무엇을 고르면 후회가 적은지를 기준으로 정리했습니다.


관리형 DB 추천 30초 결론: 이렇게 고르면 안 망합니다

1)일반적인 웹/앱 트랜잭션(주문/결제/회원/ERP) + SQL 조인 필수

  • AWS면 RDS, GCP면 Cloud SQL이 가장 무난합니다.
  • 특히 “기존 엔진 호환(Oracle/Db2 등)”까지 필요하면 RDS가 선택 폭이 더 넓습니다. (Amazon Web Services, Inc.)

2)글로벌 사용자(미국/유럽/아시아) + 초저지연 + 멀티리전 읽기/쓰기

  • Cosmos DB가 강점이 확실합니다(글로벌 분산, 멀티리전 복제, 일관성 모델 선택, RU 기반 스케일). (Microsoft Learn)

3)트래픽이 들쭉날쭉(스파이크/이벤트) + 서버리스와 찰떡 조합

  • RDB가 필요하면 RDS + RDS Proxy(커넥션 풀링/장애 시 연결 유지) (AWS Documentation)
  • GCP면 Cloud SQL Auth Proxy를 “권장 방식”으로 연결 설계 (Google Cloud Documentation)
  • NoSQL이 허용되면 Cosmos DB Serverless(사용한 RU + 저장량 기반)가 비용 예측이 쉬운 편입니다. (Microsoft Learn)

1) 관리형 DB 3대 서비스 정체: RDS·Cloud SQL·Cosmos DB 한 줄 정의

관리형 DB 비교 RDS Cloud SQL Cosmos DB 데이터센터

Amazon RDS = “관리형 관계형 DB 종합 세트”

RDS는 PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, Db2 등 여러 RDB 엔진을 관리형으로 제공합니다. (Amazon Web Services, Inc.)
자동 백업/복구 같은 관리 기능도 서비스 범위로 포함됩니다. (AWS Documentation)

Google Cloud SQL = “GCP의 관리형 MySQL/Postgres/SQL Server”

Cloud SQL은 MySQL, PostgreSQL, SQL Server를 제공하는 완전 관리형 관계형 DB 서비스입니다. (Google Cloud)
백업/복제/패치/암호화 등 운영 작업을 자동화한다고 공식 페이지에서 강조합니다. (Google Cloud)

Azure Cosmos DB = “글로벌 분산형 NoSQL(다중 API) + RU 기반 스케일”

Cosmos DB는 글로벌 규모에서 초저지연과 탄력 확장을 목표로 설계된 클라우드 네이티브 NoSQL로 소개됩니다. (Microsoft Azure)
또한 NoSQL/MongoDB/PostgreSQL/Cassandra/Gremlin/Table 등 다중 API 지원을 공식 문서에서 명시합니다. (Microsoft Learn)


2) 관리형 DB 한눈에 비교표: 목적을 먼저 정하는 표

비교 축 RDS (AWS) Cloud SQL (GCP) Cosmos DB (Azure)
DB 성격 관계형(RDBMS) 관계형(RDBMS) 글로벌 분산 NoSQL(다중 API)
엔진/호환 PostgreSQL/MySQL/MariaDB/SQL Server/Oracle/Db2 등 (Amazon Web Services, Inc.) MySQL/PostgreSQL/SQL Server (Google Cloud) NoSQL/MongoDB/Cassandra/Gremlin/Table 등(문서 기준) (Microsoft Learn)
HA 기본 개념 Multi-AZ(동기 복제+자동 장애조치) (Amazon Web Services, Inc.) HA(지역 내 멀티 존) 구성 제공 (Google Cloud Documentation) 멀티리전 복제/분산, 일관성 모델 선택 (Microsoft Learn)
읽기 확장 Read Replica로 읽기 분산 (AWS Documentation) Read replica로 읽기/분석 분리 (Google Cloud Documentation) 지역 복제 + 일관성 선택(설계에 따라) (Microsoft Learn)
서버리스 친화(커넥션) RDS Proxy로 커넥션 풀링/복원력 (AWS Documentation) Cloud SQL Auth Proxy “권장 연결” (Google Cloud Documentation) Serverless 옵션: 사용한 RU + 저장량 과금 (Microsoft Learn)
비용의 핵심 단위 DB 인스턴스 시간 + 스토리지 등 (AWS Documentation) 인스턴스/스토리지 중심(서비스 단) RU(요청 단위) + 저장량, autoscale/serverless 선택 (Microsoft Learn)

3) 관리형 DB 목적별 추천: 실무에서 가장 많이 나오는 7가지

관리형 DB 추천 목적별 클라우드 서버 인프라

목적 A. “SQL 조인 + 트랜잭션”이 핵심인 일반 서비스(가장 흔함)

  • 추천: RDS 또는 Cloud SQL
  • 왜: 둘 다 “관리형 관계형 DB”로, MySQL/Postgres/SQL Server 등 익숙한 SQL 워크로드를 그대로 가져가기 쉽습니다. (Amazon Web Services, Inc.)

이때 RDS가 특히 유리한 경우

  • Oracle/Db2 같은 상용 엔진이 필요하거나, 엔진 선택 폭이 넓어야 할 때(RDS는 Db2/Oracle 등을 명시) (Amazon Web Services, Inc.)
  • AWS 내 다른 서비스(IAM, VPC, 백업, 관측)와 운영 표준이 이미 잡혀 있을 때

이때 Cloud SQL이 특히 유리한 경우

  • 앱/데이터 파이프라인이 GCP(예: Cloud Run, BigQuery 등) 중심이고, “관리형 MySQL/Postgres/SQL Server”를 간단히 붙이고 싶을 때 (Google Cloud Documentation)

목적 B. 고가용성(HA)이 최우선: “장애 나도 자동으로 버텨야 함”

RDS의 대표 HA: Multi-AZ

RDS Multi-AZ는 대기(standby) 생성, 동기 복제, 장애조치가 자동이라고 설명합니다. (Amazon Web Services, Inc.)
그리고 Multi-AZ 장애조치 시간은 보통 60~120초라고 문서에 안내됩니다(상황에 따라 더 길어질 수 있음). (AWS Documentation)

실무 포인트: Multi-AZ “standby”는 읽기 스케일 용도가 아니라 HA 용도입니다(읽기 분산은 read replica가 맞는 레버). (AWS Documentation)

Cloud SQL의 HA

Cloud SQL은 고가용성 구성(HA) 개요 문서를 별도로 제공하며, 인스턴스를 HA로 구성하는 흐름을 안내합니다. (Google Cloud Documentation)
또한 SLA 페이지는 “HA가 켜진 Cloud SQL Enterprise/Enterprise Plus” 등을 Covered Service로 정의합니다. (Google Cloud)


목적 C. 읽기 트래픽이 압도적으로 많은 서비스(뉴스/커뮤니티/검색/리포트)

  • RDS: read replica로 읽기 분산(“읽기 전용 복제본”으로 부하를 오프로딩) (AWS Documentation)
  • Cloud SQL: read replica로 읽기/분석 트래픽 분리(“거의 실시간” 복제) (Google Cloud Documentation)

추천 패턴: “쓰기(Primary) 1개 + 읽기(Replica) N개 + 캐시” 조합이 비용/성능 모두 무난합니다.


목적 D. 서버리스(Function/Cloud Run) 기반에서 DB 커넥션 폭탄을 피하고 싶다

관리형 DB를 서버리스와 연결할 때 가장 흔한 사고가 DB 커넥션 수 폭주입니다.

AWS: RDS Proxy로 커넥션 풀링(서버리스 친화)

RDS Proxy는 앱이 DB 커넥션을 풀링/공유할 수 있게 해 스케일에 유리하고, 장애 시에도 애플리케이션 연결을 보존하며 스탠바이로 자동 연결할 수 있다고 설명합니다. (AWS Documentation)

GCP: Cloud SQL Auth Proxy를 “권장 방식”으로

Cloud SQL Auth Proxy 문서는 Cloud SQL에 연결하는 권장 방법이라고 명시합니다. (Google Cloud Documentation)
특히 Cloud Run에서 Cloud SQL을 연결할 때도 Cloud SQL Auth Proxy를 사용하는 메커니즘을 설명하면서, 인스턴스 수/런 인스턴스 수에 따른 API 쿼터 영향과 “인스턴스 cap(상한)” 같은 제어 포인트까지 안내합니다. (Google Cloud Documentation)


목적 E. 글로벌 유저 대상(여러 대륙) + 멀티리전 쓰기까지 필요

관리형 DB 추천에서 여기서부터는 Cosmos DB의 존재감이 커집니다.

Cosmos DB는 로컬 복제본에서 읽기/쓰기가 가능하고, 계정에 연결된 모든 지역으로 데이터를 투명하게 복제하며, 저지연·탄력 확장·일관성 의미·고가용성을 목표로 설계되었다고 설명합니다. (Microsoft Learn)

단, Cosmos DB의 ‘일관성’은 비용/성능과 직결됩니다

Cosmos DB 문서에 따르면 strong/bounded staleness는 여러 복제본을 읽어야 해 같은 RU에서의 읽기 처리량이 다른 일관성 모델 대비 절반이 될 수 있다고 안내합니다. (Microsoft Learn)

즉, Cosmos DB는 “글로벌 분산”에 강하지만, 일관성 요구가 높을수록 RU 비용이 커질 수 있습니다.
글로벌 서비스는 이 트레이드오프 설계가 핵심입니다.


목적 F. 비용을 ‘사용량 기반’으로 가져가고 싶다(특히 초기/간헐 트래픽)

Cosmos DB Serverless: “최소 용량 예약 없이, 사용한 만큼”

Cosmos DB serverless는 DB 작업이 소비한 RU + 저장량만큼 과금된다고 문서에 명시돼 있습니다(“no minimum charge and no capacity planning required”도 함께 언급). (Microsoft Learn)

Cosmos DB Autoscale: 트래픽 변동이 크면 자동 조절

Autoscale은 RU/s를 워크로드에 맞춰 자동 조절한다고 설명합니다. (Microsoft Learn)

RU를 모르고 시작하면? 비용이 아니라 ‘혼란’이 옵니다

Request Units(RU)는 CPU/IOPS/메모리 같은 자원을 추상화한 “성능 화폐”로 설명되고, 모든 작업이 RUs로 측정된다고 안내됩니다. (Microsoft Learn)
그래서 Microsoft는 RU 요구량을 추정하기 위한 Capacity Planner도 제공합니다. (Microsoft Learn)


목적 G. 백업/복구(실수 삭제/장애/롤백)가 매우 중요

  • RDS 자동 백업: 보관 기간 내 시점 복구(Point-in-time restore)가 가능하다고 설명합니다. (AWS Documentation)
  • Cloud SQL 백업: 자동/온디맨드 백업을 지원하고, 백업이 incremental(증분)이며 기본적으로 암호화된다고 안내합니다. (Google Cloud Documentation)

운영 팁: 백업은 “있다”보다 “복구 리허설을 했다”가 훨씬 중요합니다. 월 1회라도 실제 복구를 해보면 사고가 확 줄어요.


4) 관리형 DB 비용 구조 총정리: 무엇이 돈을 만들고 폭탄이 되나

관리형 DB 비용 구조 모니터링 서버 관리 화면

RDS 비용이 커지는 4가지 포인트

  1. DB 인스턴스 시간(초 단위 과금/최소 시간 존재) (AWS Documentation)
  2. Multi-AZ(HA): standby까지 포함하는 구조라 비용이 체감상 커질 수 있음(대신 HA 얻음) (Amazon Web Services, Inc.)
  3. 읽기 복제본(read replica 수만큼 인스턴스 비용 증가) (AWS Documentation)
  4. 백업 보관/스토리지/IO(엔진/스토리지 타입에 따라 달라짐)

절감 레버: Reserved Instances(예약) 같은 옵션으로(FinOps 실전 방법 12가지 참고) 절감 가능하다는 점을 RDS 가격 페이지가 안내합니다. (Amazon Web Services, Inc.)

Cloud SQL 비용이 커지는 4가지 포인트

  1. 인스턴스(코어/메모리) + 스토리지
  2. HA 구성(멀티 존/복제) (Google Cloud Documentation)
  3. 읽기 복제본(리드 레플리카) (Google Cloud Documentation)
  4. Cloud Run 등에서 인스턴스가 늘 때 연결/쿼리 폭주(설계로 관리)

운영 레버: Cloud SQL은 “백업/복제/패치/암호화/스토리지 증가 자동화”를 공식적으로 강조합니다. (Google Cloud)

Cosmos DB 비용이 커지는 5가지 포인트

  1. RU 소비량(쿼리/쓰기 패턴): 모든 작업이 RU로 측정 (Microsoft Learn)
  2. 일관성(Consistency) 선택: 강한 일관성일수록 같은 RU에서 처리량이 줄 수 있음 (Microsoft Learn)
  3. 지역 수(글로벌 복제): 여러 리전에 복제하면 그만큼 비용/운영 고려가 늘어남 (Microsoft Learn)
  4. autoscale/provisioned/serverless 옵션 선택: 워크로드 패턴에 따라 유불리 달라짐 (Microsoft Learn)
  5. 파티션 키 설계 실패: 핫 파티션 → RU 폭탄/스로틀링 → 비용/성능 동시 악화(이건 실무에서 정말 잦음)

5) 관리형 DB 선택 체크리스트: 이대로만 체크해도 80%는 성공

관리형 DB 선택 시 아래 질문에 답하면 결론이 거의 나옵니다.

  1. SQL 조인/트랜잭션이 필수인가?
  • Yes → RDS / Cloud SQL
  • No(문서/키-값/그래프 중심) → Cosmos DB 후보 (Microsoft Learn)
  1. 필요한 엔진이 무엇인가?
  1. 글로벌 멀티리전 ‘쓰기’가 필요한가?
  • Yes → Cosmos DB 쪽이 철학적으로 맞을 확률 ↑ (Microsoft Learn)
  1. 트래픽이 스파이크인가, 24/7 꾸준한가?
  • 스파이크/간헐 → Cosmos serverless, 또는 RDB면 Proxy/연결 최적화가 핵심 (Microsoft Learn)
  • 꾸준함 → RDS/Cloud SQL에서 예약/사이징 최적화가 더 잘 먹힘 (Amazon Web Services, Inc.)
  1. 서버리스/컨테이너(Cloud Run/Lambda/Functions)가 주 실행 환경인가?
  • Yes → RDS Proxy / Cloud SQL Auth Proxy 같은 “연결 설계”가 사실상 필수 (AWS Documentation)

관리형 DB 추천 FAQ: 자주 묻는 질문

Q1. RDS와 Cloud SQL 중 “더 좋은” 건 뭐예요?

둘 다 관리형 DB(관계형)이고, 결론은 보통 “어느 클라우드가 주력 인프라인가”로 갈립니다.
다만 RDS는 Oracle/Db2까지 포함해 더 다양한 엔진을 공식적으로 언급합니다. (Amazon Web Services, Inc.)

Q2. Cosmos DB는 SQL DB 대체인가요?

관리형 DB의 대체가 아니라 다른 문제를 푸는 DB에 가깝습니다. Cosmos DB는 글로벌 분산/초저지연/탄력 확장을 목표로 한 NoSQL로 소개되며, 다중 API를 지원합니다. (Microsoft Azure)

Q3. Cosmos DB 비용의 핵심은 뭔가요?

Cosmos DB는 모든 작업을 Request Units(RU)로 측정한다고 설명합니다. (Microsoft Learn)
그리고 일관성 모델 선택에 따라 같은 RU에서 읽기 처리량이 달라질 수 있다고 문서가 안내합니다. (Microsoft Learn)

Q4. 서버리스 환경에서 RDB 연결이 왜 자주 터지나요?

함수/컨테이너 인스턴스가 급격히 늘면(EKS vs AKS vs GKE 비용 비교도 참고) DB 커넥션도 폭증해 DB가 먼저 한계에 닿습니다.
AWS는 RDS Proxy로 커넥션 풀링과 장애 시 연결 유지 등을 제공한다고 설명합니다. (AWS Documentation)
GCP는 Cloud SQL Auth Proxy를 연결 “권장 방식”으로 안내합니다. (Google Cloud Documentation)

Q5. RDS의 Multi-AZ는 읽기 확장에도 도움이 되나요?

Multi-AZ standby는 기본적으로 HA/장애조치 목적이며, 읽기 트래픽 확장은 read replica가 더 적합하다고 문서에서 안내합니다. (AWS Documentation)

Q6. Cloud SQL 백업은 어떤 특징이 있나요?

Cloud SQL 백업은 자동/온디맨드가 가능하고, incremental(증분)이며 기본적으로 암호화된다고 문서에 설명되어 있습니다. (Google Cloud Documentation)


관리형 DB 추천이 더 구체적으로 필요하시면, 당신의 서비스 유형(예: 커머스/커뮤니티/게임/사내업무/IoT)과 트래픽 패턴(평소·피크), 데이터 모델(SQL 조인 필요 여부) 3가지만 기준으로
RDS/Cloud SQL/Cosmos DB 중에서 “1순위 + 차선책 + 피해야 할 선택”을 실제 운영 시나리오(HA/복제/비용 폭탄 포인트 포함)로 더 구체적으로 정리해 드릴게요.

AX 100배의 법칙
AX 100배의 법칙
– 나와 조직의 능력을 100배 높이는 AI 경영의 실제

도서 구매

함께 읽으면 좋은 글:

디지털 트랜스포메이션: 조직의 습관을 바꾸는 일, 도서 구매

. .

서버리스 비용 절감 가이드: Functions와 DB 설계를 함께 봐야 하는 이유

서버리스 비용 절감은 함수(Function)만 줄인다고 해결되지 않습니다. 실제로는 DB, 유휴 비용, 요청 패턴까지 함께 설계해야 고정비를 크게 낮출 수 있습니다. 이 글에서는 서버리스 아키텍처에서 비용이 어디서 새는지와 절감 방법을 실무 관점에서 정리합니다.

Functions(서버리스 컴퓨트)만 서버리스로 바꾸고,
DB는 여전히 “항상 켜진(Always-on)” 관리형 DB를 두면…
고정비는 그대로라서 “생각보다 안 싸집니다.”

그래서 오늘은 Functions + Managed DB(가능하면 서버리스 DB/오토스케일/오토일시정지) 조합으로 고정비를 줄이는 설계를, “바로 써먹을 수 있는 예시”로 정리해보겠습니다.


1) 먼저 숫자 감부터: Functions 과금 구조(3대 클라우드 공통)

서버리스 컴퓨트 과금은 크게 아래 두 축입니다.

  • 요청 수(Invoke/Execution/Request)
  • 실행 시간 × 리소스(메모리/CPU) = GB-s 또는 vCPU-s, GiB-s

AWS Lambda

Lambda는 요청 수 + 실행 시간(GB-s) 기준이고, 무료 티어로 월 100만 요청 + 400,000 GB-s가 포함됩니다. (Amazon Web Services, Inc.) 가격 예시로는 컴퓨트 $0.0000166667/GB-s, 요청 $0.20/100만 요청 같은 계산 예시가 공식 페이지에 제시돼 있습니다. (Amazon Web Services, Inc.)

서버리스

Azure Functions

Azure Functions의 Consumption(소비) 플랜은 초 단위 리소스 소비 + 실행 횟수로 과금되고, 무료 그랜트로 월 100만 실행 + 400,000 GB-s가 포함됩니다. (Microsoft Azure)
또한 Microsoft Learn에서는 “메모리(GB) × 실행 시간(초) = GB-s”로 계산한다고 명확히 안내합니다. (Microsoft Learn)

Google Cloud Run(서비스/잡)

Cloud Run은 vCPU-seconds + GiB-seconds + Requests(요청 기반 과금의 경우)로 보는 게 기본입니다. 무료 티어로 예를 들어 요청 200만/월 + CPU/RAM 무료 구간이 안내돼 있습니다. (Google Cloud)

즉, “코드가 잠깐만 실행되고, 평소엔 0에 가깝다”면 서버리스는 강합니다.


2) 그런데 왜 DB에서 돈이 새나? (서버리스 절감의 현실)

서버리스로 바꿨는데 청구서가 안 줄어드는 1등 원인은 이겁니다.

  • Function 비용은 줄었는데
  • DB 비용이 ‘항상 켜짐’으로 남아 고정비가 된다

그래서 DB도 워크로드 패턴에 맞게 선택해야 합니다.


3) Managed DB 선택 매트릭스: “고정비를 줄일 수 있는가?”가 기준

트래픽 패턴추천 DB 타입대표 예시왜 비용에 유리한가
스파이크/간헐(평소 0에 가깝고 가끔 폭주)요청 기반(서버리스/온디맨드) NoSQLDynamoDB On-Demand (Amazon Web Services, Inc.) / Firestore (Google Cloud) / Cosmos DB Serverless(개념) (Microsoft Azure)유휴 시간 고정비 최소화(“쓴 만큼”)
간헐적이지만 트랜잭션/조인이 필요서버리스/오토일시정지 가능한 RDBAurora Serverless(ACU, 유휴 시 중단 언급) (Amazon Web Services, Inc.) / Azure SQL Serverless(자동 일시정지) (Microsoft Learn)DB 고정비를 “스토리지 비용 수준”까지 내릴 여지
24/7 꾸준(항상 트래픽 있음)프로비저닝 + 예약/세이빙 플랜(각 클라우드 예약 옵션)서버리스는 단가가 더 비싸질 수 있음(특히 RDB) (Microsoft Learn)

4) 설계 예시 1: “CRUD API(회원/예약/문의)” — Functions + 요청 기반 NoSQL

가장 돈이 잘 줄어드는 대표 패턴입니다.
웹/앱 API를 함수로 만들고, DB는 ‘요청 기반 과금’으로 고정비를 없애는 방식이에요.

아키텍처(개념)

Client → API Endpoint → Function(검증/비즈로직) → NoSQL(DB)
                         ↘ (비동기) Queue/Topic → Function(후처리)

AWS 조합 예시(비용 절감형)

  • API → Lambda
  • DB → DynamoDB On-Demand(요청 기반)
  • 포인트: DynamoDB 온디맨드는 “pay-per-request + 자동 스케일”을 ‘서버리스 옵션’으로 설명합니다. (Amazon Web Services, Inc.)

비용 절감 레버

  • “리스트 전체 조회(Scan)” 같은 쿼리는 요청/읽기 비용을 급격히 올릴 수 있으니
    파티션 키 설계 + 필요한 인덱스만으로 조회를 ‘좁게’ 만드세요. (이건 돈뿐 아니라 성능도 같이 잡습니다.)
  • TTL(만료) 데이터를 적극 활용(세션/임시토큰/단기 로그 등)

Azure 조합 예시(비용 절감형)

  • API → Azure Functions
  • DB → Cosmos DB Serverless(요청 기반, 저트래픽/간헐 트래픽에 적합하다고 설명) (Microsoft Azure)

비용 절감 레버

  • Cosmos는 “작은 앱 + 지속 트래픽이 없는 경우에 유리”라는 포지셔닝이 명확합니다. (Microsoft Azure)
  • 다만 데이터가 여러 리전에 복제되면 “스토리지 비용도 N배”로 늘 수 있으니(복제 리전 수) 설계 단계에서 선을 정하세요. (Microsoft Azure)

GCP 조합 예시(완전 서버리스 느낌)

  • API → Cloud Run functions(Cloud Functions 2nd gen이 Cloud Run functions로 전환됐다는 안내가 있음) (Google Cloud Documentation)
  • DB → Firestore(문서 읽기/쓰기/삭제 기준 과금 + 무료 티어 안내) (Google Cloud)

비용 절감 레버

  • Firestore는 “쿼리 = 읽는 문서 수”가 비용이 될 수 있습니다. 무료 티어/단가 표도 공식에 명시돼 있으니 쿼리 패턴을 먼저 잡고 가는 게 좋습니다. (Google Cloud)

5) 설계 예시 2: “하루 1~2번 도는 배치/정산” — Scheduler + Function/Job + Serverless RDB

이 패턴은 특히 “개발/테스트/소규모 운영”에서 돈이 크게 줄어듭니다.

아키텍처(개념)

Scheduler → Function/Job(배치 실행) → RDB(필요 시) → 결과 저장(스토리지/리포트)

AWS 예시: Lambda + Aurora Serverless

Aurora Serverless는 공식적으로

  • 온디맨드 오토스케일
  • 유휴 기간에 “shuts down during periods of inactivity”
  • ACU(용량 단위) 초 단위 과금
    으로 설명됩니다. (Amazon Web Services, Inc.)

비용 절감 포인트

  • “정산/배치가 끝나면 DB도 쉬게(유휴)” 만들 수 있는 구조가 됩니다.
  • 단, 배치가 끝나도 앱이 DB 커넥션을 물고 있으면 유휴로 못 들어가는 구조가 생깁니다(아래 ‘커넥션 함정’ 참고).

(옵션) RDS Data API로 “커넥션 관리 부담” 줄이기

AWS는 Data API를 HTTPS API로 SQL 실행하는 방식으로 소개하며, 네트워크/연결 구성 부담을 줄인다는 취지로 설명합니다. (Amazon Web Services, Inc.)
또한 “새로운 Aurora 버전에서는 프로비저닝/Serverless v2 모두에서 Data API가 동작할 수 있다”는 안내가 있습니다(엔진/리전별 지원 확인 필요). (AWS Documentation)

Azure 예시: Timer Trigger Functions + Azure SQL Database Serverless

Azure SQL Database의 serverless compute tier는

  • 워크로드에 따라 자동 스케일
  • 비활성 시 자동 일시정지(이때는 스토리지만 과금)
  • 활동 시 자동 재개
  • 초 단위 과금
    으로 설명됩니다. (Microsoft Learn)

비용 절감 포인트

  • “밤 12시에만 도는 배치” 같은 워크로드는, DB를 24시간 켜둘 이유가 사라집니다.

⚠️ Azure SQL Serverless ‘자동 일시정지’의 함정(실무에서 진짜 많이 터짐)

Microsoft Q&A에서 열려 있는 세션(연결)이 auto-pausing을 막는다고 직접 언급합니다. (Microsoft Learn)
즉, 커넥션 풀을 “항상 유지”하는 앱이면 오히려 절감이 안 됩니다.


6) 설계 예시 3: “스파이크 트래픽(이벤트/티켓팅/쿠폰)” — Queue로 완충 + Function + DB

스파이크 트래픽은 서버리스가 잘 맞지만, DB는 스파이크를 그대로 맞으면 망가집니다.
그래서 큐/토픽으로 완충해서 비용과 안정성을 동시에 잡는 설계를 많이 씁니다.

아키텍처(개념)

Client → Function(요청 접수/검증) → Queue/Topic → Function(처리) → DB
                         ↘ 실패/재시도 → DLQ

AWS 예시: Lambda → (Queue) → Lambda → (RDB면) RDS Proxy

Lambda는 동시에 확 늘어날 수 있어서, RDB 연결을 직접 하면 “DB max connections”에 빨리 닿습니다.
AWS는 RDS Proxy가 Lambda의 많은 연결을 웜 커넥션 풀로 관리해주고, DB의 CPU/메모리 요구량을 줄이며 커넥션 관리 로직을 덜어준다고 설명합니다. (Amazon Web Services, Inc.)
또한 Lambda 공식 문서도 “직접 연결은 단순한 경우, 프로덕션은 프록시를 권장”하고, 프록시는 공유 커넥션 풀로 고동시성을 지원한다고 안내합니다. (AWS Documentation)

GCP 예시: Cloud Run/Functions → Cloud SQL(필요 시) 연결 시 주의

Cloud Run에서 Cloud SQL 연결은 Cloud SQL Auth Proxy 메커니즘을 사용하며, 인스턴스 수에 따라 Cloud SQL Admin API 쿼터가 영향을 받는다는 안내가 있습니다. 또한 Cloud Run 인스턴스 수를 cap 해서 쿼터/확장을 조절할 수 있다고 설명합니다. (Google Cloud Documentation)

비용 절감 관점에서의 해석

  • “함수/런 인스턴스가 무한정 늘어나는 것”을 그대로 두면
    DB 연결/쿼리 폭주 → DB 비용 폭탄(또는 장애)로 이어질 수 있습니다.
  • 그래서 동시성/최대 인스턴스 제한은 비용 통제 장치이기도 합니다.

7) 서버리스 절감 체크리스트 12가지 (Functions + DB 실전)

A. Functions 비용을 줄이는 6가지

  1. 메모리/CPU 과대 할당 금지: 서버리스는 “크게 잡으면 빨라지지만 단가도 올라갑니다.”
  2. 타임아웃 짧게: 무한 대기 = 과금 지속
  3. 외부 API 호출은 비동기로 분리: (큐/이벤트)로 떼어내면 평균 실행 시간이 짧아짐
  4. 로깅 과다 금지: 개발 때만 verbose, 운영은 샘플링/요약
  5. 큰 라이브러리/콜드스타트 줄이기: 함수 패키지 슬림화, 초기화 로직 최소화
  6. 동시성 가드레일: “돈 버는 트래픽”이 아니라 “폭주/공격”도 같이 커집니다

B. DB 비용을 줄이는 6가지

  1. DB가 고정비가 되지 않게: 가능하면 on-demand/serverless/auto-pause 계열 선택 (Amazon Web Services, Inc.)
  2. 쿼리 패턴부터 설계: NoSQL은 스캔/광범위 쿼리가 곧 비용
  3. TTL/만료 전략: 임시 데이터는 자동 삭제(저장비+읽기비 감소) (Google Cloud)
  4. 배치로 묶어서 쓰기/읽기: 요청 수 자체를 줄이면 즉시 절감
  5. RDB 커넥션 폭탄 방지: Lambda→RDS는 프록시/풀링 고려 (Amazon Web Services, Inc.)
  6. 서버리스 RDB ‘자동 일시정지’ 방해요인 제거: 연결을 물고 있으면 절감이 안 됩니다 (Microsoft Learn)

8) “서버리스가 오히려 비싸지는” 흔한 케이스 4가지

  1. 트래픽이 24/7 꾸준한데 서버리스로만 운영
  2. 함수가 너무 오래 돈다(ETL/대형 변환/긴 AI 추론 등) → 잡/배치/컨테이너로 재검토
  3. DB가 RDB인데 커넥션 관리 실패(동시성 증가 = 연결 폭주) (Amazon Web Services, Inc.)
  4. Azure SQL serverless 같은 경우 serverless vCore 단가가 provisioned보다 낮지 않을 수 있음(꾸준한 부하라면 프로비저닝이 더 유리할 수 있음) (Microsoft Learn)

FAQ (서버리스 비용 절감)

Q1. 서버리스로 바꾸면 무조건 비용이 줄어드나요?

아니요. “유휴 시간이 많고 트래픽이 들쭉날쭉”할 때 유리합니다. AWS Lambda/Azure Functions/Cloud Run 모두 요청/실행 시간 기반 과금 구조라, 계속 돌면 계속 과금됩니다. (Amazon Web Services, Inc.)

Q2. Functions만 서버리스로 바꿨는데 왜 비용이 그대로죠?

DB가 항상 켜져 있으면(프로비저닝 RDB 등) DB가 비용의 바닥(고정비)이 됩니다. 이 경우 DB를 on-demand/serverless/auto-pause 가능한 옵션으로 바꿔야 절감이 체감됩니다. (Microsoft Learn)

Q3. Azure SQL Serverless가 자동으로 안 꺼져요. 왜죠?

열려 있는 세션(연결)이 auto-pausing을 막을 수 있다는 안내가 Microsoft Q&A에 있습니다. 배치/함수가 끝나면 연결을 확실히 끊는 설계가 필요합니다. (Microsoft Learn)

Q4. Lambda가 늘면 RDB 커넥션이 터지는 이유가 뭔가요?

Lambda는 동시 실행이 급격히 늘 수 있어 DB 연결도 폭증합니다. AWS는 이를 해결하기 위해 RDS Proxy가 웜 커넥션 풀을 제공하고, Lambda 문서도 프로덕션에서 프록시 사용을 권장합니다. (Amazon Web Services, Inc.)

Q5. Cloud Run(또는 Cloud Run functions) + Cloud SQL 조합에서 비용/안정성 포인트는?

Cloud Run에서 Cloud SQL 연결은 Auth Proxy 메커니즘을 사용하며, 인스턴스 수에 따라 관련 API 쿼터가 영향을 받을 수 있습니다. 그래서 최대 인스턴스 cap 같은 가드레일이 비용/안정성 모두에 도움이 됩니다. (Google Cloud Documentation)

Q6. 서버리스 RDB로 가장 무난한 예시는?

AWS에서는 Aurora Serverless가 “오토스케일 + 유휴 시 중단 + ACU 초 단위 과금”으로 소개됩니다. Azure는 Azure SQL Database serverless tier가 “자동 일시정지(스토리지만 과금) + 자동 재개 + 초 단위 과금”으로 설명됩니다. (Amazon Web Services, Inc.)


원하시면, (1) 트래픽 패턴(평소/피크), (2) 데이터 모델(조인 많은 RDB인지, 문서/키-값인지), (3) 배치 주기(있다면) 딱 3가지만 기준으로
당신 서비스에 맞춘 “Functions + Managed DB” 최적 설계안 2~3개(비용 가정 포함)를 더 구체적으로 그려드릴게요.

서버리스 비용 절감
AX 100배의 법칙
AX 100배의 법칙
– 나와 조직의 능력을 100배 높이는 AI 경영의 실제

도서 구매

함께 읽으면 좋은 글:

디지털 트랜스포메이션: 조직의 습관을 바꾸는 일, 도서 구매

. .


함께 읽으면 좋은 글

Cloudflare vs Fastly vs Akamai 비용 비교 2026: 어떤 CDN이 유리한가

CDN 선택은 단순 속도 문제가 아니라 비용 구조와 운영 방식까지 함께 봐야 합니다. Cloudflare, Fastly, Akamai는 각각 강점이 다르고, 트래픽 패턴에 따라 유리한 선택도 달라집니다. 이 글에서는 2026년 기준으로 세 CDN의 비용과 실무 선택 포인트를 정리합니다.

Cloudflare / Fastly / Akamai 중에서 “내 서비스에 맞는 한 곳”을 고르되,
비용 폭탄(특히 전송비)을 피하도록 도와드리기.


결론 먼저: 10초 선택 가이드

  • Cloudflare: “일단 빨리, 싸게, 손쉽게” → 가성비·간편함·보안 기본기(특히 SMB/스타트업/글로벌 웹사이트)
    • Pro 요금이 월 $25(월간 결제)로 안내되고(연간 결제 시 실질 월 $20) 플랜 자체는 사용량 기반 추가 과금이 없다고 명시돼요.
  • Fastly: “CDN을 내가 정교하게 조련한다” → 개발자 제어·실시간·고성능 튜닝(API/동적 콘텐츠/정교한 캐시 전략)
    • 대신 지역(Region)별 GB 단가가 눈에 띄고, 한국 트래픽이면 단가가 확 뛰는 구조가 명확히 공개돼 있어요.
  • Akamai: “초대형·엔터프라이즈·미디어/보안까지 한 방” → 대규모/방송급/글로벌 초고신뢰
    • 단점은 가격이 보통 견적 기반(공개 단가 없음)이라, 계약/구성에 따라 편차가 큽니다.
CDN

1) “가격 비교”에서 꼭 봐야 하는 4가지 비용

CDN 견적은 보통 아래 4개가 합쳐져서 나옵니다.

  1. 전송비(대부분 egress, GB 단위): 사용자에게 나가는 바이트
  2. 요청비(Request): HTTP 요청 수(10,000건당 과금 같은 형태)
  3. 부가 기능 비용: WAF, Bot, Image 최적화, TLS(도메인 수), 실시간 로그
  4. 숨은 비용(진짜 폭탄): 오리진(클라우드) → CDN으로 나갈 때 드는 클라우드 전송비
    • Fastly도 “클라우드에서 Fastly로 나갈 때(캐시 미스) 클라우드 전송비 + Fastly 전송비가 이중으로 발생할 수 있다”는 취지의 설명을 공개적으로 합니다.
    • Cloudflare는 파트너사와 데이터 전송비를 할인/면제하는 “Bandwidth Alliance”를 운영합니다.

2) 한 장으로 보는 3사 비교표

구분CloudflareFastlyAkamai
가격 모델도메인/플랜 기반(Pro/Business 등) + 일부 애드온 사용량사용량 기반(GB/요청/지역) + 패키지(고정) 옵션견적/계약 기반(구성·트래픽·옵션 협상)
“전송비(GB)” 체감플랜형이라 예측 쉬움(대신 애드온/정책 확인 필요)지역별 단가로 정밀 계산 가능(한국 트래픽은 단가가 높게 책정)계약/볼륨에 따라 편차 큼
“요청비” 체감플랜형이라 단순(추가 기능은 별도)요청비 공개(1M 무료 후 10K당 과금)계약/상품군별 상이
네트워크 규모/철학전 세계 330+ 규모를 전면에 내세움“소수 대형 POP + 정교한 제어” 성향(가격표는 매우 투명)“전통의 초대형 엣지” — 4,200+ 로케이션 언급
추천 상황SMB/스타트업, 빠른 도입, 보안·성능 한 번에개발자 중심 조직, API/동적/정교한 캐시·실시간 운영엔터프라이즈, 대규모 미디어/고신뢰/보안 패키지
주의 포인트애드온(Argo/Load Balancing/Workers 등)에서 사용량 과금 생김한국·아프리카·인도 등 특정 과금 지역은 단가↑, 패키지 조건 제약도 존재가격/구성 투명성이 낮아 PoC·협상 역량 필요

CDN

3) Cloudflare 가격: “플랜형”이어서 계산이 쉽다

Cloudflare는 전형적인 “GB 단가표”보다 플랜(요금제) 중심으로 접근하는 편입니다.

  • Pro 플랜: $25/월(월간 결제)로 안내되며, “No additional usage charges(추가 사용량 과금 없음)” 문구가 명시돼 있습니다.
  • Cloudflare는 공식 블로그에서 가격 정책을 설명하면서, 연간 결제 옵션을 통해 Pro는 연 $240(=월 $20), Business는 연 $2,400(=월 $200) 수준으로 안내한 바 있어요.
  • WAF 페이지에서도 Pro $20(연간 결제)/월간 결제 시 $25, Business도 유사 구조를 안내합니다.

또한 Cloudflare의 CDN은 “330+ locations” 같은 규모를 전면에 내세우고 있어, 글로벌 사용자 비중이 높은 서비스에 무난합니다.

Cloudflare에서 비용이 늘어나는 “진짜 포인트”

Cloudflare는 플랜 자체는 단순하지만, 아래에서 비용이 생기기 쉽습니다.

  • Workers(엣지 함수): 유료 플랜 최소 비용(예: $5/월) + 요청/CPU 과금 구조. 단, egress/throughput(대역폭) 추가 과금은 없다고 명시합니다.
  • R2(Object Storage): “No egress charges(이그레스 비용 없음)”을 강하게 내세웁니다.
  • Argo 같은 성능 옵션: “성능 개선/비용 절감”을 내세우지만 애드온 과금이 붙는 영역입니다.
  • 오리진 전송비(클라우드 → Cloudflare): Bandwidth Alliance 같은 파트너를 쓰면 절감 여지가 생길 수 있습니다.

4) Fastly 가격: “투명한 대신 계산이 필요” (한국 트래픽이면 특히)

Fastly는 가격표가 꽤 직설적입니다. GB 단가(지역별) + 요청비가 정면으로 나와요.

Fastly Full Site Delivery(대표 CDN) 공개 가격 요약

  • Bandwidth(전송량): 월 100GB 무료, 이후 지역별 단가
    • 예: Europe/북미 $0.12/GB, Asia $0.19/GB, South Korea $0.28/GB(100GB~10TB 구간)
  • Requests(요청 수): 월 100만 무료, 이후 10,000건당 $0.01(구간별 할인 존재)
  • TLS 도메인: 무료 도메인 제공 후 추가 도메인당 $20/월 같은 구조가 명시돼 있습니다.

⚠️ 한국 서비스 운영자라면 Fastly에서 꼭 봐야 할 한 줄

Fastly 패키지(Network Services packages) 설명에
“웹/웹 API 용도”이며, “아프리카·인도·한국 과금 지역 트래픽이 10%를 넘으면 안 된다”는 조건이 붙어 있습니다.

즉,

  • 고정 패키지(월 $1,500~)로 “예측 가능한 비용”을 기대했는데
  • 한국 트래픽 비중이 크면 패키지 조건과 충돌할 수 있어요. (이건 꽤 치명적입니다)

Fastly 비용을 감 잡기 위한 “초간단 시뮬레이션”

아래는 이해를 위한 단순 계산(10TB≈10,000GB 가정)입니다.

  • 월 10TB + 1억 요청(한국 트래픽 중심)
    • Bandwidth: (10,000GB – 100GB 무료) × $0.28 ≈ $2,772
    • Requests: (100,000,000 – 1,000,000 무료) / 10,000 × $0.01 ≈ $99
    • 합계 ≈ $2,871/월 (+TLS/로그/보안 옵션은 별도)
  • 같은 트래픽이 북미/유럽 중심이면 Bandwidth 단가가 $0.12라서 대략 절반 이하로 떨어집니다.

➡️ 결론: Fastly는 지역 믹스(트래픽 국적)가 비용을 결정합니다.


5) Akamai 가격: “공개 단가표가 아니라 ‘견적’의 세계”

Akamai는 여전히 많은 조직에서 “최종 보스급 CDN”으로 언급되지만, 가격만 놓고 보면 비교가 어렵습니다.

  • 라이브 스트리밍/CDN 업계 비교 글에서도 Akamai CDN 가격은 공개돼 있지 않아서 정확한 $/GB를 제시하기 어렵다는 식으로 정리합니다.
  • 리뷰/구매 플랫폼에서도 상세 가격은 없고 Quote 요청으로 안내되는 경우가 흔합니다.

다만 “왜 Akamai를 쓰는가?”를 이해하려면 규모/상품군을 봐야 합니다.

  • Akamai는 자사 엣지 네트워크를 “4,200+ locations worldwide” 수준으로 언급합니다.
  • 대규모 미디어 전송(OTT/라이브 등) 용도로 Adaptive Media Delivery 같은 미디어 딜리버리 제품군을 전면에 두고 있어요.

Akamai 엣지 함수(EdgeWorkers) 과금 힌트

Akamai는 EdgeWorkers에 대해 “얼마”를 공개적으로 단순 표로 내기보다는, 과금 단위(이벤트 호출 수) 중심으로 설명합니다.

  • EdgeWorkers는 월간 invoked events(호출 이벤트 수) 기반으로 과금된다고 문서에 명시돼요.

6) “숨은 비용” 1순위: 오리진이 클라우드면 전송비가 두 번 나갈 수 있다

이 부분은 진짜로 청구서 절반을 좌우합니다.

  • Fastly도 블로그에서, 캐시 미스로 오리진(예: Azure)에서 데이터를 가져오면
    오리진 클라우드에서 나가는 전송비 + Fastly가 사용자에게 전달하는 비용이 겹칠 수 있다고 설명합니다.
  • Cloudflare는 Bandwidth Alliance로 클라우드 ↔ Cloudflare 전송비 할인/면제를 목표로 합니다.
  • Cloudflare R2는 egress fee 없음을 강하게 내세우고, 아키텍처에 따라 전송비를 구조적으로 줄일 수 있습니다.

✅ 실무 팁:
CDN만 바꾸지 말고, 오리진 위치/스토리지/캐시 정책을 같이 봐야 “진짜 절감”이 됩니다.


7) 상황별 추천(현실적인 선택지)

A. “빠르게 붙이고, 비용 예측 가능하게” → Cloudflare

  • 인력/시간이 부족한 팀(스타트업, 커머스 초기)
  • 글로벌 유저가 섞인 웹사이트(한국+해외)
  • 보안(WAF/DDoS)까지 한 번에 묶고 싶은 경우
    • Pro 가격과 연간 결제 할인 구조가 공식적으로 안내돼 있어 예측이 쉬워요.

B. “트래픽을 지역별로 계산하고, 제어권을 최대로” → Fastly

  • 요청/캐시/헤더/로그까지 정교하게 운영하고 싶은 팀
  • 장애 시 롤백/퍼지/실험을 실시간으로 운영해야 하는 서비스
  • 다만 한국 트래픽 비중이 크면 GB 단가($0.28/GB 구간)를 먼저 계산하세요.

C. “초대형, 엔터프라이즈, 미디어·보안 포함 ‘풀 패키지’” → Akamai

  • 방송급 이벤트/대규모 스트리밍
  • 규제/보안/지원 체계(SLA 등)까지 포함해 통합 계약이 필요한 조직
  • 가격은 공개 단가표가 아니라 PoC+협상이 핵심(견적 기반).

8) 선택 전에 꼭 해볼 “5분 체크리스트”(돈 새는 것 방지)

  1. 내 트래픽의 국가/지역 비중은? (한국 70%인지, 북미 40%인지)
  2. 월 전송량(GB) / 월 요청 수 / 피크 RPS를 대략이라도 뽑기
  3. 캐시 히트율 목표(예: 85% 이상) 설정
  4. 오리진이 AWS/Azure/GCP라면 오리진→CDN 전송비까지 포함해 총액 계산
  5. WAF/Bot/로그가 “필수”인지 “나중”인지 결정

FAQ (CDN)

Q1. CDN 쓰면 SEO가 진짜 좋아지나요?

간접적으로 좋아집니다. 페이지 로딩이 빨라지면 이탈률/체류시간 같은 사용자 지표가 개선되고, 코어 웹 바이탈 관점에서도 유리해질 가능성이 큽니다. 다만 “CDN만으로” 순위가 오르는 건 아니고, 성능+콘텐츠 품질+기술 SEO가 같이 가야 합니다.

Q2. Cloudflare Pro는 월 $20인가요 $25인가요?

Cloudflare는 공식적으로 월간 결제 $25, 연간 결제는 $240/년(=실질 월 $20) 구조를 설명한 바 있습니다.

Q3. Fastly가 한국에서 비싸게 느껴지는 이유가 뭔가요?

Fastly는 지역별 GB 단가가 공개돼 있는데, “South Korea” 구간이 $0.28/GB(100GB~10TB)로 책정돼 있습니다(유럽/북미 $0.12/GB 대비 높음).

Q4. Fastly 패키지(월 $1,500~)면 비용 예측이 쉬운가요?

예측은 쉬워지지만 조건이 있습니다. Fastly 가격 페이지에 패키지는 웹/웹 API 용도이며, 특정 과금 지역(아프리카·인도·한국) 트래픽이 10%를 넘지 않아야 한다는 요구사항이 명시돼 있습니다.

Q5. Akamai는 왜 가격을 공개하지 않나요?

Akamai는 대기업/미디어/보안 패키지까지 포함해 계약 구성이 다양하고, 지역·볼륨·옵션·지원 수준에 따라 견적이 크게 달라지는 구조가 많습니다. 외부 자료에서도 공개 가격이 제한적이라고 정리되는 편입니다.

Q6. Cloudflare Workers는 진짜 egress 비용이 없나요?

Cloudflare Workers 문서에서 egress(데이터 전송)·throughput(대역폭) 추가 과금이 없다고 명시합니다. 대신 요청/CPU 등은 과금될 수 있어요.

Q7. “오리진 전송비”는 왜 다들 폭탄이라고 하나요?

캐시 미스가 나면 오리진에서 CDN으로 데이터를 끌어오는데, 이때 클라우드 사업자(AWS/Azure/GCP)가 데이터 반출(egress) 비용을 청구합니다. Fastly도 이런 “이중 비용” 상황을 설명합니다.

Q8. Cloudflare R2가 CDN 비용을 줄이는 데 도움이 되나요?

R2는 egress fee 없음을 내세우기 때문에, 구조에 따라 “스토리지 ↔ 전송” 비용을 크게 줄일 여지가 있습니다.

Cloudflare Fastly Akamai 비용 비교
AX 100배의 법칙
AX 100배의 법칙
– 나와 조직의 능력을 100배 높이는 AI 경영의 실제

도서 구매

함께 읽으면 좋은 글:

디지털 트랜스포메이션: 조직의 습관을 바꾸는 일, 도서 구매

. .


함께 읽으면 좋은 글