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

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

1. 시스템 개요

이 시스템은 분전반 기동 이력 로그를 입력받아, 규칙 기반 분석과 Ollama의 gemma4:e2b 추론을 결합해 기술 보고서를 생성한다. 핵심은 LLM이 직접 모든 판단을 하게 두지 않고, 정형 분석 결과를 먼저 만든 뒤 이를 RAG와 함께 모델에 제공하는 하이브리드 구조다.

2. 설계 원칙

• 로그 해석의 1차 책임은 규칙 엔진이 가진다.
• LLM은 요약, 설명, 우선순위화, 보고서 문장화에 집중한다.
• 모든 주요 결론은 근거 로그 또는 문서 검색 결과를 포함해야 한다.
• 출력은 사람이 읽는 보고서와 시스템이 재사용하는 JSON 두 가지를 동시에 생성한다.
• 초기 구현은 Ollama 중심 로컬 실행을 전제로 하며, 기본 추론 모델은 gemma4:e2b로 고정한다. 이후 파인튜닝 모델로 교체 가능해야 한다.

3. 대상 사용자

• 데이터센터 전기 설비 운영자
• 유지보수 엔지니어
• 장애 분석 담당자
• 운영 리포트 검토 관리자

4. 상위 아키텍처

[Log Upload]
    ->
[Parser / Normalizer]
    ->
[Rule Engine + Metrics]
    ->
[RAG Retriever]
    ->
[Prompt Composer]
    ->
[Ollama gemma4:e2b]
    ->
[Structured Report Generator]
    ->
[HTML / Markdown / JSON Output]

5. 모듈 설계

5.1 Ingestion

역할:

• CSV, JSONL, TXT 업로드 수신
• 인코딩 자동 판별
• 헤더 매핑
• 원본 파일 저장

입력 예시:

timestamp,panel_id,event_type,status,alarm_code,message,current_a,voltage_v
2026-04-15T09:00:00Z,PANEL-A,START,OK,,Main feeder start command received,122.1,380
2026-04-15T09:00:02Z,PANEL-A,BREAKER,OK,,Breaker closed,124.2,381
2026-04-15T09:00:10Z,PANEL-A,ALARM,WARN,OC-201,Overcurrent warning detected,188.6,377

5.2 Parser / Normalizer

역할:

• 다양한 원본 필드를 내부 공통 스키마로 변환
• 시간 정렬
• 세션 분리
• 중요 필드 누락 검출

내부 이벤트 스키마:

{
  "event_id": "uuid",
  "ts": "2026-04-15T09:00:10Z",
  "panel_id": "PANEL-A",
  "event_type": "ALARM",
  "status": "WARN",
  "alarm_code": "OC-201",
  "message": "Overcurrent warning detected",
  "metrics": {
    "current_a": 188.6,
    "voltage_v": 377.0
  },
  "raw": {}
}

5.3 Rule Engine

역할:

• 빠르고 설명 가능한 이상 탐지
• LLM 입력 전 핵심 패턴 추출

초기 탐지 규칙:

• REPEATED_RESTART
  • 같은 panel_id가 짧은 시간 안에 N회 이상 기동
• START_WITHOUT_COMPLETE
  • START 이후 COMPLETE 또는 RUNNING 상태 없이 종료
• ALARM_CASCADE
  • 특정 시간 창 내 복수 알람 연쇄 발생
• OVERCURRENT_SUSPECT
  • 전류값 임계 초과 + 경보 코드 동시 발생
• BREAKER_CLOSE_FAIL
  • START 후 breaker close 이벤트 부재 또는 fail 상태
• COMMUNICATION_NOISE
  • 통신 오류만 있고 설비 상태 값은 정상

출력 예시:

{
  "incident_score": 74,
  "detections": [
    {
      "code": "REPEATED_RESTART",
      "severity": "high",
      "panel_id": "PANEL-A",
      "count": 4,
      "window_minutes": 12,
      "evidence_event_ids": ["e1", "e7", "e9"]
    }
  ],
  "stats": {
    "total_events": 284,
    "alarm_events": 11,
    "restart_count": 4
  }
}

5.4 RAG Retriever

역할:

