EC2는 "클라우드에 있는 서버"가 아니다 — 온프레미스 서버와 EC2의 진짜 차이

들어가며

 

EC2(Elastic Compute Cloud)를 처음 접하면 대개 이렇게 이해한다.

"온프레미스에 있던 서버를 AWS 데이터센터에 옮겨놓은 것. 인터넷만 되면 어디서든 접속할 수 있는 컴퓨터."

 

틀린 말은 아니다. 실제로 EC2는 AWS 서비스 중 가장 온프레미스 서버와 닮았고, 기존 애플리케이션을 코드 수정 없이 옮길 수 있는 출발점이다. 그러나 이 이해에 머물면 EC2를 온프레미스 서버처럼 운영하게 되고, 그 순간 클라우드의 장점 대부분을 놓친다.

이 글은 EC2가 온프레미스 서버와 무엇이 같고 무엇이 다른지, 그리고 그 차이가 서버를 다루는 방식을 어떻게 바꾸는지를 정리한다.

 

1. 온프레미스에서 서버 한 대는 어떤 존재였나

온프레미스에서 서버를 하나 추가하는 과정을 떠올려 보자. 사양을 정하고 견적을 받고 결재를 올린다. 발주 후 배송을 기다리고, 도착하면 IDC에 반입해 랙에 장착하고, 전원과 네트워크를 연결하고, OS를 설치한다. 빠르면 2주, 보통은 한 달 이상이다. 비용은 수백만 원에서 수천만 원이고, 한 번 사면 3~5년을 쓴다.

이 조건에서 서버는 자연스럽게 아끼는 자산이 된다. 고장 나면 고친다. 성능이 부족할 것 같으면 미리 넉넉하게 산다. 3년 뒤 트래픽까지 예상해서 구매하는 '용량 계획'이라는 업무가 존재한다. 서버마다 이름을 붙이고, 설정을 문서로 남기고, 담당자가 접속해서 관리한다.

 

2. EC2가 없앤 것 : 시간

EC2가 바꾼 것은 본질적으로 하나다. 서버를 만드는 데 걸리는 시간이다.

콘솔에서 몇 번 클릭하거나 CLI 명령 한 줄이면 약 90초 뒤에 서버가 켜져 있다. 필요 없으면 지우고, 과금은 분 단위로 끝난다.

aws ec2 run-instances \
  --image-id ami-0c9c942bd7bf113a2 \
  --instance-type t3.micro \
  --key-name my-key \
  --security-group-ids sg-0123456789abcdef0 \
  --subnet-id subnet-0123456789abcdef0

시간이 몇 주에서 몇 분으로 줄면 단순히 빨라지는 것이 아니라 행동이 달라진다.

온프레미스 (몇 주, 수백만 원) EC2 (90초, 시간당 수십 원)

아껴 쓴다	실험 삼아 띄워보고 아니면 지운다
고장 나면 고친다	고장 나면 버리고 새로 띄운다
미리 넉넉하게 산다 (예측)	필요할 때 늘린다 (반응)
설정을 문서로 남긴다	설정을 코드로 남긴다
서버에 이름을 붙이고 애지중지한다	서버는 번호표를 단 소모품이다

클라우드 업계에서는 이를 애완동물(Pets) 대 가축(Cattle) 비유로 부른다. 온프레미스 서버는 이름 붙여 키우는 애완동물이고, EC2 인스턴스는 번호표를 단 가축이다. 아프면 치료하는 것이 아니라 교체한다. EC2를 이해하는 데 이 사고방식 전환보다 중요한 것은 없다.

 

3. EC2는 컴퓨터 한 대가 아니라 부품 묶음이다

두 번째 차이는 구조에 있다. 온프레미스 서버는 CPU, 디스크, 네트워크 카드, IP 주소가 한 상자에 붙어 있다. 디스크를 다른 서버로 옮기려면 물리적으로 뽑아야 하고, IP를 옮기려면 네트워크 팀이 설정을 바꿔야 한다.

EC2는 이것을 전부 분해해 놓았다.

부품 EC2에서의 이름 분리되어 있어서 가능한 일

컴퓨팅 (CPU·메모리)	인스턴스	중지 후 타입만 바꿔서 더 큰 사양으로 재시작
디스크	EBS 볼륨	인스턴스가 죽어도 디스크는 살아남음, 다른 인스턴스에 연결
네트워크 카드	ENI	인스턴스 간 이동 가능, 여러 개 연결 가능
고정 IP	Elastic IP	인스턴스를 교체해도 IP 유지
OS 이미지	AMI	설정 완료된 서버를 찍어서 복제
권한	IAM 역할	서버에 비밀번호 없이 다른 AWS 서비스 접근

