이 글은 현재까지 구축된 환경을 기준으로, DSDL에서 Ollama를 연결하는 설정 방법을 정리한 메뉴얼이다.
단순히 “어디에 무엇을 입력하는가”만 정리한 것이 아니라,
왜 이 구조로 가는지, 왜 어떤 기능은 지금 제외하는지까지 함께 설명하는 것을 목표로 한다.
📌 현재 기준 전체 진행 상태
- Phase 1 — LLM 실행 : 완료
- Phase 2 — Splunk 연동 : 완료
- Phase 3 — Open WebUI : 완료
- Phase 4 — DSDL : 진행 중
지금은 “모델이 잘 돌아가느냐”를 확인하는 단계는 이미 끝났고,
이제는 Splunk와 LLM 사이를 DSDL로 연결하는 단계
🔥 먼저 결론: 지금 목표는 RAG가 아니다
문서를 그대로 따라가면 구조가 커진다. 예를 들면 아래처럼 흘러가기 쉽다.
Docker Ollama + DSDL + Milvus + LLM-RAG Container
하지만 현재 목표는 그런 “엔터프라이즈 RAG 플랫폼”이 아닙니다.
내가 가고 싶은 최종 형태는 아래에 가깝다.
자연어 질문
↓
SPL 생성
↓
Splunk 검색
↓
LLM 분석
↓
결과 반환
목표: “WebUI에서 Splunk 데이터를 자연어로 검색하고 분석하는 구조”
DSDL은 사용하되, 지금 단계에서는 RAG는 하지 않는다.
✅ 지금 해야 할 것 딱 3개
1. DSDL 앱 설치 (필수)
Open WebUI는 Splunk를 모르고, Ollama는 Splunk 데이터에 직접 접근하지 못한다.
중간에서 흐름을 연결해주는 오케스트레이터가 필요하고, 그 역할을 DSDL이 담당한다.
2. AI Toolkit 설치 (필수)
Splunk 안에서 LLM을 호출하는 표준 인터페이스 역할을 하기 때문
나중에 SPL 안에서 | ai prompt="..." 같은 흐름으로 연결할 때도 중요
3. DSDL에서 Ollama 연결
결국 이 단계가 성공해야 다음 구조가 완성된다.
Splunk → DSDL → Ollama → AI 분석❌ 지금 하지 않을 것
1. Docker 2375 Remote API
문서 예시에는 tcp://172.x.x.x:2375 같은 구성이 나오기도 하지만, 현재 환경에서는 굳이 열 필요가 없다.
이미 Docker는 로컬에 있고, 이 포트를 열면 보안 위험만 증가함
2. Milvus Vector DB
Milvus는 문서 검색 기반 RAG에서 필요한 구성이다.
하지만 지금은 Splunk가 이미 데이터 저장소 역할을 하고 있으므로 필요하지 않다.
3. LLM-RAG Container
이 역시 embedding, vector search, retrieval 같은 구조를 전제로 한다.
현재 목표는 로그 검색과 분석이므로 지금 단계에서는 과하다.
💡 왜 이렇게 의사결정했는가
근거 1. 이미 데이터 소스가 존재한다
RAG는 보통 “문서를 따로 저장하고, 검색해서, 다시 모델에 넣는 구조”다.
하지만 현재는 Splunk 자체가 이미 데이터 저장소. 따라서 굳이 데이터를 또 Vector DB로 옮길 이유가 없다.
근거 2. GPU 리소스가 넉넉하지 않다
현재 GPU는 GTX 1080 8GB.
여기에 모델 추론만 얹는 것은 가능하지만,
RAG까지 붙이면 embedding, retrieval, 추가 처리 때문에 리소스 부담이 급격히 커진다.
근거 3. 목표가 문서 QA가 아니라 실시간 로그 분석이다
문서 기반 질의응답과 Splunk 로그 분석은 성격이 다르다.
지금 필요한 것은 “문서를 잘 찾는 구조”가 아니라, “로그를 검색하고 결과를 해석하는 구조”입니다.
근거 4. 복잡도를 통제해야 한다
구성이 많아질수록 디버깅 포인트가 늘어난다. 지금 단계에서는 단순한 구조가 정답
[ Open WebUI ]
↓
[ DSDL (Splunk App) ]
↓
[ Splunk Search ]
↓
[ Ollama ]
지금은 이 정도가 가장 현실적이고, 가장 안 터지는 구조
🔥 Step 3 — DSDL에서 Ollama 연결하기
이제 실제 설정을 해보자!
1. 설정 메뉴 위치
Splunk Web 기준 경로:
DSDL 앱 → Settings → Settings
UI가 왜 이래? 싶지만 레알임.
나도 알 수가 없음.