• 규칙 엔진 결과와 질문을 기반으로 관련 문서 검색
• 운영 절차, 알람 코드 해설, 과거 장애 보고서를 근거로 제공

저장 대상 문서:

• 분전반 운전 절차서
• 차단기 투입/차단 기준서
• 알람 코드 정의서
• 점검 및 복구 매뉴얼
• 과거 장애 사례 보고서

컬렉션 메타데이터:

• doc_id
• title
• doc_type
• panel_type
• alarm_code
• revision_date
• source_path

검색 전략:

• 사용자의 자연어 질문
• 탐지 코드 목록
• 대표 알람 코드
• 패널 ID와 설비 유형

위 항목을 조합해 검색 쿼리를 생성하고, 상위 3~5개 chunk를 prompt에 주입한다.

5.5 Prompt Composer

역할:

• 규칙 분석 결과, 통계, 검색 근거, 원시 로그 일부를 한 프롬프트로 합성
• JSON 출력 형식 강제

시스템 프롬프트 초안:

너는 데이터센터 전기설비 분석 엔지니어다.
모든 결론은 제공된 로그 또는 참고 문헌에 근거해야 한다.
추측이 필요한 경우에는 반드시 "가설"로 명시하라.
리포트는 한국어로 작성하되, 로그 원문과 알람 코드는 그대로 유지하라.
출력은 반드시 지정된 JSON 스키마를 따른다.

사용자 프롬프트 구성:

[분석 대상 로그 요약]
{rule_summary}

[핵심 통계]
{stats}

[근거 로그]
{event_samples}

[참고 문헌]
{retrieved_chunks}

[요청]
분전반 기동 이력에 대한 분석 리포트를 작성하라.

5.6 LLM Adapter

역할:

• Ollama HTTP API 호출
• 타임아웃, 재시도, 모델명 관리
• JSON 모드 출력 검증

권장 호출 예시:

POST /api/generate
{
  "model": "gemma4:e2b",
  "prompt": "...",
  "stream": false,
  "format": "json"
}

초기 모델 선택:

• 기본: gemma4:e2b
• 운영 문서와 샘플 코드는 모두 gemma4:e2b를 기준으로 유지

5.7 Report Generator

역할:

• LLM JSON 응답 검증
• 누락 필드 보정
• HTML, Markdown, JSON 결과 동시 생성

출력 스키마:

{
  "summary": "PANEL-A에서 12분 내 4회의 반복 재기동이 발생했으며 과전류 경보가 동반되었다.",
  "severity": "high",
  "timeline": [
    {
      "time": "2026-04-15T09:00:00Z",
      "event": "기동 명령 수신"
    }
  ],
  "anomalies": [
    {
      "title": "반복 재기동",
      "reason": "짧은 시간 내 동일 패널에서 4회 기동"
    }
  ],
  "hypotheses": ["부하 측 과전류로 인해 차단기 재투입이 반복되었을 가능성"],
  "actions": [
    "OC-201 알람 발생 시점 전후 부하 전류 변동을 현장 계측값과 대조",
    "차단기 접점 상태와 투입 실패 이력을 점검"
  ],
  "evidence": [
    {
      "type": "log",
      "ref": "event_id:e9",
      "text": "Overcurrent warning detected"
    },
    {
      "type": "doc",
      "ref": "alarm-manual:OC-201",
      "text": "OC-201은 분기 회로 과전류 의심 경보로 분류된다."
    }
  ]
}

6. API 설계

POST /api/analyze

목적:

• 로그 파일 또는 텍스트를 받아 분석 리포트 생성

요청:

{
  "source_type": "text",
  "content": "raw log text...",
  "question": "이 로그에서 이상 징후와 조치 사항을 알려줘",
  "panel_id": "PANEL-A"
}

응답:

{
  "report_id": "rpt_001",
  "status": "completed",
  "severity": "high",
  "summary": "반복 재기동 및 과전류 의심",
  "report": {}
}

GET /api/reports/{report_id}

목적:

• 저장된 리포트 조회

GET /api/reports/{report_id}/html

목적:

• 브라우저 출력용 HTML 리포트 반환

7. 저장소 설계

초기 테이블:

