상용 NGFW HW 아키텍처

Fortinet 7121F/NP7/CP9, Palo Alto PA-7500/SP3, Check Point 29200/Maestro/LightSpeed, Juniper SRX5800, Cisco Secure Firewall 4245, Sophos XGS 8500 최상급 상용 NGFW 하드웨어 아키텍처 비교, SSL Inspection 오프로드 분류, 암호화(Encryption) 오프로드 아키텍처 3분류, 하드웨어 이벤트 스케줄러(Scheduler)(DLB/SSO), Linux 커널 기반 NGFW, 벤더별 TLS 핸드셰이크·암호화·성능 비교, 패킷 유형별 고성능 흐름, 배포 아키텍처 패턴, HA 구성, TLS 1.3/ECH 대응, PQC 영향, RFC 9411 성능 측정 방법론

상용 NGFW는 암호화·DPI 가속을 위해 크게 두 가지 하드웨어 처리 모델을 사용합니다:

대부분의 상용 NGFW는 두 모델을 혼합(Hybrid)하여 사용합니다. 다만 실무에서는 L4 세션 전달용 fast path와 SSL Inspection용 복호화(Decryption) 경로를 분리해서 봐야 합니다. 같은 장비라도 세션 포워딩은 inline인데, SSL/TLS 검사는 CPU중심 lookaside, SoC중심 lookaside, 카드형 크립토 가속기, 또는 전용 TLS 복호화 엔진일 수 있습니다. 아래 표는 2026년 6월 공식 문서 확인 기준으로 이를 정리한 것입니다:

2026년 7월 공식 자료 확인 요약

아래 내용은 2026년 7월 29일 기준 공식 벤더 문서와 데이터시트를 확인해 반영한 사항입니다. 2026년 6월 2일 1차 확인 이후 FortiOS 8.0/G 시리즈 공식 수치, OpenSSL 3.5 PQC 지원, Gartner Hybrid Mesh Firewall MQ 명칭 변경, Check Point R82.10 GA 전환 등을 추가로 반영했습니다. 2026년 7월 21일 Intel-Fortinet SP6 협력 발표, FortiSP5 발표 상세(2023년), Security Compute Rating 경쟁사 비교 수치를 추가 반영했습니다. 수치가 포함된 항목은 벤더가 공개한 시험 조건을 함께 보아야 하며, 실제 배치에서는 RFC 9411 방법론으로 재측정해야 합니다.

최상급 NGFW 장비 기준 아키텍처 비교

최고 성능 장비를 볼 때 가장 중요한 질문은 "어떤 칩이 빠른가"가 아니라 어떤 기능을 어느 계층에서 수평 확장하는가입니다. 최상급 NGFW는 대체로 ① 포트·패브릭 계층, ② 첫 패킷·세션 분류 계층, ③ L4/NAT/IPsec fast path 계층, ④ TLS 복호화 계층, ⑤ DPI/IPS/URL/파일 검사 계층, ⑥ 로그·관리 계층을 분리합니다. 아래 표는 공식 자료 기준으로 각 벤더의 플래그십 또는 최상위급 제품군을 이 관점에서 정리한 것입니다.

최상급 장비의 공통 패킷 경로 상세

플래그십 NGFW의 패킷 경로는 대부분 아래와 같은 형태로 수렴합니다. Fortinet은 이 계층을 FIM/FPM/NP7/CP9로, Palo Alto는 NPC/DPC/SFC로, Check Point는 SecureXL/CoreXL/Maestro로, Juniper는 MPC·IOC/SPC/SCB로, Cisco는 flow offload/crypto accelerator/Snort 3로, Sophos는 SlowPath/DPI Engine/FastPath/Xstream Flow Processor로 구현합니다.

벤더별 기능 칩셋 연결 구성도

아래 연결도는 공개 문서에서 확인 가능한 카드·ASIC·기능 블록의 논리 연결을 기준으로 작성했습니다. 실제 PCB 배선, SerDes lane 수, 내부 crossbar, 암호화 엔진 배치, CPU socket 구성은 대부분 벤더가 공개하지 않으므로 그림에 포함하지 않았습니다. 따라서 이 그림은 "실제 보드 회로도"가 아니라 패킷이 어느 기능 블록을 거쳐 성능을 얻는지를 설명하는 구조도입니다.

벤더별 핵심 성능 오프로드 아키텍처 상세도

아래 그림은 각 벤더의 고성능 경로를 패킷이 실제로 어느 기능 블록을 지나 성능을 얻는가라는 관점으로 다시 펼친 것입니다. 녹색 경로는 반복 패킷을 줄이는 fast path, 보라색 경로는 암호화·TLS·IPsec 보조, 주황색 경로는 DPI/IPS/URL/파일 검사처럼 비용이 큰 deep path를 뜻합니다. 벤더가 공개하지 않은 칩 내부 버스 폭, crossbar, crypto engine 세부 배치는 의도적으로 그리지 않았습니다.

벤더별 SSL Inspection 오프로드 분류

SSL/TLS Inspection은 단순히 "암호화 가속" 하나로 끝나지 않습니다. 실제로는 ① TLS 핸드셰이크와 키 교환, ② 레코드 계층 AES-GCM/ChaCha20 암·복호화, ③ 평문 DPI와 정책 엔진(Policy Engine), ④ 인증서/개인키 보관이 서로 다른 자원에 배치됩니다. 벤더별 차이는 바로 이 네 단계가 어디서 실행되는지에 있습니다.

암호화 오프로드 아키텍처 3분류

앞선 표에서 lookaside를 단일 카테고리로 분류했지만, 실제 구현을 살펴보면 lookaside 방식은 가속기의 물리적 위치와 버스 토폴로지(Topology)에 따라 크게 두 가지로 나뉩니다. CPU중심 룩어사이드(CPU-Centric Lookaside)는 PCIe 카드 형태의 외장 가속기를, SoC중심 룩어사이드(SoC-Centric Lookaside)는 SoC 다이 내장 크립토 엔진을 사용합니다. 여기에 데이터 경로 자체에 암호화를 삽입하는 인라인(Inline) 방식까지 포함하면, 암호화 오프로드는 3분류로 정리됩니다.

각 아키텍처의 핵심 차이는 패킷 데이터가 암호화 엔진에 도달하는 경로와 결과가 반환되는 지연 시간입니다. 기존 전용 크립토 가속기 섹션의 HW 스펙표와 함께 참조하면 전체 그림을 파악할 수 있습니다.

CPU중심 룩어사이드(CPU-Centric Lookaside)

CPU중심 룩어사이드는 CPU가 호스트 메모리에 있는 패킷 데이터를 PCIe 버스를 통해 외장 가속기 카드에 전송하고, 가속기가 처리한 결과를 다시 PCIe DMA로 돌려받는 모델입니다. CPU가 submission ring에 작업을 큐잉하면, 가속기가 비동기로 처리한 뒤 completion ring을 통해 완료를 통보합니다.

대표 하드웨어:

• Intel QAT 8970 (PCIe 카드) — 100 Gbps 대칭키, 100K RSA-2048 ops/s. qat_c62x 드라이버. 서버/어플라이언스용 대용량 SSL 프록시에 적합
• Intel QAT 4xxx (4th/5th Gen Xeon 내장) — 100 Gbps. SPR 이후 CPU에 통합되었으나, PCIe 도메인의 별도 디바이스로 노출되어 여전히 CPU중심 룩어사이드 모델
• Marvell NITROX V (PCIe 카드) — 100 Gbps, 최대 256 VF(SR-IOV) 지원. nitrox 드라이버로 커널 crypto API에 등록

커널 crypto API에 등록된 가속기의 우선순위(Priority) 확인:

# 등록된 암호화 알고리즘과 우선순위 확인
cat /proc/crypto | grep -A4 "name.*gcm(aes)"
# 출력 예시: driver = qat_aes_gcm, priority = 4001
# 우선순위가 높을수록 먼저 선택됨 (SW fallback은 보통 100~200)

# QAT 디바이스 상태 확인
cat /sys/kernel/debug/qat_4xxx_0000:6b:00.0/fw_counters

/* CPU중심 룩어사이드: 비동기 콜백 패턴 */
struct aead_request *req = aead_request_alloc(tfm, GFP_ATOMIC);
aead_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
                          crypto_done_callback, &result);
aead_request_set_crypt(req, src_sg, dst_sg, payload_len, iv);
aead_request_set_ad(req, assoclen);

ret = crypto_aead_encrypt(req);
if (ret == -EINPROGRESS || ret == -EBUSY) {
    /* 가속기가 비동기 처리 중 — completion 대기 */
    wait_for_completion(&result.completion);
    ret = result.err;
}
/* QAT: PCIe DMA 왕복 지연 ~10-50μs 포함 */

SoC중심 룩어사이드(SoC-Centric Lookaside)

SoC중심 룩어사이드는 크립토 엔진이 SoC 다이 내부에 통합되어 있으며, CPU와 내부 버스(AXI/AHB/ACE)로 직접 연결됩니다. PCIe를 거치지 않으므로 DMA 왕복 지연이 크게 줄어들고, 별도 전원·슬롯이 필요 없어 임베디드·네트워크 장비에 널리 사용됩니다. CPU가 Job Ring(또는 Command Ring)에 작업을 큐잉하면, 내장 크립토 엔진이 내부 버스를 통해 메모리에서 직접 데이터를 읽어 처리합니다.

대표 하드웨어:

• NXP CAAM (Cryptographic Acceleration and Assurance Module) — NXP Layerscape/i.MX SoC에 내장. Job Ring 기반 비동기 처리, 최대 4 JR. Linux 드라이버: caam (drivers/crypto/caam/)
• Marvell OCTEON CPT (Crypto Processing Thread) — OCTEON TX2/CN10K에 내장. 최대 100 Gbps 대칭키. octeontx2-cpt 드라이버
• Broadcom SPU (Security Processing Unit) — BCM58xxx/Memory Stingray SoC. bcm_crypto_spu 드라이버
• ARM CryptoCell — ARM TrustZone 연동 보안 코프로세서, 1-5 Gbps. ccree 드라이버. 상세 스펙은 크립토 가속기 비교표 참조

Device Tree 바인딩 예시 (NXP CAAM):

/* NXP Layerscape SoC — CAAM Device Tree 바인딩 */
crypto@1700000 {
    compatible = "fsl,sec-v5.4", "fsl,sec-v5.0",
                 "fsl,sec-v4.0";
    reg = <0x0 0x1700000 0x0 0x100000>;
    interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
    #address-cells = <1>;
    #size-cells = <1>;
    ranges = <0x0 0x0 0x1700000 0x100000>;

    /* Job Ring 0 */
    jr0: jr@10000 {
        compatible = "fsl,sec-v5.4-job-ring",
                     "fsl,sec-v4.0-job-ring";
        reg = <0x10000 0x10000>;
        interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
    };
    /* Job Ring 1 */
    jr1: jr@20000 {
        compatible = "fsl,sec-v5.4-job-ring";
        reg = <0x20000 0x10000>;
        interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
    };
};

인라인 암호화(Inline Crypto)

인라인 암호화는 가속기가 네트워크 데이터 경로(data path) 자체에 위치하여, 패킷이 NIC/SmartNIC을 통과하는 과정에서 암호화·복호화가 수행됩니다. CPU는 암호 키 설정과 SA(Security Association) 구성만 담당하고, 실제 패킷 데이터에는 전혀 관여하지 않습니다. IPSec, MACsec, kTLS(커널 TLS) 3가지 프로토콜이 인라인 오프로드의 대표적 사례입니다.

대표 하드웨어:

• NVIDIA (Mellanox) ConnectX-6 Dx / ConnectX-7 — IPSec inline (200 Gbps), MACsec, kTLS offload. mlx5_core 드라이버. xfrm offload + TC flower 연동
• Intel E810 (Colville) — IPSec inline offload (100 Gbps). ice 드라이버. ethtool -K eth0 esp-hw-offload on으로 활성화
• AMD (Pensando) DSC-200 — SmartNIC/DPU, IPSec + kTLS inline. P4 프로그래머블 파이프라인(Pipeline)에 crypto 엔진 통합

인라인 IPSec 오프로드 설정 확인(상세는 kTLS 오프로드 섹션 참조):

# NIC의 inline crypto 기능 확인
ethtool -k eth0 | grep -E "esp-hw-offload|tls-hw"
# esp-hw-offload: on        ← IPSec inline 지원
# tls-hw-tx-offload: on     ← kTLS TX inline 지원
# tls-hw-rx-offload: on     ← kTLS RX inline 지원

# xfrm (IPSec) offload 설정 — SA에 offload 플래그 추가
ip xfrm state add src 10.0.0.1 dst 10.0.0.2 \
    proto esp spi 0x100 reqid 1 mode tunnel \
    aead "rfc4106(gcm(aes))" 0x$(xxd -l 20 -p /dev/urandom) 128 \
    offload dev eth0 dir out    # ← inline offload 핵심 옵션

# offload 상태 확인
ip xfrm state show | grep -A2 offload

3종 아키텍처 종합 비교

하드웨어별 아키텍처 분류 상세:

리눅스 커널 Crypto API 매핑

리눅스 커널의 다양한 암호화 서브시스템은 3종 아키텍처를 각각 다른 경로로 활용합니다. 아래 표는 주요 서브시스템별 매핑을 보여줍니다:

커널 crypto API의 우선순위 기반 자동 선택(fallback chain):

# /proc/crypto에서 동일 알고리즘의 우선순위 확인
# 우선순위가 높은 드라이버가 자동 선택됨
$ grep -B1 -A5 "gcm(aes)" /proc/crypto

name         : gcm(aes)
driver       : qat_aes_gcm           # ← QAT 가속기 (CPU중심 Lookaside)
priority     : 4001                    # ← 최우선
async        : yes

