Splunk Project | Splunk 서버에 Ollama 연동 시, 아키텍처 선택 이유

Splunk 기반 보안 분석 환경에 로컬 LLM을 붙이는 작업을 진행하다 보면,

단순히 “모델이 돌아간다”와 “실제로 운영 가능한 구조다”는 전혀 다른 문제라는 걸 금방 느끼게 된다.

 

이번 글에서는 제가 실제로 검토한 구조를 기준으로

1. 왜 Ollama는 Host에 설치하고
2. Open WebUI와 DSDL은 Docker로 분리하는지
3. 그리고 왜 Foundation-Sec-8B의 Q4 GGUF 모델을 선택했는지

를 정리해봤다.

---

1. 최종 권장 아키텍처

테스트 서버 OS 상황은 아래와 같다

 

현재 기준으로 가장 현실적인 권장 구조는 아래와 같다.

[ Splunk (Host) ]
    └─ Search / Dashboard / Alert / AITK / Script
            ↓
[ Ollama (Host) ]
    └─ model: hf.co/fdtn-ai/Foundation-Sec-8B-Q4_K_M-GGUF:Q4_K_M
            ↓
[ NVIDIA GPU (Host Direct Access) ]

[ Open WebUI (Optional, Docker) ]
    └─ Ollama API 호출

[ DSDL (Optional, Docker) ]
    └─ 전처리 / 후처리 / 파이프라인 / 향후 RAG 확장
    └─ Ollama API 호출

 

모델 실행 엔진은 최대한 단순하게 Host에서 돌리고, 부가 기능은 Docker로 분리하는 구조!

---

2. 데이터 흐름은 어떻게 가져가는가

2-1. 가장 단순한 운영 흐름

Splunk Search 결과
   ↓
Python 또는 AITK 호출
   ↓
Ollama API (localhost:11434)
   ↓
Foundation-Sec 모델 분석
   ↓
결과를 Splunk에 반환

 

목표는 Splunk에서 검색된 로그나 이벤트 결과를 모델에 넘기고, 그 결과를 다시 Splunk로 받아오는 구조!

즉, Splunk는 데이터 공급자, Ollama는 분석 엔진 역할을 하는 것!

 

2-2. UI를 포함한 흐름

사용자 브라우저
   ↓
Open WebUI
   ↓
Ollama
   ↓
Foundation-Sec

 

이 구조는 사람이 직접 모델 응답을 테스트하거나 시연할 때 유용하다.

다만 운영 핵심은 아니다.

Open WebUI는 필수는 아니고, 테스트와 시연을 위한 보조 도구로 활용할 수 있다.

 

2-3. 향후 DSDL까지 포함한 확장 흐름

Splunk
   ↓
DSDL API / 파이프라인
   ↓
Ollama
   ↓
Foundation-Sec
   ↓
분석 결과 / 태깅 / 요약 / MITRE 매핑

 

이 구조까지 가면 단순 질의응답을 넘어서

전처리, 후처리, 태깅, 요약, MITRE ATT&CK 매핑, 향후 RAG 연계까지 고려할 수 있다.

 

따라서 지금 구조는 임시 조합이 아니라 확장형 기반 구조임

---

3. 왜 Ollama는 Docker가 아니라 Host에 설치하는가

이미 NVIDIA 드라이버와 CUDA가 정상 동작하는 서버라면 Ollama는 Host 설치가 가장 안정적입니다.

3-1. GPU 접근이 가장 단순하다

Host에 직접 설치하면 Ollama가 GPU에 바로 접근

즉, 중간에 Docker GPU passthrough나 nvidia-container-toolkit 같은 추가 설정이 필요 없다.

• GPU passthrough 설정 불필요
• 컨테이너 런타임 디버깅 불필요
• 장애 지점 감소
• 실패 확률 감소

특히 이미 nvidia-smi가 정상적으로 보이는 상태라면, 굳이 GPU 경로를 한 번 더 꼬이게 만들 이유가 없다.

 

3-2. Splunk와 연동 구조가 가장 단순하다

Splunk도 Host에서 돌고 있고, Ollama도 Host에 있으면 호출은 사실상 이것으로 끝!

Splunk → http://localhost:11434

 

반대로 Ollama를 Docker로 올리면 아래 같은 관리 포인트가 추가됨

• 포트 매핑
• 컨테이너 네트워크
• GPU passthrough
• 서비스 재시작 시점 관리
• 로그 추적 경로 분리

Splunk와 빠르게 붙여서 PoC를 만드는 게 목표라면, Host 설치가 훨씬 실무적이다.

 

3-3. 운영 서버에서는 단순성이 곧 안정성이다

이 서버는 AI 전용 서버가 아니라 이미 Splunk가 돌아가는 서버라,

이런 환경에서는 “예쁘게 구성하는 것”보다 “덜 꼬이게 구성하는 것”이 더 중요하다.

