코딩 초보 블로그

[DB] SQL 쿼리 성능 최적화 공부

코딩연습중 — Sat, 10 Oct 2026 15:09:08 +0900

현재 회사에서 내가 맡은 시스템에 조회 성능이 안 좋은 부분이 있다. 이 때문에 업무에 불편함을 느낀다는 불만이 있어서 틈틈이 최적화를 해볼까 한다.
쿼리 성능 최적화는 처음이라, 공부하면서 진행 방법을 기록하려고 글을 남긴다.

진행 순서

[1단계] 어디가 느린지 찾기

성능 최적화가 필요한 쿼리문을 복사해서 가져온다.
테이블 정보 조회.sql로 쿼리에 포함된 테이블 정보를 엑셀로 추출한다.
조건절(WHERE, JOIN의 ON)에 쓰인 컬럼에 인덱스가 걸려 있는지 확인한다.
- 단, 인덱스가 있다고 해서 실제로 쓰이는 건 아니다. 사용 여부는 실행계획에서 확인한다.
가장 안쪽 쿼리부터 실행하면서 오래 걸리는 부분을 찾는다. (약 2000건 결과면 0.01초 정도가 적당)
- 주의: 같은 쿼리를 두 번 실행하면 DB 버퍼 캐시 때문에 두 번째가 빨라진다. 시간보다 **읽은 양(Rows, Buffers)**이 더 믿을 만한 기준이다.

[2단계] 왜 느린지 보기

느린 부분의 실행계획을 확인한다. (공부 중)
- 가장 안쪽으로 들여쓰기된 줄부터 실행된다.
- TABLE ACCESS FULL: 테이블 전체를 읽었다는 뜻. 큰 테이블이면 1순위로 의심한다.
- 많이 읽었는데 결과 건수가 적으면 낭비가 있다는 신호다.

[3단계] 고치고 확인하기

아래 "증상별 처방"을 보고 원인을 하나씩 고친다.
고치기 전후의 실행계획, 읽은 양, 시간을 비교한다. 결과 건수와 내용이 같은지도 반드시 확인한다.

증상별 확인할 부분

실행계획에서 보이는 것

인덱스가 있는데 FULL SCAN	조건절 좌변(컬럼)에 함수나 연산을 쓰지 말고 우변 값을 바꾼다. OR 대신 UNION 사용을 검토한다.
많이 읽고 결과는 적음	WHERE 조건으로 필요한 데이터만 조회한다. 꼭 필요한 행과 컬럼만 가져온다.
서브쿼리가 행마다 반복 실행됨	서브쿼리를 줄이고 JOIN, EXISTS, UNION으로 대체한다.
큰 테이블부터 조인함	JOIN 순서를 확인한다. 작은 결과를 먼저 만드는 쪽이 유리하다.

좌변 연산 예시:

-- 인덱스 사용 불가
WHERE TO_CHAR(REG_DT, 'YYYYMMDD') = '20261010'
-- 인덱스 사용 가능
WHERE REG_DT >= TO_DATE('20261010', 'YYYYMMDD')
  AND REG_DT <  TO_DATE('20261010', 'YYYYMMDD') + 1

캐시 정리

DB 버퍼 캐시: DB가 자동으로 관리한다. 개발자가 직접 만들 수 없다.
스칼라 서브쿼리 캐싱: SELECT절 서브쿼리에 같은 입력값이 반복되면 Oracle이 결과를 재사용한다. 코드값처럼 종류가 적은 값이면 효과가 크고, 사번처럼 매번 다르면 효과가 없다. 그럴 땐 JOIN이 낫다.
애플리케이션 캐시: Spring @Cacheable, Redis 등으로 직접 만든다. 데이터가 바뀌어도 옛날 값이 남을 수 있어서, 공통코드처럼 거의 안 바뀌는 데이터에만 쓴다. 쿼리를 먼저 고치고 캐시는 마지막 수단으로 생각한다.

테이블 정보 조회.sql

0.00MB

참고:

https://community.heartcount.io/ko/query-optimization-tips/

SQL 쿼리 성능 최적화를 위한 튜닝 팁 6가지 (Query Optimization)

보다 효율적인 데이터 검색 및 추출을 위해 필요한 SQL 쿼리 튜닝 방법을 알려 드려요. 실무에서 더 빠르고 효과적으로 데이터를 처리할 수 있도록 하는 꿀팁 6가지에 대해 알아 보세요.

community.heartcount.io

https://chung-develop.tistory.com/145

SQL 쿼리 튜닝하는 여러가지 방법

SQL 쿼리는 데이터베이스에서 데이터를 추출하거나 조작하는 데 사용됩니다. 그러나 대용량 데이터나 복잡한 쿼리의 경우 성능이 저하될 수 있습니다. 이러한 문제를 해결하기 위해 SQL 쿼리를

chung-develop.tistory.com

AWS 네트워크 흐름 이해 테스트

코딩연습중 — Fri, 13 Mar 2026 22:20:24 +0900

문제 1 — Public Subnet EC2 → Internet

다음 상황에서 패킷이 어떤 경로로 이동하는지 설명하시오.

조건

EC2는 Public Subnet
Public IP 있음
Route table에

0.0.0.0/0 → Internet Gateway

설정되어 있음.

EC2에서 curl google.com을 실행했을 때
패킷은 어떤 네트워크 구성 요소들을 거쳐 인터넷으로 나가는가?

우선 라우팅 테이블에서 0.0.0.0/0(외부로 나가는 요청)에 대한 규칙을 찾음.

-> ec2의 private IP -> public IP로 변환 후, IGW를 거쳐서 나감

-> 응답은 Public IP -> private IP로 받아와짐?

모범답안

EC2가 외부로 요청을 보낼 때 먼저 라우팅 테이블에서 0.0.0.0/0 규칙을 확인하고, 대상이 Internet Gateway임을 확인한다. Public subnet의 EC2는 퍼블릭 IP가 연결되어 있으므로 IGW를 통해 인터넷과 통신할 수 있다. 외부 응답은 해당 퍼블릭 IP로 돌아오고, 인스턴스와 연결된 네트워크 인터페이스로 전달된다.

문제 2 — Private Subnet EC2 → Internet

조건

EC2는 Private Subnet
Public IP 없음
Route table

0.0.0.0/0 → NAT Gateway

질문

EC2에서 curl google.com 실행 시
패킷은 어떤 경로로 인터넷에 도달하는가?

private ec2는 IGW를 사용하기 위한 public ip가 할당되지 않았기 때문에, 외부에서 인식할 수 없음.

따라서 NAT Gateway를 통해, private ip를 public ip로 변환해야 함. 이 때 NAT Gateway에 할당된 public ip로 변환되며,

