허브(Hub)란?

허브란 여러 PC를 연결해주는 네트워크 장비이다. 그러나 허브는 MAC 주소를 저장하지 않기 때문에 패킷이 들어오면 연결된 모든 포트에 뿌려버린다.

허브의 문제점 - 반이중 방식 (Half-Duplex)

허브는 반이중 방식을 사용한다. 반이중이란 한 번에 한 방향으로만 데이터를 전송할 수 있는 방식이다.

무전기와 똑같다. 말할 때는 듣지 못하고, 들을 때는 말하지 못한다.

CSMA/CD란?

CSMA/CD(Carrier Sense Multiple Access / Collision Detection)란 허브 환경에서 충돌을 감지하고 처리하는 방식이다.

1. 보내기 전에 "지금 조용해?" 확인 (Carrier Sense)
        ↓
2. 조용하면 전송 시작
        ↓
3. 전송 중에 충돌 감지하면 (Collision Detection)
        ↓
4. 즉시 멈추고 "충돌났다!" 신호 보냄
        ↓
5. 랜덤 시간 기다렸다가 다시 1번부터

랜덤하게 기다리는 이유는 둘 다 똑같이 기다리면 또 동시에 출발해서 충돌이 발생하기 때문이다.

스위치(Switch)란?

스위치란 허브의 문제점을 해결한 네트워크 장비이다. MAC 주소를 테이블로 저장하여 목적지 포트에만 패킷을 전달한다.

허브 vs 스위치

요즘은 허브 거의 안 쓰고 다 스위치를 사용한다.

스위치 종류

네트워크 규모가 커질수록 스위치를 계층화하여 관리한다.

PC (수백대)
    ↓ 묶기
액세스 스위치 (PC 직접 연결)
    ↓ 묶기
분배 스위치 (액세스 스위치 묶음)
    ↓ 묶기
코어 스위치 (전체 트래픽 담당)
    ↓
라우터 → 인터넷

소규모 회사는 액세스 스위치 → 라우터로 단순하게 구성하기도 한다.

업링크 포트란?

업링크 포트란 하위 장비에서 상위 장비로 연결하는 포트이다.

라우터 (인터넷 연결)
    ↑ 업링크
코어 스위치
    ↑ 업링크
분배 스위치
    ↑ 업링크
액세스 스위치 (PC 연결)

트렁크 포트 = 스위치끼리 옆으로 연결
업링크 포트 = 상위 장비로 위로 연결

VLAN이란?

VLAN(Virtual LAN)이란 물리적으로 같은 네트워크인데 논리적으로 나눈 것이다.

물리적으로 같은 스위치에 연결돼있지만

VLAN 10 → 개발팀
VLAN 20 → 인사팀
VLAN 30 → 서버팀

서로 다른 VLAN끼리는 통신하지 못한다.

VLAN을 쓰는 이유

• 보안 : 같은 스위치에 연결돼있어도 VLAN이 다르면 통신 불가
• 비용 절감 : 스위치 여러 대 안 사도 하나로 논리적으로 나눌 수 있음
• 성능 향상 : 브로드캐스트 트래픽을 VLAN 안에서만 돌게 해서 전체 트래픽 감소
• 유연한 관리 : 물리적 위치 상관없이 논리적으로 묶을 수 있음

트렁크 포트란?

트렁크 포트란 여러 VLAN 정보를 한 번에 전달할 수 있는 포트이다. 스위치끼리 연결할 때 사용한다.

1층 개발자 PC
    ↓ (일반 포트 - VLAN 10)
1층 스위치
    ↓ (트렁크 포트 - VLAN 10, 20, 30 다 전달)
3층 스위치
    ↓ (일반 포트 - VLAN 10)
3층 개발자 PC

트렁크 포트 덕분에 물리적 위치가 달라도 같은 VLAN으로 묶을 수 있다.

IDS vs IPS란?

IDS = CCTV (보기만 함)
IPS = CCTV + 경비원 (보고 막음)

보안 솔루션에서 미러링 탭으로 트래픽 복사 → IDS/IPS가 분석 → 공격 탐지/차단하는 구조로 동작한다.

VPN (Virtual Private Network)이란?

VPN이란 인터넷을 통해 안전한 사설 터널을 만드는 것이다.

내 PC ──암호화된 터널──→ VPN 서버 ──→ 목적지

VPN 동작 순서

1. VPN 서버에 접속
2. 암호화된 터널 생성
3. 내 트래픽이 터널 통해서 나감
4. 목적지엔 VPN 서버 IP로 보임

VPN을 쓰는 이유

• 내 IP 숨길 수 있음
• 암호화로 도청 방지
• 회사 내부망 원격 접속

방화벽 계층이란?

방화벽은 레벨에 따라 종류가 다르다.

L3/L4 방화벽 = "이 IP, 이 포트 막아"
L7 방화벽 (WAF) = "이 URL, 이 내용 막아"

네트워크 트러블슈팅이란?

서비스 접속이 안 될 때 계층별로 좁혀나가며 확인하는 것이다.

ping (L3) → 네트워크 연결 확인
        ↓
telnet (L7) → 포트 + 서비스 확인
        ↓
ss, iptables → OS/방화벽 레벨 확인
        ↓
로그 확인 → 서비스단 확인

ping이란?

ping 서버IP

서버가 살아있는지, 네트워크 연결 자체가 되는지 확인한다. ICMP 프로토콜을 사용하며 L3 계층이다.

telnet이란?

telnet 서버IP 포트번호

특정 포트가 열려있는지 확인할 때 사용한다. 접속되면 포트 열린 것, 안되면 포트 막힌 것이다.

단, telnet 실패가 무조건 포트가 닫혀있다는 뜻은 아니다. 포트는 열렸는데 서비스단에서 막아놨을 수도 있으니 추가 확인이 필요하다.

프로세스 상태란?

Hang이란?

프로세스가 살아있는데 멈춰버린 상태이다.

# 로그 확인으로 Hang 여부 판단
tail -f /var/log/[로그경로]

로그가 계속 찍히면 정상, 멈춰있으면 Hang 의심이다.

좀비 프로세스란?

프로세스가 죽었는데 완전히 사라지지 않고 남아있는 상태이다. 자식 프로세스가 죽었을 때 부모 프로세스가 확인을 안 하면 좀비 상태로 남는다.

# 좀비 프로세스 확인
ps aux | grep Z

NIC와 리눅스 네트워크 명령어란?

NIC (Network Interface Card)란?

NIC란 네트워크에 연결하게 해주는 랜카드이다. 리눅스에서는 ens192, ens33 같은 이름으로 표시된다.

# 네트워크 인터페이스 목록 확인
ip addr

ip addr flush란?

sudo ip addr flush dev ens192

해당 인터페이스에 설정된 IP 주소를 전부 초기화하는 명령어이다. IP 새로 설정하기 전에 기존 IP를 싹 지울 때 사용한다.

주의: SSH로 접속 중이면 연결이 끊길 수 있다.

scp -rp란?

scp -rp /home/user/폴더명 root@서버IP:/목적지경로

tcpreplay와 pcap이란?

pcap (Packet Capture)이란?

네트워크에서 오간 패킷을 캡처해서 저장한 파일 형식이다.

# tcpdump로 pcap 파일 생성
tcpdump -i ens192 -w 캡처파일.pcap

pcap = 네트워크 블랙박스 영상 파일

tcpreplay란?

캡처해둔 패킷을 다시 재생(전송)하는 도구이다. 보안 솔루션 테스트할 때 주로 사용한다.

# pcap 파일 재생
tcpreplay -i ens192 캡처파일.pcap

# 속도 조절해서 재생
tcpreplay -i ens192 --mbps=10 캡처파일.pcap

wireshark로 패킷 캡처 (.pcap 파일)
        ↓
tcpreplay로 그 패킷 다시 전송
        ↓
보안 솔루션이 제대로 탐지하는지 확인

OLE vs OCR이란?

OLE = 공격자가 악용하는 것
OCR = 그걸 탐지하는 도구

마무리

오늘은 허브와 스위치의 차이부터 VLAN, 트러블슈팅, 프로세스 상태까지 다양한 개념을 학습하였다. 각각의 개념들이 네트워크 계층과 연결되면서 전체적인 흐름이 조금씩 보이기 시작하였다. 앞으로도 모르는 개념이 나올 때마다 찾아보고 정리하는 습관을 이어나갈 예정이다.

이 글은 여러 포스팅에 뿔뿔이 흩어져 있던 하둡 관련 개념들을 한 곳에 모아 정리하기 위해 작성하였다. 하둡을 배우면서 생겼던 의문들과 그에 대한 해답들을 함께 담았다.

하둡(Hadoop) 완전 정복 - 신입 엔지니어의 질문 모음

하둡(Hadoop)이란?

하둡(Hadoop)이란 대용량 데이터를 여러 서버에 나눠서 저장하고 처리하는 오픈소스 분산 처리 프레임워크이다.

여기서 오픈소스란 단순히 무료라는 의미가 아니라, 소스코드가 공개되어 있어 우리 환경에 맞게 커스터마이징이 가능하다는 의미이다. 실제로 오픈소스이지만 유료인 경우도 있다. (ex. Red Hat Linux)

하둡은 크게 세 가지 구성요소로 이루어져 있다.

하둡 (Hadoop)
    ├── HDFS (파일 시스템 - 저장 담당)
    ├── MapReduce (데이터 처리 담당)
    └── YARN (자원 관리 담당)

하둡 = 건물 전체, HDFS = 건물 안에 있는 창고

HDFS(Hadoop Distributed File System)란?

HDFS란 하둡 안에서 파일 저장을 담당하는 분산 파일 시스템이다. 대용량 데이터를 여러 서버에 나눠서 저장하는 방식이다.

데이터가 들어오면 HDFS가 자동으로 블록 단위로 나눠서 저장한다.

HDFS 핵심 특징

• 데이터를 블록 단위(기본 128MB)로 쪼개서 여러 DataNode에 분산 저장한다.
• 블록을 3개씩 복제하여 저장하기 때문에, 서버 하나가 죽어도 데이터가 유실되지 않는다.
• 한 번 쓰면 수정이 어려운 구조로, 읽기에 최적화되어 있다.

HDFS 구조 - NameNode와 DataNode

NameNode는 전체 파일 시스템의 메타데이터를 관리한다. 어떤 파일이 어느 DataNode에 저장되어 있는지 알고 있는 관리자 역할이다. NameNode가 죽으면 전체 시스템이 위험해진다는 단점이 있다.

DataNode는 실제 데이터 블록을 저장하는 서버들이다. DataNode에는 디스크가 여러 개 꽂혀있고, 각 디스크를 마운트하여 그 위에 블록을 저장한다.

DataNode 서버
    하드디스크 1 → /data/disk1 마운트 → 블록 1, 블록 2 저장
    하드디스크 2 → /data/disk2 마운트 → 블록 3, 블록 4 저장

DataNode 마운트란?

마운트란 저장 장치(디스크)를 특정 디렉토리에 연결해서 사용할 수 있게 하는 것이다. 리눅스에서는 디스크를 꽂아도 자동으로 인식되지 않고, 직접 명령어로 연결해줘야 한다.

마운트 = 책장 칸(디스크)을 연결하는 것
블록 = 책장에 꽂힌 책들

DataNode에 마운트가 올라간다는 건?

DataNode에 연결된 디스크 개수가 늘어난다는 뜻이다. 저장 공간 자체가 늘어나는 것으로, 디스크를 추가 구매해야 하므로 비용이 증가한다.

DataNode에 블록 카운트가 올라간다는 건?

DataNode에 저장된 블록 개수가 늘어난다는 뜻이다. 데이터가 쌓일수록 블록이 생기고 그 개수가 늘어나는 것으로, 저장 공간이 줄어든다.

RAID와 비교

HDFS에서 데이터를 가져올 때

HDFS에서 데이터를 가져올 때도 여러 서버에서 동시에 가져온다. 이를 병렬 처리 또는 분산 처리라고 한다.

파일 요청
    ↓
NameNode한테 "이 파일 어디 있어?" 물어봄
    ↓
NameNode가 "서버1, 서버2, 서버3에 있어" 알려줌
    ↓
서버1, 서버2, 서버3에서 동시에 블록 가져옴
    ↓
합쳐서 원본 파일 복원

MapReduce란?

MapReduce란 HDFS에 저장된 대용량 데이터를 꺼내서 분석/처리하는 방식이다.

HDFS = 창고 (저장만 함)
MapReduce = 창고에서 꺼내서 가공하는 공장

Map 단계

데이터를 이동시키지 않고 있는 곳에서 바로 처리하는 단계이다.

전체 데이터 (1억 줄)
    ↓
서버 1 → 자기 데이터에서 처리
서버 2 → 자기 데이터에서 처리
서버 3 → 자기 데이터에서 처리

한 곳에 모아서 처리하면 데이터 이동에만 시간이 엄청 걸리기 때문에, 있는 곳에서 바로 처리하는 것이다.

Reduce 단계

각 서버에서 처리한 결과를 합쳐서 최종 결과를 만드는 단계이다.

서버 1 결과: "에러 로그" 300개 ─┐
서버 2 결과: "에러 로그" 500개 ─┼──→ 합산 → 최종 결과: 1000개
서버 3 결과: "에러 로그" 200개 ─┘

한 줄 요약

Map = 데이터 있는 곳에서 바로 처리 (이동 최소화)
Reduce = 각자 처리한 결과 합쳐서 최종 답 도출

YARN이란?

YARN(Yet Another Resource Negotiator)이란 하둡에서 자원(CPU, 메모리)을 나눠주는 관리자이다.

하둡 클러스터에 서버가 여러 대 있고 작업도 여러 개 들어오면, YARN이 어떤 서버에서 어떤 작업을 처리할지 배분해준다.

서버들 = 직원들
작업들 = 해야 할 업무
YARN = 팀장 (누구한테 어떤 업무 줄지 결정)

스케줄링이란?

작업을 언제 어디서 처리할지 순서를 정해주는 것이다. 작업이 동시에 100개 들어오면 YARN이 각 서버에 배분하는 역할을 한다.

전체 흐름 정리

데이터 들어옴
    ↓
HDFS가 자동으로 분산 저장
    ↓
사용자가 분석 요청
    ↓
YARN이 자원 배분
    ↓
MapReduce가 처리 후 결과 반환

HAR (Hadoop Archive)란?

HAR이란 하둡에서 작은 파일 여러 개를 하나로 묶는 것이다.

왜 필요하냐?

HDFS는 큰 파일에 최적화되어 있다. 작은 파일이 엄청 많으면 NameNode가 파일 하나하나의 메타데이터를 다 관리해야 하므로 NameNode 메모리 부담이 커지고 성능이 저하된다.

작은 파일 1000개 → NameNode가 1000개 메타데이터 관리 → 부하 큼
        ↓ HAR로 묶기
.har 파일 1개 → NameNode가 몇 개만 관리 → 부하 감소

HAR의 효과

NameNode 관점

• 블록 카운터 감소 → NameNode 메모리 부하 감소 ✅

DataNode 관점

• 블록 수는 줄어들지만 실제 디스크 용량은 그대로 ❌
• HAR은 DataNode 디스크 용량 확보와는 관계없음

HAR 단점

• 묶인 파일 안에서 특정 파일 찾으려면 인덱스 탐색 필요
• 파일 하나 수정하려면 전체 다시 풀고 다시 묶어야 함
• MapReduce 처리 속도 느려질 수 있음
• 자주 접근하는 데이터에 사용하면 오히려 성능 저하

자주 안 쓰는 콜드 데이터에 사용하는 것이 적합하다.

HAR 명령어

# HAR 파일 만들기
hadoop archive -archiveName 이름.har -p /입력경로 /출력경로

# HAR 파일 내용 보기
hadoop fs -ls har:///출력경로/이름.har

crontab으로 HAR 자동화

HAR 작업을 매번 수동으로 하기 번거롭기 때문에 crontab으로 자동화할 수 있다.

# 매일 새벽 2시에 자동으로 HAR 생성
0 2 * * * hadoop archive -archiveName logs_$(date +%Y%m%d).har -p /logs/input /logs/archive

crontab = 알람 설정
makehar = 알람 울리면 할 일

수동으로 실행할 수도 있고, crontab으로 자동화해서 운영할 수도 있다.

DataNode 디스크 용량 확보 방법

HAR은 NameNode 부하를 줄이는 용도이지 DataNode 디스크 용량 확보와는 관계없다. DataNode 디스크 용량을 확보하려면 별도의 방법이 필요하다.

• 디스크 추가 마운트 (비용 증가)
• 오래된 데이터 다른 곳으로 이관 (콜드 스토리지)
• 오래된 데이터 삭제
• 압축해서 저장

실무에서는 보통 핫 데이터는 HDFS에 그대로 두고, 콜드 데이터는 S3 같은 저렴한 스토리지로 이관하는 방식으로 계층화하여 관리한다.

JuiceFS란?

JuiceFS란 HDFS와 동일한 역할을 하지만 저장소를 클라우드(S3 등 오브젝트 스토리지)로 바꾼 분산 파일 시스템이다.

JuiceFS = HDFS의 클라우드 버전

HDFS vs JuiceFS 구조 비교

HDFS
    ├── 메타데이터 → NameNode (전용 서버)
    └── 실제 데이터 → DataNode (전용 서버)

JuiceFS
    ├── 메타데이터 → Redis / MySQL (DB)
    └── 실제 데이터 → S3 (클라우드 스토리지)

S3랑 JuiceFS의 관계

S3는 데이터를 저장하는 스토리지이지만, 파일 시스템이 아니라서 HDFS처럼 쓰기가 불편하다. JuiceFS가 S3 위에 올라타서 S3를 HDFS처럼 사용할 수 있게 만들어주는 역할을 한다.

S3 = 그냥 하드디스크
JuiceFS = 그 하드디스크를 파일 시스템으로 만들어주는 것

HDFS가 클라우드에서 불리한 이유

HDFS는 블록을 3개씩 복제하는 설계 때문에 클라우드 디스크에 배포하면 온프레미스 대비 약 3배의 비용이 발생한다. 반면 JuiceFS는 S3를 기반으로 하여 탄력적으로 확장 가능하고 비용도 절감된다.

마무리

하둡은 단순한 저장 시스템이 아니라 HDFS, MapReduce, YARN이 유기적으로 연결된 분산 처리 생태계이다. 처음에는 복잡해 보이지만 각 구성요소의 역할을 이해하면 전체 흐름이 보이기 시작한다. JuiceFS처럼 하둡 생태계를 클라우드 환경에 맞게 발전시킨 기술들도 함께 알아두면 실무에서 큰 도움이 된다.

파티션이란?

파티션이란 하나의 디스크를 논리적으로 나눈 구역이다. 물리적으로는 디스크 1개인데 여러 개처럼 사용하는 것이다.

파티션을 잡는다는 의미

디스크를 어떻게 나눌지 구역을 설정하는 것이다.

디스크 1TB
    ├── 파티션 1 (200GB) → 운영체제
    ├── 파티션 2 (600GB) → 데이터
    └── 파티션 3 (200GB) → 백업

파티션을 나누는 이유

이점

• 운영체제랑 데이터 분리 → OS 날아가도 데이터 안전
• 파티션별로 파일 시스템 다르게 설정 가능
• 특정 파티션만 포맷 가능
• 로그가 쌓여서 디스크 꽉 차도 다른 파티션에 영향 없음

단점

• 파티션 크기 잘못 잡으면 한쪽은 꽉 차고 한쪽은 남는 낭비 발생
• 나중에 크기 조정이 번거로움
• 파티션 너무 많으면 관리 복잡

보안 솔루션 관점에서

로그가 엄청 쌓이는 환경이라 로그 파티션을 따로 잡는 것이 중요하다. 로그가 꽉 차서 OS 파티션까지 영향을 주면 서버가 다운될 수 있기 때문이다.

LVM (Logical Volume Manager)이란?

LVM이란 파티션을 유연하게 관리해서 공간이 부족하면 동적으로 크기를 늘릴 수 있는 기술이다.

일반 파티션 = 크기가 고정된 방
LVM = 필요하면 벽을 밀어서 방 크기를 늘릴 수 있는 방

LVM 설정 순서

1. 물리 볼륨 생성 (PV)

pvcreate /dev/sdb

2. 볼륨 그룹 생성 (VG)

vgcreate my_vg /dev/sdb

3. 논리 볼륨 생성 (LV)

lvcreate -L 100G -n my_lv my_vg

4. 파일 시스템 생성 후 마운트

mkfs.ext4 /dev/my_vg/my_lv
mount /dev/my_vg/my_lv /mnt/data

나중에 용량 늘리고 싶으면

lvextend -L +50G /dev/my_vg/my_lv
resize2fs /dev/my_vg/my_lv

LVM 구조

물리 디스크 (PV)
    ↓
볼륨 그룹 (VG) ← 여러 PV 묶음
    ↓
논리 볼륨 (LV) ← 실제 사용하는 공간

세그먼트 종류란?

세그먼트라는 단어는 쓰이는 곳마다 의미가 다르다.

네트워크 세그먼트

네트워크를 구역별로 나눈 것이다. 현업에서는 보통 네트워크 대역, IP 대역, 서브넷이라고 더 많이 말한다.

회사 네트워크
    ├── 개발팀 세그먼트 (192.168.1.0/24)
    ├── 인사팀 세그먼트 (192.168.2.0/24)
    └── 서버 세그먼트  (192.168.3.0/24)

TCP 세그먼트

전송 계층(L4)에서 데이터를 쪼갠 조각이다. 목적지에서 재조립하여 원본 데이터를 복원한다.

메모리 세그먼트

프로세스 하나가 실행되면 메모리가 역할별로 나뉜다.

메모리 세그먼트 (상위 개념)
    ├── 코드 세그먼트   → 실행할 코드 저장
    ├── 데이터 세그먼트 → 전역변수 저장
    ├── 스택 세그먼트   → 함수 호출 정보 저장
    └── 힙 세그먼트     → 동적 할당 메모리

Worker 단일/복수 스레드란?

Worker란 작업을 처리하는 단위 프로세스이다.

Worker (프로세스)
    ├── A 스레드 (단일) → a1 → a2 → a3 → a4 순서대로 처리
    ├── B 스레드 (복수) → 여러 스레드가 동시에 처리
    ├── C 스레드 (복수)
    └── D 스레드 (복수)

• 단일 스레드 : 그 작업을 처리하는 스레드가 1개이다. 순서가 중요한 작업일 때 사용한다.
• 복수 스레드 : 그 작업을 처리하는 스레드가 여러 개이다. 동시에 처리해야 할 때 사용한다.