2. Docker 설정
🔥 중요: DSDL은 Docker 연결이 반드시 필요하다
DSDL 설정을 진행하다 보면 아래와 같은 에러를 만날 수 있다.
Please enter at least one connection, either Docker or Kubernetes
이 에러는 단순 입력 오류가 아니라, DSDL 구조를 정확히 이해하지 못했을 때 발생하는 핵심 에러
DSDL은 Docker 또는 Kubernetes 연결이 없으면 동작안함.
즉, Ollama 연결만으로는 부족
- Ollama → 모델 실행 엔진
- DSDL → 컨테이너 기반 실행 플랫폼
👉 역할 자체가 다름
DSDL은 단순 API 게이트웨이 X. 내부적으로는 아래와 같은 구조를 가진다.
DSDL
├─ Docker 연결
├─ Container 실행 (MLTK, RAG 등)
└─ LLM 호출
즉, 실제로는:
- 컨테이너를 띄우고
- 그 안에서 AI 작업을 수행하고
- 결과를 반환하는 구조
👉 그래서 Docker 연결이 없으면 “실행 환경 자체”가 없는 상태가 됨.
Step 1. Docker Remote API 활성화
DSDL이 Docker를 호출할 수 있도록 포트 열기
vi /lib/systemd/system/docker.service
아래 부분 수정:
기존
ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
수정
ExecStart=/usr/bin/dockerd -H fd:// -H tcp://0.0.0.0:2375 --containerd=/run/containerd/containerd.sock
Step 2. Docker 재시작
systemctl daemon-reload
systemctl restart dockerStep 3. 포트 확인
ss -tulnp | grep 2375
👉 결과 나오면 정상
🔥 DSDL 설정값 (정확 입력)
| 항목 | 값 |
|---|---|
| Docker host | tcp://127.0.0.1:2375 |
| Endpoint URL | http://host.docker.internal:11434 |
| External URL | http://host.docker.internal:11434 |
| Docker network | dsenv-network |
⚠ 왜 2375를 열어야 하는가
이유 1. DSDL은 컨테이너 실행 플랫폼이다
DSDL은 내부적으로 컨테이너를 생성하고 실행
- MLTK Container
- LLM-RAG Container
👉 이 작업은 Docker API를 통해 수행
이유 2. 단순 LLM 호출 구조가 아니다
지금까지 구조:
Ollama → WebUI
👉 Docker 필요 없음
하지만 DSDL부터는:
DSDL → Container 실행 → LLM 호출
👉 Docker 필수
이유 3. 설계 자체가 오케스트레이터
DSDL은 단순 연결 도구가 아니라:
- AI 실행 오케스트레이터
- 컨테이너 관리자
👉 그래서 Docker 없이 동작하지 않도록 설계
🚀 최종 체크
- Docker 2375 포트 열림 ✔
- DSDL에 Docker host 입력 ✔
3. Endpoint URL 설정
입력 권장값:
http://<서버IP>:11434
예:
http://192.168.0.10:11434
주의할 점:
http://localhost:11434→ 컨텍스트에 따라 꼬일 수 있음host.docker.internal→ 이미 실패했던 경우가 있으면 재사용 비권장
즉, 지금 단계에서는 명시적인 서버 IP를 넣는 것이 가장 안전
4. External URL 설정
External URL도 동일하게 맞춰줍니다.
http://<서버IP>:11434
내부와 외부를 다르게 잡아야 할 특별한 이유가 없는 한, 현재는 동일하게 두는 편이 가장 단순
5. Docker Network
문서상 네트워크 이름을 넣는 칸이 있다면 다음과 같이 두자.
dsenv-network
지금 단계에서는 이 값이 실질적으로 중요하지는 않음
현재 핵심은 Docker 네트워크가 아니라 Ollama endpoint 연결