NAT Gateway table에 private -> 외부로 데이터가 나가고 들어오는 과정이 기록됨.

stateful한 성질임.

모범답안

Private subnet의 EC2는 퍼블릭 IP가 없기 때문에 인터넷과 직접 통신할 수 없다. 그래서 라우팅 테이블에서 0.0.0.0/0 -> NAT Gateway 경로를 타고 NAT Gateway로 패킷을 보낸다. NAT Gateway는 EC2의 private IP를 자신의 public IP로 변환해 인터넷으로 내보낸다. 이후 응답이 NAT Gateway의 public IP로 돌아오면, NAT Gateway가 이를 원래의 private EC2로 전달한다. 이 과정에서 NAT Gateway는 연결 상태를 기억하므로 stateful하게 동작한다.

문제 3 — Private EC2 → S3 (Endpoint 없음)

조건

EC2는 Private Subnet
NAT Gateway 존재
VPC Endpoint 없음

질문

EC2에서 aws s3 ls 실행 시
패킷은 어떤 경로로 S3에 도달하는가?

private ec2 -> nat gateway에서 ip 변환 -> 외부 인터넷 -> S3.

vpc endpoint가 없으면 내부 aws 서비스가 아닌 인터넷으로 통신하게 됨

모범답안

VPC Endpoint가 없으면 Private EC2가 S3에 접근할 때도 일반 외부 트래픽과 비슷하게 NAT Gateway와 Internet Gateway를 거쳐 인터넷 경로를 사용하게 된다. 즉 대상은 AWS의 S3 서비스이지만, 네트워크 관점에서는 내부 전용 경로가 아니라 인터넷 경로를 따라간다.

문제 4 — Private EC2 → S3 (Endpoint 있음)

조건

S3 Gateway Endpoint 생성
Route table에 prefix list 추가

질문

EC2에서 aws s3 ls 실행 시
패킷 경로는 어떻게 바뀌는가?

모범답안

S3 Gateway Endpoint를 만들면 라우팅 테이블에 S3 Prefix List로 향하는 경로가 추가되고, 그 결과 S3 트래픽이 NAT가 아니라 Endpoint로 향하게 된다.

문제 5 — User → EC2

조건

EC2는 Public Subnet
Public IP 있음

질문

사용자가 브라우저에서 EC2 서버에 접속할 때
패킷은 어떤 경로로 서버에 도달하는가?

외부 브라우저 -> IGW

-> NACL

-> SG?

모범답안

외부 사용자의 요청이 Internet Gateway를 통해 VPC로 들어오고,
먼저 Subnet 단위의 NACL 검사를 거친 뒤,
인스턴스에 연결된 Security Group 검사를 거쳐 EC2에 도달한다.

다만 실무적으로는 “라우팅도 같이 고려”해야 함

문제 6 — VPC Peering 통신

조건

VPC-A 10.0.0.0/16
VPC-B 10.1.0.0/16

Peering 연결 있음.

질문

EC2-A에서 EC2-B로 ping을 보낼 때
패킷은 어떤 네트워크 경로를 따라 이동하는가?

IGW 사용되지 않고, vpc peering을 통해 vpc 간의 통신(1홉?)

모범답안

VPC Peering이 설정되어 있으면 EC2-A가 EC2-B의 private IP로 패킷을 보낼 때 라우팅 테이블에서 상대 VPC 대역을 확인하고, 대상이 peering connection임을 확인한다. 이후 패킷은 인터넷을 거치지 않고 peering connection을 통해 상대 VPC로 전달된다. 따라서 이 통신에는 Internet Gateway가 사용되지 않는다.

문제 7 — Security Group vs NACL

다음 상황을 설명하시오.

조건

EC2 Security Group

Inbound: 80 허용

NACL

Inbound: 80 허용
Outbound: 전체 허용

질문

외부 사용자가 EC2에 HTTP 요청을 보낼 때
패킷은 어떤 순서로 필터링을 통과하는가?

SG는 인스턴스 단위이기 때문에 SG 먼저. 이는 stateful한 특성.

그 다음이 NACL. 이건 서브넷 단위. 이는 stateless함.

(아 외부에서 들어온 요청이라 반대여야 함!)

모범답안

외부 요청은 먼저 서브넷 경계에서 NACL 검사를 거친 뒤, 인스턴스에 연결된 Security Group 검사를 거쳐 EC2에 도달한다. NACL은 stateless이므로 요청과 응답 각각에 대해 규칙이 필요하고, Security Group은 stateful이므로 허용된 요청의 응답은 별도 규칙 없이 통과할 수 있다.

[네트워크] AWS 실습 #04

코딩연습중 — Fri, 13 Mar 2026 22:03:35 +0900

1. NACL은 Stateless

SG과 NACL의 차이로는 SG는 인스턴스 단위, NACL은 네트워크 단위라는 점이 있다.

그리고 SG는 stateful, NACL은 stateless의 성질을 가진다.

이번에는 이를 직접 확인해보겠다.

public에서 private으로 ssh 접속은 가능하지만, private -> public으로 응답을 보내는 건 불가능하게 해보겠다.

만약 SG에서 인바운드 규칙에서 public sg를 대상으로 22번 포트를 열어두면 statefull한 특징 때문에 아웃바운드도 성공하게 되어있다.

하지만 nacl은 다르다.

우선 이렇게 private subnet에 연결된 nacl의 규칙을 수정해서 public -> private으로 ssh 접속을 할 수 있게 했다.

-> 근데 접속이 안 됨!

왜일까?

Private NACL 아웃바운드에서 22번만 열어둠
근데 SSH “응답”은 상대(클라이언트)의 임시 포트(1024~65535) 로 나가야 해서,
22만 열면 SYN-ACK/ACK 단계가 막혀서 접속이 안 됨.

Public EC2에서 Private EC2로 SSH 할 때:

Public(클라): 10.0.1.x:임시포트(예: 53422) → Private(서버): 10.0.2.x:22
Private(서버) 응답: 10.0.2.x:22 → Public(클라): 10.0.1.x:53422

여기서 Private 서브넷 NACL Outbound 규칙은 “목적지 포트(=53422)” 기준인데,
Outbound에 22만 허용해놨으니까 응답이 다 막힘.

따라서 아래와 같이 아웃바운드 규칙을 다시 수정했다.

이렇게 인/아웃바운드 규칙을 편집해 public subnet에서 22번 포트로 들어오는 패킷은 허용하고, 나가는 건 거부하도록 설정했다.

접속 안됨

2. VPC Peering

AWS에서는 여러 VPC를 만들어서 독립된 네트워크를 구성할 수 있는데, vpc끼리는 또 vpc peering을 통해 인터넷을 거치지 않고 소통할 수가 있다.

지금부터 실습을 통해 직접 확인해보겠다.

