Ollama + Gemma 기반 OOO 로그 분석 시스템 계획서

Ollama + Gemma 기반으로 OOO 로그 분석 시스템 계획서

1. 목표

데이터센터에서 수집되는 분전반 기동 이력 로그를 분석해, 이상 징후와 주요 이벤트를 식별하고 사람이 바로 검토 가능한 결과 리포트를 생성하는 시스템을 구축한다.

본 시스템은 사용자가 로컬 또는 사내 서버에 설치한 Ollama의 gemma4:e2b 모델을 활용한다. 참조한 roadmap.md의 4단계 구조는 유지하되, 서빙 계층은 초기 버전에서 vLLM 대신 Ollama HTTP API 중심으로 구현한다.

2. 범위

초기 범위는 아래 기능에 집중한다.

CSV, JSONL, TXT 형태의 분전반 기동 로그 업로드
로그 파싱 및 이벤트 정규화
장애/이상 징후 규칙 분석
RAG 기반 도메인 문서 검색
Gemma 기반 자연어 해석 및 리포트 생성
HTML, Markdown, JSON 형태의 결과 리포트 출력

초기 범위에서 제외한다.

실시간 스트리밍 분석
다중 모델 라우팅
운영용 대규모 GPU 서빙
자동 제어 명령 실행

3. 핵심 가정

사용 모델은 ollama run gemma4:e2b로 고정한다.
분전반 로그에는 최소한 timestamp, panel_id, event_type, status, message 수준의 정보가 존재한다.
도메인 지식 문서는 운전 매뉴얼, 장애 대응 절차서, 설비 점검 기준서 등으로 제공할 수 있다.
초기 릴리스는 한국어 리포트를 기본으로 하며, 기술 용어는 영문 로그 원문을 보존한다.

4. 단계별 실행 계획

단계 1. 도메인 답변 형식 고정

목표는 Gemma가 전기 설비 분석가처럼 일관된 어조와 출력 구조를 유지하게 만드는 것이다.

출력 포맷 정의
- 요약
- 주요 이벤트 타임라인
- 이상 징후
- 원인 가설
- 권장 조치
- 근거 로그
instruction dataset 설계
- 정상 시나리오
- 과전류/과부하 의심
- 반복 재기동
- 차단기 투입 실패
- 통신 오류와 실제 설비 오류 구분
1차 구현은 프롬프트 템플릿과 출력 스키마 강제로 시작
- 즉, 프로토타입 단계에서는 모델을 다시 학습시키지 않고 gemma4:e2b에 시스템 프롬프트, few-shot 예시, JSON 스키마 제약을 주어 원하는 리포트 형식을 먼저 안정화한다.
이 단계에서는 SFT 학습 자체를 수행하지 않고, 추후 파인튜닝을 위한 instruction 데이터 포맷만 정의
- 현재 생성되는 입력, 규칙 분석 결과, RAG 근거, 최종 리포트를 이후 학습 데이터로 재사용할 수 있게 저장 구조를 맞춘다.

산출물:

리포트 스키마 초안
SFT 데이터셋 규격서
프롬프트 템플릿 v1
학습 데이터 저장 포맷 초안

완료 시 눈에 보이는 결과:

샘플 로그 1건을 입력하면 Gemma가 항상 같은 섹션 구조의 JSON 초안을 반환한다.
출력에는 최소 요약, 이상 징후, 권장 조치, 근거 로그가 빠지지 않는다.
사람이 프롬프트를 조금 바꿔도 리포트 형식이 크게 흔들리지 않는다.

완료 기준:

샘플 시나리오 5건 이상에서 동일한 출력 스키마 유지
JSON 파싱 성공률 90% 이상
리포트 포맷 기준 문서와 예제 데이터셋이 저장소에 정리되어 있음

단계 2. RAG 지식 창고 구축

목표는 모델이 최신 운영 기준과 설비 매뉴얼을 근거로 답하게 만드는 것이다.

문서 수집
- 설비 운영 매뉴얼
- 알람 코드 정의서
- 점검 체크리스트
- 과거 장애 보고서
전처리
- 문서 정규화
- 표/코드/경보 ID 보존
- 700~1000 토큰 단위 chunking
임베딩 및 저장
- 초기 프로토타입: Ollama의 embeddinggemma 사용
- 고도화 대안: 검색 품질 부족 시 bge-m3 검토
- 저장소: ChromaDB
메타데이터 설계
- 문서명
- 설비 종류
- 알람 코드
- 작성일
- 중요도

산출물:

문서 적재 파이프라인
Chroma 컬렉션 스키마
검색 품질 검증 쿼리셋

완료 시 눈에 보이는 결과:

