DevGuard AI: SigNoz를 기반으로 구축된 자기 관찰형 멀티 에이전트 보안 파이프라인
요약
SigNoz를 활용하여 보안 취약점을 탐지, 패치, 검증하는 자기 관찰형 멀티 에이전트 파이프라인인 DevGuard AI를 소개합니다. RAG 기반 스캐너, 수정자, 검증자 에이전트가 성찰 루프를 통해 보안 코드를 자동 개선하며, OpenTelemetry를 통해 전체 과정을 모니터링합니다.
핵심 포인트
- 스캐너, 수정자, 검증자 에이전트가 협력하는 멀티 에이전트 아키텍처
- SigNoz와 OpenTelemetry를 통한 에이전트 행동 및 비용의 실시간 관찰
- 최대 3회의 성찰 루프를 통한 자동화된 보안 패치 및 검증
- LLM 토큰 비용, 지연 시간, 캐시 효율성 등 커스텀 메트릭 대시보드 구축
문제점
수동 보안 코드 리뷰는 엔지니어 시간당 약 85달러의 비용이 발생하며, 커밋 속도(commit velocity)에 맞춰 확장하기 어렵습니다. 대부분의 AI 코드 스캐너는 "여기에 취약점이 있습니다"라고 말하는 수준에서 멈춥니다. 이들은 스스로의 수정 사항을 검증하지 않으며, 내부적으로 실제로 무엇을 하고 있는지에 대해 완전히 불투명합니다.
DevGuard AI는 "Agents of SigNoz" 해커톤을 위해 이 두 가지 문제를 해결하려는 저의 시도입니다. 취약점을 탐지하고, 패치하며, 자신의 작업을 적대적으로 검토(adversarially reviews)하고, 무엇보다 중요한 점은 SigNoz를 통해 자신을 면밀히 관찰함으로써 요청 도중에 자신의 행동을 변경할 수 있는 자율적인 파이프라인입니다.
아키텍처
요청 흐름: 브라우저 → POST /scan → FastAPI 백엔드 → 서킷 브레이커(circuit-breaker)로 감싸진 파이프라인 → 스캐너 에이전트 (RAG 증강) → 수정/검증자(Fixer/Validator) 성찰 루프 (최대 3회 시도) → 응답.
세 명의 에이전트가 실제 보안 작업을 수행합니다:
- 스캐너 (Scanner) — CWE/OWASP 지식 베이스를 바탕으로 RAG(검색 증강 생성, Retrieval-Augmented Generation)가 증강된 취약점 탐지를 수행하며, 항상 사용 가능한 가장 강력한 모델을 사용합니다 (중대한 취약점을 놓치는 비용은 더 큰 모델을 사용하는 토큰 비용보다 훨씬 비쌉니다).
- 수정자 (Fixer) — 패치를 생성하며, 재시도 시 이전 검토자의 피드백을 반영합니다.
- 검증자 (Validator) — 수정 사항이 부적절한 이유를 찾는 것이 유일한 임무인 적대적 검토자(adversarial reviewer)입니다. 이 에이전트는 자신이 "직접 배포할 만한" 수정 사항만을 통과시킵니다.
만약 검증자가 수정 사항을 거부하면, 그 피드백은 즉시 수정자의 다음 프롬프트로 전달됩니다. 이 루프는 파이프라인이 포기하고 최선의 시도 결과를 반환하기 전까지 최대 3번 반복됩니다.
SigNoz의 역할
스캐너, 각 수정자/검증자의 재시도, 서킷 브레이커의 상태 전환 등 모든 단계는 커스텀 @traced 데코레이터를 통해 OpenTelemetry 스팬(span)으로 감싸져 있습니다. SigNoz에서 단일 스캔에 대한 트레이스(trace)를 열면 전체 성찰 루프를 플레임 그래프(flame graph)로 볼 수 있습니다. 어떤 시도가 실패했는지, 각 에이전트가 얼마나 시간이 걸렸는지, 그리고 일시적인 오류 후에 LLM 호출이 정확히 어느 지점에서 재시도되었는지를 확인할 수 있습니다.
트레이싱 (Tracing) 외에도, 저는 SigNoz의 "DevGuard AI 커맨드 센터" 대시보드로 데이터를 공급하는 커스텀 OTel 메트릭 (OTel metrics)을 구축했습니다:
devguard.llm.tokens_total/devguard.llm.cost_total— 에이전트 및 모델별로 태깅된 스캔당 실제 토큰 및 비용 산정devguard.scan.latency— p50/p95/p99 패널을 구동하는 히스토그램 (Histogram)devguard.cache.hit_total/miss_total— Redis 캐시 (Cache) 효율성devguard.circuit_breaker.state_changes_total— 회복력 계층 (Resilience layer)이 작동하는 빈도
또한, 파이프라인이 단순히 누군가 확인해야 하는 대시보드에 머물지 않고 프로덕션 환경의 관점에서 스스로를 모니터링할 수 있도록 세 가지 SigNoz 알림 규칙 (Alert Rules)을 설정했습니다:
- 비용 예산 초과 (Cost Budget Exceeded) — 누적 LLM 지출이 임계값을 넘으면 발생
- SLO 저하 - 높은 지연 시간 (SLO Degradation - High Latency) — p99 스캔 지연 시간이 15초를 초과하면 발생
- 서킷 브레이커 열림 상태 고착 (Circuit Breaker Stuck Open) — 브레이커가 반복적으로 작동하여 상위 LLM 제공업체에 문제가 있음을 나타낼 때 발생
차별점: 자기 관찰형 에이전트 계층 (A Self-Observing Agent Layer)
이 부분이 제가 가장 기대하는 부분입니다. 대부분의 "AI 에이전트를 위한 관찰성 (Observability for AI agents)" 프로젝트는 단방향적입니다. 즉, 에이전트가 실행되면 SigNoz가 이를 지켜보는 방식입니다. DevGuard는 이 루프를 완성합니다. 파이프라인은 주요 결정을 내리기 전에 SigNoz의 MCP 서버를 통해 자체적인 최근 텔레메트리 (Telemetry)를 다시 읽어옵니다. 이는 SigNoz 자체 MCP 서버를 대상으로 실제 MCP 프로토콜 (streamable-HTTP, 인증됨)을 사용하는 작은 mcp_client.py를 통해 이루어지며, 실제 SigNoz 도구 이름을 반환하는 라이브 session.initialize() + list_tools() 핸드셰이크 (Handshake)를 통해 작동이 확인되었습니다.
현재 이 텔레메트리를 기반으로 두 가지 적응형 기능이 실행됩니다:
- 텔레메트리 인식 라우팅 (Telemetry-aware routing) — 최근 LLM 지출이 상승 추세라면, Fixer 에이전트를 더 저렴한 모델 티어로 라우팅할 수 있습니다. 단, 심각도가 높은 결과물은 비용 압박과 관계없이 항상 가장 강력한 모델을 사용합니다.
- 비용 가디언 (Cost Guardian) — 누적 비용 확인을 배치 (Batch) 처리하며, 세션 지출이 예산을 초과하면 글로벌 "보존 모드 (Conservation mode)" 플래그를 전환합니다.
모든 적응(adaptation)은 (a) 프론트엔드에서 표시할 수 있도록 API 응답에 포함되며, (b) 활성 OpenTelemetry 스팬(span)에 속성(attribute)으로 기록됩니다. 이를 통해 라우팅 재정의(routing override) 사항을 최종 사용자뿐만 아니라 해당 라우팅을 생성한 SigNoz 트레이스(trace) 내부에서도 확인할 수 있습니다. 또한, 전체 레이어는 의도적으로 결함 허용(fail-safe) 방식으로 설계되었습니다. SigNoz 또는 해당 MCP 서버에 접근할 수 없는 경우, 모든 함수는 스캔을 차단하는 대신 "마치 이 레이어가 존재하지 않는 것처럼 동작"하도록 성능이 저하(degrade)됩니다.
회복 탄력성 (Resilience)
파이프라인과 LLM 제공자 사이에는 직접 구현한 서킷 브레이커(circuit breaker, CLOSED/OPEN/HALF_OPEN)가 위치합니다. 제공자 측에서 오류가 발생하기 시작하면 브레이커가 작동(trip)하고, 파이프라인은 자동으로 더 저렴한 모델로 폴백(fallback)하며, 상태 전환 이벤트가 활성 스팬에 기록됩니다. 이는 애플리케이션 로그에 파묻히지 않고 SigNoz 트레이스에서 직접 확인할 수 있습니다.
시간이 더 있다면 하고 싶은 것들
- MCP 기반의 라우팅 결정이 비용 압박 상황에서뿐만 아니라 모든 스캔 시 가시적으로 트리거되도록 연결하여, 엔드 투 엔드(end-to-end) 데모를 더 쉽게 만들기
- 완전한 사후 분석(postmortem) 생성 흐름 추가: 서킷 브레이커가 작동할 때, 작은 LLM 호출을 통해 평이한 영어로 된 근본 원인 요약을 자동으로 작성하도록 하기
- 정확도 벤치마크(수동으로 라벨링된 14개의 OWASP 코드 조각, 정밀도/재현율 추적)를 대시보드에 라이브 패널로 추가하기
마치며
이번 해커톤을 위해 이를 구축하면서 시작 전에는 미처 깨닫지 못했던 사실을 다시 한번 확인했습니다. AI 파이프라인에 관측 가능성(observability)을 위한 계측(instrumenting)을 적용하는 것은 쉬운 80%에 불과합니다. 나머지 어려운 20%, 그리고 실제로 흥미로운 부분은 루프를 닫아(closing the loop) 시스템이 스스로 관찰한 내용에 대해 "행동"할 수 있게 만드는 것입니다. 단, 그 자기 관찰(self-observation)이 도움을 주려는 대상 자체를 망가뜨리지 않도록 보장하면서 말입니다.
Repo: github.com/akashbichukale0111/devguard-ai
WeMakeDevs의 SigNoz "Agents of SigNoz" 해커톤을 위해 제작되었습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기