책으로 공부하고 있는 내용에서는 VPC는 거의 언급되지 않았다. 그런데 회사 동료가 프로젝트용으로 구축한 AWS 인프라를 설명해줄때에는 VPC를 가장먼저 설명해주었고 꽤 오랜시간을 할애해서 이해시켜주었다. 그런데 왜 책에서는 크게 언급되지 않았을까? 나는 VPC를 처음 접했을때 Virtual PC의 약자로 생각했다. VPC가 네트워크라는 생각은 상상도 못했다. 

회사 동료의 설명으로는 인프라를 구축할때 제일먼저 만드는게 VPC라고 했다. 그만큼 중요하다는건데 아무래도 네트워크 개념이다보니 일반 교재에서는 크게 다루지 않고 넘어간듯 하다. 하지만 실제 운영용 인프라에서는 네트워크는 보안과 직결되기때문에 꽤나 복잡하게 그리고 촘촘하게 구성하는거 같다. 어찌되었든 초보자인 내가 이해하기에는 다소 어려움이 있지만 쉽게 풀이하자면 “가상 네트워크”라고는 하는데, 네트워크 자체가 익숙하지 않으니까 여전히 어렵게 느껴지기는 했다. 그래서 내가 이해한 VPC를 내 말로 다시 정리하고, 서브넷/라우팅/보안까지 연결되는 흐름을 적어나가 보겠다.

VPC 기본 개념: 내가 이해한 “AWS 안의 사내망(내 전용 네트워크)”

AWS 제공. VPC

VPC(Virtual Private Cloud)는 내가 이해하기로 “AWS 안에서 만드는 나만의 가상 사설 네트워크”다. 나는 처음엔 VPC를 VMWare의 가상PC정도로 그냥 설정 하나로 생각했는데, 실제로는 내 서버(EC2), DB(RDS), 로드밸런서(ALB) 같은 리소스들이 살아갈 ‘땅’이자 ‘사내망’이었다. 그래서 VPC를 한 번 제대로 잡아두면 이후 서비스들이 조금 덜 흩어져 보였다. 물리서버로 본다면 아마도 IDC에 서버를 장착하는 랙정도로 생각하면 될까? 맞는 비유인지는 모르겠지만 결국은 네트워크를 구성하는거라고 정리했다.
VPC를 만들 때 가장 먼저 하는 건 IP 대역(CIDR)을 정하는 것이다. 예를 들어 10.0.0.0/16 같은 범위를 잡는다. 이 CIDR은 “내 사내망의 주소 체계” 같은 거라서, 나중에 확장하거나 다른 네트워크와 연결할 수도 있다고 생각하면 너무 좁게 잡으면 불편할 수 있다. 물론 나는 아직 실무처럼 크게 설계하진 못하지만, 적어도 “대충 아무거나”로 잡지 않고, 겹치지 않는 사설 대역을 선택한다는 원칙은 세웠다.
그리고 내가 헷갈렸던 포인트는 “VPC가 있다고 인터넷이 되는 건 아니다”였다. VPC는 기본적으로 사설망이라서, 인터넷과 통신하려면 Internet Gateway(IGW) 같은 출입구가 필요하다. 즉, VPC는 ‘내 내부망’이고, 외부 연결은 별도의 장치와 라우팅 규칙으로 결정된다는 관점이 중요했다. 이 관점을 잡고 나니, 퍼블릭/프라이빗 서브넷이 왜 나오는지도 자연스럽게 이어졌다.

서브넷과 라우팅: public/private는 이름이 아니라 “길(라우트 테이블)”이 정한다