name         : gcm(aes)
driver       : caam-gcm-aes           # ← CAAM (SoC중심 Lookaside)
priority     : 3000
async        : yes

name         : gcm(aes)
driver       : generic-gcm-aesni      # ← CPU AES-NI (SW fallback)
priority     : 400
async        : no

# Fallback chain: QAT(4001) → CAAM(3000) → AES-NI(400) → generic(100)
# 가속기 장애 시 자동으로 다음 우선순위 드라이버로 전환

암호화 완료 모델: 동기·비동기·폴링(Polling)

커널 crypto API에서 암호화 요청이 HW 가속기에 제출된 뒤 결과를 수신하는 방식은 크게 3가지로 나뉩니다: 동기(Synchronous), 비동기 인터럽트(Asynchronous Interrupt), 비동기 폴링. 각 모델은 지연 시간, CPU 활용률, 처리량 특성이 근본적으로 다르며, NGFW의 성능 프로파일을 결정하는 핵심 요소입니다.

동기 처리(Synchronous)

동기 모델에서 CPU는 암호화 함수를 호출한 뒤 결과가 반환될 때까지 블로킹됩니다. CPU 자체의 AES-NI/ARMv8-CE 명령어로 처리하는 경우가 대표적이며, 함수 호출과 반환이 동일 컨텍스트에서 완료됩니다.

/* 동기(Synchronous) 처리 — CPU 명령어(AES-NI) 직접 실행 */
struct skcipher_request *req = skcipher_request_alloc(tfm, GFP_KERNEL);
skcipher_request_set_crypt(req, src_sg, dst_sg, len, iv);

/* 콜백 없이 직접 호출 — 반환 시 이미 완료 */
ret = crypto_skcipher_encrypt(req);
/* ret == 0: 즉시 완료 (동기)
 * CPU AES-NI의 경우 /proc/crypto에서 async: no 표시 */

if (ret == 0) {
    /* 암호화 완료 — 결과가 dst_sg에 이미 기록됨 */
    process_encrypted_packet(dst_sg);
}
skcipher_request_free(req);

비동기 인터럽트 처리(Asynchronous Interrupt-Driven)

비동기 인터럽트 모델은 커널 crypto API에서 가장 일반적인 HW 가속기 활용 패턴입니다. CPU가 요청을 가속기의 submission ring에 큐잉하면 즉시 반환되고, 가속기가 처리를 완료하면 인터럽트(IRQ)를 발생시켜 등록된 콜백 함수를 호출합니다.

커널 crypto API에서 비동기 요청의 반환값 의미와 콜백 처리 흐름:

/*
 * crypto API 반환값 — 완료 모델을 결정하는 핵심
 *
 *  0            : 동기 완료 — 결과가 이미 준비됨
 * -EINPROGRESS  : 비동기 처리 시작됨 — 콜백으로 완료 통보 예정
 * -EBUSY        : 백로그(backlog) 큐에 진입 — 큐 공간 확보 후 처리 예정
 * -ENOSPC       : 큐 가득 참(백로그 미허용 시) — 호출자가 재시도해야 함
 * 기타 음수     : 오류 (키 설정 오류, 메모리 부족 등)
 */

/* ── 비동기 콜백 구조체 ── */
struct crypto_async_result {
    struct completion completion;   /* wait_for_completion() 대상 */
    int err;                        /* 콜백에서 설정되는 최종 에러 코드 */
};

/* ── 콜백 함수 — 가속기 인터럽트 핸들러에서 호출됨 ── */
static void crypto_op_complete(void *data, int err)
{
    struct crypto_async_result *result = data;
    /*
     * err == 0        : 암호화 성공
     * err == -EINPROGRESS : 백로그에서 꺼내어 처리 시작
     *                       (CRYPTO_TFM_REQ_MAY_BACKLOG 설정 시)
     * err < 0 (기타)  : HW 오류
     */
    if (err == -EINPROGRESS)
        return;  /* 아직 완료 아님 — 실제 완료 시 다시 호출됨 */

    result->err = err;
    complete(&result->completion);  /* 대기 중인 스레드 깨움 */
}

/* ── 요청 제출 — CRYPTO_TFM_REQ_MAY_BACKLOG 플래그 상세 ── */
struct aead_request *req = aead_request_alloc(tfm, GFP_ATOMIC);
aead_request_set_callback(req,
    CRYPTO_TFM_REQ_MAY_BACKLOG |   /* 큐 가득 차도 백로그 허용 */
    CRYPTO_TFM_REQ_MAY_SLEEP,      /* 콜백에서 sleep 가능 (프로세스 컨텍스트) */
    crypto_op_complete, &result);
aead_request_set_crypt(req, src_sg, dst_sg, payload_len, iv);
aead_request_set_ad(req, assoclen);

ret = crypto_aead_encrypt(req);
switch (ret) {
case 0:
    /* 동기 완료 — SW fallback이 선택된 경우 또는
     * 가속기가 즉시 처리 완료한 경우 */
    process_result(req);
    break;

case -EINPROGRESS:
    /* 비동기 처리 시작 — 가속기가 DMA로 데이터 전송 중
     * 완료 시 crypto_op_complete() 콜백 호출됨 */
    break;

case -EBUSY:
    /* 가속기 큐 가득 참 + 백로그에 진입
     * CRYPTO_TFM_REQ_MAY_BACKLOG 덕분에 거부되지 않음
     * 콜백이 두 번 호출됨:
     *   1차: err=-EINPROGRESS (백로그→실제 큐 이동 시)
     *   2차: err=0 (처리 완료 시) */
    break;

default:
    /* 오류 — 키 미설정, 메모리 부족, HW 장애 등 */
    pr_err("crypto op failed: %d\n", ret);
    break;
}

백로그(Backlog) 큐 동작 상세:

비동기 폴링 처리(Asynchronous Polling)

비동기 폴링 모델에서는 인터럽트 대신 CPU가 주기적으로 completion ring(또는 상태 레지스터(Register))을 직접 확인합니다. 인터럽트 발생·처리·컨텍스트 전환 오버헤드를 제거하여 초저지연을 달성할 수 있지만, 폴링 동안 CPU 사이클을 소모합니다.

커널 6.0+에서 도입된 crypto_engine 폴링 모드와 DPDK 환경의 busy-polling이 대표적입니다:

커널 crypto_engine 폴링 모드 — struct crypto_engine은 가속기 드라이버에 kthread 기반 폴링 완료 처리를 지원합니다 (crypto/crypto_engine.c):

/*
 * crypto_engine 폴링 모드 (커널 6.0+)
 * drivers/crypto/crypto_engine.c
 *
 * 기본 인터럽트 모드 대비 폴링 모드 전환 조건:
 * 1. 고처리량 시나리오 (인터럽트 스톰 방지)
 * 2. 초저지연 요구 (IRQ 컨텍스트 전환 제거)
 */

/* ── 드라이버에서 폴링 모드 지원 등록 ── */
struct crypto_engine *engine;
engine = crypto_engine_alloc_init(dev, true);  /* rt=true: 실시간 우선순위 */

/* 폴링 기반 완료 처리 — 전용 kthread가 CQ를 확인 */
static int hw_accel_poll_completions(struct crypto_engine *engine)
{
    struct hw_completion_ring *cq = engine->priv;
    int completed = 0;

    /* completion ring의 유효한 엔트리를 순회 */
    while (cq->head != cq->tail) {
        struct crypto_async_request *req;
        struct hw_cq_entry *entry = &cq->entries[cq->head];

        /* 완료 여부 확인 (HW가 done 비트 설정) */
        if (!(READ_ONCE(entry->flags) & HW_CQ_DONE))
            break;

        req = entry->async_req;
        /* DMA 매핑 해제 */
        dma_unmap_sg(dev, req->src, sg_nents(req->src),
                     DMA_BIDIRECTIONAL);

        /* 콜백 호출 — 인터럽트 컨텍스트가 아닌
         * kthread 컨텍스트에서 실행 */
        crypto_finalize_request(engine, req, 0);

        cq->head = (cq->head + 1) % cq->ring_size;
        completed++;
    }
    return completed;
}

/*
 * 인터럽트 vs 폴링 전환 (적응형 모드)
 * 처리량이 임계치를 초과하면 자동으로 폴링 전환
 */
static irqreturn_t hw_accel_irq_handler(int irq, void *data)
{
    struct hw_accel_dev *hdev = data;

    if (hdev->completions_per_sec > POLL_THRESHOLD) {
        /* 고처리량 → 인터럽트 비활성화 + 폴링 모드 전환 */
        disable_irq_nosync(irq);
        hdev->polling = true;
        /* kthread가 폴링 루프 시작 */
        wake_up_process(hdev->poll_thread);
        return IRQ_HANDLED;
    }
    /* 일반 모드 — 인터럽트 기반 완료 */
    return hw_accel_process_irq(hdev);
}

DPDK / 유저스페이스 busy-polling — NGFW에서 DPDK 기반 데이터 플레인(VPP, Suricata AF_XDP)을 사용할 경우:

/*
 * DPDK cryptodev 폴링 모드 — 유저스페이스 busy-polling
 * rte_cryptodev_dequeue_burst()로 완료된 작업 수집
 */

/* 1. 암호화 요청 배치 제출 (enqueue) */
uint16_t enqueued = rte_cryptodev_enqueue_burst(
    cdev_id,        /* crypto device ID */
    qp_id,          /* queue pair */
    crypto_ops,     /* 요청 배열 */
    nb_ops          /* 배치 크기 (32-256) */
);

/* 2. busy-polling으로 완료 수집 (dequeue) */
uint16_t dequeued;
do {
    dequeued = rte_cryptodev_dequeue_burst(
        cdev_id, qp_id,
        completed_ops,  /* 완료된 요청 배열 */
        MAX_BURST       /* 최대 수집 수 */
    );
    /*
     * dequeued == 0: 아직 완료된 작업 없음 → 재폴링
     * 인터럽트·컨텍스트 전환 없이 즉시 재확인
     * → 지연 최소화, 단 CPU 100% 사용
     */
} while (dequeued == 0);

/* 3. 완료된 작업 처리 */
for (int i = 0; i < dequeued; i++) {
    if (completed_ops[i]->status ==
        RTE_CRYPTO_OP_STATUS_SUCCESS) {
        /* 암호화 완료 — 다음 파이프라인 단계로 전달 */
        forward_packet(completed_ops[i]->sym->m_dst);
    }
}

완료 모델 종합 비교

적응형 인터럽트 병합과 하이브리드 폴링

실무 NGFW에서는 순수 인터럽트나 순수 폴링이 아닌, 트래픽 부하에 따라 동적으로 전환하는 적응형(adaptive) 모델을 사용합니다. 리눅스 커널 NAPI(New API)가 네트워크 드라이버에서 사용하는 것과 동일한 원리입니다:

/*
 * 적응형 인터럽트/폴링 전환 — NAPI식 crypto 완료 처리
 * 고처리량 시 인터럽트 스톰을 방지하고 배치 처리 효율 극대화
 */
#define POLL_BUDGET      64    /* 한 번의 폴링에서 최대 처리 수 */
#define IRQ_TO_POLL_THRESH  1000  /* IRQ/초 임계치 → 폴링 전환 */
#define POLL_TO_IRQ_THRESH  100   /* 폴링 공회전 → IRQ 복귀 */

/* ── 인터럽트 핸들러: 고부하 감지 시 폴링 전환 ── */
static irqreturn_t crypto_irq_handler(int irq, void *data)
{
    struct crypto_hw_queue *q = data;

    q->irq_count++;

    if (q->irq_count > IRQ_TO_POLL_THRESH) {
        /* 인터럽트 빈도 과다 → 폴링 모드 전환 */
        disable_irq_nosync(irq);
        q->mode = CRYPTO_MODE_POLL;
        napi_schedule(&q->napi);   /* 폴링 스케줄링 */
        return IRQ_HANDLED;
    }

    /* 일반 모드: 개별 완료 처리 */
    crypto_process_completions(q, 1);
    return IRQ_HANDLED;
}

/* ── NAPI식 폴링 핸들러 ── */
static int crypto_napi_poll(struct napi_struct *napi, int budget)
{
    struct crypto_hw_queue *q =
        container_of(napi, struct crypto_hw_queue, napi);
    int completed = 0;

    /* completion ring에서 완료된 항목 배치 수집 */
    completed = crypto_poll_completions(q, budget);

    if (completed < budget) {
        /*
         * 배치 미달 → 트래픽 감소 감지
         * 폴링 종료 + 인터럽트 복원
         */
        q->idle_polls++;
        if (q->idle_polls > POLL_TO_IRQ_THRESH) {
            napi_complete(napi);
            q->mode = CRYPTO_MODE_IRQ;
            q->irq_count = 0;
            q->idle_polls = 0;
            enable_irq(q->irq_num);  /* 인터럽트 복원 */
        }
    } else {
        q->idle_polls = 0;  /* 배치 꽉 참 → 계속 폴링 */
    }
    return completed;
}

인터럽트 병합(Interrupt Coalescing) 설정 — QAT 가속기 예시:

# QAT 인터럽트 병합 설정
# /etc/sysconfig/qat 또는 sysfs 경로

# 병합 타이머: N μs 동안 완료를 모아서 단일 IRQ 발생
echo 10 > /sys/kernel/debug/qat_4xxx_0000:6b:00.0/irq_coal_timer_ns
# 10μs 간격 → 초당 최대 100K IRQ (vs 병합 없이 수백만)

# 병합 카운트: N개 완료마다 IRQ 1회
echo 32 > /sys/kernel/debug/qat_4xxx_0000:6b:00.0/irq_coal_count
# 32개 완료 묶음 → IRQ 횟수 1/32로 감소

# 현재 모드 확인
cat /sys/kernel/debug/qat_4xxx_0000:6b:00.0/irq_mode
# adaptive / timer / count / poll

