AWS·네이버 클라우드·GCP를 DevOps 눈으로 나란히 놓고 보기 (2025)
핵심 요약
한 줄 요약: 클라우드 비교는 스펙 표가 아니라 제약 조건(데이터 위치, 팀 숙련도, 계약)부터 맞춰야 합니다. 세 회사 다 “쓸 수는” 있는데, 처음에 고르는 이유는 보통 다릅니다.
| 상황 | 흔한 선택 | 이유 한 줄 |
|---|---|---|
| 국내 데이터·계약서에 리전이 박혀 있음 | 네이버 클라우드 비중 ↑ | 설명·문서·세금계산서 흐름이 현실적으로 편한 경우가 많음 |
| 글로벌 SaaS·레퍼런스·채용 풀 | AWS 또는 GCP | 튜토리얼·서드파티·외부 파트너가 압도적으로 많음 |
| 쿠버네티스만 잘 돌리면 됨 | 팀이 익숙한 쪽 | 플랫폼보다 운영 루틴이 비용을 먹음 |
들어가며: “누가 제일 좋아요?”에 답이 없는 이유
회의실에서 제일 먼저 나오는 질문이 그겁니다. “AWS가 낫죠?” 혹은 “국내는 네이버 아닌가요?”
저도 예전엔 한쪽만 골라서 설득하려 했는데, 요즘은 문장을 바꿉니다. “우리 팀이 다음 분기에 견뎌야 할 제약이 뭐지?”
itemSCV에서도 웹·API·배치·가끔 GPU 작업까지 올리면서, 한 벤더만 보지 않는 경우가 많습니다. CDN은 A, 상태 저장 DB는 B, 실험 워크로드는 C처럼요. 중요한 건 이름이 섞여도 운영이 안 미치게 경계를 그어 두는 쪽입니다.
이 글에서는 AWS, 네이버 클라우드 플랫폼(NCP), Google Cloud(GCP) 세 가지를 같은 줄에 세웠습니다. Azure도 경쟁사지만, 팀 내에서 논의 빈도와 레퍼런스 기준으로 이번엔 빼고 썼습니다. (나중에 별도 편으로 다룰 만합니다.)
1. 먼저 맞춰 볼 것: “같은 그림”으로 서비스 이름 짝짓기
클라우드 이전 회의가 말이 안 통하는 가장 흔한 이유는 용어가 달라서입니다. VPC 안에 VM 돌리고, 오브젝트 스토리지에 아티팩트 올리고, Kubernetes로 배포한다—패턴은 거의 같은데 브랜드만 다릅니다.
위는 개념 정렬용입니다. 세부 SKU·세대·가격은 시점마다 바뀌니, 견적서 찍을 땐 반드시 콘솔/공식 문서를 다시 보세요. 다만 Terraform 모듈 이름이나 런북 제목을 이렇게 맞춰 두면 온콜이 한결 편해집니다.
2. 한국 사용자 기준 지연: “서울 리전 있다”가 끝이 아님
세 벤더 모두 한국 또는 근접 리전을 갖고 있습니다. 그런데 실서비스에서는 RTT 한 자릿수 ms 차이도 체감될 때가 있습니다. 특히 모바일·퍼블릭 와이파이·사내 VPN을 타고 들어오는 경로는 슬라이드에 안 나옵니다.
실무 팁은 단순합니다.
- 프로덕션 트래픽 경로에서 ping 한 번이 아니라, 실제 API 핸드셰이크를 재보세요.
- 정적 파일은 CDN을 앞에 두고, 오리진은 계산·DB에 집중시키는 편이 대부분 이득입니다.
- “해외 리전이 싸서” 옮겼다가 지원 시간대가 엇나가는 경우를 저는 여러 번 봤습니다. 비용은 내려가도 사람 비용이 올라갑니다.
3. 네이버 클라우드를 고르는 쪽이 진짜로 말하는 것들
NCP를 고르는 결정이 항상 “애국”은 아닙니다. 현장에서 반복해서 나오는 말은 대략 이런 계열입니다.
- 계약·세금계산서·국내 법인 프로세스와 맞물릴 때 회계/구매 쪽 설명이 쉬움
- 한국어 기술지원·교육 콘텐츠가 팀 온보딩 속도를 올려 줌 (팀 영어 레벨에 따라 편차 큼)
- 특정 규제·발주 조건에서 국내 IDC 언급이 명시되는 경우
반대로 글로벌 서드파티가 “AWS만 공식 지원” 같은 식으로 박혀 있으면, NCP만으로 끝내기 어렵습니다. 그때는 프론트/데이터는 NCP, 특정 통합은 AWS처럼 쪼개는 설계가 나옵니다.
4. AWS를 기본으로 깔아 두는 조직의 특징
AWS를 “그냥 디폴트”로 두는 팀은 보통 다음 중 하나입니다.
- 이미 IAM·VPC·조직 계정 구조가 굳어져 있고, 이사하기 비용이 큼
- 마켓플레이스·파트너 생태계에서 레퍼런스 아키텍처를 그대로 가져오고 싶음
- 글로벌 다중 리전을 같은 패턴으로 확장할 계획이 있음
주의점은 서비스 종류가 너무 많아서 작은 팀이 길을 잃기 쉽다는 것입니다. “일단 켜본” 리소스가 분기마다 쌓이면, 비용 경고가 울릴 때가 됩니다. 저희는 태그 정책을 늦게 잡으면 후회했다고 회고에 자주 적습니다.
5. GCP가 끼어드는 지점 (특히 데이터·ML 주변)
GCP를 진지하게 보기 시작하는 계기는 종종 BigQuery나 GKE 운영 방식, 혹은 특정 데이터 파이프라인에서입니다. “다른 데서도 비슷하게 할 수 있지 않나?”가 맞는 말이지만, 이미 익숙한 쿼리·권한 모델이 있으면 이사 비용이 줄어듭니다.
다만 한국어 자료 밀도나 국내 파트너 풀은 AWS·NCP와 느낌이 다를 수 있어요. 그래서 “데이터 팀은 GCP, 애플리케이션 팀은 다른 곳” 같은 팀 단위 분리가 보이기도 합니다. 이때 네트워크 피어링·비용 배분을 문서에 안 남기면 나중에 싸움이 납니다. (경험담입니다.)
6. 비용 비교는 표로 끝내지 말 것
공개 블로그에서 “A가 B보다 N% 쌉니다”라고 쓰고 싶지 않은 이유는, 약정·세이빙스 플랜·스팟·무료 크레딧이 섞이면 독자마다 결과가 완전히 달라지기 때문입니다. 대신 팀 내부에서 쓰는 질문 리스트는 공유할 만합니다.
| 질문 | 왜 필요한가 |
|---|---|
| 트래픽이 고정인가 스파이크인가 | 예약 인스턴스 vs 온디맨드 비중 |
| 데이터 송신이 **수익의 몇 %**를 먹는가 | 오리진-CDN-크로스 리전 요금이 조용히 커짐 |
| 장애 시 지원 플랜을 쓸 수 있는가 | 온콜 2시차에 “영어 콜”이 가능한지 |
7. 멀티클라우드: 멋이 아니라 경계 문제
멀티클라우드를 “고가용성”만으로 포장하면 곤란합니다. 진짜로 필요한 건 보통 이것입니다.
- ID 경계: 사람이 이탈해도 계정이 남지 않게
- 네트워크 경계: 피어링 vs 퍼블릭 엔드포인트 중 무엇을 허용할지
- 관측: 로그·메트릭을 한 화면에 모을지, 벤더 콘솔을 오갈지
Terraform이든 Pulumi든, 한 레포에 세 벤더가 섞이면 모듈 소유권을 나누는 규칙이 없으면 PR 지옥이 옵니다. “누가 NCP 쪽만 머지 승인한다” 정도의 단순한 룰도 도움이 됩니다.
7-1. 실전 시나리오 3개 — “우리는 어디에 가깝나?”
아래는 가상이 아니라 회의에서 자주 나오는 프로필을 압축한 것입니다. 숫자는 예시이니 그대로 복붙하지 마세요.
A. 시리즈 A 스타트업 (엔지니어 4명, 한국만)
| 항목 | 현실 | 흔한 선택 |
|---|---|---|
| 트래픽 | 일 10만 요청 미만, 스파이크 있음 | 매니지드 K8s 또는 단일 리전 VM + 오토스케일 |
| 데이터 | 사용자 PII 한국 저장 계약 | NCP 또는 AWS Seoul + 명시적 리전 락 |
| 외부 연동 | 결제·이메일 SaaS 위주 | 문서상 AWS/GCP 예제 많은 벤더가 유리 |
이때 “NCP만 쓴다”와 “AWS만 쓴다”보다 VPC 피어링이나 API만 크로스로 가는 타협이 나오기도 합니다.
B. 공공·준공공 입찰
| 항목 | 현실 | 흔한 선택 |
|---|---|---|
| 계약서 | 국내 IDC, 국내 법인 과금 | NCP 비중이 크게 나옴 |
| 감사 | 접근 로그·키 관리 증빙 | 해당 벤더의 CloudTrail급 + KMS 문서화 |
| 인력 | 외주 SI와 인수인계 | 한글 런북이 있는 쪽이 유지보수에 유리한 경우多 |
C. 글로벌 SaaS (US·EU·KR 고객)
| 항목 | 현실 | 흔한 선택 |
|---|---|---|
| 리전 | EU 데이터 거주 + KR 저지연 | 멀티 리전 필수, 팀은 보통 AWS 또는 GCP에 익숙 |
| 빌링 | Stripe + 각국 세금 | 단일 조직 청구서를 AWS Organizations / GCP Billing으로 묶는 패턴 |
7-2. Terraform provider “뼈대”만 비교 (복붙용 아님)
같은 레포에서 provider만 바꿔 PoC할 때, 블록 이름이 헷갈려서 시간을 태웁니다. 아래는 형태만 보는 용도입니다.
NCP도 Terraform provider가 있으나, 팀 정책으로 허용 버전·모듈을 먼저 정하는 게 안전합니다. “최신 예제 블로그”를 그대로 프로덕션에 넣었다가 provider major 업그레이드에 깨진 적이 있어서, 저희는 provider 버전 핀을 필수로 걸었습니다.
7-3. kubectl 컨텍스트 전환 — 멀티클라우드일 때 손에 붙일 명령
EKS, NCP Kubernetes, GKE를 오가면 지금 어느 클러스터인지가 사고의 원인이 됩니다.
실전 규칙: 프롬프트에 ctx를 띄우거나, kubectx 같은 도구로 색깔을 구분하세요. kubectl delete pod 한 방이 다른 회사 클러스터로 갔다는 농담이 실제로 나옵니다.
7-4. PoC 1주차 체크리스트 (같은 시나리오로 세 벤더 밟기)
| 일 | 할 일 | Pass 기준 예시 |
|---|---|---|
| 1 | VPC + 서브넷 + NAT(필요 시) | VM에서 인터넷·내부 DB 둘 다 붙음 |
| 2 | 오브젝트 스토리지에 아티팩트 업로드 + IAM 역할 최소권한 | 앱 키 없이 역할만으로 읽기 |
| 3 | 관측: 메트릭+로그 한 화면으로 | 알람 테스트 1건 발화 |
| 4 | 백업/스냅샷 복구 버튼 눌러봄 | RTO 목표가 문서와 맞는지 |
| 5 | 비용 알림 임계값 설정 | 의도적 초과로 메일 와 보는지 |
한 벤더만 깊게 파다 보면 PoC가 아니라 이미 결정 난 쇼가 됩니다. 같은 행을 세 번 채우는 게 포인트입니다.
7-5. 장애 대응 — 타임존이 운영비다
실전: 미국 리전에서 장애가 났는데, 지원 창구가 PST 기준이면 한국 온콜이 새벽에 영어 콜을 떠안습니다. 반대로 NCP/국내 파트너는 업무시간 겹침이 편할 수 있습니다.
| 질문 | 왜 중요한가 |
|---|---|
| Business support 응답 SLA가 몇 시간인가 | P1에서 숨 넘어감 |
| 온콜이 영어 가능한가 | 불가면 국내 벤더/파트너 비중 ↑ |
8. 우리 팀이 신규 프로젝트 시작할 때 적는 한 장짜리 메모
과장 조금 보태서, 아래 다섯 줄만 채워도 회의 시간이 반으로 줄었습니다.
- 데이터가 나가도 되는 국가 (미리 합의)
- 필수 연동 SaaS (벤더 제한 있는지)
- 온콜 언어 (영어 콜 가능 시간대)
- 예산 상한과 알람 채널 (Slack 어디로 갈지)
- 3개월 뒤 이사 가능한지 (아니면 처음부터 락인 각오)
맺으며
AWS·네이버 클라우드·GCP 중 영구적인 1위는 없습니다. 있으면 그건 마케팅 문장이고, 현장에서는 제약과 팀 상태가 이깁니다. 이 글도 결국 “이 조건이면 이렇게 많이 간다” 수준의 출발점입니다.
제품 스펙은 분기마다 바뀌니, 중요한 결정 전에는 PoC 한 번이 여전히 가장 싸게 먹힙니다. 작은 워크로드로 VPC·백업·모니터링까지 동일 시나리오를 밟아 보고, “운영할 사람이 누구인지”까지 포함해 점수를 매기면 됩니다.