Alibi Detect 실전 딥다이브 — 이상치·드리프트·적대적 탐지를 코드로

Alibi Detect(SeldonIO)는 이상치(Outlier)·드리프트(Drift)·적대적 입력(Adversarial)을 탐지하는 프로덕션급 오픈소스 Python 라이브러리입니다. 보안 관점에서 이 셋은 각각 zero-day 이상 트래픽 탐지, 탐지 모델의 노후(개념 표류) 감시, 회피 공격(evasion) 탐지에 직결됩니다. 이 문서는 앞선 "XAI" 문서에서 소개만 했던 Alibi Detect를 실전 코드 중심으로 깊게 다룹니다.

1. Alibi Detect란 — 3대 축과 보안 매핑

2. 설치와 공통 API 패턴

# 설치 (TensorFlow 백엔드 기본)
pip install alibi-detect
# PyTorch 백엔드로 쓰려면
pip install alibi-detect[torch]

모든 detector는 동일한 반환 구조를 씁니다. predict()는 meta(메타데이터)와 data(실제 결과) 딕셔너리를 돌려줍니다.

preds = detector.predict(X)
preds['data']['is_outlier']      # 이상치: 0/1 배열
preds['data']['is_drift']        # 드리프트: 0(정상)/1(드리프트)
preds['data']['is_adversarial']  # 적대적: 0/1
preds['data']['instance_score']  # 샘플별 점수(옵션)
preds['data']['p_val']           # 드리프트 p-value(옵션)
preds['meta']                    # detector 이름·버전 등

3. 실전 ① 이상치 탐지 (zero-day) — IForest · Mahalanobis · VAE

정상 트래픽만 학습한 뒤, 거기서 벗어나는 샘플을 이상치로 봅니다. 라벨이 없어도 되므로 미지의(zero-day) 공격 탐지에 유리합니다(앞 "DDoS 탐지" 문서의 오토인코더/비지도 탐지와 같은 철학).

Isolation Forest — 표(tabular) flow 피처에 가볍고 빠름

import numpy as np
from alibi_detect.od import IForest
from alibi_detect.saving import save_detector, load_detector

# X_normal: 평상시 정상 트래픽 flow 피처 (n_samples, n_features) - 예: CIC-IDS 정상만
od = IForest(n_estimators=200)
od.fit(X_normal)                                  # 정상만 학습(비지도)
od.infer_threshold(X_normal, threshold_perc=95)   # 정상의 95%는 정상으로 → 임계값 자동 보정

preds = od.predict(X_test, return_instance_score=True)
is_outlier = preds['data']['is_outlier']          # 0/1 배열 (1 = 이상 트래픽)
scores     = preds['data']['instance_score']      # 샘플별 이상 점수
print(f"이상 트래픽 {is_outlier.sum()}건 / {len(is_outlier)}건")

save_detector(od, 'detectors/nids_iforest')       # 저장 → 장비에 배포
# od = load_detector('detectors/nids_iforest')    # 로드

Mahalanobis — 온라인(스트리밍) 이상치, 경량

from alibi_detect.od import Mahalanobis
# n_components: 내부 차원축소, std_clip: 이상치 영향 억제, start_clip: 통계 갱신 시작 시점
od = Mahalanobis(n_components=3, std_clip=3, start_clip=100)
od.infer_threshold(X_normal, threshold_perc=99)
preds = od.predict(X_test)                         # 분포 중심에서의 거리로 이상 판정
print(preds['data']['is_outlier'])

OutlierVAE — 복잡/고차원 데이터(딥러닝)

import tensorflow as tf
from tensorflow.keras.layers import Dense, InputLayer
from alibi_detect.od import OutlierVAE

n_features = X_normal.shape[1]; latent_dim = 2
encoder_net = tf.keras.Sequential([
    InputLayer((n_features,)), Dense(25, activation='relu'), Dense(10, activation='relu')])
decoder_net = tf.keras.Sequential([
    InputLayer((latent_dim,)), Dense(10, activation='relu'),
    Dense(25, activation='relu'), Dense(n_features, activation=None)])

od = OutlierVAE(encoder_net=encoder_net, decoder_net=decoder_net, latent_dim=latent_dim)
od.fit(X_normal, epochs=20)                        # 정상만 재구성하도록 학습
od.infer_threshold(X_normal, threshold_perc=95)
preds = od.predict(X_test, outlier_type='instance', return_instance_score=True)
# 복원 오차(reconstruction error)가 크면 이상 → "XAI 문서"의 오토인코더 원리와 동일

4. 실전 ② 드리프트 탐지 (모델 노후) — TabularDrift · MMDDrift

공격·정상 트래픽은 시간이 지나며 변합니다(개념 표류, concept drift). 그러면 배포된 탐지 모델이 낡아 성능이 떨어집니다. 드리프트 탐지는 "지금 들어오는 데이터가 배포 시점(참조)과 통계적으로 달라졌는가"를 검정해, 재학습 시점을 알려 줍니다.

TabularDrift — 혼합형 표 데이터(연속+범주), 피처별 KS·카이제곱

from alibi_detect.cd import TabularDrift

# X_ref: 배포 시점의 참조 데이터(정상 운영 트래픽 피처)
# categories_per_feature: 범주형 피처 인덱스 지정(예: 프로토콜=인덱스 3), 연속형은 생략
cd = TabularDrift(X_ref, p_val=0.05, categories_per_feature={3: None})

preds = cd.predict(X_new, drift_type='batch', return_p_val=True, return_distance=True)
print("드리프트:", preds['data']['is_drift'])       # 0/1
print("피처별 p-value:", preds['data']['p_val'])     # 어떤 피처가 변했는지까지 확인
print("피처별 거리:", preds['data']['distance'])
# → 연속형은 Kolmogorov-Smirnov, 범주형은 Chi-Square 검정, 다중검정은 Bonferroni/FDR 보정

MMDDrift — 고차원·비선형 분포 변화(커널 기반). 전처리로 차원축소 권장

from functools import partial
from alibi_detect.cd import MMDDrift
from alibi_detect.cd.tensorflow import preprocess_drift
from alibi_detect.models.tensorflow import UAE   # Untrained AutoEncoder(무학습 임베딩)

# 고차원(수십~수백 피처)일수록 원시 공간의 검정력이 떨어짐 → 임베딩으로 축소 후 검정
enc = UAE(shape=(X_ref.shape[1],), enc_dim=32)               # 개념 예시(버전별 시그니처 상이)
preprocess_fn = partial(preprocess_drift, model=enc, batch_size=256)

cd = MMDDrift(X_ref, backend='tensorflow', p_val=0.05,
              preprocess_fn=preprocess_fn, n_permutations=100)
preds = cd.predict(X_new)
print(preds['data']['is_drift'], preds['data']['p_val'], preds['data']['distance'])
# 팁: 탐지 모델의 은닉층 출력을 preprocess로 쓰면 "모델이 보는 표현" 기준 드리프트를 본다

5. 실전 ③ 온라인 드리프트 (스트리밍)

배치가 아니라 패킷/이벤트가 실시간으로 흘러드는 환경에서는 온라인 detector를 씁니다. 핵심 파라미터는 ERT(Expected Run-Time) — "드리프트가 없을 때 평균 몇 스텝마다 한 번 오탐하는가"로, 값이 클수록 오탐이 드뭅니다.

from alibi_detect.cd import MMDDriftOnline

ert = 150            # 평균 150 스텝마다 1회 오탐 허용(클수록 보수적)
window_size = 20     # 최근 관측 윈도우
cd = MMDDriftOnline(X_ref, ert=ert, window_size=window_size,
                    backend='pytorch', n_bootstraps=2500)

for x_t in traffic_stream:              # 실시간 이벤트 한 건씩
    pred = cd.predict(x_t)
    if pred['data']['is_drift']:
        alert("트래픽 분포 드리프트 감지 → 모델 재학습/재검증 필요")
        cd.reset_state()                # 감지 후 상태 초기화(재모니터링)

6. 실전 ④ 적대적 탐지 (회피 공격)

공격자는 탐지 모델을 속이도록 입력을 미세 조작(adversarial example)해 회피를 시도합니다. AdversarialAE는 오토인코더로 "분류기가 같은 판단을 유지하도록" 학습해 두고, 입력이 적대적으로 조작되면 그 적대적 점수(adversarial score)가 커지는 것을 이용해 탐지합니다.

import tensorflow as tf
from tensorflow.keras.layers import Dense, InputLayer
from alibi_detect.ad import AdversarialAE

# clf: 이미 학습된 분류기(예: 악성코드/트래픽 분류 모델). 그대로 재사용.
n_features = X_train.shape[1]
encoder_net = tf.keras.Sequential([InputLayer((n_features,)), Dense(40, activation='relu'), Dense(20, activation='relu')])
decoder_net = tf.keras.Sequential([InputLayer((20,)), Dense(40, activation='relu'), Dense(n_features, activation=None)])

ad = AdversarialAE(encoder_net=encoder_net, decoder_net=decoder_net, model=clf)
ad.fit(X_train, epochs=40, batch_size=64)          # 정상 데이터로 학습
ad.infer_threshold(X_train, threshold_perc=99)     # 정상의 99%는 정상으로

preds = ad.predict(X_test, return_instance_score=True)
print("적대적 입력:", preds['data']['is_adversarial'])   # 0/1
print("적대적 점수:", preds['data']['instance_score'])

7. 저장·로드·운영 · 백엔드

from alibi_detect.saving import save_detector, load_detector

save_detector(cd, 'detectors/nids_drift')          # 학습·보정된 detector 저장
cd = load_detector('detectors/nids_drift')          # 장비/서비스에서 로드해 바로 사용

# 백엔드 선택: 일부 detector(MMDDrift 등)는 TensorFlow / PyTorch 모두 지원
# MMDDrift(X_ref, backend='pytorch')  또는  backend='tensorflow'

8. 보안 파이프라인 통합

Alibi Detect는 탐지 모델(방화벽/IDS/NAC의 ML 엔진) 옆에서 3중 감시를 담당합니다 — 이상치(zero-day) · 드리프트(모델 노후) · 적대적(회피). "XAI" 문서의 통합 아키텍처를 이렇게 확장합니다.

9. 실무 튜닝과 함정

10. Detector 선택 가이드

11. 용어 설명

Alibi Detect