# ethtool로 NIC crypto 인터럽트 병합 설정 (ConnectX-7)
ethtool -C eth0 rx-usecs 10 tx-usecs 10
# 10μs 간격으로 RX/TX 인터럽트 병합

아키텍처 선택 가이드

시나리오별로 최적의 암호화 오프로드 아키텍처를 선택하는 기준:

하드웨어 이벤트 스케줄러 (Intel DLB / Marvell SSO)

NGFW 데이터 플레인에서 수백만 플로우를 다수의 CPU 코어에 효율적으로 분배하는 것은 핵심 과제입니다. RSS(Receive Side Scaling)는 해시(Hash) 기반 정적 분배만 가능하여 코어 간 부하 불균형이 발생하고, 소프트웨어 큐 관리는 잠금 경합(Lock Contention)과 캐시(Cache) 바운싱 오버헤드를 유발합니다. 하드웨어 이벤트 스케줄러는 이 문제를 전용 ASIC/SoC 블록으로 해결합니다.

대표적인 HW 이벤트 스케줄러로 Intel의 DLB(Dynamic Load Balancer)와 Marvell의 SSO(Schedule/Synchronize/Order)가 있으며, 둘 다 원자적(Atomic) 플로우 스케줄링, 순서 보장(Ordering), 동적 부하 분산(Load Balancing)을 하드웨어 수준에서 제공합니다.

이벤트 스케줄러 핵심 개념

HW 이벤트 스케줄러는 패킷을 직접 전달하지 않고, 이벤트(Event) 단위로 작업을 추상화합니다. 하나의 이벤트는 패킷 도착, 타이머(Timer) 만료, 크립토 완료 등 다양한 소스에서 발생하며, 스케줄러가 이를 워커 코어(Worker Core)에 분배합니다.

3종 스케줄링 모드가 NGFW 파이프라인에서 각각 다른 단계에 적용됩니다:

Intel DLB (Dynamic Load Balancer)

Intel DLB(이전 명칭 HQM — Hardware Queue Manager)는 4th Gen Xeon(SPR) 이후 CPU에 내장된 하드웨어 이벤트 스케줄러입니다. PCIe 디바이스로도 출시되었으며(DLB 2.0/2.5), DPDK eventdev 라이브러리를 통해 VPP, DPDK 기반 NGFW, Open vSwitch 등에서 활용됩니다.

DLB 핵심 사양:

DLB의 핵심 구성 요소:

• QID(Queue ID) — 논리적 이벤트 큐. 하나의 QID에 스케줄링 타입(atomic/ordered/parallel)과 우선순위를 설정합니다. NGFW에서는 파이프라인 단계별(방화벽(Firewall)→IPS→암호화) QID를 할당합니다
• CQ(Consumer Queue) — 워커 코어가 이벤트를 수신하는 큐. 각 코어에 1개 CQ를 바인딩하고, 폴링 또는 인터럽트로 이벤트를 가져옵니다
• PP(Producer Port) — 이벤트 소스(NIC RX, crypto 완료 등)가 이벤트를 제출하는 포트
• Credit — 흐름 제어(Flow Control) 메커니즘. Producer는 이벤트 제출 시 credit을 소모하고, Consumer가 처리 완료 후 반환합니다. Credit 고갈 시 자동 배압(backpressure) 발생
• Directed Port/Queue — 스케줄링 없이 특정 CQ에 직접 전달하는 1:1 경로. 파이프라인 단계 간 명시적 전달에 사용

DPDK eventdev를 통한 DLB 설정과 NGFW 파이프라인 구성:

/*
 * DPDK eventdev API로 DLB 기반 NGFW 파이프라인 구성
 * rte_event_dev → rte_event_queue → rte_event_port 매핑
 */
#include <rte_eventdev.h>
#include <rte_event_eth_rx_adapter.h>
#include <rte_event_crypto_adapter.h>

/* 1. DLB eventdev 초기화 */
struct rte_event_dev_config dev_conf = {
    .nb_event_queues = 4,        /* QID 4개 (FW/IPS/Crypto/TX) */
    .nb_event_ports = 8,         /* 워커 코어 8개 */
    .nb_events_limit = 4096,     /* 최대 동시 이벤트 수 */
    .nb_event_queue_flows = 1024,/* 플로우 해시 엔트리 수 */
    .nb_event_port_dequeue_depth = 32,
    .nb_event_port_enqueue_depth = 32,
};
rte_event_dev_configure(evdev_id, &dev_conf);

/* 2. 파이프라인 단계별 QID 설정 */
struct rte_event_queue_conf q_conf;

/* QID 0: 방화벽 (Atomic — conntrack 상태 보호) */
q_conf.schedule_type = RTE_SCHED_TYPE_ATOMIC;
q_conf.priority = RTE_EVENT_DEV_PRIORITY_HIGHEST;
q_conf.nb_atomic_flows = 1024;   /* 동시 추적 플로우 수 */
rte_event_queue_setup(evdev_id, 0, &q_conf);

/* QID 1: IPSec 암복호화 (Ordered — 순서 보장 + 병렬) */
q_conf.schedule_type = RTE_SCHED_TYPE_ORDERED;
q_conf.priority = RTE_EVENT_DEV_PRIORITY_NORMAL;
rte_event_queue_setup(evdev_id, 1, &q_conf);

/* QID 2: IPS/DPI (Parallel — 최대 처리량) */
q_conf.schedule_type = RTE_SCHED_TYPE_PARALLEL;
rte_event_queue_setup(evdev_id, 2, &q_conf);

/* QID 3: TX (Directed — 특정 TX 코어로 직접 전달) */
/* Directed는 별도 API로 설정 */

/* 3. 워커 포트 설정 — 각 코어에 CQ 바인딩 */
struct rte_event_port_conf p_conf = {
    .dequeue_depth = 32,
    .enqueue_depth = 32,
    .new_event_threshold = 128,  /* credit 기반 배압 임계치 */
};
for (int i = 0; i < 8; i++) {
    rte_event_port_setup(evdev_id, i, &p_conf);
    /* 포트 i → QID 0,1,2 매핑 (어떤 단계든 처리 가능) */
    rte_event_port_link(evdev_id, i, queues, priorities, 3);
}

/* 4. NIC RX → DLB 이벤트 어댑터 연결 */
rte_event_eth_rx_adapter_create(rx_adapter_id, evdev_id, &p_conf);
rte_event_eth_rx_adapter_queue_add(rx_adapter_id,
    eth_port_id, -1, /* 모든 RX 큐 */
    &(struct rte_event_eth_rx_adapter_queue_conf){
        .ev.queue_id = 0,    /* 첫 단계: FW QID */
        .ev.sched_type = RTE_SCHED_TYPE_ATOMIC,
        .ev.flow_id = 0,     /* RSS 해시를 flow_id로 사용 */
    });
rte_event_eth_rx_adapter_start(rx_adapter_id);

/* 5. 워커 루프 — 이벤트 수신·처리·전달 */
static void worker_loop(uint8_t port_id)
{
    struct rte_event events[32];
    while (!quit) {
        uint16_t nb = rte_event_dequeue_burst(
            evdev_id, port_id, events, 32, 0 /* no wait */);

        for (int i = 0; i < nb; i++) {
            struct rte_mbuf *pkt = events[i].mbuf;
            uint8_t cur_qid = events[i].queue_id;

            switch (cur_qid) {
            case 0: /* 방화벽 단계 — Atomic */
                if (firewall_check(pkt) == FW_PASS) {
                    /* 다음 단계(Crypto)로 전달 */
                    events[i].queue_id = 1;
                    events[i].op = RTE_EVENT_OP_FORWARD;
                } else {
                    rte_pktmbuf_free(pkt);
                    events[i].op = RTE_EVENT_OP_RELEASE;
                }
                break;

            case 1: /* IPSec 단계 — Ordered */
                ipsec_process(pkt);
                events[i].queue_id = 2;
                events[i].op = RTE_EVENT_OP_FORWARD;
                /* DLB가 자동으로 원래 순서 복원 */
                break;

            case 2: /* IPS/DPI 단계 — Parallel */
                ips_inspect(pkt);
                /* TX로 직접 전송 */
                rte_eth_tx_burst(tx_port, 0, &pkt, 1);
                events[i].op = RTE_EVENT_OP_RELEASE;
                break;
            }
        }
        rte_event_enqueue_burst(evdev_id, port_id, events, nb);
    }
}

# DLB 디바이스 확인
lspci | grep -i "dynamic load balancer"
# 6b:00.0 System peripheral: Intel Corporation
#         Dynamic Load Balancer (DLB) [8086:2710]

# 커널 드라이버 로드
modprobe dlb2
ls /dev/dlb*    # /dev/dlb0, /dev/dlb1, ...

# sysfs에서 DLB 리소스 확인
cat /sys/class/dlb2/dlb0/total_resources
# num_sched_domains: 32
# num_ldb_queues: 96
# num_ldb_ports: 64
# num_dir_ports: 96
# num_ldb_credits: 16384

# DPDK에서 DLB eventdev 바인딩
dpdk-devbind.py -b vfio-pci 0000:6b:00.0
# EAL 파라미터
--vdev=event_dlb2 --allow=0000:6b:00.0

Marvell OCTEON SSO (Schedule/Synchronize/Order)

Marvell OCTEON SSO는 OCTEON TX2/CN10K SoC에 내장된 하드웨어 이벤트 스케줄러입니다. Intel DLB와 유사한 기능을 제공하지만, SoC 내부의 모든 HW 가속기(크립토, 정규식, 압축)와 내부 버스로 직접 연동되는 것이 핵심 차이입니다. 패킷이 NIC에서 수신되면 SSO를 거쳐 CPU 코어에 분배되고, 크립토 처리 완료 후 다시 SSO로 돌아와 다음 단계 코어로 전달됩니다.

SSO 핵심 사양 (CN10K 기준):

SSO의 DLB 대비 핵심 차별점:

• HW 가속기 직접 연동: CPT(크립토), REE(정규식), ZIP(압축) 완료 시 자동으로 SSO 이벤트가 생성됩니다. DLB는 CPU가 가속기 완료를 확인한 뒤 이벤트를 재제출해야 하지만, SSO는 CPU 개입 없이 파이프라인이 진행됩니다
• WQE(Work Queue Entry): 패킷 메타데이터와 처리 컨텍스트를 포함하는 HW 구조체(Struct). NIC(RPM)이 패킷 수신 시 자동 생성하여 SSO에 제출합니다
• SWTAG(Software Tag Switch): 워커가 처리 중 태그 타입을 동적으로 변경할 수 있습니다. 예: conntrack 조회 시 Atomic → 패턴 매칭 시 Ordered로 전환
• TIM(Timer Wheel): HW 타이머가 만료되면 SSO 이벤트로 자동 전환. 세션 타임아웃 처리에 CPU 타이머 인터럽트 불필요

SSO를 활용한 NGFW 이벤트 드리븐 파이프라인:

/*
 * OCTEON CN10K SSO 기반 NGFW 파이프라인
 * DPDK eventdev API (event_cnxk 드라이버)
 *
 * 파이프라인: NIC RX → [SSO] → FW(Atomic) → [SSO] →
 *            CPT(Crypto) → [SSO] → IPS(Ordered) → TX
 */

/* 1. SSO 이벤트 수신 — MMIO GET_WORK */
static void sso_worker_loop(uint8_t port_id)
{
    struct rte_event ev;
    while (!quit) {
        /* SSO에서 이벤트 수신 (HW 폴링, ~10ns 지연) */
        if (rte_event_dequeue_burst(evdev_id, port_id,
                                     &ev, 1, 0) == 0)
            continue;

        struct rte_mbuf *pkt = ev.mbuf;
        uint32_t tag = ev.flow_id;  /* 플로우 해시 */

        switch (ev.queue_id) {
        case SSO_GRP_FIREWALL:  /* Atomic 모드 */
            /*
             * 동일 tag(flow)의 이벤트는 이 코어에서만 처리됨
             * → conntrack 조회/갱신에 락 불필요!
             */
            if (conntrack_lookup(tag, pkt) == CT_NEW) {
                conntrack_insert(tag, pkt);  /* lock-free */
            }
            if (!acl_check(pkt)) {
                rte_pktmbuf_free(pkt);
                ev.op = RTE_EVENT_OP_RELEASE;
                break;
            }

            /* IPSec 필요 시 → CPT(크립토)로 전달 */
            if (needs_ipsec(pkt)) {
                /*
                 * SSO → CPT 직접 전달 (CPU 미개입)
                 * CPT 완료 시 자동으로 SSO 이벤트 재생성
                 * → SSO_GRP_POST_CRYPTO 그룹으로 도착
                 */
                submit_to_cpt(pkt, SSO_GRP_POST_CRYPTO);
                ev.op = RTE_EVENT_OP_RELEASE;
            } else {
                ev.queue_id = SSO_GRP_IPS;
                ev.op = RTE_EVENT_OP_FORWARD;
                /* SWTAG: Atomic → Ordered 전환 */
                ev.sched_type = RTE_SCHED_TYPE_ORDERED;
            }
            break;

        case SSO_GRP_POST_CRYPTO:  /* CPT 완료 이벤트 */
            /*
             * CPU가 CPT를 폴링하지 않음!
             * HW가 암호화 완료 → SSO에 이벤트 자동 생성
             */
            ev.queue_id = SSO_GRP_IPS;
            ev.sched_type = RTE_SCHED_TYPE_ORDERED;
            ev.op = RTE_EVENT_OP_FORWARD;
            break;

        case SSO_GRP_IPS:  /* Ordered 모드 */
            ips_pattern_match(pkt);
            /* NIX TX로 직접 전송 — 순서 자동 보장 */
            ev.queue_id = SSO_GRP_TX;
            ev.op = RTE_EVENT_OP_FORWARD;
            break;
        }

        rte_event_enqueue_burst(evdev_id, port_id, &ev, 1);
    }
}

