스타트업 CTO가 말합니다. "다음 달 TV 광고 나가면 트래픽이 평소의 50배가 될 수도, 안 터질 수도 있어요." 온프레라면 50배를 감당할 서버를 미리 사둬야 하고, 광고가 실패하면 그 장비는 1년 내내 먼지만 쌓입니다. 반대로 적게 사두면 광고 성공 순간 사이트가 다운됩니다. 사거나 말거나, 둘 다 도박입니다. 클라우드는 이 도박을 "필요할 때 빌리고 끝나면 반납하는" 문제로 바꿉니다 — 단, 공짜는 아닙니다.
- 1온프레미스와 클라우드의 근본 차이를 '소유 vs 임대'로 설명할 수 있다
- 2CapEx에서 OpEx로의 전환이 의사결정에 주는 의미를 안다
- 3탄력성이 비용·가용성에 주는 실질 이점을 예로 들 수 있다
- 4책임 공유 모델에서 제공자와 고객의 책임 경계를 구분할 수 있다
- 5클라우드가 '자동으로 해결해주지 않는' 것을 안다
소유에서 임대로 — 발상의 전환
서버를 직접 사서 데이터센터에 넣고 운영하는 방식을 온프레미스(on-premises, 온프레) 라고 합니다. 내 건물, 내 장비, 내 책임입니다. 클라우드는 이 모든 것을 남의 거대한 데이터센터에서 빌려 쓰는 방식입니다.
왜 '빌리는 것'이 게임을 바꾸는가
서버를 사면(CapEx, 자본지출) 수천만 원을 미리 집행하고, 그 장비를 3~5년 감가상각하며 씁니다. 트래픽이 적든 많든 이미 지불한 돈입니다. 빌리면(OpEx, 운영지출) 초기 투자 없이 시작하고, 쓴 시간·용량만큼 매달 청구됩니다.
핵심은 "싸다"가 아니라 "유연하다" 입니다. 실험을 빠르게 시작하고, 실패하면 즉시 멈춰 비용을 0에 가깝게 만들 수 있습니다. 의사결정의 단위가 '수개월·수천만 원'에서 '수분·수천 원'으로 작아집니다.
위 그림처럼 온프레는 피크에 맞춘 고정 용량(파란 선)을 미리 깔아두고 평소엔 남깁니다. 클라우드는 수요를 따라가는 탄력적 용량(초록 선)으로, 놀리는 자원을 줄입니다.
탄력성(Elasticity) — 1년에 하루를 위한 장비를 사지 않는다
쇼핑몰의 트래픽은 세일 당일에 폭증하고 나머지는 잔잔합니다. 온프레는 그 하루를 위해 큰 장비를 사고 364일을 놀립니다. 클라우드의 탄력성은 수요가 오르면 분 단위로 늘리고, 끝나면 반납합니다. 평소 비용은 낮게, 피크는 안정적으로 — 이것이 OpEx 모델과 만날 때 진짜 절감이 됩니다.
가장 많이 틀리는 것 — 책임 공유 모델
"클라우드에 올렸으니 보안은 알아서 되겠지"가 사고의 출발점입니다. 클라우드 보안은 나눠 갖는 것입니다.
of the cloud vs in the cloud
제공자(AWS/GCP/Azure)는 "클라우드 자체(of the cloud)" 를 책임집니다 — 데이터센터 물리 보안, 전력·냉각, 하드웨어, 하이퍼바이저. 고객은 "클라우드 안(in the cloud)" 을 책임집니다 — OS·앱 패치, IAM 권한 설정, 방화벽(보안그룹) 규칙, 데이터 암호화, 키 관리.
대부분의 클라우드 유출 사고는 제공자의 시설이 뚫려서가 아니라, 고객이 S3 버킷을 공개로 열어두거나, 권한을 과하게 부여해서 발생합니다. 경계를 모르면 "내 일이 아닌 줄 알았던" 영역에서 사고가 납니다.
클라우드 작업의 첫걸음은 "지금 나는 어떤 신원(identity)으로 무슨 권한을 갖고 있나"를 아는 것입니다. AWS CLI가 설정돼 있다면 아래로 현재 계정·사용자를 확인합니다.
aws sts get-caller-identity
{
"UserId": "AIDA...EXAMPLE",
"Account": "123456789012",
"Arn": "arn:aws:iam::123456789012:user/dev-klksm"
}
aws sts get-caller-identity클라우드는 "켜두면 돈이 나간다"가 기본입니다. 실습/테스트 후 끄지 않은 인스턴스가 한 달 내내 과금되는 일이 흔합니다. 실행 중 인스턴스를 확인합니다.
aws ec2 describe-instances \
--query "Reservations[].Instances[].{Id:InstanceId,Type:InstanceType,State:State.Name}" \
--output table
-------------------------------------------------
| DescribeInstances |
+----------------------+-------------+----------+
| i-0abc123def456 | t3.micro | running |
+----------------------+-------------+----------+
aws ec2 describe-instances --query ...- get-caller-identity의 Arn — user/...면 IAM 사용자, assumed-role/...면 역할로 접속 중. 루트 계정으로 일상 작업 중이면 즉시 멈추고 IAM 사용자로 전환
- Account 번호 — 회사 계정인지 개인 계정인지. 엉뚱한 계정에 자원을 만들면 비용·정리 책임이 꼬임
- describe-instances의 State가 running인 인스턴스 수 — 의도한 것만 떠 있는가? 기억에 없는 running은 미정리 자원·침해 신호일 수 있음
- InstanceType이 예상보다 큰 것(예: 테스트인데 m5.large) — 과금의 주범. 작은 타입으로 교체 검토
상황: CLI는 설정돼 있는데 명령이 권한 거부로 막힘.
원인: 현재 신원(IAM 사용자/역할)에 해당 작업(ec2:DescribeInstances) 권한이 없음. 책임 공유 모델에서 권한 설정은 고객 책임 — 제공자가 막은 게 아니라 내 정책이 허용하지 않은 것.
진단: aws sts get-caller-identity로 현재 신원 확인 → 해당 사용자/역할에 붙은 정책을 콘솔 IAM에서 점검.
해결: 최소권한 원칙에 따라 필요한 액션만 허용하는 정책을 부여. 읽기만 필요하면 ReadOnlyAccess 같은 관리형 정책으로 시작하고, 절대 모든 작업에 *를 남발하지 않음. 권한은 [[cloud-account-iam]]에서 깊게 다룹니다.
인프라 엔지니어 면접·실무에서 "왜 클라우드를 쓰나요?"에 "요즘 다 쓰니까"는 감점입니다. 좋은 답은 "우리 트래픽이 변동성이 커서 탄력성이 필요했고, 초기 자본 투자 없이 빠르게 검증해야 했다. 다만 항상 켜져 있는 배치 서버는 비용상 예약형으로 분리했다" 처럼 트레이드오프를 말하는 것입니다.
PM 관점에서도 중요합니다. "클라우드로 옮기면 비용이 준다"고 보고했다가 lift-and-shift 후 청구서가 더 나오는 일이 잦습니다. 클라우드 비용은 설계와 운영의 결과이지 플랫폼만 바꾼다고 줄지 않습니다 — 이는 [[cloud-cost-optimization]]의 핵심 주제입니다.
다음 모듈에서는 클라우드가 자원을 빌려주는 세 가지 층위 — IaaS·PaaS·SaaS 와, 전 세계에 흩어진 리전·가용영역(AZ) 의 구조를 다룹니다.