매뉴얼, 알람 코드 정의서, 점검 기준서를 적재하면 ChromaDB에 문서 chunk가 생성된다.
알람 코드나 장애 키워드로 질의하면 관련 문단 3~5개가 검색되어 반환된다.
검색 결과에는 문서명, 알람 코드, 출처 경로 같은 메타데이터가 함께 보인다.

완료 기준:

대표 문서 3종 이상 적재 완료
대표 질의 10건 기준, 상위 검색 결과에 관련 문서가 포함됨
검색 API 또는 테스트 스크립트로 결과를 재현 가능

단계 3. 로그 분석 오케스트레이션 구축

목표는 정형 규칙 분석과 LLM 추론을 결합하는 것이다.

입력 로그 파이프라인
- 파일 업로드
- 포맷 판별
- 이벤트 정규화
- 세션 단위 묶기
1차 규칙 엔진
- 반복 재기동 감지
- 특정 시간 창 내 경보 연쇄 감지
- 정상 종료 없이 재기동 발생 감지
- 오류 코드 매칭
RAG 검색
- 규칙 엔진 결과와 사용자의 질문을 조합해 검색 쿼리 생성
Gemma 생성
- 시스템 지시문
- 검색 근거
- 통계 요약
- 중요 로그 샘플
- 결과 JSON 스키마 강제

산출물:

파서 모듈
규칙 엔진
분석 오케스트레이터
리포트 생성기

완료 시 눈에 보이는 결과:

로그 파일 1개를 넣으면 파싱, 규칙 탐지, RAG 검색, Gemma 생성이 한 번에 실행된다.
결과 리포트에는 이상 징후, 원인 가설, 권장 조치, 근거 로그, 참고 문헌이 함께 표시된다.
반복 재기동이나 과전류 의심 같은 대표 패턴이 탐지 결과에 명시된다.

완료 기준:

정상 로그와 이상 로그를 각각 최소 1건 이상 end-to-end 분석 가능
규칙 엔진 탐지 결과와 LLM 최종 리포트가 같은 요청에서 연결됨
분석 결과가 JSON 구조와 Markdown 또는 HTML 형태로 동시에 생성됨

단계 4. 서비스화

목표는 현업 사용자가 브라우저에서 로그를 올리고 보고서를 받게 하는 것이다.

백엔드: FastAPI
모델 호출: Ollama API
프론트엔드: 업로드 화면 + 분석 결과 뷰어
리포트 저장: SQLite 또는 Postgres
운영 로깅
- 요청/응답 메타데이터
- 토큰/지연시간
- 분석 실패 사유

산출물:

/api/analyze
/api/reports/{id}
웹 UI
운영 배포 가이드

완료 시 눈에 보이는 결과:

브라우저에서 로그 파일을 업로드하고 분석 버튼을 누르면 결과 리포트 화면이 열린다.
생성된 리포트는 URL 또는 ID로 다시 조회할 수 있다.
최근 분석 이력이 저장되어 같은 결과를 재확인할 수 있다.

완료 기준:

FastAPI 서버 기동 후 업로드부터 결과 조회까지 UI에서 수행 가능
/api/analyze와 /api/reports/{id}가 정상 응답
분석 결과가 SQLite에 저장되고 재조회 가능

5. 프로토타입 확정 기술 스택

roadmap.md의 4단계를 맥 M3 환경에서 실제로 검증 가능한 수준으로 구현하기 위해, 프로토타입에서는 아래 스택을 확정 사용한다.

레이어	확정 기술	선택 이유
LLM Inference	Ollama + `gemma4:e2b`	맥 M3 로컬 환경에서 바로 실행 가능하며, 보고서 생성과 질의응답 검증을 빠르게 반복할 수 있다.
Backend API	FastAPI	Python 기반 파서, RAG, 리포트 생성 파이프라인을 한 서비스로 묶기 쉽고 API 문서화가 빠르다.
Orchestration	경량 커스텀 Python 파이프라인	프로토타입 단계에서는 LangChain보다 흐름 제어와 디버깅이 단순하고, 로그 분석 규칙과 RAG 조합을 직접 다루기 쉽다.
Embedding	Ollama `embeddinggemma`	현재 추론 스택과 같은 Ollama 계열로 운영할 수 있어 설치와 호출이 단순하고, 맥 M3 프로토타입에 가장 적합하다.
Vector DB	ChromaDB	로컬 파일 기반으로 간단히 시작할 수 있어 문서 적재와 검색 검증에 적합하다.
Operational DB	SQLite	단일 사용자 또는 소규모 프로토타입에서 설치 부담이 없고, 분석 이력과 리포트 저장에 충분하다.
Report Rendering	Jinja2 + HTML + Markdown + JSON	사람용 리포트와 시스템 재사용용 구조화 결과를 동시에 만들기 쉽다.
Fine-Tuning Prep	Unsloth + TRL + LoRA 데이터 구조	맥 M3에서 즉시 학습을 돌리는 것이 목적은 아니지만, 이후 GPU 환경으로 이전했을 때 바로 SFT(Supervised Fine-Tuning, 지도 미세조정)를 시작할 수 있도록 데이터 포맷을 맞춘다.

