이번 회차에서 다룬 내용

2026년 1월 13일 화요일, AWS Certified Cloud Practitioner(CLF-C02) 스터디 3회차를 진행했다. 이번 회차의 주제는 Compute 핵심이었다.

발표자 배정표 기준으로 3회차 범위는 다음과 같았다.

  • A(대산): EC2 기본 개념 & 인스턴스 타입
  • B(대산): EC2 Security Group
  • C(지현): Auto Scaling 개념
  • D(지현): Lambda vs EC2 vs LightSail

이번 회차는 개인적으로도 꽤 중요했다. 1회차와 2회차에서 클라우드 개념과 AWS 글로벌 인프라를 배웠다면, 3회차부터는 “그 위에서 실제로 어떤 컴퓨팅 자원을 어떻게 선택할 것인가”라는 더 실무적인 질문으로 넘어오기 때문이다.

Cloud Practitioner를 공부하면서 많이 드는 생각이 있는데, 결국 AWS의 많은 서비스는 “어떤 문제를 어떤 수준의 관리 부담으로 해결할 것인가”를 선택하는 과정이라는 점이다. 3회차는 그 질문을 가장 직접적으로 다루는 회차였다.

왜 Compute가 중요한가

클라우드에서 대부분의 애플리케이션은 결국 “무언가를 실행하는 컴퓨팅 자원” 위에서 동작한다.

  • 웹 서버를 돌릴 수도 있고
  • API 서버를 띄울 수도 있고
  • 배치 작업을 실행할 수도 있고
  • 특정 이벤트가 발생했을 때 짧은 코드를 돌릴 수도 있다

그런데 모든 경우를 같은 방식으로 처리할 필요는 없다.

예를 들면:

  • 서버를 오래 켜두고 직접 관리해야 하는가
  • 사용량에 따라 자동으로 늘고 줄어야 하는가
  • 아예 서버를 신경 쓰지 않고 코드만 실행하면 되는가
  • 정해진 월 비용 안에서 간단히 시작하는 것이 더 중요한가

이 질문에 따라 EC2, Lambda, Lightsail 같은 선택지가 달라진다.

즉, 3회차는 “AWS에서 컴퓨팅을 선택하는 기본 문법”을 배우는 시간이었다.

EC2란 무엇인가

EC2(Elastic Compute Cloud)는 AWS에서 제공하는 대표적인 가상 서버 서비스다.

가장 단순하게 말하면:

  • 물리 서버를 직접 사지 않고
  • AWS가 제공하는 가상 컴퓨터를
  • 원하는 사양으로 빌려 쓰는 서비스

라고 보면 된다.

왜 이름이 Elastic Compute Cloud인가

  • Compute: 연산 자원
  • Cloud: 클라우드에서 제공
  • Elastic: 필요에 따라 유연하게 조정 가능

즉, 클라우드에서 유연하게 쓸 수 있는 가상 서버라는 의미가 그대로 들어 있다.

EC2를 이해하는 가장 쉬운 비유

EC2는 클라우드 안에 있는 “내가 직접 관리하는 컴퓨터”에 가깝다.

노트북과 비슷하게 생각하면:

  • 운영체제를 선택할 수 있고
  • CPU와 메모리 사양을 고를 수 있고
  • 네트워크 설정을 할 수 있고
  • 어떤 소프트웨어를 설치할지도 정할 수 있다

하지만 차이점도 있다.

  • 물리 장비를 직접 만지지 않아도 된다
  • 몇 분 안에 생성할 수 있다
  • 필요 없으면 종료할 수 있다
  • 여러 대를 동시에 운영할 수 있다

Cloud Practitioner 수준에서는 EC2를 “제어권이 높은 가상 서버”라고 이해하면 된다.

EC2가 적합한 경우

EC2는 다음과 같은 상황에서 잘 맞는다.

  • 운영체제 수준 제어가 필요할 때
  • 특정 소프트웨어를 직접 설치해야 할 때
  • 장시간 실행되는 애플리케이션이 필요할 때
  • 서버 구성 자체를 세밀하게 커스터마이징해야 할 때

예를 들어:

  • 웹 애플리케이션 서버
  • 백엔드 API 서버
  • 레거시 애플리케이션 이전
  • 자체 구성 미들웨어가 필요한 시스템

이런 환경에서는 EC2가 자연스러운 선택이 된다.

