AWS 안의 중요한 용어 개념잡고 가기 1

예전에 VMWare를 이용해서 3개의 서버를 구성하고 네트워크 실습을 한적이 있었다. 하지만 곧 흐지부지되고 공부를 마칠수밖에 없었는데 당시 모바일개발을하던 나에게 네트워크는 너무 먼 이야기였던거 같다. 지금도 마찬가지로 AWS를 공부할 때 제일 막막했던 파트가 네트워크였다. 그래서 2026년 기준으로 내가 이해한 범위 안에서 VPC부터 서브넷, 라우팅, 보안(SG/NACL)까지 핵심 용어를 내 말로 정리해 학습 기록으로 남긴다. 물론 회사 동료에게 속성으로 배우는 시간이 있었는데 솔직히 너무 어려운 인터페이스때문에 어느 메뉴가 어디인지도 지금은 기억이 나지 않는다. 그래서 천천히 나중에 헷갈릴 때 다시 읽을 수 있게 “한 줄 정의 + 실무 감각” 중심으로 적어보려고 한다.

소제목 1 - VPC: AWS 안에서 만드는 나만의 가상 사설 네트워크

AWS VPC

VPC는 내가 AWS에서 처음 제대로 붙잡은 개념이다. 예전에는 “그냥 네트워크 설정 같은 거겠지”라고 생각했는데, 실습을 해보니 VPC는 거의 모든 리소스 배치의 시작점이었다. 내가 이해한 VPC는 “AWS 안에서 만드는 나만의 가상 사설 네트워크, 즉 데이터센터 한 칸”이다. 회사에서 사내망을 따로 운영하듯이, AWS에서도 내 서비스가 돌아갈 사내망을 하나 만든다고 보면 감이 잡혔다.

VPC를 만들 때 제일 먼저 하는 건 IP 대역(CIDR)을 정하는 것이다. 예를 들어 10.0.0.0/16 같은 범위를 잡아두고, 그 안에 EC2(서버), RDS(DB), ALB(로드밸런서) 같은 자원을 배치한다. 여기서 중요한 건 “처음부터 너무 작게 잡지 말 것”과 “겹치지 않게 잡을 것”이라고 들었다. 나중에 다른 네트워크랑 연결(VPN/Peering/Transit Gateway 같은 것)을 할 수도 있는데, CIDR이 겹치면 골치가 아프다고 해서 나는 공부용이라도 신중하게 잡아두려고 했다.
VPC를 ‘한 덩어리’로만 보면 좀 추상적인데, 내 머릿속에서는 “큰 땅”으로 생각하니 이해가 쉬웠다. 땅이 있으면 구역을 나눠야 하고(서브넷), 길을 깔아야 하고(라우트 테이블), 출입구를 만들고(IGW), 외부로 나가는 통로를 만들고(NAT), 경비 규칙을 세워야 한다(SG/NACL). 결국 VPC는 그 모든 요소가 얹히는 ‘기본 지도’였다.
내가 초반에 가장 많이 헷갈렸던 포인트는 “VPC 자체가 인터넷이 되게 해주는 게 아니다”라는 점이었다. VPC는 사설망이고, 인터넷과 통신하려면 IGW 같은 출입구가 필요하다. 그리고 그 출입구가 있다고 해서 자동으로 다 열리는 것도 아니고, 라우팅/공인 IP/보안 규칙이 같이 맞아야 한다. 정리하면 VPC는 ‘내가 통제하는 사내망’이고, 인터넷과 연결하는 건 별도의 장치와 규칙으로 결정된다고 이해했다.

소제목 2 - Subnet & Route Table: public/private를 가르는 진짜 기준

서브넷은 VPC를 더 작게 나눈 구역이다. 나는 “동네/건물 단위”라는 비유가 제일 이해가 쉬웠다. 예를 들어 VPC가 10.0.0.0/16이면, 그 안을 10.0.1.0/24, 10.0.2.0/24 같은 식으로 쪼개서 서브넷을 만든다. 여기서 실무적으로 많이 나오는 규칙은 “AZ(가용영역) 단위로 서브넷을 나눠서 고가용성을 만든다”는 것이다. 같은 서브넷에만 자원을 몰아두면 AZ 장애가 났을 때 같이 터질 수 있으니, 서브넷을 AZ 별로 나누는 구성이 자연스럽다.
그리고 내가 진짜 많이 오해했던 게 public subnet / private subnet이다. 나는 처음에 이름만 보고 “public으로 만들면 public, private으로 만들면 private”인 줄 알았다. 그런데 실제로는 이름표가 아니라 라우팅이 결정한다. 즉, 그 서브넷이 연결된 라우트 테이블에 0.0.0.0/0이 어디로 가게 되어 있느냐가 핵심이었다.
라우트 테이블은 “서브넷이 어디로 트래픽을 보낼지 정하는 길 안내판”이다. 예를 들어 이런 규칙이 있다.
- 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)가 붙어 있어야 하고, SG/NACL도 허용돼야 한다. 즉, 나는 이제 public/private를 볼 때 “라우팅(IGW/NAT) + 공인 IP 유무 + 보안 규칙” 세 가지를 같이 체크해야 한다고 정리했다.
내가 자주 떠올리는 기본 그림은 이거다. 웹 서비스에서 Public Subnet에는 ALB나 Bastion, NAT Gateway 같은 인터넷과 맞닿는 구성요소를 두고, Private Subnet에는 앱 서버(EC2/ECS)나 DB(RDS)를 둔다. 그리고 라우팅은 Public은 IGW, Private은 NAT로 나간다. 이 그림이 머리에 들어오니, 네트워크 설정이 조금 덜 무섭게 느껴졌다.