따라서 Ollama는 Host에 두고, 모델 실행 경로를 최대한 짧게 가져가는 것이 맞다고 판단했다.

---

4. 왜 모델은 Foundation-Sec-8B Q4 GGUF인가

현재 실제로 성공적으로 실행한 방식은 아래와 같습니다.

ollama run hf.co/fdtn-ai/Foundation-Sec-8B-Q4_K_M-GGUF:Q4_K_M

 

이 선택 역시 “가능한 모델”이 아니라 운영 가능한 모델을 기준으로 내려진 결정이다.

 

4-1. GPU가 GTX 1080 8GB이기 때문이다

GTX 1080 8GB 환경에서는 8B 모델을 FP16이나 BF16으로 돌리는 것이 부담스럽다.

게다가 Splunk까지 함께 올라가 있는 서버라면, 모델은 “겨우 돌아가는 수준”이 아니라 안정적으로 들어가는 수준이어야 한다.

 

Q4 GGUF의 장점은 명확합니다.

• VRAM 부담이 낮다
• 속도가 비교적 빠르다
• Ollama에서 실행이 쉽다
• PoC와 자동화 테스트에 충분하다

즉, 이 선택은 성능을 포기한 것이 아니라, 현재 리소스에서 가장 현실적인 최적점을 고른 것

 

4-2. Reasoning 모델을 고집하면 현실적으로 막힌다

보안 분석 목적만 놓고 보면 reasoning 계열이 더 매력적으로 보일 수 있지만,

실제 운영 환경에서는 다음 문제가 바로 나타날 가능성이 있다.

• 공식 quantized 배포가 불명확한 경우가 있다
• Ollama registry에서 바로 안 잡히는 경우가 있다
• VRAM 8GB 환경에서는 안정성 리스크가 크다
• 긴 입력 / 긴 출력 / 동시 요청에서 OOM 위험이 커진다

즉, 품질만 보면 더 좋아 보이는 선택이 있을 수 있지만,
지금 목표가 Splunk와 실제로 붙는 보안 분석 PoC라면 instruct/Q4 계열이 훨씬 실무적이라고 판단했다.

 

4-3. 지금은 정확도 100점보다 1차 성공이 더 중요하다

현재 단계에서 더 중요한 기준은 아래 네 가지로 정했다.

• 잘 설치되는가
• 잘 응답하는가
• GPU가 터지지 않는가
• API로 안정적으로 붙는가

이 기준으로 보면 Foundation-Sec-8B-Q4_K_M-GGUF는 아쉽지만 충분히 합리적인 선택이라고 느꼈다.

---

5. 왜 Open WebUI는 Docker로 분리하는가

Open WebUI는 모델 실행 엔진이 아니라, 사람이 테스트하고 확인하기 위한 프런트엔드다.

그래서 Docker 분리가 관리에 편리하다 생각했다.

5-1. 웹 애플리케이션은 컨테이너화가 잘 맞는다

Open WebUI는 내부 의존성이 있는 웹 애플리케이션

포트만 열고, 볼륨만 적절히 잡아주면 비교적 깔끔하게 운영할 수 있다는 의견이 많았다.

이런 종류의 앱은 Host에 직접 설치하는 것보다 Docker가 훨씬 관리하기 쉽다는 의견이 많아 따랐다.

5-2. Host를 오염시키지 않는다

Splunk 서버에 UI용 패키지와 웹 앱 의존성을 직접 설치하기 시작하면, 패키지 충돌이나 관리 포인트가 늘어날 가능성이 크다. Splunk가 주인공인 서버라면, 이런 부가 서비스는 분리해줬다.

5-3. 역할 분리가 명확하다

Open WebUI의 역할은 다음과 같다.

• 테스트용 대화 UI
• 프롬프트 검증
• 모델 응답 확인
• 시연용 인터페이스

즉, 엔진이 아니라 프런트엔드! 그래서 docker로 분리!

---

6. 왜 DSDL도 Docker로 분리하는가

DSDL은 단순 실행 프로그램이 아니다.

향후 확장성을 고려하면 오히려 가장 분리가 필요한 컴포넌트라고 한다.

6-1. DSDL은 Splunk와 성격이 다르다

DSDL에는 보통 이런 요소가 붙는데,

• Python runtime
• 패키지 의존성
• 데이터 전처리 / 후처리
• 향후 embedding / vector DB / RAG 확장

이걸 Splunk Host에 직접 얹기 시작하면 의존성 충돌 가능성이 커진다고 한다.

6-2. Splunk Python 환경과 섞이면 운영 리스크가 크다

Splunk는 자체 Python과 앱 런타임을 많이 사용한다.

여기에 DSDL용 라이브러리까지 Host에 직접 깔면, 어떤 Python이 어떤 라이브러리를 쓰는지부터 정리가 안될 가능성이 높다.

이 단계에서 발생하는 문제는 단순 설치 실패가 아니라 운영 복잡도 증가다.