VPC가 큰 땅이라면, Subnet은 그 땅을 나눈 구역이다. 예를 들어 VPC가 10.0.0.0/16이면, 10.0.1.0/24, 10.0.2.0/24처럼 쪼개서 서브넷을 만든다. 보통은 고가용성을 위해 AZ(가용영역)별로 서브넷을 나눈다. 그래서 흔한 기본 구성은 Public Subnet 2개(AZ 2개) + Private Subnet 2개(AZ 2개)다.
내가 제일 크게 배운 건 “Public/Private는 이름표가 아니다”라는 점이었다. 어떤 서브넷이 퍼블릭인지 프라이빗인지는 라우트 테이블(Route Table)이 결정한다. 라우트 테이블은 “이 서브넷의 트래픽을 어디로 보낼지” 정하는 길 안내판이다.
- 10.0.0.0/16 -> local (VPC 내부 통신)
- 0.0.0.0/0 -> igw-xxxx (인터넷으로 나가기)
- 0.0.0.0/0 -> nat-xxxx (NAT 통해서만 인터넷으로 나가기)
여기서 0.0.0.0/0이 IGW로 향하면 그 서브넷은 인터넷으로 직접 나갈 수 있는 조건이 생긴다. 그래서 보통 그걸 Public Subnet이라고 부른다. 반대로 0.0.0.0/0이 NAT로 향하면, 외부에서 직접 들어오진 못하고 내부에서만 “나가기”가 가능한 구조가 되어서 Private Subnet 성격이 된다.
다만 이것도 “조건”일 뿐이라서 실제로 인터넷과 통신하려면 퍼블릭 IP(또는 EIP)와 보안그룹 설정까지 맞아야 한다. 나는 예전에 라우팅만 맞춰놓고 “왜 접속이 안 되지?”로 헤맨 적이 있는데, 그때 공인 IP가 없거나 SG가 막고 있던 경우가 많았다. 이제는 VPC 문제를 볼 때 라우팅만 보지 않고, IP와 보안까지 같이 보는 습관을 들이려고 한다.

IGW/NAT/SG/NACL: 내가 이해한 “출입구 + 외출통로 + 경비규칙”

VPC를 운영한다는 건 결국 “누가 어디로 들어오고 나가는지”를 통제하는 일이라고 느꼈다. 그래서 IGW, NAT, SG/NACL을 각각 역할로 외워두었다.
Internet Gateway(IGW)는 VPC가 인터넷과 통신할 수 있게 해주는 출입구다. Public Subnet 라우트 테이블에 0.0.0.0/0 -> IGW가 있어야 인터넷으로 나갈 수 있다. 그리고 실제로 외부에서 들어오려면 공인 IP가 붙어 있어야 하고, Security Group이 열려 있어야 한다.
NAT Gateway는 Private Subnet의 인스턴스가 “밖으로 나가기만” 가능하게 해주는 장치다. 외부에서 Private Subnet으로 직접 들어오는 건 불가능하다. 그래서 Private Subnet의 EC2가 패키지 설치, 업데이트, 외부 API 호출처럼 아웃바운드가 필요할 때 NAT를 쓴다. 보통 NAT는 Public Subnet에 두고, Private Subnet 라우트 테이블에서 0.0.0.0/0 -> NAT로 걸어준다. 나는 특히 NAT가 비용이 발생한다는 점을 크게 의식하고 있어서, 실습할 땐 켜두고 방치하지 않도록 체크리스트를 만들었다.
Security Group(SG)은 인스턴스(정확히는 ENI)에 붙는 상태 기반(Stateful) 방화벽이다. 인바운드/아웃바운드를 정의하고, 응답 트래픽은 자동으로 허용된다. 나는 SG를 “서버 단위 경비 규칙”이라고 생각한다. 예를 들어 “ALB SG → EC2 SG만 허용”, “EC2 SG → RDS SG만 허용”처럼 SG끼리 연결해서 최소 권한을 유지하는 패턴이 실무 감각에 가까워 보였다.
Network ACL(NACL)은 서브넷에 붙는 무상태(Stateless) 방화벽이다. 인바운드/아웃바운드를 각각 따로 허용해야 하고, Deny 규칙도 가능하다. 나는 아직 초보라서 SG만으로도 충분히 헷갈리기 때문에, 기본 실습에서는 NACL은 최소로 두고 SG를 확실히 하는 쪽을 목표로 하고 있다. 다만 특정 IP 대역을 서브넷 레벨에서 차단해야 할 때 NACL이 유용하다는 점은 기억해두었다.
추가로 VPC Endpoint도 같이 메모해뒀다. S3/DynamoDB 같은 AWS 서비스 접근을 NAT/인터넷 없이 VPC 내부 경로로 할 수 있게 해줘서, 보안 강화와 NAT 비용 감소에 도움이 된다. 나는 아직 깊게 써보진 못했지만, “사설 경로로 AWS 서비스를 쓰는 방법”이라는 관점으로 기억하고 있다.