SeldonIO의 오픈소스 라이브러리. 이상치·드리프트·적대적 입력 탐지를 제공하며 TensorFlow·PyTorch 백엔드를 지원.

이상치 탐지 (Outlier Detection)

정상 분포에서 벗어난 샘플을 찾는 것. 라벨 없이 가능해 zero-day 탐지에 유리.

드리프트 (Drift) / 개념 표류 (Concept Drift)

시간이 지나며 데이터(또는 입력-출력 관계) 분포가 변하는 현상. 배포된 모델을 낡게 만든다.

적대적 입력 (Adversarial Example)

모델의 판단을 속이도록 미세하게 조작한 입력. 보안에선 탐지 회피(evasion)에 악용된다.

infer_threshold

정상 데이터로 "정상의 몇 %를 정상으로 볼지(threshold_perc)"를 정해 이상 판정 경계를 자동 보정하는 함수.

p_val (유의수준)

드리프트 통계 검정에서, 계산된 p-value가 이 값보다 작으면 "분포가 유의하게 달라졌다=드리프트"로 판정.

KS / Chi-Square / MMD

Kolmogorov-Smirnov(연속형 분포 검정), Chi-Square(범주형), Maximum Mean Discrepancy(커널 기반 고차원 분포 차이).

ERT (Expected Run-Time)

온라인 드리프트에서 "드리프트가 없을 때 평균 몇 스텝마다 오탐하는가". 클수록 보수적(오탐↓).

UAE (Untrained AutoEncoder)

학습하지 않은 오토인코더로 만든 임베딩. 고차원 드리프트 검정 전 차원축소 전처리에 쓰인다.

reference data (참조 데이터)

드리프트 판단의 기준이 되는 배포 시점 분포, 또는 이상치 학습의 정상 데이터.

instance_score

샘플별 이상/적대적 점수. 임계값과 비교해 0/1 판정을 만든다.

12. 참고 자료(Sources)

• Alibi Detect (GitHub): github.com/SeldonIO/alibi-detect
• Alibi Detect 문서 — Getting Started: docs.seldon.io
• Drift 예제(TabularDrift): tabulardrift
• Outlier 예제(Mahalanobis/IForest): iforest.ipynb
• PyPI: pypi.org/project/alibi-detect

본 문서는 학습·방어(defensive) 목적의 실전 코드 정리입니다. 코드의 클래스·인자 시그니처는 Alibi Detect 버전에 따라 달라질 수 있으니 공식 문서/저장소의 해당 버전 예제를 확인하세요. 일부 코드는 개념 예시입니다.

Ubuntu 24.04 지키며 재파티션 → Ubuntu 26.04 듀얼부팅 설치 완전 가이드

이미 Ubuntu 24.04가 설치된 노트북의 SSD를 재파티션해 여유 공간을 만들고, 그 공간에 Ubuntu 26.04를 24.04를 손상시키지 않고 설치하는 전체 과정을 그림과 함께 정리합니다. 핵심은 "실행 중인 파티션은 줄이지 않는다", "EFI 파티션은 재사용하되 포맷하지 않는다", "나중에 설치하는 26.04의 부트로더가 전체 부팅을 통제한다" 세 가지입니다.

1. 3가지 핵심 안전 원칙

2. 전체 작업 흐름 한눈에

3. 1단계 — 현재 상태 파악 (24.04에서 실행)

# UEFI인지 Legacy BIOS인지 (요즘 노트북은 대부분 UEFI)
[ -d /sys/firmware/efi ] && echo "UEFI" || echo "BIOS"

# 디스크·파티션·파일시스템 확인
lsblk -f
sudo parted -l
df -h

# LVM / 암호화(LUKS) 사용 여부 (중요!)
lsblk | grep -Ei "lvm|crypt"

확인 포인트:

• UEFI/BIOS 여부와 ESP 위치(보통 /boot/efi, FAT32, 512MB~1GB, esp/boot 플래그).
• 루트(/) 파티션의 파일시스템(대개 ext4)과 현재 사용량.
• LVM 또는 LUKS 사용 여부 — 쓰고 있으면 축소 절차가 다릅니다(아래 "특수 상황"). 기본 설치면 보통 단순 ext4입니다.

4. 2단계 — 목표 파티션 레이아웃 (Before/After)

• 26.04용 여유 공간: 최소 40GB, 넉넉히 60~100GB 권장.
• ESP는 두 OS가 공유합니다(새로 만들지 않음).
• swap: 요즘 Ubuntu는 root 안의 swapfile을 쓰므로 별도 swap 파티션이 필요 없습니다.

5. 3단계 — 24.04에서 공간 정리

sudo apt clean
# 축소할 목표 크기보다 실제 사용량이 충분히 작은지 확인
df -h /

루트의 실제 사용량이 "축소 후 크기"보다 작아야 합니다. (예: 사용량 60GB면 그보다 작게는 못 줄임)

6. 4단계 — Ubuntu 26.04 Live USB 제작

• 26.04 LTS ISO를 다른 정상 PC에서 USB로 굽습니다.
  • Windows: Rufus / balenaEtcher
  • Linux: Startup Disk Creator(디스크 만들기) 또는 아래 명령

# ⚠ of= 대상(USB 장치명)을 반드시 정확히 확인! 잘못하면 다른 디스크가 지워짐
sudo dd if=ubuntu-26.04-desktop-amd64.iso of=/dev/sdX bs=4M status=progress oflag=sync

노트북 부팅 메뉴(F12/F2/ESC 등)에서 USB로 부팅 → "Try Ubuntu(체험하기)" 선택.

7. 5단계 — Live USB에서 파티션 축소 (GParted)

# Live 세션 터미널에서
sudo apt install gparted          # 없으면 설치 (라이브에 기본 포함되기도 함)

# 먼저 24.04 root 파일시스템 무결성 검사 (대상 장치명 정확히! 예: nvme0n1p2)
sudo fsck -f /dev/nvme0n1pX

sudo gparted

GParted에서:

1. 24.04 root(ext4) 파티션 선택 → Resize/Move.
2. 오른쪽 끝을 당겨 크기를 줄이고 뒤쪽에 Unallocated(빈 공간)을 만든다. (앞쪽은 건드리지 말 것)
3. ESP·다른 파티션은 그대로 둔다.
4. ✔ Apply → 완료까지 전원 유지.

8. 6단계 — Ubuntu 26.04 설치 (ESP 재사용)

Live 데스크톱의 Install Ubuntu 26.04 실행. 설치 유형 화면에서 두 갈래가 있습니다.

방법 A — 자동 ("Ubuntu 24.04와 함께 설치 / Install alongside")

설치기가 빈 공간에 자동으로 26.04를 설치하고 ESP를 공유합니다. 가장 간단합니다.

방법 B — 수동 ("Manual / 이전의 Something else") — 권장

1. 앞서 만든 빈 공간(free space) 선택 → ＋ → 새 파티션: ext4, 마운트 지점 /.
2. 기존 ESP(예 /dev/nvme0n1p1, FAT32) 선택 → "EFI System Partition"으로 지정. ⚠ "포맷" 체크는 절대 금지 (마운트 /boot/efi).
3. 부트로더 설치 위치: ESP가 있는 디스크 전체(예 /dev/nvme0n1)로 지정.
4. 계정 만들고 설치 진행.

9. 7단계 — 부팅 메뉴(GRUB) 정리

재부팅 시 GRUB 메뉴에 26.04와 24.04가 모두 보여야 합니다. 만약 24.04가 안 보이면, 26.04로 부팅한 뒤:

# os-prober가 다른 OS를 찾도록 활성화
sudo os-prober                                  # 24.04가 감지되는지 확인
echo 'GRUB_DISABLE_OS_PROBER=false' | sudo tee -a /etc/default/grub
sudo update-grub                                # GRUB 메뉴 재생성 → 24.04 항목 추가

# UEFI 부팅 항목 확인
efibootmgr -v

10. 8단계 — 검증과 기본 부팅 OS 설정

• 재부팅 → GRUB에서 26.04와 24.04를 번갈아 부팅해 둘 다 정상인지 확인.
• 기본 부팅 OS·대기시간 변경(26.04에서):

sudo nano /etc/default/grub
#   GRUB_DEFAULT=0        # 0=첫 항목, 또는 "saved"로 마지막 선택 기억
#   GRUB_TIMEOUT=10
sudo update-grub

11. 특수 상황 — LVM · LUKS · /home 공유

12. 체크리스트 · 용어 설명

파티션 (Partition)

디스크를 논리적으로 나눈 구획. 각 OS·파일시스템이 자기 파티션을 갖는다.

ESP (EFI System Partition)

UEFI 부팅에 필요한 부트로더가 담긴 FAT32 파티션(보통 /boot/efi). 여러 OS가 공유하며, 재파티션 시 포맷하면 안 된다.

UEFI / Legacy BIOS

펌웨어 부팅 방식. 요즘 노트북은 대부분 UEFI. /sys/firmware/efi 존재 여부로 확인.

GRUB

리눅스 부트로더. 부팅 시 어떤 OS·커널로 부팅할지 메뉴를 제공한다. 나중에 설치한 OS의 GRUB이 통제한다.

os-prober

다른 파티션의 운영체제를 탐지해 GRUB 메뉴에 추가하는 도구. 최신 GRUB은 기본 비활성이라 필요 시 켠다.

GParted

그래픽 파티션 편집기. Live USB에서 마운트 해제된 파티션을 안전하게 축소·이동한다.

fsck

파일시스템 무결성 검사·복구 도구. 축소 전 실행해 안정성을 높인다.

ext4

Ubuntu 기본 파일시스템. 축소·확장이 지원된다.

swapfile / swap

메모리 부족 시 사용하는 디스크 영역. 요즘 Ubuntu는 root 안의 파일(swapfile)을 써서 별도 파티션이 불필요.

LVM / LUKS

논리 볼륨 관리(LVM)와 디스크 암호화(LUKS). 사용 중이면 파티션 축소 절차가 더 복잡하다.

본 문서는 학습용 안내입니다. 파티션 작업은 데이터 손실 위험이 있으므로 반드시 백업 후, 본인 디스크의 실제 장치명·레이아웃을 확인하고 진행하세요. 장치명(/dev/...)을 잘못 지정하면 다른 디스크가 지워질 수 있습니다.

Ubuntu 24.04 지키며 재파티션 → Windows 10 듀얼부팅 설치 (GRUB 복구까지)