/* 2. HW 타이머를 이용한 세션 타임아웃 */
static void setup_session_timeout(uint32_t flow_tag,
                                   uint64_t timeout_ns)
{
    /*
     * OCTEON TIM(Timer Wheel)에 타이머 등록
     * 만료 시 SSO 이벤트로 자동 변환 → CPU 인터럽트 불필요
     */
    struct rte_event_timer tim = {
        .ev.queue_id = SSO_GRP_TIMEOUT,
        .ev.sched_type = RTE_SCHED_TYPE_ATOMIC,
        .ev.flow_id = flow_tag,
        .timeout_ticks = timeout_ns / tim_tick_ns,
        .state = RTE_EVENT_TIMER_ARMED,
    };
    rte_event_timer_arm_burst(timer_adapter_id, &tim, 1);
    /* timeout_ns 후 SSO_GRP_TIMEOUT에 이벤트 도착 */
}

DLB vs SSO 종합 비교

NGFW 파이프라인에서의 이벤트 스케줄러 활용

기존 NGFW 데이터 플레인은 run-to-completion(단일 코어가 패킷을 끝까지 처리) 또는 SW 파이프라인(SW 큐로 단계 간 전달) 모델을 사용합니다. HW 이벤트 스케줄러는 이를 HW 파이프라인으로 대체하여 잠금 경합·캐시 미스·부하 불균형을 제거합니다.

Fortinet NP7 / CP9 / SoC5 계열

Fortinet FortiGate는 제품군에 따라 구현이 다르지만, 공개 자료 기준으로 보면 세션 전달용 Network Processor와 검사용 보안/콘텐츠 프로세서를 결합한 하이브리드 구조입니다. F-series 데이터센터 계열과 7000F 섀시는 NP7이 inline fast path를 맡고, E-series 데이터센터 계열과 7000E 섀시는 NP6가 동일 역할을 수행합니다. SSL Inspection과 콘텐츠 검사는 별도 inspection 경로가 담당합니다. 브랜치 SoC 장비는 세대에 따라 SoC4/SP4(100F/200F/40F~80F 계열)와 SoC5/SP5(120G/200G 계열, NP7Lite 내장)로 나뉘며, 동일 SoC 내부에 해당 기능이 더 밀집되어 있어 SoC중심 lookaside에 가까운 하이브리드로 보는 편이 정확합니다:

• NP7 / NP6 계열 (Network Processor) — [Inline] L2~L4 세션 오프로드, NAT, IPSec/VXLAN/GRE fast path. Session table에 ESTABLISHED 세션을 등록하면 이후 패킷이 NP에서 직접 전달됩니다.
• CP9 / CP10 및 보안 프로세서 경로 — [Lookaside 또는 SoC 내부 inspection path] 프록시 기반 SSL/TLS 검사, 콘텐츠 검사, 파일/패턴 매칭을 보조합니다.
• SoC5 / NP7Lite 계열 — [SoC-Centric Hybrid] 네트워크 처리와 inspection 가속기가 같은 패키지 안에 결합되어 branch 모델의 전력과 지연을 줄입니다.

FortiGate 제품군별 ASIC 세대 및 공식 성능

다음 표는 공식 데이터시트에서 확인한 ASIC 세대와 주요 성능 수치입니다. F-series는 NP7+CP9(일부 고급형은 CP10), E-series와 7000E 섀시는 NP6+CP9, G-series 브랜치는 SoC5/SP5(NP7Lite) 기반이며, 데이터센터급 G 시리즈(400G/3500G/700G/900G)는 NP7Lite가 아닌 풀 NP7+CP10을 사용합니다.

* Hyperscale Firewall License 적용 시 확장 세션 수입니다. FW = IPv4 Firewall Throughput (1518/512/64 byte UDP 최대값), IPsec = IPsec VPN Throughput, SSL Inspection = SSL Inspection Throughput, NGFW = NGFW Throughput, Threat = Threat Protection Throughput. 출처: 각 모델별 FortiGate 공식 데이터시트.

→ 전 벤더 교차 비교: Fortinet 하드웨어 스펙 종합표 (급·상태·CPU·RAM 포함)

SP5 Security Processing Unit과 FortiGate G 시리즈

Fortinet의 SP5(Security Processing Unit 5)는 SoC(System-on-Chip) 형태의 5세대 보안 처리 장치로, 네트워크 처리와 콘텐츠 처리를 단일 다이(die)에 통합하고 두 개의 ARM CPU 코어를 내장합니다. SP5는 FortiGate G 시리즈 방화벽의 핵심 프로세서이며, 기존 SoC4/SP4 세대(100F~200F, 40F~80F 계열)를 계승합니다. SP5 내부에는 NP7Lite(경량화된 네트워크 프로세서)가 포함되어 있어, 별도 NP7 ASIC 없이도 L4 세션 fast-path 오프로드를 수행합니다.

Fortinet 공식 백서에 따르면, 커스텀 ASIC은 범용 CPU 대비 방화벽 성능 8배, 위협 방지 9배, 암호화 4배의 성능을 제공하며, 최대 88% 적은 전력을 소비합니다. 이는 ASIC이 범용 명령어 파이프라인 대신 보안 처리에 특화된 고정 기능(fixed-function) 하드웨어 블록을 사용하기 때문입니다.

FortiSP5 발표 상세 (2023년 2월)

Fortinet은 2023년 2월 6일 5세대 보안 처리 장치인 FortiSP5를 공식 발표했습니다 (공식 보도자료). SP5는 7nm 공정의 SoC(System-on-Chip) 형태로, 네트워크 처리와 보안 검사 기능을 단일 다이(die)에 통합하고 내장 멀티코어 ARM CPU를 포함합니다. 20년 이상의 ASIC 투자를 누적한 5세대 설계로, 기존 SoC4/SP4 세대를 계승합니다.

SP5 칩 자체의 절대 성능 수치는 ServeTheHome 분석에서 확인됩니다 (ServeTheHome: Fortinet FortiSP5 ASIC Launched):

SP5는 다음 하드웨어 기능을 칩 내부에 통합했습니다:

• Secure boot — 승인된 운영체제만 부팅하여 악의적 변조로부터 보호
• Volumetric DDoS protection — 하드웨어 수준 DDoS 공격 방어
• VXLAN/GRE 하드웨어 가속 캡슐화 — 분산 네트워크 간 보안 연결
• 하드웨어 가속 QoS — 화상회의 등 민감 애플리케이션 전용 QoS

SP5가 지원하는 핵심 사용 사례는 Branch/Campus(SD-Branch 전환, Secure SD-WAN), Edge Compute(상용·OT 환경 고속 네트워크 보안), OT(IT·OT 통합 보안), 5G(엔터프라이즈 5G 도입 최적화)입니다. SP5는 2023년 후반 출시된 차세대 엔트리·미드레인지 FortiGate 방화벽(G 시리즈)의 핵심 프로세서로 사용됩니다.

FortiASIC 3-엔진 아키텍처

Fortinet의 커스텀 ASIC 전략은 세 가지 특화 엔진을 제품군별로 조합하는 것입니다. 각 엔진은 서로 다른 처리 계층을 담당하며, 이 조합이 제품의 성능·전력·비용 균형을 결정합니다:

FortiSP6: Intel 파운드리 협력 발표 (2026년 7월)

Fortinet은 2026년 7월 21일 Intel과의 전략적 협력을 통해 6세대 보안 프로세서인 FortiSP6(SP6)을 공동 개발한다고 발표했습니다 (Fortinet 공식 보도자료, Intel 공식 보도자료). SP6는 SP5(7nm)의 후속 세대로, Intel 4 공정에서 설계·패키징·제조됩니다.

이 협력의 핵심 내용은 다음과 같습니다:

• Intel 4 공정 — Intel이 처음으로 EUV(Extreme Ultraviolet) 리소그래피를 도입한 공정 노드. 2023년 9월 Fab 34에서 양산을 시작했으며, 기존에는 Meteor Lake 컴퓨트 타일 내부용으로만 사용되었습니다. Fortinet은 Intel 4의 첫 공개 외부 파운드리 고객입니다.
• 역할 분담 — Fortinet은 보안 프로세서 설계 전문성(20년 이상 ASIC 투자)을 제공하고, Intel은 첨단 설계 툴, 어드밴스드 패키징, 파운드리 제조 역할을 담당합니다.
• 공급망 다변화 — Fortinet의 글로벌 반도체 공급망을 다각화하고 강화하는 것이 협력의 주요 목표 중 하나입니다. 단일 파운드리 의존도를 낮추고 지리적 리스크를 분산합니다.
• ASIC 로드맵 가속 — 양사는 반도체 기술 및 제조 분야에서 추가 협력 기회를 탐색할 예정이며, Fortinet의 ASIC 로드맵 전반을 가속하는 것을 목표로 합니다.

FortiOS 7.6 / 8.0 주요 기능

ForthiOS 7.6은 SP5/NP7/CP9/CP10 커스텀 ASIC과 synergy를 이루도록 최적화된 운영체제입니다. FortiOS 8.0은 7.6의 후속으로 G 시리즈와 F 시리즈 고급형에서 지원됩니다.

NP7 세션 오프로드 프로세스

FortiGate에서 세션이 NP7으로 오프로드되는 과정:

1. 첫 패킷: CPU(IPS Engine)가 수신 → conntrack + UTM(IPS/AV/App Control) 전체 검사
2. 세션 수립: 검사 통과 시 FortiOS 내부 세션 필터가 오프로드 가능 여부를 판단합니다
3. NP7 등록: 조건 만족 시 NP7 Session Table에 5-tuple + NAT 정보 + QoS 태그를 기록합니다
4. 후속 패킷: NP7 ASIC이 Session Table lookup → NAT rewrite → QoS → forwarding (CPU bypass)
5. 세션 종료: TCP FIN/RST → NP7이 CPU에 알림 → Session Table 삭제 → 통계 동기화

# FortiGate 진단 명령
diagnose npu np7 session-stats         # NP7 오프로드 세션 통계
diagnose npu np7 sse-stats all         # Session Search Engine 통계
diagnose npu np7 port-list             # NP7 포트 매핑 확인
diagnose sys session filter dport 443  # 특정 포트 세션 확인
get system performance firewall statistics # 전체 성능 통계

# NP7 오프로드 비율 확인
diagnose npu np7 session-stats
# 출력 예:
# NP7 offload sessions: 1,234,567
# CPU sessions: 12,345
# Offload ratio: 99.0%

# 특정 세션의 오프로드 상태 확인
diagnose sys session filter src 10.0.0.1
diagnose sys session list
# 출력에서 npu_state=offloaded 확인

NP7 HPE(Host Protection Engine)와 FortiOS 8.0 신기능

FortiOS 8.0 하드웨어 가속 문서에서 확인된 NP7 추가 기능입니다. 이 기능들은 NP7이 세션 오프로드뿐 아니라 CPU 보호와 정책 오프로드 역할도 수행함을 보여줍니다.

Fortinet 보안 프로세서/SoC inspection 경로

Fortinet 공개 자료는 제품군에 따라 CP9/CP10, SoC5, 보안 프로세서 등 서로 다른 명칭을 사용합니다. 공통점은 세션 전달용 NP fast path와 별도의 inspection 암호화 경로가 존재하는 점입니다. CPU가 TLS 정책과 평문 검사를 총괄하되, 핸드셰이크와 레코드 암·복호화의 상당 부분을 이 inspection 경로가 보조합니다.

Fortinet SSL Deep Inspection 파이프라인

FortiGate가 SSL Deep Inspection(SSL 딥 인스펙션)을 수행할 때의 내부 패킷 흐름입니다:

1. 클라이언트 → FortiGate TLS 핸드셰이크: inspection 경로가 ECDHE/RSA 키 교환을 보조하고, FortiGate의 CA 인증서로 서버 인증서를 동적 생성하여 클라이언트에 제공합니다.
2. FortiGate → 서버 TLS 핸드셰이크: inspection 경로가 실제 서버와 별도의 TLS 세션을 수립하고 서버 인증서를 검증합니다.
3. 데이터 복호화: inspection 경로가 클라이언트 TLS 세션의 레코드를 하드웨어에서 복호화하고, 평문을 CPU(IPS 엔진)에 전달합니다.
4. DPI/IPS 검사: CPU + CP 계열 가속기가 평문에 대해 App Control, IPS 시그니처 매칭, AV 스캔, DLP를 수행합니다.
5. 재암호화: inspection 경로가 서버 TLS 세션용 레코드로 재암호화하고, 이후 패킷이 NP로 전달됩니다.

# FortiGate SSL Inspection 진단 명령
diagnose sys session filter proto 6 dport 443
diagnose sys session list
# 출력에서 확인할 항목:
# npu_state=0 (SSL Inspection 세션은 offload 안 됨)
# ssl_action=deep-inspection
# ssl_cipher=ECDHE-RSA-AES256-GCM-SHA384

# SSL Inspection 통계
get system performance firewall statistics
# SSL proxy 관련 카운터와 전체 처리량은 FortiOS/모델별 출력 항목 확인

# SSL Inspection 정책 설정
config firewall ssl-ssh-profile
  edit "deep-inspect"
    set ssl-anomaly-log enable
    config https
      set ports 443
      set status deep-inspection
      set cert-validation-timeout 30
    end
  next
end

# NP7 오프로드와 SSL inspection 경로 분리 확인
diagnose npu np7 session-stats
# 비-SSL fast path 세션은 NP7 카운터에서 증가하고, deep-inspection 세션은 session list에서 별도 확인

NP7의 IPSec 암호화 처리 상세