A가 단일 스레드인 이유는 a1 → a2 → a3 → a4가 순서가 중요한 작업이기 때문이다. 동시에 처리하면 순서가 꼬일 수 있으므로 혼자 순서대로 처리하는 것이다.

YARN이란?

YARN(Yet Another Resource Negotiator)이란 하둡에서 자원(CPU, 메모리)을 나눠주는 관리자이다.

하둡 클러스터에 서버가 여러 대 있고 작업도 여러 개 들어오면, YARN이 어떤 서버에서 어떤 작업을 처리할지 배분해준다.

서버들 = 직원들
작업들 = 해야 할 업무
YARN = 팀장 (누구한테 어떤 업무 줄지 결정)

스케줄링이란

작업을 언제 어디서 처리할지 순서를 정해주는 것이다. 작업이 동시에 100개 들어오면 YARN이 각 서버에 배분하는 역할을 한다.

프록시(Proxy)란?

프록시란 클라이언트와 서버 사이에서 중간 대리인 역할을 하는 것이다.

클라이언트 → 프록시 → 서버
클라이언트 ← 프록시 ← 서버

프록시 종류

1. 포워드 프록시 (Forward Proxy)

클라이언트 앞에 있는 프록시로, 클라이언트를 대신해서 서버에 요청을 전달한다.

클라이언트 → 포워드 프록시 → 인터넷 → 서버

• 클라이언트 IP 숨김
• 회사에서 직원 인터넷 감시/차단할 때 사용
• 특정 사이트 접근 우회할 때 사용

2. 리버스 프록시 (Reverse Proxy)

서버 앞에 있는 프록시로, 서버를 대신해서 클라이언트 요청을 받는다.

클라이언트 → 인터넷 → 리버스 프록시 → 서버

• 서버 IP 숨김
• 로드밸런싱 (여러 서버에 트래픽 분산)
• DDoS 방어
• Nginx가 대표적인 리버스 프록시

3. 투명 프록시 (Transparent Proxy)

클라이언트가 프록시 존재를 모르는 것이다. 설정 없이 자동으로 트래픽을 가로챈다.

4. 익명 프록시 (Anonymous Proxy)

클라이언트 IP를 숨겨주는 프록시이다. VPN과 비슷한 개념이다.

5. SOCKS 프록시

HTTP뿐만 아니라 모든 트래픽을 처리할 수 있는 범용적인 프록시이다.

6. SSL 프록시

HTTPS 트래픽을 복호화해서 내용을 검사하는 프록시이다. 보안 솔루션에서 많이 사용하며 DPI와 연결되는 개념이다.

암호화 통신에서 프록시가 필요한 이유

HTTPS, SSH 같은 암호화 통신은 패킷을 가져와도 Key가 없으면 내용을 볼 수 없다. 프록시는 중간에서 양쪽을 속여 Key를 모두 획득한다.

클라이언트 → "나 서버야" (프록시가 속임) → Key 교환
프록시 → "나 클라이언트야" (프록시가 속임) → 서버랑 Key 교환

이 원리는 중간자 공격(MITM)과 동일하다.

Socket Injection

클라이언트가 프록시로 접속하게 만들기 위해 드라이버를 사용자 PC에 설치한다. 이 드라이버가 소켓이 열릴 때 목적지 IP를 프록시 IP로 바꿔치기하는 방식이다.

DMA (Direct Memory Access)란?

일반적인 패킷 수집 흐름

NIC 카드 버퍼 (랜카드)
    ↓ 복사 1번
커널 메모리 (OS)
    ↓ 복사 2번
솔루션 버퍼 (보안 프로그램)

패킷 하나가 복사를 두 번 당해서 느리고 메모리 낭비가 발생한다.

DMA 방식

솔루션이 미리 버퍼를 만들어서 NIC에 전달하면, NIC가 패킷을 해당 버퍼에 직접 쓰는 방식이다.

NIC 카드 버퍼 → 솔루션 버퍼 (복사 1번으로 끝!)

택배가 물류센터를 거치지 않고 집으로 바로 오는 것

DMA 장단점

OLE (Object Linking and Embedding)이란?

OLE란 다른 프로그램에서 만든 객체를 문서 안에 삽입하거나 연결하는 기술이다.

워드 문서 안에 엑셀 표를 넣는 것이 OLE이다.

보안에서 OLE가 중요한 이유

OLE 객체 안에 악성코드를 숨길 수 있다. 워드 파일 안에 OLE 객체로 악성 매크로가 숨어있는 경우가 있으며, 이메일 피싱 공격에서 많이 사용되는 방식이다.

스테가노그래피 (Steganography)란?

스테가노그래피란 데이터를 다른 데이터 안에 숨기는 기술이다.

암호화와의 차이점은 다음과 같다.

• 암호화 : 내용을 못 읽게 변환 (숨긴다는 걸 알 수 있음)
• 스테가노그래피 : 데이터가 숨겨져 있다는 것 자체를 모르게 함

이미지에서 예시

이미지 픽셀의 색상값 마지막 비트를 살짝 바꿔도 사람 눈으로는 차이를 느끼지 못한다. 그 비트에 데이터를 숨기는 것이다.

원본 픽셀값: 11001010
숨긴 픽셀값: 11001011  ← 마지막 비트만 바꿈

보안에서는 정상적인 이미지 파일 안에 악성코드를 숨겨서 전송하는 방식으로 악용된다.

OCR (Optical Character Recognition)이란?

OCR이란 이미지나 스캔된 문서에서 텍스트를 자동으로 인식하는 기술이다.

손으로 쓴 글씨나 인쇄된 글자를 컴퓨터가 인식해서 텍스트로 변환하는 것

보안 솔루션에서는 이미지 안에 텍스트로 숨겨진 악성코드를 탐지할 때 OCR을 활용하기도 한다.

메타데이터 종류란?

기술 메타데이터 (Technical Metadata)

파일의 기술적인 정보를 담고 있는 것이다.

• 이미지 → 해상도, 파일 크기, 색상 정보, 촬영 카메라 모델
• 동영상 → 코덱, 해상도, 프레임레이트
• 문서 → 파일 형식, 인코딩 방식

구조 메타데이터 (Structural Metadata)

파일이 어떻게 구성되어 있는지 나타내는 것이다.

• 책 → 목차, 챕터 구조, 페이지 번호
• 데이터베이스 → 테이블 구조, 컬럼 정보
• 웹페이지 → HTML 태그 구조

관리 메타데이터 (Administrative Metadata)

파일을 관리하기 위한 정보이다.

• 생성일, 수정일, 작성자
• 저작권 정보
• 접근 권한

보안에서 메타데이터가 중요한 이유

이미지 파일을 보내면서 모른다고 해도 메타데이터에 촬영 위치, 기기 정보, 작성자 정보가 남아있다. 포렌식할 때 메타데이터가 증거로 중요하게 활용된다.

마무리

오늘은 스토리지 관리부터 프록시, DMA, 보안 개념까지 다양한 내용을 학습하였다. 각 개념들이 보안 솔루션에서 어떻게 연결되는지 조금씩 보이기 시작하였다. 앞으로도 모르는 개념이 나올 때마다 찾아보고 정리하는 습관을 이어나갈 예정이다.

풀패킷 캡처 vs 일반 패킷 수집이란?

패킷을 수집하는 방식에는 두 가지가 있다.

택배로 비유하자면, 일반 패킷 수집은 송장만 보는 것이고, 풀패킷 캡처는 박스를 열어서 내용물까지 확인하는 것이다.

풀패킷 캡처는 용량 부담이 크지만, 침해사고 발생 시 원본 패킷을 재현해야 하거나 법적 증거 및 정밀 포렌식이 필요할 때 반드시 필요하다.

디지털 포렌식이란?

디지털 포렌식이란 사건이 발생한 후 디지털 증거를 수집하고 분석해서 무슨 일이 있었는지 밝혀내는 것이다.

디지털 데이터는 삭제해도 흔적이 남는다는 원리를 기반으로 한다.

• 파일을 삭제해도 실제 데이터는 디스크에 남아있다.
• 패킷 캡처본으로 당시 통신을 복원할 수 있다.
• 로그로 누가 언제 무엇을 했는지 추적할 수 있다.

포렌식 흐름

사고 발생
    ↓
증거 수집 (패킷, 로그, 파일, 메모리 등)
    ↓
증거 보존 (원본 훼손 방지)
    ↓
분석 (무슨 일이 있었는지 재구성)
    ↓
보고서 작성 (법적 증거로 활용)

풀패킷 캡처가 포렌식에 필요한 이유

요약본(로그)만 있으면 "이 IP가 접속했다" 정도만 알 수 있다. 반면 풀패킷이 있으면 "이 IP가 접속해서 이런 데이터를 주고받았다" 까지 복원이 가능하다.

범인이 어떤 공격을 했는지 당시 상황을 그대로 재현할 수 있기 때문에, 풀패킷 캡처는 침해사고 분석과 법적 증거 확보에 있어 핵심적인 역할을 한다.

풀패킷 데이터는 어떻게 관리할까?

풀패킷을 무한정 쌓으면 디스크가 감당이 안 되기 때문에, 실무에서는 보존 기간을 정해두고 관리한다.

풀패킷 계속 수집
    ↓
30일 지난 데이터 자동 삭제
    ↓
디스크 용량 일정하게 유지

• 보존 기간을 정해두고 일정 기간이 지나면 자동 삭제한다.
• 법적으로 요구되는 보존 기간이 있는 경우 그에 맞춰서 관리한다.
• 결국 용량 vs 보존 기간 의 트레이드오프이다.

디스크가 넉넉하면 오래 보관하고, 그렇지 않으면 보존 기간을 짧게 가져간다.

참고로 "삭제해도 흔적이 남는다"는 것과 풀패킷 관리는 별개의 개념이다.

파일을 삭제한다는 것은 실제 데이터를 지우는 것이 아니라, "이 공간을 써도 된다"는 표시만 바꾸는 것이다. 마치 도서관에서 책을 반납했을 때 책 자체가 사라지는 게 아니라 "대출 가능" 표시로 바뀌는 것과 같다. 즉 새로운 데이터가 덮어쓰기 전까지는 원본 데이터가 디스크에 그대로 남아있어 복구가 가능하다.

풀패킷 보존 기간 관리는 이와 무관하게 운영 정책에 따라 의도적으로 삭제하는 것이다.

DPI (Deep Packet Inspection)란?

DPI란 패킷이 지나가는 순간 실시간으로 내용을 분석하는 기술이다.

일반적인 패킷 검사는 헤더만 확인하지만, DPI는 헤더와 내용(payload)까지 전부 들여다본다.

패킷 지나감
    ↓
DPI가 실시간으로 내용 분석
    ↓
원본 패킷은 버림
    ↓
분석 결과만 로그로 저장

일반 검사 = 편지 봉투만 보는 것 (보낸 사람, 받는 사람)
DPI = 봉투를 열어서 편지 내용까지 읽는 것

보안 솔루션에서 DPI를 쓰는 이유는 악성코드 탐지, 특정 키워드 필터링, 비정상 트래픽 감지 등은 헤더만 봐서는 알 수 없고 내용까지 분석해야 하기 때문이다.

세션(Session)이란?

세션이란 두 대상이 연결되어 있는 시간 동안의 상태를 말한다.

HTTP는 원래 무상태(Stateless) 프로토콜이라 매 요청마다 사용자를 기억하지 못한다. 그래서 로그인 상태를 유지하기 위해 세션을 사용한다.

로그인 성공
    ↓
서버가 세션 ID 발급
    ↓
브라우저가 세션 ID 들고 다님
    ↓
다음 요청에 세션 ID 보내면 서버가 사용자를 알아봄

세션 로그란?

세션 로그란 누가 언제 어디에 얼마나 접속했는지를 기록하는 것이다.

세션 로그에 남는 정보는 다음과 같다.

• 세션 ID
• 출발지 IP / 목적지 IP
• 시작 시간 / 종료 시간
• 사용한 프로토콜 (TCP, UDP 등)
• 전송된 데이터 양
• 접속한 포트

풀패킷은 내용을 전부 저장하는 반면, 세션 로그는 접속 정보를 기록하는 것이라 용량이 작고 이상 행동 탐지에 효과적이다.

세션 관리란?

세션 관리란 접속한 사용자의 연결 상태를 추적하고 제어하는 것이다.

• 세션 생성 : 누가 언제 접속했는지 기록한다.
• 세션 유지 : 접속 중인 상태를 계속 추적한다.
• 세션 만료 : 일정 시간 이후 자동으로 종료한다.
• 세션 종료 : 로그아웃 시 완전히 끊는다.

헬스장 입장 관리와 비슷하다.
회원이 들어오면 기록하고(생성), 안에 있는 동안 추적하고(유지), 오래 있으면 퇴장 안내하고(만료), 나가면 기록을 종료한다(종료).

보안에서 세션 관리가 중요한 이유

세션 관리가 제대로 되지 않으면 다음과 같은 문제가 발생할 수 있다.

• 로그아웃 후에도 세션 ID 재사용 가능 → 탈취 위험
• 세션 만료가 없으면 평생 로그인 상태 유지 → 보안 취약
• 동시 접속 제한이 없으면 세션 하이재킹 감지 불가

세션 관리는 세션 하이재킹을 완전히 막는 것이 아니라, 탐지하고 피해를 최소화하는 역할을 한다. 완벽한 보안을 위해서는 세션 관리 + HTTPS + 추가 인증을 함께 사용해야 한다.

보안은 100% 막는 것이 목표가 아니라, 공격자가 들어오기 어렵게 만들고 들어와도 빠르게 잡아내는 것이 목표이다.

세션 하이재킹(Session Hijacking)이란?

세션 하이재킹이란 다른 사람의 세션 ID를 탈취해서 그 사람인 척 하는 공격이다.

피해자가 로그인
        ↓
서버가 세션 ID 발급 (ex. abc123)
        ↓
공격자가 세션 ID 탈취
        ↓
공격자가 abc123 들고 서버에 접속
        ↓
서버는 피해자로 인식

탈취 방법으로는 네트워크 스니핑, XSS 공격으로 쿠키 탈취, 공개 와이파이에서 가로채기 등이 있다.

동시 접속 제한이 있으면 같은 계정이 두 곳에서 동시 접속할 때 이상을 감지할 수 있어 세션 하이재킹 탐지에 도움이 된다.

SCP (Secure Copy Protocol)란?

SCP란 파일을 네트워크를 통해 안전하게 전송하는 명령어이다. SSH 암호화를 기반으로 동작한다.

# 내 PC → 서버로 보내기
scp 파일명 user@서버IP:/목적지경로

# 서버 → 내 PC로 받기
scp user@서버IP:/파일경로 ./

SSH가 전화 통화라면, SCP는 택배를 보내는 것이다.

WinSCP의 이름도 Windows + SCP에서 나온 것이다.

Fabric이란?

Fabric이란 Python 기반의 자동화 배포 툴이다. 여러 서버에 동시에 명령어를 실행하거나 파일을 배포할 수 있다.

수동 설치 = 음식 10인분 손으로 직접 만들기
Fabric 설치 = 레시피 짜놓고 한 번에 10인분 만들기

보안 솔루션을 여러 고객사 서버에 배포할 때 Fabric을 사용하면 효율적으로 작업할 수 있다.

소켓 통신 vs HTTP 통신이란?

HTTP 통신

요청하면 응답하고 연결이 종료되는 방식이다.

클라이언트 → "나 이 페이지 줘" → 서버
클라이언트 ← "여기" ← 서버
연결 종료

소켓 통신

한 번 연결하면 계속 연결을 유지하는 방식이다.

클라이언트 ↔ 서버 (연결 유지)
클라이언트 → 서버 (언제든 전송 가능)
서버 → 클라이언트 (언제든 전송 가능)

HTTP = 편지 주고받기, 보내고 답장 오면 끝
소켓 = 전화 통화, 연결되면 서로 언제든 말할 수 있음

보안 솔루션에서 소켓 통신을 쓰는 이유

로그는 1초에 수백 수천 개가 발생한다. HTTP 통신으로 로그를 수집하면 로그가 생길 때마다 연결을 맺고 끊는 작업을 반복해야 하므로 오버헤드가 엄청나게 크다.

반면 소켓 통신은 한 번 연결해두고 계속 실시간으로 데이터를 흘려보낼 수 있어 로그 수집에 훨씬 효율적이다.

HTTP = 편지 올 때마다 우체국 갔다오기
소켓 = 전화 연결해두고 계속 말하기

Keep-Alive란?

소켓 통신은 한 번 연결해두고 계속 유지하는 방식이지만, 네트워크 장비(방화벽, 라우터 등)가 일정 시간 동안 아무 데이터도 오가지 않으면 연결을 강제로 끊어버린다.

여기서 의문이 들었다. 그냥 계속 연결 상태로 설정해두면 되지 않을까? 굳이 Keep-Alive 방식을 써야 하는 이유가 뭘까?

결론부터 말하면 "그냥 계속 유지"를 네트워크 장비가 허락하지 않는다.

편의점 자동문이 사람이 서있어도 일정 시간 움직임이 없으면 닫혀버리는 것처럼, 네트워크 장비도 데이터가 없으면 연결을 끊어버린다. Keep-Alive는 주기적으로 신호를 보내 "우리 아직 통신 중이야"라고 알려주는 것이다.

즉 Keep-Alive 자체가 곧 계속 연결을 유지하는 방법인 것이다.

클라이언트 ──────────────────── 서버
     │                           │
     │──── 데이터 전송 ─────────→│
     │                           │
     │   (일정 시간 데이터 없음)  │
     │                           │
     │──── "나 살아있어" ────────→│  ← Keep-Alive 신호
     │←─── "ㅇㅇ 확인" ──────────│
     │                           │
     │──── 데이터 전송 ─────────→│

만약 Keep-Alive 신호에도 응답이 없으면 연결이 끊겼다고 판단하고 자동으로 재연결을 시도한다.

shmget이란?

shmget(Shared Memory Get)이란 리눅스에서 공유 메모리 세그먼트를 생성하거나 가져오는 시스템 콜이다.

여러 프로세스가 같은 메모리 공간을 공유해서 데이터를 주고받을 때 사용하는 함수이다.

프로세스 A ──┐
             ├──→ 공유 메모리 (shmget으로 생성)
프로세스 B ──┘

프로세스끼리 데이터를 주고받는 방법은 여러 가지가 있지만, 공유 메모리 방식은 메모리를 직접 공유하기 때문에 속도가 매우 빠르다는 장점이 있다.

보안 솔루션에서 쓰는 이유

네트워크 패킷이나 로그를 수집할 때는 프로세스 간 데이터 전달이 매우 빠르게 이루어져야 한다. 소켓이나 파이프 방식보다 공유 메모리 방식이 훨씬 빠르기 때문에, 고성능이 요구되는 보안 솔루션에서 shmget을 활용한 공유 메모리 방식을 많이 사용한다.

마무리

오늘은 패킷 수집 방식의 차이부터 세션 관리, 프로세스 간 통신까지 다양한 개념을 학습하였다. 하나의 개념이 다른 개념으로 꼬리를 물며 연결되는 것을 느꼈고, 보안 솔루션이 왜 이런 방식으로 설계되었는지 조금씩 이해되기 시작하였다. 앞으로도 모르는 개념이 나올 때마다 찾아보고 정리하는 습관을 이어나갈 예정이다.

ojt때 사내 솔루션에 대한 교육을 듣는데, 중간 중간 들은 내용들에서 모르는 기초 개념들이랑 헷갈리는 개념들이 많아 이 글을 통해 정리하고자 작성하게되었다.

RAID란?

RAID(Redundant Array of Independent Disks)란 여러 개의 디스크를 묶어서 하나처럼 사용하는 기술이다. 목적은 크게 두 가지로, 성능 향상과 데이터 안전성 확보이다.

RAID 레벨별 특징

핵심 개념

• 스트라이핑 : 데이터를 여러 디스크에 나눠서 저장하는 방식이다. RAID 0, 5, 6, 10에서 사용된다.
• 미러링 : 데이터를 여러 디스크에 동일하게 복사하는 방식이다. RAID 1에서 사용된다.
• 패리티 : 디스크 장애 시 데이터를 복구하기 위한 복구용 정보이다.

외우는 법

• RAID 0 = 숫자 0처럼 안전성 제로, 속도만 존재
• RAID 1 = 일란성 쌍둥이, 똑같은 데이터 1개 더 보관
• RAID 5 = 보험 1개, 패리티 1개로 디스크 1개 장애 복구 가능
• RAID 6 = 보험 2개, 패리티 2개로 디스크 2개 장애 복구 가능
• RAID 10 = 이름 그대로 RAID 1 + RAID 0

tar 명령어란?

tar란 리눅스에서 파일을 압축하거나 압축을 해제할 때 사용하는 명령어이다.

기본 사용법

tar zxvf 파일명.tgz

옵션 설명

f 옵션은 반드시 마지막에 위치해야 한다.

윈도우와 리눅스의 차이

윈도우에서는 설치 파일(.exe)을 실행하면 해당 위치에 프로그램이 설치된다. 반면 리눅스에서는 tgz 압축을 해제하면 설치용 파일들이 나오고, 그 안의 install.sh 같은 스크립트를 실행하면 /usr/, /opt/, /etc/ 같은 정해진 위치에 자동으로 설치된다.

쉽게 말해 tmp 디렉토리는 택배 박스를 뜯는 공간이고, 실제 물건은 집 안 제자리로 들어가는 구조이다.

수집과 로깅의 차이란?

보안 솔루션을 공부하다 보면 수집과 로깅이라는 단어가 자주 등장한다. 두 개념은 비슷해 보이지만 엄연히 다르다.

• 수집 : 데이터를 여기저기서 가져오는 행위이다.
• 로깅 : 가져온 데이터를 파일이나 DB에 기록하는 행위이다.

수집이 먼저 이루어지고, 그 다음 로깅이 이루어지는 순서이다.

로그 = 기록된 데이터 (결과물)
로깅 = 로그를 기록하는 행위 (과정)

transfer와 transmit의 차이란?

보안 솔루션에서 데이터 흐름을 설명할 때 자주 등장하는 두 용어이다.

보안 솔루션 관점에서의 차이

• transmit : 장비에서 발생한 로그를 수집 서버로 전송하는 행위이다. 원본 데이터는 그대로 유지되며 복사되어 전달된다.
• transfer : 수집된 로그 파일 자체가 한 위치에서 다른 위치로 이동하는 행위이다. 파일 분리도 이 단계에서 이루어진다.