이미 Ubuntu 24.04가 설치된 노트북에 SSD를 재파티션해 Windows 10을 함께 설치하는 방법입니다. 이 경우 앞의 "Ubuntu + Ubuntu"와 결정적으로 다른 점이 하나 있습니다 — Windows는 설치되면서 부팅 순서를 자기 것으로 덮어써 GRUB(리눅스 부팅 메뉴)을 밀어냅니다. 그래서 "Windows 설치 → GRUB 복구"가 반드시 한 세트로 진행되어야 합니다.

1. 핵심 차이 — "Windows가 GRUB을 덮어쓴다"

리눅스의 정석은 "Windows 먼저, 리눅스 나중"입니다. 그러면 리눅스 GRUB이 Windows를 메뉴에 넣어 주기 때문입니다. 그런데 지금은 반대 순서(Ubuntu 먼저, Windows 나중)입니다. Windows 설치기는 자기 부트로더를 UEFI 부팅 1순위로 등록하고 GRUB을 밀어내므로, 설치 직후엔 Ubuntu가 안 보이고 Windows로만 부팅됩니다. 이건 고장이 아니라 예상된 현상이며, 6단계 GRUB 복구로 되살립니다.

2. 전체 작업 흐름

3. 1단계 — 현재 상태 파악 (Ubuntu 24.04에서)

# UEFI 여부 (Windows도 같은 방식으로 설치해야 부팅 호환)
[ -d /sys/firmware/efi ] && echo "UEFI" || echo "BIOS"

lsblk -f            # 파티션·파일시스템·ESP 위치
sudo parted -l
df -h /             # Ubuntu root 사용량

4. 2단계 — 목표 레이아웃 (Before/After)

• Windows용 공간: 최소 64GB, 넉넉히 100GB+ 권장(업데이트·앱 여유).
• ESP는 공유 — Windows는 기존 ESP 안에 자기 부트 파일(Microsoft 폴더)을 넣습니다. ESP를 지우거나 포맷하지 마세요.
• Windows는 설치 중 MSR·복구 파티션을 자동 생성하므로, 빈 공간은 unallocated(미할당)로 남겨두면 됩니다.

5. 3단계 — Live USB에서 Ubuntu 축소 (빈 공간 만들기)

Ubuntu(ext4)는 Windows에서 줄일 수 없으므로, 먼저 Ubuntu 24.04 Live USB(또는 아무 Ubuntu Live)로 부팅해 GParted로 Ubuntu root를 줄여 빈 공간을 만듭니다. (실행 중인 root는 못 줄이므로 Live USB 필수 — 앞 문서와 동일 원리)

# Live 세션에서
sudo apt install gparted
sudo fsck -f /dev/nvme0n1pX     # Ubuntu root 무결성 검사(장치명 정확히!)
sudo gparted
# → Ubuntu root(ext4) 선택 → Resize/Move → 오른쪽(뒤)만 당겨 축소 → 빈 공간 생성 → Apply

6. 4단계 — Windows 10 설치 USB 제작

• 다른 Windows PC에서 Rufus로 Windows 10 ISO를 USB에 굽습니다.
  • 파티션 구성: GPT, 대상 시스템: UEFI(비 CSM) — Ubuntu가 UEFI이므로 반드시 일치.
  • ISO는 Microsoft "미디어 생성 도구" 또는 공식 ISO 사용.

7. 5단계 — Windows 10 설치 (파티션 선택이 가장 중요)

1. Windows USB로 부팅 → 언어 선택 → "지금 설치" → 제품 키(없으면 "제품 키가 없음").
2. 설치 유형에서 "사용자 지정(Custom): Windows만 설치" 선택. (업그레이드 아님)
3. 파티션 화면에서 앞서 만든 미할당 공간(Unallocated)을 선택 → "다음" (또는 "새로 만들기"로 크기 지정).
4. ⚠ 절대 금지: 기존 ESP(작은 FAT 파티션)·Ubuntu 파티션을 삭제·포맷하지 말 것.
5. 설치 진행 → 재부팅. 이 시점엔 Windows로만 부팅됩니다(정상). → 6단계로.

8. 6단계 — GRUB 복구 (이 시나리오의 핵심!)

Windows 설치로 밀려난 GRUB을 되살립니다. Ubuntu Live USB로 부팅("Try Ubuntu")한 뒤 두 방법 중 하나를 씁니다.

방법 A — Boot-Repair (가장 쉬움, 권장)

# Ubuntu Live USB(Try Ubuntu)에서, 인터넷 연결 후
sudo add-apt-repository ppa:yannubuntu/boot-repair
sudo apt update
sudo apt install -y boot-repair
boot-repair
# → 창에서 "Recommended repair" 클릭 → 안내 따라 진행 → 재부팅

방법 B — 수동 chroot로 GRUB 재설치 (Boot-Repair가 안 될 때)

# 장치명은 본인 것으로! (예: root=nvme0n1p2, ESP=nvme0n1p1)
sudo mount /dev/nvme0n1p2 /mnt
sudo mount /dev/nvme0n1p1 /mnt/boot/efi
for d in dev proc sys run; do sudo mount --bind /$d /mnt/$d; done
sudo chroot /mnt

# (chroot 안에서)
grub-install /dev/nvme0n1        # 디스크 전체 지정
update-grub                      # Windows 감지해 메뉴에 추가
exit

# 정리
for d in run sys proc dev; do sudo umount /mnt/$d; done
sudo umount /mnt/boot/efi && sudo umount /mnt

9. 7단계 — 검증 · Fast Startup · 시간 문제

• 부팅 검증: 재부팅 → GRUB 메뉴에서 Ubuntu와 Windows 둘 다 부팅되는지 확인.
• Windows 빠른 시작(Fast Startup) 끄기: Windows의 빠른 시작은 디스크를 "잠근(hibernate)" 상태로 종료해, 듀얼부팅에서 NTFS 접근·부팅 문제를 일으킬 수 있습니다. 제어판 → 전원 옵션 → 전원 단추 동작 → "빠른 시작 켜기" 체크 해제.
• 시간(시계) 어긋남 해결: Windows는 기본적으로 하드웨어 시계를 지역 시간(localtime)으로, Ubuntu는 UTC로 봅니다. 그대로 두면 OS 전환 시 시간이 틀어집니다. Ubuntu에서 아래로 맞추면 편합니다.

# Ubuntu에서: 하드웨어 시계를 localtime으로(=Windows와 동일 기준)
timedatectl set-local-rtc 1 --adjust-system-clock
# (대안: Windows 레지스트리에서 RealTimeIsUniversal=1로 UTC 사용하게 하는 방법도 있음)

10. 실패 시 대처 · 체크리스트

11. 용어 설명

부트로더 (Bootloader)

전원이 켜진 뒤 어떤 OS를 부팅할지 담당하는 프로그램. 리눅스는 GRUB, Windows는 Windows Boot Manager.

GRUB

리눅스 부트로더 겸 부팅 메뉴. Windows를 나중에 설치하면 밀려나므로 복구가 필요하다.

ESP (EFI System Partition)

UEFI 부팅 파일이 담긴 FAT32 파티션. Ubuntu와 Windows가 공유하며, 삭제·포맷하면 안 된다.

UEFI / GPT

현대 펌웨어 부팅 방식(UEFI)과 파티션 테이블(GPT). 두 OS를 같은 방식(UEFI+GPT)으로 맞춰야 공존한다.

MSR (Microsoft Reserved Partition)

Windows가 관리용으로 만드는 작은 예약 파티션. 설치기가 자동 생성한다.

NTFS

Windows 기본 파일시스템. Windows는 자기 파티션을 NTFS로 만든다.

Boot-Repair

GRUB·부팅 문제를 자동 진단·복구해 주는 도구. Live USB에서 실행한다.

chroot

Live 환경에서 설치된 시스템으로 "들어가" 명령을 실행하는 방법. 수동 GRUB 재설치에 쓴다.

os-prober

다른 OS(여기선 Windows)를 탐지해 GRUB 메뉴에 추가하는 도구.

efibootmgr

UEFI 부팅 항목·순서를 조회·변경하는 도구. ubuntu를 1순위로 만들 때 사용.

Fast Startup (빠른 시작)

Windows의 하이브리드 종료 기능. 디스크를 잠근 채 꺼서 듀얼부팅에서 문제를 유발 → 끄는 것을 권장.

RTC / localtime / UTC

하드웨어 시계(RTC) 기준. Windows는 localtime, 리눅스는 UTC를 기본 사용해 시간이 어긋날 수 있다.

본 문서는 학습용 안내입니다. 파티션·부트로더 작업은 데이터 손실 위험이 있으니 반드시 백업 후 본인 디스크의 실제 장치명을 확인하고 진행하세요. Windows 10은 지원 종료 상태이므로 보안상 Windows 11 또는 최신 OS 사용을 함께 검토하시길 권합니다.

Ubuntu 24.04(i5-7200U)에 VirtualBox 설치 → Windows 11 가상머신 만들기

Intel Core i5-7200U가 장착된 Ubuntu 24.04 노트북에 VirtualBox를 설치하고 그 위에 Windows 11을 가상머신(VM)으로 올리는 전체 과정입니다. 이 CPU는 7세대(Kaby Lake, 2016)라 Windows 11의 공식 CPU 요구사항(8세대 이상)을 만족하지 못합니다. 다행히 TPM 2.0·Secure Boot는 VirtualBox 7이 가상으로 제공하고, CPU 검사만 설치 중 우회하면 됩니다. 이 문서는 그 방법까지 포함합니다.

1. 전체 작업 흐름

2. 하드웨어 궁합 점검 (VT-x·TPM·CPU)

3. 1단계 — VT-x(가상화) 활성화 확인

먼저 BIOS/UEFI에서 Intel Virtualization Technology(VT-x)가 켜져 있어야 합니다. Ubuntu에서 확인:

# 값이 0보다 크면 CPU가 가상화를 지원 (vmx=Intel)
egrep -c '(vmx|svm)' /proc/cpuinfo

# 더 친절한 확인 도구
sudo apt install -y cpu-checker
kvm-ok        # "KVM acceleration can be used" 나오면 OK

lscpu | grep -i virtual   # Virtualization: VT-x 표시 확인

4. 2단계 — VirtualBox 설치 (두 가지 방법)

방법 A — Ubuntu 저장소 (가장 간단)

