AWS 배우면서 Azure 시작한 멀티클라우드 입문자의 현실 기록

 

솔직히 말하면 수업 첫날 "멀티클라우드 엔지니어"라는 말 들었을 때 그냥 클라우드 여러 개 쓸 줄 알면 되는 거 아닌가 싶었다. 근데 AWS VPC 설계 실습 한 번 해보고 나서 생각이 바뀌었다. 클라우드 하나도 구조를 이해하는 데 이렇게 시간이 걸리는데, 이걸 여러 개를 동시에 다룬다는 게 어떤 의미인지 조금씩 감이 오기 시작했다.

현재 상황을 정리하면 이렇다. AWS 기본 설계는 실습까지 마쳤고, 이번 주부터 Azure를 배우기 시작한다. GCP는 개념 수준으로만 알고 있다. 이 글은 그 과정에서 직접 겪은 것들, 강사님한테 들은 현업 이야기, 그리고 Azure와 GCP를 비교 조사하면서 이해한 것들을 섞어서 쓴 기록이다.

---

AWS 실습에서 처음으로 막혔던 순간

VPC 설계 실습에서 퍼블릭 서브넷이랑 프라이빗 서브넷을 나누고, EC2 인스턴스에 웹 서버를 올리는 과제였다. 이론으로는 이해했는데 실제로 하니까 바로 막혔다.

인스턴스 만들고 퍼블릭 IP 붙였는데 브라우저에서 접속이 안 됐다. 오류 메시지도 없이 그냥 타임아웃. 한참 들여다봤는데 원인은 Security Group 인바운드 규칙에 HTTP(80포트)를 빠뜨린 거였다.

근데 더 웃긴 건, 80포트 열고 나서도 안 됐다. 이번엔 다른 문제였다.

ssh: connect to host [EC2 PUBLIC IP] port 22: Connection timed out

이건 인터넷 게이트웨이가 VPC에 붙어있긴 한데 라우팅 테이블에 경로를 안 잡아준 거였다. 0.0.0.0/0 → igw-xxxxxxxx 이 한 줄이 없으면 퍼블릭 서브넷이라도 외부 통신이 안 된다.

이게 이론이랑 실습의 차이다. "인터넷 게이트웨이를 붙이면 외부 통신이 된다"는 말 자체는 맞는데, 라우팅 테이블에 명시적으로 경로를 넣어야 한다는 게 실습 전에는 머릿속에 안 들어왔다.

---

AWS로 이해한 구조, Azure에서는 어디에 해당할까

이번 주 Azure 수업 시작하기 전에 미리 조사를 좀 해봤다. AWS에서 배운 개념들이 Azure에서는 어떤 이름으로 존재하는지 매핑해보는 식으로.

네트워크 구조 비교:

AWS Azure 역할

VPC	Virtual Network (VNet)	격리된 네트워크 공간
Subnet	Subnet	서브넷 (거의 동일)
Security Group	Network Security Group (NSG)	인스턴스/서브넷 레벨 방화벽
Internet Gateway	별도 리소스 없음 (기본 제공)	인터넷 연결
Route Table	Route Table	라우팅 경로
VPC Peering	VNet Peering	VNet 간 연결

조사하면서 흥미로웠던 차이가 있다. AWS는 Security Group을 인스턴스 단위로 붙이는데, Azure의 NSG는 서브넷 단위로도 붙이고 NIC(네트워크 인터페이스) 단위로도 붙일 수 있다. 즉 같은 서브넷 안에서도 VM별로 다른 규칙을 적용할 수 있는 구조다.

강사님이 수업 중에 이런 말씀을 하셨다.

"AWS에서 Security Group 설계를 대충 배우고 넘어가면 Azure NSG에서 헷갈린다. 이름은 다른데 하는 일은 비슷하거든. 근데 세부 동작이 다른 부분이 있어서, 하나를 제대로 이해해야 다른 거 배울 때 비교가 된다."

지금 생각하면 AWS 실습에서 Security Group 규칙 하나 빠뜨려서 연결 안 됐던 그 경험이 오히려 NSG 이해할 때 도움이 될 것 같다.

---

GCP는 어떻게 다른가 — 조사 기반 비교

GCP는 아직 실습을 안 해봤으니 조사한 내용 기반으로 쓴다.

GCP의 네트워크 구조에서 가장 독특한 점은 VPC가 글로벌 리소스라는 거다. AWS와 Azure는 VPC/VNet이 특정 리전에 종속된다. 서울 리전 VPC, 도쿄 리전 VPC 이런 식으로 따로 만들어야 한다.

GCP는 하나의 VPC 안에 여러 리전의 서브넷을 넣을 수 있다.

GCP VPC 구조 예시:
└── my-global-vpc (글로벌)
    ├── subnet-asia-northeast3 (서울, 10.10.0.0/24)
    ├── subnet-us-central1 (미국, 10.20.0.0/24)
    └── subnet-europe-west1 (유럽, 10.30.0.0/24)

AWS였으면 리전마다 VPC를 따로 만들고 피어링이나 Transit Gateway로 연결해야 할 구조다. GCP는 처음부터 글로벌 단위로 설계가 된다.

강사님이 이 차이에 대해 이런 말씀을 하셨다.

"GCP 처음 배울 때 AWS 식으로 생각하면 VPC 설계에서 막힌다. 멀티클라우드 하다 보면 이런 순간이 계속 온다. 각 클라우드가 왜 이런 구조를 택했는지를 이해해야 전환이 빠르다. 그냥 버튼 위치 외워봤자 소용없다."