SNMP란?

SNMP(Simple Network Management Protocol)란 네트워크 장비(라우터, 스위치, 서버 등)를 중앙에서 모니터링하고 관리하기 위한 프로토콜이다.

구조

동작 방식

• Get : Manager가 Agent에게 정보를 요청한다.
• Set : Manager가 Agent의 설정을 변경한다.
• Trap : Agent가 이상을 감지했을 때 Manager에게 능동적으로 알림을 보낸다.

병원으로 비유하자면, 의사(Manager)가 각 병실(장비)을 돌며 상태를 확인하고, 간호사(Agent)가 보고하는 구조이다. 환자 상태가 위급할 때 간호사가 먼저 연락하는 것이 Trap에 해당한다.

NCPS란?

NCPS(Network Content Processing System)란 네트워크로 지나가는 패킷을 캡처하여 내용을 분석하는 시스템이다.

전체 데이터 흐름

네트워크 트래픽 유입
        ↓
NCPS (패킷 캡처 & 분석)
        ↓
Writer (로그 파일 기록)
        ↓
Transfer (파일 이동 & 분리)
        ↓
Decoder (데이터 해석 & 파싱)

스위치 미러(포트 미러링)와 미러링 탭(TAP)이란?

네트워크 트래픽을 복사하여 보안 장비나 분석 장비로 보내는 두 가지 방식이다.

스위치 미러 (포트 미러링)이란?

스위치에서 지나가는 트래픽을 소프트웨어적으로 복사하여 다른 포트로 보내는 방식이다. 원본 트래픽은 그대로 흐르고, 복사본을 분석 장비로 전달한다.

미러링 탭 (TAP, Test Access Point)이란?

네트워크 케이블 중간에 물리적으로 끼워서 트래픽을 복사하는 전용 장비이다. 스위치 설정 없이도 트래픽을 그대로 캡처할 수 있다.

비교

고객사가 미러링 탭을 선호하는 이유

스위치 미러는 스위치가 본래 업무와 트래픽 복사를 동시에 처리하기 때문에, 부하가 높아지면 미러링 트래픽을 먼저 버린다. 즉 스위치 입장에서 미러링은 우선순위가 낮아 유실이 발생할 수 있다.

반면 미러링 탭은 트래픽 복사만을 전담하는 장비라 유실이 거의 없다. 보안 관점에서 패킷 하나라도 유실되면 침해사고를 탐지하지 못할 수 있기 때문에, 비용이 더 비싸더라도 미러링 탭을 선호하는 것이다.

하둡(Hadoop)과 HDFS란?

하둡이란?

하둡(Hadoop)이란 대용량 데이터를 여러 서버에 나눠서 저장하고 처리하는 오픈소스 분산 처리 프레임워크이다.

HDFS란?

HDFS(Hadoop Distributed File System)란 하둡 안에서 파일 저장을 담당하는 분산 파일 시스템이다. 하둡이 더 큰 개념이고, HDFS는 그 안의 저장소 역할을 담당한다.

하둡 (Hadoop)
    ├── HDFS (파일 시스템 - 저장 담당)
    ├── MapReduce (데이터 처리 담당)
    └── YARN (자원 관리 담당)

하둡 = 건물 전체, HDFS = 건물 안에 있는 창고

HDFS 구조

HDFS 핵심 특징

• 데이터를 블록 단위로 쪼개서 여러 DataNode에 분산 저장한다.
• 블록을 3개씩 복제하여 저장하기 때문에, 서버 하나가 죽어도 데이터가 유실되지 않는다.
• 한 번 쓰면 수정이 어려운 구조로, 읽기에 최적화되어 있다.

RAID와 비교

JuiceFS란?

JuiceFS란 HDFS와 동일한 역할을 하지만 저장소를 클라우드(S3 등 오브젝트 스토리지)로 바꾼 분산 파일 시스템이다.

HDFS vs JuiceFS 구조 비교

HDFS
    ├── 메타데이터 → NameNode (전용 서버)
    └── 실제 데이터 → DataNode (전용 서버)

JuiceFS
    ├── 메타데이터 → Redis / MySQL (DB)
    └── 실제 데이터 → S3 (클라우드 스토리지)

S3랑 JuiceFS의 관계

S3는 데이터를 저장하는 스토리지이지만, 파일 시스템이 아니라서 HDFS처럼 쓰기가 불편하다. JuiceFS가 S3 위에 올라타서 S3를 HDFS처럼 사용할 수 있게 만들어주는 역할을 한다.

S3 = 그냥 하드디스크
JuiceFS = 그 하드디스크를 파일 시스템으로 만들어주는 것

한 줄 요약

JuiceFS = HDFS랑 똑같은 역할인데 저장소만 클라우드(S3)로 바꾼 것

마무리

오늘은 기초적인 스토리지 개념부터 네트워크 프로토콜, 그리고 실제 솔루션의 데이터 흐름까지 학습하였다. 생소한 개념들이 많아 어렵게 느껴졌지만, 하나씩 정리하다 보니 전체적인 흐름이 조금씩 보이기 시작하였다. 앞으로도 모르는 개념이 나올 때마다 찾아보고 정리하는 습관을 이어나갈 예정이다.

보안 회사에 입사 후 이것저것 개념을 배우게 되었는데, Hadoop, Kafka, DB, Elasticsearch 등 각각의 개념은 알고 있었지만 이것들이 실제로 어떻게 상호작용하는지에 대해서는 깊게 고민해본 적이 없었다. 이번 기회에 그 고민을 정리하고, AI의 도움을 받아 작성한 글이다.

📦 전체 저장소 한눈에 비교

🐘 Hadoop이란

대용량 데이터를 여러 서버에 분산 저장하고 처리하는 시스템이다.

엄청 큰 데이터
→ 여러 서버에 쪼개서 저장 (HDFS)
→ 각 서버에서 동시에 분석 (MapReduce)
→ 결과 합치기

Hadoop의 핵심 개념: 클러스터

여러 서버가 하나처럼 동작하는 묶음을 클러스터라고 한다. Hadoop은 이 클러스터 단위로 데이터를 나눠서 저장한다.

A 클러스터 (데이터 적음)     B 클러스터 (데이터 많음)
├── 서버1                   ├── 서버1
└── 서버2                   ├── 서버2
   (2~3대면 충분)            ├── 서버3
                            ...
                            └── 서버100
                               (수십~수백대 필요)

데이터가 많을수록 서버를 더 늘리는 것을 스케일 아웃이라고 한다.

Hadoop vs 일반 DB

Hadoop에서 SQL처럼 쿼리하기 (Hive)

Hadoop은 원래 SQL 문법이 없는데, Hive라는 도구를 쓰면 SQL과 거의 동일하게 쿼리할 수 있다.

-- 일반 DB
SELECT * FROM PAMATHS;

-- Hive (Hadoop)
SELECT * FROM PAMATHS;  -- 거의 똑같다

📨 Kafka란

대용량 메시지 큐 시스템이다. 데이터를 중간에서 받아서 전달해주는 역할을 한다.

[데이터 발생] → [Kafka] → [처리 서버]

생산자(Producer)가 메시지를 던지면, Kafka가 받아서 쌓아두고, 소비자(Consumer)가 꺼내가는 구조다.

Kafka vs Redis — 둘 다 큐로 쓸 수 있는데 차이가 있을까

🦁 Zookeeper란

Kafka 서버들을 관리하고 조율해주는 도구다.

Kafka가 여러 서버에 분산돼서 돌아갈 때, 그 서버들이 살아있는지 죽었는지 확인하고 관리해준다.

[Kafka 서버1]  [Kafka 서버2]  [Kafka 서버3]
        ↑            ↑            ↑
               [Zookeeper]
        "얘네 다 살아있나? 관리해줄게"

⚠️ Zookeeper는 Hadoop이 아닌 Kafka를 관리한다. 처음에 헷갈리기 쉬운 부분이다.

요즘은 Kafka가 Zookeeper 없이도 동작하도록 업데이트됐지만, 아직 같이 쓰는 곳이 많다.

🔍 Elasticsearch란

검색 특화 저장소이다. 일반 DB보다 키워드 검색이 훨씬 빠르다.

-- 일반 DB 검색
SELECT * FROM PAMATHS WHERE NAME LIKE '%이나형%';
-- → 전체 데이터 다 뒤짐 → 느림

-- Elasticsearch
GET /pamaths/_search
{
  "query": {
    "match": { "NAME": "이나형" }
  }
}
-- → 미리 색인해둠 → 바로 찾음

Elasticsearch는 DB에 붙이는 플러그인일까

처음에 이 부분에 대한 고민을 해보았는데, 정답은 아니었다. Elasticsearch는 DB에 붙이는 것이 아닌 독립적인 저장소이다.

[DB] ──→ 데이터 복사 ──→ [Elasticsearch]
  원본 저장                검색용으로 따로 저장
                               ↑
                          [백엔드 API] ← [UI에서 검색]

DB는 원본 저장, Elasticsearch는 검색용 복사본이라고 생각하면 된다.

⚡ Redis란

메모리 기반 초고속 저장소이다. 휘발성이라 서버가 꺼지면 데이터가 날아간다.

컴퓨터 구조로 비유하면 아래와 같다.

Redis = RAM (빠르고 휘발성) 일반 DB = HDD/SSD (느리고 영구적)

Redis가 하는 일이 너무 많은 것 아닐까

Redis를 처음 접했을 때 하는 일이 너무 많아서 만능처럼 느껴졌는데, 핵심은 하나이다.

메모리에 데이터를 저장하는 초고속 저장소

나머지는 그 특성 덕분에 파생된 역할들이다.

• 빠르니까 → 캐싱
• 빠르니까 → 세션 저장소
• 빠르니까 → 중복 체크 (멱등성 보장)
• 빠르니까 → 메시지 큐

멱등성이란

같은 작업을 여러 번 해도 결과가 1번 한 것과 같은 것

같은 로그가 네트워크 오류로 3번 전송됨
→ 멱등성 없으면: 로그 3개 저장됨 (중복)
→ 멱등성 있으면: 1개만 저장됨 (정상)

Redis가 "이미 처리한 ID"를 기억해둬서 중복을 막아주는 방식으로 멱등성을 보장한다.

☁️ S3 Glacier란

AWS S3의 초저가 장기 보관 전용 버전이다.

단점은 데이터 꺼내는 데 몇 시간씩 걸린다는 것이다. 자주 꺼내볼 데이터엔 맞지 않고, 법적으로 보관만 해야 하는 데이터에 적합하다.

🏗️ 실제로 다 같이 쓰면 어떻게 될까

보안 로그 시스템을 예시로 들면 아래와 같다.

로그 발생
    ↓
[Kafka] → 대량 로그 안전하게 받아서 쌓아둠
    ↓
[Redis] → 중복 로그 체크 (멱등성 보장)
    ↓
[DB] → 최근 1달 로그 저장 (빠른 조회용)
[Elasticsearch] → 키워드 검색용
[S3 Glacier] → 1년 이상 로그 장기 보관

각각 역할이 달라서 겹치지 않는다. 마트로 비유하면 아래와 같다.

• DB = 냉장고 (자주 쓰는 것)
• Elasticsearch = 검색대 (빠르게 찾기)
• Hadoop / S3 Glacier = 창고 (오래된 것 보관)
• Redis = 계산대 옆 바구니 (잠깐 올려두는 곳)
• Kafka = 물류 트럭 (데이터 실어 나르는 것)

공부하면서 헷갈렸던 것들

Hadoop이 대용량 데이터를 처리한다고 했는데, 그러면 빠른 것일까

이 부분에 대해 고민해보았는데, Hadoop이 빠른 것이 아니었다.

빠른 게 아니라, 혼자였으면 불가능한 것을 여럿이 나눠서 그나마 할 수 있다는 개념이다.

일반 DB 서버 1대 → 1억건 혼자 처리 → 불가능
Hadoop 서버 100대 → 각자 100만건씩 나눠서 동시 처리 → 가능

몇만건 데이터 조회가 30분 걸리면 Hadoop을 써야 할까

이에 대한 고민을 해보았는데, 정답은 아니었다. 몇만건은 Hadoop을 쓰기엔 너무 작은 규모이다.

진짜 원인은 따로 있을 가능성이 높다.

• 인덱스가 없는 경우 → 인덱스 추가로 해결
• 쿼리가 비효율적인 경우 → 쿼리 튜닝으로 해결
• 서버 사양이 낮은 경우 → 서버 업그레이드

Hadoop은 수억건 이상일 때 고려하는 것이다.

Zookeeper가 Hadoop 서버를 감시하는 것일까

처음에 Zookeeper가 Hadoop 서버를 감시한다고 생각했는데, 이는 잘못된 이해였다. Zookeeper는 Kafka 서버들을 관리한다. Hadoop과는 직접적인 관계가 없다.

Elasticsearch는 DB에 붙이는 플러그인일까

처음에 이 부분에 대한 고민을 해보았는데, 정답은 아니었다. Elasticsearch는 DB에 붙이는 것이 아닌 독립적인 저장소이다. DB의 데이터를 복사해서 Elasticsearch에 따로 저장해두고, 검색할 땐 DB 말고 Elasticsearch에 물어보는 방식이다.

저장소가 DB, Hadoop, Elasticsearch, S3 Glacier 다 따로 있으면 너무 많은 것 아닐까

이에 대한 고민을 해보았는데, 다 역할이 다르기 때문에 어쩔 수 없다는 결론이 나왔다. 각자 잘하는 것이 다르기 때문에 용도에 맞게 골라 쓰는 것이다.

보안 솔루션 엔지니어로 새롭게 취업하게 되었다. 그동안 배워왔던 클라우드/인프라 개념과는 결이 조금 다른, 네트워크 장비와 보안 기술들을 이번 기회에 한번 제대로 정리해보았다.

🌐 네트워크 장비

방화벽 (Firewall)

방화벽은 네트워크 트래픽을 허용(Allow) 또는 차단(Deny) 하는 보안 장비다. 미리 정의된 정책(Rule)에 따라 출발지 IP, 목적지 IP, 포트, 프로토콜을 기준으로 패킷을 필터링한다.

Linux 환경에서는 iptables 또는 nftables를 이용해 소프트웨어 방화벽을 구성할 수 있다.

# 특정 포트 허용 예시 (iptables)
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# 특정 IP 차단
iptables -A INPUT -s 192.168.1.100 -j DROP

IDS / IPS

IDS (Intrusion Detection System) — 침입 탐지 시스템

IDS는 Intrusion Detection System의 약자로, 네트워크 또는 시스템에서 발생하는 비정상적인 행위를 탐지하고 관리자에게 알림을 주는 시스템이다. 직접 차단하지는 않고 탐지 및 경보 역할만 수행한다.

🔍 비유하자면, CCTV처럼 이상한 행동을 감지하고 알려주지만 직접 막지는 않는다.

IPS (Intrusion Prevention System) — 침입 차단 시스템

IPS는 Intrusion Prevention System의 약자로, IDS의 탐지 기능에 능동적인 차단 기능이 추가된 시스템이다. 이상 트래픽을 감지하면 실시간으로 세션을 끊거나 패킷을 드롭한다.

🛡️ 비유하자면, 경비원처럼 이상한 행동을 감지하는 동시에 직접 제지한다.

L2 / L3 스위치

L2 스위치 (데이터링크 계층)

L2 스위치는 MAC 주소 기반으로 동작하는 스위치다. 같은 네트워크(동일 서브넷) 내의 장비들이 통신할 수 있도록 프레임을 전달한다. MAC 주소 테이블을 학습해 목적지 포트로만 트래픽을 전송하며, VLAN 구성이 가능하다.

L3 스위치 (네트워크 계층)

L3 스위치는 IP 주소 기반으로 라우팅 기능까지 수행하는 스위치다. 서로 다른 서브넷(VLAN 간) 통신을 처리할 수 있어, 소규모~중규모 네트워크에서 라우터 역할을 대신하기도 한다.

SIP (Session Initiation Protocol)

SIP는 VoIP(인터넷 전화), 영상통화 등 멀티미디어 세션을 개시·종료하는 애플리케이션 계층 프로토콜이다. 텍스트 기반 프로토콜로 HTTP와 구조가 유사하며, 기본 포트는 UDP/TCP 5060, TLS 사용 시 5061을 사용한다.

기본 흐름 (콜 설정)

Client --INVITE-->  Server
Client <--100 Trying--
Client <--180 Ringing--
Client <--200 OK--
Client --ACK-->     Server
         (통화 중)
Client --BYE-->     Server
Client <--200 OK--

보안 관점에서는 SIP Flooding, SIP Spoofing 같은 공격이 발생할 수 있어, SBC(Session Border Controller) 장비로 보호하는 경우가 많다.

TAP / 포트 미러링

보안 장비(IDS, 패킷 분석 등)가 트래픽을 수집하기 위해 사용하는 방법이다.

Network TAP (Test Access Point)

물리 장비로, 네트워크 케이블 사이에 인라인으로 설치해 트래픽을 복사해서 별도 장비로 전달한다. 원본 트래픽에 영향을 주지 않으며, 전원이 꺼져도 통신이 유지된다는 장점이 있다.

Port Mirroring (SPAN)

스위치 기능으로, 특정 포트의 트래픽을 다른 모니터링 포트로 복사한다. 별도 장비 없이 설정만으로 구성 가능하지만, 스위치 부하가 증가할 수 있다.

NAS (Network Attached Storage)

NAS는 네트워크에 연결된 파일 스토리지 장비다. 여러 서버/클라이언트가 네트워크를 통해 공유 스토리지에 접근할 수 있도록 한다.

주요 프로토콜

SAN vs NAS

보안 관점에서는 접근 제어(ACL), 스냅샷, 암호화 설정이 중요하다.

🔐 보안 기술

패킷 스니핑 / 스푸핑

스니핑 (Sniffing)

(이 개념은 조금 어렵게 느껴져서 ai의 도움을 많이 받았다.) 스니핑은 네트워크 상에서 자신에게 오지 않는 패킷을 몰래 엿보는 행위다.

네트워크에서 패킷은 목적지 주소가 적혀 있어서, 원래는 내 컴퓨터로 온 패킷만 수신한다. 그런데 랜카드(NIC)를 Promiscuous Mode(무차별 모드) 로 설정하면, 목적지가 나 아닌 패킷도 전부 수신하도록 필터를 꺼버릴 수 있다.

이를 이용해 같은 네트워크 대역에 흘러다니는 트래픽을 몽땅 캡처하는 것이 스니핑이다. 대표적인 도구로는 tcpdump, Wireshark가 있다.

이 글로만 보면 tcpdump와 Wireshark는 나쁜 해킹 도구인가? 했는데, 찾아보니 양날의 검이라는 것을 알 수 있었다. 예를 들어, 다음과 같은 용도에서 tcpdump와 Wireshark는 사용이 가능하다.

반면, 공격자가 허가 없이 남의 네트워크에서 사용하면 스니핑 공격이 된다. 칼이 요리도구냐 흉기냐는 누가, 어디서, 어떤 목적으로 쓰느냐에 달린 것처럼 tcpdump와 Wireshark도 마찬가지인 것이다.

스푸핑 (Spoofing)

출발지 주소를 위조해 다른 시스템인 척 통신하는 공격이다.

ARP 스푸핑 / MITM

ARP(Address Resolution Protocol) 는 IP 주소를 MAC 주소로 변환하는 프로토콜이다. ARP는 인증이 없기 때문에, 공격자가 위조된 ARP Reply를 브로드캐스트하면 피해자의 ARP 테이블을 오염시킬 수 있다.

이를 통해 MITM(Man In The Middle) 공격이 가능해진다.

정상:  피해자 ---> 게이트웨이
공격:  피해자 ---> 공격자 ---> 게이트웨이  (공격자가 중간에서 트래픽 감청)

대응 방법

• 스위치의 Dynamic ARP Inspection (DAI) 기능 활성화
• 정적 ARP 엔트리 설정
• IDS/IPS로 비정상 ARP 탐지

추가 글 (패킷을 떠본다의 의미)

스니핑 도구에서 tcpdump를 보면서 패킷을 떠본다는 것이 어떤 의미인지 잘 납득이 가질 않았다. 그래서 이해하기 위해 글을 작성하게 되었다.

🔍 그래서 패킷을 "떠본다"는 게 뭔데?

처음에 이 말이 와닿지 않았다. 패킷을 떠본다는 게 도대체 뭘 보겠다는 건지.

쉽게 말하면 이렇다.

네트워크는 편지가 오가는 우체국 같은 곳이고, 패킷은 그 편지 한 장 한 장이다. tcpdump는 그 편지들을 중간에서 복사해서 내용을 들여다보는 행위다.

실제로 어떤 정보가 보이나?

아래는 tcpdump를 실행했을 때 나오는 출력 예시다.

$ sudo tcpdump -i eth0

-i는 interface의 약자로, 어떤 네트워크 인터페이스(랜카드)에서 패킷을 캡처할지 지정하는 옵션이다. eth0은 리눅스에서 첫 번째 유선 랜카드를 부르는 이름이다. (ethernet 0번) 쉽게 말해 "현관문, 뒷문, 창문 중 어느 쪽을 감시할지" 고르는 것과 같다. 요즘 리눅스는 eth0 대신 ens33, enp0s3 같은 이름을 쓰기도 하니, ip a 명령어로 먼저 내 인터페이스 이름을 확인한다.

위 명령어를 실행하면 다음과 같이 나온다.

14:23:01.123456 IP 192.168.1.10.54321 > 142.250.196.142.443: Flags [S], seq 123456, win 64240
14:23:01.124000 IP 142.250.196.142.443 > 192.168.1.10.54321: Flags [S.], seq 654321, ack 123457
14:23:01.124100 IP 192.168.1.10.54321 > 142.250.196.142.443: Flags [.], ack 654322

한 줄이 패킷 하나다. 처음 보면 암호처럼 느껴지는데, 구조를 알면 읽힌다.

[시간]  [출발지IP.포트]  >  [목적지IP.포트]  [플래그]
14:23:01  192.168.1.10.54321  >  142.250.196.142.443  Flags [S]

위 3줄이 바로 TCP 3-way handshake 과정이다.

뭘 분석하려고 쓰는 건데?

실무에서 tcpdump를 꺼내드는 상황은 보통 이렇다.

1. 통신이 되는지 안 되는지 확인할 때

sudo tcpdump -i eth0 host 192.168.1.1

특정 IP와 패킷이 오가는지 눈으로 확인한다. 패킷이 아예 안 잡히면 네트워크 단에서 막힌 것.

