1. 서론 — 왜 로컬 LLM이었는가 #

BASTION의 핵심은 로컬 LLM(Qwen2.5-14B)입니다. GPT-4나 Claude와 같은 최첨단 외부 LLM API가 아닌, 자체 GPU 서버에서 구동하는 Qwen2.5를 선택했습니다.

“정확도가 높은 것을 사용하면 되는데, 왜 굳이 성능이 떨어지는 로컬 모델을?”이라는 의문은 당연합니다. 본 기사에서는 그 선택의 배경과 실제로 어떻게 구동하는지를 설명합니다.

결론을 먼저 말하자면, 로컬 LLM에는 “정확도”와는 별개로 3가지 강력한 장점이 있으며, 인프라 운영이라는 도메인에서는 그것들이 더 중요했다는 이야기입니다.

2. 클라우드 LLM의 3가지 장벽 #

BASTION을 개발하는 초기에 당연히 OpenAI API나 Anthropic API 사용을 검토했습니다. 하지만 다음 3가지 장벽에 부딪혔습니다.

2.1 데이터 주권의 벽 #

BASTION이 다루는 로그에는 고객의 민감한 정보가 포함됩니다. 공격원 IP, 내부 시스템 구성, 사용자 이름, 인증 실패 상세 내역 등. 이를 외부 LLM API로 전송하는 것은 많은 고객 계약에서 허용되지 않습니다.

특히 금융·공공기관·의료 분야에서는 “로그를 외부로 전송한 시점에서 계약 위반”이라는 고객도 드물지 않습니다. 클라우드 LLM은 애초에 “사용할 수 없는” 것입니다.

2.2 비용의 불투명성 #

외부 LLM API는 사용량 기반 과금입니다. AWS의 DevOps Agent 등은 초 단위로 과금됩니다. BASTION처럼 상시 가동되는 시스템에서 이를 사용하면 로그량에 비례하여 비용이 선형으로 증가합니다. 월별 예산을 예측할 수 없습니다.

“공격이 많은 달에는 예산 초과”, “평화로운 달에는 사용하지 못하고 낭비”라는 형태로 비용 최적화가 극히 어려운 구조입니다.

2.3 네트워크 의존성 #

클라우드 LLM은 인터넷 연결이 전제입니다. 폐쇄 환경(전용선으로 격리된 네트워크 등)에서는 애초에 사용할 수 없습니다.

BASTION의 타겟에는 “인터넷에 연결되지 않은 환경에서도 작동하는 모니터링 시스템이 필요하다”는 고객이 포함됩니다. 이를 확보할 수 있는지는 차별화의 핵심이었습니다.

3. BASTION의 LLM 활용 방침 — 3가지 원칙 #

이를 바탕으로 BASTION은 다음 3가지 방침으로 LLM을 활용하고 있습니다.

즉, LLM은 “유능한 비서”로 사용하고, 판단은 결정론적 코드에 맡긴다는 것이 BASTION의 기본 자세입니다. 이는 LLM 업계의 주류 사용법과는 조금 다릅니다.

4. 아키텍처 — GPUStack + Qwen2.5-14B #

BASTION의 LLM 기반은 단순한 구성으로 작동합니다.

BASTION 중앙 서버 (AI-SLOG)
  │
  ├── rsyslog로 각 기기에서 로그 수신
  ├── 셸 스크립트군으로 전처리·요약
  │     │
  │     ↓ HTTP API call (OpenAI 호환)
  │
  └── GPUStack 클러스터
        ├── Qwen2.5-14B (주력 모델)
        ├── 경량 모델 (폴백용)
        └── 자동 로드 밸런스 + 자동 재시작

선정 이유를 간단히 설명합니다.

4.1 왜 Qwen2.5-14B인가 #

BASTION에서는 로그 요약과 자연어 보고서 생성이 주요 작업입니다. 이에 필요한 것은:

• 일본어의 자연스러운 출력 — 고객용 보고서가 영어 혼용이면 사용할 수 없음
• 14B 정도의 크기 — 24GB GPU 1장으로 양자화 없이도 작동
• 장문 대응 — 로그 요약을 위해 컨텍스트 길이가 충분히 필요
• 오픈 라이선스 — 상업적 사용이 명확히 허가됨

