1. 들어가며 🎯

새로운 프로젝트를 기획하며, 개발에서 무엇을 가장 먼저 고민해야 하는지 다시 돌아보게 되었습니다.

한때는 프론트엔드가 모든 설계의 출발점이라고 믿었습니다. 유저가 무엇을 보고, 어떤 흐름에서 머무르고 이탈하는지에 대한 이해 없이 서비스를 만든다는 건 불가능하다고 생각했기 때문입니다. 실제로 화면 위에서 벌어지는 모든 상호작용은 유저 경험의 핵심이고, 그 경험이 곧 서비스의 얼굴이니까요.

하지만 백엔드 로직을 다루기 시작하면서 생각은 한 번 바뀌었습니다. 아무리 정교한 화면이라도, 그 뒤에서 이를 받쳐주는 API 구조가 허술하다면 결국 서비스는 한계에 부딪힐 수밖에 없다는 사실을 체감했기 때문입니다.

그런데 지금, 시선은 더 아래로 내려왔습니다. 이제는 인프라만큼 중요한 초석은 없다는 결론에 도달했습니다. 돌이켜보면 그동안 저는 평탄화되지 않은 땅 위에 위태롭게 건물을 세워두고, 무너지지 않기만을 바라는 곡예를 반복해왔던 것 같습니다.

2. AWS 글로벌 인프라 🎯

2-1. AWS 리전 ✍️

AWS 콘솔에 접속하면 가장 먼저 눈에 들어오는 것이 바로 리전입니다. 2026년 2월 기준, AWS는 전 세계에 34개의 리전을 운영하고 있으며, 이 리전들은 단순한 논리적 구분이 아니라 물리적으로 완전히 분리된 인프라 단위입니다.

서울 리전에서 장애가 발생하더라도 도쿄나 오하이오, 프랑크푸르트 리전에는 아무런 영향이 가지 않습니다. 즉, 리전을 선택한다는 것은 단순히 “어디에서 서비스를 돌릴까”를 정하는 것이 아니라, 내 서비스가 물리적으로 어디에 발을 딛고 서 있을지를 결정하는 행위에 가깝습니다.

AWS 리전은 다시 여러 개의 가용 영역으로 구성됩니다. 데이터 센터들이 모여 가용 영역을 이루고, 이 가용 영역들의 집합이 하나의 리전을 구성합니다. 2026년 2월 기준으로 서울 리전은 네 개의 가용 영역을 가지고 있으며, 이 부분이 사실 고가용성 설계의 출발점이 됩니다.

2-2. 가용 영역 ✍️

가용 영역을 조금 더 들여다보면, 결국 하나 이상의 데이터 센터로 구성된 독립된 공간이라는 사실을 알 수 있습니다. 중요한 점은 이 가용 영역들이 단순히 논리적으로만 분리된 것이 아니라, 전력이나 네트워크, 물리적 인프라 측면에서도 서로 영향을 최소화하도록 설계되어 있다는 점입니다.

이 덕분에 하나의 가용 영역이 통째로 장애를 겪더라도, 다른 가용 영역에서 서비스는 계속 동작할 수 있습니다. AWS가 말하는 고가용성은 여기서부터 시작됩니다.

2-3. 글로벌 인프라와 VPC의 관계 ✍️

리전과 가용 영역을 먼저 살펴본 이유는, AWS가 제공하는 서비스들이 이 경계를 기준으로 서로 다른 성격을 갖기 때문입니다.

어떤 서비스는 특정 지역에 묶이지 않고 글로벌하게 동작하고, 어떤 서비스는 리전 단위로, 또 어떤 서비스는 가용 영역 단위로 동작합니다. 예를 들어 S3나 DynamoDB는 하나의 리전 안에서 여러 가용 영역에 자동으로 분산되어 제공되는 반면, EC2나 RDS는 내가 어느 가용 영역에 배치할지를 직접 선택해야 합니다.

