C4I 방어체계 MSA(target-tracking-service / threat-intel-ai-service / defense-api-gateway / c4i-dashboard-frontend) 기반. "AI를 API로 호출해봤다" 수준을 넘어 "AI가 실제 업무 프로세스를 바꾼다"는 걸 보여주는 방향으로 강화하기 위한 실행 계획.

현재 구현 완료 현황

항목 구현 위치 비고
RAG (실시간 단일 표적 vs 고정 지식베이스) target-tracking-service — Spring AI + pgvector(HNSW) 10개 위협 패턴 코사인 유사도 검색 → Gemini SITREP 생성
규칙 기반 위협 등급 사전 평가 ThreatAnalysisService LLM 호출 전 규칙 기반 등급 산출, AI 미설정 시 단독 동작 (Graceful Degradation)
비동기 AI 분석 AsyncConfig + analyzeAsync() Kafka consumer 스레드 블로킹 방지 (aiAnalysisExecutor)
비정형 문서 RAG + 실이력 패턴 탐지 threat-intel-ai-service — LangGraph + Qdrant(2 컬렉션) /chat 하나에서 doc_rag / pattern_search 분기
Tool calling (모델이 자율 판단) threat-intel-ai-service/app/graph/tools.py Gemini function-calling으로 assess_threat_level 자율 호출
SSE 스트리밍 threat-intel-ai-service/routers/chat.py 토큰 단위 스트리밍 + tool_call/sources 이벤트
RAG 정량 평가 threat-intel-ai-service/eval/evaluate_rag.py RAGAS — faithfulness 0.751.0, answer_relevancy 0.870.91
AI 챗 프론트엔드 c4i-dashboard-frontend/src/components/ChatPanel.tsx 대시보드 내 챗 UI
K8s 배포/운영 k3s-msa-infrastructure ArgoCD, Image Updater, /ai Ingress, 비용/리소스 실측 문서

강화 방향 (우선순위)

1순위 후보였던 것 — 온프레미스/망분리 LLM → 현재 하드웨어로는 상시 운영 불가 (실측 완료)

배경: 방산/국방 AX 공고는 "외부 API(Gemini/OpenAI) 사용 불가, 망분리 환경에서 동작해야 함"이 실제 현업 제약인 경우가 많음. 지금 이 포트폴리오는 전부 Gemini API에 의존 중이라, 로컬 모델(vLLM/Ollama + Qwen/EXAONE 계열)을 하나 띄워 "인터넷 끊긴 환경에서도 동작하는 AI"를 보여주면 도메인과 정확히 맞아떨어지는 스토리가 될 것으로 판단했음.

2026-09-16 SSH 실측 결과 (100.112.104.24, multipass 호스트):

항목 값
호스트 Mac mini, Apple M2 (8-core CPU: 4P+4E, 8-core GPU)
호스트 통합 메모리 8GB (macOS는 CPU/GPU가 메모리를 공유)
호스트 디스크 228GB 중 여유 63GB
k3s-master VM 2 vCPU / 메모리 할당 2.9GiB (사용 중 1.3GiB, load avg 1.38)
k3s-worker1 VM 1 vCPU / 메모리 할당 1.4GiB (사용 중 970MiB)
k3s-worker2 VM 1 vCPU / 메모리 할당 1.7GiB (사용 중 1.3GiB, load avg 1.28)
VM 총 할당 4 vCPU / 약 6GB (호스트 8GB 중)

결론: k3s 클러스터(VM 3개)만으로 이미 8GB 중 6GB를 점유하고 있어서, macOS 자체 오버헤드를 빼면 로컬 LLM을 위한 여유 메모리가 사실상 없다. 7B8B급 양자화 모델조차 GGUF Q4 기준 최소 45GB가 필요해서 지금 구성으로는 상시 기동이 불가능. Apple Silicon Mac mini는 통합 메모리 특성상 사후 RAM 증설도 안 됨.

대안 (택1, 또는 조합):

옵션 설명 트레이드오프
A. VM 메모리 다이어트 후 초소형 모델 상시 구동 multipass set 으로 worker 메모리를 줄여 1~2GB 확보 → Qwen2.5-0.5B/1.5B-Instruct(Q4) 같은 초소형 모델을 호스트에서 직접(VM 밖) 구동 모델이 너무 작아 실용적 답변 품질은 기대하기 어려움. "동작 증명" 수준의 데모용
B. 데모 시점에만 임시 기동 평소엔 꺼두고, 시연 때만 k3s worker 1개를 잠시 내리고 그 자리에 Ollama로 7B급 모델을 임시 기동 상시 운영은 아니지만 "실제로 로컬에서 돌아간다"는 걸 증명 가능. 포트폴리오/면접 데모용으로는 충분
C. 별도 머신 확보 클라우드 GPU 인스턴스(스팟)나 다른 로컬 머신(RAM 16GB+)에 별도로 LLM 서빙 컨테이너를 올려 threat-intel-ai-service가 필요시 그쪽 엔드포인트로 라우팅 인프라가 하나 더 늘어남. 다만 "모델 라우팅(클라우드 API ↔ 온프레미스 LLM)" 자체가 새로운 스토리가 됨
D. 방향 자체를 재우선순위 하드웨어 제약을 그대로 스토리로 활용: "8GB 엣지 환경에서 로컬 LLM 서빙이 왜 어려운지 실측하고, 대신 클라우드-온프레미스 하이브리드 라우팅을 설계했다"는 분석 자체를 문서화 구현 없이도 엔지니어링 판단력을 보여줄 수 있음. 단, "직접 돌려봤다"는 임팩트는 약함

재평가: 지금 하드웨어 그대로는 1순위로 밀어붙이기 부담스럽다. B(데모용 임시 기동)가 구현 난이도 대비 가장 현실적이고, 그 다음으로 아래 2·3순위를 먼저 진행하는 편이 ROI가 높다.

2순위 — Human-in-the-loop 의사결정 루프 ✅ 구현 완료 (2026-09-16)

지금은 AI가 SITREP/위협등급을 "생성"하는 데서 끝난다. AX의 핵심은 그 결과가 실제 업무(승인/반려/에스컬레이션)에 연결되는 것.

구현 내용:

위치 내용
target-tracking-service/domain/approval/* ThreatApproval 엔티티/리포지토리/DTO/서비스/컨트롤러 신규
ThreatAnalysisService.analyze() HIGH/CRITICAL 판정 시 ThreatApprovalService.createIfNeeded() 자동 호출 (REST 수동 분석·Kafka 자동 분석 둘 다 커버)
POST /api/v1/threat-approvals/{id}/decide 승인/반려 + 결정자/사유 기록
/topic/approvals (STOMP) 승인 요청 생성·결정을 실시간 브로드캐스트
c4i-dashboard-frontend/hooks/useApprovalSocket.ts REST 초기 로드 + WebSocket 실시간 반영
c4i-dashboard-frontend/components/ApprovalPanel.tsx 대시보드 좌측 승인 대기 패널, 헤더에 대기 건수 배지
target-tracking-service/docs/threat-approval.md 설계 근거·API·WebSocket 스펙 문서화