KDY

NGINX 란 무엇인가?

KDY0218 — Thu, 19 Feb 2026 21:12:26 +0900

AWS 로드밸런서 실습을 하면서 볼 수 있었던 NGINX 화면.

문득 내가 지금까지 이론과 실습을 공부하긴 했는데 과연 내가 이걸 정말 알고 있는 것일까 라는 생각이 들면서

시간적으로 여유가 있는 상황에서 다시 한번 재정립을 해볼 필요가 있다고 결정을 내렸다.

현재 IT 비즈니스 자체 솔루션을 개발하는 것을 넘어, 검증된 다양한 기술들을 유기적으로 엮어 고객에게 최적의 솔루션을 제안하고

이를 통해 비즈니스 가치를 창출하는 것이 핵심이다.

따라서, 이번 기회를 통해 지금까지는 간단한 이론 설명과 실습위주로 진행 했다면 이제는 확실하게 정의를 내릴 수 있게 정리를 해볼려고 한다.

NGINX 란 무엇인가?

가볍고 높은 성능을 자랑하는 오픈소스 웹서버 이자, 백엔드 시스템을 보호하고 트래픽을 지휘하는 리버스 프록시 및 로드밸러스 이다.

단순히 HTML 화면을 띄워주는 것을 넘어 현대의 복잡한 멀티 티어 웹 인프라에서 트래픽을 가장 먼저 맞이하는 '최전방 문지기' 역할을 수행한다.

높은 성능과 안정성을 가지고 있기에 당연히 현재 가장 많이 사용되고 있는 웹서버이다.

아파치(Apache) 같은 웹 서버와 비교하면 더 빠르고 가볍고, 대규모 애플리케이션 처리에 적합하다는 장점이 있다.

먼저 NGINX를 더 완벽하게 이해하기 위해 관련된 4가지의 용어를 알아보자.

클라이언트 " 요청하는 손님 "

식당에 들어가서 손님이 음식을 주문한다. 여기서 손님은 클라이언트 이다.

IT 네트워크 환경에서 서비스를 이용하기 위해 네트워크 너머로 요청을 보내는 주체를 뜻한다.

크롬과 사파리

크롬과 사파리.

위와 같은 웹 브라우저들이 바로 웹 생태계에서의 가장 대표적인 손님( 클라이언트 ) 들이다.

우리가 스마트폰으로 켜는 배달의민족 앱, 카카오톡 앱도 모두 클라이언트의 일종이라고 볼 수 있다.

웹서버 " 응답하는 제공자 "

클라이언트의 요청을 받아주는 웹 서버이다.

NGINX가 바로 이 웹 서버 생태계의 대장이라고 볼 수 있다.

손님( 클라이언트 )가 무언가를 요청하면, 그에 맞는 정적 파일(HTML 문서, css, 이미지 ) 등을 찾아서 응답 해주는 소프트웨어 입니다.

식당으로 치면 주문을 받고 만들어진 요리를 손님 테이블에 내어주는 안내데스크 직원, 홀서빙 직원과 같다.

현재 시장을 양분하고 있는 NGINX와 Apache가 있다. 이 외에도 마이크로소프트의 IIS , Lighttpd 등이 있다.

동작 흐름

요청: 사용자가 클라이언트( 크롬 , 사파리 ) 를 열고 리눅스/AWS의 IP 주소를 입력한 뒤 엔터를 친다.

클라이언트가 웹페이지 보여줘 라며 HTTP 통신을 보내게 된다.

수신 및 탐색: 인스턴스에 설치되어 있던 웹서버(NGINX)가 그 요청을 문 앞에서 받아낸다.

그리고 서버 내부 창고에 있던 index.html 파일을 꺼낸다.

