오프라인에서도 작동하는 AI 산불 대응 플랫폼
모바일 네트워크 불안정 시 오프라인 우선 PWA 지원으로 비상 상황 대응 능력 강화
AI 기반 비상 안내 챗봇의 한계를 극복하기 위해 허미스 에이전트(Hermes Agent) 도입
허미스 에이전트(Hermes Agent)를 활용해 실시간 경보 및 복구 지원금 검색 기능 자동화
로컬 LLM 추론으로 외부 API 의존성 없이 안정적인 운영 환경 구축
허미스 에이전트(Hermes Agent)의 핵심 기능과 이점
허미스 에이전트(Hermes Agent)는 내장된 도구 실행(Built-in Tool Execution), 지속적인 세션 메모리(Persistent Session Memory), 그리고 자연어 기반 스케줄링(Natural Language Scheduling) 기능을 제공하여 복잡한 오케스트레이션 없이 에이전트 워크플로우를 구현할 수 있게 함.
도구 실행: 웹 검색, HTTP 호출 등 다양한 도구를 별도의 프레임워크 없이 직접 사용 가능하여 개발 복잡성 감소
세션 메모리: 사용자별 대화 기록을 유지하여 맥락을 이해하고 일관된 응답 제공, 이는 위기 상황에서 매우 중요함
스케줄링: YAML 설정만으로 정기적인 작업(예: 화재 위험 브리핑)을 예약하고 실행하여 자동화된 프로액티브 대응 가능
이러한 기능들은 상태 비저장(Stateless) 모델의 한계를 극복하고, 결정론적이고 예측 가능한 동작을 보장하여 높은 신뢰성이 요구되는 비상 대응 시스템에 적합함.
로컬 LLM 추론 환경 구축 및 최적화 전략
프로젝트는 Docker Compose를 활용하여 Ollama를 통해 로컬에서 허미스 에이전트(Hermes Agent) 및 LLM 모델(Nous Hermes 2, Gemma 2 등)을 실행함.
초기 설정: `docker compose up --build` 명령어로 모든 서비스(마이크로서비스, API 게이트웨이, DB, 메시지 큐, PWA)와 LLM 모델 다운로드 및 실행
모델 선택: `HERMES_MODEL` 환경 변수를 통해 Nous Hermes 2, Gemma 2 등 다양한 모델로 교체 가능하며, 메모리 사용량 및 응답 속도에 따라 최적화 가능 (예: 저사양 환경에서 Gemma 2 2B 모델 사용)
성능 이슈: 초기 모델 다운로드 시간(약 4.5GB)이 길 수 있으나, Docker 볼륨을 통해 캐싱되어 후속 실행은 빠름. CPU 환경에서 느린 응답 시 모델 크기 조정으로 해결
하드웨어 요구사항: 최소 8GB RAM, 16GB 권장하며, WSL2 환경에서의 네트워킹 문제 해결을 위해 Docker 메모리 할당량 조정 필요
이러한 로컬 환경 구축은 외부 API 의존성 제거 및 비용 효율성 확보에 기여함.
허미스 에이전트(Hermes Agent) vs. Llama, Gemma 2 비교 분석
로컬 LLM 추론 환경에서 허미스 에이전트(Hermes Agent)는 Llama, Gemma 2와 같은 범용 모델 대비 에이전트 특화 기능에서 강점을 보임.
Llama 3.x: 빠른 응답 속도와 준수한 성능을 보이나, 내장된 도구 실행, 세션 메모리, 스케줄링 기능 부재로 별도 오케스트레이션 레이어 필요
Gemma 2: 뛰어난 JSON 형식 준수 능력과 우수한 지시사항 이행 능력을 보이나, Llama와 마찬가지로 에이전트 기능이 없어 별도 구현 필요하며, 지식 단절(Knowledge Cutoff) 문제 발생 가능
Mistral: 과도한 면책 조항(Disclaimer)으로 인해 위기 상황 UX에 부적합하며, 이를 완화하기 위한 프롬프트 엔지니어링 비용이 높음
허미스 에이전트(Hermes Agent)는 이러한 인프라스트럭처 수준의 기능들을 YAML 설정만으로 제공하여, 개발자가 복잡한 오케스트레이션 코드 작성 없이 핵심 로직 구현에 집중할 수 있도록 함.
이벤트 기반 아키텍처와 마이크로서비스 설계
프로젝트는 이벤트 기반 아키텍처(Event-Driven Architecture)와 마이크로서비스 패턴(Microservices Pattern)을 채택하여 시스템의 유연성과 확장성을 확보함.
메시징 큐: RabbitMQ를 사용하여 서비스 간 비동기 통신을 구현, 특히 날씨 예측 → 경보 발령 파이프라인에서 데이터 흐름의 안정성 및 확장성 보장
API 게이트웨이: 단일 진입점을 제공하며, 내부 서비스(Ollama, 추천 서비스 등)로 요청을 라우팅하고 클라이언트 인증 제거 등의 역할 수행
데이터 관리: 각 서비스는 독립적인 PostgreSQL 인스턴스를 사용하며, 복구 지원금 정보는 동적 웹 검색 결과를 DB에 실시간으로 업데이트하여 최신성 유지
계약 우선 설계(Contract-First Design): OpenAPI 명세를 사용하여 서비스 간 인터페이스를 명확히 정의하고, 독립적인 개발 및 배포 지원
이러한 설계는 시스템의 복원력(Resilience)을 높이고 장애 발생 시 영향을 최소화하는 데 기여함.
AI 기반 비상 안내 및 정보 제공의 신뢰성 확보 방안
비상 상황에서 AI의 정확하고 신뢰할 수 있는 정보 제공은 매우 중요하며, 프로젝트는 이를 위해 시스템 프롬프트(System Prompt)와 도구 연동을 적극 활용함.
접지(Grounding) 강화: 시스템 프롬프트에 호주 비상 프로토콜, 000(긴급 전화번호) 에스컬레이션 지침 등을 명시하여 AI 응답의 정확성과 안전성 확보
실시간 데이터 활용: 복구 지원금 검색 시 정적 데이터베이스 대신 웹 검색 도구를 사용하여 최신 정보 반영 및 환각(Hallucination) 감소
엄격한 출력 제어: JSON 형식 준수, 요약 길이 제한 등 구체적인 출력 형식 요구를 통해 AI 응답의 일관성 및 사용성 증대
로컬 추론: 외부 API 의존성 없이 로컬에서 모델을 실행하여 네트워크 불안정 상황에서도 기능 유지 보장
이러한 접근 방식은 AI가 단순 정보 제공을 넘어, 실제 위기 상황에서 신뢰할 수 있는 조언자 역할을 수행하도록 함.
