From Signal to PR: Anatomy of a Self-Improving Agent — Jason Lopatecki, Arize

한 줄 핵심

Observability를 사람이 보는 대시보드가 아니라 에이전트가 신호를 수집·분석·검증해 자동으로 PR까지 올리는 지속적 자기개선 루프로 재정의해야 한다는 주장이다.

시간별 요약

1. 0:01
   기존에 직접 디버깅하던 에이전트 경험에서 출발해, 관측 데이터와 자동 수정을 결합한 다음 세대의 운영 방식이 필요하다는 문제의식이 제시된다. 현재의 관측성은 인간이 클릭하며 보는 도구에 가깝지만, 앞으로는 에이전트가 시스템의 흔적을 읽고 스스로 개선 루프를 돌리는 방향으로 이동한다.
2. 3:01
   핵심은 수정 자체보다도, 수정이 맞는지 확신하고 계속 반복할 수 있는 루프를 만드는 데 있다. 이를 위해 로그·트레이스·텔레메트리를 훨씬 더 많이 남겨 에이전트가 코드 경로를 재구성하고, 인간은 응답자보다 검토자 역할로 이동한다.
3. 5:01
   에이전트가 문제를 풀려면 이벤트, 트레이스, 리포지토리, 런타임 파일 같은 컨텍스트를 조합해서 가져와야 하며, 이때 skills가 데이터 수집과 문제 정의를 결정한다. 로컬에서 하던 디버깅을 sandbox와 trigger로 옮기면, 일정 주기나 오류 발생 시점마다 같은 흐름을 자동으로 재실행할 수 있다.
4. 8:00
   실제 예시로 Alex가 에러를 기반으로 이슈를 만들고, Signal이 백그라운드에서 이를 수집해 짧은 수정안이나 더 큰 조사 흐름을 만든다. 이렇게 되면 운영자의 역할은 장애 대응자가 아니라, 충분한 근거가 붙은 이슈를 이어받아 마무리하는 사람으로 바뀐다.
5. 11:02
   제품은 AX SaaS와 Phoenix 오픈소스로 나뉘며, Signal은 AX에서 주기적으로 실행되어 GitHub 이슈 생성, evaluator 생성, 데이터셋 축적까지 연결된다. Cloud code, Arise sandbox, Daytona 같은 하네스를 선택하고, VPC 안에서 데이터 소스를 연결하며, 여러 에이전트 세션과 transcript를 관리하는 운영 화면이 함께 제공된다.
6. 16:04
   Cloud code에 데이터를 직접 연결하면 되지 않느냐는 질문에 대해, 단순 연결보다 데이터 선택과 파일화, skills 설계가 더 중요하다는 답이 나온다. 특히 traces에서 필요한 세션을 골라 repo에 넣고, Pyroscope 같은 도구의 facet를 활용하도록 skill surface area를 잘 설계해야 에이전트가 실제로 문제를 잘 찾는다.

실무 인사이트

• 에이전트 자동수정의 성패는 모델 성능보다도 어떤 traces·logs·repo 상태를 어떤 형식으로 넣어 주느냐에 달려 있으므로, 컨텍스트 수집 규격을 먼저 표준화해야 한다.
• 운영 체계를 ‘알림 → 사람 대응’에서 ‘신호 → 이슈 생성 → 에이전트 초안 수정 → 사람 검토’로 바꾸면 장애 대응 속도와 재현성이 함께 올라간다.
• eval은 사후 품질 점검이 아니라, production traces 위에 계속 얹히는 상시 감시 계층으로 설계해야 반복 실패를 자동으로 다시 잡아낼 수 있다.