응답: 웹서버(NGINX가 다시 클라이언트( 크롬 , 사파리 ) 에게 그 파일을 포장해서 던진다.

출력: 클라이언트 ( 크롬, 사파리 )가 받은 파일을 해석해서 우리 눈앞에 화면을 띄워준다.

WAS ( Web Application Server ) " 요리하는 주방장 "

웹서버 ( NGINX ) 가 만들어져 있는 정적 파일( HTML, 이미지 ) 을 가져다 주는 홀서빙 직원 이라면,

WAS는 고객의 주문에 맞춰 그때그때 지지고 볶아서 새로운 결과물을 만들어내는 주방장 이다.

대표적인 WAS 톰캣

사용자가 " 내 장바구니 목록 보여줘 " 또는 " 아이디와 비밀번호로 로그인해줘 " 라고 요청하면, 이건 미리 만들어둘 수 없는 데이터이다.

이때 WAS가 나서서 뒷단의 데이터베이스를 뒤지고, 비즈니스로직을 연산한 뒤 그 결과를 동적으로 만들어서 웹 서버에게 넘겨준다.

왜 웹서버와 WAS를 분리해서 사용해야할까?

1. 서버 부하 방지 : 무거운 비즈니스 로직을 처리해야하는 WAS가 단순 이미지 파일까지 서빙하게 두면 비효율적이다.

정적 서빙은 가벼운 NGINX에게 맡겨 역할을 분담하면 처리 속도가 훨씬 빨라진다.

2. 보안 강화 : 데이터베이스와 직접 연결된 WAS의 실제 IP를 외부에 노출하지 않고, 앞단의 NGINX가 대리인으로 트패픽을 받아줌으로써 보안을 크게 높일 수 있다.

DB ( Database ) " 핵심 식자재 창고 겸 금고 "

주방장 ( WAS )가 아무리 요리를 잘해도, 요리할 '식재료'와 '비법 레시피'가 없다면 아무것도 만들 수 없을 것이다.

웹서버(NGINX)와 WAS(톰캣)은 기본적으로 데이터를 영구적으로 기억하지 않는 휘발성 일꾼들이다.

반면, DB는 서비스에 필요한 모든 핵심 데이터가 영구적으로 안전하게 보관되는 단 하나의 거대한 창고이자 금고이다.

사용자가 "내 장바구니 목록 보여줘"라고 요청하면, 주방장(WAS)은 가장 먼저 창고(DB)로 달려가 해당 고객의 장바구니 데이터를 꺼내 온 뒤 요리를 시작하는 구조이다.

대표적인 DB로는 MySQL, Oracle 그리고 클라우드 환경에서 널리 쓰이는 AWS RDS 등이 있다.

기업 인프라에서 DB는 서비스의 명운이 달린 가장 소중한 자산이다.

그렇기 때문에 무중단 서비스를 위해 클라우드 리전 간 데이터베이스 마이그레이션 작업을 꼼꼼히 수행하는 등 가장 공들여 관리하는 곳이기도 하다.

DB는 가장 민감한 정보가 담긴 '심장'이다. 절대 외부 인터넷과 직접 맞닿게 두어서는 안된다.

현대 아키텍처는 Web(NGINX) - WAS - DB라는 3중 방어선(3-Tier)을 구축합니다.

1선: NGINX가 맨 앞단에서 최전방 문지기(리버스 프록시) 역할을 하며 트래픽을 선별합니다.
2선: WAS는 외부에서 직접 접근할 수 없는 내부망에서 안전하게 비즈니스 로직을 처리합니다.
3선: DB는 가장 깊고 안전한 곳에서 오직 인증된 WAS하고만 소통하도록 철저히 격리해 둡니다.

1선: NGINX (Public Zone / 최전방 문지기)

가장 바깥쪽에서 인터넷과 직접 맞닿아 있는 구역입니다. 클라우드 환경에서는 외부와 통신이 가능한 퍼블릭 서브넷(Public Subnet)에 위치합니다.

진짜 주소 숨기기 (Reverse Proxy): 외부의 모든 사용자는 NGINX의 공인 IP(Public IP)로만 접속합니다. 해커가 아무리 스캔을 돌려도 뒤에 있는 WAS나 DB의 진짜 주소(Private IP)는 절대 알 수 없습니다. NGINX가 철저하게 내부망을 캡슐화하여 숨겨주기 때문입니다.
SSL 암호화 해독 (SSL Termination): 우리가 웹사이트에 접속할 때 쓰는 안전한 HTTPS(자물쇠 마크) 트래픽의 암호를 NGINX가 맨 앞단에서 풀어서 확인합니다. 뒷단의 WAS는 암호 해독에 힘을 뺄 필요 없이 비즈니스 로직에만 집중할 수 있습니다.
불량 손님 차단: 비정상적인 트래픽이나 과도한 요청이 들어오면, 뒷단으로 넘기기 전에 NGINX 선에서 연결을 끊어버립니다(Drop).

2선: WAS (Private Zone / 내부망의 브레인)

여기서부터는 외부 인터넷에서 절대 직접 들어올 수 없는 닫힌 공간, 즉 프라이빗 서브넷(Private Subnet)입니다.

엄격한 출입 통제: WAS 서버의 방화벽(Security Group 등)은 "오직 앞단의 NGINX가 보내는 트래픽만 허용한다"라는 규칙이 걸려 있습니다. 해커가 NGINX를 우회해서 WAS로 직접 침투하려는 시도 자체를 네트워크 단에서 원천 차단합니다.
비즈니스 로직의 격리: 로그인 처리, 장바구니 결제 등 복잡한 연산이 일어나는 공간입니다. 만약 최전방의 NGINX가 뚫리거나 디도스 공격으로 마비되더라도, 2선인 WAS가 분리되어 있기 때문에 내부 시스템 전체가 장악당하는 시간을 벌거나 피해를 최소화할 수 있습니다.

3선: DB (Deep Private Zone / 최심부의 금고)

인프라 아키텍처에서 가장 깊고, 가장 폐쇄적인 공간입니다.

오직 WAS와만 소통: DB의 방화벽은 "오직 인증된 WAS 서버의 특정 포트(예: MySQL의 3306 포트)에서 오는 쿼리 요청만 허용한다"라고 설정되어 있습니다. 앞단의 NGINX조차도 DB에는 직접 접근할 수 없습니다.
망 분리의 완성: 이처럼 Web, WAS, DB를 각각 다른 네트워크 망(서브넷)에 쪼개어 배치하는 것을 '망 분리(Network Segmentation)'라고 합니다. 해커가 1선(Web)을 뚫고 들어오더라도, 2선(WAS)과 3선(DB)으로 넘어가기 위해(횡적 이동, Lateral Movement) 또 다른 네트워크 방화벽과 인증을 계속 뚫어야 하는 험난한 성벽 구조를 만드는 것입니다.

요약!

Web-WAS-DB를 3계층으로 분리하는 것은 단순히 서버의 역할을 나누는 것을 넘어, 망 분리를 통해 보안의 깊이를 더하는 심층 방어 전략이다. 인터넷에 노출된 퍼블릭 망에는 NGINX만 배치하여 리버스 프록시로 활용하고, 실제 데이터가 처리되고 저장되는 WAS와 DB는 외부 접근이 철저히 차단된 프라이빗 망에 겹겹히 숨겨둠으로써 기업의 핵심 자산을 안전하게 보호 한다.

조금 더 쉽게!

왜 우리는 굳이 식당을 3구역으로 나눌까

지금까지 살펴본 NGINX와 3-Tier 아키텍처를 한마디로 정의하자면, '소중한 금고를 지키기 위해 겹겹이 성벽을 쌓는 과정' 이라고 할 수 있다.

1. NGINX는 '유능한 문지기' 입니다. 손님을 가장 먼저 맞이하며, 불량 손님을 걸러내고 복잡한 길 안내(리버스프록시)를 도맡는다.

덕분에 뒤에 있는 일꾼들은 자기 업무에만 집중할 수 있다.

2. 역할을 나누면 '안전' 해진다. 손님이 보는 앞에 주방장(WAS)과 금고(DB)를 두지 않는 것과 같다. 문지기 뒤로 주방을 숨기고, 그보다 더 깊숙한 곳에 금고를 숨겨서 외부 사람이 함부로 접근할 수 없게 만드는 것이 핵심이다.

3. 효율과 보안, 두마리 토끼를 잡는다. 가벼운 일(이미지 전달)은 문지기가 처리하고, 복잡한 요리(비즈니스 로직)는 주방장이 전담하니 속도가 빨라진다. 또한, 설령 문 앞이 시끄러워져도(디도스 공격 등) 안쪽의 주방과 금고는 안전하게 보호받을 수 있다.

결국 NGINX란 단순히 화면을 보여주는 도구를 넘어, 우리 서비스라는 거대한 성을 지키는 가장 든든한 '최전방 파수꾼'인 셈이다.

OSPF 이론 정리__[ GNS3 ]

KDY0218 — Sun, 1 Feb 2026 17:17:07 +0900

OSPF란 무엇인가?

링크상태 라우팅 프로토콜의 대표적인 종류로, 네트워크의 구조를 정확하게 파악하여 목적지까지의 가장 효율적인 경로를 계산하는 프로토콜이다.

대규모 기업 네트워크나 데이터 센터에서 가장 널리 사용되는 '내부 라우팅 프로토콜'이며, '링크상태' 알고리즘을 사용하여 네트워크의 모든 정보를 파악한 뒤, 가장 빠른 길을 찾아내는 똑똑한 길잡이 역할을 한다.

OSPF를 사용하는 이유

복잡한 네트워크 환경에서도 효율적이고 안정적인 경로 선택을 가능하게 하는 링크 상태 라우팅 프로토콜이다.

1. 링크 상태 데이터베이스(LSDB)와 동일한 네트워크 맵 공유

OSPF의 가장 큰 특징은 각 라우터가 자신의 연결 정보를 담은 LSA를 생성하여 이웃에게 알린다는 점이다.

이 정보는 해당 영역(Area) 내의 모든 라우터에게 전달되어, 결과적으로 모든 라우터는 전체 네트워크 구조를 담은 동일한 LSDB를 갖게 된다.

2. 독릭적인 최적 경로 계산 (SPF 알고리즘)

모든 라우터는 공유된 LSDB(네트워크 지도)를 바탕으로 SPF알고리즘을 각자 실행하여 목적지까지의 최적 경로를 독립적으로 계산한다. 이를 통해 네트워크를 더 잘 이해하고 관리할 수 있지만, 정보를 다루는 양이 많아 CPU와 메모리 리소스 사용량이 높다는 특징이 있다.

3. 영역(Area) 분할을 통한 효율적 관리

네트워크 규모가 커지면 LSDB가 비대해지고 경로 계산에 많은 시간이 소모된다.

OSPF는 이를 방지하기 위해 네트워크 여러 영역으로 나누어 관리한다.

4. DR 및 BDR 선발을 통한 트래픽 최적화

이더넷과 같은 브로드캐스트 네트워크 환경에서는 모든 라우터가 서로 LSA를 교화하면 트래픽이 과도하게 발생한다.

이를 최적화하기 위해 네트워크의 반장 역할을 하는 DR 과 부반장인 BDR을 선발한다.

* 일반 라우터들은 오직 DR/BDR과만 정보를 주고 받으며 네트워크 부하를 줄인다.

* 선발은 Priority 값이나 Router-ID 가 높은 순서대로 결정된다.

5. 대역폭 기반의 메트릭 : cost

OSPF는 경로의 우열을 가릴 때 Cost(비용) 이라는 메트릭을 사용한다.

* 계산 방식 : 기본적으로 참조 대역폭 / 인터페이스 대역폭 공식을 따른다.

* 기본 참조 대역폭은 100Mbps이므로, 기가비트 이상의 환경에서는 차별화를 위해 모든 라우터의 참조 대역폭을 동일하게 수정하거나 인터페이스에서 직접 Cost를 지정하여 관리하는 것이 좋다.

6. 빠른 수렴 시간

OSPF는 Hello 패킷(기본10초)을 교환하며 이웃 상태를 체크하고, Dead 주기(기본40초) 내에 응답이 없으면 즉시 변화를 감지하여 경로를 재계산한다. 이를 통해 네트워크 변화에 매우 신속하게 대응할 수 있다.

OSPF 동작 원리

1단계: 이웃 관계 형성 및 DR/BDR 선발

먼저 라우터는 Hellow 패킷을 교환하여 인접한 라우터를 찾고 이웃 관계를 맺는다.

세부 상태: Down → Init → 2-way 상태를 거친다.

DR/BDR 선발: 이더넷과 같은 브로드캐스트 네트워크에서는 효율적인 LSA 교환을 위해 DR과 BDR을 선발합니다

인접성 형성: 일반 라우터(DROther)는 모든 라우터와 정보를 주고받지 않고, 오직 DR/BDR과만 완전한 인접 관계를형성하여 네트워크 부하를 줄입니다.

2단계: LSA 교환 및 데이터베이스(LSDB) 동기화

이웃과 연결되면 각 라우터는 자신의 링크 상태 정보인 LSA를 생성하여 광고한다.

세부 상태: Exstart → Exchange → Loading 상태를 거친다.

플러딩(Flooding): LSA 정보는 영역(Area) 내의 모든 라우터에게 전달되어, 모든 라우터가 동일한 LSDB, 즉 전체 네트워크 지도를 갖게 된다.

동기화 유지: LSA는 30분의 Aging Time이 있으며, 시간이 지나거나 네트워크 변화가 생기면 다시 플러딩 되어 최신 상태를 유지하게 된다.

3단계: 최적 경로 계산 및 라우팅 테이블 등록

데이터베이스 동기화가 완료되면 각 라우터는 독립적으로 경로를 계산한다.

세부 상태: Full 상태에 도달한다.

SPF 알고리즘 실행: 공유된 LSDB 맵을 바탕으로 SPF알고리즘을 실행하여 각 목적지까지의 가장 짧은 경로를 찾아낸다.

메트릭 적용: 경로의 우열은 Cost(비용) 값을 기준으로 결정하며, 이 결과가 최종적으로 라우팅 테이블에 삽입되어 실제 데이터 전송에 사용된다.

효율적인 운영을 위한 추가 메커니즘

영역(Area) 분할: 네트워크 규모가 커지면 LSDB가 비대해지고 리소스 소모가 심해지므로, 이를 여러 영역으로 나누어 관리함으로써 경로 계산의 효율성을 높인다.

주기적인 상태 확인: Hello 주기(10초)와 Dead 주기(40초)를 사용하여 이웃 라우터의 생존 여부를 지속적으로 확인하고, 변화에 빠르게 반응한다.

멀티캐스트 주소 사용: 효율적인 정보 전달을 위해 일반 라우터는 224.0.0.6 주소로 DR/BDR에게 정보를 보내고, DR은 224.0.0.5 주소로 모든 라우터에게 업데이트를 전달한다.

OSPF의 7가지 상태 변화

라우터가 서로를 인식하고 정보를 완전히 공유하기까지 거치는 세부 단계.

Down: 아직 아무 정보도 주고받지 않은 상태.
Init: 상대방으로부터 Hello 패킷을 받은 상태.
2-Way: 서로의 Hello 패킷에 각자의 ID가 확인된 상태. (DR/BDR 선출이 여기서 일어납니다.)
Exstart: 정보를 주고받기 위해 누가 주도권(Master/Slave)을 가질지 결정하는 상태.
Exchange: 데이터베이스의 요약본(DBD)을 주고받는 상태.
Loading: 요약본 중 나에게 없는 상세 정보를 요청(LSR)하고 전송(LSU)받는 상태.
Full: 모든 정보 동기화가 완료된 상태.

핵심 용어

Router ID : OSPF 네트워크 내에서 라우터를 식별하는 고유 이름

Area 0 : Backbone Area라고 불리며, 모든 다른 Area는 반드시 여기에 연결되어야 한다.

DR / BDR : 중복된 정보 교환을 줄이기 위해 선출된 반장과 부반장 라우터

Metric(cost) : 100bps / 대역폭으로 계산, 값이 작을수록 더 좋은 경로.

VTP 기반 VLAN 구성 및 RSPAN_GNS3

KDY0218 — Sat, 17 Jan 2026 11:30:20 +0900

서론

GNS3 에서 구축을 했다.

현대 네트워크 인프라는 단순히 장치들을 연결하는 것을 넘어, 효율적인 관리, 강력한 보안, 그리고 실시간 모니터링이 유기적으로 결합되어야 한다.
이번 포스팅에서는 이전에 다뤘던 VTP 심화 버전으로 시스코 장비를 활용하여 실제 기업 환경과 유사한 VTP 기반의 네트워크 토폴로지를 구축하고, 데이터 전송부터 보안 설정, 인터넷 연결, 그리고 원격 모니터링까지 한번 다뤄볼려고 한다.

목표

VTP를 통한 효율적인 VLAN 관리
보안 중심의 네트워크 설계
라우팅 및 외부 연결성 확보
RSPAN을 이용한 중앙 집중식 모니터링
사용되는 이론 및 기술 배경 이해.

주요 이론 및 기술

VTP : 스위치 네트워크 내에서 VLAN 정보를 자동으로 전파하는 프로토콜

DTP : 스위치 간 트렁크 연결을 자동으로 협상한다.

상황에 따라 Desirable 과 Auto 모드를 조합하여 안정적인 트렁크 구간을 생성한다.

Native VLAN : 기본값인 VLAN 1을 그대로 사용하지 않고, 보안을 위해 스위치 간 연결과 라우터 연결의 Native VLAN을 각각 분리하여 설정한다.

Inter-VLAN Routing : 각기 다른 VLAN에 속한 PC들이 서로 통신할 수 있도록 라우터에 서브 인터페이스를 생성한다.

각 서브 인터페이스는 해당 VLAN의 게이트웨이 역할을 수행하며 802.1Q 캡슐화를 통해 드래픽을 처리한다.

ACL : 특정 IP나 포트에 대한 접근을 제어한다.

예를 들어 협력업체가 내부의 특정 웹서버에만 접근할 수 있도록 화이트리스트 기반의 보안 정책을 수립한다.

NAT/PAT : 내부의 사설 IP 주소를 공인 IP주소로 변환하여 외부 인터넷 통신이 가능하도록 하며, 여러 장치가 하나의 공인 IP를 공유하는 PAT 방식을 주로 사용한다.

RSPAN : 일반적인 SPAN과 달리, 특정 스위치의 트래픽을 RSPAN VLAN에 실어 다른 스위치에 연결된 분석 장비로 전달하는 기술이다.

장비별 설정 로그

SW1 [ SERVER ] 설정

conf t 

[ VTP SERVER 설정 ] 
vtp domain cisco
vtp password ccnp
vtp mode server
vtp pruning
vtp version 2

[ VLAN 생성 ] 
vlan 10,20,30,40,50
vlan 999
name Native_VLAN
vlan 60 
 name Partner_Net
vlan 70
 name RSPAN_VLAN
 remote-span
 
 [ SW2 방향 TrunK 설정 ]
int g0/0
switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
switchport trunk native vlan 999
switchport trunk allowed vlan 10,20,30,40,50,999
switchport trunk pruning vlan 10,20,30,40,50

[ SW3 방향 Dynamic Desirable 설정 ]
int g0/1
switchport trunk encapsulation dot1q
switchport mode dynamic desirable
switchport trunk native vlan 999
switchport trunk allowed vlan 10,20,30,40,50,999

[ SW4 방향 Dynamic Desirable 설정 ]
int g0/2
switchport trunk encapsulation dot1q
switchport mode dynamic desirable
switchport trunk native vlan 999
switchport trunk allowed vlan 10,20,30,40,50,60,70,999

[ 라우터 방향 포트 설정 ] 
int g0/3
switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
switchport trunk native vlan 10
switchport trunk allowed vlan 10,20,30,40,50,60,70,999

SW2 [ client ] 설정

도메인 패스워드는 동일하게 설정.

conf t

vtp mode client
vtp version 2

[ SW1 연결 포트 Trunk 설정 ]
int g0/0
switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
switchport trunk native vlan 999
switchport trunk allowed vlan 10,20,30,40,50,999

[ PC1 연결 포트 ]
int g0/1
switchport mode access
switchport access vlan 10

[ PC2 연결포트 ]
int g0/2
switchport mode access
 switchport access vlan 20

SW3 [ client ] 설정

도메인 패스워드는 동일하게 설정.

conf t

vtp mode client
vtp version 2

[ SW1 연결 포트 Dynamic Desirable 설정 ]
int g0/1
switchport trunk encapsulation dot1q
switchport mode dynamic desirable
switchport trunk native vlan 999
switchport trunk allowed vlan 10,20,30,40,50,999

[ PC3 연결 포트 ]
int g0/2
switchport mode access
switchport access vlan 30

[ Toolbox 연결 포트, 웹서버 vlan 40 ]
int g0/3
switchport mode access
switchport access vlan 40

SW4 [ client ] 설정

도메인 패스워드는 동일하게 설정.

conf t

vtp mode client
vtp version 2

[ SW1 연결포트 ]
int g0/2
switchport trunk encapsulation dot1q
switchport trunk native vlan 999
switchport trunk allowed vlan 10,20,30,40,50,60,70,999
negotiation auto

[ SW5 연결포트 ] 
int g0/3
switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport nonegotiate
 switchport trunk native vlan 999
 switchport trunk allowed vlan 10,20,30,40,50,60,70,999
 
[ PC5 연결포트 ]
int g0/0
switchport mode access
switchport access vlan 50

[ 웹텀 연결 포트 ]
int g0/1
switchport mode access
switchport access vlan 50

SW5 [ VTP Transparent ] 설정

도메인 패스워드 동일하게 설정,

독립적으로 동작하므로, VLAN 60,70을 직접 만들어줘야 한다.

conf t

vtp mode transparent
vtp version 2

[ VLAN 생성 ]
vlan 60
 name Partner_Net
vlan 70
 name RSPAN_VLAN
 remote-span <- RSAPN VLAN 설정 중요!
 vlan 999 
 name Native_VLAN
 
 
[ SW4 연결포트 ]
int g0/3
switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
switchport trunk native vlan 999
switchport trunk allowed vlan 10,20,30,40,50,60,70,999

[ 협력업체 웹텀 연결 포트 ]
int g0/1
switchport mode access
switchport access vlan 60
 
[ RSPAN 설정 SOC 장비 연결 ] 
conf t
monitor session 1 source remote vlan 70
monitor session 1 destination interface g0/2

R1 설정

NAT 설정 및 DHCP 풀 받아오는건 생략.

conf t

[ VLAN 10 - native VLAN ] 
interface Gi0/3.10
encapsulation dot1Q 10 native
ip address 10.1.1.126 255.255.255.128
ip nat inside

[ VLAN 20 ]
interface Gi0/3.20
encapsulation dot1Q 20
ip address 10.1.1.190 255.255.255.192
ip nat inside

[ VLAN 30 ]
interface Gi0/3.30
encapsulation dot1Q 30
ip address 10.1.1.222 255.255.255.224
ip nat inside

[ VLAN 40 ]
interface Gi0/3.40
encapsulation dot1Q 40
ip address 10.1.1.238 255.255.255.240
ip nat inside

[ VLAN 50 ]
interface Gi0/3.50
encapsulation dot1Q 50
ip address 10.1.1.246 255.255.255.248
ip nat inside

[ VLAN 60 - 협력업체]
interface Gi0/3.60
encapsulation dot1Q 60
ip address 10.1.1.250 255.255.255.252

SW1 설정 추가 [ RSPAN 설정 ]

소스(Source)를 VLAN 10, 30으로 지정
monitor session 1 source vlan 10 , 30

목적지(Destination)를 RSPAN VLAN 70으로 지정
monitor session 1 destination remote vlan 70

R1 설정 추가 [ 협력 업체 VLAN 60 ACL 설정 ]

conf t

ip access-list extended VLAN60_Security
permit tcp host 10.1.1.249 host 10.1.1.225 eq 80
deny ip any any log

협력업체 pc -> 웹서버 80포트 허용 (WWW)
나머지는 전부 로그를 남기고 차단한다.

interface Gi0/3.60
ip access-group VLAN60_Security in
협력업체 pc에서 출발한 데이터가 라우터로 들어오자마자 바로 검문한다.
라우터 내부로 들어오기도 전에 입구컷을 시키므로 성능 부하를 줄이고 보안성을 높인다.

최종결과

전체 설정을 확인하기에는 내용이 너무 많아지므로,

선별했습니다.

SOC 외부통신 감지.

sw1 RSPAN VLAN 설정

sw5 RSPAN VLAN 설정

우분투 SOC에서 tcpdump 명령어를 통해 감시가 가능하다.

tcpdump -X 'host 8.8.8.8 or tcp port 80 or tcp port 443'

PC 1 -> 외부통신 연결 시도

SOC tcpdump 명령어를 통해 출력 완료.

협력업체 내부 툴박스 VLAN 60 ACL 설정 확인

툴박스 정보.

ICMP는 차단되고 WWW 80번 포트만 연결된 모습을 볼 수 있다.

복잡한 대규모 네트워크 토폴로지를 처음으로 구성하고 블로그에 공유하게 되었다. 단편적인 기초 실습과 달리, 복합적인 설정을 다루다 보니 작업의 우선순위와 절차를 설계하는 데 어려움이 있었다. 기능 구현은 완료했지만, 과정 중 실시간으로 문서화를 하지 않은 점이 가장 큰 실수였다. 후에 적용된 명령어를 찾아 복기하느라 불필요한 시간이 소요되었다.
이번 시행착오를 통해, 다음 프로젝트부터는 설정 단계마다 로그를 남기고 기록하는 습관을 들여야겠다고 다짐한다.

AWS DMS Cross-Region 마이그레이션 실습_ [ AWS ]

KDY0218 — Wed, 14 Jan 2026 22:31:57 +0900

서론

AWS를 처음 접해본 사람으로서 천천히 교재와 수업자료를 비교해가며 따라가본다.
물리적으로 떨어진 두 리전 간의 데이터를 안전하게 옮기는 것,
수작업으로 데이터를 백업하고 복원하는 번거로움 대신 AWS DMS 라는 기능을 활용하여
기술 변화의 혁신을 알아보았다.

본 포스팅에서는 AWS의 EC2(IaaS) 환경에서 운영 중이던 MariaDB 데이터를, 운영 편의성이 높은 Amazon RDS(PaaS) 환경으로 마이그레이션하는 과정을 다룬다. 특히 AWS DMS를 활용하여 인프라 구축부터 데이터 복제, 정합성 검증까지의 과정을 엔지니어링 관점에서 기록했다.

목표

도쿄 리전에 구축된 DB를 서울 리전의 관리형 DB(RDS)로 이관.
서로 다른 리전 간의 네트워크 및 보안 그룹 구성.
AWS DMS의 3요소 ( 복제 인스턴스 , 엔드포인트, 태스크 ) 를 활용한 마이그레이션 파이프라인 구축.
데이터 유실 없이 원본 데이터가 타켓 DB로 완벽하게 복제되었는지 검증해보자.

**AWS DMS *Database Migration Service**

관계형 데이터베이스, 데이터 웨어하우스, NoSQL 데이터베이스 등 다양한 유형의 데이터 저장소를 쉽고 안전하게 마이그레이션하도록 돕는 AWS의 관리형 서비스.

마이그레이션 중에도 소스 데이터베이스를 계속 사용할 수 있어 애플리케이션 가동 중단 시간을 최소화할 수 있다.

AWS DMS를 선택하는 이유

1. 강력한 보안 (Security)

IAM 권한 관리, SSL/TLS 암호화, AWS Secrets Manager를 연동하여 마이그레이션 전 과정에서 데이터를 철저하게 보호한다.

2. 최소한의 다운타임 (Minimal Downtime)

데이터가 이동하는 동안에도 소스 시스템(원본 DB)을 정상적으로 운영할 수 있어, 서비스 중단을 최소화할 수 있다.

3. 데이터 무결성 및 복원력 (Integrity & Resiliency)

다중 AZ(Multi-AZ) 이중화와 체크포인트 복구 기능을 통해 장애 발생 시에도 안정적.
데이터 검증(Validation) 프로세스를 통해 데이터 손실을 방지하고 불일치를 자동으로 해결.

4. 비용 효율성 (Cost-Efficiency)

사용한 만큼만 지불하는 시간당 요금제와, 불필요한 용량을 줄여주는 서버리스(Serverless) 확장을 통해 비용을 절감할 수 있다.

1. 도쿄 지역 인스턴스 생성 (소스 데이터베이스 준비)

보안그룹은 도쿄 리전에 3개를 추가해서 적용시켜주자.

인스턴스 유형은 t3.micro로 설정해보자.

vpc는 기본으로 선택.

서브넷은 위 그림과 똑같이 선택한다.

1-1 도쿄 지역 인스턴스 연결 후 mysql 작업

도쿄지역 연결 후

sudo dnf install mariadb105-server -y -> 설치
sudo systemctl start mariadb -> 실행
mysql -> 접속

mysql 접속.

접속 후 간단한 DB 랑 테이블 list 만들어보자.

예시

MariaDB [(none)]> CREATE DATABASE mproject;
MariaDB [(none)]> use mproject;
MariaDB [mproject]> CREATE TABLE list (
    -> Name VARCHAR(10),
    -> Number INT PRIMARY KEY NOT NULL,
    -> Date DATE );
    
    MariaDB [mproject]> DESC list;  -> 생성된 테이블 리스트 확인해보자.

생성된 테이블 리스트에 값을 넣어주자.

MariaDB [mproject]> INSERT INTO list VALUES ('Kim', 546245, '2026-01-13');
MariaDB [mproject]> INSERT INTO list VALUES ('Lee', 567336, '2026-02-15');

MariaDB [mproject]> SELECT * FROM list; -> 설정 확인해보자

1-2 도쿄 인스턴스 안에서 만든 mysql을 퍼블릭 아이피로 접속

새로운 데이터베이스 사용자를 만들고, 사용자에게 권한을 부여한 뒤, 외부에서 접속 해보자.

MariaDB [mproject]> CREATE USER dmsuser@'%' IDENTIFIED BY '1234';
MariaDB [mproject]> GRANT ALL ON mproject.* TO dmsuser@'%';

2. 서울 리전에서 RDS 생성 (타켓 데이터베이스 생성)

서브넷 그룹 , 파라미터 그룹, 옵션그룹 생성해준다.

가용영역은 퍼블릭으로 2개 선택해준다.

2-1 데이터 베이스 생성

보안그룹 RDS 생성

첨부한 스크린샷과 같이 설정을 하자.

퍼블릭 액세스 선택 '예'로 설정.

자격증명관리 '자체관리'

템플릿은 프리티어가 없으면 샌드박스로 해서 설정하자.

조금 기다리면 생성 완료가 된다.

3. DMS 생성

데이터를 최종적으로 전송받을 목적지인 서울 리전에서 생성.

3-1 데이터를 실어나르는 '트럭' 역할을 하는 "복제 인스턴스"를 서울 리전에서 배치해서 도쿄의 데이터를 서울로 끌어오는 구조를 만든다.

DMS 복제 인스턴스가 서울의 어느 네트워크를 사용할지 지정하기 위해 서브넷 그룹을 먼저 만들어야 된다.

3-2 소스 엔드포인트 등록 ( 도쿄 EC2의 퍼블릭 IP와 접속 정보를 입력. 데이터를 가져올 곳을 등록 )

캡쳐화면에 없는 정보들은 디폴트로 두는데

하단부분 SSL은 없음으로 체크하자.

3-3 대상 엔드포인트 생성 ( 서울 RDS의 정보를 입력하여 데이터 넣을 곳을 등록 )

서버이름에는 서울 RDS 엔드포인트 주소정보를 넣어주자.

3-4 복제 인스턴스 생성 (데이터를 실제로 실어 나르는 가상 컴퓨터를 구축하는 작업)

복제 인스턴스는 생성하는데 시간이 좀 걸린다. 참고하자!

3-5 복제 인스턴스 생성 완료 확인 후 태스크 생성. (DMS 위치)

태스크 로드 완료 확인.

4. 데이터 확인을 위해 리눅스 서버 A에서 서울 RDS 엔드포인트로 접속 시도.

RDS 엔드포인트로 접속.

리눅스 서버 A 접속 후 엔드포인트로 접속.

mysql -h [ 엔드포인트 주소 ] -p -u admin

데이터 조회를 해본다. ( 도쿄 리전에서 넣었던 데이터인 'kim' 'Lee' 행이 그대로 조회되는 것을 확인한다 )

결론

도쿄지점에서 장부를 작성하고(DB 설정)

서울본사에서 새 금고를 마련한 뒤(RDS 설정)

장부를 실어 나를 특수 운반 트럭( DMS 복제 인스턴스) 과 양쪽 지점의 약도(엔드포인트)를 준비해서

사고 없이 안전하게 장부를 운반(태스크 실행) 해 온 것이다.

이번 실습을 통해서 도쿄 리전의 EC2 기반 데이터베이스를 서울리전의 RDS로 성공적으로 이관해보았다.

DMS를 활용한 이번 실습은 단순한 데이터 이동을 넘어 다음과 같은 의의를 가진다.

1. 관리 포인트의 최소화. 기존 EC2 환경에서는 OS와 DB를 직접 관리해야 했으나, 완전 관리형 서비스인 RDS로 전환함으로써

백업, 보안패치, 스케일링과 같은 운영 리소스를 AWS에 위임하여 비즈니스 로직에 더 집중할 수 있는 환경을 마련했다.

2. 물리적 거리를 극복한 서비스 성능 최적화. 기존에는 데이터가 도쿄에 있어 한국 사용자가 접속할 때마다 물리적인 지연 시간이 발생했다. 이번 실습을 통해 데이터를 주 사용자가 위치한 서울 리전으로 이관함으로써, 네트워크 거리를 단축시켜 로딩 속도를 개선하고 사용자 경험을 향상시킬 수 있는 환경을 구축했다.

Goethe said

KDY0218 — Wed, 14 Jan 2026 17:10:01 +0900

everything.

Reflections of a Conflicted Heart

KDY0218 — Tue, 13 Jan 2026 19:59:02 +0900

무엇을 해야 할지 모르겠는 건 아니다.

다만 내 생각이 어디에 머물러 있는지 모를 뿐이다.

머리로는 무엇이 우선인지 명확히 알고 있지만,

새해라는 타이틀이 무색하게도 나는 여전히 어리석은 선택을 반복하고 있다.

끊임없이 '만약'을 가정하며 지난날을 되감기 한다. "그때 다른 선택을 했더라면 잘 될 수 있었을까?"

하지만 깨닫는다. 어차피 가지 않은 길은 모두 후회로 남을 뿐이라는 것을.

그렇다면 차라리 마음이 시키는 대로,

설령 그것이 시간과 돈을 낭비하는 일이라 할지라도 내 마음이 향하는 곳에 나를 던지는 게 맞지 않을까.

2026년의 시작이 조금은 초라해 보인다.

먼 훗날 지금을 되돌아보면 비웃음을 살 만큼 바보 같은 모습일지도 모른다.

하지만 지금은 욕심내지 않고, 그저 상황을 바라보기로 했다.

욕심내지 않는 것이 맞다.

어차피 지금 내가 통제할 수 있는 선택지는 많지 않기에,

흐르는 대로 집중하며 견뎌내려 한다.

데이터 베이스 생성_[ AWS ]

KDY0218 — Sat, 10 Jan 2026 22:35:28 +0900

서론

AWS를 처음 접해본 사람으로서 천천히 교재와 수업자료를 비교해가며 따라가본다.
AWS 데이터베이스 서버를 생성해본다.
시스템에서 빠질 수 없는 데이터베이스를 준비하는 방법을 알아보자.
MySQL을 이용한 데이터 베이스 서버를 생성해본다.

목표

RDS 개념 이해
환경 구성 실습 > 데이터 베이스 생성에 필요한 파라미터 그룹, 옵션그룹, 서브넷 그룹을 직접 설정해본다.
AWS RDS 생성 > MySQL 엔진을 기반으로 하는 RDS 인스턴스를 실제로 생성
DB 접속 및 확인 > 로컬 환경 과 클라우트 환경 두 가지 방법으로 생성된 DB에 접속하여 정상 작동을 확인해본다.

AWS RDS

Amazon Relational Database Service (RDS) 는 AWS가 제공하는 매니지드 서비스이다.

설치 운영 백업 등을 AWS가 미리 수행한 상태로 제공을 한다.

우리는 어떤 DB를 쓸지, 성능은 어느 정도로 할지 고르기만 하면 된다.

EC2가 빈 땅을 빌려주는 것이라면, RDS는 이미 지어진 최신식 창고를 빌려주고 관리인까지 붙여주는 것과 같다.

RDS 시스템

1. 데이터베이스 엔진 : 실제로 데이터가 저장되거나 질의에 응답하는 데이터베이스 본체를 가리킨다. RDS에서는 MySQL이나 PostgreSQL 등을 앞세운 다양한 데이터베이스 제품을 데이터베이스 엔진으로 선택할 수 있다.

2. 파라미터 그룹 : 주로 데이터베이스 엔진 고유의 설정을 수행한다. 사용하는 언어나 데이터베이스 튜닝을 설정할 수 있다.

3. 옵션 그룹 : 주로 RDS 고유의 설정을 수행한다. AWS를 이용한 데이터베이스 모니터링에 관한 설정 등을 수행 할수있다.

4. 서브넷 그룹 : 데이터베이스 서버를 여러 개의 가용 영역에 분산 배치할 때 이용되는 설정이다. 웹 서버와는 시스템 이나 개념이 다소 다르지만, 데이터베이스 서버도 여러 대의 서버를 제공함으로써 신뢰성이나 성능 을 높일 수 있다. 여러 데이터베이스 서버를 분산시켜 제공할 수 있는 서브넷들을 서브넷 그룹으로 설정한다.

1. 데이터 베이스 생성 전 설정

1-1 . 파라미터 그룹 생성

1-2 옵션 그룹 생성

1-3 서브넷 그룹 생성

퍼블릭 01, 02 로 생성한다.

2. 데이터 베이스 생성

만약 프리티어가 없고 샌드박스로 되어 있다면 샌드박스로 진행해도 무관.

암호 설정

서브넷 그룹 선택

자동 백업 활성화 체크 해제 해주자.

데이터 베이스 생성. 완료

데이터 베이스 생성 후 선택한 VPC 설정

접속이 안될 시 대비해서 TCP 프로토콜 추가로 데이터베이스에 보안그룹을 추가해주자.

3. HeidiSQL 접속

생성한 데이터베이스 엔드포인트 주소를 IP 대신에 복사해서 입력하고 접속한다.

4. 인스턴스 한개 만들어서 만든 데이터베이스로 접속해보자.

설치 명령어 입력.

접속 완료. ( 엔드포인트를 입력 해줘야 된다. )

테스트 데이터 베이스를 만들고 확인해보았다.

앱을 사용해서 생성한 데이터베이스 들어가면 똑같이 생성이 되어있는 것을 확인할 수 있다.

로드 밸런서_[ AWS ]

KDY0218 — Sat, 10 Jan 2026 03:28:22 +0900

서론

AWS를 처음 접해본 사람으로서 천천히 교재와 수업자료를 비교해가며 따라가본다.
AWS 로드밸런서에 대해서 이해해본다.
인스턴스 3개 생성 과정은 생략한다.
(인스턴스 정보는 중간에 나와있음.)

목표

로드밸런서의 필요성과 역할을 학습한다.
AWS ALB를 직접 생성하고, 대상그룹 설정을 실습한다.
웹서버의 화면 내용을 다르게 설정하여, 실제 브라우저 요청이 여러 서버로 라우팅 되는 과정을 눈으로 검증한다.

로드 밸런서

사용자가 늘어나면 1대의 웹 서버로는 요청을 깔끔하게 처리할 수 없는 시점이 온다.
이럴 때는 웹 서버를 여러 대 준비해서 성능을 높이는 방법을 이용할 수 있다.
이렇게 성능을 향상하는 방식을 스케일 아웃scale-out이라 부른다.
그러나 단순히 웹 서버만 늘리면 송신 대상지의 PC 브라우저나 모 바일에서는 새로운 웹 서버를 자동으로 이용하지 못한다. 따라서 스케일 아웃을 할 때는 서비스를 제공하는 측에서 무언가의 시스템을 추가로 제공해야 한다.

예를 들어서 이해해보자.

상황 : 맛집에 손님이 몰린다. ( 트래픽 증가 )

조치 : 요리사 추가 고용 ( 스케일 아웃 )

문제 발생 : 손님은 여전히 1번 요리사만 찾는다.

-> 손님들은 기존 1번 요리사의 전화번호만 알고 있다는 것이다.

새로 온 2번 3번 요리사는 손님 전화를 기다리며 대기 중이고, 1번 요리사만 전화받느라 바쁘다.

손님(브라우저/모바일) 입장에서는 새로온 요리사들의 전화번호(IP주소)를 모르기 때문이다.

해결책 : 대표 번호 개설 ( 시스템 추가 제공 )

시스템이 필요하다고 생각되서 대표 주문번호(로드 밸런서) 를 만들었다.

>> 가게 대표 번호(로드밸런서)를 하나 만들었다.

>> 손님들은 이제 요리사 개인 번호가 아니라, 대표 번호로만 전화를 한다.

>> 대표 번호를 관리하는 직원(로드밸런서)이 전화를 받아서 지금 1번 바쁘니까 2번 요리사가 받으세요 라고 연결을 해준다.

요약

웹서버만 늘리면 >> 컴퓨터 주소가 다 제각각이라 사용자가 일일이 새주소를 알아내서 접속을 해야한다.

시스템(로드밸런서)를 추가하면 >> 사용자는 대표 주소 하나만 알면되고, 뒤에서 알아서 한가한 서버로 연결을 해준다.

로드 밸런서의 역할

로드밸런서는 스케일 아웃을 수행하는 방법의 하나이다.

로드밸런서의 주요 역할

1. 요청 분산

2. SSL 처리

3. 부정 요청 대응

AWS에서 제공하는 로드 밸런서

AWS에서는 ELB 라는 서비스로 로드 밸런서를 제공한다.

Application Load Balancer(ALB) : HTTP나 HTTPS를 이용한 접근을 분산하는 데 최적화된 로드 밸런서.

Network Load Balancer : 기본적인 분산처리 기능만을 제공하지만, 다양한 통신 프로토콜에 대응하는 로드 밸런서.

Classic Load Balancer : ALB나 Network Load Balancer가 등장하기 전에 쓰이던 오래전의 로드 밸런서다. 기존의 AWS 시스템을 사용해야 하는 특별한 경우가 아닌 이상 새롭게 쓰이지는 않는다.

로드 밸런서 생성

1. ALB 선택

2. 가용 영역 및 서브넷 선택

퍼블릭 01 , 02를 사용한다.

3. 보안그룹 선택

여기서 elb는 로드 밸런서가 인터넷으로부터의 HTTP/HTTPS 접근을 받도록 한다.

4. 대상 그룹

5. 대상 등록

선택 후 보류 중인 것으로 포함 시킨다.

6. 검토 및 생성

7. 다시 로드 밸런서 생성 으로 돌아와서 대상그룹 선택에서 방금 만든 대상그룹을 선택한다.

7-1 : 요약 부분 체크

8. 생성 완료

인스턴스 접속

1. 퍼블릭 아이피로 접속을 하자.

모바엑스텀을 이용해서 접속해본다.

2. 보안 펨키를 끌어와서 넣는다.

3. vi testkey.pem으로 들어가서 생성된 보안키를 메모장으로 켜서 그대로 복사 붙여넣기 해주자.

그리고 chmod 400 testkey.pem 으로 권한을 변경해주자.

( SSH 키 파일의 권한이 너무 열려 있으면, AWS가 보안상 위험하다고 판단하여 접속을 거부하기 때문에 나만 읽기 가능한 400 으로 설정 해야한다. )

4. ssh -i testkey.pem ec2-user@10.0.10.135 접속하자.

5. 인스턴스 프라이빗 주소로 점프해서 접속하자.

그리고 nginx 설치

6. 접속 전 검토 후 접속

대상 그룹 상태 확인 해보자.

상태 Healthy 확인.

로드밸런서 주소로 해서 브라우저 주소 검색창에 복사해서 접속해보자.

접속 성공.

로드밸러서 주소로 접속하는 게 정석.

개별 서버 주소로 접속이 안 되는 건 보안설정이 잘 되었다는 뜻이라고 한다.

++ 인스턴스 3개 중 남은 한개를 대상그룹에 보류중인 상태로 넣었다.

인스턴스 프라이빗 아이피로 다시 점프해서 위와 같은 과정을 반복 후 로드밸런서 테스트를 해보기 위해 내용을 수정하고서 새로고침을 눌러보면 화면이 번갈아가면서 나온다.

부하분산 기능이 정상 작동하는지 눈으로 검증 위해 잠시 내용을 다르게 설정을 해본것.

점프 서버 및 private 서버 접속_[ AWS ]

KDY0218 — Sat, 3 Jan 2026 22:23:50 +0900

서론

AWS를 처음 접해본 사람으로서 천천히 교재와 수업자료를 비교해가며 따라가본다.
지난 포스팅에서는 AWS의 뼈대인 VPC 네트워크 환경을 구축해보았다.
이번엔 EC2를 만들어본다.

목표

점프서버 생성후 접속
보안그룹 추가
프라이빗 서버 생성
점프서버에서 프라이빗 서버로 접속.

1. 점프서버

네트워크에 다양한 리소스를 생성한 뒤에는 해당 리소스에 외부로부터 접속해서 리소스에 대한 설정을 수행한다.
이때 리소스로의 접속은 제한된 관리자만 수행할 수 있어야 한다.
하지만 그런 설정을 모든 리소스에 수행하기란 매우 어려우며 설정이 누락될 가능성도 높다.

따라서 모든 리소스에 접속할 수 있는 입구인 점프서버를 준비하고, 해당 서버를 경유해야만 각 리소스에 접속할 수 있는 방식을 많이 사용한다.

점프 서버는 EC2를 이용해 구축할 수 있다.
EC2는 가상 서버로 CPU, 메모리, 디스크 등이 제공되며 리눅스나 윈도우 등의 OS를 설치할 수 있다.
점프 서버 자체는 목적한 리소스로의 통로 이외의 용도는 없다.
따라서 성능이 낮아도 되며 OS도 특별히 가리지 않는다.

점프 서버가 왜 필요한가?

보안 관리의 효율성과 안전성을 높이기 위해서이다.

만약 내부의 모든 서버가 각각 관리자 접속을 허용한다면, 서버가 늘어날수록 보안 설정(방화벽)을 관리하기가 매우 어려워집니다. 설정 누락으로 인한 보안 사고 위험도 커집니다.

이를 해결하기 위해 '점프 서버' 라는 단일 진입점을 만듭니다.

관리자는 오직 점프 서버에만 접속할 수 있습니다.
내부 서버들은 오직 점프 서버에서의 접근만 허용합니다.

2. SSH 접속에 필요한 키 페어 준비

고유한 이름으로 이름을 생성한다.

PuTTY라는 오픈소스 ssh 클라이언트를 사용할 경우 .ppk형식을 이용한다.

윈도우에서는 .pem 형식을 사용하자.

(나중에 PuTTY 관련 포스팅 할 예정이다)

키페어 생성을 누르면 다운로드가 된다.

키페어는 한번 생성 되기 때문에 다운로드한 비밀 키를 잃어버리는 경우에는 키 페어를 새롭게 만든 뒤 기존 서버의 공개 키를 바꾸어야 하므로 주의해야한다.

3. 점프 서버 생성

점프서버는 EC2 인스턴스로 생성한다.

이름을 정해주자.

인스턴스 유형을 t3.micro로 선택하고

키페어를 위에서 생성했던 키페어로 선택해주자.

여기 설정이 중요하다.

VPC 선택에서 만들었던 VPC로 선택.
서브넷은 public01.
퍼블릭 IP 자동 할당.
보안그룹은 기존 보안그룹 선택으로 바꾸고 네트워크 구축때 만든 보안그룹 (22번)을 추가해준다.

인스턴스 생성완료.

4. 접속 확인

AWS EC2 인스턴스를 웹에서 바로 연결을 해서 들어가보자.

접속 완료.

여기서 내 리눅스 서버 A ( 모박엑스텀 이용) 에서 지금 만든 인스턴스로 SSH 접속을 시도해보자.

수월한 환경을 위해서 모바엑스텀을 이용했다.

다운로드 된 키를 먼저 공유 한다.

ssh -i TEST0103.pem ec2-user@43.203.255.254

퍼블릭 IP 주소로 접속을 시도했는데 거부가 된다.

키 파일 권한이 너무 개방되어 있어서 보안상 위험하다고 판단해 접속이 거부가 되는 거라고 한다.

chmod 400 TEST0103.pem

권한 변경 명령어로 키파일 권한을 수정해주자.

다시 접속!

비둘기가 뜨면서 접속 완료가 되었다.

5. private 인스턴스 생성 및 점프서버 연결 보안그룹 추가

프라이빗 인스턴스를 하나더 만들자.

이름은 TEST-private로 생성한다.

위 그림 이외에는 첫 인스턴스를 만들때와 똑같이 설정해준다.

키페어는 기존에 다운로드 돼 있던 걸로 연결해도 된다.
VPC 선택 중요!
서브넷은 private01로 선택
기존 보안 그룹선택 후 default로 설정해주자. ( public01 인스턴스에도 똑같이 default 보안그룹을 설정해줘야된다 )

5-1. 퍼블릭 , 프라이빗 서로 연결을 해주기 위해 보안그룹 default 추가.

보안 그룹 default 추가.

6. 점프 서버 -> 프라이빗 서버로 접속.

6-1. 모바엑스텀으로 점프서버 접속 후 프라이빗 서버로 접속.

점프서버 퍼블릭 IP 입력

Use private key에서 생성한 키페어 넣어주자.

로그인 아이디 : ec2-user 입력.

점프서버 접속 완료.

이제 여기서 프라이빗 서버로 접속하자.

프라이빗 서버 IP로 접속을 해야된다.

우선 핑테스트 후 ssh -i TEST0103.pem ec2-user@10.0.4.127 으로 접속하자.

점프서버에서 프라이빗 서버로 접속 완료.

가상 네트워크(VPC) 수동 구축_[ AWS ]

KDY0218 — Sat, 3 Jan 2026 17:38:05 +0900

서론

AWS를 처음 접해본 사람으로서 천천히 교재와 수업자료를 비교해가며 따라가본다.
네트워크를 수동으로 구축하면서 구조파악과 기본개념에 대해서 공부해보자.

목표

VPC 네트워크 인프라 수동 구축

1. VPC 생성

AWS를 이용해 네트워크를 구축할 때는 VPC라는 시스템을 이용할 수 있다.물리적인 기기를 이용하지 않고 가상의 네트워크를 구축할 수 있다. AWS의 데이터센터에 있는 전용 기기에서 서버나 네트워크 장비가 가진 기능을 에뮬레이션하는 소프트웨어를 작동시켜, 물리적인 기기를 이용하지 않고 가상의 네트워크를 구축할 수 있다.

10.0.0.0 /16 = 사설 IP 대역으로, 내부 통신용으로 가장 널리 쓰이는 주소이다.
/16 은 AWS VPC에서 허용하는 가장 큰 서브넷 마스크 크기이다. 65,536개의 IP 주소를 사용할 수 있게 되어 추후 서브넷을 여러 개로 쪼개거나 서버가 늘어나도 IP가 부족할 일이 없다.

2. 서브넷 생성

VPC 안에는 하나 이상의 서브넷을 만들어야 한다.

서브넷은 VPC의 IP 주소 범위를 나누는 단위다.

- 역할분리 : 외부에공개하는 리소스 여부를 구별

- 기기 분리 : AWS 안에서의 물리적인 이중화를 수행

보안(Role): 인터넷 연결이 필요한 Public 영역과 데이터를 보호해야 할 Private 영역을 철저히 분리하기 위해서이다.
재해 복구(Device): 서로 다른 물리적 위치(가용 영역)에 서버를 분산시켜, 천재지변이나 데이터센터 장애 시에도 서비스가 죽지 않게(고가용성) 하기 위해서이다.

VPC ID 선택

어느 땅 위에 건물을 지을지 정하는 과정이다.

서브넷은 독립적으로 존재할 수 없고, 반드시 특정 VPC 안에 소속되어야 한다.

그래서 "이 서브넷은 TEST-VPC 소속이다 라고 지정 해준다.

총 4개의 서브넷을 생성한다.

외부에 공개 public 2개

외부에 비공개 private 2개

가용영역 선택

public01 = 2a

public02 = 2c

private01 = 2a

private02 = 2c

3. 인터넷 게이트웨이

VPC에서 생성된 네트워크와 인터넷 사이의 통신을 가능하게 하는 것이다.

인터넷 게이트웨이가 없으면 인터넷과 VPC 안의 리소스는 서로 통신할 수 없다.

구분 하기 쉬운 이름을 설정하고서 생성한다.

생성 후 VPC에 연결을 해준다.

4. NAT 게이트웨이 생성

* 과금 대상이니 실습 후에는 꼭 삭제해주자 * ***

* 탄력적 IP도 꼭 릴리스 해주자 *

인터넷 게이트웨이의 역할은 VPC에서 생성된 네트워크와 인터넷 사이의 통신을 수행하는 것이다.
이때 VPC에서 생성된 네트워크 안에 만들어진 리소스는 외부 네트워크와 직접 통신하므로 공개 IP를 가져야 한다.
하지만 공개 IP를 가진다는 것은 인터넷에 직접 공개된다는 의미이므로, 애써 서브넷을 퍼블릭과 프라이빗으로 구분한 의미가 사라진다.

프라이빗 서브넷에 생성된 리소스는 인터넷으로 내보낼 수는 있지만 인터넷에서 접근할 수는 없어야한다.
이런 요구사항을 구현하기 위해 NAT라는 네트워크 주소 변환 시스템이 있다.
AWS에서는 이 NAT를 구현하는 NAT 게이트웨이를 제공한다.
NAT 게이트웨이는 퍼블릭 서브넷에 대해 생성한다.
이중성을 확보하려면 여러 NAT 게이트웨이를 생성하는 것이 좋다.

NAT 게이트웨이 (중계자)

역할: "나가는 건 OK, 들어오는 건 NO"
- 내부(Private)에서 밖으로 요청하는 건 대신 처리해 주고, 밖에서 내부로 들어오려는 건 막아줍니다.
비유 (연예인과 매니저):
- Private 서버 (연예인): 집 밖으로 나가면 위험해서 집에만 있습니다. 근데 햄버거가 먹고 싶습니다.
- NAT 게이트웨이 (매니저): 연예인 대신 햄버거 가게(인터넷)에 갑니다.
- 결과: 햄버거 가게 직원은 매니저 얼굴만 봅니다. (연예인 집 주소는 모름). 매니저가 햄버거를 사서 집 안의 연예인에게 전달해 줍니다.

배치 위치가 중요

"NAT 게이트웨이는 퍼블릭 서브넷에 생성한다"

왜? 매니저(NAT)는 햄버거 가게(인터넷)에 다녀와야 한다.
흐름: Private 서버 -> NAT 게이트웨이 (Public 서브넷 위치) -> 인터넷 게이트웨이 -> 인터넷

-> 여기서는 2개의 퍼블릭 서브넷에 각각 NAT 게이트웨이를 생성할 것이다.

영역별 선택

서브넷 퍼블릭01, 02 선택 후 탄력적 IP 까지 할당해주고 생성을 해준다.

5. 라우팅 테이블

VPC상에 서브넷을 생성하고 리소스를 생성할 장소를 준비했다.
또한 인터넷 게이트웨이와 NAT게이트웨이를 생성해 리소스가 인터넷과 통신할 수 있도록 출입구를 만들었다.
하지만 이 상태에서는 서브넷과 서브넷, 또는 서브넷과 각 게이트웨이가 통신할 수 있는 경로가 아직 존재하지 않는다.
따라서 어떤 서브넷 안의 리소스가 해당 서브넷 밖의 리소스에는 접근할 수 없다.

이러한 서브넷 사이의 통신 경로를 설정하고자 AWS에서는 라우팅 테이블 기능을 제공한다.
라우팅 테이블에는 '이 서버'에 접속할 때는 이 곳을 경유한다' 라는 규칙을 다음과 같은 테이블 형식으로 설정할 수 있다.

내비게이션 (또는 도로 표지판)

VPC/서브넷: 도로와 건물을 지었습니다.
인터넷 게이트웨이/NAT: 고속도로로 나가는 톨게이트를 지었습니다.
문제점: 하지만 도로 위에 서울로 가려면 오른쪽으로 가시오 라는 표지판이 하나도 없습니다. 그래서 자동차(데이터)가 톨게이트가 어디 있는지 몰라서 뱅뱅 돌고 있는 상태입니다.

라우팅 테이블이 바로 이 표지판(내비게이션) 역할을 합니다.

현재 총 4개의 서브넷이 존재한다.

모든 서브넷에 라우팅 테이블을 작성해야한다.

단, 여러 서브넷이 같은 라우팅 테이블을 공유할 수도 있다. 이를 고려해 여기서는 다음과 같이 라우팅 테이블을 생성할 것이다.

퍼블릭 라우팅 테이블 : 퍼블릭 서브넷 1,2 공용

프라이빗 라우팅 테이블 1: 프라이빗 서브넷 1용

프라이빗 라우팅 테이블 2: 프라이빗 서브넷 2용

라우팅 경로 편집 (Route Editing)

라우팅 테이블을 생성했다면, 이제 실제로 트래픽이 이동할 경로를 지정해야 합니다. '라우팅 편집' 메뉴로 들어가 [라우팅 추가] 버튼을 클릭합니다.

대상 (Destination): 0.0.0.0/0 (모든 IP 대역을 의미)
타겟 (Target): 인터넷 게이트웨이 (방금 생성한 IGW 선택)

이 설정의 의미는 목적지를 모르는 모든 트래픽(0.0.0.0/0)은 인터넷 게이트웨이로 보내라(인터넷으로 내보내라)는 뜻입니다.

라우팅 테이블이 속한 서브넷을 지정한다.

서브넷 연결 탭을 선택 -> 서브넷 연결 편집 버튼을 클릭한다.

서브넷 연결 편집 화면에서 편집 중인 라우팅 테이블이 속하는 서브넷을 지정하면 된다.

퍼블릭 라우팅 테이블에는 public01, public02에 연결되므로 이 2개의 서브넷에 체크한 뒤 연결 저장을 누른다.

**프라이빗 라우팅 테이블을 설정할 때는 인터넷 게이트웨이가 아닌 NAT 게이트웨이 를 선택해야 한다.

프라이빗 01, 02 서브넷 연결도 각각 하나씩 연결 해주면 된다.

정리

라우팅 테이블 3개 생성 public 1개 private 01, 02 한개씩

public 라우팅은 인터넷 게이트웨이 연결

private 01,02는 NAT로 연결

서브넷 연결

public -> 01 , 02 추가

private : 01 -> 01 , 02 -> 02 연결

6. 보안그룹

VPC상에 다양한 리소스를 생성할 준비를 마쳤다.
하지만 이 상태에서는 인터넷을 통해 모든 리소스에 접근할 수 있다.
VPC 안의 리소스를 보호하려면 외부로부터의 접근에 제한을 걸어야 한다.
이런 접근 제한을 수행하기 위해 보안그룹 이라는 기능을 제공한다.

포트번호를 이용한 제어: 웹 서비스에 접근할 때 쓰이는 80번과 443번 또는 서버에 접속해서 유지 보수할 때 쓰이는 22번 등을 많이 지정한다.

IP주소를 이용한 제어: 소속된 회사나 학교 등 조직 내 네트워크에서 작업할 경우 인터넷에 접속하는 IP 주소는 보통 한정된다. 이러한 IP 주소들을 지정함으로써 조직 외부로부터의 접근을 막을 수 있다.

여기서는 2개의 보안그룹을 생성할 것이다.

모든 리소스에 접속하는 입구인 '점프서버'

요청이나 처리를 분산하는 '로드 밸런서'

보안그룹 1 : VPC 정보는 만들어놓은 VPC -> TEST VPC로 연결을 해줘야된다.

인바운드 규칙 추가를 눌러서 위와 같이 설정해준다.

* 점프 서버용 보안그룹은 관리자 접속을 위해 SSH 22번 포트를 내 IP에서만 접근 가능하도록 열어준다.

보안그룹 2 : 1과 똑같이 VPC 설정해주고

인바운드 규칙 2개를 추가해서 HTTP 와 HTTPS 를 넣어준다.

마무리

AWS 클라우드 환경의 가장 기초가 되는 VPC 네트워크를 수동으로 구축해 보았다.

VPC(땅) → 서브넷(건물 구획) → 게이트웨이(출입문) → 라우팅 테이블(이정표) 로 이어지는 네트워크 흐름을 알 수 있다.