sudo apt update
sudo apt install -y virtualbox virtualbox-ext-pack
# 설치 후 버전 확인 (Windows 11엔 7.x 권장)
vboxmanage --version

방법 B — Oracle 공식 저장소 (최신 7.x, 권장)

sudo apt update && sudo apt install -y wget gpg

# Oracle 서명키 등록
wget -O- https://www.virtualbox.org/download/oracle_vbox_2016.asc \
  | sudo gpg --dearmor --yes -o /usr/share/keyrings/oracle-virtualbox-2016.gpg

# 저장소 추가 (Ubuntu 24.04 코드명 = noble)
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/oracle-virtualbox-2016.gpg] \
https://download.virtualbox.org/virtualbox/debian noble contrib" \
  | sudo tee /etc/apt/sources.list.d/virtualbox.list

sudo apt update
sudo apt install -y virtualbox-7.1        # (또는 virtualbox-7.0)

# USB 등 사용 위해 그룹 추가 후 재로그인
sudo usermod -aG vboxusers $USER

5. 3단계 — Windows 11 ISO 준비

• Microsoft 공식 사이트에서 Windows 11 디스크 이미지(ISO)를 내려받습니다(64-bit).
• 다운로드한 .iso 파일 경로를 기억해 둡니다(4단계에서 지정).

6. 4단계 — VM 생성 (EFI · TPM 2.0 · Secure Boot)

VirtualBox를 실행하고 "새로 만들기(New)"로 VM을 만듭니다. Windows 11이 요구하는 TPM·Secure Boot를 여기서 켭니다.

1. 새로 만들기 → 이름 입력, ISO 이미지에 내려받은 Win11 ISO 지정.
   • "Skip Unattended Installation(무인 설치 건너뛰기)"을 체크하면 설치 화면을 직접 제어할 수 있어 우회가 쉽습니다.
2. 종류 Windows 11 (64-bit), RAM 4096MB, CPU 2, 디스크 64GB↑.
3. 생성 후 설정 → 시스템 → 마더보드: EFI 사용 체크, TPM 2.0 선택.
4. 설정 → 시스템 → (Secure Boot): Secure Boot 사용 체크.
5. 디스플레이 비디오 메모리 128MB, 필요 시 3D 가속(성능 여유 없으면 생략).

7. 5단계 — Windows 11 설치 + CPU 검사 우회 (핵심)

VM을 시작해 ISO로 부팅합니다. TPM·Secure Boot는 켰지만 7세대 CPU라 "이 PC는 Windows 11을 실행할 수 없습니다"가 뜰 수 있습니다. 이때 레지스트리로 CPU(및 잔여) 검사를 우회합니다.

1. 설치 도중 "이 PC는 Windows 11을 실행할 수 없습니다"가 뜨면 그 화면에서 Shift + F10 → 명령 프롬프트.
2. regedit 입력 → 레지스트리 편집기.
3. HKEY_LOCAL_MACHINE\SYSTEM\Setup에서 Setup 우클릭 → 새로 만들기 → 키 → 이름 LabConfig.
4. LabConfig 안에 DWORD(32비트) 값들을 만들고 값을 1로:
   • BypassCPUCheck = 1 ← 7세대 CPU 핵심
   • BypassTPMCheck = 1
   • BypassSecureBootCheck = 1
   • BypassRAMCheck = 1
5. regedit·명령창 닫기 → 설치 화면에서 뒤로 갔다가 다시 진행 → 이제 통과됩니다.
6. 이후는 일반 Windows 11 설치와 동일(에디션·디스크 선택 → 설치 → 계정 설정).

8. 6단계 — Guest Additions 설치 (화면·성능·클립보드)

설치 후 화면 크기 자동 조절, 마우스 통합, 클립보드 공유, 성능 향상을 위해 Guest Additions를 설치합니다.

1. Windows 11 VM이 켜진 상태에서 상단 메뉴 장치(Devices) → "Guest Additions CD 이미지 삽입".
2. Windows 탐색기에서 CD 드라이브 → VBoxWindowsAdditions.exe 실행 → 설치 → 재부팅.
3. 이후 보기 → 자동 크기 조정, 양방향 클립보드(장치 → 클립보드 공유 → 양방향) 사용 가능.

9. 성능 최적화 · 문제 해결

10. 용어 설명

VirtualBox

Oracle의 무료 오픈소스 가상화 소프트웨어. 호스트 OS 위에서 다른 OS를 가상머신(VM)으로 실행한다.

VM (Virtual Machine, 가상머신)

소프트웨어로 만든 가상의 컴퓨터. 여기서는 Ubuntu(호스트) 위에 Windows 11(게스트)을 올린다.

호스트 / 게스트 (Host / Guest)

가상화를 실행하는 실제 OS(호스트=Ubuntu)와, 그 안에서 도는 OS(게스트=Windows 11).

VT-x

인텔의 하드웨어 가상화 기술. BIOS에서 켜야 VM이 원활히·64비트로 동작한다. i5-7200U는 지원.

TPM 2.0 (Trusted Platform Module)

보안 키·측정값을 저장하는 하드웨어 모듈. Windows 11 요구사항으로, VirtualBox 7이 가상으로 제공한다.

Secure Boot

서명된 부트로더만 실행하는 UEFI 보안 기능. Windows 11 요구사항이며 VM 설정에서 켠다.

EFI / UEFI

현대 펌웨어 부팅 방식. Windows 11 VM은 EFI로 부팅해야 한다(VM 설정에서 "EFI 사용").

LabConfig / Bypass 키

Windows 설치 중 레지스트리에서 CPU·TPM·Secure Boot·RAM 요구사항 검사를 건너뛰게 하는 값들.

Guest Additions

게스트에 설치하는 드라이버·도구 묶음. 화면 자동조절·클립보드 공유·성능 향상을 제공한다.

Extension Pack

USB 2.0/3.0, RDP 등 추가 기능 팩. (개인·평가용 라이선스 조건 확인)

MOK (Machine Owner Key)

호스트 Secure Boot가 켜졌을 때 커널 모듈(vboxdrv) 서명을 등록하는 절차.

본 문서는 학습용 안내입니다. i5-7200U는 Windows 11 공식 미지원 CPU이므로 우회 설치는 테스트·학습 목적으로 권장되며, 공식 지원·보안 업데이트 보장이 제한될 수 있습니다. Windows는 정품 라이선스 사용을 권장합니다. 명령·메뉴 명칭은 VirtualBox 버전에 따라 다를 수 있습니다.

GPO와 MDM 완전 정리 — 조직의 단말을 어떻게 통제하는가

회사가 수백~수천 대의 PC와 스마트폰에 일관된 보안 설정·소프트웨어·인증서를 배포하려면 어떻게 할까요? 전통적으로는 Windows의 GPO(Group Policy Object, 그룹 정책 개체)가, 모바일과 클라우드 시대에는 MDM(Mobile Device Management, 모바일 단말 관리)가 그 역할을 합니다. 이 문서는 두 기술의 개념·아키텍처·동작·차이, 그리고 현대적 통합 흐름(UEM·Intune)까지 그림과 함께 자세히 정리합니다.

1. 엔드포인트 관리 — 큰 그림

조직이 늘어나는 단말(PC·노트북·스마트폰·태블릿)을 중앙에서 일관되게 통제·보호하는 활동을 엔드포인트 관리(Endpoint Management)라 합니다. 목표는 보안 설정 강제, 소프트웨어·업데이트 배포, 인증서·Wi-Fi·VPN 프로파일 배포, 분실 시 원격 잠금·삭제 등입니다.

2. GPO란 무엇인가

GPO(Group Policy Object)는 Microsoft Active Directory(AD) 환경에서 사용자와 컴퓨터의 설정을 중앙에서 정의·강제하는 "정책 묶음"입니다. Windows 2000부터 도입된 그룹 정책(Group Policy)의 핵심 단위로, 하나의 GPO 안에는 수백~수천 개의 설정(암호 정책, 화면 잠금, 방화벽, 소프트웨어 설치, 로그온 스크립트, 인증서 배포 등)을 담을 수 있습니다.

GPO는 AD의 사이트(Site)·도메인(Domain)·조직 단위(OU, Organizational Unit)에 연결(link)되어, 그 범위 안의 컴퓨터·사용자에게 적용됩니다.

3. GPO 아키텍처 — AD · GPC · GPT(SYSVOL)

하나의 GPO는 물리적으로 두 부분으로 나뉘어 저장됩니다.

• GPC(Group Policy Container) — AD 데이터베이스에 저장되는 부분. GPO의 속성·버전·상태 등 메타데이터.
• GPT(Group Policy Template) — 도메인 컨트롤러의 공유 폴더 SYSVOL에 저장되는 실제 설정 파일들(스크립트, 관리 템플릿 값 등). 경로는 \\도메인\SYSVOL\...\Policies\{GUID}.

4. GPO 적용 순서 — LSDOU와 상속

한 컴퓨터·사용자에 여러 GPO가 겹칠 수 있습니다. 이때 적용 순서는 LSDOU입니다 — Local(로컬) → Site(사이트) → Domain(도메인) → OU(조직 단위, 상위→하위). 나중에 적용되는 것이 앞의 것을 덮어씁니다. 따라서 대상에 가장 가까운 하위 OU의 GPO가 최종 우선권을 갖습니다.

5. GPO 구성과 관리 도구

모든 GPO는 크게 두 갈래로 나뉩니다.

• Computer Configuration(컴퓨터 구성) — 컴퓨터에 적용(부팅 시). 예: 방화벽, 서비스, 보안 옵션, 신뢰할 수 있는 루트 인증서.
• User Configuration(사용자 구성) — 사용자에 적용(로그온 시). 예: 바탕화면, 드라이브 매핑, 앱 제한.

그 아래 Administrative Templates(관리 템플릿)가 대표적인데, ADMX/ADML 파일로 정의되며 실제로는 레지스트리 값을 제어합니다. 조직 공통 템플릿은 SYSVOL의 Central Store에 둡니다.

# 정책 즉시 적용 및 결과 확인
gpupdate /force
gpresult /r                       # 적용된 GPO 요약
gpresult /h C:\gpreport.html      # HTML 상세 리포트

# PowerShell로 GPO 만들고 OU에 연결하기 (개념 예시)
New-GPO -Name "보안-화면잠금" -Comment "10분 후 화면 잠금"
New-GPLink -Name "보안-화면잠금" -Target "OU=사무직,DC=corp,DC=example,DC=com"