이 차이를 이해하지 못하면, 왜 어떤 서비스는 위치를 신경 쓰지 않아도 되고, 어떤 서비스는 가용 영역을 고르라고 하는지 계속해서 헷갈리게 됩니다.

~~제가 그래왔고, 이제서야 알았습니다. 굳이 실수를 똑같이 따라할 필요는 없겠죠?~~

VPC는 바로 이 리전이라는 틀 안에서 만들어지는, 나만의 네트워크 공간입니다.

3. VPC 기본 구성요소 🎯

3-1. VPC란? ✍️

VPC는 Virtual Private Cloud의 약자로, AWS 클라우드 안에 내가 직접 설계하고 통제할 수 있는 가상 네트워크를 의미합니다. 쉽게 말해, 광활한 AWS 클라우드라는 대륙 위에 내가 소유한 울타리 쳐진 땅 하나를 마련하는 것과 같습니다.

모든 EC2, RDS, 로드밸런서 같은 리소스들은 이 VPC라는 땅 위에 올라가게 되고, 이 땅의 구조가 어떻게 설계되느냐에 따라 서비스의 안정성과 확장성이 결정됩니다.

3-2. IP 범위 설정 ✍️

VPC를 생성할 때 가장 먼저 해야 할 일은, 이 땅 안에서 사용할 주소 체계를 정하는 것입니다. 즉 CIDR 블록을 설정하는 단계입니다. 보통은 10.0.0.0/16과 같은 사설 IP 대역을 사용합니다.

단순히 숫자를 하나 고르는 일이 아닙니다. 한 번 정해진 CIDR 범위는 나중에 변경하기가 매우 까다롭고, 이후 서브넷 분할이나 서비스 확장에도 직접적인 영향을 미칩니다. 그래서 이 단계에서는 “일단 만들어두고 나중에 생각하자”라는 접근이 가장 위험합니다.

3-3. 고가용성을 위한 가용영역 설정 ✍️

서울 리전에 네 개의 가용 영역이 존재한다고 해서, 모든 리소스를 하나의 가용 영역에 몰아두는 것은 아무 의미가 없습니다. 인프라 설계에서 고가용성을 고려한다는 것은, 최소 두 개 이상의 가용 영역에 리소스를 분산 배치한다는 뜻입니다.

만약 하나의 가용 영역이 천재지변이나 대규모 장애로 인해 사용할 수 없는 상황이 오더라도, 내 서비스는 다른 가용 영역에서 계속 동작해야 합니다. 선택의 문제가 아닌 인프라 설계의 기본 전제입니다.

3-4. 인터넷 게이트웨이 ✍️

VPC는 기본적으로 외부와 완전히 단절된 공간입니다. 이 상태에서는 아무리 서버를 띄워도 외부 인터넷과 통신할 수 없습니다. 이때 외부 세계로 나가기 위한 항구 역할을 하는 것이 바로 인터넷 게이트웨이입니다.

인터넷 게이트웨이를 VPC에 연결하고, 이를 향한 경로를 명시해 주어야 비로소 인터넷과의 통신이 가능해집니다. 단순히 생성만 해서는 아무 일도 일어나지 않는다는 점이 포인트입니다.

3-5. 네트워크 서브넷 ✍️

VPC라는 광활한 땅을 하나로 통째로 사용하는 것은 관리 측면에서 현실적이지 않습니다. 그래서 우리는 성격에 따라 이 땅을 여러 구역, 즉 서브넷으로 나누게 됩니다.

외부와 직접 통신해야 하는 리소스가 위치하는 퍼블릭 서브넷이 있고, 외부에 노출될 필요가 없는 내부 자원들이 위치하는 프라이빗 서브넷이 있습니다. 이 구분은 보안과 직결되며, 이후 인프라 설계의 방향성을 결정짓는 중요한 기준이 됩니다.

3-6. 라우팅 테이블 ✍️

라우팅 테이블은 각 서브넷이 어떤 방향으로 트래픽을 흘려보낼지 결정하는 길 안내판과 같습니다. 같은 VPC 안에 있더라도, 어떤 라우팅 테이블을 연결하느냐에 따라 해당 서브넷은 인터넷으로 나갈 수도 있고, 내부 통신만 수행하도록 제한될 수도 있습니다.

