The Missing Layer After Launch - Raphael Kalandadze, Wandero AI

한 줄 핵심

에이전트를 실제로 출시한 뒤에는 모델 성능보다 운영 루프를 얼마나 빨리 닫고, 로그·세션·브라우저까지 아우르는 메타 하네스로 시스템 건강을 지속적으로 관측·수정하느냐가 더 중요하다.

시간별 요약

1. 0:00
   에이전트는 데모에서 잘 작동하는 것보다 출시 이후 수백·수천 개의 실제 대화 속에서 어떻게 움직이는지 파악하는 일이 더 중요하다. 출시가 끝이 아니라 시작이며, 제품을 매일 개선하는 핵심은 빠른 피드백 루프다.
2. 2:01
   에이전트는 정해진 플로우가 없는 비결정적 시스템이라 사전 테스트와 단위 테스트만으로는 커버리지가 한계에 부딪힌다. 겉으로는 정상 종료처럼 보여도 실제로는 사용자 목적을 실패하는 경우가 많고, 긴 작업 중간에 숨은 실패가 조용히 누적될 수 있다.
3. 6:00
   로그는 출발점이지만, 실제 운영에는 로그를 읽고 원인과 잡음을 구분하며 PR까지 만드는 또 다른 에이전트가 필요하다. 트레이스와 코드베이스에 접근해 문제를 진단하고 수정안을 제시한 뒤, 별도의 review agent가 반박·재검증하는 구조가 운영의 핵심이 된다.
4. 9:01
   짧은 시간 안에 문제를 찾아 PR이나 Slack 알림으로 연결하는 빠른 루프와, 전체 시스템의 건강도를 보여주는 높은 수준의 관측 루프를 분리해야 한다. PR 설명, 다이어그램, 메타데이터, 리스크 요약 같은 산출물은 사람의 판단 시간을 크게 줄여준다.
5. 13:01
   세션 단위 분석은 개별 버그 수정이 아니라 시스템 건강 점수와 패턴 탐지에 초점을 둔다. 모든 대화를 점수화하고 도구 호출, sub-agent 사용, 요약 횟수, 감정·엔티티를 집계하면 수백·수천 개 대화의 이상 징후를 한눈에 볼 수 있다.
6. 16:01
   로그와 코드만으로는 부족하므로, 브라우저를 열고 실제 고객처럼 행동하는 computer use agent가 UI 문제와 사용자 관점을 보완한다. 결국 중요한 것은 모델 단독 성능이 아니라, 문제를 감지하고 이해하고 자동 수정까지 연결하는 메타 하네스를 제품 주변에 구축하는 일이다.

실무 인사이트

• 출시 직후에는 단위 테스트 확대보다 트레이스 수집, 세션 스코어링, 자동 PR 생성처럼 운영 루프를 먼저 설계해야 실제 품질 개선 속도가 붙는다.
• 사람이 매일 모든 대화를 검토할 수 없으므로, 개별 실패 탐지용 루프와 전체 건강도 관측용 루프를 분리해 병목 없이 운영하는 구조가 필요하다.
• UI·로그·DB를 함께 보는 에이전트형 관측 체계를 넣으면, 코드만 볼 때 놓치는 사용자 체감 실패를 조기에 발견할 수 있다.