1. vpc 두개 생성

2. 각 vpc에 서브넷 생성

라우팅 테이블에 igw 연결

3. EC2 각각 생성

이제 실습 시작!

EC2-A에 ssh 접속해서 EC2-B에 ping 보내봤는데 안됨.

생각해보니까 아직 피어링 연결을 생성하지 않음

이렇게 peering 생성 후, 요청 수락.

라우팅 테이블 수정 - 각각의 vpc 라우팅 테이블에 vpc peering 했던 거 추가

그리고 나서 EC2-A에서 EC2-B로 ping 요청 보내면

이렇게 잘 됨

그럼 만약 여기서 VPC-C를 새롭게 만들고,

VPC-B -> VPC-C에 피어링 연결을 하면, VPC-A -> VPC-C 간의 피어링 연결이 될까?

답은, 아니다.

VPC Peering은 중간 VPC를 통한 라우팅(transitive routing) 을 지원하지 않기 때문.

이러한 제약 때문에 여러 VPC를 연결해야 하는 환경에서는 보통 Transit Gateway와 같은 구조를 사용한다.

3. VPC Endpoint

VPC Endpoint는 VPC 내부에서 인터넷을 거치지 않고 AWS 서비스(S3 등)에 접근하는 방법이다.

보통 EC2에서 S3 접근할 때 흐름은 이렇게 된다.

EC2 -> NAT Gateway -> Internet -> S3

즉, AWS 내부 서비스인데도 인터넷을 나갔다 들어옴.

이럴 때 VPC Endpoint를 사용.

엔드포인트를 만들면 흐름이 다음과 같아진다.

EC2 -> VPC Endpoint -> S3

➡ AWS 내부망으로 통신

Endpoint에는 두 종류가 있다.

Gateway Endpoint

S3
DynamoDB
무료

Interface Endpoint

대부분 AWS 서비스
PrivateLink 기반
ENI 생성
시간당 비용 있음

VPC Endpoint 사용 예

EC2 로그를 S3에 저장하는 경우
백업 데이터를 S3에 업로드하는 경우
CI/CD 파이프라인에서 S3 artifact를 다운로드하는 경우
Private Subnet 환경에서 S3 접근이 필요한 경우

Endpoint 생성 시 내부 동작

S3 Gateway Endpoint를 생성하면 VPC의 Route Table에 다음과 같은 경로가 추가된다.

Destination: pl-xxxx (S3 Prefix List)
Target: vpce-xxxx

이 의미는 다음과 같다.

➡ S3로 향하는 트래픽은 인터넷이 아니라 VPC Endpoint를 통해 전달하라는 의미

VPC Endpoint는 새로운 네트워크 장비라기보다 특정 AWS 서비스로 향하는 트래픽의 라우팅 경로를 변경하는 기능

[알고리즘] 전화번호 목록 문제

코딩연습중 — Thu, 12 Mar 2026 20:07:39 +0900

https://school.programmers.co.kr/learn/courses/30/lessons/42577

프로그래머스

SW개발자를 위한 평가, 교육의 Total Solution을 제공하는 개발자 성장을 위한 베이스캠프

programmers.co.kr

취준 중 오랜만에 여유가 생겨서 알고리즘 문제를 하나 풀어봤다!

전화번호부에 있는 번호들 중, 어떤 번호가 다른 번호의 접두어인지 확인하는 문제.

전화번호는 최대 1,000,000개.
길이는 각각 최대 20.

이중 for문으로 모든 번호를 다 비교하면 O(N²)인데,
최악의 경우 10^12번 비교해야 해서 말이 안 됨.
보통 1초에 10^8번 연산 가능하다고 잡으면 10,000초 수준이라 사실상 불가능.

따라서 이중 for문은 아님.

그럼 어떤 자료구조를 쓰면 좋을까?

처음에는 hash도 생각났는데,
이 문제는 단순 조회가 아니라 문자열끼리 접두어 비교가 필요해서
순서가 없는 map보다는 정렬 후 비교할 수 있는 list가 더 낫다고 판단.

일단 리스트로 바꾼 뒤 sort 해봄.
String 정렬 기준이 정확히 헷갈려서 직접 출력해봤는데,
사전순으로 잘 정렬되고 접두어 후보들도 서로 붙게 됨.

그러면 굳이 모든 문자열을 다 비교할 필요 없이
정렬된 상태에서 인접한 두 개만 비교하면 됨.

즉, curr와 next를 비교해서
next.startsWith(curr) 이면 curr가 next의 접두어라는 뜻이므로 false 반환.

import java.util.*;

class Solution {
    public boolean solution(String[] phone_book) {
        
        List<String> arrList = Arrays.asList(phone_book);
        
        Collections.sort(arrList);
        
        for(int i = 0; i < arrList.size() -1; i++){
            String curr = arrList.get(i);
            String next = arrList.get(i+1);
            
            if(next.startsWith(curr)){
                return false;
            }
        }
        
        return true;
    }
}

[네트워크] AWS 실습 #03

코딩연습중 — Wed, 18 Feb 2026 02:01:58 +0900

1. traceroute

우선 private ec2에서 traceroute를 설치

sudo apt update
sudo apt install -y traceroute

private ec2에서 google.com까지 패킷이 어떻게 왔다갔다하는지 traceroute로 확인할 수 있다.

traceroute google.com

위의 과정을 설명하자면,

1. private ec2에서 외부로 나가는 요청: subnet의 라우팅 테이블에 의해 nat로 향하게 됨. 따라서 10.0.1.194는 public subnet 영역에 할당된 NAT Gateway ENI private IP임.

AWS에서 NAT ENI(Elastic Network Interface)는 주로 NAT Gateway 또는 NAT 인스턴스가 프라이빗 서브넷의 트래픽을 인터넷으로 전달할 때 사용하는 네트워크 인터페이스를 의미

프라이빗 서브넷의 인스턴스가 인터넷과 통신하기 위해서는 퍼블릭 서브넷에 위치한 NAT 장치(Gateway/Instance)를 거쳐야 하는데, 이때 NAT 장치에 연결된 ENI가 사설 IP(Private IP)와 탄력적 IP(EIP) 간의 변환을 처리

2 ~ 13. AWS 외부 네트워크 ~ ISP(통신사) ~

14. Google.com

2. ICMP 차단

현재 private ec2의 인바운드 규칙을 보면, ssh만 열어두었다. 따라서 public에서 private으로 ssh 접속은 되지만 ping은 되지 않는다.

만약, 다음과 같이 인바운드 규칙에 icmp 프로토콜을 허용해준다면

위와 같이 ping이 정상적으로 동작한다.

이를 통해 보안그룹은 프로토콜 단위로 세세하게 제어할 수 있다는 걸 알 수 있다.

3. tcpdump

