We instrumented an AI agent swarm with SigNoz, and its own telemetry told us we were wrong about almost everything

개요

SigNoz 팀은 WeMakeDevs Agents of SigNoz 해커톤을 통해 DevSwarm이라는 AI 에이전트 시스템을 구축하고, SigNoz의 관찰 가능성(observability) 도구를 사용하여 시스템의 성능을 모니터링했습니다. 이 과정에서 시스템의 작동 방식에 대해 가지고 있던 거의 모든 가정이 잘못되었음을 발견했습니다.

주요 내용

* DevSwarm의 구조: DevSwarm은 하나의 프롬프트를 받아 풀스택 애플리케이션을 생성하는 AI 에이전트 시스템입니다. 5가지 역할(계획자, 프론트엔드, 백엔드, 비평가, 의사)을 수행하는 오픈 웨이트 모델들로 구성되어 있으며, 각 역할은 특정 작업에 최적화된 모델을 사용합니다. Hugging Face Inference Providers를 통해 모든 모델 호출이 이루어집니다.
* 관찰 가능성(Observability)의 중요성: 시스템의 각 단계는 OpenTelemetry 스팬으로 기록되었으며, SigNoz를 통해 실시간으로 추적 및 분석되었습니다. 이는 코드 생성 자체보다 먼저 구축되었습니다.
* 주요 발견 사항 (6가지):
1. '모델 한계'는 실제로는 자체 설정한 정적 상수 때문이었습니다. 모델 출력 토큰 수 제한이 실제로는 적용되지 않았음에도 불구하고, 개발팀이 설정한 오래된 상수가 문제를 일으켰습니다.
2. 실제 오류 원인은 '프로바이더 룰렛'이었습니다. Hugging Face 라우터가 여러 프로바이더에 모델을 로드 밸런싱하면서 각 프로바이더별로 다른 토큰 제한이 존재했고, 이로 인해 간헐적인 오류가 발생했습니다.
3. 스팬 속성이 실패 추적을 방해했습니다. 기본 모델 실패 시, 실패한 모델 대신 대체 모델의 이름으로 gen_ai.request.model 속성이 덮어쓰여 분석에 혼란을 주었습니다.
4. 비평가(review gate) 역할이 swarm 내에서 가장 약한 모델이었습니다. 자체 벤치마킹 결과, 이전 모델보다 Kimi-K2.7-Code 모델이 훨씬 더 나은 성능을 보였습니다.
5. 20%의 성공률은 계약서의 누락된 한 문장이 원인이었습니다. 필드 형식, 범위, Null 허용 여부에 대한 명확한 정의가 없어 프론트엔드와 백엔드 간 불일치가 발생했습니다.
6. 디자인 시스템이 오히려 결과물의 품질을 저하시켰습니다. 지나치게 엄격한 디자인 가이드라인이 모델이 의도한 풍부한 디자인 요소(SVG, 애니메이션, 폰트 등)를 제거하게 만들었습니다.
* 자동화된 복구 시스템 (Doctor): fallback_promotion 및 critic_catch와 같은 특정 스팬 이벤트 발생 시, swarm-doctor라는 에이전트가 트리거되어 문제를 진단하고 라우팅 테이블을 조정하는 등의 복구 작업을 수행합니다.
* 생성된 애플리케이션의 관찰 가능성: swarm이 생성하는 모든 애플리케이션은 자체 서비스 이름으로 SigNoz에 계측되어 RED 메트릭과 라우트 테이블을 제공합니다.
* LLM 경제학: 생성된 마케팅 사이트 하나가 약 34센트의 비용이 들었으며, 비평가 역할이 백엔드 작성 비용의 15배에 달하는 비용을 소모한다는 사실을 발견했습니다. 또한, 실패한 실행이 성공한 실행보다 더 많은 토큰을 사용하여 비용이 더 많이 든다는 점을 확인했습니다.
* 복제 가능한 시스템: SigNoz 설정, 대시보드, 알림 규칙 등은 모두 Git 리포지토리에 커밋되어 누구나 시스템을 재현할 수 있도록 했습니다.

시사점

AI 에이전트 시스템 개발 시, 초기 단계부터 상세한 관찰 가능성을 구축하는 것이 잘못된 가정을 발견하고 시스템의 실제 성능을 이해하는 데 필수적이며, 이는 디버깅 스킬이 프롬프트 엔지니어링이 아닌, 자신의 설정에 대한 기억보다 계측 데이터의 신뢰를 믿는 능력에 있음을 시사합니다.