6. MDM이란 무엇인가 — 태동 배경

MDM(Mobile Device Management)은 스마트폰·태블릿, 그리고 이제는 PC까지 포함한 단말을 인터넷을 통해 원격으로 등록·설정·통제·보호하는 기술입니다. GPO가 "사내망의 Windows"에 최적화됐다면, MDM은 다음 변화에 대응하기 위해 등장했습니다.

• 스마트폰·태블릿의 폭증 — iOS·안드로이드는 AD 도메인에 가입하지 않는다.
• BYOD(Bring Your Own Device) — 개인 기기로 업무를 보는 흐름.
• 원격·재택근무 — 사내망 밖의 단말을 통제해야 함(GPO의 사내망 전제가 깨짐).
• 크로스 플랫폼 — Windows·mac·iOS·안드로이드를 한 콘솔에서.

7. MDM 아키텍처 — 서버 · Push · 프로파일

MDM은 OS 제조사가 만든 관리 프레임워크 위에서 동작합니다. 핵심은 MDM 서버가 단말에게 "프로파일(정책)"을 밀어(push) 넣는 것인데, 직접 연결하는 대신 OS별 푸시 알림 서비스로 "서버에 접속하라"는 신호를 보내는 구조입니다.

• Apple(iOS·macOS) — APNs(Apple Push Notification service)로 깨우고, 단말이 MDM 서버에 접속해 명령을 받음. Apple MDM 프로토콜 사용.
• 안드로이드 — Android Enterprise + FCM(Firebase Cloud Messaging) 푸시.
• Windows — OMA-DM 표준 프로토콜 + WNS(Windows Notification Service) 푸시.

8. MDM 등록(Enrollment)과 정책 배포 절차

MDM은 단말이 등록(Enrollment)되어야 통제가 시작됩니다. 절차는 대략 다음과 같습니다.

<!-- Apple 구성 프로파일(.mobileconfig)의 개념적 구조 (XML) -->
<plist version="1.0">
 <dict>
   <key>PayloadType</key>      <string>com.apple.wifi.managed</string>
   <key>PayloadDisplayName</key> <string>회사 Wi-Fi</string>
   <key>SSID_STR</key>         <string>CORP-WIFI</string>
   <key>EncryptionType</key>   <string>WPA2</string>
 </dict>
</plist>
<!-- MDM 서버가 이런 프로파일을 단말에 push → 사용자가 손대지 않아도 Wi-Fi가 설정됨 -->

9. MDM을 둘러싼 개념 — EMM · UEM · MAM · MCM

MDM은 더 큰 관리 개념의 일부로 발전했습니다. 용어가 헷갈리기 쉬워 관계를 정리합니다.

10. GPO vs MDM 비교

11. 현대적 흐름 — 클라우드 · Intune · Co-management

많은 조직이 온프레미스 AD/GPO에서 클라우드 기반 MDM으로 이동하고 있습니다. 마이크로소프트 진영에서는 Entra ID(구 Azure AD) + Intune 조합이 대표적입니다. 단말을 클라우드에 조인·등록하면, 사내망 없이도 정책·앱·인증서를 배포할 수 있습니다.

• Co-management(공동 관리) — 기존 ConfigMgr(SCCM)와 Intune을 함께 써 점진적으로 전환.
• GPO → MDM 전환 지원 — Intune의 Group Policy Analytics가 기존 GPO를 분석해 대응하는 MDM 설정으로 매핑해 주고, Settings Catalog·Administrative Templates로 유사한 설정을 클라우드에서 제공.
• 조건부 접근(Conditional Access) — "규정을 준수한(compliant) 단말만 사내 리소스 접근 허용" 같은 정책과 결합.

12. 실무 시나리오 — 인증서 · Wi-Fi · 앱 배포

① 내부 CA 인증서 배포 (SSL 가시화 연계)

"SSL 가시화" 문서에서 본 것처럼, 복호화 장비의 내부 Root CA 인증서를 모든 단말이 신뢰하게 하려면 GPO 또는 MDM으로 배포합니다.

• GPO: Computer Configuration → Windows Settings → Security Settings → Public Key Policies → Trusted Root Certification Authorities에 CA 인증서를 추가하면 도메인 PC 전체가 자동 신뢰.
• MDM: "인증서 프로파일(Trusted Certificate)"로 iOS·안드로이드·Windows·mac에 동시에 배포.

② Wi-Fi / VPN 프로파일

사용자가 손대지 않아도 회사 Wi-Fi·VPN이 자동 설정되도록 프로파일을 배포합니다(그림 5의 .mobileconfig 예시).

③ 앱 배포·제한

필수 업무 앱을 자동 설치하고, 금지 앱을 차단합니다. MDM은 앱 스토어(사내 카탈로그)와 연동해 원격 설치·제거가 가능합니다.

④ 보안 기준 강제·컴플라이언스

암호 복잡도, 화면 잠금, 디스크 암호화(BitLocker·FileVault), 최신 OS 버전 등을 강제하고, 미준수 단말은 사내 리소스 접근을 차단(조건부 접근)합니다.

13. 시장과 선도 기업

전체 흐름은 "단순 MDM → 통합 UEM", 그리고 "온프레미스 GPO → 클라우드 관리"로 수렴하고 있습니다. 제로 트러스트(Zero Trust)와 조건부 접근이 결합되며, 단말 관리가 곧 보안의 최전선이 되었습니다.

14. 용어 설명

GPO (Group Policy Object, 그룹 정책 개체)

Active Directory에서 사용자·컴퓨터 설정을 중앙에서 정의·강제하는 정책 묶음.

Active Directory (AD) / 도메인 컨트롤러(DC)

Windows의 디렉터리 서비스와 그 서버. 사용자·컴퓨터·정책을 중앙 관리한다.

OU (Organizational Unit, 조직 단위)

AD 안에서 사용자·컴퓨터를 묶는 컨테이너. GPO를 이 단위에 연결(link)해 적용 범위를 정한다.

GPC / GPT / SYSVOL

GPO의 메타데이터(GPC, AD 저장)와 실제 설정 파일(GPT, SYSVOL 공유 폴더 저장).

LSDOU

GPO 적용 순서: Local → Site → Domain → OU. 나중 것이 앞 것을 덮어쓴다.

Block Inheritance / Enforced

상속 차단(하위가 상위 정책을 안 받음)과 강제(상위 정책을 하위가 못 덮어쓰게 함, 상속 차단도 무시).

Administrative Templates / ADMX

레지스트리 기반 설정을 정의하는 GPO 템플릿과 그 파일 형식(ADMX/ADML).

GPMC / gpupdate / gpresult / RSoP

GPO 관리 콘솔, 즉시 갱신 명령, 적용 결과 확인, 최종 정책 시뮬레이션 도구.

MDM (Mobile Device Management)

단말을 인터넷으로 원격 등록·설정·통제·보호하는 기술. OS 관리 프레임워크 위에서 동작.

Enrollment (등록)

단말을 MDM에 편입시키는 절차. 자동 등록: Apple ADE(구 DEP), Android Zero-Touch, Windows Autopilot.

APNs / FCM / WNS

Apple·안드로이드·Windows의 푸시 알림 서비스. MDM 서버가 단말을 깨워 접속을 유도하는 통로.

OMA-DM

단말 관리 표준 프로토콜. Windows MDM 등에서 사용.

프로파일 (Profile) / .mobileconfig

MDM이 단말에 배포하는 설정 묶음(Wi-Fi·VPN·인증서·제한 등). Apple은 .mobileconfig(XML) 형식.

Remote Wipe / Selective Wipe

원격 데이터 삭제. Selective Wipe는 BYOD에서 회사 데이터만 지우고 개인 데이터는 보존.

EMM / UEM / MAM / MCM

MDM을 확장한 개념들. EMM(모빌리티 전반), UEM(모든 단말 통합), MAM(앱 관리), MCM(콘텐츠 관리).

Co-management (공동 관리)

ConfigMgr(SCCM)와 Intune을 함께 사용해 온프레미스에서 클라우드로 점진 전환하는 방식.

Conditional Access (조건부 접근)

규정을 준수한 단말·사용자만 사내 리소스 접근을 허용하는 정책. 제로 트러스트의 핵심.

본 문서는 학습 목적의 개념·실무 정리입니다. 설정 경로·명령·제품 기능은 OS·제품 버전에 따라 달라질 수 있으니 공식 문서를 확인하세요. "SSL 가시화" 문서의 "내부 CA 배포"가 바로 이 GPO·MDM으로 구현됩니다.

BGP 완전 정복 — 개념부터 장비 설정, 그리고 클라우드(OpenStack · Kubernetes)까지

BGP(Border Gateway Protocol, 경계 경로 프로토콜)는 "인터넷을 하나로 묶는 접착제"입니다. 전 세계 수만 개의 독립 네트워크(AS)가 서로 어떤 IP 대역이 어디에 있는지를 이 프로토콜로 주고받습니다. 그런데 BGP는 이제 통신사 백본을 넘어 데이터센터 내부, 그리고 OpenStack·Kubernetes 같은 클라우드 안까지 깊숙이 들어와 있습니다. 이 문서는 BGP의 개념·동작·경로 선택부터 실무 장비 설정, 그리고 클라우드 활용 사례까지 그림과 함께 아주 자세히 정리합니다.

1. BGP란 무엇인가 — 인터넷의 지도 프로토콜

인터넷은 하나의 거대한 네트워크가 아니라, 독립적으로 운영되는 수만 개의 네트워크(AS, Autonomous System, 자율 시스템)가 서로 연결된 "네트워크들의 네트워크"입니다. 각 AS(통신사, 대기업, 클라우드 사업자 등)는 자신이 보유한 IP 대역을 가지고 있습니다. BGP는 이 AS들 사이에서 "어떤 IP 대역이 어느 경로를 통해 도달 가능한지"를 광고하고 학습하는 프로토콜입니다.

BGP는 경로 벡터(Path Vector) 프로토콜입니다. 단순히 "거리(hop 수)"만 보는 것이 아니라, 목적지까지 거쳐 가는 AS들의 목록(AS_PATH)과 다양한 정책 속성을 함께 전달합니다. 덕분에 루프를 방지하고, 사업자마다 원하는 정책(policy)에 따라 경로를 선택할 수 있습니다.

2. IGP vs EGP — BGP의 자리