tcpdump로 패킷을 봐보자.

sudo tcpdump -ni ens5 port 22

이 서버의 ens5 네트워크 인터페이스에서 22번 포트로 오가는 모든 트래픽을 보여달라는 뜻

이번 실험의 목적은 “어디에서 패킷이 차단되는지”를 tcpdump를 통해 이해하는 것이다.

참고로 그 전에 tcpdump에 대한 이해가 부족한 것 같아 다시 한 번 짚고 넘어가겠다.

tcpdump는 ‘이 서버가 실제로 받은 패킷’만 보여준다.

서버가 패킷을 ‘받는다’는 게 무슨 뜻이냐

Private EC2 입장에서 보면, 외부에서 패킷이 올 때 순서는 이렇다:

AWS 네트워크를 타고 온다.
Private EC2의 네트워크 카드(ens5)로 들어온다.
리눅스가 그 패킷을 처리한다.
sshd 같은 프로그램이 그걸 사용한다.

tcpdump는 2번과 3번 사이,
즉 “이 서버의 네트워크 카드로 실제 들어온 패킷”을 보여준다.

그럼 이제 다시 넘어가보겠다.

1. SSH를 Security Group에서 차단한 경우

Private EC2에서 다음 명령어로 캡처 중이라고 가정한다.

sudo tcpdump -ni ens5 port 22

그리고 Public EC2에서 SSH 접속을 시도한다.

결과: 아무 패킷도 찍히지 않는다.

이유: Security Group은 ENI(Elastic Network Interface) 단계에서 패킷을 필터링한다.
즉, 패킷이 리눅스 커널까지 도달하지 못한다.

tcpdump는 운영체제 네트워크 스택에서 패킷을 관찰하는 도구이기 때문에, Security Group에서 드롭된 패킷은 애초에 보이지 않는다.

정리: Security Group에서 막히면 tcpdump에 아무것도 찍히지 않는다.

2.ICMP(ping)를 허용했을 때와 차단했을 때

Private EC2에서 다음 명령어 실행:

sudo tcpdump -ni ens5 icmp

Public EC2에서 ping

(1) ICMP 허용된 경우

다음과 같은 출력이 보인다.

IP 10.0.1.10 > 10.0.2.15: ICMP echo request
IP 10.0.2.15 > 10.0.1.10: ICMP echo reply

의미:

echo request는 ping 요청,
echo reply는 그에 대한 응답이다.

즉, ICMP 패킷이 정상적으로 왕복하고 있다.

(2) ICMP 차단된 경우

아무것도 찍히지 않는다.

역시 Security Group 단계에서 차단되어 OS까지 도달하지 못한 것이다.

3. SYN만 보이고 SYN-ACK가 보이지 않는 경우

tcpdump에 다음과 같이 찍힌다고 가정한다.

IP client > server: Flags [S]
IP client > server: Flags [S]
IP client > server: Flags [S]

SYN 패킷만 반복적으로 보이고, SYN-ACK가 없다.

이 경우 해석은 다음과 같다.

SYN은 서버까지 도달했다.
그러나 서버가 응답하지 못하고 있다.

가능한 원인:

sshd 프로세스가 떠 있지 않다.
서버의 아웃바운드 경로가 차단되어 SYN-ACK를 내보내지 못한다.
방화벽이나 NACL에서 응답이 차단되고 있다.

중요한 점은, SYN이 tcpdump에 보인다는 것은
이미 Security Group은 통과했다는 의미라는 것이다.

전체 비교 정리

Security Group에서 차단된 경우
→ tcpdump에 아무것도 찍히지 않는다.

포트는 열려 있으나 서비스가 실행되지 않은 경우
→ SYN 후 RST가 보인다.

정상 연결
→ S → S. → . (3-way handshake)

SYN만 반복
→ 응답 경로 또는 서버 설정 문제

다시 말하면, tcpdump는 운영체제에 도달한 패킷만 보여준다.
따라서 “보이지 않는 것” 자체가 중요한 단서가 된다.

패킷이 보이지 않으면 네트워크 레벨에서 차단된 것이고,
패킷이 보이는데 연결이 성립하지 않으면 서버 설정이나 응답 경로 문제다.

이 관점으로 보면, 보안 그룹과 애플리케이션 문제를 구분할 수 있다.

하... tcpdump를 예전에 전공 수업 때 실습했었는데 그 때 제대로 공부 안 한 게 후회됨.. 다시 하려니까 너무 막막했는데ㅠㅠ

그래도 해야되니까 열심히 해야겠다..

차분하게 조금씩 이해를 넓히려고 하니까 그래도 금방 이해가 돼서 다행이다.

다음 글에서는 아래의 내용을 다뤄보겠다.

NACL Stateless 실험
VPC Peering
Hairpin NAT
Public IP 1:1 NAT 구조
다른 VPC Public IP 통신 경로

[네트워크] AWS 실습 #02

코딩연습중 — Mon, 16 Feb 2026 15:44:32 +0900

원래는 항상 ec2 접속할 때 putty를 썼었는데

이번에는 cmd에서 ssh로 접속해보겠다. 우선 ssh -V로 깔려있는지 확인

내 key가 있는 디렉토리로 옮겨서 먼저 public ec2에 접속해보겠다.

1. Public EC2 접속

ssh -i key.pem ubuntu@<PUBLIC_EC2_PUBLIC_IP>

위의 명령어 작성

근데 key가 너무 열려있다고 에러나서 저렇게 설정함.(이 부분 설명 보충)

icacls "C:\path\to\key.pem" /inheritance:r
icacls "C:\path\to\key.pem" /grant:r %USERNAME%:R

그리고 나서 다시 접속하니 들어가짐

2. Private EC2 접속

그치만 같은 방법으로는 private ec2에는 timeout으로 접속이 안 된다.

그럼 이번에는 public ec2(bastion host)에서 private ec2로 ssh 접속해보겠다.

오.. 안 된다. 분명 public ec2 접속할 때 -A 옵션을 써서 키를 전달하려고? 했는데..

이건 Public EC2(바스천) 안에서 ssh-agent가 아예 안 떠있다는 뜻이야.
그래서 -A로 포워딩을 하든 말든, 쓸 수 있는 에이전트가 없어서 키를 전달/사용 못하고
결국 Private에서 Permission denied (publickey)가 뜨는 거.

라고 한다.

그래서 해결 방법은

1. 로컬 -> public ec2로 key 파일을 복사해와서 (scp) -i로 접속

2. 윈도우에서 agent 켜서 Agent Forwarding 살리기

나는 2번으로 해보겠다.

윈도우 PowerShell에서(관리자 권장)

Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent
ssh-add D:\eunbin\03_Personal_Info\02_aws\my-key.pem
ssh-add -l