퍼블릭 서브넷과 프라이빗 서브넷의 본질적인 차이 역시, 결국 이 라우팅 설정에서 갈라집니다.

여기서 한 가지 문제가 생깁니다. 프라이빗 서브넷에 있는 서버가 외부 인터넷으로부터의 접근은 차단하면서도, 패키지 업데이트나 외부 API 호출처럼 밖으로 나가는 통신은 할 수 있어야 하는 경우입니다.

이때 등장하는 것이 NAT Gateway입니다. NAT Gateway는 프라이빗 서브넷의 리소스가 인터넷으로 나갈 수 있는 일방통행 출구 역할을 합니다. 퍼블릭 서브넷에 배치되어, 프라이빗 리소스의 아웃바운드 트래픽을 자신의 공인 IP로 변환해서 내보내 주되, 외부에서 직접 들어오는 인바운드 연결은 원천 차단합니다.

3-7. Elastic IP ✍️

EC2 인스턴스는 기본적으로 재시작할 때마다 공인 IP가 변경됩니다. 하지만 운영 환경에서 서버의 주소가 계속 바뀐다면, 서비스 접근 자체가 불가능해집니다.

Elastic IP는 이런 문제를 해결하기 위해 제공되는 고정 공인 IP입니다. 한 번 할당받으면 내가 직접 반납하기 전까지는 변하지 않으며, 서버에 붙였다 떼는 것도 가능합니다. 말 그대로 내 서버에 붙여두는 고정된 집 주소라고 생각하면 가장 이해하기 쉽습니다.

4. VPC 엑세스 제어 🎯

4-1. NACL ✍️

NACL은 서브넷 단위에서 동작하는 접근 제어 장치입니다. 서브넷 입구에 서 있는 문지기처럼, 들어오고 나가는 모든 트래픽을 규칙 번호 순서대로 검사합니다.

특정 IP 대역을 아예 차단하고 싶을 때처럼, 비교적 거친 수준의 통제가 필요할 경우 NACL이 적합합니다. 이 단계에서 걸러진 트래픽은 아예 내부로 들어오지도 못합니다.

4-2. Security Group ✍️

보안 그룹은 인스턴스 단위에서 동작하는 방어선입니다. NACL이 마을 입구를 지킨다면, 보안 그룹은 개별 건물의 현관문을 지키는 역할을 합니다.

어떤 포트는 열어두고, 어떤 요청은 허용할지 세밀하게 제어할 수 있으며, 실제로 인프라를 운영하면서 가장 자주 마주치게 되는 보안 설정이기도 합니다. 인프라 보안은 이렇게 여러 겹으로 쌓일 때 비로소 의미를 가집니다.

4-3. NACL과 Security Group 비교 ✍️

NACL과 보안 그룹은 역할이 명확히 다른 도구입니다. 하나는 서브넷 단위에서 거칠게 걸러내고, 다른 하나는 인스턴스 단위에서 정교하게 통제합니다. 두 장치가 함께 동작할 때, 비로소 VPC의 보안이 완성됩니다.

5. 마치며 🎯

VPC Endpoint나 Peering, Transit Gateway처럼 이름만 들어도 머리가 얼얼해지는 주제들이 아직도 줄을 서 있습니다. 하지만 이론만 받아먹는 것은 제 스타일이 아닙니다. 아무리 남이 잘 그려놓은 설계도를 많이 봐도, 내 손에 흙이 묻지 않으면 그건 진짜 지식이 아니라고 생각합니다.

이번 글은 본격적인 설계를 시작하기 전, 땅을 고르고 지형을 파악하는 과정에 가깝습니다. 이제 기초 공사를 위한 개념 정리는 어느 정도 끝났습니다. 다음 글에서는 실제 서비스를 가정한 설계 도면을 들고 찾아뵙겠습니다.