MCP와 관측 가능성을 활용한 자가 치유 에이전트 구축
Building a Self-Healing Agent with MCP and Observability
핵심 요약
MCP와 관측 가능성 데이터를 활용해 스스로 버그를 진단하고 수정하는 자가 치유 에이전트 구축 실험에 관한 내용입니다.
- 자가 치유 에이전트 — 코드 생성 단계를 넘어 스스로 버그를 진단하고 수정하는 에이전트 구현
- 관측 가능성 활용 — 로그 대신 MCP를 통해 텔레메트리 데이터를 직접 조회하여 문제 해결
- 엔지니어링 도구 — 에이전트가 실제 엔지니어처럼 관측 가능성 계층에 접근하여 운영 효율성 증대
- 실험적 접근 — Monocle과 MCP를 결합하여 에이전트 루프 내에서 실시간 디버깅 수행
대부분의 에이전트는 코드를 생성하거나 설계된 작업을 수행할 수 있습니다.
내가 더 흥미롭게 느끼기 시작한 건 에이전트가 스스로 디버깅할 수 있는지 여부입니다.
친구 중 한 명이 Monocle과 OpenCode를 사용해 이 아이디어를 바탕으로 작은 데모를 만들었습니다. 에이전트에게 처음부터 애플리케이션을 만들라고 하는 대신, 일부러 고장 낸 Text-to-SQL 서비스와 실패하는 테스트 스위트를 줬습니다.
규칙은 간단했습니다. 로컬 로그를 읽지 말고, 수정 사항을 추측하지 말 것.
에이전트는 테스트를 실행하고, MCP를 통해 트레이스를 검사하고, 텔레메트리 데이터에서 근본 원인을 파악하고, 코드를 패치하고, 모든 것이 통과될 때까지 이 과정을 반복해야 했습니다.
흥미로웠던 점은 버그 그 자체가 아니었습니다. 애플리케이션에는 잘못된 모델 구성, 부정확한 응답 파싱, 프롬프트와 데이터베이스 간의 스키마 불일치 같은 몇 가지 문제만 있었습니다.
흥미로운 부분은 관측 가능성을 에이전트 루프의 일부로 취급했다는 점입니다.
보통 트레이스는 실패 후 사람이 보는 것이지만, 여기서는 트레이스가 에이전트의 진실의 원천(source of truth)이 되었습니다. 모든 실패는 Monocle을 통해 텔레메트리를 생성했고, 에이전트는 MCP를 통해 그 트레이스를 조회했으며, 다음 행동은 모델이 추측한 내용이 아니라 실제로 일어난 일을 기반으로 결정되었습니다.
에이전트 시스템에 있어 중요한 변화처럼 느껴집니다.
오늘날 많은 에이전트 워크플로우는 코드 생성에서 멈춥니다. 실제 운영 시스템은 디버깅, 모니터링, 장애 복구, 예상치 못한 동작 처리에 훨씬 더 많은 시간을 씁니다.
에이전트가 유용한 엔지니어링 도구가 되려면, 엔지니어들이 사용하는 것과 동일한 관측 가능성 계층에 접근할 수 있어야 할 것입니다.
이 데모는 계측을 위해 Monocle을, 텔레메트리와 에이전트 사이의 인터페이스로 MCP를 사용하여 그 방향으로 나아가는 작은 실험이었습니다.