ssh -A -i my-key.pem ubuntu@3.35.140.154 으로 접속 후

바스천에서 확인:

echo $SSH_AUTH_SOCK
ssh-add -L

SSH_AUTH_SOCK 경로가 찍히고
ssh-add -L에 공개키가 나오면 성공

이제 private 접속: ssh ubuntu@10.0.2.154

아 성공적으로 접속!

이제 여기서

curl ifconfig.me를 치면

이렇게 nat의 EIP가 나온다!

근데 ifconfig.me가 뭔지 궁금해서 구글에 그대로 쳐봤더니

이런 게 나옴! 지금 카페인데 이게 지금 카페가 쓰고 있는 공인 IP인가보다.

이런 거 보니까 갑자기 vpn 실습도 해보고 싶어지는데 이것도 나중에 제대로 다뤄보겠다.

3. NAT 꺼보기

private subnet의 라우팅 테이블에서 nat 연결을 제거.

nat연결을 제거하고 나니,

이렇게 외부로 나갈 수가 없다.(timeout)

4. SG vs NACL

private ec2의 보안그룹 > 인바운드 규칙에서 Bastion SG 허용을 제거.

하고 public에서 다시 private ssh 접속해보려니 timeout 뜸.

NACL과 SG의 가장 큰 차이는 '경계'이다. NACL은 서브넷 단위이고, SG는 인스턴스 단위이기 때문에 SG는 인스턴스 단위로 보안그룹을 설정할 수 있다.

두번째 차이점은

NACL은 stateless, SG는 stateful하다는 점.

SG는 요청 허용하면 응답을 자용 허용하는데, NACL은 아웃바운드까지 같이 꼭 열어줘야 함!

NACL: “서브넷 경계에서의 거친 가드레일(guardrail)”
- 명백히 불필요/위험한 트래픽(예: 특정 국가 대역, 알려진 공격 IP, 완전 불필요한 포트 범위)을 초기에 떨어뜨리는 용도
- 혹은 조직 정책상 “서브넷 단위로 최소 허용”을 강제하는 용도
SG: “인스턴스/서비스 단위의 정밀 정책”
- 어떤 서비스가 어떤 서비스와 통신하는지(웹→앱, 앱→DB) 같은 마이크로 세그먼테이션을 구현

“NACL로 부족해서 SG로 조정”이 필요한 예시

NACL이 “서브넷 단위”라서 못 하는 것/하기 불편한 것들이 있어.

1) SG 참조(보안그룹을 소스로 지정)

SG는 “소스 = 특정 SG”로 지정 가능
→ 예: App 서버 SG만 DB(3306) 접근 가능
NACL은 SG 같은 “논리 그룹”을 소스로 못 넣고 **CIDR(IP 대역)**만 가능
→ Auto Scaling으로 인스턴스가 늘고 IP가 바뀌면 NACL로 관리 지옥

예시

DB 인스턴스 SG inbound: 3306 from App-SG
NACL로 하면: 3306 from 10.0.2.0/24 같은 식 → 같은 서브넷의 다른 인스턴스도 DB 붙을 수 있음(원치 않을 수 있음)

2) 인스턴스별로 다르게 열어야 할 때

같은 서브넷 안에
- A는 8080 열고
- B는 9090 열고
- C는 내부만 열고
NACL은 서브넷 공통이라 세밀하게 분리하려면 서브넷을 쪼개야 함
SG는 인스턴스별로 붙여서 해결 가능

3) Stateful의 편리함(응답 트래픽 자동 허용)

NACL은 Stateless라서
- 인바운드만 열면 끝이 아니라
- **아웃바운드(에페멀 포트)**까지 같이 열어야 해서 실수하기 쉬움
SG는 “요청 허용하면 응답은 자동 허용”이라 운영 안전성이 높음

4) 정책 변경/배포 민첩성

SG는 특정 서비스만 즉시 조정 가능
NACL은 서브넷 전체 영향이라 변경 리스크가 더 큼

요약하면:

NACL은 “경계에서 큰 칼”, SG는 “서비스별 정밀 메스”.

다음 글에서는

1️⃣ traceroute 실험 (L3 라우팅 체감)
2️⃣ TCP handshake 레벨 분석 (L4 이해)
3️⃣ ICMP 막고 TCP만 허용 실험 (프로토콜 차이 체감)
4️⃣ tcpdump로 패킷 눈으로 보기
5️⃣ VPC Flow Logs 분석
6️⃣ SSM vs Bastion 비교
7️⃣ ALB → Private 구조 실험

이러한 내용을 다뤄보겠음

[네트워크] AWS 실습 #01

코딩연습중 — Mon, 16 Feb 2026 13:27:40 +0900

1단계: VPC 생성

우선 이렇게 VPC를 만들었다.

2단계: Subnet 2개 만들기

1. public subnet 생성

방금 만든 VPC에 public subnet을 생성한다.

public 서브넷은 10.0.1.0/24, private은 10.0.2.0/24로 네트워크 영역을 분리할 것이다.

2. private subnet 생성

private subnet도 동일한 방식으로 만들어준다.(서브넷 cidr 블록만 다르게)

3단계: Internet Gateway 만들기

test-internet-gateway라는 이름으로 IGW 생성했다.

다음 단계를 Public subnet 대역을 실질적으로 public으로 설정하기 위한 작업이다.(라우팅 테이블 설정)

그리고 VPC에 연결해야 함

4단계: Public 라우팅 테이블 설정

우선 라우팅 테이블을 생성해준다. (라우팅 테이블은 서브넷 단위!)

위와 같은 설정을 추가해서, 0.0.0.0/0(외부)로 나가려는 것들은 모두 IGW를 거치도록 설정해준다.

원래는 0.0.0.0/0이 아니라 public subnet의 주소블록을 쓰는 건 줄 알았는데, 생각해보니까 내가 할당받은 건 사설 ip 대역이지, 실제 IP가 아니기 때문에 말도 안 되는 생각이란 걸 깨달음.

~~외부에서 들어오는 건 실제로 할당 받은 하나의 IP가 있어야 가능한거임.~~

~~IGW에서 하는 것이 아님~~~

라우팅 테이블은 연결된 서브넷에서 나가는 패킷의 목적지에 따라 어디(다음 홉)로 보낼지 결정하는 규칙이다.

따라서 위에서 내가 했던 건 라우팅 테이블에 대해 제대로 이해하지 못해서 했던 생각임.

5단계: NAT Gateway 생성

private의 외부 접근을 위한 NAT Gateway를 생성해야 한다.

이 때 NAT의 위치는 Public Subnet으로 두어야 한다. 왜일까?

이걸 이해하기 위해 NAT의 동작 원리를 다시 한번 보겠다.

NAT의 역할 다시 정리

NAT는