NP7은 IPSec VPN 트래픽에 대해 ESP 패킷의 전체 처리(캡슐화(Encapsulation) + 암호화 + 포워딩)를 하드웨어에서 수행합니다:

FortiOS 8.0 G 시리즈 (2026년 신규 라인업)

Fortinet Accelerate 2026에서 발표된 FortiGate G 시리즈는 NP7/SP5 기반의 기존 F 시리즈를 계승하는 next-generation 라인입니다. 주요 제품은 FortiGate 3500G, FortiGate 400G로, FortiOS 8.0에 최적화된 AI-driven security features와 향상된 throughput을 갖춥니다. 2026년 5월 공식 발표 자료에서 확인된 구체 수치는 아래 표와 같습니다.

Security Compute Rating 경쟁사 비교 (2026년)

Fortinet은 2026년 G 시리즈 발표 시 Security Compute Rating이라는 자체 벤치마크 지표로 경쟁사 제품과의 비교 수치를 공개했습니다 (공식 보도자료). 이 비교는 Fortinet이 자체 선정한 경쟁 모델을 기준으로 하므로, 독립적인 RFC 9411 방법론 검증이 권장됩니다.

Palo Alto Networks SP3

Palo Alto Networks의 공개 자료는 Single-Pass Architecture의 핵심을 분리된 control plane/data plane, 병렬 처리 하드웨어, single-pass 소프트웨어로 설명합니다. (본 문서에서는 이를 편의상 SP3로 약칭합니다 — Palo Alto 공식 용어는 "Single-Pass Architecture" / "single pass"이며, "SP3"나 "Single-Pass Parallel Processing"은 Palo Alto 교육 자료(PCNSE Study Guide 등)에서 사용하는 명칭이나, 데이터시트에서는 Single-Pass Architecture로 표기합니다.) 따라서 세션 fast path는 장비 내부 dataplane hardware가 inline으로 처리하지만, SSL/TLS 복호화와 평문 검사는 Fortinet이나 Juniper처럼 분리된 전용 SSL ASIC보다 dataplane CPU 자원에 밀착된 CPU중심 lookaside로 해석하는 편이 정확합니다. 다시 말해, 세션 분류는 inline이고 decryption은 single-pass 파이프라인 안에서 CPU가 소화합니다:

• Single-Pass Parallel Processing — [Inline CPU] 패킷이 한 번의 통과로 FW, App-ID, IPS, URL 필터링을 병렬 처리
• NPC (Network Processing Card) — 고성능 모델에 추가 가능한 데이터 플레인 카드
• Dataplane packet-processing hardware — [Inline] 세션 테이블 lookup, NAT rewrite, 포워딩을 모델별 dataplane에서 가속
• Dataplane CPU 코어에서 App-ID/DPI/decryption을 처리하고, packet-processing 하드웨어가 세션 분류와 패킷 전달을 보조합니다.

Single-Pass 아키텍처 상세

Palo Alto의 핵심 차별점은 Single-Pass Parallel Processing (SP3) 아키텍처입니다:

Packet-processing hardware의 역할: 공개 자료 수준에서는 세션 분류, 포워딩, NAT, dataplane 병렬 처리를 보조하는 하드웨어로 해석하는 것이 안전합니다. App-ID, Threat Prevention, SSL Forward Proxy는 single-pass dataplane 소프트웨어와 CPU 자원을 사용하므로, 검사 대상 세션이 CPU를 완전히 bypass한다고 단정하면 안 됩니다.

App-ID 4단계 식별 기법

Palo Alto의 App-ID는 최대 4단계 기법을 순차적으로 적용하여 애플리케이션을 식별합니다. 이 4단계가 Single-Pass 파이프라인 안에서 수행되며, 각 단계가 CPU 비용을 발생시키는 지점입니다. App-ID Tech Brief에 따르면 주평균 5개의 새 애플리케이션이 추가됩니다.

Palo Alto SSL 복호화 아키텍처

Palo Alto 공개 자료에서 SSL Forward Proxy는 클라이언트-방화벽, 방화벽-서버의 두 TLS 세션을 만들고 보안 정책과 decryption profile을 적용하는 방식입니다. 독립 SSL ASIC 명칭이 공개되어 있지 않으므로, SSL 복호화 성능은 dataplane CPU, 모델별 하드웨어, 정책 프로필이 결합된 결과로 보는 편이 정확합니다.

Palo Alto의 접근법은 Fortinet처럼 NP/CP/SoC 계열 가속기를 강하게 전면화하는 방식과 다릅니다. 장점: single-pass 정책 처리와 PAN-OS 기능 통합이 명확합니다. 주의점: SSL 활성화 시 처리량은 모델별 SSL decryption 데이터시트와 실제 decryption profile 조건으로 별도 확인해야 합니다.

# Palo Alto SSL 복호화 진단 명령
show counter global filter delta yes | match ssl
# ssl_proxy_session_new: 연결/초 (CPS)
# ssl_proxy_session_active: 현재 활성 SSL 세션
# ssl_decrypt_success: 복호화 성공 패킷
# ssl_decrypt_fail: 복호화 실패 (cipher 미지원 등)
# ssl_cert_verify_fail: 인증서 검증 실패

show session all filter ssl-decrypt yes
# SSL 복호화 중인 세션 목록

show system resources
# CPU 사용률 확인 → SSL 활성 시 증가폭

# SSL 복호화 정책 설정 (PAN-OS)
set rulebase decryption rules "decrypt-outbound" {
    from any; to any;
    source any; destination any;
    service any; action decrypt;
    type { ssl-forward-proxy { }; };
    profile "default";
}

# SSL 복호화 프로파일
set profiles decryption "strict" {
    ssl-forward-proxy {
        block-expired-certificate yes;
        block-untrusted-issuer yes;
        block-unsupported-version yes;
        block-unsupported-cipher yes;
        min-version tls1-2;
    };
}

# Palo Alto CLI 진단 명령
show running resource-monitor           # CPU/메모리/세션 사용률
show session all filter state active    # 활성 세션 목록
show session info                       # 세션 통계 (CPS, CC)
show counter global filter delta yes \
  packet-filter yes                     # 실시간 카운터
debug dataplane packet-diag set filter \
  match src 10.0.0.1                    # 특정 IP 패킷 추적

Palo Alto 제품군별 공식 성능 수치

다음 표는 공식 데이터시트에서 확인한 주요 모델의 성능 수치입니다. 측정 조건이 모델마다 다르므로 단순 순위 비교보다 조건별 해석이 필요합니다.

출처: PA-5400-Series-Datasheet, PA-5450-Datasheet, PA-5500-Series-Datasheet (PAN-OS 12.1 측정), PA-7000-Series-Datasheet, PA-7500-Datasheet (Palo Alto Networks 공식 데이터시트). 측정 기준: FW = Firewall throughput (appmix transactions, App-ID + logging enabled). Threat Prevention = App-ID + IPS + antivirus + antispyware + WildFire + file blocking + logging (appmix transactions). IPsec VPN = 64 KB HTTP transactions + logging. 동시 세션 = HTTP transactions. CPS = application override, 1 byte HTTP transactions. PA-5500 시리즈의 IPsec VPN(80~170 Gbps)·Threat Prevention(90~300 Gbps)·동시 세션(39~99M)·CPS(1.33~3.3M) 수치는 PA-5500-Series 공식 데이터시트 Table 1에서 확인된 값입니다. 모든 Palo Alto 데이터시트는 SSL decryption throughput을 별도 수치로 공개하지 않습니다.

→ 전 벤더 교차 비교: Palo Alto 하드웨어 스펙 종합표 (급·상태·CPU·RAM 포함)

PA-7500 Series 모듈형 아키텍처

PA-7500는 Palo Alto의 최상위 모듈형 섀시 방화벽으로, 9개 전면 슬롯과 2개 후면 슬롯으로 구성됩니다. 최소 1개의 MPC, NPC, DPC가 필요하며, 최대 6개 DPC + 2개 NPC 구성에서 FW 1,500 Gbps, Threat Prevention 1,440 Gbps, IPsec VPN 407 Gbps를 달성합니다.

PA-5500 Series: 양자 후 암호(PQC) 대응

PA-5500 시리즈는 Palo Alto Networks의 양자 후 암호(Post-Quantum Cryptography, PQC) 준비 NGFW 라인업입니다. FE-400 ASIC을 탑재하여 고처리량·저지연 데이터 플레인을 제공하며, PAN-OS 12.1부터 NIST 표준 PQC 알고리즘을 하드웨어·소프트웨어 수준에서 지원합니다. PA-7500도 동일한 FE-400 ASIC을 사용하므로, PA-5500 시리즈는 PA-7500의 PQC 기능을 고정 폼팩터(3U)로 제공하는 라인업으로 볼 수 있습니다.

PA-5500 시리즈가 지원하는 PQC 알고리즘은 다음과 같습니다:

Check Point SecureXL / Maestro

Check Point는 SecureXL/CoreXL 중심의 소프트웨어 기반 inline 가속 아키텍처를 사용합니다. 일부 제품군은 Lightspeed 계열 가속으로 L4 방화벽 fast path를 강화하지만, 공개 자료 기준으로 범용 HTTPS Inspection의 TLS 레코드 처리까지 전용 SSL ASIC이 대신한다고 보기는 어렵습니다. 따라서 HTTPS Inspection은 CPU/CoreXL 중심 경로로 분류하는 편이 안전합니다:

• SecureXL — [Inline 커널] 커널 레벨 가속. Accept Template(ESTABLISHED 세션 direct forward)과 Drop Template(미리 차단 목록)으로 CPU 부하를 줄입니다.
• CoreXL — [Inline CPU] 멀티코어 병렬 처리. SND(Secure Network Distributor)가 RSS처럼 코어 간 패킷을 분배합니다.
• Maestro HyperScale — 여러 Security Gateway를 하나의 논리 장비로 클러스터링하여 수평 확장
• SSL/IPSec — [CPU/CoreXL 중심] 범용 CPU AES-NI와 SecureXL/CoreXL 경로로 처리합니다. 모델별 가속 카드가 있더라도 HTTPS Inspection 성능은 공식 데이터시트와 실제 프로필 조건으로 확인해야 합니다.

SecureXL 처리 경로 상세

SecureXL은 3가지 처리 경로(Accelerated Path, Medium Path, Firewall Path)로 패킷을 분류합니다:

Accept Template은 Linux conntrack의 ESTABLISHED + flowtable 개념과 유사합니다. conntrack이 세션 상태를 추적하고, Accept Template이 검사가 완료된 세션의 5-tuple을 커널 가속 테이블에 등록합니다. Drop Template은 이미 DROP 판정이 난 소스 IP/포트를 캐시하여, 동일한 악성 트래픽이 재전송(Retransmission)될 때 CPU까지 가지 않고 즉시 DROP합니다.

CoreXL / SND 아키텍처

Check Point의 멀티코어 아키텍처는 Linux의 RSS/RPS와 유사하지만 보안에 최적화되어 있습니다:

• SND (Secure Network Distributor) — 전용 코어가 NIC에서 패킷을 수신하여 CoreXL 인스턴스에 분배. CPU affinity 기반으로 세션을 고정 코어에 할당
• CoreXL FW Instance — 각 코어가 독립적인 FW 인스턴스를 실행. 세션 테이블은 공유하되, 처리는 병렬
• Multi-Queue — SND가 NIC의 RSS 큐를 활용하여 하드웨어 수준 분산

# Check Point 진단 명령 (Gaia OS)
fwaccel stat                            # SecureXL 가속 통계
fwaccel stats -s                        # 경로별 패킷/바이트 통계
fwaccel conns                           # Accept Template 연결 수
fw ctl multik stat                      # CoreXL 인스턴스별 통계
cpview                                  # 실시간 성능 모니터 (TUI)

# SecureXL 비활성화/활성화 (성능 비교 테스트)
fwaccel off     # 가속 비활성화 → 전체 Firewall Path
fwaccel on      # 가속 재활성화

# 특정 세션의 처리 경로 확인
fw ctl zdebug + drop    # 디버그 로그

Check Point HTTPS Inspection 아키텍처

Check Point는 Fortinet(CP/SoC inspection 경로)이나 전용 크립토 ASIC 없이 순수 소프트웨어 기반의 HTTPS Inspection을 수행합니다. CoreXL의 멀티코어 병렬 처리와 SecureXL의 가속 경로를 조합하여 성능을 최적화합니다.

SecureXL과 HTTPS Inspection의 관계: HTTPS Inspection이 활성화되면 해당 세션은 Firewall Path(가장 느린 경로)에서 처리됩니다. Accelerated Path로 승격될 수 없으므로, HTTPS Inspection 비율이 높을수록 SecureXL 가속 효과가 감소합니다.

# Check Point HTTPS Inspection 진단
fwaccel stat
# Accelerated Conns: 1,200,000
# HTTPS Inspect Conns: 45,000 (Firewall Path)
# → HTTPS Inspection 세션은 Accelerated Path 불가

# HTTPS Inspection 통계
cpstat -f https_inspection fw
# Total inspected connections: 45,000
# Bypassed connections: 5,000 (bypass 규칙 적용)
# Certificate cache hit ratio: 85%

# CoreXL 인스턴스별 SSL 부하 분포
fw ctl multik stat
# 각 CoreXL 인스턴스의 CPU 사용률 확인
# HTTPS Inspection 활성 시 불균형 주의

# HTTPS Inspection 바이패스 규칙 (성능 최적화)
# SmartConsole → Security Policies → HTTPS Inspection
# 금융/의료 사이트, Windows Update 등 → Bypass 권장

Check Point 제품군별 공식 성능 수치

