기준: CLF-C02 시험 가이드오류 제보
클라우드를 한 문장으로 줄이면 "남의 컴퓨터를 빌려 쓰는 것"이다. 그런데 그 "컴퓨터"를 빌리는 방식이 한 가지가 아니다. 가상 서버 한 대를 통째로 빌릴 수도 있고, 코드 조각만 던져 두고 실행될 때만 빌릴 수도 있으며, 컨테이너 단위로 빌릴 수도 있다. 이 세 가지 방식이 각각 EC2, Lambda, ECS/Fargate다. CLF-C02 시험은 이 셋을 깊게 다루지 않지만, "어떤 상황에 어떤 컴퓨팅을 고르는가"는 반드시 묻는다.
오늘은 세 가지 컴퓨팅 서비스가 어떤 문제를 풀기 위해 태어났는지, 그리고 그것들이 "운영 책임을 얼마나 AWS에 넘기느냐"라는 하나의 축 위에 어떻게 줄지어 있는지를 정리한다.
EC2가 왜 대단한 발명이었는지 알려면, EC2 이전에 서버 한 대를 늘리는 일이 어땠는지를 봐야 한다.
클라우드가 없던 시절, 새 서비스를 열려면 이런 과정을 거쳤다. 앞으로 몇 명이 쓸지 추정하고(대부분 틀린다) → 사양을 정해 견적을 받고 → 구매 결재를 올리고 → 장비가 배송되기를 몇 주 기다리고 → 전산실에 설치해 전원·냉방·네트워크를 연결하고 → OS를 깔고 설정한 뒤에야 서비스를 올렸다.
아이디어가 떠오른 날부터 서비스가 열리는 날까지 몇 주에서 몇 달이 걸렸다. 게다가 이 모든 위험은 맨 앞의 추정에 걸려 있었다. 크게 잡으면 비싼 장비가 놀고, 작게 잡으면 서비스가 죽는다. 그리고 한번 산 장비는 되팔 수 없다.
EC2는 이 여섯 단계를 "콘솔에서 클릭 몇 번, 몇 분"으로 바꿨다. 더 중요한 변화는 심리적인 것이었다. 장비를 사는 결정은 되돌릴 수 없지만, 빌리는 결정은 되돌릴 수 있다. 틀렸으면 지우면 그만이다. 이 "되돌릴 수 있음"이 클라우드가 만든 진짜 변화이고, 앞서 배운 민첩성(Agility)의 실체다.
EC2의 E는 Elastic(탄력적인)이다. 이름 자체가 "필요에 따라 늘었다 줄었다 하는 컴퓨팅 클라우드"라는 뜻이다. AWS 서비스 이름에 Elastic이 붙으면(EC2, ELB, EBS, EFS, EKS…) 대체로 "규모를 유연하게 조절할 수 있다"는 성격을 담고 있다고 보면 된다.
EC2(Elastic Compute Cloud)는 AWS에서 가장 오래되고 기본이 되는 컴퓨팅 서비스다. 한마디로 클라우드 위의 가상 서버 한 대를 빌리는 것이다. 운영체제(Linux, Windows)를 고르고, CPU·메모리 크기를 고르고, 디스크를 붙이면 몇 분 안에 내 서버가 켜진다.
EC2가 주는 것은 "유연성과 통제권"이다. 서버에 SSH로 접속해 원하는 소프트웨어를 깔고, OS 설정을 바꾸고, 무엇이든 할 수 있다. 대신 그만큼 내가 관리할 책임도 크다 — OS 패치, 보안 업데이트, 용량 조절이 모두 내 몫이다.
EC2는 IaaS(Infrastructure as a Service)의 대표 사례다. IaaS는 "인프라(서버, 네트워크, 스토리지)만 빌려주고 그 위는 사용자가 알아서"라는 모델이다. 책임 공유 모델(Shared Responsibility Model)에서 EC2는 "AWS는 하드웨어와 하이퍼바이저까지, 사용자는 OS부터 위로"라는 경계를 가진다.
EC2 인스턴스는 용도에 따라 "유형(instance family)"으로 나뉜다. 시험에서는 패밀리 이름 하나하나를 외울 필요는 없고, "용도에 맞는 균형이 있다"는 개념만 알면 된다.
| 유형 | 특징 | 어울리는 작업 |
|---|---|---|
| 범용(General Purpose) | CPU·메모리 균형 | 웹 서버, 소규모 DB, 개발 환경 |
| 컴퓨팅 최적화(Compute Optimized) | CPU 비중 높음 | 배치 처리, 게임 서버, 고성능 연산 |
| 메모리 최적화(Memory Optimized) | RAM 비중 높음 | 대형 인메모리 DB, 캐시 |
| 스토리지 최적화(Storage Optimized) | 디스크 I/O 높음 | 대용량 데이터 웨어하우스 |
| 가속 컴퓨팅(Accelerated) | GPU 등 가속기 | 머신러닝, 그래픽 렌더링 |
핵심은 "한 가지 만능 서버는 없다"는 것이다. 메모리를 많이 쓰는 작업에 컴퓨팅 최적화 인스턴스를 쓰면 비싸고 비효율적이다. 작업의 성격에 맞춰 모양을 고르는 것이 비용 최적화의 첫걸음이다.
AWS 문서를 보면 t3.micro, m5.large 같은 이름이 계속 나온다. 암호처럼 보이지만 규칙은 단순하다.
t3.micro
│ │ └── 크기 (nano < micro < small < medium < large < xlarge < 2xlarge …)
│ └───── 세대 (숫자가 클수록 최신)
└─────── 인스턴스 패밀리 (용도 계열)
패밀리(첫 글자)는 용도 계열이다. t와 m은 범용, c는 컴퓨팅 최적화(Compute), r은 메모리 최적화(RAM), g·p는 GPU가 붙은 가속 컴퓨팅 계열이다. 세대(숫자)는 클수록 최신 하드웨어이고, 보통 최신 세대가 같은 값에 더 나은 성능을 준다. 크기(점 뒤)는 같은 패밀리 안에서 CPU·메모리 규모가 단계적으로 커지는 눈금이다.
시험에서 특정 인스턴스 이름을 외울 필요는 전혀 없다. 다만 "이름만 봐도 용도와 크기를 읽을 수 있다"는 감각은 이후 학습을 훨씬 편하게 만든다.
서버가 부족할 때 늘리는 방법은 두 가지다. 이름이 비슷해서 시험에서 자주 뒤바뀐다.
| 구분 | 스케일 업(Scale Up, 수직 확장) | 스케일 아웃(Scale Out, 수평 확장) |
|---|---|---|
| 방법 | 서버 한 대를 더 큰 것으로 교체 | 서버를 여러 대로 늘림 |
| 비유 | 1인용 책상을 더 큰 책상으로 바꾼다 | 책상을 한 개 더 놓는다 |
| 한계 | 가장 큰 사양 이상은 못 간다 | 이론적으로 계속 늘릴 수 있다 |
| 장애 영향 | 그 한 대가 죽으면 서비스 정지 | 한 대가 죽어도 나머지가 버틴다 |
| 보통 필요한 일 | 인스턴스 중지 후 유형 변경 | 앞단에 트래픽 분배 장치 필요 |
클라우드가 특히 잘하는 쪽은 스케일 아웃이다. 여러 대로 나눠 두면 확장도 자유롭고 안정성도 올라가기 때문이다.
⚠️ 함정: 두 용어를 반대로 외우는 사람이 정말 많다. "업(Up) = 위로 = 한 대를 크게", "아웃(Out) = 옆으로 = 대수를 늘리기"로 방향을 그림으로 기억한다. 그리고 지문에 "고가용성"이나 "한 대가 죽어도"가 함께 나오면 거의 항상 스케일 아웃이 정답이다. 스케일 업은 대수가 그대로라 가용성을 올려 주지 못한다.
스케일 아웃을 실제로 하려면 두 가지가 필요하다. 자격증 기초 단계에서는 "무엇을 하는 물건인지"만 알면 충분하다.
이 둘을 묶으면 이렇게 된다.
사용자 요청
↓
[ ELB ] ← 요청을 골고루 분배 + 죽은 서버 우회
↙ ↓ ↘
EC2 EC2 EC2 ← Auto Scaling이 대수를 자동 조절
(AZ-a) (AZ-b) … ← 여러 AZ에 걸쳐 두면 고가용성까지
온라인 강의 사이트가 매주 월요일 저녁에만 접속이 몰린다고 가정한다. 예전에는 그 두 시간을 위해 서버를 상시 크게 유지해야 했다. Auto Scaling을 쓰면 접속이 늘 때 자동으로 대수를 늘리고 새벽에는 최소로 줄인다. ELB는 그 사이 요청을 살아 있는 서버들에 고르게 나눠 준다. 성능과 비용을 동시에 잡는 전형적인 조합이다.
EC2는 똑같은 서버라도 "어떻게 사느냐"에 따라 가격이 크게 달라진다. 이 구매 방식은 시험 범위에 든다.
| 구매 옵션 | 개념 | 어울리는 상황 |
|---|---|---|
| 온디맨드(On-Demand) | 쓰는 만큼 시간당 과금, 약정 없음 | 예측 불가·단기·테스트 워크로드 |
| 예약 인스턴스(Reserved Instance) | 1년/3년 약정으로 최대 ~72% 할인 | 24시간 꾸준히 도는 안정 워크로드 |
| Savings Plans | 약정 사용량($/시간) 기준 할인 | 유연한 장기 사용 |
| 스팟 인스턴스(Spot) | 남는 용량을 최대 ~90% 싸게, 중단 가능 | 중단돼도 괜찮은 배치·내결함성 작업 |
| 전용 호스트(Dedicated Host) | 물리 서버 통째로 점유 | 라이선스·규정 준수 요구 |
구매 옵션의 본질은 "예측 가능성과 가격의 교환"이다. 약정을 길게 하고 중단을 감수할수록 싸진다. 온디맨드는 가장 비싸지만 가장 자유롭고, 스팟은 가장 싸지만 AWS가 언제든 회수할 수 있다. 이건 AWS Well-Architected의 비용 최적화(Cost Optimization) 기둥의 핵심 도구다.
⚠️ 함정: 스팟 인스턴스는 "AWS가 용량이 필요하면 2분 통보 후 회수"한다는 점이 핵심이다. 그래서 결제 처리나 상태가 중요한 작업에는 부적합하고, 중단돼도 다시 시작하면 되는 배치·렌더링·CI 빌드 같은 작업에 적합하다.
구매 옵션 문항은 지문에서 세 가지 질문만 던지면 거의 갈린다.
① 워크로드가 중단돼도 괜찮은가?
예 → 스팟(Spot)
아니오 ↓
② 1년 이상 꾸준히 쓸 것이 확실한가?
예 → 예약 인스턴스 / Savings Plans
(인스턴스 유형까지 고정이면 예약, 유연하게 쓰고 싶으면 Savings Plans)
아니오 ↓
③ 물리 서버 단위 점유나 특정 라이선스·규정 요구가 있는가?
예 → 전용 호스트(Dedicated Host)
아니오 → 온디맨드(On-Demand)
지문 신호도 정리해 둔다. "단기·테스트·예측 불가"면 온디맨드, "1년/3년·꾸준한"이면 예약/Savings Plans, "중단돼도 무방·내결함성·배치"면 스팟, "라이선스·물리 서버 분리 규정"이면 전용 호스트다.
EC2가 "서버를 빌리는 것"이라면 Lambda는 "서버를 잊는 것"이다. 코드(함수)만 올려 두면, 이벤트가 발생할 때마다 AWS가 알아서 실행 환경을 띄워 코드를 돌리고, 끝나면 내린다. 관리할 서버 자체가 없다.
Lambda의 특징을 세 가지로 정리하면:
Lambda는 서버리스(Serverless)의 대표 주자다. "서버리스"는 서버가 없다는 뜻이 아니라, 서버를 사용자가 보거나 관리하지 않는다는 뜻이다. OS 패치, 용량 계획, 확장이 전부 AWS의 책임으로 넘어간다. 책임 공유 모델에서 사용자가 책임지는 영역이 EC2보다 훨씬 작아진다.
하루에 몇 번, 불규칙하게 들어오는 이미지 썸네일 생성 작업을 생각해 본다. EC2로 하면 서버를 24시간 켜 두고 대부분 놀게 된다. Lambda로 하면 이미지가 올라온 그 순간에만 실행되고 비용도 그때만 든다. 이런 "간헐적·이벤트성 작업"이 Lambda의 전형적 무대다.
Lambda는 만능이 아니다. 어울리지 않는 자리를 아는 것이 시험에서는 더 중요하다.
함정: "서버리스니까 무조건 싸고 좋다"는 보기는 오답 신호다. Lambda가 저렴한 이유는 놀 때 돈이 안 들어서이지 단가가 싸서가 아니다. 그래서 놀 시간이 많은 워크로드일수록 유리하고, 24시간 꽉 찬 워크로드일수록 이점이 줄어든다. 지문에 "간헐적", "불규칙", "이벤트가 발생할 때만"이 있으면 Lambda, "상시 가동", "일정한 트래픽"이면 EC2/컨테이너 쪽을 먼저 의심한다.
세 번째는 컨테이너다. 컨테이너는 "애플리케이션과 그 실행에 필요한 모든 것을 하나의 표준 상자에 담아 어디서든 똑같이 돌리는" 기술이다(대표 도구가 Docker). AWS에서 컨테이너를 운영하는 대표 서비스가 ECS(Elastic Container Service)다.
가상 서버(VM)와 컨테이너는 뭐가 다를까. 이사에 비유하면, VM은 집 한 채를 통째로 옮기는 것이다. 운영체제까지 각자 하나씩 들고 다니므로 무겁고 켜는 데 시간이 걸린다. 컨테이너는 짐만 규격 상자에 담아 옮긴다. 바닥(운영체제)은 여러 상자가 함께 쓰므로 가볍고 몇 초 만에 뜬다.
| 구분 | 가상 서버(VM, EC2) | 컨테이너 |
|---|---|---|
| 각자 갖는 것 | 운영체제를 통째로 하나씩 | 앱과 필요한 라이브러리만 |
| 무게·시작 속도 | 무겁고 느림 | 가볍고 빠름 |
| 격리 수준 | 강함 | VM보다는 약함 |
| 어울리는 상황 | OS 수준 통제가 필요할 때 | 같은 앱을 여러 환경에 똑같이 배포할 때 |
컨테이너의 진짜 매력은 "내 노트북에서 되던 게 서버에서도 똑같이 된다"는 점이다.
여기서 한 가지를 더 구분해야 한다 — 컨테이너를 어디서 돌리느냐다.
| 실행 방식 | 개념 | 관리 부담 |
|---|---|---|
| ECS on EC2 | 내가 빌린 EC2 위에서 컨테이너 실행 | 서버 관리 내 책임 |
| ECS on Fargate | 서버 없이 컨테이너만 실행(서버리스) | 서버 관리 AWS 책임 |
즉 Fargate는 "컨테이너용 서버리스"다. EC2를 직접 빌려 그 위에서 컨테이너를 돌릴 수도 있고(통제권 ↑, 관리 부담 ↑), Fargate를 써서 서버를 신경 쓰지 않을 수도 있다(편리함 ↑).
AWS에는 ECS 외에 EKS(Elastic Kubernetes Service)도 있다. EKS는 오픈소스 표준인 Kubernetes를 AWS가 관리형으로 제공하는 것이다. 시험 입문 수준에서는 "ECS는 AWS 고유 방식, EKS는 Kubernetes 표준 방식, 둘 다 Fargate로 서버리스 실행 가능"이라는 정도만 알면 충분하다.
세 서비스는 따로따로 외우기보다, "운영 책임을 얼마나 AWS에 넘기는가"라는 하나의 축 위에서 보면 명료해진다.
[ 통제권 ↔ 편리함의 스펙트럼 ]
내가 더 관리 AWS가 더 관리
통제권 큼 관리 부담 작음
───────────────────────────────────────►
EC2 → ECS on EC2 → ECS on Fargate → Lambda
(서버 직접) (컨테이너 서버리스) (함수 서버리스)
왼쪽으로 갈수록 자유롭지만 손이 많이 가고, 오른쪽으로 갈수록 편하지만 통제권은 줄어든다. 시험 시나리오에서 "운영 부담을 최소화하고 싶다"는 키워드가 나오면 오른쪽(Lambda/Fargate)이 정답이고, "OS 수준의 세밀한 통제가 필요하다"면 왼쪽(EC2)이 정답이다.
🎯 시나리오: "트래픽이 거의 없다가 갑자기 폭증하는 이벤트성 API를, 운영 인력 없이 운영하고 싶다." → Lambda. 자동 확장 + 사용한 만큼 과금 + 서버 관리 불필요라는 세 조건을 모두 만족한다. 반대로 "특정 OS 커널 설정이 필요한 레거시 앱"이라면 EC2다.
| 지문 키워드 | 고를 것 |
|---|---|
| OS 커널 설정, 특정 소프트웨어 직접 설치, 완전한 통제 | EC2 |
| 24시간 꾸준한 트래픽, 1년 이상 안정 운영 | EC2 + 예약 / Savings Plans |
| 중단돼도 무방한 배치·렌더링, 최대한 저렴하게 | EC2 스팟 |
| 라이선스 요구, 물리 서버 단위 점유 | 전용 호스트 |
| 간헐적·이벤트 기반, 서버 관리 없이, 놀 땐 비용 0 | Lambda |
| 컨테이너로 배포, 그런데 서버는 관리하기 싫다 | ECS/EKS on Fargate |
| 컨테이너인데 기반 서버를 직접 통제해야 한다 | ECS/EKS on EC2 |
| 이미 Kubernetes를 쓰고 있다 | EKS |
| 트래픽 변화에 맞춰 서버 대수를 자동 조절 | Auto Scaling |
| 여러 서버에 요청을 고르게 분배 | ELB |
함정: "운영 부담 최소화"와 "완전한 통제"는 동시에 만족시킬 수 없다. 보기 중에 둘 다 준다고 하는 것이 있으면 그게 오답이다. 지문이 둘 중 무엇을 요구하는지만 정확히 읽으면 컴퓨팅 선택 문항은 대부분 두 개로 좁혀진다.
EC2의 인스턴스 유형은 "작업에 맞는 모양", 구매 옵션은 "예측 가능성과 가격의 교환"이라는 두 개념만 잡으면 된다. Lambda와 Fargate의 공통 키워드는 "서버리스 = 서버를 안 보고 안 관리한다"이다.
내일은 컴퓨팅이 만들어 낸 데이터를 어디에 저장하는가 — S3, EBS, EFS로 이어지는 스토리지의 세계를 본다.
선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
트래픽이 불규칙하고 간헐적으로 발생하는 이벤트성 작업을, 서버를 직접 관리하지 않고 사용한 만큼만 비용을 내며 운영하려고 한다. 가장 적합한 컴퓨팅 서비스는?
문제 2
중단되어도 다시 시작하면 되는 대규모 배치 처리 작업을 가능한 한 저렴하게 실행하려고 한다. 가장 비용 효율적인 EC2 구매 옵션은?
문제 3
컨테이너 기반 애플리케이션을 운영하되, 그 컨테이너를 돌리는 서버(EC2)를 직접 프로비저닝하거나 관리하고 싶지 않다. 적합한 조합은?
문제 4
다음 중 EC2 인스턴스 유형(instance family)을 고르는 기준을 가장 정확히 설명한 것은?
문제 5
"서버리스(Serverless)"라는 용어의 의미로 가장 정확한 것은?