이 분해 덕분에 "인스턴스가 죽었다"와 "데이터를 잃었다"가 다른 사건이 된다. 인스턴스는 언제든 버릴 수 있는 것이 되고, 살아남아야 하는 것은 EBS·S3·RDS 같은 서버 밖으로 빼놓게 된다.

 

4. AWS는 인스턴스가 계속 살아 있을 것을 약속하지 않는다

세 번째 차이는 장애를 대하는 전제다. 온프레미스에서 서버가 갑자기 죽으면 사고다. 원인을 찾고, 하드웨어를 교체하고, 재발 방지 보고서를 쓴다.

EC2에서는 인스턴스가 하드웨어 문제로 예고 후 재시작되거나 회수(retire)될 수 있고, 이것은 장애가 아니라 정상 운영이다. AWS는 "이 인스턴스 한 대가 계속 살아 있을 것"을 약속하지 않는다. 대신 "언제든 새 인스턴스를 만들 수 있음"을 약속한다.

따라서 EC2 위의 설계 원칙은 이렇게 된다. 인스턴스는 두 대 이상 띄운다. 상태(세션, 업로드 파일, DB)는 인스턴스 밖에 둔다. 한 대가 죽으면 고치지 말고 AMI에서 새로 띄운다. 이 원칙이 자동화된 것이 Auto Scaling이고, 그 앞에 붙는 것이 로드밸런서다.

 

5. 그래도 여전히 서버다: 가상화와 책임 범위

네 번째는 "다르지 않은 점"이다. EC2는 관리형 서비스가 아니다. OS 설치까지는 AWS가 해주지만, 그 위의 패치·보안 설정·백업·모니터링은 온프레미스와 똑같이 내 책임이다(공동 책임 모델). RDS나 Lambda처럼 AWS가 OS까지 관리해 주는 서비스와 EC2의 결정적 차이가 여기에 있다.

그리고 EC2는 물리 서버가 아니라 가상화된 공유 자원이다. vCPU 하나는 물리 코어 하나가 아니라 하이퍼스레드 하나다. t 패밀리(t2, t3)는 CPU 크레딧을 모았다가 쓰는 버스트 구조라, 온프레미스에서 "CPU 100%"와 t3.micro에서 "CPU 100%"는 의미가 다르다. 후자는 크레딧이 소진되면 성능이 기준선 아래로 떨어진다.

 

6. 손으로 확인하기: 고치지 않고 교체하기

이 글의 핵심인 "서버는 교체하는 것"을 15분 안에 체감할 수 있는 실습이다.

1. t3.micro 인스턴스를 만들고 nginx를 설치한다.
2. 그 인스턴스로 AMI를 생성한다.
3. AMI에서 새 인스턴스를 띄운다. 접속하지 않아도 nginx가 이미 떠 있다.
4. 원래 인스턴스를 종료(Terminate)한다.

# 2. 실행 중인 인스턴스로 AMI 만들기
aws ec2 create-image --instance-id i-0123456789abcdef0 --name "nginx-base-v1"

# 3. 그 AMI로 새 인스턴스 띄우기
aws ec2 run-instances --image-id ami-xxxxxxxx --instance-type t3.micro ...

# 4. 원래 인스턴스 종료
aws ec2 terminate-instances --instance-ids i-0123456789abcdef0

온프레미스에서 이 작업은 "서버 복제"라는 이름의 프로젝트다. EC2에서는 5분이다. 이것이 "서버를 고치지 않는다"가 가능한 이유다.

 

마치며

EC2를 "클라우드에 있는 서버"로 이해하면, 온프레미스에서 하던 대로 한 대를 정성껏 키우게 된다. 그러면 EC2는 그냥 비싼 호스팅이 된다.

EC2가 실제로 바꾼 것은 서버를 만드는 시간이고, 그 시간이 사라지자 서버를 대하는 태도가 아끼기에서 버리기로 바뀌었다. 부품을 분해해 놓은 구조, 인스턴스의 수명을 보장하지 않는 전제, 이미지에서 찍어내는 방식은 전부 그 태도를 전제로 설계되어 있다.

EC2를 쓰면서 여전히 서버에 이름을 붙이고, SSH로 들어가 손으로 고치고, 한 대가 죽으면 밤새 복구하고 있다면, 클라우드에 있을 뿐 클라우드를 쓰고 있지는 않은 것이다.

---

참고 자료

• Amazon EC2 — 공식 문서
• EC2 인스턴스 수명 주기 — 공식 문서
• 버스트 가능 성능 인스턴스(t 패밀리) — 공식 문서
• AWS 공동 책임 모델