EC2의 장점과 부담

장점

  • 제어권이 크다
  • 유연성이 높다
  • 다양한 워크로드를 수용할 수 있다

부담

  • 운영체제 관리가 필요하다
  • 패치, 보안 설정, 모니터링을 신경 써야 한다
  • 서버 수가 많아질수록 운영 부담이 커진다

즉, EC2는 자유도가 높은 대신 그만큼 사용자가 책임지는 영역도 많다. 이 점은 나중에 Lambda와 비교할 때 더 분명해진다.

EC2 인스턴스 타입이란 무엇인가

EC2는 “가상 서버”라고만 이해하면 반만 이해한 셈이다. 실제로는 어떤 종류의 가상 서버를 쓸지 고르는 과정이 중요하다. 이것이 인스턴스 타입(instance type) 개념이다.

인스턴스 타입은 쉽게 말하면:

  • CPU가 더 중요한지
  • 메모리가 더 중요한지
  • 스토리지 성능이 중요한지
  • GPU가 필요한지

같은 기준에 따라 서버 유형을 고르는 것이다.

왜 인스턴스 타입이 중요한가

같은 “서버”라도 모든 작업이 같은 자원을 요구하지는 않는다.

예를 들어:

  • 단순 웹 서버는 균형형이면 충분할 수 있고
  • 메모리 캐시 서버는 메모리 비중이 높아야 하며
  • 머신러닝 추론은 GPU가 필요할 수 있다

즉, 인스턴스 타입은 비용과 성능을 함께 최적화하기 위한 선택이다.

인스턴스 타입을 시험 수준에서 이해하는 법

CLF-C02에서는 세세한 타입 코드 암기보다 유형별 목적을 구분하는 것이 중요하다.

대표적으로 이렇게 이해하면 된다.

범용(General Purpose)

CPU, 메모리, 네트워크가 비교적 균형 잡힌 유형이다.

적합한 경우:

  • 웹 서버
  • 중소규모 애플리케이션 서버
  • 일반적인 워크로드

컴퓨팅 최적화(Compute Optimized)

CPU 성능 비중이 더 높은 유형이다.

적합한 경우:

  • 연산 집약적 작업
  • 고성능 웹 서버
  • 배치 처리 일부

메모리 최적화(Memory Optimized)

RAM 비중이 큰 유형이다.

적합한 경우:

  • 인메모리 데이터베이스
  • 캐시 서버
  • 대규모 메모리 분석 작업

스토리지 최적화(Storage Optimized)

로컬 스토리지 처리량이나 I/O가 중요한 유형이다.

적합한 경우:

  • 고성능 스토리지 워크로드
  • 대용량 데이터 처리

시험에서는 “어떤 인스턴스 타입이 좋을까”라고 아주 직접적으로 나오기보다, 워크로드 특성에 따라 맞는 유형을 고르게 하는 경우가 많다.

인스턴스 타입 선택에서 중요한 사고 방식

처음 공부할 때는 “좋은 서버 = 큰 서버”처럼 느껴질 수 있다. 하지만 클라우드에서는 그 생각이 오히려 비효율적일 수 있다.

핵심은:

  • 필요한 만큼의 자원만 쓰고
  • 워크로드 특성에 맞는 타입을 고르고
  • 필요하면 나중에 바꾸는 것

이다.

즉, 클라우드에서는 미리 너무 크게 잡는 것보다, 맞는 타입을 선택하고 필요에 따라 조정하는 것이 더 중요하다.

이 사고 방식은 Auto Scaling과도 이어진다. 인스턴스 한 대를 무작정 크게 키우는 것보다, 적절한 인스턴스를 여러 대 두고 자동 조절하는 설계가 더 좋은 경우가 많다.

Security Group이란 무엇인가

EC2를 띄우면 곧바로 따라오는 개념이 Security Group 이다.

Security Group은 EC2 인스턴스에 붙는 가상 방화벽이다.

즉:

  • 어떤 트래픽은 들어오게 하고
  • 어떤 트래픽은 막을지

를 정하는 규칙 집합이다.

쉽게 생각하면

EC2가 건물이라면 Security Group은 출입문 규칙에 가깝다.

  • 80번 포트는 웹 트래픽이니 허용할까
  • 22번 포트는 SSH 접속이니 특정 IP만 허용할까
  • 데이터베이스 포트는 애플리케이션 서버에서만 접근하게 할까