다음 표는 Check Point 공식 데이터시트에서 확인한 주요 모델의 성능 수치입니다. Quantum 28000의 이전 수치가 일부 자료에서 64/15/7 Gbps로 인용되었으나, 2024년 7월 기준 공식 데이터시트는 FW 145 Gbps / NGFW 51.5 Gbps / Threat Prevention 30 Gbps / IPS 52.2 Gbps / VPN AES-128 49 Gbps를 제시합니다. SSL/HTTPS Inspection 처리량은 28000 데이터시트에 별도 수치로 공개되어 있지 않습니다.

출처: Check Point Quantum 28000 Security Gateway Datasheet (2024-07), Quantum 3200/6400 Datasheet, Quantum Force Appliance Comparison Chart (checkpoint.com). Quantum Force 29200의 Threat Prevention은 제품 페이지 헤드라인 75 Gbps가 아닌 공식 데이터시트 기준 63.5 Gbps를 표기했습니다. Quantum Force 19100~29200의 HTTP/TLS Inspection Threat Prevention 수치는 각각 14.1/18.6/24.3/24.6 Gbps로 공개되어 있어, 이 시리즈에서만 SSL Inspection 성능 수치가 확인됩니다. Quantum 28000은 SSL Inspection 수치를 별도로 공개하지 않습니다.

→ 전 벤더 교차 비교: Check Point 하드웨어 스펙 종합표 (급·상태·CPU·RAM 포함)

Juniper Express Path

Juniper SRX 시리즈의 Express Path는 fast-path 패킷을 flow daemon이 아닌 network processor 경로에서 처리하도록 설계된 가속 기능입니다. SRX5000 계열은 NP/PFE 기반 전달 경로와 SPC(Service Processing Card) 서비스 경로를 조합합니다. IPSec, SSL Proxy, UTM 처리는 플랫폼·카드·라이선스·정책에 따라 서비스 처리 경로를 사용하므로, 모든 SSL 암호화가 SPC3의 특정 엔진에서 전담된다고 단정하면 안 됩니다:

• Express Path — [Inline] 확립된 세션의 패킷을 flowd를 bypass하여 NP에서 forwarding
• Services Processing Card / SPU 경로 — [Service path] IPSec, SSL Proxy, UTM 같은 서비스 처리를 담당합니다. 실제 암호화 가속 범위와 처리량은 카드·Junos 버전·기능 조합별 공식 문서로 확인해야 합니다.

Express Path 동작 원리

Juniper SRX의 패킷 처리 아키텍처:

1. NP (Network Processor): 모든 패킷의 1차 수신. 세션 테이블에서 lookup
2. Express Path 히트: 기존 세션 매칭 → NP에서 직접 forwarding + NAT rewrite (flowd bypass)
3. Express Path 미스: 새 세션 → flowd(flow daemon)로 전달 → 정책 평가 + IPS/AppID
4. 세션 설치: flowd가 정책 통과 시 세션을 NP Express Path 테이블에 등록

# Juniper SRX 진단 명령
show security flow statistics           # 플로우 통계 (Express Path 비율)
show security monitoring fpc 0          # FPC별 세션/처리량
show security flow session              # 세션 테이블
show security flow session summary      # 세션 요약 (활성/최대)

# Express Path 상태 확인
show pfe statistics traffic
# express-path-packets, slow-path-packets 비교

# Services Offload Engine 상태
show chassis fpc pic-status

SPC3 (Services Processing Card) 암호화 가속

Juniper SRX 5000 시리즈는 SPC3 같은 서비스 카드를 통해 보안 서비스 처리 용량을 확장합니다. 공개 문서는 SRX5800 섀시, SPC3 카드, Express Path, Inline IPsec, SSL Proxy 기능을 각각 설명하지만, 카드 내부 crypto engine별 TLS CPS나 인증서 캐시 구조를 일관된 공개 수치로 제공하지 않습니다.

# Juniper SRX SPC3 암호화 관련 진단
show security ipsec statistics
# ESP 암·복호화 패킷/바이트 통계

show security ipsec sa
# SA 목록 + 하드웨어 가속 여부

show services ssl proxy statistics
# SSL Proxy 세션 수, CPS, 처리량

show chassis fpc 0 pic 0
# SPC3 카드 상태 + 크립토 엔진 사용률

# SPC3 IPSec 오프로드 설정
set security ipsec vpn site-a {
    ike {
        gateway gw-site-a;
        ipsec-policy ipsec-pol;
    }
    establish-tunnels immediately;
}
# SPC3가 자동으로 IPSec 처리를 하드웨어에서 수행

SPC3 SSL Forward Proxy 핸드셰이크 처리

Juniper SRX의 SSL Forward Proxy는 클라이언트 측 TLS 세션과 서버 측 TLS 세션을 분리하여 복호화, 보안 검사, 재암호화를 수행합니다. 이 처리는 Express Path의 단순 fast-path 전달과 다른 서비스 처리 경로이며, SPC/SPU 자원과 flowd 정책 처리, 지원 cipher/group 조건이 함께 영향을 줍니다.

Juniper SRX 제품군별 공식 성능 수치

다음 표는 Juniper 공식 데이터시트에서 확인한 SRX5000 시리즈 섀시 성능 수치입니다. SPC3는 Services Processing Card로, 두 개의 SPU(Services Processing Unit)와 SPU당 128GB 메모리를 제공하며 방화벽/IPsec/IDP 서비스를 처리합니다. SPC3 카드 자체의 per-card Gbps 처리량은 공식 문서에 별도로 공개되어 있지 않으므로 섀시 단위 수치를 참조해야 합니다.

출처: SRX5400/SRX5600/SRX5800 Firewall Datasheet, SRX5000 Cards Reference (juniper.net). SRX5800의 Express Path + IOC3 조합에서 방화벽 처리량은 최대 2 Tbps로 별도 언급되나, 섀시 전체 최대 FW 처리량(IMIX)은 3.36 Tbps입니다. IPSec VPN AES-256-GCM 699 Gbps는 SRX5800 섀시 단위 수치이며, SPC3 카드 단위 수치는 공식 문서에서 별도로 공개되지 않습니다.

→ 전 벤더 교차 비교: Juniper SRX 하드웨어 스펙 종합표 (급·상태·CPU·RAM 포함)

Cisco Secure Firewall 4200 / FTD / Snort 3

Cisco Secure Firewall 계열은 ASA 계열의 stateful firewall 처리(LINA), FTD(Threat Defense) 정책 처리, Snort 3 DPI 엔진, crypto accelerator, flow offload를 결합합니다. 4200 Series 공식 데이터시트는 multi-threaded Snort 3 engine, cryptographic acceleration architecture, TLS hardware decryption, 최대 16-node cluster, 400G interface option을 공개합니다. 따라서 Cisco의 고성능 구조는 "모든 패킷을 Snort로 보냅니다"가 아니라, 먼저 L3/L4에서 fast path/offload 가능성을 판정하고, 복호화가 필요한 TLS/VPN 비용을 crypto accelerator로 낮춘 뒤, 실제 위협 판단은 Snort 3 worker에 병렬 분산하는 방식으로 이해해야 합니다.

Cisco Secure Firewall 4200 제품군 비교

Cisco Secure Firewall 4200 Series는 4215, 4225, 4245 세 모델로 구성됩니다. 다음 표는 공식 데이터시트의 주요 수치입니다.

출처: Cisco Secure Firewall 4200 Datasheet. FW = Stateful Multiprotocol throughput. NGFW = FW + App + IPS. TLS HW Decryption 측정 조건: 50% TLS 1.2 traffic with AES256-SHA with RSA 2048B keys. 기존 Firepower 4100 Series(4110~4145)는 2026년 1월 6일 주문 마감(End of Sale) 예정이며 4200 Series가 권장 대체 모델입니다.

Sophos XGS / Xstream FastPath

Sophos XGS 계열은 Fortinet의 NP/CP 조합이나 Palo Alto의 섀시형 NPC/DPC 구조와 달리, multi-core x86 CPU와 Xstream Flow Processor를 결합한 dual-processor appliance 구조입니다. Sophos Firewall 21.5 공식 문서는 데이터 경로를 SlowPath, DPI Engine, offload module, FastPath로 나누어 설명합니다. 핵심은 첫 패킷과 보안 판정은 CPU/SlowPath/DPI Engine이 수행하고, 신뢰된 후속 흐름과 일부 crypto 작업만 FastPath/Xstream Flow Processor로 넘겨 CPU를 절약하는 방식입니다.

XGS 8500 공식 성능 수치와 조건

Sophos XGS 2U 공식 페이지의 XGS 8500 수치는 다음과 같습니다. 이 수치는 vendor datasheet 조건이므로, Fortinet/Palo Alto/Check Point/Juniper/Cisco 수치와 직접 순위 비교하지 않고 조건별로 분리해 봐야 합니다.

Sophos XGS 2U/1U 제품군별 공식 성능 수치

다음 표는 Sophos 공식 브로셔(2025)에서 확인한 XGS 2U/1U 제품군의 성능 수치입니다. XGS 8500의 동시 세션 5,800만, CPS 170만, IPsec VPN 터널 15,000, SSL VPN 터널 24,000, Xstream SSL/TLS 동시 연결 250만이 공식 수치로 확인됩니다.

출처: Sophos Firewall Brochure 2025, Sophos Firewall Datasheet (2024-09-26), Operating Instructions XGS 7500/8500. XGS 8500 Main CPU 64/128 cores, 256GB DDR4 ECC 3200; NPU 36 cores, 24GB DDR4 2667 ECC; 2×960GB NVMe (HW RAID). XGS 7500 QSFP28는 40G까지만 지원하며 8500는 100G까지 지원합니다.

→ 전 벤더 교차 비교: Sophos XGS 하드웨어 스펙 종합표 (급·상태·CPU·RAM 포함)

Sophos 오프로드 결정 흐름

1. 초기 수신: 패킷이 XGS 포트로 들어오면 SlowPath의 firewall stack과 user space module이 세션 상태, 정책, NAT, 라우팅을 평가합니다.
2. 보안 검사 필요성 판단: 웹/앱/IPS/TLS/멀웨어 검사가 필요한 흐름은 DPI Engine으로 전달됩니다. DPI Engine은 DAQ 계층을 통해 stream을 받고, 보안 판정과 offload 가능성을 결정합니다.
3. Firewall acceleration: 초기 패킷 검사 후 신뢰된 흐름은 FastPath로 넘어가며, FastPath는 매 패킷마다 전체 firewall processing을 반복하지 않도록 stateful tracking으로 처리합니다.
4. PKI acceleration: TLS Inspection에서 X.509 서버 인증서를 재서명해야 하는 qualifying flow는 Xstream Flow Processor의 crypto hardware로 PKI 작업을 넘길 수 있습니다. 공식 문서가 명시한 항목은 certificate re-signing이며, inspected TLS flow의 AES-GCM 레코드 전체가 NPU에서 line-rate로 처리된다고 확대 해석하면 안 됩니다.
5. IPsec acceleration: XFRM stack이 Phase 2 SA를 기준으로 FastPath에 IPsec encryption/decryption offload를 지시합니다. 3DES, Blowfish, MD5 조합은 offload 대상에서 제외됩니다.
6. Fallback: FastPath가 처리할 수 없는 프로토콜과 조건은 SlowPath로 남습니다. 공식 문서는 IP in IP 같은 미지원 프로토콜, SSL VPN, proxies/WAF, QoS/DoS, wireless/RED/LAG/PPPoE, IP fragmentation, packet capture 등을 제한 조건으로 제시합니다.

Sophos FastPath/PKI/IPsec 확인 명령

# Firewall acceleration 상태 확인 및 제어
system firewall-acceleration show
system firewall-acceleration enable
system firewall-acceleration disable

# PKI acceleration은 IPS/DPI 설정에 속합니다.
show ips-settings
set ips pki-acceleration enable
set ips pki-acceleration disable

# IPsec SA offload 상태 확인 및 제어
system ipsec-acceleration show
system ipsec-acceleration enable
system ipsec-acceleration disable

F5 BIG-IP ASM/AF

F5 Networks의 BIG-IP 플랫폼은 TMOS(Traffic Management Operating System) 기반의 ADC(Application Delivery Controller)와 보안 기능을 통합한 장비입니다. 다른 NGFW 벤더가 L3~L7 전 스택의 수평적 보안 처리에 집중하는 반면, F5는 L7 애플리케이션 계층에서의 보안 정확도와 제어력을 핵심 차별점으로 삼습니다. BIG-IP는 WAF(Web Application Firewall), AFM(Advanced Firewall Manager), APM(Access Policy Manager), SSL Orchestrator를 단일 플랫폼에서 통합 제공합니다.

TMOS 아키텍처

BIG-IP의 핵심은 TMOS(Traffic Management Operating System)입니다. TMOS는 데이터 플레인과 컨트롤 플레인을 분리하며, 데이터 플레인의 중심에는 TMM(Traffic Management Microkernel)이 있습니다. TMM은 사용자 공간(user-space)에서 동작하는 단일 프로세스로, 패킷 수신부터 송신까지 전체 데이터 경로를 관장합니다.

BIG-IP iSeries 성능

F5 BIG-IP iSeries 플랫폼은 1RU 폼팩터에서 L4/L7 처리, SSL 오프로드, 하드웨어 압축, DDoS 방어를 통합합니다. 다음 표는 i7600과 i7800의 공식 성능 수치입니다.

TurboFlex는 i7800에서 지원되는 소프트웨어 기반 성능 확장 기능으로, Tier 3 적용 시 L4/L7 처리량을 2배로 확장할 수 있습니다. 이는 하드웨어 교체 없이 라이선스 업그레이드만으로 처리량을 늘릴 수 있는 F5 특유의 모델입니다.

→ 전 벤더 교차 비교: F5 BIG-IP iSeries 하드웨어 스펙 종합표 (급·상태·CPU·RAM 포함)

BIG-IP의 NGFW 기능