2. 특정 포트로 트래픽이 들어오는지 확인할 때

sudo tcpdump -i eth0 port 443

HTTPS 트래픽만 필터링해서 본다.

3. 비정상적인 트래픽을 잡을 때 평소에 없던 IP로 대량의 패킷이 나가고 있다면? 악성코드나 공격 징후일 수 있다.

Wireshark는 뭐가 다른데?

tcpdump가 터미널에서 텍스트로 패킷을 보여준다면, Wireshark는 같은 정보를 GUI로 시각화해서 보여준다.

초보자라면 Wireshark가 훨씬 보기 편하다. 색깔로 프로토콜을 구분해주고, 클릭하면 패킷 내부 구조를 트리 형태로 펼쳐볼 수 있다.

• tcpdump → 서버에서 빠르게 확인할 때 (GUI 없는 환경)
• Wireshark → 로컬에서 자세히 분석할 때

패킷을 떠본다는 건 결국 "지금 이 네트워크에서 무슨 대화가 오가고 있는지 들여다보는 것" 이다. 장애가 났을 때, 보안 이슈가 생겼을 때, 통신 흐름을 이해하고 싶을 때 — 앞으로 실무에서 자주 쓰게 될 도구다.

🚨 실무에서 "통신이 안 돼요" 하면 어떻게 접근할까?

보안솔루션 엔지니어로 일하다 보면 고객사에서 "갑자기 통신이 안 된다"는 연락이 많이 온다는 것을 주변 실무자들을 통해 알게되었다. 그래서 처음 연락을 받았을 때 어떻게 하면 될지 이 추가 글도 작성하게 되었다. 배우면서 느낀것은, 이때 무작정 tcpdump부터 뜨는 게 아니라, 계층별로 좁혀가는 것이 핵심이라는 것을 알게되었다.

네트워크는 L1(물리) → L2(데이터링크) → L3(네트워크) → L4(전송) 순으로 쌓여있기 때문에, 아래 계층부터 위로 올라가며 하나씩 확인한다.

1단계 — 물리 연결 확인 (L1)

가장 먼저, 케이블이 꽂혀있긴 한지부터 본다.

ip link show          # 인터페이스 상태 확인

eth0: <BROADCAST,MULTICAST,UP,LOWER_UP>   ← UP이면 물리 연결 OK
eth0: <BROADCAST,MULTICAST>               ← LOWER_UP 없으면 케이블 문제

2단계 — 같은 네트워크 내 통신 확인 (L2)

물리 연결은 됐는데 통신이 안 된다면, 같은 스위치에 연결된 장비끼리 통신이 되는지 확인한다.

ping 192.168.1.1      # 같은 대역 게이트웨이에 ping
arp -n                # ARP 테이블 확인 (MAC 주소 학습 여부)

192.168.1.1   ether  aa:bb:cc:dd:ee:ff   ← ARP 있으면 L2 통신 OK
192.168.1.1   (incomplete)               ← ARP 없으면 L2 문제

3단계 — 다른 네트워크와 통신 확인 (L3)

게이트웨이까지는 되는데 외부가 안 된다면, 라우팅 문제다.

ping 8.8.8.8              # 외부 IP로 ping (구글 DNS)
traceroute 8.8.8.8        # 어디서 끊기는지 경로 추적
ip route show             # 라우팅 테이블 확인

$ traceroute 8.8.8.8
1  192.168.1.1    1ms       ← 게이트웨이 (L3 스위치/라우터)
2  10.0.0.1       5ms       ← ISP 구간
3  * * *                    ← 여기서 끊김 → 이 구간 문제

4단계 — 포트/서비스 통신 확인 (L4)

IP는 되는데 특정 서비스만 안 된다면, 포트 차단 문제다.

telnet 192.168.1.10 443       # 특정 포트 열려있는지 확인
nc -zv 192.168.1.10 443       # netcat으로 포트 확인
curl -v https://example.com   # HTTP/HTTPS 응답 확인

$ telnet 192.168.1.10 443
Connected to 192.168.1.10     ← 포트 열려있음
Connection refused            ← 포트 막혀있음 또는 서비스 미실행

5단계 — 그래도 모르겠으면 tcpdump

위 단계를 다 해도 원인을 못 잡겠을 때 tcpdump를 뜬다. "패킷이 실제로 오가고 있는지" 를 눈으로 직접 확인하는 것이다.

# 특정 호스트와의 패킷만 캡처
sudo tcpdump -i eth0 host 192.168.1.10

# 특정 포트만 캡처
sudo tcpdump -i eth0 port 443

# 패킷 내용까지 출력
sudo tcpdump -i eth0 -X port 80

패킷이 아예 안 잡힌다 → 내 쪽에서 패킷을 못 보내고 있는 것 패킷은 나가는데 응답이 없다 → 상대방 쪽 또는 중간 경로 문제

전체 흐름 요약

통신 안 됨
│
├── 케이블/인터페이스 확인 (L1)  →  ip link show
│
├── 같은 대역 ping 확인 (L2)    →  ping 게이트웨이, arp -n
│
├── 외부 ping 확인 (L3)         →  ping 8.8.8.8, traceroute
│
├── 포트 확인 (L4)              →  telnet, nc, curl
│
└── 그래도 모르겠으면           →  tcpdump로 패킷 직접 확인

계층을 건너뛰지 않고 L1부터 차근차근 올라가는 것이 핵심이다.

최근 cloudbro에서 Kubernetes Ingress NGINX 은퇴 관련 글을 보았다.

처음에는 “Ingress NGINX가 종료되는구나” 정도로 봤는데, 내용을 보니 단순히 특정 오픈소스 하나가 사라지는 이야기가 아니었다.
쿠버네티스에서 외부 트래픽을 클러스터 안으로 넣는 방식 자체가 Ingress 중심에서 Gateway API 중심으로 넘어가는 흐름에 가깝다고 볼 수 있었다.

원문 링크

Ingress NGINX가 뭐길래 이게 이슈인가?

쿠버네티스에서 외부 사용자가 서비스에 접근하려면, 외부 트래픽을 클러스터 내부 서비스로 연결해주는 진입점이 필요하다.

이때 많이 쓰던 리소스가 Ingress였다.

그리고 그 Ingress를 실제로 동작하게 해주는 대표적인 컨트롤러가 바로 ingress-nginx다.

Ingress는 “외부 요청을 어떤 서비스로 보낼지 정의하는 쿠버네티스 리소스”다.
다만 Ingress 리소스만 만든다고 트래픽이 자동으로 흐르는 것은 아니다.
이 규칙을 실제 NGINX 설정으로 바꾸고, 로드밸런서처럼 동작하게 만드는 컨트롤러가 필요하다. 그 대표적인 구현체가 ingress-nginx다.

ingress-nginx는 오랫동안 사실상 표준처럼 사용되어 왔다.
쿠버네티스를 조금이라도 운영해본 환경이라면 한 번쯤은 봤을 가능성이 높다.

그런데 이 프로젝트가 2026년 3월 이후로 공식 은퇴 예정이다.

은퇴 이후에는 다음 항목이 중단된다.

• 신규 릴리스 중단
• 버그픽스 중단
• 보안 취약점 패치 중단
• GitHub 저장소 read-only 전환 예정

즉, 기존에 설치된 ingress-nginx가 갑자기 바로 죽는 것은 아니다.
하지만 인터넷에 직접 노출되는 컴포넌트를 더 이상 보안 패치 없이 운영해야 한다는 점이 문제다.

운영 관점에서는 꽤 큰 리스크다.

그럼 이제 뭘 봐야 하나?

쿠버네티스 진영에서 밀고 있는 다음 표준은 Gateway API다.

Gateway API는 기존 Ingress의 한계를 보완하기 위해 나온 네트워킹 API다.
단순히 “Ingress의 새 버전”이라기보다는, 외부 트래픽 관리 방식을 더 세분화하고 표준화한 구조에 가깝다.

Gateway API는 Ingress처럼 HTTP 라우팅만 다루는 것이 아니라,
Gateway, HTTPRoute, TCPRoute, GRPCRoute 같은 리소스를 통해 다양한 트래픽 처리 방식을 표준화하려는 시도다.
쉽게 말하면 “각 컨트롤러마다 제각각 annotation으로 처리하던 기능을 쿠버네티스 표준 리소스로 끌어올리는 것”이다.

기존 Ingress의 한계

Ingress는 단순한 구조라서 처음 쓰기에는 편하다.
하지만 운영 규모가 커질수록 한계가 보인다.

예를 들면 다음과 같은 Ingress 리소스가 있다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

겉으로 보기에는 단순하다.
example.com/api로 들어온 요청을 api-service:80으로 보내겠다는 의미다.

문제는 운영 환경에서는 이 정도로 끝나지 않는다는 점이다.

실제 서비스에서는 TLS 인증서, 리다이렉트, rewrite, rate limit, header 기반 라우팅, canary 배포, 트래픽 분할 같은 요구사항이 붙는다.

Ingress는 이런 고급 기능을 표준 필드로 충분히 표현하지 못했다.
그래서 각 컨트롤러가 annotation으로 기능을 확장했다.

예를 들면 NGINX에서는 이런 annotation을 쓴다.

nginx.ingress.kubernetes.io/rewrite-target: /
nginx.ingress.kubernetes.io/ssl-redirect: "true"
nginx.ingress.kubernetes.io/canary: "true"

이 방식의 문제는 명확하다.

ingress-nginx에서는 동작하지만, 다른 Ingress Controller에서는 안 될 수 있다.
즉, YAML은 쿠버네티스 리소스처럼 보이지만 실제로는 특정 컨트롤러에 종속된다.

annotation은 쿠버네티스 리소스에 추가 메타데이터를 붙이는 방식이다.
원래는 보조 정보에 가깝지만, Ingress에서는 컨트롤러별 고급 기능을 켜는 용도로 많이 사용되었다.
이 때문에 같은 Ingress YAML이라도 NGINX, ALB, Traefik, HAProxy에서 다르게 동작할 수 있다.

또 다른 문제는 역할 분리다

Ingress는 하나의 리소스 안에 너무 많은 책임이 들어간다.

• 어떤 도메인을 받을지
• 어떤 경로를 어떤 서비스로 보낼지
• TLS 인증서를 어떻게 쓸지
• 로드밸런서 동작을 어떻게 할지
• 컨트롤러별 세부 옵션을 어떻게 줄지

이런 내용이 하나의 Ingress에 섞인다.

작은 팀에서는 괜찮을 수 있다.
하지만 인프라팀과 앱팀이 분리된 조직에서는 문제가 된다.

앱팀은 라우팅 규칙만 수정하고 싶은데, Ingress 안에는 TLS나 로드밸런서 설정까지 같이 들어 있다.
반대로 인프라팀은 공통 Gateway 정책을 관리하고 싶은데, 각 서비스 Ingress에 설정이 흩어져 있다.

결국 RBAC 분리도 애매해진다.

RBAC는 Role-Based Access Control의 약자다.
쿠버네티스에서는 “누가 어떤 리소스를 조회·생성·수정·삭제할 수 있는지”를 제어하는 권한 관리 방식이다.
예를 들어 앱팀에는 HTTPRoute만 수정할 수 있게 하고, Gateway나 TLS 설정은 인프라팀만 수정하게 만드는 식의 분리가 가능하다.

Ingress 구조에서는 이런 분리가 깔끔하지 않다.
Ingress 하나를 수정할 수 있으면 라우팅뿐 아니라 중요한 진입점 설정까지 같이 건드릴 수 있기 때문이다.

Gateway API는 뭐가 다를까?

Gateway API는 이 문제를 리소스 분리로 해결한다.

대표적인 리소스는 다음과 같다.

구조를 단순하게 보면 이렇다.

외부 사용자
   ↓
Gateway
   ↓
HTTPRoute
   ↓
Service
   ↓
Pod

Ingress에서는 하나의 리소스에 섞여 있던 책임을 Gateway API에서는 나누어 가진다.

인프라팀은 Gateway를 관리하고, 앱팀은 HTTPRoute를 관리한다.
이 구조가 운영 조직과 잘 맞는다고 볼 수 있다.

Gateway API 예시

예를 들어 인프라팀은 아래처럼 공통 Gateway를 만든다.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: main-gateway
  namespace: infra
spec:
  gatewayClassName: nginx
  listeners:
  - name: https
    port: 443
    protocol: HTTPS
    hostname: example.com
    tls:
      mode: Terminate
      certificateRefs:
      - name: example-com-cert

이 Gateway는 example.com의 HTTPS 요청을 받을 수 있는 진입점이다.

TLS Terminate는 HTTPS 암호화 연결을 Gateway나 Load Balancer에서 종료한다는 의미다.
외부 사용자는 HTTPS로 접속하지만, Gateway 이후 내부 서비스로는 HTTP 또는 별도 정책에 따라 전달될 수 있다.
운영 환경에서는 인증서 관리 지점과 내부 통신 암호화 여부를 분리해서 설계해야 한다.

그리고 앱팀은 자신의 서비스에 대한 라우팅만 정의한다.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
  namespace: app
spec:
  parentRefs:
  - name: main-gateway
    namespace: infra
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: api-service
      port: 80

이렇게 하면 /api로 들어온 요청이 api-service:80으로 전달된다.

중요한 점은 앱팀이 Gateway 자체를 수정하지 않아도 된다는 것이다.
앱팀은 자신의 HTTPRoute만 관리하면 된다.

Ingress와 Gateway API 비교

트래픽 분할에서의 장점

Gateway API에서는 트래픽을 여러 서비스로 나누는 것도 표준 방식으로 표현할 수 있다.

예를 들어 v1 서비스에 90%, v2 서비스에 10%만 보내는 구성이 가능하다.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-canary-route
spec:
  rules:
  - backendRefs:
    - name: api-v1
      port: 80
      weight: 90
    - name: api-v2
      port: 80
      weight: 10

Canary 배포는 새 버전을 전체 사용자에게 바로 배포하지 않고, 일부 트래픽만 먼저 보내서 안정성을 확인하는 방식이다.
예를 들어 기존 버전에 90%, 새 버전에 10%만 보내고 오류율이나 응답 시간을 확인한 뒤 점진적으로 비율을 높인다.

Ingress에서도 비슷한 구성을 할 수는 있었다.
하지만 대부분 annotation이나 컨트롤러별 기능에 의존했다.

Gateway API는 이런 기능을 리소스 스펙 안에서 더 표준적인 방식으로 표현하려는 방향이다.

CSP들도 Gateway API 쪽으로 움직이고 있다

여기서 말하는 CSP는 Cloud Service Provider의 약자다.
즉, AWS, Google Cloud, Microsoft Azure처럼 클라우드 인프라를 제공하는 회사를 의미한다.

CSP는 클라우드 서비스를 제공하는 사업자를 말한다.
대표적으로 AWS, GCP, Azure가 있고, 이들은 Kubernetes를 직접 운영하지 않아도 사용할 수 있도록 관리형 Kubernetes 서비스를 제공한다.

그리고 각 CSP는 자체 관리형 Kubernetes 서비스를 제공한다.

• GKE: Google Kubernetes Engine, Google Cloud의 관리형 Kubernetes 서비스
• EKS: Elastic Kubernetes Service, AWS의 관리형 Kubernetes 서비스
• AKS: Azure Kubernetes Service, Microsoft Azure의 관리형 Kubernetes 서비스

관리형 Kubernetes 서비스는 사용자가 직접 Control Plane을 설치하고 운영하지 않아도, CSP가 Kubernetes 제어 영역을 관리해주는 서비스다.
사용자는 주로 워커 노드, 애플리케이션 배포, 네트워크, 보안 설정에 집중하면 된다.

최근 흐름을 보면 주요 CSP들도 Gateway API 지원을 점점 확대하고 있다.

GKE

Google Kubernetes Engine은 Gateway API 기반 L7 Load Balancer와 Multi-Cluster Gateway를 지원한다.
GKE는 Gateway API를 비교적 적극적으로 밀고 있는 편이다.

L7 Load Balancer는 HTTP/HTTPS 같은 애플리케이션 계층 정보를 보고 트래픽을 분산하는 로드밸런서다.
예를 들어 URL 경로가 /api인지 /web인지, Host가 무엇인지에 따라 서로 다른 서비스로 요청을 보낼 수 있다.

EKS

AWS 쪽에서는 VPC Lattice와 연계되는 Gateway API Controller가 나왔다.
또 AWS Load Balancer Controller에서도 Gateway API 지원이 진행되고 있다.

다만 운영 환경에서는 각 컨트롤러의 지원 수준을 반드시 확인해야 한다.
“Gateway API를 지원한다”와 “프로덕션에서 안정적으로 모든 기능을 쓸 수 있다”는 같은 말이 아니다.

VPC Lattice는 AWS에서 서비스 간 통신을 관리하기 위한 네트워킹 서비스다.
여러 VPC나 계정에 흩어진 서비스를 논리적으로 연결하고, 인증·인가·트래픽 제어를 붙일 수 있다.
Gateway API와 연결하면 Kubernetes의 HTTPRoute 같은 리소스를 AWS 네트워킹 리소스와 매핑하는 식으로 사용할 수 있다.

AKS

Azure는 Application Gateway for Containers를 통해 Gateway API 기반 구조를 강화하고 있다.
기존 AGIC의 후속 방향으로 볼 수 있다.

AGIC는 Application Gateway Ingress Controller의 약자다.
AKS에서 Kubernetes Ingress 리소스를 Azure Application Gateway와 연결해주는 컨트롤러다.
Application Gateway for Containers는 이 흐름을 Gateway API 중심으로 발전시킨 후속 구조에 가깝다.

결국 AWS, GCP, Azure 모두 Gateway API 흐름을 무시하기 어려운 상황이다.
Kubernetes 네트워킹 표준이 Ingress 중심에서 Gateway API 중심으로 이동하고 있기 때문이다.

오픈소스 컨트롤러도 바뀌고 있다

Ingress NGINX 은퇴 이후 선택지는 하나만 있는 것이 아니다.
Gateway API를 구현하는 여러 컨트롤러가 있다.

• NGINX Gateway Fabric
• Envoy Gateway
• Istio
• Traefik
• Kong
• APISIX
• HAProxy Kubernetes Ingress / Gateway 관련 구현체

각 컨트롤러마다 성격은 다르다.

NGINX Gateway Fabric은 NGINX 기반 Gateway API 구현체다.
Envoy Gateway는 Envoy 기반이고, Istio는 서비스 메시까지 함께 고려할 수 있다.
Kong이나 APISIX는 API Gateway 성격이 강하다.

Envoy는 L7 프록시로 많이 사용되는 오픈소스다.
서비스 메시, API Gateway, 클라우드 네이티브 로드밸런싱에서 자주 쓰인다.
Istio, Envoy Gateway 같은 도구들이 Envoy를 데이터 플레인으로 사용한다.

따라서 단순히 “Ingress NGINX가 끝났으니 NGINX Gateway Fabric으로 가면 된다”라고 보기보다는, 현재 운영 환경에 맞는 컨트롤러를 골라야 한다.

지금 당장 다 바꿔야할까?

그건 아니다.

기존 클러스터에서 ingress-nginx를 사용 중이라고 해서 당장 서비스가 중단되는 것은 아니다.
하지만 신규 릴리스와 보안 패치가 중단되는 시점 이후에는 리스크가 커진다.

그래서 현실적인 접근은 단계적 전환이다.

전환 전략

사실 이 부분은 내가 혼자 바로 떠올린 전략은 아니다.

Ingress NGINX 은퇴 소식을 보고 “그럼 실제 운영 환경에서는 어떻게 넘어가야 하지?”라는 생각이 들었고,
Claude와 ChatGPT에게도 질문해보면서 여러 전환 방식을 정리해봤다.

현재 Kubernetes 운영 관점에서 현실적으로 가능한 방향만 추려보았고 그 생각은 다음과 같다.

1. 현재 사용 중인 Ingress부터 파악한다

가장 먼저 해야 할 일은 현재 클러스터에서 Ingress를 어떻게 쓰고 있는지 확인하는 것이다.

kubectl get ingress -A

이 명령어를 사용하면 전체 네임스페이스에서 사용 중인 Ingress 목록을 확인할 수 있다.

하지만 단순히 Ingress 개수만 보는 것으로는 부족하다.
중요한 것은 각 Ingress가 어떤 annotation에 의존하고 있는지 확인하는 것이다.

kubectl get ingress -A -o yaml | grep "nginx.ingress.kubernetes.io"

예를 들어 아래와 같은 annotation을 많이 쓰고 있다면 전환 난이도가 올라갈 수 있다.

• rewrite
• ssl-redirect
• auth
• canary
• rate limit
• configuration-snippet
• server-snippet

여기서 중요한 점은 “Ingress를 몇 개 쓰고 있느냐”보다 “NGINX 전용 기능에 얼마나 의존하고 있느냐”다.
단순 path routing만 사용 중이라면 Gateway API로 옮기기 비교적 쉽지만, NGINX annotation을 많이 사용 중이라면 동일한 기능을 Gateway API에서 어떻게 구현할지 따로 검토해야 한다.

2. 신규 서비스부터 Gateway API를 적용한다

기존 서비스를 한 번에 전부 바꾸는 것은 위험하다.
Ingress는 외부 트래픽이 들어오는 진입점이기 때문에, 잘못 바꾸면 서비스 장애로 바로 이어질 수 있다.

그래서 가장 현실적인 방법은 신규 서비스나 신규 클러스터부터 Gateway API를 적용하는 것이라고 본다.

기존 서비스는 당분간 Ingress로 유지하고,
새로 만드는 서비스부터 Gateway, HTTPRoute 기반으로 구성해보는 방식이다.

이렇게 하면 운영 중인 서비스에 주는 영향을 줄이면서 Gateway API 사용 경험을 쌓을 수 있다.

쉽게 말하면 “기존 도로를 바로 폐쇄하지 않고, 새 도로부터 Gateway API 방식으로 만들어보는 것”에 가깝다.
운영 환경에서는 한 번에 갈아엎는 방식보다, 신규 서비스부터 적용하고 검증하는 방식이 훨씬 안전하다.

3. Ingress와 Gateway API를 병행 운영한다

전환 기간에는 Ingress와 Gateway API를 같이 운영할 수 있다.

예를 들면 다음과 같은 방식이다.

• 기존 서비스: Ingress 유지
• 신규 서비스: Gateway API 적용
• 일부 경로: Gateway API로 먼저 이전
• 테스트 트래픽: 별도 hostname으로 검증
• 안정화 후 점진적으로 Gateway API 비중 확대

