H100 한 장으로 구축한 온프레미스 보안 LLM과 자율 탐지 파이프라인

보안 로그는 조직 외부로 단 한 줄도 유출되어서는 안 되는 가장 민감한 자산입니다. 엘리스가 PurpleOps를 기획할 때부터 완전한 온프레미스(On-premises) 환경을 전제로 설계한 이유입니다.

이번 3편에서는 H100 GPU 단 1장 위에 보안 특화 LLM을 직접 올리고, SIEM과 연동하여 실시간 자율 탐지 파이프라인을 구축한 실전 아키텍처를 소개합니다.
*SIEM : Security Information and Event Management, 보안 정보·이벤트 관리 시스템

-> PurpleOps 에이전트 SOC의 작동방식 알아보기

1. 설계 원칙: 온프레미스를 선택한 이유

보안관제센터(SOC)가 다루는 데이터는 방화벽 로그, 계정 인증 이력, 내부 네트워크 트래픽 등 민감도가 매우 높습니다. 이를 외부 상용 LLM API로 전송하면 데이터 주권(Data Sovereignty) 침해와 엄격한 보안 컴플라이언스 위반 리스크가 뒤따릅니다.

엘리스가 자체 클라우드 인프라에 보안 특화 LLM을 직접 호스팅한 이유도 바로 여기에 있습니다. 모든 추론 연산이 사내 격리망 내부에서 끝나므로 로그가 외부로 유출될 여지가 원천 차단됩니다.

엘리스는 여기서 한 걸음 더 나아가, 보안 에이전트가 외부 LLM을 임의로 호출하지 못하도록 이그레스 가드(Egress Guard)를 구축했습니다. 사전에 승인된 화이트리스트 외의 엔드포인트로 향하는 모든 LLM 호출은 기본 차단(Fail-closed) 정책을 적용받습니다. 온프레미스 보안 원칙을 담당자의 주의에 맡기는 대신, 아키텍처와 코드로 강제한 것입니다.

*이그레스 가드 : 외부로 나가는 통신을 검사해 허용 여부를 결정하는 장치
*기본 차단 : 판단이 불확실할 때 차단을 기본값으로 두는 방식

2. 추론 서빙 계층: GPU 한 장으로 20여 개 에이전트를 서빙하는 방법

단 1장의 GPU로 20여 개에 달하는 보안 에이전트를 안정적으로 구동하려면 서빙 효율화가 필수적입니다. 엘리스는 양자화한 보안 특화 모델을 vLLM 고성능 추론 엔진에 얹고, 모든 에이전트가 OpenAI 호환 표준 엔드포인트로 통신하도록 인터페이스를 표준화했습니다.

특히 에이전트 로직이 특정 모델이나 인프라 구현에 의존하지 않도록 모델명, 엔드포인트 URL, API 키를 환경변수 3개로 완전히 분리했습니다.

# 에이전트는 모델 내부 구현을 몰라도 표준 인터페이스로 호출 가능
from openai import OpenAI

client = OpenAI(
    base_url=os.environ["DEFAULT_BASE_URL"],   # 온프레미스 vLLM 엔드포인트
    api_key=os.environ["LOCAL_LLM_API_KEY"],
)

resp = client.chat.completions.create(
    model=os.environ["DEFAULT_MODEL_NAME"],
    messages=[
        {"role": "system", "content": SECURITY_ANALYST_PROMPT},
        {"role": "user", "content": alert_context}
    ],
    max_tokens=8192,   # 추론 특화 모델의 사고 과정 및 출력 누락 방지
)

운영 인사이트 사고 과정을 거치는 추론 특화 모델은 내부 연산에 많은 토큰을 소비합니다. 따라서 max_tokens를 충분히 넉넉하게 설정하지 않으면 사고 과정 도중 토큰이 소진되어 최종 요약 결과가 누락된 채 빈 응답이 반환될 수 있습니다. 엘리스 역시 초기 구축 과정에서 분석 보고서 본문이 누락되는 현상을 겪었고, 출력 토큰 한도를 8,192 이상으로 상향하여 이 문제를 해결했습니다.

3. 데이터 계층: SIEM을 에이전트의 관측 창구로

보안 에이전트가 정확한 분석을 내리려면 신뢰할 수 있는 실시간 로그가 뒷받침되어야 합니다. PurpleOps는 SIEM을 중심으로 엔드포인트 에이전트, EDR, 서버 백신, IPS, 방화벽, WAF, IAM, DB 접근제어 등 여러 솔루션의 로그들을 전방위로 통합 수집합니다.