F5 BIG-IP는 전통적으로 ADC 영역에서 강점을 가지지만, 다음 NGFW 기능을 모듈 형태로 제공합니다:

• AWAF (Advanced Web Application Firewall): OWASP Top 10 방어, bot management, API security, positive security model, 학습 기반 정책 자동 생성. L7 HTTP/HTTPS 트래픽의 deep packet inspection에서 업계 최고 수준의 정확도 제공
• AFM (Advanced Firewall Manager): L4/L7 방화벽, IP intelligence(위험 IP 평판), DoS 방어, NAT, 라우팅. L4 fastL4 profile로 80 Gbps 라인레이트 처리 가능
• APM (Access Policy Manager): SSL VPN, 인증·인가 (SAML, OAuth, RADIUS, LDAP), ZTNA(Zero Trust Network Access) 정책 시행
• SSL Orchestrator (SSLO): TLS 복호화 후 다중 보안 도구(IPS, DLP, WAF)로 트래픽 분배·재암호화하는 서비스 체인 오케스트레이션. F5는 이 영역에서 독보적인 기능 depth를 제공
• iRule (TCL 기반): 이벤트 구동 스크립트로 HTTP/TCP/SSL 계층에서 트래픽 검사·변형·라우팅. HTTP_REQUEST, CLIENTSSL_HANDSHAKE, SERVER_CONNECTED 등 이벤트에서 콜백 실행

SSL Orchestrator와 서비스 체인

F5 BIG-IP의 SSL Orchestrator(SSLO)는 NGFW 환경에서 F5만의 차별적 기능입니다. 단순한 TLS MITM 복호화를 넘어, 복호화된 평문 트래픽을 다수의 보안 도구(IPS, DLP, WAF, 포렌식)로 분배하고, 각 도구의 검사 완료 후 재암호화하는 서비스 체인(service chain)을 구성합니다. 이는 단일 NGFW 장비 내부에서 DPI를 수행하는 다른 벤더와 달리, 외부 보안 도구 생태계를 오케스트레이션하는 접근 방식입니다.

벤더별 오프로드 아키텍처 세대별 변천사

상용 NGFW 벤더들은 암호화 트래픽 증가와 DPI(Deep Packet Inspection) 연산 비용을 감당하기 위해 각자의 하드웨어(H/W) 및 소프트웨어(S/W) 오프로드 아키텍처를 세대별로 발전시켜 왔습니다. 본 절에서는 7개 주요 벤더의 오프로드 아키텍처 변천사를 세대별로 정리하고, 각 세대가 해결한 문제(의미), 장점, 그리고 남은 한계를 종합합니다.

Fortinet — NP/CP/SoC/SP 세대별 변천사

Fortinet은 자체 설계 ASIC(FortiASIC)을 20년 이상 누적 개발한 벤더로, 오프로드 칩셋이 3개 계열로 분화되어 있습니다. [확인됨 — Intel·Fortinet 2026년 7월 21일 공동 발표, Fortinet 커뮤니티 KB]

FortiSP5의 파운드리가 TSMC 7nm였다는 점은 업계 분석 매체(ServeTheHome)에서 "추정"으로 언급한 것이며 Fortinet 공식 확인은 아닙니다 [추정]. SP6가 Intel 4에서 제조된다는 점은 Intel·Fortinet 공동 발표 및 Tom's Hardware 취재로 확인됩니다 [확인됨].

Palo Alto Networks — SP3 소프트웨어 아키텍처에서 FE-400 ASIC까지

Palo Alto는 소프트웨어 중심의 Single-Pass Parallel Processing (SP3) 아키텍처에서 출발하여, 최근 FE-400 ASIC을 통한 하드웨어 가속으로 진화했습니다. [확인됨 — Palo Alto 공식 SP3 백서, PA-5500 데이터시트]

Check Point — SecureXL 세대별 진화와 Maestro·LightSpeed

Check Point는 소프트웨어 기반 inline 가속(SecureXL)을 핵심으로 하면서, Maestro로 수평 확장, LightSpeed로 하드웨어 L4 가속을 추가하는 경로를 밟았습니다. [확인됨 — Check Point R81.20 문서, Maestro 데이터시트]

Juniper — Express Path와 SPC 세대별 진화

Juniper SRX는 RE(Routing Engine)·PFE(Packet Forwarding Engine) 분리 아키텍처에 Express Path fast path와 SPC(Service Processing Card) 서비스 경로를 조합합니다. [확인됨 — Juniper SRX 문서, 데이터시트]

Cisco — ASA/LINA에서 FTD + Snort 3 듀얼 엔진으로

Cisco는 ASA 계열의 stateful firewall(LINA)에 FTD(Threat Defense) 정책과 Snort 3 DPI 엔진, crypto accelerator를 결합하는 아키텍처로 진화했습니다. [확인됨 — Cisco Secure Firewall 4200 데이터시트]

Sophos — Xstream dual-processor와 FastPath 진화

Sophos는 x86 CPU + Xstream Flow Processor(NPU) dual-processor 구조에 SlowPath/DPI Engine/FastPath 4계층 데이터 경로를 사용합니다. [확인됨 — Sophos Firewall 19.0/21.5 문서, 공식 페이지]

F5 — TMOS 소프트웨어 아키텍처와 iSeries 하드웨어 오프로드

F5는 ADC(Application Delivery Controller)에서 출발한 NGFW 벤더로, TMOS(traffic management OS) 소프트웨어 아키텍처에 하드웨어 SSL/DDoS/압축 오프로드를 결합합니다. [확인됨 — F5 iSeries 데이터시트]

벤더별 세대별 변천 선택 이유 (Why)

각 NGFW 벤더가 세대별 아키텍처 변천을 선택한 근거와 동기를 정리합니다. 단순한 기술 나열이 아닌, "왜 그 시점에 그러한 변화를 선택했는가"를 각 벤더의 공식 발표·블로그·기술 문서에서 확인한 근거로 설명합니다.

Fortinet — 왜 20년간 자체 ASIC을 고수했는가

선택 배경: Fortinet 창업자 Ken Xie는 2000년대 초반부터 "범용 CPU로는 보안과 네트워킹의 동시 고성능을 달성할 수 없다"는 판단으로 자체 ASIC(FortiASIC) 설계를 시작했습니다. 2026년 7월 Intel 파운드리 협력 발표에서 Ken Xie는 "Fortinet의 purpose-built ASIC이 20년 이상 핵심 차별점이었다"고 명시했습니다. [확인됨 — Intel Newsroom 2026-07-21]

세대별 선택 이유:

• NP1~NP4 (2004~2012): 소프트웨어 방화벽의 L3/L4 전달 병목을 하드웨어로 해결 — 당시 범용 CPU로 10Gbps 라인레이트 방화벽 처리가 불가능했기 때문입니다. [추정/일반적 평가]
• SoC2~SoC4 (2012~2018): 소형 브랜치 장비에도 하드웨어 가속을 제공하기 위해 NP 기능을 단일 SoC로 통합 — 별도 NP 칩의 비용·전력을 절감하면서도 가속을 유지하기 위해서였습니다. [추정/일반적 평가]
• NP7 (2020~): 하이퍼스케일 데이터센터의 100Gbps 요구와 elephant flow 처리를 위해 설계 — Fortinet 공식 블로그는 "NP7은 단일 칩에서 100Gbps 데이터 흐름, 200만 CPS 세션 설정, 75Gbps IPSec 복호화를 지원하며, 하드웨어 기반 DDoS 방어와 VXLAN 종단/재기원을 수행한다"고 명시했습니다. 핵심 동기는 "기존 NGFW가 hyperscale 트래픽의 choke point가 되어 조직이 보안을 포기하는 현상"을 해결하는 것이었습니다. [확인됨 — Fortinet 블로그 "Hyperscale Security Enables The Art of What's Possible"]
• SP5 (2023): NP+CP 기능을 단일 SoC로 통합하여 중간급 장비의 전력 효율과 처리량을 동시 향상 — Fortinet은 SP5가 "범용 CPU 대비 방화벽 17x, NGFW 3.5x, 암호화 32x 성능, 88% 절전"을 달성한다고 발표했습니다. 동기는 edge에서의 SSL inspection(2.5Gbps)을 포함한 "모든 네트워크 엣지에서의 보안-네트워킹 융합"이었습니다. [확인됨 — Fortinet SP5 발표 2023-02-06]
• SP6 (2026 개발 중): Intel 4 EUV 공정으로 차세대 보안 프로세서 개발 — 동기는 "성능·서비스 풍부화·공급망 다변화"의 동시 달성입니다. TSMC 단일 파운드리 의존에서 Intel Foundry 추가로 공급망 리스크를 분산시키는 전략적 선택입니다. [확인됨 — Intel·Fortinet 공동 발표 2026-07-21]

Palo Alto — 왜 x86에서 FE-400 ASIC으로 전환했는가

선택 배경: Palo Alto는 2007년부터 "소프트웨어 우선, Single-Pass 아키텍처"로 모든 PA 모델에 x86 CPU를 사용했습니다. 그러나 데이터센터 시장의 1Tbps+ 요구에 x86 CPU로는 대응할 수 없게 되자, 2023년 11월 PAN-OS 11.1과 함께 FE-400 ASIC을 탑재한 PA-7500을 발표했습니다. [확인됨 — Palo Alto 블로그 "Testing the Limits of Firewall Performance and Flexibility" 2023-11-08]

전환 이유:

• x86의 한계: Single-Pass 아키텍처의 처리량이 CPU 코어 수에 선형 비례하므로, 1.5Tbps App-ID를 x86으로 달성하려면 수백 코어가 필요했을 것 — 전력·비용·폼팩터 현실성 없음. [추정/일반적 평가]
• FE-400의 목표: "업계 최초로 1.5Tbps App-ID 성능을 초과하는 방화벽" — 400M 동시 L7 세션, 저지연, 최대 7개 데이터 처리 카드 또는 네트워킹 카드 확장. 동기는 "multisite data center protection, CSP 가상 네트워크 분할, 5G 서비스 프로바이더 네트워크 보호"였습니다. [확인됨 — Palo Alto 블로그]
• 소프트웨어 일관성 유지: FE-400 ASIC을 도입하면서도 SP3 Single-Pass 소프트웨어 논리는 동일하게 유지 — "모든 PA 모델에서 동일한 PAN-OS"라는 일관성을 해치지 않으면서 최상위급만 하드웨어 가속. [확인됨 — PA-Series Hardware Architectures 페이지]
• PQC 대응: FE-400은 양자 후 암호(PQC)를 하드웨어·소프트웨어 수준에서 지원 — "Store Now, Decrypt Later" 위협에 대비한 선제적 선택. PA-5500 시리즈에 PCIe 확장 슬롯을 추가하여 향후 PQC 기능 확장을 예비. [확인됨 — PA-5500 데이터시트]

Check Point — 왜 커널에서 유저스페이스로, 왜 Maestro로

선택 배경: Check Point는 소프트웨어 기반 가속(SecureXL)을 핵심으로 하면서, 두 번의 주요 전환을 단행했습니다.

전환 이유:

• SecureXL KPPAK → UPPAK (R81.20): 커널 모드 가속은 성능은 뛰어나지만 커널 패닉 위험과 기능 확장 시 커널 의존성이 문제였습니다. UPPAK(유저스페이스) 전환으로: (1) 커널 분리로 안정성 향상 (2) 프로세스 독립 복구(watchdog) (3) 고급 기능 잠금 해제. 단, Active-Active/Load Sharing 클러스터 미지원이라는 트레이드오프가 있었습니다. [확인됨 — Check Point R81.20 Performance Tuning Guide]
• Maestro Hyperscale: 단일 게이트웨이의 처리량 한계를 수평 확장으로 극복 — 핵심 동기는 "기존 하드웨어 투자를 활용하면서 확장"이었습니다. 새 장비 구매 없이 Orchestrator 추가만으로 다수 게이트웨이(단일 사이트 Security Group당 최대 31개, 듀얼 사이트 기준 총 28개)를 하나의 Security Group으로 통합. 이는 "처리량을 늘리기 위해 더 큰 장비를 사라"는 전통적 방식 대신 "같은 장비를 더 많이 연결하라"는 접근입니다. [확인됨 — Maestro 데이터시트, sk147853]
• LightSpeed: NVIDIA ASIC 기반으로 L4 방화벽 fast path를 3Tbps/800Gbps, 3µs 지연으로 가속 — 초대형 데이터센터의 L4 전달 병목 해결이 목표. 단, 범용 TLS Inspection 전담은 아닌 것으로 분석됩니다. [확인됨 — sk176466, 추정 — SSL Inspection 범위]

Cisco — 왜 Snort 2에서 Snort 3로, 왜 crypto 가속을

선택 배경: Cisco는 ASA의 stateful firewall(LINA)에 FTD 이미지로 NGFW 기능을 통합하면서, DPI 엔진을 Snort 2에서 Snort 3로 전환했습니다.

전환 이유:

• Snort 2 → Snort 3: Snort 2는 단일 스레드 구조로 멀티코어 활용이 제한적이었습니다. Snort 3는 모듈식 DAQ(Data Acquisition) + flow 기반 다중 worker 스레드로 병렬 탐지를 구현 — 멀티코어 CPU(4245의 128코어/256스레드)를 최대 활용하기 위한 필수 선택이었습니다. 또한 오픈소스 Snort 커뮤니티 생태계(4000+ 앱 식별, OpenAppID)를 활용하는 전략적 이점도 있습니다. [확인됨 — Cisco 4200 데이터시트, BRKSEC-2239]
• crypto accelerator + TLS HW 복호화: 암호화 트래픽(현재 인터넷 트래픽의 90%+)의 복호화 비용을 전용 하드웨어로 낮추어 Snort 3가 평문 보안 검사에 CPU를 집중 — "Advanced FPGA + 1~4 VPN crypto HW accelerator + Flow Offload" 구조. 동기는 "TLS 복호화 없이는 보안 검사 자체가 불가능"해진 환경에서 복호화 비용을 하드웨어로 제거하는 것이었습니다. [확인됨 — BRKSEC-2239]
• 4100 → 4200: 4200 시리즈는 4100 대비 "NGFW 최대 3x, TLS 복호화 최대 5x, ASA 최대 2x" 성능 향상을 목표 — 1RU에서 180Gbps stateful/140Gbps NGFW를 달성. 동기는 "1RU 고밀도로 데이터센터 랙 공간 절약 + 400G 인터페이스 옵션으로 미래 대비"였습니다. [확인됨 — BRKSEC-2239]