이런 방식을 사용하면 한 번에 모든 트래픽을 Gateway API로 넘기지 않아도 된다.

예를 들어 기존에는 example.com/api를 Ingress가 처리했다면,
테스트 단계에서는 gateway-test.example.com/api 같은 별도 도메인을 만들어 Gateway API 동작을 검증할 수 있다.

병행 운영의 핵심은 트래픽 진입점을 명확히 나누는 것이다.
Ingress와 Gateway API가 같은 host, 같은 path를 동시에 처리하게 만들면 오히려 혼란이 생길 수 있다.
따라서 어떤 요청은 Ingress가 받고, 어떤 요청은 Gateway가 받는지 기준을 명확히 잡아야 한다.

4. 기능별로 마이그레이션 가능 여부를 확인한다

Ingress에서 쓰던 기능이 Gateway API에서 모두 똑같이 동작한다고 보면 안 된다.

특히 NGINX annotation으로 처리하던 기능은 Gateway API 표준 리소스로 바로 1:1 대응되지 않을 수 있다.

예를 들어 다음 항목은 따로 확인이 필요하다.

Gateway API가 표준을 지향한다고 해서 모든 기능이 표준 필드 하나로 해결되는 것은 아니다.
특히 rate limit, 인증, WAF, custom NGINX 설정처럼 컨트롤러 특화 기능에 가까운 부분은 사용하는 Gateway Controller의 지원 범위를 반드시 확인해야 한다.

5. 컨트롤러를 먼저 정한다

Gateway API를 사용하려면 Gateway API를 실제로 처리할 컨트롤러가 필요하다.

Ingress 리소스만 만든다고 동작하지 않았던 것처럼,
Gateway API도 Gateway, HTTPRoute 리소스만 만든다고 자동으로 트래픽이 흐르지는 않는다.

대표적인 선택지는 다음과 같다.

• NGINX Gateway Fabric
• Envoy Gateway
• Istio
• Traefik
• Kong
• APISIX
• AWS Gateway API Controller for VPC Lattice
• GKE Gateway Controller
• Azure Application Gateway for Containers

어떤 컨트롤러를 선택할지는 환경에 따라 다르다.

예를 들어 AWS EKS 환경이라면 AWS Load Balancer Controller나 VPC Lattice 연계를 검토할 수 있고,
서비스 메시까지 고려한다면 Istio 기반 Gateway API 구성을 볼 수 있다.
반대로 단순 L7 라우팅 중심이라면 Envoy Gateway나 NGINX Gateway Fabric도 후보가 될 수 있다.

Gateway API는 표준 스펙이고, 컨트롤러는 그 스펙을 실제로 구현하는 구성요소다.
따라서 “Gateway API를 쓴다”는 말만으로는 부족하고, “어떤 Gateway Controller로 운영할 것인가”까지 정해야 한다.

서비스 메시란?

여기서 서비스 메시라는 말이 나오는데, 처음 보면 조금 어렵게 느껴질 수 있다.

서비스 메시(Service Mesh)는 쉽게 말하면 서비스끼리 통신할 때 필요한 네트워크 기능을 애플리케이션 코드 밖에서 관리하는 구조다.

일반적으로 마이크로서비스 환경에서는 여러 서비스가 서로 호출한다.

예를 들면 다음과 같은 구조다.

사용자
  ↓
주문 서비스
  ↓
결제 서비스
  ↓
알림 서비스

이때 서비스 간 통신에서는 여러 가지 문제가 생길 수 있다.

• 결제 서비스가 느리면 어떻게 할 것인가?
• 요청이 실패하면 재시도할 것인가?
• 서비스 간 통신을 암호화할 것인가?
• 특정 버전으로 트래픽을 일부만 보낼 것인가?
• 어느 서비스에서 장애가 발생했는지 어떻게 추적할 것인가?

이런 기능을 애플리케이션 코드마다 직접 구현하면 복잡해진다.

서비스 메시를 사용하면 이런 기능을 애플리케이션 코드가 아니라 프록시 계층에서 처리할 수 있다.

프록시는 중간에서 요청을 대신 받아 전달해주는 구성요소다.
서비스 메시에서는 보통 각 서비스 옆에 프록시가 붙고, 이 프록시가 서비스 간 통신을 대신 제어한다.
Istio에서는 Envoy 프록시가 이 역할을 한다.

서비스 메시를 사용하면 다음과 같은 기능을 구현하기 쉬워진다.

• 서비스 간 mTLS 암호화
• 트래픽 분할
• 장애 시 재시도
• 타임아웃 설정
• Circuit Breaker
• 요청 흐름 추적
• 서비스 간 접근 제어

mTLS는 mutual TLS의 약자다.
일반 TLS가 주로 클라이언트가 서버 인증서를 검증하는 구조라면, mTLS는 클라이언트와 서버가 서로를 인증한다.
서비스 메시 환경에서는 서비스 간 통신을 더 안전하게 만들기 위해 자주 사용된다.

단순히 외부 트래픽을 내부 서비스로 보내는 정도라면 Gateway API만으로도 충분할 수 있다.
하지만 서비스가 많아지고, 서비스 간 통신까지 세밀하게 제어해야 한다면 서비스 메시까지 함께 검토할 수 있다.

6. 서비스 메시를 사용 중이라면 같이 검토한다

Istio 같은 서비스 메시를 이미 사용하고 있다면 Gateway API 전환을 따로 떼어놓고 보기 어렵다.

서비스 메시 환경에서는 외부에서 들어오는 North-South 트래픽뿐 아니라,
서비스 간 East-West 트래픽까지 함께 고려해야 하기 때문이다.

North-South 트래픽은 외부 사용자와 클러스터 내부 서비스 사이의 트래픽을 말한다.
East-West 트래픽은 클러스터 내부 서비스끼리 주고받는 트래픽을 말한다.
예를 들어 사용자가 API 서버에 접근하는 것은 North-South 트래픽이고, API 서버가 내부 결제 서비스나 회원 서비스를 호출하는 것은 East-West 트래픽이다.

Gateway API는 Istio 같은 서비스 메시와도 연결되는 방향으로 발전하고 있다.
다만 이 경우에는 단순 Ingress 교체가 아니라 네트워크 구조 전체를 다시 봐야 하므로 공수가 커질 수 있다.

따라서 서비스 메시를 이미 쓰고 있다면 Gateway API 전환을 네트워크 표준화 작업의 일부로 보는 것이 맞다.

개인적으로 보는 현실적인 순서

정리하면, 지금 당장 모든 Ingress를 Gateway API로 바꾸는 것은 현실적이지 않다고 본다.

대신 아래 순서가 가장 안전해 보인다.

1. 현재 Ingress 목록과 annotation 사용 현황을 확인한다.
2. NGINX annotation 의존도가 높은 서비스를 따로 분류한다.
3. 신규 서비스부터 Gateway API를 적용한다.
4. 운영 영향이 적은 서비스부터 HTTPRoute로 이전해본다.
5. Ingress와 Gateway API를 일정 기간 병행 운영한다.
6. 사용하는 CSP와 컨트롤러의 Gateway API 지원 수준을 확인한다.
7. 2026년 3월 이후에도 ingress-nginx를 장기 운영하지 않도록 전환 계획을 세운다.

마무리

이번 내용을 정리하면서 느낀 점은, Ingress NGINX 은퇴가 단순히 “컨트롤러 하나가 사라진다”는 문제가 아니라는 것이다.

기존에는 Ingress 하나에 라우팅, TLS, 로드밸런서 관련 설정을 몰아넣는 방식이 많았다.

예를 들면 아래처럼 하나의 Ingress 리소스 안에 host, path, backend service, TLS 설정이 같이 들어간다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  namespace: app
spec:
  tls:
  - hosts:
    - example.com
    secretName: example-com-tls
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

이 설정만 보면 단순해 보인다.
example.com/api로 들어온 요청을 api-service:80으로 보내고, TLS 인증서는 example-com-tls를 사용한다는 의미다.

문제는 실제 운영 환경에서는 여기서 끝나지 않는다는 점이다.

경로를 바꿔서 전달해야 하거나, HTTP 요청을 HTTPS로 강제 리다이렉트해야 하거나, 일부 트래픽만 새 버전으로 보내야 하는 요구사항이 생긴다.

Ingress 기본 스펙만으로 표현하기 어려운 기능은 보통 annotation으로 해결했다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  namespace: app
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/proxy-body-size: "20m"
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"
spec:
  tls:
  - hosts:
    - example.com
    secretName: example-com-tls
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service-v2
            port:
              number: 80

위 설정은 예를 들면 이런 의미로 볼 수 있다.

• rewrite-target: 요청 경로를 내부 서비스에 전달할 때 다시 작성한다.
• ssl-redirect: HTTP 요청을 HTTPS로 리다이렉트한다.
• proxy-body-size: 업로드 가능한 요청 body 크기를 조정한다.
• canary: 카나리 배포용 Ingress로 사용한다.
• canary-weight: 전체 트래픽 중 일부 비율만 이 서비스로 보낸다.

이런 방식은 편하긴 하지만, NGINX Ingress Controller에 강하게 의존한다.
즉, 같은 Ingress YAML이라도 다른 컨트롤러에서는 annotation이 동작하지 않거나, 아예 다른 방식으로 설정해야 할 수 있다.

그래서 기존 방식은 운영 규모가 커질수록 컨트롤러 종속성이 강해지고, 조직이 커질수록 운영 권한 분리도 애매해진다.

Gateway API는 이 문제를 표준 리소스와 역할 분리로 풀려고 한다.

• 인프라팀은 Gateway, TLS, Load Balancer를 관리한다.
• 앱팀은 HTTPRoute로 자신의 서비스 라우팅을 관리한다.
• RBAC로 권한을 더 명확하게 나눌 수 있다.
• 컨트롤러별 annotation 의존도를 줄일 수 있다.

물론 Gateway API가 모든 문제를 바로 해결해주는 것은 아니다.
컨트롤러 선택, 기존 annotation 대체, CSP 지원 수준, 운영 검증 등 확인해야 할 부분이 많다.

그래도 방향성은 명확해 보인다.

당장 운영 중인 서비스를 무리하게 바꿀 필요는 없지만,
신규 서비스나 신규 클러스터를 설계한다면 이제는 Ingress보다 Gateway API를 먼저 검토하는 것이 맞다고 본다.

이 글이 어려운 사람을 위한 정리글

사실 나도 처음에 이 내용을 봤을 때 바로 이해되지는 않았다.

Ingress, Ingress Controller, annotation, Gateway API 이런 단어가 한 번에 나오니까
“그래서 뭐가 문제고, 왜 Gateway API로 넘어가야 한다는 거지?”라는 생각이 들었다.

그래서 나처럼 처음 보는 사람 기준으로 다시 정리해보면 핵심은 이거다.

1. Ingress는 외부 요청을 내부 서비스로 보내는 규칙이다

쿠버네티스 안에는 여러 서비스와 Pod가 있다.
그런데 외부 사용자가 클러스터 내부의 서비스에 접근하려면 중간에 진입점이 필요하다.

이때 사용하는 리소스가 Ingress다.

예를 들면 이런 식이다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

이 설정은 쉽게 말하면 이런 뜻이다.

example.com/api 로 요청이 들어오면
api-service의 80번 포트로 보내라

여기까지는 Kubernetes 표준 Ingress 설정이다.

2. 그런데 Ingress만 있다고 실제로 동작하는 것은 아니다

Ingress는 “규칙”이다.
하지만 이 규칙을 실제로 읽고 동작시키는 프로그램이 따로 필요하다.

그게 Ingress Controller다.

대표적으로 많이 쓰인 것이 ingress-nginx다.

흐름은 이렇게 볼 수 있다.

사용자 요청
  ↓
Ingress Controller
  ↓
Ingress 규칙 확인
  ↓
Service
  ↓
Pod

즉, Ingress는 설정이고,
Ingress Controller는 그 설정을 실제 트래픽 처리로 바꿔주는 역할이다.

3. 문제는 Ingress 기본 기능만으로는 부족했다

Ingress 기본 설정만으로는 단순 라우팅 정도는 할 수 있다.

예를 들면 이런 것들이다.

• 특정 도메인으로 들어온 요청 처리
• 특정 path로 들어온 요청을 특정 서비스로 전달
• TLS 인증서 연결

하지만 실제 운영 환경에서는 이것보다 더 많은 기능이 필요하다.

예를 들면 다음과 같다.

/api 경로를 내부 서비스에는 / 로 바꿔서 넘기고 싶다
HTTP로 들어온 요청을 HTTPS로 강제 전환하고 싶다
트래픽 10%만 새 버전으로 보내고 싶다
요청 body 크기 제한을 늘리고 싶다
특정 header가 있을 때만 다른 서비스로 보내고 싶다

이런 세부 기능은 Ingress 기본 스펙만으로는 표현하기 어려운 경우가 많았다.

그래서 ingress-nginx에서는 annotation을 사용했다.

4. annotation은 컨트롤러 전용 옵션에 가깝다

예를 들면 아래와 같은 설정이다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

여기서 중요한 부분은 이거다.

annotations:
  nginx.ingress.kubernetes.io/rewrite-target: /
  nginx.ingress.kubernetes.io/ssl-redirect: "true"
  nginx.ingress.kubernetes.io/canary: "true"
  nginx.ingress.kubernetes.io/canary-weight: "10"

이 annotation들은 Kubernetes 표준 기능이라기보다는
NGINX Ingress Controller가 알아듣는 전용 설정에 가깝다.

각 설정은 대략 이런 의미다.

• rewrite-target: 요청 경로를 바꿔서 내부 서비스로 전달한다.
• ssl-redirect: HTTP 요청을 HTTPS로 리다이렉트한다.
• canary: 카나리 배포용 Ingress로 사용한다.
• canary-weight: 전체 트래픽 중 일부 비율만 이 서비스로 보낸다.

5. 그래서 NGINX Ingress Controller에 의존한다는 말이 나온다

Ingress 자체는 Kubernetes 표준이다.
하지만 nginx.ingress.kubernetes.io/... annotation은 Kubernetes 공통 표준이 아니다.

이 annotation을 해석하는 주체는 Kubernetes가 아니라 NGINX Ingress Controller다.

흐름은 이렇게 된다.

Ingress YAML 작성
  ↓
Kubernetes API Server에 저장
  ↓
NGINX Ingress Controller가 Ingress를 감시
  ↓
nginx.ingress.kubernetes.io/... annotation을 읽음
  ↓
NGINX 설정으로 변환
  ↓
트래픽 처리

그래서 NGINX Ingress Controller를 사용할 때는 잘 동작한다.

하지만 컨트롤러를 AWS ALB Controller, Traefik, HAProxy, Istio 같은 것으로 바꾸면
nginx.ingress.kubernetes.io/... annotation은 동작하지 않을 수 있다.

왜냐하면 다른 컨트롤러는 NGINX 전용 annotation을 해석하지 않기 때문이다.

즉, 같은 Ingress YAML이라도 컨트롤러가 바뀌면 다시 수정해야 할 수 있다.

6. 한 줄로 말하면 Ingress는 표준인데 annotation은 사투리다

이렇게 이해하면 쉽다.

Ingress의 spec.rules, spec.tls
→ Kubernetes 표준어

nginx.ingress.kubernetes.io/rewrite-target
nginx.ingress.kubernetes.io/canary-weight
→ NGINX Ingress Controller가 알아듣는 사투리

그래서 nginx.ingress.kubernetes.io/... annotation을 많이 쓰고 있다면
겉으로는 Kubernetes Ingress를 쓰는 것처럼 보여도
실제로는 NGINX Ingress Controller에 많이 묶여 있는 상태라고 볼 수 있다.

7. Gateway API는 이 문제를 줄이려고 나온 흐름이다

Gateway API는 Ingress의 한계를 보완하기 위해 나온 Kubernetes 네트워킹 API다.

Ingress에서는 하나의 리소스 안에 여러 역할이 섞여 있었다.

도메인 설정
TLS 설정
라우팅 설정
서비스 연결
컨트롤러별 세부 기능

Gateway API는 이 역할을 나눈다.

쉽게 보면 이런 구조다.

외부 사용자
  ↓
Gateway
  ↓
HTTPRoute
  ↓
Service
  ↓
Pod

Gateway는 인프라팀이 관리하고,
HTTPRoute는 앱팀이 관리하는 식으로 역할을 나눌 수 있다.

8. Gateway API를 쓰면 뭐가 좋아지는가?

핵심은 세 가지다.

첫 번째, annotation 의존을 줄일 수 있다

Ingress에서는 트래픽 분할 같은 기능을 annotation으로 처리하는 경우가 많았다.

metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"

Gateway API에서는 이런 트래픽 분할을 HTTPRoute에서 더 표준적인 방식으로 표현할 수 있다.

backendRefs:
- name: api-v1
  port: 80
  weight: 90
- name: api-v2
  port: 80
  weight: 10

이 설정은 api-v1에 90%, api-v2에 10% 트래픽을 보내겠다는 의미다.

즉, 특정 NGINX annotation에 의존하는 것이 아니라
Gateway API의 표준 리소스 구조 안에서 표현할 수 있다.

두 번째, 역할 분리가 쉬워진다

Ingress는 하나의 리소스 안에 많은 설정이 들어간다.

그래서 앱팀이 라우팅만 수정하고 싶어도 TLS나 Gateway 성격의 설정까지 같이 보게 된다.

Gateway API는 역할이 나뉘어 있다.

인프라팀
→ GatewayClass, Gateway 관리

앱팀
→ HTTPRoute 관리

이렇게 되면 권한 분리도 쉬워진다.

예를 들어 앱팀에는 HTTPRoute만 수정할 수 있게 하고,
인프라팀만 Gateway와 TLS 설정을 수정할 수 있게 만들 수 있다.

세 번째, 앞으로의 표준 흐름에 맞다

Kubernetes에서는 Ingress보다 Gateway API를 더 확장된 네트워킹 표준으로 가져가려는 흐름이다.

Ingress는 주로 HTTP/HTTPS 라우팅 중심이었다.
Gateway API는 HTTP뿐 아니라 gRPC, TCP 같은 트래픽까지 더 넓게 다루려는 구조다.

예를 들면 이런 리소스들이 있다.

• HTTPRoute
• GRPCRoute
• TCPRoute
• TLSRoute

즉, Gateway API는 단순히 Ingress를 이름만 바꾼 것이 아니라
쿠버네티스 네트워킹 구조를 더 세분화하고 표준화하려는 방향이라고 볼 수 있다.

9. 그래도 Gateway API가 모든 의존성을 없애는 것은 아니다

여기서 오해하면 안 되는 부분이 있다.

Gateway API를 쓴다고 해서 특정 컨트롤러 의존성이 완전히 사라지는 것은 아니다.

Gateway API도 실제로 동작하려면 컨트롤러가 필요하다.

예를 들면 다음과 같은 것들이 있다.

• NGINX Gateway Fabric
• Envoy Gateway
• Istio
• Traefik
• Kong
• APISIX
• AWS Gateway API Controller
• GKE Gateway Controller
• Azure Application Gateway for Containers

즉, Gateway API도 컨트롤러가 있어야 실제 트래픽을 처리한다.

다만 Ingress 시절보다 공통 표준 스펙이 더 넓어졌기 때문에,
컨트롤러별 annotation에 의존하던 부분을 줄일 수 있다.

정리하면 이렇다.

Ingress
→ 기본 기능은 표준이지만, 실무 고급 기능은 컨트롤러별 annotation에 많이 의존했다.

Gateway API
→ 라우팅, Gateway, TLS, 트래픽 분할 같은 기능을 더 표준화된 리소스로 나누어 관리하려는 방식이다.

10. 내가 이해한 최종 결론

내가 이해한 핵심은 이렇다.

Ingress 자체가 나쁜 것은 아니다.
문제는 실제 운영에서 필요한 세부 기능을 Ingress 기본 스펙만으로 다 표현하기 어려웠고,
그래서 NGINX 같은 특정 Ingress Controller의 annotation에 많이 의존하게 되었다는 점이다.

그러다 보니 컨트롤러를 바꾸거나, 운영 구조가 커질수록 관리가 어려워질 수 있다.

Gateway API는 이 문제를 줄이기 위해 나온 흐름이다.

• 라우팅 설정은 HTTPRoute로 분리한다.
• 외부 진입점과 TLS 설정은 Gateway로 분리한다.
• 어떤 컨트롤러를 쓸지는 GatewayClass로 정의한다.
• 트래픽 분할 같은 기능도 표준 리소스 안에서 표현하려고 한다.
• 인프라팀과 앱팀의 역할 분리도 더 쉬워진다.

결국 이 글에서 말하려는 핵심은
“Ingress NGINX가 은퇴하니까 당장 모든 것을 바꿔야 한다”가 아니다.

더 정확히는
“기존 Ingress + NGINX annotation 중심의 운영 방식에서, Gateway API 기반의 표준화된 네트워킹 구조로 넘어가는 흐름을 이해해야 한다”에 가깝다.

그래서 신규 서비스나 신규 클러스터를 설계한다면
이제는 Ingress만 당연하게 선택하기보다는 Gateway API도 같이 검토하는 것이 맞다고 본다.

참고

• Kubernetes 공식 블로그 - Ingress NGINX Retirement
• Kubernetes Gateway API 공식 문서
• Ingress2Gateway 1.0 Release
• NGINX Gateway Fabric
• cloudbro 원문 토론

본 콘텐츠는 구름 서포터즈 활동으로 지원을 받아 작성된 교육생의 실제 경험 후기입니다.

2026년 05월 20일. 오늘을 기점으로 6개월간의 구름 부트캠프를 수료하게 되었다.

깃허브 주소 : https://github.com/Goorm4I/pposiraegi-ecommerce 회의록 노션 주소 : https://www.notion.so/goormkdx/Four-I-2fec0ff4ce3180838568e13dbd3f8bac

뽀시래기 프로젝트란?

뽀시래기는 반려동물 용품을 타임딜(시간 한정 특가) 방식으로 판매하는 이커머스 플랫폼이다. 타임딜 특성상 특정 시간대에 트래픽이 폭발적으로 몰리고, 재고가 초과 판매되지 않도록 정확하게 제어해야 한다. 이런 요구사항 때문에 단순한 웹 서비스가 아니라, 클라우드 네이티브 인프라 위에서 운영되는 서비스로 설계했다.

팀명은 포아이팀이고, 이나형(팀장/인프라), 박지훈(인프라/프론트엔드), 서주원(Git관리/백엔드) 3명으로 구성되었다. 프로젝트는 총 3개 Phase로 나뉘어 진행되었으며, 이 글은 최종 단계인 Phase 3 (EKS v3.5) 를 중심으로 한 회고이다.