그러나 벤더마다 로그 형식이 달라, 원문을 그대로 LLM에 넣으면 환각(Hallucination)과 오해석이 발생합니다.

이 문제를 해결하기 위해 로그 정규화 계층을 구축했습니다. 다양한 벤더의 로그를 ECS(Elastic Common Schema) 기반의 공통 스키마로 변환하고, 이를 log_class 단위로 추상화합니다. 이 구조 덕분에 새로운 보안 솔루션이 도입되어도 전용 어댑터 1개만 추가하면 되므로, 기존 에이전트 코드나 프롬프트는 수정할 필요가 없습니다. 결과적으로 에이전트가 정규화된 근거로만 추론하게 되어 환각 발생을 낮췄습니다.

# 벤더 로그 수집 → 공통 스키마 정규화 → 에이전트 소비
raw = fetch_from_siem(index="security-alerts-*", query=q)
events = [normalize(e) for e in raw]                # ECS-subset 공통 필드로 매핑
grounding = aggregate_by(events, key="log_class")   # 이벤트 방향성 및 카디널리티 교정

# LLM에는 원문 로그가 아닌 '검증된 집계 사실'을 근거로 주입 → 환각 원천 차단

4. 자율 파이프라인: 탐지에서 대응까지

수집·정규화된 정제 데이터를 바탕으로 에이전트 그래프가 자율적으로 동작합니다. SIEM에서 고위험 상관 알림이 감지되는 즉시 블루팀 에이전트 그래프가 트리거되며, “1차 트리아지 → 연관 위협 헌팅 → 위협 인텔리전스(TI) 보강 → 대응” 단계로 진행됩니다.

이때 IP 차단이나 계정 정지와 같이 서비스 영향도가 큰 핵심 조치는 반드시 사람 승인(HITL, Human-In-The-Loop) 관문을 거치도록 설계했습니다. 또한 관측 계층(트레이싱)이 모든 과정을 실시간 기록하므로, 어떤 에이전트가 어떤 데이터와 판단 근거로 해당 조치를 제안했는지 완벽하게 추적할 수 있습니다.

파이프라인 성능 (자체 실증 환경, 24시간 기준)

※ 위 수치는 특정 시점의 엘리스 자체 실증 환경 측정치이며, 로그 볼륨 및 에이전트 구성, 튜닝 파라미터에 따라 달라질 수 있습니다.

주목할 점은 GPU 한 장으로 하루 약 300회의 자율 사이클을 처리했다는 사실입니다. 온프레미스 소형 인프라로도 충분히 실전성 높은 자율 SOC를 운영할 수 있습니다. 대규모 조직은 GPU를 늘려 병렬성과 모델 크기를 함께 확장하면 됩니다.

5. 실전 운영에서 얻은 4가지 교훈

1) 환각 대책의 효과는 데이터 계층에서 가장 크게 나타났습니다. 프롬프트를 다듬는 작업보다 정규화된 근거를 제공하는 편이 효과가 컸습니다.

2) 재기동과 환경변수 관리에 주의가 필요합니다. 서빙 프로세스 재기동이나 .env 편집 실수 하나로 전체 파이프라인이 멈출 수 있습니다. 그래서 부팅·복구 절차를 문서화하고 자동화했습니다.

3) 변화가 없을 때는 보고를 생략합니다. 무 변동 보고를 걸러내는 게이트를 두어, 담당자가 실제 중요 알람에만 주목하도록 했습니다.

4) 자율성의 상한선은 신뢰가 결정합니다. 근거를 투명하게 남기고 위험 조치는 사람 승인을 필수로 설정하여, 자동화 범위를 더 넓게 잡을 수 있었습니다.

GPU 한 장에서 출발한 PurpleOps는 지금도 수집 로그 소스와 에이전트를 넓혀가고 있습니다. 앞으로는 보안 솔루션 어댑터를 추가하고, 탐지 규칙 자동 생성·배포의 검증 루프를 강화하며, 멀티 GPU 환경의 병렬 오케스트레이션을 다룰 계획입니다.

이어지는 4편에서는 이 시스템의 '신뢰성'을 보장하기 위한 방법을 설명합니다. 환각을 구조로 막는 그라운딩과 교차 검증, LLM 트레이싱 기반 감사 추적을 다룹니다.