• analysis_jobs
  • 요청 메타데이터
  • 처리 상태
  • 모델명
  • 실행 시간
• analysis_reports
  • 요약
  • severity
  • 최종 JSON
  • HTML 결과
• source_logs
  • 원본 파일 경로
  • 해시값
  • 패널 ID
  • 분석 시점

초기 버전은 SQLite로 충분하며, 다중 사용자 운영 시 Postgres로 이관한다.

8. 디렉터리 제안

gemma-switchgear-reporting/
  app/
    main.py
    api/
    core/
    services/
    models/
    templates/
  data/
    raw_logs/
    reports/
    chroma/
    knowledge/
  scripts/
    ingest_docs.py
    seed_sample_logs.py
    run_eval.py
  tests/

8.1 프로토타입 확정 기술 스택

이 설계는 맥 M3 환경에서 roadmap.md의 핵심 구조를 실제로 검증하는 것을 목표로 하므로, 아래 스택을 프로토타입 확정안으로 사용한다.

LLM Inference: Ollama + gemma4:e2b

• 보고서 생성의 핵심 모델이다.
• API 서버는 Ollama HTTP API를 호출해 JSON 형식의 분석 결과를 받는다.
• 초기 버전에서는 별도 GPU 서빙 엔진이나 분산 추론 구성을 두지 않는다.

Backend: FastAPI

• 업로드, 분석, 리포트 조회 API를 제공한다.
• Python 기반의 파서, 규칙 엔진, RAG 검색 모듈과 직접 연결하기 좋다.
• 프로토타입에서 OpenAPI 문서를 바로 확인할 수 있어 검증 속도가 빠르다.

Orchestration: 경량 커스텀 Python 파이프라인

• LangChain은 도입하지 않는다.
• 프로토타입의 핵심은 체인 프레임워크 사용이 아니라, 로그 분석 플로우를 명확하게 구현하는 것이다.
• 권장 흐름은 아래와 같다.

Upload
  -> Parse
  -> Normalize
  -> Rule Detect
  -> Retrieve
  -> Prompt Compose
  -> Gemma Generate
  -> Report Render

Embedding: Ollama embeddinggemma

• roadmap.md의 RAG 단계를 실제로 달성하기 위한 기본 임베딩 모델이다.
• 추론 모델과 동일하게 Ollama를 통해 호출하므로 로컬 맥 M3 환경에서 설치와 운영이 단순하다.
• 문서 적재와 질의 시 동일한 임베딩 모델을 사용해 ChromaDB 검색 일관성을 유지한다.
• 검색 품질이 기대에 못 미칠 경우, 2차 단계에서 bge-m3를 대안으로 비교 평가한다.

Vector DB: ChromaDB

• 문서 chunk와 메타데이터를 저장한다.
• 로컬 프로토타입에서 설치 부담이 적고, 검색 품질 검증이 빠르다.
• 저장 경로는 프로젝트 내 data/chroma/로 고정한다.

Operational Storage: SQLite

• 분석 작업 상태, 원본 로그 메타데이터, 최종 리포트를 저장한다.
• 단일 머신 프로토타입에서는 별도 DB 서버 없이 충분하다.
• 향후 다중 사용자 운영 시 Postgres로 이관할 수 있게 repository 계층을 분리한다.

Report Rendering: Jinja2 + HTML + Markdown + JSON

• HTML은 브라우저 검토용 결과 화면이다.
• Markdown은 보고서 공유와 보관용이다.
• JSON은 후속 자동화, 평가, 파인튜닝 데이터 축적용이다.

Fine-Tuning Preparation: Unsloth + TRL + LoRA 대응 데이터 구조

• 맥 M3 프로토타입에서 대규모 학습 자체를 목표로 두지 않는다.
• 대신 현재 생성되는 입력과 출력 데이터를 SFT 데이터셋으로 재활용할 수 있게 저장한다.
• 여기서 SFT(Supervised Fine-Tuning)는 사람이 원하는 모범 답안을 모델에 학습시켜, 출력 형식과 도메인 표현을 더 안정적으로 맞추는 지도 미세조정 방식이다.
• 예를 들어 입력은 규칙 분석 결과 + RAG 검색 근거 + 대표 로그이고, 출력은 검수된 표준 리포트 JSON + 자연어 설명이 된다.
• 즉, 프로토타입 산출물은 나중에 GPU 환경에서 LoRA 파인튜닝을 적용할 수 있는 형태여야 한다.