뽀시래기의 역사 — ECS에서 EKS까지

Phase 1 · 2 — ECS Fargate 기반 MSA

처음에는 AWS ECS Fargate 위에 MSA(마이크로서비스 아키텍처) 구조로 서비스를 구축했다. api-gateway, user-service, order-service, product-service 4개의 서비스를 각각 컨테이너로 분리하고, RDS PostgreSQL과 ElastiCache Redis를 데이터 레이어로 사용했다.

ECS는 관리 오버헤드가 적고 빠르게 구축할 수 있다는 장점이 있었지만, 운영을 하면서 다음과 같은 한계에 부딪혔다.

• 트래픽 제어의 한계 — 타임딜처럼 특정 서비스에 트래픽이 몰릴 때 서비스 간 세밀한 라우팅이나 서킷브레이킹이 ECS로는 어려웠다.
• 수동 작업 잔존 — 인프라 변경 시 콘솔에서 직접 수정해야 하는 부분이 남아있었다.
• 모니터링 한계 — CloudWatch 수준으로는 Pod·Node 단위의 세밀한 지표 수집이 불가능했다.

Phase 3 — EKS로의 전환

이러한 한계를 극복하기 위해 Phase 3에서는 Amazon EKS(Elastic Kubernetes Service) 로 전환을 결정했다. ECS보다 복잡도는 높지만, IAM·네트워크·스토리지·배포·관측성의 경계를 명확히 컨트롤할 수 있다는 점이 핵심이었다.

단순히 EKS를 띄우는 것이 목표가 아니었다. 각 도구가 맡는 책임 경계를 명확히 정리하고, 재현 가능한 운영 흐름을 만드는 것이 이번 Phase 3의 진짜 목표였다.

Phase 3 기술 스택 — 무엇을, 왜 썼나

Terraform — 인프라 전체를 코드로

VPC, EKS 클러스터, RDS, ElastiCache, ALB, IAM, IRSA까지 모든 AWS 인프라를 Terraform으로 코드화했다. 코드로 관리하면 팀원 누구든 동일한 순서로 실행하면 동일한 인프라를 재현할 수 있고, 변경 이력도 Git에 남아 언제 무엇이 바뀌었는지 추적할 수 있다.

Bootstrap Script — 플랫폼 컴포넌트 1회 설치 자동화

Terraform이 AWS 리소스를 만들고 나면, EKS 위에 올라가는 플랫폼 컴포넌트들을 설치해야 한다. 이를 위해 bootstrap-platform.sh 쉘 스크립트를 직접 작성했다. metrics-server → ArgoCD → Karpenter → AWS LBC → Istio → Prometheus+Grafana → ESO 순서로 한 번의 실행으로 전체 플랫폼을 구성할 수 있도록 자동화했다. --only monitoring, --from eso 같은 옵션으로 특정 단계만 재실행하는 것도 가능하다.

GitHub Actions + ArgoCD — GitOps CI/CD

GitHub Actions는 CI를 담당한다. main 브랜치에 코드가 push되면 자동으로 Docker 이미지를 빌드하고 ECR에 push한다. 이때 이미지 태그는 latest 대신 Git commit SHA를 사용한다. 어떤 코드가 배포됐는지 정확히 추적하고, 문제가 생기면 이전 SHA 태그로 즉시 롤백할 수 있기 때문이다.

ArgoCD는 CD를 담당한다. infrastructure/kubernetes/ 폴더를 지속적으로 감시하다가 변경이 감지되면 자동으로 EKS 클러스터에 sync한다. 이것이 GitOps 방식이다. Git이 단일 진실의 원천(Single Source of Truth)이 되어, 배포 상태가 항상 코드와 일치한다.

Karpenter — 워크로드 특성별 노드 프로비저닝

Karpenter를 단순히 "비용 절감 도구"로 보면 안 된다. 워크로드 특성에 맞는 노드 프로비저닝 정책을 실행하는 운영 정책 실행기가 더 정확한 표현이다.

• 모니터링 스택(Prometheus, Grafana, Loki) → On-Demand 고정. 안정성이 중요해서 Spot이 적합하지 않다.
• 앱 워크로드(api-gateway, order-service 등) → Karpenter 탄력 확장. 타임딜 트래픽 폭증 시 Spot + On-Demand 자동 혼합으로 대응한다.

Istio Ambient — 서비스 메시

서비스 간 통신에 mTLS 암호화를 적용하고, Waypoint + AuthorizationPolicy로 접근 제어를 구현했다. /actuator/prometheus 같은 내부 엔드포인트를 외부에서 직접 접근하지 못하도록 경계를 만들었다.

Prometheus + Grafana + Loki + Tempo — 완전한 Observability

모니터링은 "설치했다"가 아니라 실제 병목을 찾기 위해 사용했다.

• Prometheus — Pod/Node 단위 메트릭 수집. Spring Boot actuator /actuator/prometheus 엔드포인트 스크래핑
• Grafana — JVM, Kubernetes 클러스터, Karpenter 대시보드 통합 시각화
• Loki — 서비스 로그 수집 및 검색 (S3에 IRSA로 저장)
• Tempo + OTEL Collector — 분산 트레이싱. 서비스 간 지연 구간 추적
• Alertmanager → Discord — 이상 징후 발생 시 Discord 웹훅으로 즉시 알림

실제로 k6 부하 테스트(300 VU, 30초)를 통해 order-service의 HikariCP 커넥션 풀이 병목임을 발견했고, maximum-pool-size를 10 → 30으로 조정해서 평균 응답시간을 4.15초 → 1.69초로 59% 개선했다.

해당 내용은 링크에서 확인해볼 수 있다.

ESO + AWS SSM — Secret 자동 관리

External Secrets Operator(ESO) 를 통해 AWS SSM Parameter Store에 저장된 DB 비밀번호, JWT Secret 등을 Kubernetes Secret으로 자동 주입한다. 민감한 정보를 Git에 올리지 않고도 안전하게 관리할 수 있다. 이런식으로 깃허브 settings에서 관리하고 있다.

IRSA — Pod 단위 최소 권한 보안

기존에는 노드 전체에 IAM 권한을 부여했지만, IRSA(IAM Roles for Service Accounts) 를 도입해 Pod 단위로 필요한 권한만 부여하도록 바꿨다. Loki가 S3에 접근하거나 ESO가 SSM에 접근할 때도 각각의 Service Account에 딱 필요한 권한만 가진 IAM Role을 연결했다.

뽀시래기 프로젝트 소개

뽀시래기 메인페이지, 제품 페이지

뽀시래기는 다음과 같이 반려동물을 파는 이커머스 플랫폼이다. 원래 금액과 할인된 금액을 찾아볼 수 있고, 남는시간과 남은 재고를 한눈에 살펴볼 수 있다.

그런다음, 상품을 누르면 상세페이지로 들어갈 수 있는데 밑으로 스크롤을 내리면 인기 있는 다른 제품을 구매할 수 있게 된다.

회원가입 & 로그인 화면

이렇게 회원가입을 할 수 있게 되고, 로그인을 통해 서비스를 이용할 수 있다. 그러나 물품을 구매하기 위해서는 배송지를 등록을 먼저 해야한다. 다음과 같이 마이페이지를 클릭하게 되면 배송지관리, 전화번호 관리 등 기본적인 설정을 할 수 있게되고 구매한 물품들의 목록을 확인할 수도 있다.

찜 기능

다음과 같이 찜을 하게 되면 상단에 하트를 눌러 어느 제품들을 찜했는지도 살펴볼 수 있다.

관리자 페이지 구현

관리자로 로그인하게 되면 상단과 하단에서 관리자 버튼과 모니터링 버튼이 생긴다. 관리자같은 경우에는 현재 진행중인 딜을 수정하거나 새로운 딜을 만들 수 있다.

또한 모니터링 버튼을 눌러 현재 서비스별 리소스가 어떻게 동작하는지 확인할 수 있다.

후기

6개월동안, 거의 7개월이 되는 기간동안 구름과 kt에 지원을 받아서 인프런 무료수강을 하면서 팀원들과 스터디를 매일매일 하면서 kubernetes, docker에 대한 트러블슈팅하던 것이 며칠 전 같은데 벌써 하나의 프로젝트를 완성하면서 우수상까지 받으며 수료할 수 있어서 감회가 깊게 느껴졌다.

짧지 않은 기간이었지만 6개월동안 몰입할 수 있는 환경덕에 1년 이상의 성장을 이룰 수 있었다고 생각이 들며 퇴사를 하면서 이 부트캠프를 선택했던 내 선택에 후회하지 않는다고 자신할 수 있다. 주변에 인프라나 클라우드에 관심이 있는 후배가 있다면 당당하게 이 구름의 클라우드 네이티브 부트캠프를 추천하고 싶다.

문제

avg=4.15s / p(90)=5.73s / p(95)=6.09s

300명이 동시에 주문 요청을 보내면 DB 커넥션 풀이 금방 고갈된다. 커넥션을 얻지 못한 요청들은 줄을 서서 대기하게 되고, 그게 응답 지연으로 이어지는 구조였다.

HikariCP란? Spring Boot에서 기본으로 사용하는 DB 커넥션 풀 라이브러리다. 커넥션 풀이란 DB 연결을 미리 여러 개 만들어두고 요청이 들어올 때마다 재사용하는 방식인데, 풀 사이즈가 너무 작으면 동시 요청이 몰릴 때 병목이 생긴다. 기본값은 maximum-pool-size: 10으로, 동시에 10개의 DB 연결만 허용한다.

해결

application-prod.yaml에 Hikari 설정이 아예 없었기 때문에 아래 설정을 추가해주었다.

hikari:
  maximum-pool-size: 30      # 최대 커넥션 수 (기본값 10 → 30으로 증가)
  minimum-idle: 10           # 유휴 상태에서 유지할 최소 커넥션 수
  connection-timeout: 30000  # 커넥션 획득 대기 최대 시간 (30초)
  idle-timeout: 600000       # 유휴 커넥션 유지 시간 (10분)
  max-lifetime: 1800000      # 커넥션 최대 수명 (30분)

핵심은 maximum-pool-size를 10에서 30으로 늘린 것이다. 동시에 처리할 수 있는 DB 연결이 3배로 늘어나니 대기 줄이 줄어들 수밖에 없다.

결과

설정 몇 줄 추가했을 뿐인데 평균 응답시간이 4.15초 → 1.69초로 약 60% 개선됐다.

코드 한 줄 안 바꾸고 설정만으로 이 정도 성능 차이가 난다는 게 인상적이었다. 기본값이 항상 최선은 아니다. 특히 트래픽이 몰리는 서비스라면 커넥션 풀 사이즈는 반드시 확인하고 튜닝해야 한다는 걸 이번에 직접 체감하게 되었다.

도메인은 https://pposiraegi.cloud/login 이며, 타임딜 서비스 특성상 특정 시간대에 트래픽이 순간적으로 폭증하는 상황이 발생한다. 이 트래픽을 실제로 버틸 수 있는지 검증하기 위해 부하 테스트 도구인 k6를 사용해보기로 했다.

k6란? JavaScript로 테스트 스크립트를 작성해 HTTP 요청을 대량으로 보내고, 응답 시간·성공률 등을 측정할 수 있는 오픈소스 부하 테스트 도구다.

k6 설치

공식 설치 문서: https://grafana.com/docs/k6/latest/set-up/install-k6/

Windows 환경이므로 PowerShell에서 아래 명령어를 실행한다.

winget install k6 --source winget

k6 테스트 파일 작성

test.js 파일을 생성하고 아래 스크립트를 작성했다.

import http from 'k6/http';
import { sleep, check } from 'k6';

export const options = {
  vus: 300,       // 동시 접속 가상 유저 300명
  duration: '30s', // 30초 동안 테스트 실행
};

// 테스트 시작 전 1회 실행 - 로그인해서 토큰을 가져옴
export function setup() {
  const res = http.post(
    'https://pposiraegi.cloud/api/v1/auth/login',
    JSON.stringify({ email: 'test@test.com', password: '123456' }),
    { headers: { 'Content-Type': 'application/json' } }
  );
  console.log('로그인 응답:', res.status, res.body);
  const token = res.json('data.accessToken');
  console.log('토큰:', token);
  return { token };
}

// 가상 유저 300명이 30초 동안 반복 실행하는 시나리오
export default function (data) {
  const body = `{"orderItems":[{"skuId":839470480585919574,"quantity":1}]}`;

  const res = http.post(
    'https://pposiraegi.cloud/api/v1/orders',
    body,
    {
      headers: {
        'Content-Type': 'application/json',
        'Authorization': `Bearer ${data.token}`,
      }
    }
  );
  console.log('주문 응답:', res.status, res.body);
  check(res, {
    'status is 200': (r) => r.status === 200,
  });
  sleep(1);
}

작성 후 아래 명령어로 실행한다.

k6 run test.js

실행 결과

결과를 해석하면 다음과 같다.

요청 자체는 전부 성공했지만 응답 속도가 너무 느리다. 평균 4초, 최대 약 10초는 타임딜 서비스에서는 치명적인 수치다. DB 커넥션 풀을 관리하는 HikariCP 튜닝이 필요할 것 같다.

위처럼 OutOfSync + Degraded 상태가 떠서 로그를 확인해보기로 했다.

• OutOfSync: Git에 있는 설정과 실제 클러스터 상태가 다르다는 뜻
• Degraded: 배포된 애플리케이션이 정상 동작하지 않는다는 뜻

로그 확인

kubectl describe application pposiraegi -n argocd

로그에서 눈에 띄는 내용은 다음과 같았다.

external-secrets.io/ClusterSecretStore CRD가 없음
external-secrets.io/ExternalSecret CRD가 없음

ClusterSecretStore와 ExternalSecret CRD가 없다는 에러였다.

CRD(Custom Resource Definition)란 Kubernetes에 기본으로 없는 리소스 타입을 사용자가 직접 정의해서 추가하는 것이다. ESO를 설치하면 이 CRD들이 함께 등록된다.

원인은 이전 bootstrap 스크립트 실행 중 Loki 설치 단계에서 Windows 환경 문제로 오류가 발생했고, 그 이후 단계인 ESO(External Secrets Operator) 설치까지 진행되지 못했기 때문이었다. ESO는 AWS Secrets Manager 같은 외부 시크릿 저장소의 값을 Kubernetes Secret으로 자동으로 동기화해주는 도구다.

따라서 ESO만 따로 설치해주기로 했다.

ESO 따로 설치

./scripts/bootstrap-platform.sh --from eso

ESO 설치는 완료됐는데 여전히 OutOfSync 상태였다. Pod 상태를 확인해봤다.

waypoint만 떠 있고 나머지 서비스들이 올라오지 않은 상태였다. ArgoCD가 자동으로 sync를 하지 못하고 있어서 강제로 sync를 실행해보기로 했다.

ArgoCD sync 강제 실행

kubectl -n argocd exec -it $(kubectl get pods -n argocd -l app.kubernetes.io/name=argocd-server -o jsonpath='{.items[0].metadata.name}') -- argocd app sync pposiraegi --insecure --server argocd-server:80

ArgoCD CLI를 사용하려면 먼저 로그인이 필요하다고 떴다. 초기 admin 비밀번호를 확인한 뒤, port-forward로 ArgoCD 서버에 접근해서 로그인했다.

# 초기 admin 비밀번호 확인
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

# port-forward 후 로그인
kubectl port-forward svc/argocd-server -n argocd 8080:80 &
sleep 3
kubectl -n argocd exec -it $(kubectl get pods -n argocd -l app.kubernetes.io/name=argocd-server -o jsonpath='{.items[0].metadata.name}') -- argocd login localhost:8080 --insecure --username admin --password [위에서 확인한 비밀번호]

로그인 성공. 이제 sync를 다시 실행했다.

kubectl -n argocd exec -it $(kubectl get pods -n argocd -l app.kubernetes.io/name=argocd-server -o jsonpath='{.items[0].metadata.name}') -- argocd app sync pposiraegi --insecure --server localhost:8080

sync가 정상적으로 진행되는 것을 확인했다. 이제 production 네임스페이스의 Pod 상태를 확인해봤다.

production Pod 확인

kubectl get pods -n production

모든 서비스의 Pod가 정상적으로 올라왔다. 이제 실제 서비스에 접속해봤다.

서비스 확인

pposiraegi.cloud에 정상적으로 접속되는 것을 확인했다. 길고 긴 삽질이 드디어 끝났다.

마무리 정리

팀원은 MacOS 환경이라 bootstrap 스크립트가 한 번에 실행됐지만, Windows 환경에서는 여러 문제가 연달아 발생했다.

• Git Bash에서 sudo 권한 없음 → helm 수동 설치
• helm 실행 경로 문제 → PATH 직접 설정
• Windows에 /proc 경로가 없음 → Loki 설치 실패
• kubectl이 aws CLI 경로를 인식하지 못함 → 심볼릭 링크 + kubeconfig 수동 수정
• ESO 미설치로 인한 CRD 누락 → ESO 단독 설치

같은 스크립트라도 OS 환경에 따라 전혀 다르게 동작할 수 있다는 걸 몸소 경험했다. 다음에 스크립트를 작성할 때는 OS 환경 분기 처리를 꼭 고려해야겠다고 느꼈다.

PowerShell 및 VS Code에서 실행 불가

처음에는 VS Code 터미널에서 그냥 실행하려 했다.

./scripts/bootstrap-platform.sh

당연히 실패했다. .sh 파일은 Linux/Mac 환경의 bash 스크립트이기 때문에, Windows의 PowerShell이나 VS Code 기본 터미널에서는 실행할 수 없다. bash를 실행할 수 있는 환경이 필요했다.

Git Bash 설치 + helm 설치

https://git-scm.com/download/win 에서 Git을 설치하면 Git Bash가 함께 설치된다. Git Bash는 Windows에서 bash 명령어를 쓸 수 있게 해주는 터미널 환경이다.

설치 후 Git Bash를 열고 다시 시도했다.

cd /c/pposiraegi-ecommerce
aws eks update-kubeconfig --region ap-northeast-2 --name pposiraegi-cluster --profile goorm
./scripts/bootstrap-platform.sh

이번엔 helm이 설치되어 있지 않다는 오류가 떴다.

[ERROR] helm 미설치

helm은 Kubernetes 패키지 매니저로, 차트(chart)라는 단위로 애플리케이션을 클러스터에 쉽게 배포할 수 있게 해준다. bootstrap 스크립트 내부에서 helm을 사용하기 때문에 반드시 설치가 필요했다.

Linux라면 sudo 명령어로 간단히 설치할 수 있지만, Git Bash 환경에서는 sudo 권한이 없어서 수동으로 다운받아 설치했다.

curl -L https://get.helm.sh/helm-v3.16.0-windows-amd64.zip -o helm.zip
unzip helm.zip
mv windows-amd64/helm.exe ./helm.exe
export PATH=$PATH:/c/pposiraegi-ecommerce

EKS 인증 문제

helm까지 설치하고 다시 실행했더니 이번엔 EKS 인증 오류가 떴다.

kubectl get nodes도 동일한 오류가 발생했다. aws eks get-token은 정상적으로 토큰을 반환하는데, kubectl이 이를 제대로 활용하지 못하는 상황이었다.

kubeconfig를 확인해보니 command: aws로 설정되어 있었는데, Git Bash 환경에서 aws CLI의 경로를 제대로 찾지 못하는 것이 원인이었다.

kubeconfig란? kubectl이 어떤 클러스터에 어떻게 접속할지 정의해둔 설정 파일이다. 보통 ~/.kube/config 경로에 위치한다.

kubeconfig 초기화 및 경로 문제 해결

전체 경로로 바꿔봤지만 경로에 공백이 포함되어 있어 또 실패했다. kubeconfig를 완전히 초기화하고 다시 시도했다.

rm ~/.kube/config
aws eks update-kubeconfig --region ap-northeast-2 --name pposiraegi-cluster --profile goorm
kubectl get nodes

여전히 안 됐다. kubeconfig 내용을 직접 확인해봤다.

command: aws 부분이 문제였다. aws CLI의 전체 경로로 바꿔야 하는데, Windows 특성상 경로에 공백이 포함되어 있어(C:\Program Files\...) 그대로 쓸 수가 없었다.

먼저 aws CLI의 실제 경로를 확인했다.

which aws

공백 문제를 우회하기 위해 심볼릭 링크를 만들기로 했다.

심볼릭 링크 생성

심볼릭 링크란 특정 파일이나 경로를 가리키는 바로가기 파일이다. 공백 없는 경로에 링크를 걸어두면 경로 문제를 우회할 수 있다.

ln -s "/c/Program Files/Amazon/AWSCLIV2/aws.exe" ~/aws.exe
sed -i 's|command: aws|command: /c/Users/gkthf/aws.exe|g' ~/.kube/config
kubectl get nodes

kubectl이 Windows 네이티브 바이너리라 Windows 경로 형식으로 바꿔서 다시 시도했다.

sed -i 's|command: /c/Users/gkthf/aws.exe|command: C:\\Program Files\\Amazon\\AWSCLIV2\\aws.exe|g' ~/.kube/config
kubectl get nodes

경로는 이제 제대로 찾는데, 이번엔 인증 문제가 또 떴다. kubeconfig 상태를 다시 확인했다.

cat ~/.kube/config | grep "command:"

경로는 맞는데 AWS_PROFILE 환경변수가 제대로 전달되지 않는 것 같아서, kubeconfig에 profile 설정이 있는지 확인했다.

cat ~/.kube/config | grep -A3 "env:"

profile은 존재했다. 그렇다면 AWS 자체 권한 문제일 수 있겠다 싶어 AWS 콘솔에 접속해서 확인해봤다.

IAM 사용자 목록을 보니 nahyung과 jihoon은 있는데 terraform-user가 없었다. kubeconfig에는 terraform-user 프로파일로 인증하도록 설정되어 있었으니 당연히 권한 오류가 날 수밖에 없었다.

terraform-user를 IAM에 생성한 뒤 다시 kubectl get nodes를 실행했다.

권한 할당

연결은 됐는데 이번엔 권한이 없다는 오류가 떴다. EKS는 IAM 사용자가 존재하더라도 클러스터 내부에 별도로 접근 권한을 부여해야 한다.

AWS 콘솔에서 다음 순서로 권한을 추가했다.

EKS → 해당 클러스터 → Access entries → terraform-user 선택 → Add access policy → AmazonEKSClusterAdminPolicy 추가