이런 식으로 접근 통제 규칙을 정하는 것이다.

Security Group의 핵심 특징

Cloud Practitioner 수준에서 꼭 기억해야 할 특징은 다음이다.

1. Allow 규칙만 가진다

Security Group은 기본적으로 허용 규칙을 추가하는 방식이다.

즉:

  • 허용한 것은 들어오고
  • 나머지는 자동으로 거부된다

별도의 explicit deny 규칙을 직접 넣는 방식으로 이해하지 않는 편이 좋다.

2. Stateful이다

상태 저장(stateful)이라는 점이 중요하다.

예를 들어:

  • 들어오는 요청을 허용하면
  • 그에 대한 응답 트래픽은 별도로 규칙을 쓰지 않아도 허용된다

이건 나중에 NACL 같은 개념과 비교할 때 중요하지만, CLF-C02에서는 “Security Group은 stateful” 정도만 분명히 기억해도 충분하다.

3. 인스턴스 단위에 가깝다

Security Group은 EC2 인스턴스와 연결되어 보호하는 방식으로 생각하면 된다.

즉, 네트워크 전체보다 인스턴스 접근 제어에 더 가까운 개념이다.

왜 Security Group이 중요한가

서버를 올리는 것보다 더 중요한 것이 “누가 접속할 수 있는가”를 통제하는 일이다.

예를 들어:

  • 웹 서버는 80/443 포트를 열어야 할 수 있다
  • SSH 접속은 관리자 IP만 허용해야 할 수 있다
  • DB 서버는 외부 인터넷이 아니라 특정 애플리케이션 서버만 접근해야 할 수 있다

이런 설계가 없으면 서버가 인터넷에 노출되기만 하고, 보안은 허술해진다.

Cloud Practitioner 시험에서는 보통:

  • “EC2에 대한 접근을 제어하는 서비스는?”
  • “가상 방화벽 역할을 하는 것은?”

같은 형태로 Security Group을 묻는다.

내가 맡았던 주제 1: Auto Scaling

이번 3회차에서 내가 맡은 첫 번째 발표는 Auto Scaling 개념이었다.

이 주제는 1회차에서 배운 탄력성(Elasticity)을 실제로 구현하는 대표 사례라고 볼 수 있다.

Auto Scaling이 필요한 이유

트래픽은 늘 일정하지 않다.

예를 들어 쇼핑몰이라면:

  • 평일 새벽에는 접속이 적고
  • 점심 시간대에는 늘 수 있고
  • 행사 시간이나 주말에는 갑자기 몰릴 수 있다

이럴 때 항상 최대 트래픽 기준으로 서버를 켜두면 낭비가 크다. 반대로 적은 서버만 두면 갑자기 트래픽이 몰릴 때 장애가 날 수 있다.

Auto Scaling은 이 문제를 해결하기 위해:

  • 필요할 때는 인스턴스를 늘리고
  • 한가할 때는 줄이고
  • 비정상 인스턴스는 교체하는

구조를 제공한다.

Auto Scaling Group(ASG)

Auto Scaling을 이해할 때 중심이 되는 개념은 Auto Scaling Group 이다.

이건 여러 EC2 인스턴스를 하나의 묶음처럼 관리하는 구조다.

ASG로 할 수 있는 것

  • 최소 인스턴스 수 설정
  • 최대 인스턴스 수 설정
  • 원하는 인스턴스 수 유지
  • 상태가 나쁜 인스턴스 교체
  • 조건에 따라 자동 확장/축소

즉, EC2를 “한 대씩 수동으로” 관리하는 것이 아니라, 집합 단위로 관리하게 해주는 개념이다.

Scale Out, Scale In, Self-Healing

Auto Scaling에서 자주 나오는 핵심 동작은 세 가지다.

Scale Out

부하가 커질 때 인스턴스를 추가하는 것

예:

  • CPU 사용률 증가
  • 요청 수 증가
  • 트래픽 급증

Scale In

부하가 줄어들 때 인스턴스를 줄이는 것

예:

  • 야간 시간대
  • 이벤트 종료 후 트래픽 감소

Self-Healing

비정상 상태의 인스턴스를 감지해 제거하고 새 인스턴스로 교체하는 것