소제목 3 - IGW/NAT/SG/NACL: “나가고 들어오고 막고 허용하기”를 결정하는 것들

여기부터는 내가 공부하면서 “아, 이게 실제 운영에서 사고 나는 지점이구나”라고 느꼈던 영역이다. 우선 Internet Gateway(IGW)는 VPC가 인터넷과 통신할 수 있게 해주는 출입구다. 내가 이해한 한 문장은 “VPC의 인터넷 출입구”다. Public subnet 라우트 테이블에 0.0.0.0/0 -> IGW가 들어가면 인터넷으로 나갈 수 있는 길이 열리고, 공인 IP와 보안이 맞으면 외부에서 들어오는 것도 가능해진다.
NAT Gateway는 private subnet 서버가 “바깥으로 나가기만” 가능하게 해주는 장치다. 외부에서 private subnet으로 직접 들어오는 건 불가능하고, apt update나 패키지 다운로드, 외부 API 호출, 도커 이미지 pull 같은 아웃바운드가 필요할 때 사용한다. 보통 NAT Gateway는 public subnet에 두고, private subnet 라우트 테이블에서 0.0.0.0/0 -> NAT로 걸어준다. 내가 실무 관점에서 기억해둔 포인트는 “NAT는 비용이 발생한다(시간/트래픽)”와 “AZ 단위 장애를 고려해 AZ별 NAT를 두기도 한다”는 점이다. 공부용으로도 비용 공포가 있는 나에게 NAT는 특히 조심해야 하는 리소스라고 느꼈다.
보안 쪽은 Security Group(SG)과 Network ACL(NACL)을 같이 보는데, 나는 둘의 차이를 ‘상태 기반 vs 무상태’로 외우는 게 가장 쉬웠다. SG는 인스턴스(정확히는 ENI)에 붙는 상태 기반(Stateful) 방화벽이다. 인바운드/아웃바운드 규칙을 정하면, 한쪽을 허용했을 때 응답 트래픽은 자동으로 허용된다. 그래서 실무에서 가장 자주 만지는 방화벽이 SG라고 한다. 예를 들어 웹서버 SG는 80/443 인바운드를 허용하고, DB SG는 앱서버 SG에서 오는 3306만 허용하는 식이다. 나는 “SG로 ALB → 앱, 앱 → DB만 열어둔다”는 문장을 기준으로 외우려고 했다.
NACL은 서브넷에 붙는 무상태(Stateless) 방화벽이다. 인바운드/아웃바운드를 각각 따로 허용해야 하고, 응답 트래픽도 규칙이 필요하다. 그리고 허용(Allow)뿐 아니라 거부(Deny)도 할 수 있고, 규칙 번호 우선순위가 있다. 실무에서는 SG로 충분하면 NACL은 최소로 쓰는 팀도 많다고 들었다. 하지만 특정 IP 대역을 “서브넷 레벨에서 아예 차단”해야 하는 요구가 있으면 NACL이 유용하다는 점도 기억해뒀다.
추가로 나는 Elastic IP(EIP)도 같이 메모했다. EIP는 고정 공인 IP라서 서버를 재시작/교체해도 IP를 유지하고 싶을 때 쓴다. 다만 할당만 해놓고 안 쓰거나 조건에 따라 비용이 발생할 수 있어서, 공부용 계정에서는 더더욱 “만들면 관리까지”를 해야 한다고 적어뒀다. 그리고 DNS/Route 53은 example.com 같은 도메인을 IP나 AWS 리소스로 연결해주는 체계다. ALB, CloudFront, S3 웹호스팅 등과 연동된다는 점 때문에, 나중에 실제 서비스처럼 구성해볼 때 꼭 다시 공부할 영역이라고 느꼈다.
마지막으로 VPC Endpoint는 내가 “NAT 비용 줄이기” 쪽에서 특히 관심이 간 개념이다. S3/DynamoDB 같은 AWS 서비스 접근을 인터넷/NAT을 거치지 않고 VPC 내부 경로로 하게 해준다. 보안도 강화되고 NAT 의존도도 줄일 수 있다. S3/DynamoDB는 Gateway Endpoint가 흔하고, 그 외 서비스는 Interface Endpoint(ENI 생성)가 흔하다는 정도까지는 기억해두었다. 아직 깊게 써보진 못했지만, “사설로 AWS 서비스에 접근한다”는 방향성 자체가 큰 힌트였다.

나는 VPC를 “AWS 안의 사내망”으로 이해하고, 서브넷은 그 안의 구역, 라우트 테이블은 길 안내판으로 정리했다. public/private는 이름이 아니라 라우팅(IGW/NAT)이 가르고, 실제 통신은 공인 IP와 SG/NACL 규칙까지 함께 맞아야 한다는 것도 배웠다. 아직 나는 네트워크가 약하지만, 이 용어들을 내 말로 다시 정리해두니 실습에서 막혔을 때 어디부터 의심해야 할지 조금 감이 잡힌다. 다음에는 이 개념을 바탕으로 “Public ALB + Private EC2 + RDS” 기본 아키텍처를 직접 만들어보며 더 구체적으로 기록해보려고 한다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

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; 실행 결과는 ...
자세한 내용 보기