추가 완료 후 다시 실행했다.

kubectl get nodes

노드 목록이 정상적으로 출력됐다.

bootstrap 실행

경로 문제와 권한 문제가 모두 해결되어 드디어 bootstrap 스크립트를 실행할 수 있었다.

export PATH=$PATH:/c/pposiraegi-ecommerce
helm version
./scripts/bootstrap-platform.sh

bootstrap이 정상적으로 실행되며 ArgoCD, Karpenter, Istio 등 플랫폼 컴포넌트들이 클러스터에 설치되기 시작했다. 삽질이 길었지만 결국 해결됐다!

"production" not found 에러

이 에러는 production 네임스페이스가 존재하지 않아 발생하는 오류다. 원인을 파악해보니, terraform apply만 완료된 상태에서 아직 부트스트랩을 실행하지 않았기 때문에 발생하는 문제로 보였다. 기존 워크플로우에는 ECR에 이미지가 푸시된 이후 kubectl rollout restart를 실행하는 단계가 있었는데, ArgoCD가 자동으로 Sync를 수행하므로 해당 스텝은 사실상 불필요했다. 따라서 deploy-all.yml에서 아래 구간을 제거했다.

- name: Update kubeconfig
        run: aws eks update-kubeconfig --region ${{ env.AWS_REGION }} --name ${{ env.EKS_CLUSTER }}

      - name: Rollout restart (ArgoCD sync fallback)
        run: |
          kubectl rollout restart deployment/${{ matrix.service }} -n production

그런 다음 자동으로 Actions가 실행되기 때문에 기다려주었다.

수정 후 GitHub Actions가 자동으로 트리거되었고, 결과는 성공이었다.

처음에 깃허브 argocd가 안되어서 왜 그런가 봤더니

조직 레벨에서 외부 액션 사용이 막혀있어서 pnpm/action-setup@v3 같은 액션을 못 쓰는 문제가 생겼다. 이거를 프로젝트 레포에서 보니 변경이 막혀있어서

조직 Settings에서 "Allow all actions" 으로 변경해서 해결하였다.

terraform.tfvars가 .gitignore에 막혀서 변수 못 읽는 문제

보안상 tfvars 파일은 git에 올리지 않는데, GitHub Actions는 로컬 파일을 못 읽는 문제도 발생했다. 이는 CI 실행 시 GitHub Secrets에서 값을 주입해서 tfvars를 동적으로 생성하는 방식으로 해결하였다.

DockerFile 못찾는 오류

이렇게 apply까진 했는데 오류가 떴다. 에러를 확인해보니 DockerFIle을 못찾는 오류이다.

워크플로우에서는 working-directory: ./backend 로 설정했는데 실제 Dockerfile 위치가 다른것이다.

이렇게 백엔드 경로에 DockerFile이 없어서,

deploy-all.yml에서

      - name: Build, tag, and push image to Amazon ECR
        env:
          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
          ECR_REPOSITORY: pposiraegi-${{ matrix.service }}
          IMAGE_TAG: ${{ github.sha }}
        run: |
          docker build --build-arg MODULE_NAME=${{ matrix.service }} -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG -t $ECR_REGISTRY/$ECR_REPOSITORY:latest .
          docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
          docker push $ECR_REGISTRY/$ECR_REPOSITORY:latest

working-directory: ./backend 이 줄을 삭제해준다.

그리고나서 다시 Actions를 실행해본다.

프론트엔드 오류

패키지 이름 오류

이번에는 프론트엔드쪽이 오류가 떴다.

프론트엔드 패키지 이름이 frontend가 아닌 것이다.

Get-Content해서 보니 timedeal-front라고 뜬다.

따라서 deploy-all.yml에서 패키지이름을 timedeal-front로 바꿔준다 (json을 frontend로 바꾸는게 낫지 않나 싶었는데 다른곳에서 참조할 경우가 있기 때문에 json에 맞추어서 depoly-all 파일을 바꿔준다.)

##기존
      - name: Build Frontend
        run: pnpm turbo run build --filter=frontend
##바꾼 코드
      - name: Build Frontend
        run: pnpm turbo run build --filter=timedeal-front

이렇게 코드를 바꿔준다.

ESLint 오류로 빌드 실패

이렇게 오류가 또 생겼는데 찾아보니, React useEffect missing dependencies, 미사용 변수 선언 등 ESLint 규칙 위반으로 빌드 실패한 것이었다.

프론트엔드도 내 담당이기 때문에 코드를 직접 수정해준다.

Run pnpm turbo run build --filter=timedeal-front

Attention:
Turborepo now collects completely anonymous telemetry regarding usage.
This information is used to shape the Turborepo roadmap and prioritize features.
You can learn more, including how to opt-out if you'd not like to participate in this anonymous program, by visiting the following URL:
https://turborepo.dev/docs/telemetry


   • Packages in scope: timedeal-front
   • Running build in 1 packages
   • Remote caching disabled

timedeal-front:build
cache miss, executing b851ac8de420a9b8

> timedeal-front@0.1.0 build /home/runner/work/pposiraegi-ecommerce/pposiraegi-ecommerce/frontend
> react-scripts build

Creating an optimized production build...

Treating warnings as errors because process.env.CI = true.
Most CI servers set it automatically.

Failed to compile.

[eslint] 
src/api/auth.js
  Line 167:1:  Assign object to a variable before exporting as module default  import/no-anonymous-default-export

src/api/config.js
  Line 7:1:  Assign object to a variable before exporting as module default  import/no-anonymous-default-export

src/api/order.js
  Line 118:1:  Assign object to a variable before exporting as module default  import/no-anonymous-default-export

src/api/timedeal.js
  Line 182:1:  Assign object to a variable before exporting as module default  import/no-anonymous-default-export

src/pages/AddressManager.jsx
  Line 30:6:  React Hook useEffect has missing dependencies: 'navigate' and 'user'. Either include them or remove the dependency array  react-hooks/exhaustive-deps

src/pages/AdminPage.jsx
  Line 57:6:  React Hook useEffect has a missing dependency: 'fetchDeals'. Either include it or remove the dependency array  react-hooks/exhaustive-deps

src/pages/MyPage.jsx
  Line 24:6:    React Hook useEffect has missing dependencies: 'navigate' and 'user'. Either include them or remove the dependency array  react-hooks/exhaustive-deps
  Line 227:28:  'v' is assigned to itself                                                                                                 no-self-assign

src/pages/OrderResult.jsx
  Line 26:6:  React Hook useEffect has missing dependencies: 'fetchOrder' and 'order'. Either include them or remove the dependency array  react-hooks/exhaustive-deps

src/pages/TimeDealDetail.jsx
  Line 41:6:  React Hook useEffect has missing dependencies: 'fetchDeal', 'fetchRelatedDeals', and 'user'. Either include them or remove the dependency array  react-hooks/exhaustive-deps
  Line 47:6:  React Hook useEffect has a missing dependency: 'fetchDeal'. Either include it or remove the dependency array                                     react-hooks/exhaustive-deps

src/pages/TimeDealList.jsx
  Line 6:26:   'logout' is defined but never used            no-unused-vars
  Line 12:16:  'setUser' is assigned a value but never used  no-unused-vars

src/pages/WishList.jsx
  Line 18:6:  React Hook useEffect has a missing dependency: 'navigate'. Either include it or remove the dependency array  react-hooks/exhaustive-deps


 ELIFECYCLE  Command failed with exit code 1.
Error: timedeal-front#build: command (/home/runner/work/pposiraegi-ecommerce/pposiraegi-ecommerce/frontend) /home/runner/setup-pnpm/node_modules/.bin/pnpm run build exited (1)
 ERROR  timedeal-front#build: command (/home/runner/work/pposiraegi-ecommerce/pposiraegi-ecommerce/frontend) /home/runner/setup-pnpm/node_modules/.bin/pnpm run build exited (1)

 Tasks:    0 successful, 1 total
Cached:    0 cached, 1 total
  Time:    13.829s 
Failed:    timedeal-front#build

 ERROR  run failed: command  exited (1)
Error: Process completed with exit code 1.

일단 오류 로그는 이렇게 떴다.

• frontend/src/api/auth.js
• frontend/src/api/config.js
• frontend/src/api/order.js
• frontend/src/api/timedeal.js
• frontend/src/pages/AddressManager.jsx
• frontend/src/pages/AdminPage.jsx
• frontend/src/pages/MyPage.jsx
• frontend/src/pages/OrderResult.jsx
• frontend/src/pages/TimeDealDetail.jsx
• frontend/src/pages/TimeDealList.jsx
• frontend/src/pages/WishList.jsx 이렇게, 고쳐야할 파일이 11개나 되기 때문에 아찔했다. 그래도 임시방편으로 deploy-all에서 CI: false 하는것보단 근본적으로 고치는게 내 성격에 맞기 때문에 고쳐준다.

일단 코드가 frontend/src/api/auth.js같은 경우에는

##중략
// 401 인터셉터: 토큰 만료 시 자동 로그아웃 + 로그인 페이지 이동
axios.interceptors.response.use(
  res => res,
  err => {
    if (err.response?.status === 401) {
      localStorage.removeItem('accessToken');
      localStorage.removeItem('refreshToken');
      localStorage.removeItem('user');
      sessionStorage.removeItem('user');
      // 현재 페이지가 /login이 아닐 때만 리다이렉트
      if (!window.location.pathname.startsWith('/login')) {
        window.location.href = '/login?expired=1';
      }
    }
    return Promise.reject(err);
  }
);

export default { login, register, logout, getCurrentUser, saveAddress, getAddress };

이렇게 되어있는데 맨 마지막줄을

const authAPI = { login, register, logout, getCurrentUser, saveAddress, getAddress };
export default authAPI;

이런식으로 고쳐준다. (거의 모든 파일이 저렇게 되어있어서 저런식으로 고쳐준다.)

또는 useEffect에서 발생하는 오류가 있는데, 이는 dependency array 문제다. React의 useEffect는 두 번째 인자로 dependency array를 받는데, useEffect 내부에서 사용하는 변수나 함수가 dependency array에 없으면 ESLint가 경고를 띄운다.

예를 들어 AddressManager.jsx의 경우

jsuseEffect(() => {
    if (!user) { navigate('/login'); return; }
    ...
}, []); // ← navigate, user를 사용하는데 dependency array가 비어있음

이런 경우 navigate와 user를 dependency array에 추가해줘야 한다.

jsuseEffect(() => {
    if (!user) { navigate('/login'); return; }
    ...
}, [navigate, user]); // ← 추가

단, TimeDealDetail.jsx처럼 fetchDeal, fetchRelatedDeals 같은 함수를 dependency에 넣으면 무한루프가 발생할 수 있다. 이런 경우 해당 함수를 useCallback으로 감싸서 함수 참조가 변경되지 않도록 처리해준다.

그리고나서 Actions가 잘 돌아가는지 확인한다.

fetchDeals, fetchOrder를 useCallback으로 감싸 무한루프 방지

Actions를 돌렸더니 이러한 오류가 떴다.

Run pnpm turbo run build --filter=timedeal-front

Attention:
Turborepo now collects completely anonymous telemetry regarding usage.
This information is used to shape the Turborepo roadmap and prioritize features.
You can learn more, including how to opt-out if you'd not like to participate in this anonymous program, by visiting the following URL:
https://turborepo.dev/docs/telemetry


   • Packages in scope: timedeal-front
   • Running build in 1 packages
   • Remote caching disabled

timedeal-front:build
cache miss, executing 381ed73731ab9079

> timedeal-front@0.1.0 build /home/runner/work/pposiraegi-ecommerce/pposiraegi-ecommerce/frontend
> react-scripts build

Creating an optimized production build...

Treating warnings as errors because process.env.CI = true.
Most CI servers set it automatically.

Failed to compile.

[eslint] 
src/pages/AdminPage.jsx
  Line 57:7:  'fetchDeals' was used before it was defined                                                                                                                                             no-use-before-define
  Line 59:9:  The 'fetchDeals' function makes the dependencies of useEffect Hook (at line 57) change on every render. To fix this, wrap the definition of 'fetchDeals' in its own useCallback() Hook  react-hooks/exhaustive-deps

src/pages/OrderResult.jsx
  Line 26:6:  React Hook useEffect has a missing dependency: 'fetchOrder'. Either include it or remove the dependency array  react-hooks/exhaustive-deps
Error: timedeal-front#build: command (/home/runner/work/pposiraegi-ecommerce/pposiraegi-ecommerce/frontend) /home/runner/setup-pnpm/node_modules/.bin/pnpm run build exited (1)
 ERROR  timedeal-front#build: command (/home/runner/work/pposiraegi-ecommerce/pposiraegi-ecommerce/frontend) /home/runner/setup-pnpm/node_modules/.bin/pnpm run build exited (1)


 ELIFECYCLE  Command failed with exit code 1.

 Tasks:    0 successful, 1 total
Cached:    0 cached, 1 total
  Time:    13.493s 
Failed:    timedeal-front#build

 ERROR  run failed: command  exited (1)
Error: Process completed with exit code 1.

아까보다는 나아졌다. 이제는 AdminPage.jsx랑 OrderResult.jsx만 에러가 뜨고 있다.

AdminPage.jsx - import에 useCallback 추가하고 fetchDeals를 useCallback으로 감싸고 useEffect 위로 올려 수정해준다.

OrderResult.jsx - import에 useCallback 추가하고 fetchOrder를 useCallback으로 감싸 수정해준다.

그리고 다시 Actions를 실행해준다.

fetchDeals, fetchOrder 함수 누락으로 인한 not defined 오류 수정

방금 고친 AdminPage랑 OrderResult에서 여러가지를 수정하며, 쓰지 않는 함수를 삭제했는데 잘못 삭제하여 함수를 찾지 못한다고 에러가 떠서 다시 추가해준다.

그리고 또 Actions를 기대해준다.

프론트엔드 마침내 성공

마침내 프론트엔드 빌드가 성공했다. 길고 길었던 ESLint 오류와의 싸움이 끝났다.

이제 4개의 백엔드와의 긴 싸움이 남았다.

저번 포스팅에서 ArgoCD 연결까지는 성공했는데, production Pod를 띄우는 과정에서 CrashLoopBackOff 오류가 발생했다.

이번 포스팅에서는 원인을 추적하고 해결하는 과정을 기록한다.

CrashLoopBackOff란?
컨테이너가 시작됐다가 바로 죽는 걸 반복하는 상태다.
쿠버네티스가 "계속 죽으니까 잠깐 기다렸다가 다시 시작할게" 하면서 점점 재시작 간격을 늘린다.
보통 앱 설정 오류, DB 연결 실패, 환경변수 누락 등이 원인이다.

1. EKS 연결

먼저 로컬에서 EKS 클러스터에 접근할 수 있도록 kubeconfig를 설정한다.

# kubeconfig 연결
aws eks update-kubeconfig --region ap-northeast-2 --name pposiraegi-cluster --profile goorm

# 노드 상태 확인
kubectl get nodes

노드가 Ready 상태로 뜨면 클러스터 연결은 정상이다.

노드(Node)란?
쿠버네티스에서 실제로 컨테이너가 실행되는 서버(가상머신)다.
EKS에서는 EC2 인스턴스가 노드 역할을 한다.

2. 어떤 Pod가 죽었는지 확인

kubectl get pods -n production

아무것도 뜨지 않았다.

-n production이란?
-n은 네임스페이스(namespace)를 지정하는 옵션이다.
쿠버네티스는 리소스를 네임스페이스라는 공간으로 분리해서 관리한다.
production은 실제 서비스가 올라가는 공간이다.

production 네임스페이스에 Pod가 하나도 없다는 건, ArgoCD가 아직 sync를 하지 않은 것이다.
즉, GitHub 레포에 있는 매니페스트 파일들이 클러스터에 아직 반영되지 않은 상태라는 뜻이다.

ArgoCD부터 다시 설치하고 연결해야 한다.

3. ArgoCD 재설치

# argocd 네임스페이스 생성
kubectl create namespace argocd

# 공식 매니페스트 적용
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

created 메시지들이 쭉 뜨면 설치가 진행 중인 것이다.

설치 완료 후 Pod 상태를 확인한다:

kubectl get pods -n argocd

모든 Pod의 STATUS가 Running으로 바뀌면 다음 단계로 넘어간다.
처음엔 ContainerCreating이나 Pending으로 뜨는 게 정상이니 잠깐 기다리면 된다.

4. ArgoCD UI 접속

ArgoCD는 웹 UI를 제공한다. 포트 포워딩으로 로컬에서 접속한다.

kubectl port-forward svc/argocd-server -n argocd 8080:443

포트 포워딩이란?
클러스터 내부 서비스를 외부에 노출하지 않고, 내 PC에서만 접근할 수 있도록 통로를 만드는 것이다.
위 명령어는 "내 PC의 8080번 포트로 들어오는 요청을 ArgoCD 서버의 443 포트로 전달해줘"라는 뜻이다.

브라우저에서 https://localhost:8080 접속 후 로그인한다.

초기 비밀번호 확인 (PowerShell):

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | ForEach-Object { [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($_)) }

• 아이디: admin
• 비밀번호: 위 명령어 출력값

⚠️ 브라우저에서 "안전하지 않은 연결" 경고가 뜨면 고급 → 계속 진행을 누르면 된다.
자체 서명 인증서라서 뜨는 경고로, 로컬 개발 환경에서는 정상이다.

5. namespace 및 Secret 생성

ArgoCD가 배포할 production 네임스페이스와 DB/Redis 접속 정보를 미리 만들어줘야 한다.
이 작업을 먼저 해두지 않으면 Pod가 뜨다가 환경변수를 못 찾아서 바로 죽는다.

# namespace, configmap 먼저 생성
kubectl apply -f kubernetes/base/namespace.yaml
kubectl apply -f kubernetes/base/configmap.yaml

RDS, Redis 엔드포인트를 확인한다:

terraform output rds_endpoint
terraform output elasticache_endpoint

확인한 엔드포인트로 Secret을 생성한다:

kubectl create secret generic app-secret \
  --namespace=production \
  --from-literal=DB_HOST=RDS엔드포인트 \
  --from-literal=DB_USERNAME=pposiraegi \
  --from-literal=DB_PASSWORD=DB비밀번호 \
  --from-literal=REDIS_HOST=Redis엔드포인트 \
  --from-literal=JWT_SECRET=JWT시크릿

Secret이란?
비밀번호, API 키처럼 코드에 직접 넣으면 안 되는 민감한 값을 쿠버네티스 내부에서 안전하게 관리하는 리소스다.
--from-literal로 값을 넣으면 자동으로 base64로 인코딩되어 저장된다.
Pod에서는 환경변수 형태로 이 값을 꺼내 쓸 수 있다.

6. ArgoCD App 연결 및 Sync

kubectl apply -f argocd-app.yaml

터미널에서 직접 sync한다:

# argocd-server Pod 이름 먼저 확인
kubectl get pods -n argocd

# ArgoCD 서버에 로그인
kubectl -n argocd exec -it [argocd-server-Pod이름] -- \
  argocd login localhost:8080 --insecure --username admin --password [비밀번호]

# Sync 실행
kubectl -n argocd exec -it [argocd-server-Pod이름] -- \
  argocd app sync pposiraegi --insecure

exec -it란?
실행 중인 Pod 안으로 직접 들어가서 명령어를 실행하는 것이다.
마치 서버에 SSH로 접속해서 명령어를 치는 것과 같다.

7. Pod 상태 확인 및 로그 분석

kubectl get pods -n production

Pod들이 뜨기 시작하면 각 Pod의 로그를 확인한다:

# 현재 로그 확인
kubectl logs -n production [죽은Pod이름]

# 이미 죽은 컨테이너의 직전 로그 확인
kubectl logs -n production [죽은Pod이름] --previous

order-service Pod의 로그를 먼저 확인했다.

Connect timed out

원인 분석:

보안 그룹(Security Group)이란?
AWS에서 서버 간 트래픽을 허용/차단하는 방화벽 역할을 한다.
RDS의 보안 그룹에 EKS 노드가 포함되어 있지 않으면 아무리 올바른 주소로 접속해도 연결이 차단된다.

8. EKS 노드 보안 그룹을 동적으로 추가

EKS는 배포할 때마다 보안 그룹 ID가 바뀐다.
그래서 ID를 하드코딩하지 않고, Terraform이 자동으로 가져오도록 동적으로 연결했다.

왜 동적으로 해야 할까?
terraform apply를 할 때마다 EKS가 새 보안 그룹을 만든다.
매번 수동으로 ID를 복사해서 넣으면 실수가 생기고 유지보수가 어렵다.
Terraform 모듈끼리 연결해두면 항상 최신 ID를 자동으로 참조한다.

1) modules/security/variables.tf에 변수 추가

variable "eks_cluster_sg_id" {
  description = "EKS cluster security group ID"
  default     = ""
}

2) modules/security/main.tf 수정

RDS와 Redis 보안 그룹에 EKS 노드 접근 허용 규칙을 추가한다.

# RDS 보안 그룹 — PostgreSQL 5432 포트
ingress {
  from_port       = 5432
  to_port         = 5432
  protocol        = "tcp"
  security_groups = [var.eks_cluster_sg_id]
}

# Redis 보안 그룹 — Redis 6379 포트
ingress {
  from_port       = 6379
  to_port         = 6379
  protocol        = "tcp"
  security_groups = [var.eks_cluster_sg_id]
}

3) modules/eks/outputs.tf에 출력값 추가

EKS 모듈이 보안 그룹 ID를 외부로 내보낼 수 있도록 output을 추가한다.

output "cluster_security_group_id" {
  value = aws_eks_cluster.main.vpc_config[0].cluster_security_group_id
}

4) 루트 main.tf에서 모듈 간 연결

module "security" {
  source = "./modules/security"

  project_name      = var.project_name
  vpc_id            = module.networking.vpc_id
  eks_cluster_sg_id = module.eks.cluster_security_group_id  # EKS에서 자동으로 가져옴
}

이렇게 연결해두면 terraform apply를 할 때마다 EKS가 새로 만드는 보안 그룹 ID를 자동으로 참조한다.

수정 후 적용:

terraform apply -var-file="terraform.tfvars"

9. Terraform apply 후 ArgoCD 재sync

apply 후 ArgoCD 상태를 확인했는데 뭔가 이상해 보였다.

혹시 Secret이나 엔드포인트가 잘못됐나 싶어서 다시 확인했다.

Secret과 엔드포인트는 정상적으로 등록된 것을 확인했다. 그래서 다시 sync를 시도했다.