페이지 하단으로 스크롤 내려서 Test & Save 클릭


6. LLM 모델 설정
메뉴:
설정 → 설정 → Setup LLM-RAG (optional)
모델 이름 입력:
hf.co/fdtn-ai/Foundation-Sec-8B-Q4_K_M-GGUF:Q4_K_M
이 모델명을 쓰는 이유
- Open WebUI에서도 확인됨
- GTX1080 8GB 환경에서 현실적으로 안정적임

✅ 연결 테스트
방법 1. DSDL UI에서 확인
설정값 입력 후 Save를 눌러 확인
이 단계에서 성공하면, DSDL이 Ollama endpoint를 정상적으로 인식한 것
방법 2. Splunk Search에서 확인
더 확실하게 보려면 SPL에서 직접 테스트
| makeresults
| ai prompt="로그인 실패 공격 분석해줘"
정상 결과가 반환되면 실제 흐름이 연결된 것
❗ 실패 시 점검 포인트
1. Ollama 접근 가능 여부 확인
curl http://<서버IP>:11434/api/tags
JSON이 반환되면 Ollama 자체는 정상
2. Splunk 서버 컨텍스트 문제
쉘에서는 접속되는데 Splunk 내부에서는 안 되는 경우가 있다.
이런 경우 localhost 대신 서버 IP를 명시적으로 넣는 것이 안전하다.
3. 모델 이름 오타 확인
모델명은 아래처럼 정확히 맞춰야 함.
hf.co/fdtn-ai/Foundation-Sec-8B-Q4_K_M-GGUF:Q4_K_M
특히 공백, 대소문자, suffix까지 다 맞아야 한다.
📌 이 단계가 중요한 이유
1. DSDL이 사실상 LLM 허브 역할을 한다
Open WebUI는 UI일 뿐이고, Ollama는 모델 실행 엔진일 뿐이다.
중간에서 파이프라인을 다루는 허브가 필요하고, 그 역할을 DSDL이 맡는다.
2. 이후 전체 구조의 중심이 된다
WebUI → DSDL → Splunk → Ollama
이 구조에서 DSDL은 단순 연결점이 아니라 전체 흐름의 중심
3. 이후 자연어 검색으로 확장할 수 있다
자연어 질문
↓
SPL 자동 생성
↓
Splunk 검색
↓
LLM 분석
↓
결과 출력
즉, 지금 단계는 단순 연결이 아니라, 자연어 기반 Splunk 검색 자동화의 출발점
✅ 최종 체크리스트
- DSDL에 Ollama endpoint 설정 완료
- 모델 선택 가능
- Test & Save 성공
- SPL에서
| ai prompt="..."동작 확인
이 네 가지가 되면 Step 3은 성공
'Splunk > Splunk Project' 카테고리의 다른 글
| Splunk Project | Ollama / AITK 모델 연동 시 발생하는 원인 박멸하기 (0) | 2026.04.14 |
|---|---|
| Splunk Project | Ollama / AITK 모델 연결 문제 해결 과정 정리 (0) | 2026.04.14 |
| Splunk Project | Splunk + Ollama + LLM 연동 구축 가이드 (실전 PoC 기준) (0) | 2026.04.01 |
| Splunk Project | Splunk 서버에 Ollama 연동 시, 아키텍처 선택 이유 (0) | 2026.04.01 |
| Splunk | Foundation-Sec-8B 모델 구조와 선택 가이드 (Ollama 기반) (0) | 2026.04.01 |