Private 인스턴스가 인터넷으로 나갈 때
사설 IP → 공인 IP로 변환해주는 장치

예:

Private EC2 (10.0.2.15)
   ↓
NAT Gateway (3.3.3.3)
   ↓
Internet

NAT 동작 흐름

① Private EC2가 외부 API 호출

출발지:

10.0.2.15:54321

② NAT가 변환

3.3.3.3:40001

(자기 공인 IP로 바꿈 + 포트도 바꿈)

③ 응답이 돌아옴

Internet → 3.3.3.3:40001

NAT는 매핑 테이블 보고:

→ 10.0.2.15:54321

으로 다시 전달

NAT가 제대로 동작하려면:

NAT 자신이 인터넷과 연결되어 있어야 함
즉 IGW를 통해 나갈 수 있어야 함

그래서 NAT는 반드시 Public Subnet에 둬야 함

❌ 만약 NAT를 Private Subnet에 둔다면?

그 Subnet은 IGW 라우트가 없음.

그럼 NAT는 사설 IP 변환은 가능해도 인터넷으로 못 나감

→ 의미 없음

따라서 이처럼 내 public subnet 영역에 NAT gateway를 생성해줬다.

참고로 EIP를 할당받아야 NAT를 사용할 수 있다! 왜냐하면 내 사설 IP -> 공인 IP로 바꿔야하니까 NAT의 공인 IP가 있어야 함.

6단계: Private 라우팅 테이블 설정

위와 같이 설정하여 private subnet -> 외부로 나가는 요청은 nat를 거치도록 규칙을 추가한다.

그리고 private 서브넷 연결!

public 라우트 테이블도 public 서브넷에 연결되어있어야 함!

7단계: EC2 2개 띄우기

원래는 이제 public EC2, private EC2를 띄워서 여러 테스트를 진행해보려고 했는데

public 인스턴스를 만드는 중에 소스 유형을 내 IP로 하면 대체 '내 IP'는 어떻게 아는거지,,? 하는 의문이 생김.

이에 대한 내용은 따로 글로 정리해보겠다.

우선은 내 IP로 설정하고 넘어가겠다.

private 인스턴스는 아래와 같이 소스 유형을 public sg로 설정했다.

이렇게 하면 실험 준비 완료임!

다음 글부터는 실제로 실험해보면서 더 깊게 공부해보겠다.

[네트워크]_AWS를 통한 네트워크 구조 이해

코딩연습중 — Sun, 15 Feb 2026 15:38:32 +0900

Private/Public IP, Subnet에 대한 이해가 조금 어려워서 AWS를 예시로 이해해봤다.

예를 들어 내가 A 웹 서비스를 개발해서 EC2 인스턴스에 배포하려고 할 때, 가장 먼저 해야할 것은 VPC를 만들고 내가 사용할 사설 IP 대역(CIDR 블록)을 정하는 것이다.

여기서 중요한 포인트는 “사설 IP를 하나 할당받는다”가 아니라, 사설 IP ‘대역’을 내가 설정한다는 느낌이다.
예를 들어 VPC를 이렇게 만든다고 하자.

VPC CIDR: 10.0.0.0/16

이 뜻은 “나는 10.0.0.0부터 10.0.255.255까지의 사설 IP 공간을 내 네트워크로 쓰겠다”는 의미다.
(이 CIDR(/16)은 AWS가 정해주는 게 아니라 내가 선택/설정한다.)

그리고 AWS에서 어떤 서비스를 이용하든, VPC 내부에서는 이 사설 IP 대역을 기반으로 네트워크가 구성된다.

서브넷을 나누는 이유 (Public / Private 분리)

내 DB는 private하게 올려서 외부에서는 접근할 수 없게 하고,
내 서비스는 외부 사용자가 접근할 수 있도록 하고 싶다면, 서브네팅으로 네트워크 대역을 나눠서 “구역”을 분리한다.

예를 들어 /16 전체를 두 개의 서브넷으로 나눠보면:

Public Subnet: 10.0.1.0/24
Private Subnet: 10.0.2.0/24

여기서 10.0.1.0/24, 10.0.2.0/24 자체가 public/private인 건 아니고,
같은 사설 IP 대역 안에서 역할별로 구역을 나눈 것이라고 보면 된다.

그럼 “대체 public subnet / private subnet은 뭐가 다른데?”가 남는다.

public subnet이 public이 되는 기준: 라우팅(길)

여기서 헷갈렸던 게, IP처럼 public/private가 대역으로 딱 정해져있는 게 아니라는 점인데,
AWS에서 public subnet / private subnet은 주소 모양이 아니라 라우팅 테이블(어디로 나가는 길이 있냐)로 결정된다.

즉,

Public Subnet: 0.0.0.0/0 → IGW 라우트가 있음
Private Subnet: 0.0.0.0/0 → IGW 라우트가 없음 (보통 NAT로 감)

정리하면,

“public subnet”은 인터넷으로 나갈 수 있는 출구(IGW)로 가는 길이 열려있는 서브넷이다.

IGW

여기서 IGW(Internet Gateway)를 “등록”이라는 느낌으로 이해했었는데,
정확히는 VPC와 인터넷을 연결해주는 출입구/통로라고 보면 된다.

IGW를 만든다
IGW를 VPC에 연결(attach)한다

이건 “내 VPC가 인터넷과 연결될 수 있는 문을 만든다”는 느낌이다.
하지만 IGW만 붙인다고 외부가 자동으로 내 서비스를 찾는 건 아니고,
어떤 서브넷이 IGW로 나갈지(라우팅 테이블)를 따로 지정해줘야 한다.

그래서 Public Subnet 쪽 라우팅 테이블에:

0.0.0.0/0 → IGW

이걸 넣어주면 “이 서브넷은 인터넷으로 나갈 때 IGW로 나가라”가 된다.

여기까지가 public subnet “길 뚫기” 느낌임!

그럼 외부에서 내 EC2로 바로 접속 가능해질까?

아니다. 아직은 길만 뚫린 상태고, 외부에서 실제로 접속 가능하려면 추가 조건이 필요하다.

EC2에 Public IP(또는 Elastic IP)가 있어야 한다

EC2는 기본적으로 Private IP는 무조건 받음(10.0.x.x)
Public IP는 옵션으로 추가로 붙는 개념

Security Group에서 인바운드를 열어야 한다

예: HTTP(80), HTTPS(443), SSH(22) 등
안 열면 길이 있어도 못 들어옴

그래서 public subnet + public ip + security group 인바운드 허용이 되면
외부 사용자가 내 서비스에 접근할 수 있게 된다.

그리고 IP가 고정이어야 하면 EIP(탄력적 IP)를 발급해서 EC2에 연결하면 된다.

만약 DB나 WAS를 private하게 두고 싶다면?