# ArgoCD 서버에 로그인
kubectl -n argocd exec -it argocd-server-78f5bb67d5-xt9g6 -- \
  argocd login localhost:8080 --insecure --username admin --password [패스워드]

# Sync 실행
kubectl -n argocd exec -it argocd-server-78f5bb67d5-xt9g6 -- \
  argocd app sync pposiraegi --insecure

각 명령어의 의미를 정리하면:

첫 번째 명령어 — ArgoCD 로그인

두 번째 명령어 — App Sync

10. 그런데 또 문제가 — kubeconfig와 RBAC

여기까지 했는데도 production Pod가 여전히 뜨지 않았다.

팀원과 공유하는 과정에서 원인이 두 가지 더 있다는 걸 알게 됐다.

원인 1 — kubeconfig가 예전 엔드포인트를 가리키고 있음

terraform apply를 다시 하면 EKS 클러스터가 재생성되면서 API 서버 엔드포인트 주소가 바뀐다.
그런데 로컬의 kubeconfig는 예전 주소를 그대로 들고 있기 때문에, kubectl 명령어가 존재하지 않는 클러스터에 계속 요청을 보내고 있던 것이다.
해결 방법은 간단하다. aws eks update-kubeconfig를 다시 실행해서 최신 엔드포인트로 갱신해주면 된다.

aws eks update-kubeconfig --region ap-northeast-2 --name pposiraegi-cluster --profile goorm

원인 2 — RBAC 권한 문제

RBAC(Role-Based Access Control)란?
쿠버네티스에서 "누가 무엇을 할 수 있는지" 권한을 관리하는 시스템이다.
ArgoCD가 production 네임스페이스에 Pod를 배포하려면 그에 맞는 권한이 부여되어 있어야 한다.
권한이 없으면 sync는 성공해도 실제 리소스가 생성되지 않거나 오류가 발생한다.

이 두 가지 문제가 복합적으로 작용해서 production Pod가 계속 뜨지 않았던 것이다.

마무리

이번 포스팅에서 겪은 문제들을 정리하면:

트러블슈팅을 하다 보면 문제 하나를 해결하면 또 다른 문제가 나오는 게 일상이다.
RBAC 권한 설정과 부트스트랩 스크립트 적용 과정은 다음 포스팅에서 이어서 정리할 예정이다. 😅

이번 포스팅은 ArgoCD Sync를 시도하다가 연속으로 두 가지 문제를 맞닥뜨린 트러블슈팅 기록이다.
결론부터 말하면 레포 이름 오타 → 폴더 경로 오류 → RDS 보안 그룹 차단 순서로 문제가 터졌고, 아직 완전히 해결 전 단계다.

사전 준비 — 엔드포인트 확인 및 리소스 생성

Sync 전에 RDS, ElastiCache 엔드포인트를 확인하고 쿠버네티스 리소스를 미리 만들어둔다.

# RDS, ElastiCache 엔드포인트 확인
terraform output rds_endpoint
terraform output elasticache_endpoint

# namespace, configmap 생성
kubectl apply -f kubernetes/base/namespace.yaml
kubectl apply -f kubernetes/base/configmap.yaml

# DB, Redis, JWT 정보를 Secret으로 등록
kubectl create secret generic app-secret \
  --namespace=production \
  --from-literal=DB_HOST=pposiraegi-db.c5wkmcaauwn2.ap-northeast-2.rds.amazonaws.com \
  --from-literal=DB_USERNAME=pposiraegi \
  --from-literal=DB_PASSWORD=DB비밀번호 \
  --from-literal=REDIS_HOST=pposiraegi-redis.qka9g8.0001.apn2.cache.amazonaws.com \
  --from-literal=JWT_SECRET=JWT시크릿

Secret이란?
비밀번호, API 키처럼 외부에 노출되면 안 되는 값을 쿠버네티스 안에서 안전하게 관리하는 리소스다.
--from-literal로 값을 직접 넣으면 자동으로 base64 인코딩되어 저장된다.

트러블슈팅 1 — ArgoCD Sync 실패 (레포/경로 문제)

Sync 시도

kubectl apply -f argocd-app.yaml

# UI에서 SYNC → SYNCHRONIZE 클릭 후 반응 없음
# 터미널로 직접 해결하기로 함

# ArgoCD 파드 확인
kubectl get pods -n argocd

# ArgoCD 서버에 직접 로그인
kubectl -n argocd exec -it argocd-server-7648988dc6-zq7hn -- \
  argocd login localhost:8080 --insecure --username admin --password NDiUuc1t8XJKmF2O

# 수동 Sync
kubectl -n argocd exec -it argocd-server-7648988dc6-zq7hn -- \
  argocd app sync pposiraegi --insecure

UI에서 Sync 버튼을 눌렀는데 아무 반응이 없어서, ArgoCD 서버 파드에 직접 exec로 들어가서 CLI로 진행했다.

문제 1 — feat/eks-migration 브랜치를 못 찾음

브랜치를 찾지 못한다는 에러가 발생했다. 하나씩 확인했다.

# 원격 브랜치 목록 확인
git branch -r

→ 브랜치는 실제로 존재함.

# 해당 브랜치에 커밋이 있는지 확인
git log --oneline origin/feat/eks-migration

→ 커밋도 있음.

# argocd-app.yaml 내용 확인
cat argocd-app.yaml

→ path 설정은 이상 없음.

# 실제 레포 이름 확인
git remote -v

원인 발견 — 레포 이름 오타

argocd-app.yaml의 repoURL을 올바른 주소로 수정 후 재적용했다.

kubectl apply -f argocd-app.yaml
kubectl -n argocd exec -it argocd-server-7648988dc6-zq7hn -- \
  argocd app sync pposiraegi --insecure

문제 2 — app path does not exist

레포 이름은 고쳤는데 이번엔 경로 문제가 발생했다.

원인

ArgoCD는 레포 루트에서 kubernetes/ 폴더를 찾는데,
실제 폴더 구조는 infrastructure/kubernetes/ 였다.

pposiraegi-ecommerce/
└── infrastructure/
    └── kubernetes/   ← 실제 위치

argocd-app.yaml의 path를 infrastructure/kubernetes로 수정 후 재적용했다.

kubectl apply -f argocd-app.yaml
kubectl -n argocd exec -it argocd-server-7648988dc6-zq7hn -- \
  argocd app sync pposiraegi --insecure

→ 연결 성공 🎉

트러블슈팅 2 — Pod CrashLoopBackOff (RDS 보안 그룹 차단)

다시 Sync 후 Pod 상태 확인

kubectl -n argocd exec -it argocd-server-7648988dc6-zq7hn -- \
  argocd app sync pposiraegi --insecure

→ successfully synced

그런데 Pod 상태를 확인하니 문제가 있었다.

kubectl get pods -n production

처음엔 Running처럼 보였는데...

→ CrashLoopBackOff 발생

CrashLoopBackOff란?
컨테이너가 시작됐다가 바로 죽는 걸 반복하는 상태다.
보통 앱 내부 에러, 설정 오류, 외부 서비스 연결 실패 등이 원인이다.

no more tasks 문제

Sync 중 no more tasks 에러도 함께 발생했다.

ArgoCD가 infrastructure/kubernetes/ 하위 폴더를 재귀적으로 탐색하지 못해서 production Pod를 찾지 못하는 문제였다.

해결 — directory.recurse: true 추가

argocd-app.yaml에 재귀 탐색 옵션을 추가했다.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: pposiraegi
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/Goorm4I/pposiraegi-ecommerce
    targetRevision: feat/eks-migration
    path: infrastructure/kubernetes
    directory:
      recurse: true   # 하위 폴더까지 재귀적으로 탐색
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true

kubectl apply -f argocd-app.yaml
kubectl -n argocd exec -it argocd-server-7648988dc6-zq7hn -- \
  argocd app sync pposiraegi --insecure

Pod는 뜨기 시작했지만... CrashLoopBackOff는 계속됐다.

로그로 원인 파악

kubectl logs -n production order-service-88547fbf4-vcl4k

Connect timed out

원인 — EKS 노드 → RDS 보안 그룹이 막혀있음

기존 RDS 보안 그룹 인바운드 규칙이 api_gateway_sg, internal_msa_sg만 허용하고 있었는데, EKS 노드는 다른 보안 그룹을 사용하고 있어서 접근이 차단된 상태였다.

해결 — EKS 노드 보안 그룹 ID 확인 후 RDS/Redis 보안 그룹에 추가

# EKS 클러스터 보안 그룹 ID 확인
aws eks describe-cluster \
  --name pposiraegi-cluster \
  --query "cluster.resourcesVpcConfig.clusterSecurityGroupId" \
  --output text \
  --profile goorm

→ sg-0aa36452edaf69dd9 확인

modules/security/main.tf에서 rds_sg와 redis_sg에 EKS 노드 보안 그룹을 추가했다.

rds_sg — PostgreSQL 5432 포트 허용 추가

resource "aws_security_group" "rds_sg" {
  vpc_id      = var.vpc_id
  name        = "${var.project_name}-rds-sg"
  description = "RDS PostgreSQL security group"

  ingress {
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.api_gateway_sg.id, aws_security_group.internal_msa_sg.id]
  }

  # EKS 노드 접근 허용 추가
  ingress {
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = ["sg-0aa36452edaf69dd9"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = { Name = "${var.project_name}-rds-sg" }
}

redis_sg — Redis 6379 포트 허용 추가

# EKS 노드 접근 허용 추가
ingress {
  from_port       = 6379
  to_port         = 6379
  protocol        = "tcp"
  security_groups = ["sg-0aa36452edaf69dd9"]
}

# Terraform으로 보안 그룹 변경 적용
terraform apply -var-file="terraform.tfvars"

정리

Terraform 적용 후 Pod가 정상적으로 뜨는지는 다음 포스팅에서 이어서 정리할 예정이다.

이번 포스팅에서는 AWS EKS 클러스터에 ArgoCD를 설치하고, GitHub 레포지토리와 연동해서 자동 배포까지 설정하는 과정을 정리했다.

ArgoCD란?
Kubernetes 환경에서 GitOps 방식의 배포를 도와주는 툴이다.
쉽게 말하면, GitHub에 코드를 올리면 ArgoCD가 자동으로 감지해서 클러스터에 배포해주는 자동화 배포 도구다.

1. kubeconfig 연결

먼저 로컬 환경에서 EKS 클러스터에 접근할 수 있도록 kubeconfig를 설정해야 한다.
kubectl 명령어가 어느 클러스터를 바라볼지 알려주는 작업이라고 생각하면 된다.

# kubeconfig 연결
aws eks update-kubeconfig --region ap-northeast-2 --name pposiraegi-cluster --profile goorm

# 클러스터 연결 확인
kubectl get nodes

• --region: 클러스터가 위치한 AWS 리전
• --name: EKS 클러스터 이름
• --profile: AWS CLI에 등록된 프로파일 이름

kubectl get nodes로 노드 목록이 출력되면 연결 성공이다.

2. ArgoCD 설치

ArgoCD를 위한 네임스페이스를 먼저 만들고, 공식 매니페스트를 적용해서 설치한다.

# ArgoCD 전용 네임스페이스 생성
kubectl create namespace argocd

# ArgoCD 공식 매니페스트 적용
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# 설치 완료 확인 (모든 Pod가 Running 상태여야 함)
kubectl get pods -n argocd

네임스페이스(namespace)란?
쿠버네티스 안에서 리소스를 논리적으로 분리하는 공간이다.
ArgoCD 관련 리소스만 모아두기 위해 별도 네임스페이스를 만든다.

설치 후 kubectl get pods -n argocd를 실행했을 때, 모든 Pod의 STATUS가 Running으로 바뀌면 설치 완료다. (처음엔 ContainerCreating으로 뜨는 게 정상이니 잠깐 기다리자.)

3. ArgoCD UI 접속

ArgoCD는 웹 UI를 제공한다. 외부에 바로 노출하지 않고 포트 포워딩으로 로컬에서 접속할 수 있다.

# 로컬 8080 포트 → ArgoCD 서버 443 포트로 포워딩
kubectl port-forward svc/argocd-server -n argocd 8080:443

포트 포워딩이란?
클러스터 내부 서비스를 외부로 노출하지 않고, 내 로컬 PC에서만 접근할 수 있도록 터널을 뚫어주는 것이다.

이 명령어를 실행한 상태로 브라우저에서 https://localhost:8080 에 접속하면 ArgoCD 로그인 화면이 나온다.

⚠️ 브라우저에서 "안전하지 않은 연결"이라고 경고가 뜰 수 있는데, 자체 서명 인증서라서 그렇다. 고급 → 계속 진행을 누르면 된다.

4. 초기 비밀번호 확인

초기 관리자 계정은 admin이고, 비밀번호는 쿠버네티스 시크릿에 저장되어 있다.

Linux / macOS:

kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d

Windows (PowerShell):

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | ForEach-Object { [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($_)) }

출력된 값이 초기 비밀번호다. 로그인 후에는 보안을 위해 비밀번호를 변경하는 걸 추천한다.

5. ArgoCD App 설정 (GitOps 연동)

이제 핵심이다. ArgoCD가 GitHub 레포지토리를 감시하고 자동으로 배포하도록 Application 리소스를 생성한다.

kubectl apply -f - <<EOF
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: pposiraegi
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/Goorm4I/pposiraegi-ecommerce-msa  # 감시할 GitHub 레포
    targetRevision: feat/eks-migration                             # 대상 브랜치
    path: kubernetes                                               # 매니페스트 파일 경로
  destination:
    server: https://kubernetes.default.svc
    namespace: production                                          # 배포할 네임스페이스
  syncPolicy:
    automated:
      prune: true      # 레포에서 삭제된 리소스는 클러스터에서도 삭제
      selfHeal: true   # 클러스터가 레포와 달라지면 자동으로 복구
    syncOptions:
    - CreateNamespace=true  # production 네임스페이스 없으면 자동 생성
EOF

yaml 파일로 따로 저장했다면 이렇게 적용할 수도 있다:

kubectl apply -f argocd-app.yaml

각 설정의 의미:

6. 상태 확인

ArgoCD UI에서 App이 정상적으로 생성된 것을 확인할 수 있다.

Synced + Healthy 상태가 뜨면 GitHub 레포와 클러스터가 정상적으로 연동된 것이다. 이제 해당 브랜치에 커밋을 푸시하면 ArgoCD가 자동으로 감지해서 클러스터에 반영해준다.

마무리

GitOps를 도입하면 배포 이력이 GitHub 커밋 히스토리에 그대로 남고, 문제가 생겼을 때 revert만으로 롤백이 가능해서 운영이 훨씬 편해진다. 처음 설정이 좀 번거롭지만 한 번 해두면 그 이후엔 정말 편하다!

팀원이 tfstate s3 버킷을 지정하면서 오류가 생겨서 이거때문에 terraform apply가 안되는 오류가 발생했다.

팀원이 보내준 사유는 다음과 같다

현재 pposiraegi-ecommerce repo에서 Terraform/EKS 접근 문제가 있습니다.
중요: 파일 수정하지 말고 먼저 진단만 해주세요. terraform apply 금지. terraform import 금지. destructive command 금지.
현재 확인된 상태: AWS_PROFILE=goorm 계정: 779846782353 EKS cluster: pposiraegi-cluster, ACTIVE, version 1.32 NodeGroup: pposiraegi-node-group, ACTIVE, t3.medium 2대 healthy Terraform backend: bucket = pposiraegi-tf-state-779846782353 key = ecommerce/terraform.tfstate 해당 backend key에 state object가 없는 것으로 보임 terraform plan 실행 시 기존 리소스를 인식하지 못하고 86 to add 따라서 현재 apply하면 중복 생성/충돌 위험 kubectl은 kubeconfig 생성은 되지만 Kubernetes API 접근 실패:"the server has asked for the client to provide credentials" EKS authenticationMode는 CONFIG_MAP 현재 IAM user arn:aws:iam::779846782353:user/jihoon이 aws-auth에 매핑되지 않은 것으로 추정
해야 할 일: 실제 Terraform state 위치를 찾기 backend.tf와 실제 state 위치 불일치 여부 확인 state 유실이면 import 대상 목록 정리만 하기 aws-auth 또는 EKS access 권한 복구 방안 제안 팀원이 공통으로 사용할 AWS_PROFILE/backend/tfvars 절차 문서화 제안

진단하기

이거에 대한 해결방법은 사실 아직까지 잘 모르겠다. 차근차근 진단해보기로 했다.

1. Terraform state 위치 찾기

# S3 버킷 목록 전체 확인
aws s3 ls --profile goorm

# 팀원이 말한 버킷 확인
aws s3 ls s3://pposiraegi-tf-state-779846782353 --profile goorm

# 버킷 안에 뭐가 있는지
aws s3 ls s3://pposiraegi-tf-state-779846782353 --recursive --profile goorm

이렇게 가장 최근에 만든 프로필인 pposiraegi-tf-state-779846782353에는 아무것도 없고

pposiraegi-tfstate-779846782353에 infrastructure/terraform.tfstate 파일이 들어있는 것을 확인할 수 있다.

2. 원인 파악

S3 버킷이 두 개 존재하는 것을 확인했다.

팀원이 설정한 backend 버킷 이름은 pposiraegi-tf-state-779846782353이었는데, 실제 state 파일은 pposiraegi-tfstate-779846782353에 있었다. 버킷 이름이 미묘하게 달랐던 것이 원인이었다.

팀원 backend 설정: bucket = "pposiraegi-tf-state-779846782353" ← 없는 버킷 (tf-state) key = "ecommerce/terraform.tfstate" ← 경로도 다름 실제 state 위치: bucket = "pposiraegi-tfstate-779846782353" ← 진짜 버킷 (tfstate) key = "infrastructure/terraform.tfstate" ← 실제 경로

3. backend.tf 파일 없는 것 확인

팀원 backend 설정: bucket = "pposiraegi-tf-state-779846782353" ← 없는 버킷 (tf-state) key = "ecommerce/terraform.tfstate" ← 경로도 다름 실제 state 위치: bucket = "pposiraegi-tfstate-779846782353" ← 진짜 버킷 (tfstate) key = "infrastructure/terraform.tfstate" ← 실제 경로

따라서, 중복생성과 충돌이 발생할 위험이 있었다.

4. 해결 방법: backend.tf 생성

infrastructure/backend.tf 파일을 새로 만들어서 S3 backend를 명시적으로 설정했다.

terraform {
  backend "s3" {
    bucket  = "pposiraegi-tfstate-779846782353"
    key     = "infrastructure/terraform.tfstate"
    region  = "ap-northeast-2"
    profile = "goorm"
  }
}

이렇게 하면 뭐가 좋아지냐면:

5. terraform init 재실행

backend.tf 생성 후 terraform init을 다시 실행해서 S3 backend를 인식시켜줬다.

terraform init -reconfigure

-reconfigure 옵션은 기존 backend 설정을 무시하고 새로운 backend로 다시 초기화하는 옵션이다.

이후 terraform plan을 실행하면 기존 리소스를 정상적으로 인식하고 No changes 또는 실제 변경사항만 표시되어야 한다.

정리

이번 문제의 핵심은 두 가지였다.

1. 버킷 이름 불일치: 팀원이 설정한 버킷 이름과 실제 state가 있는 버킷 이름이 달랐다.
2. backend.tf 파일 부재: 팀 전체가 공유해야 하는 backend 설정이 코드로 관리되지 않고 있었다.

앞으로는 backend.tf를 Git에 포함해서 팀원 모두가 동일한 S3 backend를 바라보도록 관리하도록 변경하였다.

본 콘텐츠는 구름 서포터즈 활동으로 지원을 받아 작성된 교육생의 실제 경험 후기입니다.

이전 게시물에서 프로젝트를 시작했을 때 포스팅을 남겨놓았다. 그때는 기획 수준이었는데, 지금은 그때와는 다른 고민들을 하기 시작했다. CI/CD 파이프라인 구성이라든지, 자동 배포 전략은 어떻게 할 것인지 등등. 아직은 반 수동 배포인 상황이지만, 앱이 잘 돌아가는 상태로는 만들었다. 일단 이전 게시물과 가장 크게 달라진 점은 인프라 구성도인 것 같다.

기존과 가장 달라진 점

기존엔 bastion 서버를 두어서 private 서브넷에 있는 자원들에 접근하게 했는데, 지금은 SSM 서비스를 이용해 콘솔에 로그인하면 바로 EC2에 접근할 수 있도록 변경했다. (현재 이 아키텍처도 수정해야 할 부분이 많다는 건 인지하고 있다. 백엔드 EC2를 private에 두어야 한다는 점 등.) 이 아래는 프로젝트 발표 때 사용했던 PPT다. 우리가 고려한 백엔드 엣지케이스라든가, 바뀐 인프라 아키텍처를 확인해볼 수 있다.

백엔드 엣지케이스 고려 및 바뀐 인프라 전략

bastion에서 SSM으로 전환한 이유

프로젝트 발표 중에 가장 첫번째로 받은 질문이 왜 bastion을 두지 않았느냐 인 것 같다. ssm으로 전환 시 가장 팀원들이랑 많이 얘기했던 부분들이기도 하고. 왜 bastion에서 ssm으로 전환하였냐면 다음과 같은 이유들 때문이다.

• 보안 측면에서 더 유리하다. bastion을 운영하려면 SSH 포트(22번)를 외부에 열어둬야 하는데, 이 자체가 공격 표면이 된다. SSM은 인바운드 포트를 아예 열 필요가 없고, IAM 기반으로 접근을 제어하기 때문에 보안상 더 낫다고 판단했다.
• bastion 서버 자체의 유지비용과 관리 포인트가 줄어든다. bastion도 결국 EC2 인스턴스라 비용이 나가고, 패치나 키 관리 같은 운영 부담도 생긴다. SSM으로 전환하면 그 오버헤드를 없앨 수 있다.
• 접근 이력 추적이 편하다. SSM Session Manager는 세션 로그를 CloudWatch나 S3에 자동으로 남길 수 있어서, 누가 언제 어떤 인스턴스에 접근했는지 감사(audit) 추적이 훨씬 수월하다. bastion 방식에서는 이걸 별도로 구성해야 한다.

다만 bastion을 완전히 버려야 하나에 대해선 아직도 고민 중이다. 지금은 서비스 규모가 작아서 SSM으로도 충분하지만, EC2 수가 늘어나거나 현업 환경처럼 여러 인스턴스를 빠르게 오가며 관리해야 하는 상황이라면 SSH로 직접 붙는 게 더 편할 수 있기 때문이다.