라우팅 프로토콜은 크게 두 종류로 나뉩니다. BGP가 어디에 위치하는지 이해하는 것이 중요합니다.

3. 핵심 개념 — AS · eBGP/iBGP · 세션 · 메시지

eBGP와 iBGP

BGP 세션은 두 종류입니다. 어느 AS끼리 맺느냐에 따라 동작이 크게 다릅니다.

• eBGP(external BGP) — 서로 다른 AS 사이의 세션. 보통 물리적으로 직접 연결된 이웃과 맺음(기본 TTL 1).
• iBGP(internal BGP) — 같은 AS 내부의 라우터끼리 맺는 세션. 외부에서 배운 경로를 AS 내부에 전파하는 데 사용.

BGP 세션과 메시지

BGP는 TCP 179번 포트 위에서 동작합니다(신뢰성 있는 전송에 의존). 세션이 맺어지면 4가지 메시지를 주고받습니다.

4. BGP 상태 머신과 세션 수립 절차

BGP 세션은 정해진 상태 머신(Finite State Machine)을 거쳐 Established(수립 완료)에 도달합니다.

5. 경로 속성(Path Attributes)과 Best Path 선정

같은 목적지로 가는 경로가 여러 개일 때, BGP는 경로 속성(Path Attributes)을 순서대로 비교해 단 하나의 최적 경로(Best Path)를 고릅니다. 주요 속성은 다음과 같습니다.

6. 운영 시나리오 ① 멀티홈(Multihoming)과 이중화

기업이 인터넷 회선을 두 개 이상의 ISP에 연결하는 것을 멀티홈(Multihoming)이라 합니다. 목적은 이중화(한 ISP 장애 시 다른 ISP로 자동 전환)와 트래픽 분산입니다. 자체 AS 번호와 독립 IP 대역(PI)을 가지고 두 ISP와 각각 eBGP를 맺습니다.

7. 운영 시나리오 ② 인바운드/아웃바운드 트래픽 제어

멀티홈에서 가장 중요한 실무 기술은 "트래픽이 어느 회선으로 나가고 들어오게 할지" 제어하는 것입니다. 핵심 원리는 다음과 같습니다.

• 아웃바운드(나가는 트래픽) 제어 = LOCAL_PREF — 내부에서 선호 회선을 정한다. 값이 클수록 선호. 내가 통제하기 쉬움.
• 인바운드(들어오는 트래픽) 제어 = AS_PATH Prepend / MED / Community — 상대가 내 경로를 어떻게 볼지 조정. 상대 정책에 좌우되어 통제가 어려움.

8. 운영 시나리오 ③ iBGP 확장 — Route Reflector

iBGP는 "배운 경로를 다른 iBGP 이웃에 재전달하지 않는다"는 규칙 때문에, 라우터가 N대면 N×(N-1)/2 개의 Full Mesh 세션이 필요합니다. 라우터가 많아지면 관리가 폭발합니다. 이를 해결하는 것이 Route Reflector(RR, 경로 반사기)입니다. RR은 iBGP 경로를 다른 iBGP 이웃(client)에게 대신 반사(reflect)해 주어, Full Mesh 없이도 경로를 전파합니다.

대규모 환경에서는 RR을 이중화하고, 또 다른 방법인 Confederation(연합)으로 AS를 잘게 나누기도 합니다.

9. 운영 시나리오 ④ 데이터센터 Spine-Leaf eBGP 패브릭

현대 데이터센터는 Spine-Leaf(CLOS) 토폴로지를 씁니다. 흥미롭게도 이 내부 패브릭의 라우팅 프로토콜로 전통적 IGP(OSPF) 대신 eBGP를 쓰는 것이 사실상 표준이 되었습니다(RFC 7938). 각 스위치를 별도 AS로 두고 eBGP로 연결하면, 단순·확장성·트래픽 엔지니어링·멀티벤더 측면에서 유리하기 때문입니다.

10. 실무 장비 설정 (Cisco · Juniper · FRRouting)

Cisco IOS — 기본 eBGP 피어링

router bgp 65100
 bgp router-id 10.0.0.1
 neighbor 203.0.113.2 remote-as 64500      ! ISP A와 eBGP
 neighbor 203.0.113.6 remote-as 64501      ! ISP B와 eBGP
 address-family ipv4 unicast
  network 198.51.100.0 mask 255.255.255.0  ! 우리 대역 광고
  neighbor 203.0.113.2 activate
  neighbor 203.0.113.6 activate
 exit-address-family

! 세션/경로 확인
! show ip bgp summary
! show ip bgp
! show ip route bgp

Cisco IOS — 아웃바운드는 ISP A 선호(LOCAL_PREF), 인바운드는 ISP B로 덜 유도(AS_PATH prepend)

! 들어온 경로에 LOCAL_PREF 200 부여 → 나가는 트래픽은 ISP A 우선
route-map FROM-ISP-A permit 10
 set local-preference 200
!
! ISP B로 내보내는 우리 경로의 AS_PATH를 길게(prepend) → 인바운드는 ISP A로 유도
route-map TO-ISP-B permit 10
 set as-path prepend 65100 65100 65100
!
router bgp 65100
 neighbor 203.0.113.2 route-map FROM-ISP-A in
 neighbor 203.0.113.6 route-map TO-ISP-B out

Cisco IOS — iBGP + Route Reflector

router bgp 65100
 neighbor 10.0.0.2 remote-as 65100          ! iBGP (같은 AS)
 neighbor 10.0.0.2 update-source Loopback0  ! 루프백으로 안정적 세션
 address-family ipv4 unicast
  neighbor 10.0.0.2 next-hop-self           ! iBGP next-hop 문제 방지
  neighbor 10.0.0.2 route-reflector-client  ! 이 이웃을 RR client로

Juniper Junos — eBGP

protocols {
    bgp {
        group ISP-A {
            type external;
            peer-as 64500;
            neighbor 203.0.113.2;
        }
    }
}
routing-options {
    autonomous-system 65100;
}
# 확인: show bgp summary / show route protocol bgp

FRRouting (FRR) — 리눅스/클라우드에서 널리 쓰이는 오픈소스 BGP

! vtysh 설정 (Cisco 유사 문법)
router bgp 65100
 bgp router-id 10.0.0.1
 neighbor 203.0.113.2 remote-as 64500
 address-family ipv4 unicast
  network 198.51.100.0/24
  neighbor 203.0.113.2 activate
 exit-address-family
!
! 확인: vtysh -c "show bgp summary"
!       vtysh -c "show bgp ipv4 unicast"

11. BGP 보안과 안정성 — 필터링 · RPKI · 하이재킹

BGP는 태생적으로 "이웃을 신뢰"하도록 설계되어, 잘못된(혹은 악의적인) 경로 광고에 취약합니다. 누군가 남의 IP 대역을 자기 것이라 광고하면 트래픽이 엉뚱한 곳으로 흘러가는데, 이를 BGP 하이재킹(hijacking)이라 합니다.

12. 클라우드 ① OpenStack Neutron 동적 라우팅

클라우드에서도 BGP가 깊이 쓰입니다. OpenStack의 네트워킹 서비스 Neutron은 neutron-dynamic-routing 확장으로 BGP를 지원합니다. 대표 용도는 "테넌트의 사설 IP(프로젝트 서브넷)와 Floating IP를 물리 네트워크로 자동 광고"하는 것입니다. 그러면 외부 라우터가 별도 정적 경로(static route) 없이도 클라우드 내부의 IP로 가는 길을 BGP로 학습합니다.

# OpenStack Neutron 동적 라우팅(BGP) 설정 예시
openstack bgp speaker create --local-as 64512 --ip-version 4 my-speaker
openstack bgp speaker add network my-speaker provider-network
openstack bgp peer create --peer-ip 10.0.0.1 --remote-as 64513 tor-router
openstack bgp speaker add peer my-speaker tor-router
# 광고되는 경로 확인
openstack bgp speaker list advertised routes my-speaker

최근에는 OVN(Open Virtual Network) 기반 환경에서 OVN-BGP-Agent가 FRR과 연동해 같은 역할을 더 유연하게 수행합니다.

13. 클라우드 ② Kubernetes — Calico · MetalLB · Cilium

Kubernetes에서 BGP는 "Pod IP와 Service(LoadBalancer) IP를 클러스터 밖 네트워크로 광고"하는 데 핵심적으로 쓰입니다. 오버레이(터널) 없이 Pod IP를 물리망에서 직접 라우팅하거나, 온프레미스에서 LoadBalancer 타입 서비스를 구현할 때 BGP가 등장합니다.

(1) Calico — Pod 네트워크를 BGP로 광고

Calico는 대표적인 CNI(Container Network Interface)로, 각 노드에서 BGP(내부적으로 BIRD 또는 FRR)를 돌려 그 노드에 있는 Pod 대역(예: /26)을 다른 노드와 물리 라우터에 광고합니다. 덕분에 오버레이 없이도 Pod끼리 순수 IP 라우팅(no-overlay)으로 통신할 수 있어 성능·가시성이 좋습니다. 대규모에서는 노드마다 Full Mesh 대신 Route Reflector를 씁니다.

# Calico 전역 BGP 설정 (AS 번호, RR 등)
apiVersion: projectcalico.org/v3
kind: BGPConfiguration
metadata:
  name: default
spec:
  asNumber: 64512
  serviceClusterIPs:
    - cidr: 10.96.0.0/12    # Service IP도 광고 가능
---
# 물리 라우터(ToR)와 BGP 피어링
apiVersion: projectcalico.org/v3
kind: BGPPeer
metadata:
  name: tor-switch
spec:
  peerIP: 10.0.0.1
  asNumber: 64513

(2) MetalLB (BGP 모드) — 온프레미스 LoadBalancer 서비스

퍼블릭 클라우드가 아닌 온프레미스 Kubernetes에는 LoadBalancer 타입 서비스에 외부 IP를 붙여 주는 장치가 없습니다. MetalLB가 이를 해결하는데, BGP 모드에서는 서비스의 외부 IP를 BGP로 물리 라우터에 광고해 클러스터 밖에서 그 IP로 접속할 수 있게 합니다. 여러 노드가 같은 서비스 IP를 광고하면 ECMP로 부하가 분산됩니다.

# MetalLB BGP 모드 — 피어와 IP 풀 정의
apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:
  name: tor-router
  namespace: metallb-system
spec:
  myASN: 64500
  peerASN: 64501
  peerAddress: 10.0.0.1