이건 단순 확장보다도 운영 안정성 측면에서 중요하다. Auto Scaling은 성능 대응뿐 아니라 기본적인 복원력 확보에도 도움이 된다.

Auto Scaling 정책 유형

발표 자료에서도 다뤘던 것처럼 Auto Scaling은 여러 방식으로 동작시킬 수 있다.

1. 수동 조정

사람이 직접 인스턴스 수를 바꾸는 방식

자동화의 의미는 약하지만, 기본 개념 이해에는 도움이 된다.

2. 동적 스케일링(Dynamic Scaling)

실시간 지표에 반응해서 인스턴스 수를 조정한다.

예:

  • CPU 70% 초과 시 1대 추가
  • CPU 30% 이하 시 1대 감소

시험에서는 “경보(alarm)에 반응한다”는 느낌으로 이해하면 좋다.

3. 예약 스케일링(Scheduled Scaling)

미리 정해진 시간에 따라 조정한다.

예:

  • 매주 금요일 오후 6시에 트래픽 급증
  • 업무 시간 전에 서버 수 미리 늘리기

패턴이 예측 가능할 때 적합하다.

4. 예측 스케일링(Predictive Scaling)

과거 데이터를 기반으로 트래픽을 예측하고, 미리 인스턴스를 준비하는 방식이다.

자료에서는 머신러닝 기반 접근으로 설명되어 있었다. Cloud Practitioner에서는 “과거 패턴을 보고 미리 준비한다” 정도의 감각을 잡으면 충분하다.

Auto Scaling을 시험 관점에서 이해하는 법

시험에서는 아주 기술적으로 설정값을 묻기보다, 어떤 상황에 어떤 스케일링 방식이 적절한지 판단하게 하는 문제가 많다.

예를 들면:

  • 매주 특정 시간대에 트래픽이 오른다 → Scheduled Scaling
  • CPU 지표에 따라 자동 대응해야 한다 → Dynamic Scaling
  • 과거 패턴을 학습해 미리 늘리고 싶다 → Predictive Scaling
  • 인스턴스 장애 시 자동 복구가 필요하다 → ASG 활용

즉, Auto Scaling은 단순 기능이 아니라 비용 최적화와 가용성을 동시에 잡는 핵심 메커니즘으로 이해하는 것이 좋다.

내가 맡았던 주제 2: Lambda vs EC2 vs LightSail

이번 3회차에서 내가 맡은 두 번째 발표는 Lambda, EC2, Lightsail 비교였다.

이 비교는 Cloud Practitioner 공부에서 특히 중요하다. AWS에는 컴퓨팅 서비스가 많기 때문에, “무조건 EC2” 식으로 이해하면 안 된다. 어떤 서비스는 직접 서버를 다뤄야 하고, 어떤 서비스는 서버를 거의 의식하지 않아도 되며, 어떤 서비스는 초보자에게 더 단순한 진입점을 제공한다.

Lambda란 무엇인가

AWS Lambda는 서버를 프로비저닝하거나 관리하지 않고 코드를 실행하는 서버리스 컴퓨팅 서비스다.

핵심 포인트

  • 사용자는 서버를 직접 만들지 않는다
  • 이벤트가 발생했을 때 코드가 실행된다
  • 실행 시간 기반으로 비용이 청구된다
  • 짧고 독립적인 작업에 잘 맞는다

자료에도 나왔듯이 Lambda는 실행 시간 제한이 있다. Cloud Practitioner에서는 최대 15분이라는 점을 기억해두는 것이 중요하다.

Lambda가 잘 맞는 경우

  • 파일 업로드 후 처리
  • 간단한 API 백엔드
  • 이벤트 기반 자동화
  • 간헐적으로 발생하는 작업

즉, Lambda는 “항상 켜진 서버”보다는 “필요할 때만 실행되는 코드”에 가깝다.

Lightsail이란 무엇인가

Amazon Lightsail은 AWS를 처음 쓰는 사용자나 소규모 프로젝트를 위해 더 단순하게 제공되는 서비스다.

쉽게 말하면:

  • EC2보다 간단하고
  • 월 정액제 성격이 강하고
  • VPS처럼 시작하기 쉬운 서비스

라고 보면 된다.

Lightsail이 잘 맞는 경우

  • 간단한 웹사이트
  • 블로그
  • 테스트용 서버
  • 빠르게 시작하고 싶은 소규모 프로젝트