DB나 내부 WAS처럼 외부에서 직접 접근하면 안 되는 애들은 Private Subnet에 둔다.

Private Subnet은 기본적으로

0.0.0.0/0 → IGW 라우트가 없음
그래서 인터넷과 직접 연결이 안 됨
즉 외부에서 먼저 들어오는 요청을 직접 받을 수 없음

여기까지가 private subnet이 private인 이유다.

근데 문제는:
private subnet에 있는 애들도 외부 API 호출(결제 API, 지도 API 등)은 해야함.
즉, “외부에서 들어오는 건 막되, 내부에서 나가는 건 허용”이 필요함.

이럴 때 쓰는 게 NAT이다.

NAT란?

사설 IP를 공인 IP로 변환해서 외부 네트워크와 통신할 수 있도록 해주는 기술

AWS에서는 보통 NAT Gateway를 사용한다.

여기서 내가 처음에 착각했던 부분이 있는데,
“NAT Gateway에 서비스를 올린다”가 아니라,

✅ NAT Gateway는 서비스를 호스팅하는 곳이 아니라 ‘트래픽 변환기’다.

NAT Gateway는 Public Subnet에 둔다.
그리고 NAT Gateway는 공인 IP(EIP)를 하나 가진다.

구조는 이런 느낌:

Private Subnet의 EC2(예: 10.0.2.15)가 인터넷으로 나가려 함
Private Subnet 라우팅 테이블에 0.0.0.0/0 → NAT Gateway 설정
그러면 인터넷으로 나가는 트래픽은 NAT Gateway로 감
NAT Gateway가 출발지 IP를 자기 공인 IP로 바꿔서 IGW를 통해 인터넷으로 보냄
응답은 다시 NAT로 돌아오고, NAT가 원래의 private EC2로 전달

즉,

Private Subnet은 IGW로 직접 나가는 게 아니라 NAT를 거쳐서 나간다.

근데 왜 외부에서는 private subnet으로 접근이 안 될까?

보면 NAT는 그냥 트래픽 변환기일 뿐이지, 외부 접근을 ‘막는 장치’는 아닌데,,

그리고 외부에서 접근이 안 된다면, 만약 db에서 외부 api 호출 후 응답을 받을 때 어떻게 그게 가능할까?

NAT의 동작 원리

핵심은, NAT는 “내부에서 먼저 시작된 연결”만 기억하고 변환해준다는 것이다.

내부 → 외부 요청

Private EC2 (10.0.2.15)가 외부 API 서버(1.2.3.4)에 요청을 보낸다고 해보자.

EC2 → NAT로 패킷 보냄
출발지: 10.0.2.15
목적지: 1.2.3.4
NAT가 출발지 IP를 자기 공인 IP로 바꿈
출발지: 3.100.200.10
목적지: 1.2.3.4
인터넷으로 나감

이때 NAT는 내부에 이런 걸 저장함:

3.100.200.10:포트 → 10.0.2.15:포트

즉, “이 연결은 내부 EC2가 시작한 것”이라고 기억해둠

외부에서 요청이 “먼저” 들어오면, NAT는 그걸 내부의 어떤 EC2로 전달해야 할지 모른다.
(NAT는 기본적으로 “내부에서 먼저 나간 요청의 응답”만 다시 돌려보내는 구조라서)

그래서 결과적으로,

Private Subnet의 EC2는 외부로 “나갈 수는” 있지만
외부에서 “직접 들어오는” 건 불가능하게 유지된다.

이게 private subnet + NAT의 핵심 목적임!

그럼 AWS에서 외부에서 Private EC2 접근하려면?

방법은 3가지

Bastion Host
ALB/NLB 같은 Load Balancer
포트포워딩 (AWS NAT Gateway는 지원 안 함)

AWS NAT Gateway는
포트포워딩 기능이 없다.

그래서 Private Subnet은 기본적으로 외부에서 직접 접근 불가.

이는 따로 블로그를 작성해보겠다.

Security Group / NACL은 어디서 역할이 갈리냐?

Security Group: 인스턴스 단위, Stateful
- 내가 가장 자주 만지는 규칙 (인바운드/아웃바운드)
- 요청을 허용하면 응답은 자동 허용
NACL: 서브넷 단위, Stateless
- 추가적인 방어선
- 인바운드/아웃바운드 각각 허용해줘야 함

대부분은 SG로 해결하고, 필요하면 NACL로 한 번 더 제어한다고 보면 된다.

정리하자면,

VPC에서 사설 IP “대역”을 정한다 (예: 10.0.0.0/16)
그 대역을 서브넷으로 나눈다 (public/private 용도 분리)
public subnet은 라우팅 테이블로 IGW로 나가는 길을 만든다
public subnet에 EC2를 두고 public ip + sg 설정하면 외부 접근 가능
private subnet은 IGW 직접 연결 없이 NAT를 통해 외부로만 나가게 만든다
그래서 DB/WAS 같은 건 private에 두고, 외부 노출은 막으면서도 외부 API 호출은 가능하게 만든다

우선 다음 글에서 AWS로 직접 실습을 해보겠다.

[네트워크] 네트워크 계층 공부 #02

코딩연습중 — Sun, 15 Feb 2026 15:37:38 +0900

1. Public IP와 Private IP

IPv4는 32비트로 약 43억 개의 주소를 가질 수 있다.
하지만 인터넷 기기 사용량이 급증해 전 세계에서 유일한 공인 IP 주소가 부족해지기 시작했다.

이를 해결하기 위Private IP(사설 IP)가 생겼다.

Public IP (공인 IP)

Public IP는

전 세계에서 유일한 주소
인터넷 상에서 직접 접근 가능
ISP(통신사)로부터 할당받음

예시: 8.8.8.8

공인 IP는 인터넷 라우터들이 인식하고 경로를 찾을 수 있는 주소이다.

Private IP (사설 IP)

Private IP는

내부 네트워크에서만 사용
인터넷에서 직접 접근 불가
여러 네트워크에서 중복 사용 가능

RFC1918에서 다음 대역을 사설 IP로 정의한다.

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

예를 들어 집 공유기에서:

192.168.0.2
192.168.0.3

이런 주소를 사용하는데,
이 IP는 전 세계 어디에서든 중복될 수 있다.

그럼 인터넷은 어떻게 연결될까?

내 노트북의 사설 IP가 192.168.0.5라고 하자.

이 주소는 인터넷에서 직접 접근할 수 없다.
그래서 공유기(또는 라우터)가 다음을 수행한다:

출발지 IP를 사설 IP → 공인 IP로 변환
응답이 오면 다시 공인 IP → 사설 IP로 변환

이 과정을 NAT(Network Address Translation) 이라고 한다.

Private IP는 내부 식별용