세부 설명은 아래와 같다.

Ollama + gemma4:e2b
- 실제 보고서 생성 모델이다.
- 로그 요약, 이상 징후 설명, 권장 조치 문장화, 근거 기반 자연어 리포트 작성에 사용한다.
- 프로토타입에서는 별도 서빙 엔진 없이 Ollama HTTP API를 직접 호출한다.
FastAPI
- 업로드 API, 분석 API, 리포트 조회 API를 담당한다.
- 파서, 규칙 엔진, RAG 검색, Gemma 호출을 하나의 요청 흐름으로 연결한다.
경량 커스텀 Python 파이프라인
- ingest -> normalize -> detect -> retrieve -> generate -> render 흐름을 직접 구현한다.
- 프로토타입에서 필요한 것은 복잡한 에이전트 체인이 아니라, 설명 가능한 순차 처리다.
embeddinggemma
- roadmap.md의 RAG 단계를 실동작으로 구현하기 위한 기본 임베딩 모델이다.
- Ollama + gemma4:e2b와 같은 실행 환경에서 관리할 수 있어 운영 복잡도가 낮다.
- 사내 매뉴얼, 알람 코드 정의서, 점검 기준서를 임베딩해 검색 근거로 사용한다.
- 검색 품질이 부족할 경우 2차 단계에서 bge-m3로 교체 또는 비교 평가한다.
ChromaDB
- 문서 chunk와 메타데이터를 저장하고 유사도 검색을 제공한다.
- 초기에는 로컬 디렉터리 기반으로 운영하고, 검색 품질이 검증되면 다른 벡터 저장소로 교체할 수 있다.
SQLite
- 분석 요청, 원본 로그 메타데이터, 생성된 리포트 JSON/HTML 저장용이다.
- 프로토타입에서는 Postgres보다 설정이 단순해 전체 플로우 검증에 더 적합하다.
Jinja2 + HTML + Markdown + JSON
- HTML은 현업 검토용, Markdown은 공유/보관용, JSON은 후속 자동화용으로 사용한다.
- 프론트엔드를 무겁게 가져가지 않고도 리포트 화면을 빠르게 만들 수 있다.
Unsloth + TRL + LoRA 데이터 구조
- 여기서 SFT는 Supervised Fine-Tuning의 약자로, 사람이 원하는 정답 예시를 모델에 학습시켜 출력 형식과 답변 스타일을 안정화하는 방식이다.
- 예를 들어 입력에는 규칙 분석 결과 + RAG 검색 문단 + 대표 로그를 넣고, 출력에는 표준 리포트 JSON + 자연어 설명을 넣어 학습시킨다.
- 파인튜닝을 바로 실행하는 것이 아니라, 프로토타입 산출물이 추후 SFT 데이터셋으로 누적되도록 설계한다.
- 즉, 현재 단계의 목표는 학습 인프라 완성이 아니라 학습 가능한 입출력 포맷 확보와 우수 사례 축적이다.
- 이후 GPU 환경으로 넘어가면 이 누적 데이터를 Unsloth + TRL + LoRA로 학습해, 프롬프트 의존도를 줄이고 리포트 형식 일관성을 높인다.

6. 구현 우선순위

샘플 로그 스키마 확정
로그 파서와 규칙 엔진 구현
Ollama 호출 기반 리포트 생성
RAG 문서 적재와 검색 결합
웹 UI와 저장 기능 추가
SFT 데이터셋 축적 및 파인튜닝 준비 경로 확정

7. 초기 성공 기준

정상/비정상 로그 샘플 20건에 대해 리포트 자동 생성
리포트에 근거 로그와 권장 조치가 포함됨
반복 재기동, 알람 연쇄, 미완료 기동 같은 핵심 패턴을 규칙 기반으로 검출
RAG를 통해 관련 절차서 문단을 3건 이상 근거로 제시
분석 1건당 처리 시간이 30초 이내

8. 리스크와 대응

Gemma 단독 추론의 환각
- 규칙 엔진 결과와 검색 근거를 함께 주입
로그 형식 다양성
- 파서 어댑터 구조로 설계
파인튜닝 데이터 부족
- 초기에는 프롬프트 + few-shot으로 시작
설비 도메인 용어 불일치
- 용어집과 알람 코드 사전 별도 관리

9. 다음 작업

문서 작성 이후 바로 착수할 실제 구현 순서는 아래와 같다.

샘플 로그 포맷 정의
API/디렉터리 구조 생성
파서/규칙 엔진 최소 기능 구현
Ollama 연동 테스트
리포트 템플릿 구현