Juniper — 왜 Express Path를, 왜 RE/PFE 분리를

선택 배경: Juniper SRX는 라우터(MX/T 시리즈)의 RE(Routing Engine)/PFE(Packet Forwarding Engine) 분리 아키텍처를 상속받았습니다.

선택 이유:

• RE/PFE 분리: 관리 평면(RE)과 데이터 평면(PFE/SPC)을 물리적으로 분리 — 관리 평면 장애가 데이터 평면에 영향을 주지 않도록 격리. 이는 통신사급(carrier-grade) 안정성 요구에서 비롯된 선택입니다. RE3에 Intel Haswell-EP 6코어 128GB DDR4를 사용하여 제어 평면 성능을 확보. [확인됨 — Juniper Pathfinder HCT]
• Express Path: 확립된 세션을 flowd(software flow daemon) bypass하여 NP에서 직접 forwarding + NAT rewrite — flowd의 CPU 병목을 hardware fast path로 우회. 동기는 "SRX5000 시리즈로 3.36Tbps FW 처리량을 달성하려면 소프트웨어 flowd만으로는 한계"였기 때문입니다. [확인됨 — Juniper SRX 문서]
• SPC3 카드 확장: 서비스 처리(IPSec/IDP/SSL)를 전용 카드(SPC3)로 분산 — 섀시 처리량을 카드 추가로 선형 확장. SPU당 128GB 메모리로 대규모 세션 테이블 지원. 동기는 "데이터센터 요구에 맞춰 서비스 처리량을 점진적 확장"이었습니다. [확인됨 — SRX5000 데이터시트]

Sophos — 왜 dual-processor를, 왜 Synchronized Security를

선택 배경: Sophos는 x86 CPU + Xstream Flow Processor(NPU) dual-processor 구조로 "비용 효율적 가속"을 추구합니다.

선택 이유:

• dual-processor: 자체 ASIC 설계 비용 없이 기존 x86 CPU와 범용 NPU(Marvell)를 조합 — Fortinet/Palo Alto의 자체 ASIC 대비 개발 비용·주기를 절감하면서, trusted 흐름의 하드웨어 오프로드(FastPath)를 구현. 동기는 "중간 가격대에서 ASIC급 성능을 제공"이었습니다. [추정/일반적 평가 — NPU 제조사 Marvell은 확인됨]
• Synchronized Security: Sophos Endpoint/Intercept X와 방화벽 간 위협 정보 공유·자동 격리 — "네트워크 보안과 endpoint 보안이 단절되어 있으면 lateral movement를 막을 수 없다"는 인식에서 출발. 동기는 "단일 벤더 생태계로 자동 대응 체계 구축"이었습니다. [확인됨 — Sophos 공식 페이지]
• Xstream 단일 스트리밍 DPI: AV/IPS/web/app/TLS를 단일 엔진으로 통합 — 다중 엔진의 패킷 복사 오버헤드를 제거. 동기는 "중간급 장비에서도 일관된 검사를 저비용으로 제공"이었습니다. [확인됨 — Sophos 문서]

F5 — 왜 L7 전문화를, 왜 TurboFlex를

선택 배경: F5는 ADC(Application Delivery Controller)에서 출발하여 NGFW 기능을 모듈로 추가한 벤더로, L7 HTTP/HTTPS 처리에서 독보적 depth를 가집니다.

선택 이유:

• L7 전문화: NGFW 전문 벤더(Fortinet/Palo Alto)가 L4~L7 전체를 커버하는 반면, F5는 "L7 프록시 처리 정확도·제어력"에 집중 — iRule(TCL)로 HTTP/TCP/SSL 계층 커스텀 정책 구현. 동기는 "ADC 고객이 이미 L7 트래픽 제어(Traffic Control)에 투자하고 있으며, 이를 보안으로 확장"이었습니다. [추정/일반적 평가]
• TurboFlex: 하드웨어 교체 없이 소프트웨어 라이선스 업그레이드만으로 L4/L7 처리량 2배 확장(i7800/i11800) — 동기는 "고객의 하드웨어 투자 보호"와 "트래픽 증가에 맞춘 단계적 확장"이었습니다. 하드웨어 교체 주기를 늦춤으로써 CapEx를 절감. [확인됨 — F5 iSeries 데이터시트]
• SSL Orchestrator: 단일 장비 내부 DPI가 아닌 외부 보안 도구 생태계를 오케스트레이션 — 동기는 "기존 IPS/DLP/WAF 투자를 버리지 않으면서 SSL 복호화 블라인드 스팟 해결"이었습니다. "모든 보안 도구를 F5 안에 넣어라"가 아니라 "F5가 복호화하고 기존 도구들에게 분배하라"는 접근. [확인됨 — F5 문서]

벤더별 모델군 종합 매트릭스 (등급·세대·폼팩터)

상용 NGFW 벤더들은 Entry(소형/브랜치)·Mid-range(중간급/캠퍼스)·Enterprise(엔터프라이즈)·Datacenter(데이터센터/서비스프로바이더) 4개 등급으로 모델군을 구성합니다. 본 절은 각 벤더의 모델군을 등급×세대×Rack-mount Unit(RU) 크기 기준으로 종합 정리합니다.

Fortinet FortiGate 모델군 매트릭스

FortiGate 7121F는 16U 19인치 랙마운트 12슬롯 섀시로 1Tbps 패브릭 백플레인과 50Gbps 베이스 백플레인을 갖춥니다 [확인됨 — Fortinet 문서]. G 시리즈(1200G/3500G/400G)는 2026년 5~7월 발표된 AI 시대 보안 라인업으로, 브랜치급(120G/200G)은 SP5(NP7Lite) 기반이고 데이터센터급(3500G/400G)은 NP7+SP5+CP10 조합입니다 [확인됨 — Fortinet press release].

Palo Alto Networks 모델군 매트릭스

PA-5500 시리즈(PA-5540~5580)는 3U 폼팩터(5.2인치 높이, 19인치 표준 랙)에 3RU 랙 키트를 사용하며, AC/DC 전원 옵션과 3.84TB SSD 페어를 포함합니다 [확인됨 — PA-5500 데이터시트 SKU 정보]. 등급 분류(Entry/Mid-range)는 본 문서의 분석적 분류로 PA 공식 카테고리명과 다를 수 있습니다 [추정/분석].

Check Point Quantum 모델군 매트릭스

Quantum 28000의 공식 수치: FW 145 Gbps / NGFW 51.5 Gbps / Threat Prevention 30 Gbps / IPS 52.2 Gbps / VPN AES-128 49 Gbps ("enterprise testing conditions" 측정) [확인됨 — 28000 데이터시트]. Maestro Hyperscale Orchestrator 140/175로 Security Group당 최대 31개 게이트웨이(단일 사이트), 듀얼 사이트 기준 총 28개 게이트웨이를 하나의 Security Group으로 클러스터링합니다 [확인됨 — Maestro 데이터시트].

Juniper SRX 모델군 매트릭스

SRX5400은 "480 Gbps firewall"로 Juniper 공식 문서에 명시되어 있으며, 데이터시트에서는 섀시 최대 FW 960 Gbps(IMIX)로 확인됩니다 [확인됨]. SRX1600은 1U 전력 효율 NGFW로 캠퍼스/데이터센터 엣지용입니다 [확인됨 — SRX1600 데이터시트].

Cisco Secure Firewall 모델군 매트릭스

Cisco Secure Firewall 4200 Series는 전 모델 1RU 폼팩터로, 8× SFP28 온섀시 + 2× NM 베이 + 400G 인터페이스 옵션 + fail-to-wire + 16-node 클러스터링을 제공합니다 [확인됨 — Cisco 4200 데이터시트]. Firepower 4100 Series(4110~4145)는 2026년 1월 6일 주문 마감(EOS) 예정이며 4200 Series가 권장 대체 모델입니다 [확인됨].

Sophos XGS 모델군 매트릭스

XGS 7500/8500은 최대 100 Gbps 연결 속도를 지원하며, Threat Protection은 XGS 7500 70 Gbps / XGS 8500 92.5 Gbps(2024-09-26 개정 데이터시트 기준)입니다 [확인됨 — Sophos 공식 페이지·데이터시트]. XGS 8500 Main CPU 64/128코어, NPU 36코어, 256GB DDR4 ECC, 2×960GB NVMe(HW RAID) [확인됨].

F5 BIG-IP iSeries 모델군 매트릭스

F5 iSeries는 전 모델 1U 폼팩터입니다 [확인됨]. i7600: 6코어 Xeon, 96GB DDR4. i7800: 6코어 Xeon, TurboFlex Tier3(2x bandwidth), 12 vCMP 게스트. i11600: 18코어 Xeon, 256GB DDR4. i11800: 18코어 Xeon, 40 Gbps 하드웨어 압축, 32 vCMP 게스트, TurboFlex Tier3 [확인됨 — F5 iSeries 데이터시트]. 성능 수치는 "local traffic management services only" 조건입니다 [확인됨].

벤더별 전 모델 하드웨어 스펙 종합표

출처: Fortinet [확인됨 — eol.network/fortinet/fortigate, Fortinet Community KB], Palo Alto [확인됨 — Palo Alto 공식 Hardware End-of-Life Dates 페이지], Cisco [추정 — Cisco EOL 공지 기반, 모델별 세부 일자는 Cisco EoL Notice 확인 필요], Check Point [추정 — Check Point support sk 기반, 세부 일자는 별도 확인 필요], Juniper [추정 — Juniper EOL 공지 기반], Sophos [확인됨 — Sophos EOL 공지], F5 [확인됨 — F5 EOL 공지]. "일부 EOS/EOL"은 해당 시리즈 내 모델별로 상태가 다름을 의미합니다.

본 절은 각 NGFW 벤더의 주요 모델별로 등급(급), CPU/SoC 구성, 코어 수, RAM, 오프로드 칩셋, 폼팩터(RU), 그리고 NGFW 각 기능별 성능을 단일 표로 종합합니다. 각 모델의 급은 Entry(소형/브랜치)·Mid-range(중간급)·Enterprise(엔터프라이즈)·Datacenter(데이터센터/SP) 4단계로 분류합니다. 하드웨어 스펙은 벤더에 따라 공개 수준이 다릅니다 — Fortinet은 데이터시트에 CPU/RAM을 명시하지 않으므로 커뮤니티 수집 데이터를 사용하고, Palo Alto는 CPU/RAM을 보안상 비공개로 처리합니다.

Fortinet FortiGate 하드웨어 스펙 종합

Fortinet은 데이터시트에 CPU 모델·RAM 용량을 공식 명시하지 않습니다. 아래 CPU/RAM 데이터는 커뮤니티에서 get hardware stat 명령으로 수집한 비공식 값이며, ASIC(NP/CP/SoC) 구성은 Fortinet 커뮤니티 KB에서 확인한 공식 매핑입니다. 성능 수치는 공식 데이터시트 값입니다.

CPU·RAM: [비공식/커뮤니티 — yurisk.info, forti.blog, get hardware stat 수집]. ASIC 구성: [확인됨 — Fortinet 커뮤니티 KB]. 성능 수치: [확인됨 — Fortinet 공식 데이터시트, IMIX 기준]. FG-7121F는 16U 12슬롯 섀시(1Tbps 패브릭 백플레인)로 슬롯당 처리량은 구성 의존적입니다 [확인됨 — Fortinet 문서]. 일부 모델의 성능 수치는 데이터시트 버전에 따라 상이할 수 있으며, 200G/900G 등 G 시리즈 일부 수치는 공식 데이터시트 교차 확인이 필요합니다 [추정]. G 시리즈(120G/400G/700G/3500G) 성능 수치: [확인됨 — Fortinet 공식 발표(2026년 5~7월), AVFirewalls/SHI/CDW 제품 페이지]. CPU·RAM은 G 시리즈 [비공개].

Cisco Secure Firewall 4200 하드웨어 스펙 종합

CPU: [확인됨 — AMD 공식 블로그 및 LinkedIn 발표: Cisco Secure Firewall 4200 Series는 AMD EPYC Embedded 7003(Milan, Zen 3) 프로세서 + AMD Versal Adaptive SoC(FPGA) 탑재]. 코어·RAM: [확인됨 — CiscoLive BRKSEC-2239: 4215=1× EPYC 32코어(64스레드) 256GB, 4225=1× EPYC 64코어(128스레드) 512GB, 4245=2× EPYC 64코어(128코어/256스레드) 1TB, 2× NVMe RAID1(4215/4225=2×900GB, 4245=2×1.8TB SED)]. 오프로드: [확인됨 — AMD Versal Adaptive SoC + Flow Offload + 1~4 VPN crypto HW accelerator, Crypto Offload Chip-to-Chip 4215/4225=100Gbps, 4245=2×100Gbps]. 성능·측정기준: [확인됨 — Cisco 4200 공식 데이터시트, NGFW=FW+AVC+IPS 1024B, TLS=50% TLS 1.2 AES256-SHA RSA 2048B, IPsec=1024B TCP w/Fastpath]. 16-node cluster, 최대 34 multi-instance(4245) [확인됨].

Palo Alto Networks 하드웨어 스펙 종합