Public IP는 외부 통신용

2. Public Subnet과 Private Subnet

IP는 개별 주소 개념, subnet은 네트워크 단위 설계 개념

Public Subnet

Public Subnet은

인터넷 게이트웨이(IGW)와 연결된 라우팅 테이블을 가진다
내부 리소스가 공인 IP를 가질 수 있음
외부에서 직접 접근 가능

예시: 웹 서버, 로드밸런서

- 외부 인터넷과 직접 통신 가능한 네트워크 영역

Private Subnet

Private Subnet은

인터넷 게이트웨이와 직접 연결되지 않음
기본적으로 외부에서 접근 불가
필요하면 NAT를 통해 외부로 나감

예시: WAS 서버, DB 서버

- 외부에서 직접 접근하면 안 되는 내부 네트워크 영역

Public IP vs Public Subnet 차이

저렇게만 보면 헷갈려서 gpt한테 부탁해서 표를 만들어봤다.

	Public IP	Public Subnet
의미	개별 주소	네트워크 영역
역할	외부에서 직접 접근 가능	외부와 직접 연결된 네트워크
필요 조건	공인 IP 할당	IGW와 연결된 라우팅

Public Subnet 안에 있어도
공인 IP를 할당하지 않으면 외부에서 직접 접근은 불가함.

4. 실제 네트워크 설계 예시

일반적인 구조는 다음과 같다.

인터넷
   ↓
[Public Subnet]
   - Load Balancer
   - Bastion Host
   ↓
[Private Subnet]
   - WAS
   - DB

왜 이렇게 나누냐면:

보안
트래픽 분리
역할 분리

이 부분이 이해가 조금 어려워서 AWS를 예시로 이해해봤다.

https://codstudy.tistory.com/237

[네트워크]_AWS를 통한 네트워크 구조 이해

Private/Public IP, Subnet에 대한 이해가 조금 어려워서 AWS를 예시로 이해해봤다. 예를 들어 내가 A 웹 서비스를 개발해서 EC2 인스턴스에 배포하려고 할 때, 가장 먼저 해야할 것은 VPC를 만들고 내가 사

codstudy.tistory.com

[네트워크] 네트워크 계층 공부

코딩연습중 — Sat, 14 Feb 2026 17:09:57 +0900

1. IP 주소란?

인터넷에 연결된 모든 기기들이 서로 식별하고 통신하기 위해 필요한 고유한 주소이다.

내가 내 노트북에서 구글을 접속하려고 하면 구글에서 데이터를 제공해야 할 위치를 알아야한다. 이 내 노트북에 할당된 IP가 있어야 한다.

IP 주소의 핵심 역할은

1) 송신자, 수신자의 식별

2) 최적의 경로 설정(라우팅)

3) 패킷 단위의 통신

이라고 보면 된다. 3계층인 네트워크 계층에서는 데이터를 패킷 단위로 주고받게 된다.

각 패킷에는 출발지 IP, 목적지 IP가 포함된다.

IP의 종류로는 IPv4, IPv6이 있는데 주로 사용되는 건 IPv4이다.

이는 32비트로 이루어져 있다.

각 8비트씩 네 덩어리로 이루어져있다고 보면 된다.

IP 주소는 네트워크 부분, 호스트 부분으로 나뉜다.

옛날에는 IP 주소를 A,B,C 클래스 방식으로 구분해서 네트워크 부분의 길이를 고정해서 사용했다.(하지만 현재는 CIDR 방식이 주로 사용됨)

A 클래스 - 앞의 한 덩어리만 네트워크 부분

B 클래스 - 두 덩어리 네트워크 부분

C 클래스 - 세 덩어리 네트워크 부분

IPv4는 총 32비트이므로 약 43억개의 주소를 가질 수 있는데, 주소가 부족해지는 문제가 발생했다. 이를 해결하기 위해

사설 IP, NAT, CIDR, IPv6과 같은 개념이 등장했다.

CIDR

CIDR은

IP주소를 최대한 효율적으로 쓰기 위해 네트워크 부분 길이를 비트 단위로 조정을 하는 방법이라고 생각하면 될 것 같다.

서브네팅이 CIDR의 예시인데, 예전에는 서브네팅을 한 네번 봐도 제대로 이해를 못 해서,,, 어려웠는데 드디어 제대로 이해할 수 있게 됐다.

예제 1.
IP: 192.168.10.0
서브넷 마스크: 255.255.255.128 (/25)

IP는 32비트이고, 8비트씩 네 덩어리로 나뉜다.

/25는 앞에서부터 25비트가 네트워크 영역이라는 뜻이다.

이를 8비트 단위로 나눠보면:

8비트
8비트
8비트
1비트

즉, 앞의 세 옥텟(192.168.10)은 전부 네트워크 영역에 해당하고,
마지막 옥텟에서 맨 앞 1비트만 네트워크에 포함된다.

그래서 계산할 때는
앞의 192.168.10 부분은 고정이라고 보고,
마지막 옥텟만 집중해서 보면 된다.

마지막 옥텟의 남은 7비트가 호스트 영역이므로
2⁷ = 128개의 주소를 가질 수 있다.

따라서 다음과 같이 두 개의 네트워크로 나뉜다.

192.168.10.0 ~ 192.168.10.127
192.168.10.128 ~ 192.168.10.255

그런데 실제로 사용 가능한 호스트 주소는
첫 번째 네트워크: 192.168.10.1 ~ 192.168.10.126
두 번째 네트워크: 192.168.10.129 ~ 192.168.10.254 이다.
각 네트워크의 첫 주소는 네트워크 주소, 마지막 주소는 브로드캐스트 주소이기 때문이다.

근데 이게 서브넷 마스크랑 항상 비교해서 보기에는,,, 너무 길다. 그래서 보기 편하도록 한 게 prefix이다.

Prefix

prefix는 ip 뒤에 붙어서 /24, /16 이런 식으로 서브넷 마스크를 알려주는 방식이다. 서브넷 마스크 대신 1의 개수를 나타낸 것.

위와 같은 예시를 서브넷 마스크 대신 prefix로 나타내면

192.168.10.0 /25 이렇게 나타낼 수 있다. 이러면 IP 주소랑 서브네팅이 어떻게 되어있는지 한 눈에 파악할 수 있다.

다음에서는

Public/Private IP

Public/Private Subnet에 대해 다루겠다

https://codstudy.tistory.com/236

[네트워크] 네트워크 계층 공부 #02

1. Public IP와 Private IPIPv4는 32비트로 약 43억 개의 주소를 가질 수 있다.하지만 인터넷 기기 사용량이 급증해 전 세계에서 유일한 공인 IP 주소가 부족해지기 시작했다.이를 해결하기 위Private IP(사

codstudy.tistory.com