---
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: lb-pool
  namespace: metallb-system
spec:
  addresses:
    - 198.51.100.0/24
---
apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: lb-adv
  namespace: metallb-system
spec:
  ipAddressPools: [lb-pool]

(3) Cilium — eBPF 기반 CNI의 BGP Control Plane

Cilium은 eBPF 기반의 현대적 CNI로, 자체 BGP Control Plane(내부적으로 GoBGP)을 내장합니다. Pod CIDR와 LoadBalancer IP를 BGP로 광고하는 점은 Calico·MetalLB와 비슷하지만, eBPF의 고성능 데이터 경로와 결합된다는 점이 특징입니다. (참고: Cilium은 앞서 다룬 "eBPF/XDP" 기술과 직접 연결됩니다.)

# Cilium BGP — 클러스터 BGP 설정(개념 예시, 버전별 CRD 상이)
apiVersion: cilium.io/v2alpha1
kind: CiliumBGPClusterConfig
metadata:
  name: bgp-cluster
spec:
  bgpInstances:
    - name: "instance-64512"
      localASN: 64512
      peers:
        - name: "tor-peer"
          peerASN: 64513
          peerAddress: 10.0.0.1

14. 클라우드 ③ BGP EVPN / VXLAN 오버레이

대규모 데이터센터·클라우드에서는 VXLAN으로 L2 네트워크를 물리망 위에 겹쳐(overlay) 만들고, 그 제어 평면(control plane)으로 BGP EVPN(Ethernet VPN)을 사용합니다. 쉽게 말해 "어떤 가상머신·컨테이너의 MAC/IP가 어느 물리 서버(VTEP)에 있는지"를 BGP로 광고해, 넓은 데이터센터에서도 효율적으로 L2/L3 오버레이를 운영합니다.

15. 운영·트러블슈팅 팁

• 세션 상태 먼저 — show ip bgp summary로 이웃이 Established인지 확인. 숫자(경로 수)가 보이면 정상.
• Active/Idle 고착 — TCP 179 도달성(방화벽), remote-as·주소·인증(MD5) 불일치 점검.
• 경로가 안 보임 — 광고측 network/재분배 설정, 수신측 필터(prefix-list/route-map), iBGP next-hop 문제(next-hop-self) 확인.
• Flap(경로 요동) — 링크 불안정·타이머 문제. 과거엔 route dampening을 썼으나 부작용으로 신중히 사용.
• 최적 경로 이유 — show ip bgp <prefix>로 어떤 속성 때문에 best가 됐는지 확인.
• 안전장치 — 이웃마다 maximum-prefix와 인/아웃 필터를 반드시 설정(경로 누출 방지).

16. 시장과 생태계

BGP는 40년 가까이 인터넷의 근간을 지켜 왔고, 이제는 데이터센터 내부와 클라우드·컨테이너로 활동 무대를 넓혔습니다. "라우팅 프로토콜은 통신사만의 것"이라는 시대는 지났고, 개발·인프라 엔지니어에게도 BGP는 필수 소양이 되었습니다.

17. 용어 설명

BGP (Border Gateway Protocol)

AS들 사이에서 IP 대역의 도달 경로를 광고·학습하는 경로 벡터 프로토콜. 인터넷의 표준 라우팅 프로토콜.

AS / ASN (Autonomous System / Number)

하나의 정책으로 운영되는 네트워크 집합과 그 식별 번호. BGP 광고의 주체.

eBGP / iBGP

서로 다른 AS 사이의 세션(eBGP)과 같은 AS 내부 라우터 간 세션(iBGP).

IGP / EGP

AS 내부 라우팅(OSPF·IS-IS 등, IGP)과 AS 간 라우팅(BGP, EGP).

NLRI (Network Layer Reachability Information)

UPDATE 메시지에 실리는 "도달 가능한 IP 대역" 정보.

Path Attributes

경로에 붙는 속성들(AS_PATH, LOCAL_PREF, MED, NEXT_HOP, COMMUNITY 등). Best Path 선정과 정책의 기준.

AS_PATH

경로가 거쳐 온 AS 목록. 짧을수록 선호되며 루프 방지에도 쓰인다. Prepend로 일부러 길게 만들 수 있다.

LOCAL_PREF / MED

LOCAL_PREF는 AS 내부에서 아웃바운드 경로를 결정(클수록 선호), MED는 이웃 AS에 인바운드 입구를 힌트(작을수록 선호).

Best Path

같은 목적지의 여러 경로 중 속성 비교로 선택된 최적 경로.

Route Reflector (RR)

iBGP Full Mesh를 대체하기 위해 경로를 client에게 반사(전파)해 주는 라우터. 대규모 AS의 필수 설계.

CLOS / Spine-Leaf

데이터센터의 확장형 토폴로지. 내부 라우팅으로 eBGP를 널리 사용(RFC 7938).

RPKI / ROA

Resource PKI와 Route Origin Authorization. 어떤 AS가 어떤 대역을 광고해도 되는지 검증해 하이재킹을 막는다.

BGP 하이재킹 / 경로 누출

남의 대역을 자기 것이라 잘못 광고(hijack)하거나, 받은 경로를 잘못 재광고(leak)해 트래픽이 오도되는 사고.

FRRouting (FRR)

리눅스용 오픈소스 라우팅 스택. Kubernetes·OpenStack·화이트박스 스위치의 BGP 엔진으로 널리 쓰인다.

CNI (Container Network Interface)

Kubernetes의 네트워크 플러그인 표준. Calico·Cilium 등이 BGP로 Pod/Service IP를 광고한다.

MetalLB

온프레미스 Kubernetes에서 LoadBalancer 서비스 IP를 제공하는 도구. BGP 모드로 외부 IP를 광고한다.

VXLAN / BGP EVPN

물리망 위에 가상 L2/L3 네트워크를 겹치는 오버레이 기술(VXLAN)과 그 제어 평면(BGP EVPN).

ECMP (Equal-Cost Multi-Path)

비용이 같은 여러 경로로 트래픽을 분산하는 기법. 여러 노드가 같은 IP를 광고할 때 부하분산에 활용.

본 문서는 학습 목적의 개념·실무 정리입니다. 설정 예시는 이해를 돕기 위한 것으로, 실제 적용 시에는 장비·소프트웨어 버전과 공식 문서를 확인하시기 바랍니다. "Anycast"·"DNS"·"OVS" 문서와 함께 보면 BGP의 쓰임새가 더 넓게 보입니다.

SSL 가시화(SSL/TLS Visibility) — 개념 · 아키텍처 · 망구성, 그리고 직접 개발하기

오늘날 인터넷 트래픽의 대부분은 TLS(Transport Layer Security)로 암호화되어 있습니다. 보안이 강해진 것은 좋지만, 역설적으로 방화벽·침입탐지(IDS/IPS)·유출방지(DLP) 같은 보안 장비가 "내용을 볼 수 없는" 사각지대가 생겼습니다. 공격자는 이 암호화 뒤에 악성코드를 숨깁니다. SSL 가시화(SSL/TLS Visibility) 제품은 이 암호화 트래픽을 안전하게 복호화해 보안 장비에 넘겨주고 다시 암호화하는 장치입니다. 이 문서는 그 개념·아키텍처·망구성부터, 오픈소스로 직접 구현하는 방법까지 다룹니다.

1. SSL 가시화란 무엇인가 — 암호화라는 사각지대

SSL 가시화(SSL/TLS Visibility, 또는 SSL Inspection·TLS Decryption·복호화 가시성)는 암호화된 TLS 트래픽을 중간에서 복호화하여 그 내용을 보안 장비가 검사할 수 있게 만든 뒤, 다시 암호화하여 목적지로 전달하는 기술·제품입니다.

왜 필요할까요? 현재 웹 트래픽의 대부분(80~95%)이 HTTPS로 암호화되어 있습니다. 그런데 방화벽·IPS·DLP·샌드박스 같은 보안 장비는 암호화된 페이로드(payload)를 들여다볼 수 없습니다. 공격자는 이 점을 노려 악성코드 다운로드, 명령제어(C2), 데이터 유출을 모두 TLS 안에 숨깁니다. "보이지 않으면 막을 수 없다"는 것이 핵심 문제입니다.

2. 태동 배경과 역사 (Motive)

• HTTPS의 전면 확산 — Let's Encrypt의 무료 인증서, 구글의 "HTTPS 우대" 정책, 브라우저의 "안전하지 않음" 경고로 웹 전체가 암호화됨.
• 암호화된 위협(Encrypted Threats) — 악성코드·C2·랜섬웨어의 대다수가 이제 TLS를 통해 오간다. 암호화가 공격자의 은신처가 됨.
• 규제·감사 요구 — 데이터 유출 방지(DLP), 규정 준수(compliance)를 위해 나가는 트래픽 내용을 봐야 하는 필요.
• TLS 1.3·PFS의 등장 — 과거의 "수동 복호화(passive)"가 불가능해지면서, 인라인 복호화(가시화 장비)가 사실상 필수가 됨.

3. 두 가지 큰 방향 — 아웃바운드 vs 인바운드

4. 동작 원리 ① 아웃바운드 Forward Proxy(MITM)

아웃바운드 가시화의 핵심은 "통제된 중간자(Man-in-the-Middle)"입니다. 가시화 장비는 TLS 세션을 둘로 쪼갭니다 — 클라이언트와는 장비가 서버인 척, 서버와는 장비가 클라이언트인 척. 그 사이에서 평문(plaintext)을 얻어 검사합니다.

1. 클라이언트가 https://site.com에 접속을 시도(ClientHello의 SNI로 목적지 파악).
2. 장비가 실제 서버와 먼저 TLS를 맺어 진짜 인증서를 확인.
3. 장비가 내부 CA로 site.com용 가짜(대리) 인증서를 즉석 생성해 클라이언트에게 제시.
4. 클라이언트는 (내부 CA를 신뢰하도록 설정돼 있으므로) 이를 정상으로 받아들여 장비와 TLS를 맺음.
5. 장비는 양쪽 세션의 중간에서 평문을 획득 → 보안 장비로 검사 → 다시 암호화하여 서버로 전달.

5. 동작 원리 ② 인바운드(서버 보호) 복호화