9. 프론트엔드 화면 제안

초기 화면은 3개면 충분하다.

• 업로드 화면
  • 파일 선택
  • 로그 예시 붙여넣기
  • 질문 입력
• 분석 결과 화면
  • 심각도 배지
  • 요약 카드
  • 타임라인
  • 이상 징후
  • 권장 조치
  • 근거 로그/문서
• 리포트 목록 화면
  • 최근 분석 이력
  • 재열람

10. 품질 관리

검증 항목:

• 파서가 잘못된 헤더를 정상 매핑하는지
• 규칙 엔진이 알려진 이상 시나리오를 놓치지 않는지
• RAG가 관련 없는 문서를 과도하게 끌어오지 않는지
• Gemma 응답이 JSON 스키마를 지키는지
• 리포트가 로그 근거 없이 단정하지 않는지

평가 데이터셋:

• 정상 기동 10건
• 경보 동반 기동 10건
• 반복 재기동 10건
• 통신 오류 노이즈 10건

11. 파인튜닝 확장 설계

초기에는 Ollama 상의 gemma4:e2b를 사용하고, 데이터가 쌓이면 아래 방식으로 확장한다.

이 항목은 프로토타입 1차 범위가 아니라 후속 확장 단계다. 즉, 초기 버전은 프롬프트 기반으로 동작을 검증하고, 운영 및 평가 과정에서 축적한 우수 사례를 나중에 SFT 데이터셋으로 전환한다.

여기서 SFT 데이터셋은 아래 같은 구조를 의미한다.

• instruction
  • 모델에게 시키는 작업 설명
• input
  • 로그 원문, 규칙 분석 결과, RAG 근거 문단 등
• output
  • 사람이 검수한 최종 리포트

이 방식의 목적은 단순 지식 추가가 아니라, 모델이 항상 같은 리포트 형식과 도메인 표현으로 답하게 만드는 데 있다.

적용 시점:

• 프롬프트만으로는 출력 형식 흔들림이 크거나
• 도메인 표현 일관성이 부족하거나
• 재현 가능한 우수 입력/출력 사례가 충분히 누적된 경우

권장 착수 조건:

• 검수된 instruction 데이터 500건 이상 확보

• 입력에는 규칙 분석 결과, RAG 근거, 대표 로그가 포함됨

• 출력에는 회사 표준 리포트 형식의 JSON과 자연어 설명이 포함됨

• 입력:

  • 규칙 분석 결과
  • RAG 문단
  • 대표 로그

• 출력:

  • 회사 표준 리포트 형식의 JSON 및 자연어 설명

학습 데이터 예시는 아래 형식을 따른다.

{
  "instruction": "분전반 기동 로그를 분석하고 표준 리포트를 작성하라.",
  "input": "규칙엔진 결과 ... / 참고문헌 ... / 로그 샘플 ...",
  "output": "요약 ... 이상 징후 ... 권장 조치 ..."
}

11.1 초보자용 설명: 왜 프로토타입을 먼저 만들고 나중에 파인튜닝하는가

처음부터 나만의 AI 모델을 만들려면 결국 파인튜닝 데이터셋이 필요하다. 다만 이 프로젝트에서는 파인튜닝부터 시작하는 것보다, 먼저 동작하는 프로토타입을 만들고 그 과정에서 좋은 데이터를 모으는 방식이 더 현실적이다.

이유는 아래와 같다.

• 처음에는 어떤 로그 형식이 실제로 들어올지 완전히 고정되어 있지 않다.
• 규칙 엔진 출력 형식도 구현하면서 바뀔 수 있다.
• RAG로 붙는 참고 문헌 형식도 초기에 조정될 가능성이 높다.
• 최종 리포트 형식 역시 실제 사용해 보면서 수정될 수 있다.

이 상태에서 학습 데이터를 먼저 대량으로 만들면, 나중에 입력 형식이나 리포트 구조가 바뀔 때 데이터셋을 다시 손봐야 한다. 그래서 먼저 프로토타입을 만들어 실제로 동작하는 입력과 출력 패턴을 확정하는 것이 유리하다.

