AWS 인프라 설계 실습 정리: 멀티 AZ·로드 밸런서·오토스케일링을 하나의 그림으로 이해하는 학습 관점 전환

AWS 인프라 실습을 어느 정도 진행하다 보면 어느 순간 이런 감각이 찾아온다. “명령어는 따라쳤는데, 이게 왜 이렇게 설계된 건지 한 문장으로 설명하기 어렵다”는 느낌이다. 바로 이 지점이 클라우드 학습에서 가장 중요한 분기점이다. 단순히 리소스를 만드는 단계에서 벗어나, 시스템 전체를 하나의 구조로 이해하고 설명할 수 있느냐가 학습의 깊이를 가른다. 이 글은 오늘 진행한 AWS 인프라 실습을 단순한 과정 나열이 아니라, ‘왜 이런 구조가 표준이 되는지’를 중심으로 다시 정리한 기록이다. 클라우드를 배우는 사람들에게 실습을 더 효과적인 학습 자산으로 바꾸는 관점을 공유하고자 한다.

 

서론: AWS 실습은 언제 비로소 ‘이해’가 되는가

AWS를 처음 배울 때는 EC2 생성, 서브넷 설정, 로드 밸런서 연결 같은 개별 작업에 집중하게 된다. 하지만 실무에서 요구되는 역량은 각 서비스의 사용법이 아니라, “왜 이런 배치를 선택했는가”를 설명하는 능력이다. 오늘 실습에서 다룬 멀티 AZ 구조, 퍼블릭·프라이빗 서브넷 분리, 로드 밸런서와 오토 스케일링, NAT 게이트웨이까지 이어지는 설계는 AWS 인프라 설계의 핵심 원칙이 한 번에 담긴 구조다. 이 글에서는 그 구조를 학습자 관점에서 다시 해석하며, 실습을 통해 무엇을 머릿속에 고정해야 하는지를 정리한다.

 

1단계: 전체 아키텍처를 한 장의 그림으로 묶기

클라우드 실습에서 가장 먼저 해야 할 일은 전체 구조를 하나의 흐름으로 묶는 것이다. 오늘 실습의 핵심 흐름은 비교적 명확하다. 외부 트래픽은 퍼블릭 서브넷에 위치한 로드 밸런서를 통해 들어오고, 실제 요청 처리는 프라이빗 서브넷에 위치한 EC2 인스턴스들이 담당한다. 이 인스턴스들은 오토 스케일링 그룹에 속해 트래픽에 따라 자동으로 늘어나거나 줄어든다. 데이터는 가용 영역별로 분산된 데이터베이스에 저장되며, 프라이빗 자원은 인터넷과 직접 통신하지 않고 NAT 게이트웨이를 통해서만 외부로 나간다. 이 한 문장을 자연스럽게 말할 수 있다면, 실습의 절반은 이미 자기 것이 된다.

2단계: 구성 요소를 ‘기능’이 아니라 ‘역할’로 이해하기

VPC와 가용 영역(AZ)은 단순한 네트워크 설정이 아니라, 장애를 전제로 한 설계의 출발점이다. 하나의 AZ가 문제가 생겨도 서비스가 멈추지 않게 만드는 것이 목적이다. 그래서 각 AZ마다 퍼블릭 서브넷과 프라이빗 서브넷을 나누는 구조가 기본이 된다. 퍼블릭 서브넷은 외부와 연결되는 입구이자 출구 역할을 담당하고, 프라이빗 서브넷은 실제 서비스가 동작하는 내부 공간이 된다. 이 구분을 이해하지 못하면 보안과 확장성의 개념도 함께 흐려진다.

퍼블릭 서브넷의 핵심 역할은 두 가지다. 하나는 로드 밸런서를 통해 외부 요청을 받아 내부로 분산시키는 것이고, 다른 하나는 NAT 게이트웨이를 통해 프라이빗 자원이 외부로 나갈 수 있는 통로를 제공하는 것이다. 반대로 프라이빗 서브넷에 위치한 EC2와 데이터베이스는 외부에 직접 노출되지 않는다. 실제로 일을 하는 자원은 항상 프라이빗 영역에 둔다는 원칙이 여기서 자연스럽게 드러난다.

 

3단계: Auto Scaling을 ‘서버 관리’가 아닌 ‘시스템 사고’로 보기

오토 스케일링 그룹은 단순히 EC2를 자동으로 늘리고 줄이는 기능이 아니다. 이 기능의 핵심은 “서버를 직접 관리하지 않아도 되는 상태”를 만드는 데 있다. 트래픽이 증가하면 인스턴스가 자동으로 추가되고, 트래픽이 줄면 자동으로 제거된다. 기준은 CPU 사용률이나 요청 수처럼 시스템 상태를 반영하는 지표다. 이 구조를 이해하면 클라우드 운영의 관점이 바뀐다. 더 이상 서버 수를 계산하는 사람이 아니라, 정책과 기준을 설계하는 사람이 되는 것이다.

 

4단계: 데이터베이스 배치에서 배운 가용성의 개념

실습에서는 각 가용 영역에 데이터베이스를 배치하고, 스냅샷을 통해 동일한 상태를 유지하는 구조를 경험했다. 이는 실무에서 흔히 사용하는 다중 AZ 구성이나 읽기 전용 복제 구조의 개념을 이해하기 위한 단계다. 중요한 점은 데이터베이스 역시 단일 장애 지점이 되지 않도록 설계해야 한다는 사고방식이다. 오늘 실습은 간소화된 형태였지만, 실제 운영 환경에서는 이를 기반으로 더 진화한 구조로 확장된다.

 

5단계: 실습 과정을 ‘절차’가 아니라 ‘이유’로 기억하기

VPC를 만들고, 서브넷을 나누고, 인터넷 게이트웨이와 NAT 게이트웨이를 연결하는 과정은 단순히 따라야 할 절차가 아니다. 각각은 명확한 이유를 가지고 있다. 퍼블릭 라우트 테이블은 외부와 직접 연결되기 위해 존재하고, 프라이빗 라우트 테이블은 내부 자원이 안전하게 외부로 나가기 위해 NAT를 참조한다. AMI를 만드는 이유는 오토 스케일링에서 동일한 서버를 반복적으로 생성하기 위함이고, 런치 템플릿은 이 과정을 자동화하기 위한 기준점이다. 이런 이유들이 머릿속에서 하나의 이야기로 연결될 때 실습은 비로소 이해의 영역으로 들어간다.

 

결론: AWS 실습의 진짜 성과는 ‘확장되는 사고방식’이다

이번 AWS 인프라 실습은 단순히 서버를 만든 경험이 아니다. 확장성과 가용성을 전제로 시스템을 설계하는 사고방식을 체득하는 과정에 가깝다. 이 구조를 말로 설명할 수 있다면, 클라우드 엔지니어 면접에서도, 기술적인 설득이 필요한 자리에서도 충분히 활용할 수 있다. 클라우드 학습에서 가장 중요한 것은 더 많은 서비스를 외우는 것이 아니라, 하나의 표준 구조를 깊이 이해하는 것이다. 오늘 실습을 이렇게 정리해두는 것 자체가, 학습이 다음 단계로 넘어갔다는 가장 분명한 증거다.