---

실습하면서 내가 결정해야 했던 것들

과제 중에 서브넷을 퍼블릭이랑 프라이빗으로 나누는 실습이 있었다. 강사님이 기준을 딱 정해주지 않으셨다. "어떤 걸 프라이빗에 넣을지 생각해보고 설계해봐라"고 하셨다.

내가 내린 판단:

• 퍼블릭 서브넷: ALB(로드밸런서), NAT Gateway
• 프라이빗 서브넷: EC2 웹서버, RDS

처음엔 EC2도 퍼블릭에 넣으려 했다. 어차피 웹서버면 외부에서 접속해야 하니까. 근데 강사님 설명 듣고 생각이 바뀌었다.

"EC2를 퍼블릭에 두면 서버 IP가 직접 외부에 노출된다. ALB가 앞에서 받고 EC2는 뒤에 숨겨두는 게 맞다. 실제 서비스에서 EC2 IP가 직접 노출되면 공격 표면이 너무 커진다."

이걸 듣고 구조를 바꿨다. 그리고 프라이빗 서브넷에 있는 EC2가 외부 인터넷에서 패키지를 설치할 수 있으려면 NAT Gateway가 필요하다는 것도 그때 처음 제대로 이해했다.

CIDR 설계도 처음엔 대충 잡았다가 나중에 고생할 뻔 했다.

• VPC CIDR: 10.0.0.0/16
• 퍼블릭 서브넷: 10.0.1.0/24
• 프라이빗 서브넷: 10.0.2.0/24

강사님이 지나가다 보시더니 "나중에 멀티클라우드 연결할 때 저 대역 충돌 난다. 지금부터 습관 들여놔라"고 하셨다. 다른 클라우드랑 연결할 걸 고려하면 처음부터 10.10.0.0/16, 10.20.0.0/16 같이 대역을 분리해서 잡아야 한다는 거였다. 지금은 혼자 실습이니까 문제없지만, 나중에 Azure VNet이나 GCP VPC랑 연결하는 순간 대역이 겹치면 처음부터 다시 해야 한다.

---

강사님한테 들은 현업 이야기 — 이게 제일 도움됐다

수업 쉬는 시간에 현업에서 어떤 상황이 가장 힘들었냐고 여쭤봤다. 두 가지 얘기를 해주셨다.

첫 번째, AWS와 Azure를 같이 쓰는 환경에서 IAM 정책이 꼬인 사례다.

"AWS에서는 역할(Role) 기반으로 권한을 주는데, Azure도 RBAC이라고 비슷한 구조가 있다. 문제는 개념은 같아 보이는데 세부 동작이 달라서, AWS 방식으로 Azure 권한 설계를 하면 생각지도 못한 구멍이 생긴다. 내가 겪은 건 Azure에서 특정 리소스 그룹에만 권한을 줬다고 생각했는데, 상위 구독 레벨에서 상속된 권한이 있어서 실제로는 더 넓은 범위에 접근이 됐던 거다. AWS는 기본이 Deny고 명시적으로 Allow를 줘야 하는데, Azure는 상속 구조를 이해 못 하면 의도치 않은 권한이 생긴다."

두 번째, 모니터링 이야기다.

"AWS CloudWatch, Azure Monitor, GCP Cloud Monitoring 각각 따로 보다가 장애 나면 어느 구간이 문제인지 파악이 너무 느리다. 내가 처음 멀티클라우드 환경 맡았을 때 장애 원인 찾는 데 한 시간 넘게 걸렸다. 나중에야 Grafana 같은 걸로 한 곳에서 보는 구조를 만들었다. 처음부터 모니터링 통합을 염두에 두고 설계했어야 했는데, 그게 없으니까 운영이 너무 힘들었다."

아직 실습 단계인 나한테도 와닿는 이야기였다. 지금 AWS 콘솔 하나 보는 것도 어색한데, 이게 세 개가 되면 어떤 상황일지.

---

지금 내 수준에서 멀티클라우드가 의미하는 것

솔직히 아직 멀티클라우드 엔지니어가 무엇인지 완전히 그려지지는 않는다. AWS 실습을 하면서 겨우 VPC 구조가 손에 익기 시작했고, 이번 주부터 Azure를 배우면 또 새로운 용어와 콘솔에 적응해야 한다.

근데 지금까지 배우면서 한 가지는 명확해졌다. 클라우드를 "버튼 위치 외우는 것"으로 접근하면 안 된다는 거다. AWS Security Group 규칙 하나 빠뜨려서 연결 안 됐을 때, 단순히 규칙 추가하는 법을 배운 게 아니라 "인바운드/아웃바운드 트래픽이 어떻게 제어되는가"를 이해하게 됐다.

강사님이 수업 마지막에 하신 말씀이 계속 생각난다.

"AWS 배울 때 왜 이렇게 설계됐는지를 이해해놓으면, Azure 배울 때 '아, 여기서는 이 개념을 이렇게 구현했구나' 하고 비교가 된다. 클라우드는 다 비슷한 문제를 다른 방식으로 푼 거다. 하나를 깊게 이해하면 나머지는 비교하면서 배울 수 있다."

이번 주 Azure 배우면서 그 말이 맞는지 직접 확인해볼 생각이다. 막히는 부분이 생기면 또 기록으로 남길 예정이다.