그래서 DSDL은 초기에부터 Docker로 격리하는 것이 안전할 수 있다.

6-3. 향후 RAG 확장에도 유리하다

Splunk
  ↓
DSDL
  ├─ 전처리
  ├─ 문서 chunking
  ├─ embedding
  ├─ vector search
  └─ prompt orchestration
  ↓
Ollama

 

지금은 단순 API 중계만 하더라도, 나중에는 이 구조가 자연스럽게 RAG 파이프라인으로 확장될 가능성이 있다.

이때 Host에 직접 올려둔 구조보다 Docker 분리 구조가 훨씬 유연하다고 판단했다.

---

7. 이 조합이 가장 합리적인 이유

정리하면 이번 구조의 핵심은 아래 한 줄로 설명할 수 있다.

모델 실행은 Host에서 단순하게, 부가 서비스는 Docker로 분리한다.

 

각 컴포넌트별로 보자.

• Ollama는 Host → GPU 직접 접근, Splunk와 localhost 연동, 운영 단순
• Open WebUI는 Docker → UI 앱 분리, Host 오염 방지, 테스트/시연 편의
• DSDL은 Docker → Python 의존성 격리, Splunk와 충돌 방지, 향후 RAG 확장 용이

 

---

8. 리소스 관점에서도 왜 이 구성이 맞는가

현재 서버 기준으로 보면 CPU와 RAM은 PoC 단계에서 비교적 여유가 있는 편이고,

실제 병목은 GPU 쪽에서 발생할 가능성이 크다.

8-1. CPU는 충분하다

DSDL, WebUI, Splunk, Ollama API 처리를 함께 올려도 CPU가 바로 병목이 되지는 않는다.

즉, CPU보다는 다른 자원을 더 신경 써야 했다.

8-2. RAM도 PoC 단계에서는 감당 가능하다

Splunk가 이미 동작 중이더라도,

Ollama + 8B Q4 + 가벼운 WebUI + 초기 DSDL 정도는 충분히 운영 가능한 수준이라고 생각했다.

8-3. 진짜 병목은 GPU다

GTX 1080 8GB 환경에서는 아래처럼 보는 것이 현실적

• Q4는 비교적 안전
• Q8은 타이트함
• reasoning-q8은 현실적으로 부담이 큼
• 동시 요청이 많아지면 위험함

그래서 현재 단계에서는 모델을 Q4로 두고, 병렬 처리도 보수적으로 가져가려고 했다.

---

9. 권장 구축 순서

이런 종류의 구성은 처음부터 모든 컴포넌트를 한꺼번에 올리면 복잡도만 급격히 증가, 따라서 아래 순서로 진행했다.

1단계. Ollama + Foundation-Sec 모델 먼저

가장 핵심 엔진.

이 단계가 성공해야 GPU 사용 여부도 확인되고, 이후 Splunk 연동 테스트의 기반이 생긴다.

2단계. Splunk 연동

최종 목적이 Splunk 활용이라면, 모델 설치보다 실제 검색 결과를 모델에 넣고 결과를 받아오는 과정이 더 중요

PoC 가치가 생기는 지점도 바로 여기

3단계. Open WebUI

사람이 테스트하기 쉬워지고, 시연과 프롬프트 검증이 편해짐

다만 핵심 기능은 아니므로 3순위

4단계. DSDL

파이프라인 고도화 단계.

처음부터 붙이면 복잡도만 올라가므로, 기본 연동이 끝난 뒤 확장 단계에서 붙이는 것이 맞다.

---

10. 이 아키텍처가 실제 목적에 맞는 이유

이번 구성이 의미가 있는 이유는, 단순 챗봇이 아니라 아래 목적에 직접 맞물리기 때문

• 보안 로그 요약
• MITRE ATT&CK 매핑
• 공격 흐름 설명
• Splunk 대시보드 및 서치와 연계
• 향후 DSDL / RAG 확장

특히 Foundation-Sec 계열 모델은 보안 도메인 적합성이 있기 때문에,

일반 범용 모델보다 보안 분석 PoC에서는 더 직접적인 장점이 있다.

 

그리고 Q4 GGUF + Host Ollama 조합은 지금 서버에서 “이론상 좋아 보이는 구성”이 아니라

“실제로 성공 가능한 구성”이라는 점에서 의미를 갖기로 했다.

---

11. 최종 결론

현재 환경에서 가장 현실적인 전략은 아래 한 줄로 정리할 수 있다.

모델 실행은 Host Ollama로 단순하게 가져가고,
Open WebUI와 DSDL 같은 부가 서비스는 Docker로 분리한 뒤, 먼저 Splunk 연동을 성공시키고 이후 확장

 

이 방식이 가장 안정적이고, 가장 실무적이며,

무엇보다 PoC를 빠르게 성공시키고, 이후 점진적으로 고도화하기에도 가장 좋은 출발점이 아닐까 한다.