쉽게 말하면 아래 순서다.

1. 먼저 프로토타입을 만든다.
   • 로그를 넣으면 리포트가 나오게 만든다.
2. 그 결과를 사람이 검토한다.
   • 잘 나온 결과는 저장하고, 잘못 나온 결과는 수정한다.
3. 이렇게 모은 좋은 예시를 데이터셋으로 만든다.
   • 이것이 SFT 데이터셋이다.
4. 그 데이터셋으로 파인튜닝한다.
   • 이때 비로소 내 도메인에 더 잘 맞는 나만의 모델이 된다.

즉, 프로토타입은 단지 시험용이 아니라 파인튜닝용 정답 데이터를 모으는 장치이기도 하다.

11.2 파인튜닝 데이터셋 확보 전략

이 프로젝트에서 SFT 데이터셋을 만드는 방법은 크게 3가지다.

방법 1. 프로토타입 기반 수집

가장 권장하는 방식이다.

• 사용자가 로그를 분석 요청한다.
• 시스템이 규칙 분석, RAG 검색, Gemma 리포트를 생성한다.
• 엔지니어가 결과를 검토하고 수정한다.
• 수정이 끝난 최종 결과를 학습용 정답으로 저장한다.

장점:

• 실제 시스템 입력과 정확히 같은 형태의 데이터를 쌓을 수 있다.
• 리포트 형식이 바뀌어도 최신 구조로 계속 축적 가능하다.
• 가장 실무 친화적인 데이터셋이 된다.

방법 2. 기존 문서 기반 수집

이미 과거 장애 보고서, 운영 보고서, 점검 보고서가 충분히 있다면 가능한 방식이다.

• 기존 보고서에서 질문, 입력 로그, 최종 판정 내용을 추출한다.
• 이를 instruction / input / output 구조로 변환한다.

장점:

• 프로토타입 운영 전에도 초기 데이터셋을 만들 수 있다.

주의점:

• 현재 시스템 입력 구조와 맞지 않을 수 있다.
• 규칙 엔진 결과나 RAG 근거가 빠져 있을 수 있다.

방법 3. 혼합 수집

가장 현실적인 중간안이다.

• 초기에는 기존 보고서로 소량의 데이터셋을 만든다.
• 이후에는 프로토타입 운영 중 생성되는 검수 사례를 계속 추가한다.

이 방식은 시작 속도와 데이터 품질을 둘 다 확보하기 좋다.

11.3 언제 “나만의 AI 모델”이 되는가

아래 4단계를 거치면 된다.

1. 기본 모델 사용
   • 처음에는 gemma4:e2b를 그대로 사용한다.
2. 도메인용 프로토타입 구축
   • 로그 분석, RAG, 리포트 생성이 실제로 동작하게 만든다.
3. 검수된 SFT 데이터셋 축적
   • 좋은 입력/출력 사례를 모은다.
4. LoRA 파인튜닝 수행
   • 이 시점부터는 분전반 로그 분석에 특화된 내 모델이 된다.

즉, 지금 단계에서는 아직 “내 모델”을 학습한 상태는 아니고, “내 모델을 만들기 위한 데이터와 구조를 준비하는 단계”라고 이해하면 된다.

12. 배포 시나리오

개발 단계:

• 단일 맥 M3 개발 머신
• FastAPI + Ollama + gemma4:e2b + embeddinggemma + ChromaDB + SQLite

운영 단계:

• API 서버와 Ollama 분리
• Postgres 도입
• 문서 적재 배치 분리
• 임베딩 모델 교체 또는 전용 임베딩 서비스 분리
• 장기적으로는 Ollama 대신 병합된 Gemma 서빙 엔진으로 이관 가능

13. 구현 순서 제안

1. 샘플 로그 정의 및 파서 구현
2. 규칙 엔진 구현
3. Ollama 연동과 JSON 리포트 생성
4. HTML 리포트 템플릿 생성
5. RAG 적재 및 검색 결합
6. 평가셋 기반 품질 보정
7. SFT 데이터셋 생성 및 LoRA 파인튜닝 적용