즉, EC2가 자유도는 높지만 복잡도가 있는 반면, Lightsail은 더 쉽게 시작할 수 있도록 추상화를 높인 느낌이다.

EC2 vs Lambda vs Lightsail을 한 번에 비교하면

EC2

  • 가상 서버
  • 제어권 높음
  • 장시간 실행 가능
  • 운영 책임 큼

Lambda

  • 서버리스
  • 코드 중심
  • 이벤트 기반
  • 짧은 실행 작업에 적합

Lightsail

  • 단순한 VPS 스타일
  • 예측 가능한 비용
  • 초보자에게 진입 장벽이 낮음

시험 문제에서는 보통 다음처럼 연결하면 풀기 쉽다.

  • 서버를 세밀하게 직접 제어해야 함 → EC2
  • 서버 관리 없이 코드 실행 → Lambda
  • 간단하고 저렴하게 빨리 시작하고 싶음 → Lightsail

그 외 자료에 등장한 서비스들

HTML 자료에는 EC2, Lambda, Lightsail 외에도 Fargate, Batch 같은 서비스가 같이 등장했다.

Cloud Practitioner에서 아주 깊게 파지 않아도, 큰 그림 정도는 알아두면 정리에 도움이 된다.

Fargate

컨테이너를 위한 서버리스 실행 환경에 가깝다.

즉:

  • ECS와 함께
  • 서버를 직접 관리하지 않고
  • 컨테이너를 실행하고 싶을 때

자주 연결된다.

AWS Batch

대량의 배치 작업을 실행하기 위한 서비스다.

즉, 짧은 요청-응답보다는:

  • 대규모 일괄 처리
  • 계산 잡
  • 반복적인 대량 작업

에 더 적합하다.

이 서비스들은 3회차 핵심 발표 범위의 중심은 아니지만, “AWS 컴퓨팅 선택지가 단순히 EC2 하나만 있는 것은 아니다”라는 감각을 만드는 데 도움이 된다.

이번 회차에서 남겨둘 포인트

이번 회차를 하면서 가장 크게 느낀 건, AWS에서 컴퓨팅 서비스는 단순히 기능 비교가 아니라 운영 책임의 분배 방식을 고르는 일이라는 점이었다.

예를 들어:

  • EC2는 자유도가 큰 대신 내가 신경 써야 할 것도 많다
  • Lambda는 관리 부담이 적지만 실행 방식이 제한적이다
  • Lightsail은 간단하지만 복잡한 요구에는 한계가 있을 수 있다

즉, “어떤 서비스가 더 좋은가”보다 “지금 상황에 어떤 서비스가 맞는가”를 묻는 게 더 정확하다.

Cloud Practitioner 시험도 결국 이 관점에 가깝다. 서비스 기능을 모두 외우는 것보다, 요구사항을 보고 적절한 방향을 고르는 문제들이 많기 때문이다.

시험 전에 다시 볼 포인트

짧게 정리하면:

  • EC2는 제어권이 높은 가상 서버다.
  • 인스턴스 타입은 워크로드 특성에 맞춰 CPU, 메모리, 스토리지 중심으로 선택한다.
  • Security Group은 EC2에 붙는 가상 방화벽이다.
  • Auto Scaling은 수요에 따라 인스턴스를 늘리고 줄이며, 비정상 인스턴스를 교체할 수 있다.
  • Lambda는 서버리스 코드 실행, Lightsail은 단순한 VPS 스타일 서비스다.

이번 회차는 Cloud Practitioner 전체에서도 체감상 중요한 분기점이었다. 여기서부터는 서비스 이름이 본격적으로 나오지만, 동시에 “서비스를 어떻게 선택할 것인가”라는 판단 문제가 함께 등장하기 시작했기 때문이다.

자료 다운로드

reference 폴더 기준으로 3회차와 직접 연결되는 자료 파일은 아래 3개였다. 복습용으로 바로 내려받을 수 있게 정적 경로로 옮겨두었다.

다음 글에서는 1월 15일 4회차 주제였던 Storage 핵심, 즉 S3, EBS, Instance Store, EFS를 정리할 예정이다.

#aws#clf-c02#cloud-practitioner#ec2#auto-scaling#security-group#lambda#lightsail#study#certification

Community

Comments

0 comments

Comments appear immediately. Use report if something needs review.

Max 40 chars for name, 500 chars for comment.

No comments yet.