Llama 3 계열도 검토했지만, 일본어의 자연스러움에서 Qwen2.5가 우세했습니다. 이는 사내 비교 평가의 결론입니다.

4.2 왜 GPUStack인가 #

GPUStack은 여러 GPU 서버를 클러스터로 관리할 수 있는 OSS입니다. BASTION에서는:

• OpenAI 호환 API로 외부에서 접근 가능
• 모델 전환이 용이(주 모델 다운 시 폴백)
• 분산 운영 가능(여러 GPU 서버에서 병렬 처리)
• 운영 대시보드 제공(모델 가동 상태를 한눈에 확인 가능)

이들이 상용 환경에 필요한 요구사항을 충족했습니다.

5. 파이프라인 — 로그에서 알림까지 #

BASTION의 LLM 활용은 여러 단계로 나뉩니다.

1. 장비 로그 수신        (rsyslog)
        ↓
2. 장비별 분류 저장    (셸 + 파일 시스템)
        ↓
3. 장비별 요약      (LLM 호출 #1)
        ↓
4. 전체 상관 분석        (LLM 호출 #2)
        ↓
5. 중대도 판정          (결정론적 로직)
        ↓
6. Slack 통지          (중대도가 CRITICAL일 때만 자동 게시)
        ↓
7. 상세 분석            (운용자가 멘션으로 호출)

중요한 것은, 각 단계에서 LLM의 역할이 명확히 제한되어 있다는 것입니다.

“LLM에게 판단시키지 않고, 정형화만 맡긴다”는 원칙을 일관되게 유지하고 있습니다.

6. LLM에 맡길 것과 맡기지 말 것 #

이것은 BASTION 설계의 핵심 부분이므로 조금 더 자세히 설명하겠습니다.

BASTION에서는 LLM의 출력을 신뢰하는 경우와 신뢰하지 않는 경우를 최초 설계 단계에서 명확히 구분했습니다.

6.1 LLM에 맡겨도 되는 것 #

• 로그의 자연어 요약 — 약간의 표현 편차는 허용 범위
• 여러 장비의 상황을 한 단락으로 정리 — 사람이 읽기 위한 것
• Slack 통지 문구의 정형화 — 중요도에 따른 이모지나 강조도 맡길 수 있음
• 과거 유사 사례 참조 — “이것은 지난주에도 발생했다”고 제시

6.2 LLM에 맡겨서는 안 되는 것 #

• 공격 IP인지 여부의 최종 판정 — 수학적 판정으로 결정적으로 결정
• 차단 실행의 의사 결정 — 코드로 조건을 명시
• 차단 해제의 의사 결정 — 24시간 자동 실효 또는 운용자 조작만 허용
• 운영 환경 설정 변경 — 운용자의 수동 조작만 허용
• 보안 중대도의 최종 판정 — 룰 베이스로 결정

“LLM의 출력을 읽고 운용자가 판단하는” 시나리오는 많지만, “LLM의 출력이 직접 시스템을 작동시키는” 시나리오는 BASTION에 거의 존재하지 않습니다.

7. 하이브리드 LLM 전략 — 로컬 + 외부 API의 구분 사용 #

2026년 5월 시점에서 BASTION은 로컬 LLM뿐만 아니라, Claude나 GPT 등의 외부 고성능 LLM API와의 연계도 실험 단계에서 구축 중입니다.

다만, 이는 “로컬 LLM을 버리고 외부로 전환한다”는 이야기가 아닙니다. 용도에 따라 구분해서 사용하는 하네스를 구축하고 있다는 의미입니다.

폐쇄망 요구사항이 엄격한 고객에게는 외부 LLM 연계를 분리하여 로컬만으로 동작하는 구성도 기존과 같이 제공합니다. “외부 LLM을 반드시 사용하는 제품”이 아니라, “사용하고 싶을 때 사용할 수 있는 확장성을 가진 제품“이라는 것이 현재의 위치입니다.

8. 설계상의 판단 포인트 #

로컬 LLM 운용에서 몇 가지 중요한 판단이 있었습니다.

1. 프롬프트는 버전 관리한다: LLM에 대한 질의 내용(프롬프트)은 코드와 마찬가지로 버전 관리 대상. 프롬프트 변경으로 출력 품질이 크게 달라지므로 변경 이력을 남긴다.

2. JSON 출력을 강제한다: LLM의 출력이 “자유 문장”인 상태로는 후단 코드에서 파싱할 수 없다. BASTION에서는 JSON 형식 출력을 강제하고, 파싱 오류 시 재시도한다.

3. temperature는 낮게: 동일한 입력에 대해 안정적인 출력을 얻기 위해 temperature는 낮은 값(0.0~0.3 정도)으로 고정. 창의성은 불필요하며, 결정성이 중요하다.

4. 프롬프트의 “조작 방지” 지시: “주어진 로그에 없는 정보를 생성하지 않는다” “불명확한 경우 명시적으로 ‘unknown’을 반환한다”는 지시를 반드시 포함한다. 그래도 할루시네이션을 완전히 막을 수 없으므로 후단에서 할루시네이션 감사를 수행한다(별도 글에서 상세히 다룰 예정).

5. 모델 다운 시 폴백: 메인 모델(Qwen2.5-14B)이 응답하지 않을 때를 대비하여 경량 모델로의 폴백 경로를 구현. 완전 중단보다는 간이 요약이라도 지속하는 것을 우선시한다.

9. 운용 실적 — 노이즈 감소와 결정성 #

BASTION이 운영 환경에서 가동을 시작한 지 약 1개월. LLM의 운용 실적을 공유합니다.

• 로그 분석 자동화율: 약 95%(기존에는 운용자가 개별적으로 Tail하던 로그를 LLM 요약으로 대체)
• Slack 알림 노이즈 감소: CRITICAL 전용 알림으로 전환하여 정기 알림 발생 빈도가 약 1/8로 감소
• 판정의 결정성: 동일한 입력에 대한 판정 결과는 완전히 일치(LLM의 확률적 출력은 배제했기 때문)
• 오탐률: 0%(자사 IP/거래처 IP의 오차단 건수 제로)
• 할루시네이션 탐지 건수: 감사 로직으로 지속적으로 탐지. 탐지된 경우 이벤트를 폐기하고 재분석

특히 「결정성 100%」가 중요합니다. LLM을 판단에 사용하면 동일한 입력에서 다른 결과가 나올 수 있습니다. BASTION에서는 LLM을 판단에 사용하지 않으므로 이러한 「재현성 없는 오작동」이 물리적으로 발생하지 않습니다.

10. 설계상의 트레이드오프 #

솔직히 말하면 로컬 LLM 운영에도 제약이 있습니다.

1. 초기 GPU 비용: Qwen2.5-14B를 원활하게 실행하려면 24GB 클래스의 GPU가 필요. 최소 구성이라도 수십만 엔~. 클라우드 API와 같은 「제로 엔 스타트」는 아님.

2. 추론 성능의 상한: 14B 클래스 모델은 GPT-4나 Claude 3.5 Sonnet만큼의 추론 능력은 없음. 복잡한 다단계 추론이 필요한 경우 외부 API로의 폴백이 필요.

3. 모델 업데이트 추종: 새로운 모델이 나올 때마다 평가·전환 판단이 필요. 사내에 기술적 판단이 가능한 인재가 필요(이는 BASTION의 유지보수 계약으로 커버).

4. 프롬프트 조정의 지속성: 환경마다 최적의 프롬프트가 다름. 도입 시의 튜닝과 운영 중의 지속적인 개선이 필요.

이들은 「로컬 LLM을 채택하는 이상 피할 수 없는 트레이드오프」입니다. 다만 데이터 주권·비용 예측성·폐쇄망 대응이라는 3가지 장점과 맞바꿔 받아들여야 할 비용이라고 판단하고 있습니다.

11. 향후 발전 #

LLM 기반은 앞으로도 지속적으로 진화시킬 것입니다.

• 신세대 모델로의 추종: Qwen3 및 차세대 모델의 평가와 전환
• 하이브리드 LLM 전략의 본격 운영: 용도별 자동 분배를 정형화
• 멀티모달 대응: 네트워크 다이어그램이나 트래픽 그래프를 LLM에 읽히는 용도
• 고객 환경별 튜닝: 각 고객의 로그 특성에 맞춘 프롬프트 최적화 자동화

이들은 순차적으로 추진할 예정입니다.