내가 정리한 VPC의 핵심은 “AWS 안에 내 사내망을 만든다”는 것이다. VPC(CIDR) 위에 서브넷을 AZ별로 나누고, 라우트 테이블로 public/private를 결정하며, IGW/NAT로 출입과 외출을 만들고, SG/NACL로 보안을 통제한다. 아직 나는 네트워크가 약하지만, 이 흐름을 머릿속에서 한 번 ‘왕복’시킬 수 있게 되니 실습에서 막혀도 어디부터 의심해야 할지 감이 잡힌다. 다음에는 실제로 VPC를 만들고(서브넷/라우팅/SG까지) “Public ALB + Private EC2” 구조를 최소 구성으로 재현해보며 더 구체적으로 기록해볼 생각이다.

적고보니 어려운 용어의 집합인거같다. ChatGPT가 없었다면 이정도 용어를 이해하면서 공부하는게 대여섯배 시간이 더 걸렸을거 같다. 책을보면서 그리고 회사 동료가 가르쳐줬던 내용을 용어를 찾아가면서 한단계식 돌파하고 있는데 생각보다 AI로 시간적인 도움을 많이 받고 있다. 

댓글

댓글 쓰기

이 블로그의 인기 게시물

JOIN 기초: users와 point_history를 합쳐 ‘회원별 요약(잔액/최근 활동)’ 만들기

포인트 원장(point_history)만으로도 잔액과 통계를 만들 수 있지만, 실제 화면이나 운영 도구에서는 거의 항상 “사용자 정보”가 함께 필요합니다. 예를 들어 이런 질문들은 point_history만으로는 답이 부족합니다. 이 uid가 누구인지(가입일, 상태 등) 함께 보고 싶다 회원 목록을 보면서 각 회원의 잔액/최근 활동을 한 줄로 요약하고 싶다 최근 7일 동안 사용이 많은 회원을 “회원 정보와 함께” 추려 보고 싶다 이때 필요한 것이 JOIN입니다. JOIN은 테이블을 “합치는” 기능이지만, 정확히는 두 테이블의 행을 연결 해 새로운 결과를 만드는 방식입니다. 이번 글에서는 포인트 시스템에서 가장 흔한 JOIN 패턴(회원 + 원장 요약)을 중심으로, INNER JOIN/LEFT JOIN의 차이와 실전에서 헷갈리는 포인트를 정리합니다. 이 단원의 목적: “회원 목록 + 포인트 요약”을 안정적으로 뽑아내기 JOIN은 문법을 외우는 것보다 “어떤 결과를 만들고 싶은지”를 먼저 그리는 것이 중요합니다. 이번 글의 목표는 아래 3가지입니다. INNER JOIN과 LEFT JOIN의 차이를 이해하고 상황에 맞게 선택한다 집계(GROUP BY)와 JOIN을 결합해 ‘회원별 잔액/통계’를 만든다 JOIN에서 자주 발생하는 오류(행 폭증, 중복 집계)를 피하는 패턴을 익힌다 준비: users에 최소한의 컬럼을 더해 “JOIN 결과가 읽히게” 만들기 이전 글에서는 users가 uid와 created_at만 있었지만, JOIN 결과를 보기 편하게 하려면 display_name 같은 컬럼이 하나 있으면 좋습니다. 실제 서비스라면 이메일/닉네임/상태값이 있을 텐데, 여기서는 학습 목적상 간단히 display_name을 추가합니다. -- 이미 있다면 생략 ALTER TABLE users ADD COLUMN display_name VARCHAR(50) NULL; -- 예시 값 입력(학습용) UPDATE users SET display_n...
자세한 내용 보기

점검 SQL: “원장 합계(SUM) vs balance” 불일치를 찾아내고 원인을 좁히는 방법