인바운드 방식은 훨씬 단순합니다. 우리가 서버의 인증서와 개인키를 이미 보유하므로, 장비에 그 키를 넣어 두면 들어오는 트래픽을 중간자 없이 직접 복호화할 수 있습니다(또는 리버스 프록시로 TLS를 종단). 데이터센터에서 웹 서버로 향하는 트래픽을 WAF·IPS로 검사할 때 씁니다.

6. Passive/TAP 방식과 TLS 1.3·PFS의 벽

예전에는 트래픽을 복제(TAP/mirror)해서 서버 개인키로 오프라인 복호화하는 수동 방식이 인기였습니다. 장비가 경로에 끼어들지 않아 지연·장애 위험이 없었기 때문입니다. 그러나 이 방식은 사실상 수명을 다했습니다.

7. Architecture — 제품 내부 구성요소

SSL 가시화 제품(또는 직접 만들 시스템)은 대체로 다음 구성요소로 이루어집니다.

8. 망 구성(Deployment Topology)

실제 네트워크에 어떻게 끼워 넣느냐에 따라 세 가지 대표 배치가 있습니다.

9. Decrypt Broker와 서비스 체이닝 — "한 번 복호화, 여러 번 검사"

복호화는 CPU를 많이 먹는 비싼 작업입니다. 그래서 여러 보안 장비가 각자 복호화하는 낭비를 없애기 위해, 전용 Decrypt Broker(복호화 중개기)가 딱 한 번 복호화한 평문을 여러 검사 장비에 순서대로(또는 병렬로) 흘려보내고, 마지막에 한 번 재암호화합니다. 이를 서비스 체이닝(Service Chaining)이라 합니다.

10. 인증서·CA 아키텍처

아웃바운드 가시화의 심장은 내부 CA(Certificate Authority)입니다. 장비는 접속 요청이 올 때마다 그 도메인용 대리(leaf) 인증서를 즉석에서 만들어 내부 CA 키로 서명합니다. 이 CA 인증서를 모든 사내 단말이 신뢰하도록 배포해 두면, 클라이언트는 경고 없이 접속합니다.

11. 직접 개발하기 — 설계 단계

실제로 SSL 가시화 시스템을 구현한다면, 대략 다음 순서로 설계합니다.

1. 배치 모드 결정 — 아웃바운드(Forward MITM)냐 인바운드(Reverse)냐, 인라인이냐 명시 프록시냐.
2. 트래픽 유도 — 리눅스에서 iptables/nftables + TPROXY로 투명 리다이렉트, 또는 명시 프록시. 목적지는 SNI로 파악.
3. 내부 CA 구축 — OpenSSL로 Root CA 생성, 키는 HSM/파일 보관. 대리 인증서를 SNI에 맞춰 즉석 생성·캐시.
4. TLS 세션 분리 — 클라이언트 측은 대리 인증서로 종단, 서버 측은 새 TLS로 재수립. 서버 인증서 검증은 장비가 대신 수행.
5. 정책 엔진 — 도메인 카테고리·SNI 기반 복호화/우회(bypass) 목록(금융·의료·인증서 pinning 앱은 우회).
6. 검사 연동 — 평문을 인라인으로 통과시키거나, ICAP·mirror로 IPS/DLP/AV에 전달.
7. 재암호화·포워딩, 그리고 로깅·감사·성능(하드웨어 암호가속·세션 캐시).

# (1) 투명 인터셉션: iptables로 443 트래픽을 프록시(8080)로 리다이렉트 (개념 예시)
iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 8080

# (2) 내부 Root CA 생성 (OpenSSL)
openssl genrsa -out myCA.key 4096
openssl req -x509 -new -nodes -key myCA.key -sha256 -days 3650 \
  -subj "/CN=MyCorp SSL Visibility CA" -out myCA.crt
# → myCA.crt 를 사내 단말 신뢰 저장소(GPO/MDM)에 배포

12. 직접 개발하기 — 오픈소스·라이브러리

바닥부터 만들 필요는 없습니다. 아래 오픈소스들이 각 구성요소의 훌륭한 출발점입니다.

① TLS 가로채기(MITM) 엔진 — 핵심

② TLS 라이브러리(직접 구현 시)

OpenSSL, BoringSSL(구글), wolfSSL·mbedTLS(경량/임베디드), s2n-tls(AWS), 그리고 Go의 crypto/tls·Rust의 rustls. 대리 인증서 즉석 생성은 Go의 crypto/x509나 OpenSSL API로 쉽게 구현합니다.

③ 평문 검사(분석) 측

Suricata(IDS/IPS, 인라인 가능), Zeek(네트워크 보안 모니터·TLS 메타데이터), ClamAV(안티바이러스, ICAP 연동), c-icap(ICAP 서버로 서비스 체이닝), nDPI(프로토콜 식별). 복호화된 평문을 이들에게 넘겨 검사합니다.

④ 최신 대안 — eBPF 기반 호스트 가시성

MITM 없이 단말(호스트)에서 평문을 얻는 방법도 뜨고 있습니다. eCapture·Pixie 같은 도구는 eBPF로 애플리케이션의 SSL_write/SSL_read 지점을 후킹해, 인증서 위조 없이 평문을 관측합니다. (앞서 다룬 "eBPF/XDP" 기술의 응용)

mitmproxy로 만드는 최소 프로토타입

# mitmproxy 설치 후 투명 모드로 실행 (자체 CA가 자동 생성됨: ~/.mitmproxy/mitmproxy-ca-cert.pem)
mitmdump --mode transparent --showhost

# 파이썬 애드온으로 복호화된 요청/응답을 검사 로직에 연결하는 예시
# save as inspect.py  →  mitmdump -s inspect.py
def request(flow):
    host = flow.request.pretty_host        # 복호화된 목적지
    # 정책: 금융/의료 도메인은 우회(복호화 로그 남기지 않음)
    if host.endswith("bank.com"):
        return
    body = flow.request.get_text()         # 평문 본문
    # → 여기서 DLP/시그니처 검사 로직 호출 (예: 민감정보 패턴, ClamAV 스캔)

def response(flow):
    ctype = flow.response.headers.get("content-type", "")
    if "application/octet-stream" in ctype:
        data = flow.response.content       # 평문 응답 바이트
        # → 악성코드 스캔(AV)로 전달

# Squid SSL Bump 예시 (선택적 복호화: peek → bump/splice)
# squid.conf 발췌
http_port 3128 ssl-bump \
  cert=/etc/squid/ssl/myCA.pem \
  generate-host-certificates=on dynamic_cert_mem_cache_size=8MB
acl step1 at_step SslBump1
acl bank ssl::server_name .bank.com
ssl_bump peek step1
ssl_bump splice bank        # 금융은 복호화하지 않고 통과(splice)
ssl_bump bump all           # 나머지는 복호화(bump)

13. 도전 과제 — Pinning · ECH · 성능 · 법적 문제

14. 시장과 선도 제품

흐름은 전용 어플라이언스 → SASE/클라우드 기반 검사로 이동 중입니다. 재택·모바일이 늘며 "출구 장비"만으로는 부족해졌고, 클라우드에서 복호화·검사하는 방식이 커지고 있습니다.

15. 용어 설명

SSL 가시화 (SSL/TLS Visibility)

암호화된 TLS 트래픽을 복호화해 보안 장비가 검사하게 한 뒤 다시 암호화하는 기술·제품. SSL Inspection·TLS Decryption이라고도 한다.

MITM (Man-in-the-Middle, 중간자)

통신 양단 사이에 끼어들어 트래픽을 중계하는 것. 가시화에서는 "통제된 MITM"으로 합법적으로 복호화한다.

Forward / Reverse Proxy

Forward는 내부 사용자의 아웃바운드 트래픽을, Reverse는 우리 서버로 들어오는 인바운드 트래픽을 다루는 프록시.

대리(대체) 인증서 (Forged/Re-signed Certificate)

가시화 장비가 목적지 도메인용으로 즉석 생성해 내부 CA로 서명한 인증서. 클라이언트가 장비를 서버로 믿게 만든다.

내부 CA (Internal Certificate Authority)

대리 인증서를 서명하는 조직 자체 인증기관. 이 CA를 단말이 신뢰해야 경고 없이 동작한다. 키 유출 시 치명적.

SNI (Server Name Indication)

TLS ClientHello에 담긴 접속 대상 도메인 이름. 무엇을 복호화/우회할지 정책 판단의 기준.

PFS (Perfect Forward Secrecy) / ECDHE

세션마다 임시 키를 쓰는 방식. 서버 개인키가 유출돼도 과거 트래픽을 복호화할 수 없어, 수동 복호화를 불가능하게 만든다.

Passive / Inline 복호화

Passive는 트래픽 복제(TAP)에 개인키로 오프라인 복호화(PFS에서 불가), Inline은 경로에 끼어들어 실시간 복호화.

Decrypt Broker / Service Chaining

한 번만 복호화한 평문을 여러 보안 장비에 순차/병렬로 전달하고 마지막에 한 번 재암호화하는 구조.

ICAP (Internet Content Adaptation Protocol)

프록시가 콘텐츠를 외부 검사 서버(AV·DLP)에 넘겨 검사·수정하게 하는 프로토콜. 서비스 체이닝에 쓰인다.

Certificate Pinning (인증서 고정)

앱이 특정 인증서만 신뢰하도록 고정하는 기법. MITM을 거부하므로 가시화에서 우회 대상이 된다.

ECH (Encrypted Client Hello) / ESNI

SNI를 포함한 ClientHello 일부를 암호화하는 최신 기술. 목적지 파악을 어렵게 해 가시화의 새로운 도전이 된다.

eBPF 호스트 가시성 (eCapture 등)

MITM 없이 단말에서 애플리케이션의 암·복호화 함수를 후킹해 평문을 얻는 방식. 인증서 위조가 필요 없다.

HSM (Hardware Security Module)

암호 키를 안전하게 생성·보관·연산하는 전용 하드웨어. 내부 CA 키 보호의 표준.

fail-open / fail-close

인라인 장비 장애 시 트래픽을 그대로 통과(fail-open)시킬지 차단(fail-close)할지의 정책. 가용성 설계의 핵심.

본 문서는 학습·방어(defensive) 목적의 개념·설계 정리입니다. SSL 복호화는 강력한 만큼 프라이버시·법적 책임이 따릅니다. 실제 도입·구현 시에는 사내 정책·관련 법규를 반드시 확인하고, 금융·의료 등 민감 트래픽은 복호화 대상에서 제외하는 것을 원칙으로 하세요.