기존의 소프트웨어 엔지니어링에서 관측성(Observability)은 “시스템에서 무슨 일이 일어났는가”를 보여주는 것만으로도 훌륭한 역할을 했다. 하지만 비결정론적으로 움직이는 AI 에이전트 시스템에서 트레이스(Trace)와 토큰 비용을 들여다보는 것만으로는 근본적인 문제가 해결되지 않는다. 에이전트의 실패는 수많은 프롬프트, 도구 호출의 연쇄, 그리고 모델 자체의 환각이 복잡하게 얽혀 발생하기 때문이다.
“무슨 일이 일어났는지”를 확인한 후, “왜 일어났는지”, “어떻게 고칠 것인지”, 그리고 “어떻게 재발을 막을 것인지”를 알아내는 과정은 온전히 개발자의 수동 작업으로 남겨져 심각한 병목을 초래한다.
근거
Cursor의 아키텍처에서 알 수 있듯, 훌륭한 에이전트의 품질은 모델 자체가 아니라 모델을 감싸고 제어하는 하네스(Harness)의 정교함에 달려 있다. 새로운 모델이 출시되거나 도구가 추가될 때마다 실패의 엣지 케이스는 폭발적으로 증가하며, 이를 인간이 수동으로 추적하고 패치하는 루프는 지속 불가능하다.
What you don’t get is why it broke, the change that would fix it, or any promise the same thing won’t happen again next week.
Opik 같은 플랫폼이 제시하는 방향성은 명확하다. 관측성 도구는 트레이스를 보여주는 대시보드에 머물러선 안 된다. 그 트레이스를 바탕으로 코딩 에이전트가 소스를 분석해 수정안을 제안하고, 이를 즉각 회귀 테스트로 고정하는 ‘닫힌 디버깅 루프(Closed Debugging Loop)‘를 제공해야만 비로소 프로덕션 수준의 가치가 있다. 이제 관측성 도구를 평가하는 기준은 “무엇을 보여주는가”가 아니라 “고치는 과정을 얼마나 자동화하는가”가 되어야 한다.
연결된 생각
- 20260610-self-repairing-agent-harness — 모니터링, 수정, 테스트가 하나의 엔진으로 결합되어 스스로 견고해지는 시스템 구조
- observability-vs-monitoring — 관측성의 정의가 수동적인 관찰에서 능동적인 시스템 제어로 확장되는 패러다임