포인트 시스템은 “정상 처리”만 잘 만들면 끝나는 것처럼 보이지만, 실제로는 시간이 지날수록 다양한 이유로 데이터가 어긋날 수 있습니다. 예를 들어 이런 상황이 생깁니다. 중간 장애로 트랜잭션이 일부만 반영된 것처럼 보이는 케이스(재처리/수동 개입 포함) 운영 정정(ADJUST)이나 소프트 삭제(hide) 처리 기준이 흔들린 케이스 배치 작업(만료/정산)이 예상과 다른 시간에 들어간 케이스 코드 변경 이후 특정 action_type이 누락/중복 집계된 케이스 그래서 “점검 쿼리”는 기능 쿼리만큼 중요합니다. 특히 balance 테이블(잔액 캐시)을 함께 쓰는 구조라면, 주기적으로 원장 합계와 balance가 같은지 확인해야 합니다. 이 단원의 목적: 불일치를 “발견”하고 “원인”을 좁힐 수 있는 쿼리 세트 만들기 이번 글에서는 아래 3가지를 목표로 합니다. 원장 합계(SUM)와 balance를 비교해 불일치 UID를 뽑는다 불일치가 발견되면 어디서부터 어긋났는지 범위를 좁힌다 자주 발생하는 유형(숨김 처리, 중복 요청, 배치 만료)을 점검 항목으로 만든다 1) 1차 점검: uid별 “원장 잔액”과 “balance 잔액” 비교 가장 기본은 uid별로 두 값을 나란히 놓고 비교하는 것입니다. 여기서는 hide=0만 원장 합계에 포함한다고 가정합니다. SELECT b.uid, b.balance AS balance_cache, COALESCE(l.ledger_balance, 0) AS balance_ledger, b.balance - COALESCE(l.ledger_balance, 0) AS diff FROM point_balance b LEFT JOIN ( SELECT uid, SUM(amount) AS ledger_balance FROM point_history WHERE hide = 0 GROUP BY uid ) l ON l.uid = b.uid WHERE b.balance <> COALESCE(l.ledger_...
자세한 내용 보기

EXPLAIN 기초: 점검/리포트 쿼리가 느려질 때 “왜 느린지” 확인하는 방법

포인트 시스템을 만들어가면서 새삼 느끼는것은 생성형AI가 있어서 설계하고 구상하는게 너무 쉬워졌다는것입니다. 혼자서 했다면 아마도 어려움이 많았을거 같은데 AI와 대화를 하며 개선점을 찾아가는 방식으로 진행하다보니 생각보다 기능이 치밀하게 설계를 할 수 있었습니다. 지금까지 하나하나 학습범위를 늘려가며 왔는데 아직도 갈길이 먼거 같습니다.  포인트 원장(point_history)은 시간이 지날수록 커집니다. 데이터가 커지면, 기능 쿼리(내역/잔액)뿐 아니라 점검 쿼리(원장 vs balance 비교, 월별 집계, ref_id 그룹핑)도 점점 느려집니다. 이때 흔히 “인덱스를 더 만들면 되지 않을까?”라고 생각하지만, 인덱스는 무조건 늘린다고 좋아지지 않습니다. 어떤 쿼리가 어떤 방식으로 실행되는지 모르면 잘못된 인덱스를 만들거나, 효과 없는 튜닝을 반복할 가능성이 큽니다. 그래서 필요한 도구가 EXPLAIN 입니다. EXPLAIN은 “이 쿼리를 DB가 어떤 순서로 실행할지”를 보여주는 실행 계획입니다. 즉, 느린 이유를 추측하지 않고 눈으로 확인 할 수 있게 해줍니다. 이 단원의 목적: 실행 계획을 보고 “어디를 고칠지” 결정하기 이번 글의 목표는 아래 3가지입니다. EXPLAIN 결과에서 최소한의 핵심 항목을 읽을 수 있게 된다 포인트 시스템 쿼리에서 자주 나오는 느린 패턴(풀 스캔, filesort)을 구분한다 인덱스를 “조회 패턴에 맞게” 설계하는 감각을 만든다 1) EXPLAIN 사용법: SELECT 앞에 붙이면 된다 가장 기본은 SELECT 앞에 EXPLAIN을 붙이는 것입니다. EXPLAIN SELECT id, action_type, amount, created_at FROM point_history WHERE uid = '11111111-1111-1111-1111-111111111111' AND hide = 0 ORDER BY created_at DESC, id DESC LIMIT 50; 실행 결과는 ...
자세한 내용 보기