Your Agent Fix Just Broke Something Else - Sofia Jakovcevic, Arize AI

한 줄 핵심

에이전트의 변경은 코드 리뷰만으로는 안전성을 보장할 수 없으며, 생산 트레이스 기반 평가·실험·CI 게이트로 회귀를 자동화해야 진짜로 깨지지 않는 개선이 가능하다.

시간별 요약

1. 0:00
   에이전트 관측성의 필요성 에이전트는 내부 동작이 블랙박스처럼 보이기 때문에, 관측성을 통해 실제로 무엇을 하고 있는지 드러내야 디버깅과 성능 개선이 가능하다. 트레이스와 평가 지표를 함께 써야 시스템의 동작을 이해하고 반복 개선할 수 있다.
2. 1:08
   수정이 다른 문제를 망가뜨리는 현실 가장 큰 문제는 무엇이 깨졌는지를 찾는 것보다, 하나를 고친 뒤 다른 기능이 무너지지 않도록 막는 일이다. 회귀 방지 과정은 사람의 수동 점검이 아니라 CI/CD로 연결되는 자동화된 평가 프로세스여야 한다.
3. 2:26
   한 줄 프롬프트 변경이 만든 +17과 -17 안전 확인 문구를 한 줄 추가하면 action safety는 좋아질 수 있지만, task completion은 오히려 떨어질 수 있다. 단일 지표만 보면 개선처럼 보이는 변경도 전체적으로는 상쇄되거나 악화될 수 있으므로, 숫자로 검증된 다차원 평가가 필요하다.
4. 4:48
   에이전트는 코드가 아니라 런타임에서 실패한다 문제의 원인은 코드 diff 자체보다 런타임에서 실제로 벌어지는 행동 변화에 있다. 정적 코드 리뷰보다 트레이스가 더 중요한 진실의 원천이며, 회귀 테스트는 먼저 트레이스를 봐야 한다.
5. 6:25
   다섯 단계 회귀 루프 개요 회귀 방지는 생산 트레이스 수집, 평가 구축, 실험 실행, 비교, CI 게이트라는 다섯 단계로 구성된다. 이 흐름을 자동화하면 변경을 빠르게 반복하면서도 품질 기준을 지킬 수 있다.
6. 6:48
   생산 트레이스로 데이터셋 만들기 합성 데이터보다 실제 사용자 질의, 도구 호출, 실패 사례, 엣지 케이스, 성공 사례를 함께 모아야 한다. 특히 이미 잘 동작하던 워크플로를 포함해야 새로운 수정이 기존 동작을 깨지 않는지 검증할 수 있다.
7. 7:50
   평가자로 점수 매기기 hallucination, accuracy, tool trajectory, step efficiency 같은 주관적 지표를 수치화하려면 evaluator가 필요하다. LLM-as-a-judge, 코드 기반 평가, ML 기반 평가를 조합해 각 지표를 일관된 점수로 바꿔야 한다.
8. 9:48
   기준선 실험과 변경 비교 기준선은 생산 데이터셋에 기존 에이전트를 돌리고 평가 점수를 얻는 데서 시작한다. 그다음 프롬프트, 핸드오프, 도구, 모델을 바꿔가며 같은 평가를 반복해 비교하면, 배포 전에 ROI와 품질 변화를 정량적으로 확인할 수 있다.
9. 11:14
   CI에서 머지 차단하기 실험과 평가를 CI에 넣으면 각 PR이 자동으로 회귀 기준을 통과해야만 머지된다. 이렇게 하면 추측이 아니라 합의된 지표에 근거해 배포 여부를 결정할 수 있다.
10. 11:48
    Arize에서 실험하기 Arize UI에서는 단일 에이전트를 위한 prompt playground와 다중 에이전트 시스템을 위한 agent playground로 실험을 나눠 수행할 수 있다. 데이터셋, eval, latency, cost, error rate를 한곳에서 비교하면서 여러 프롬프트·모델 변경의 트레이드오프를 확인할 수 있다.
11. 15:38
    코딩 에이전트와 skills 활용 Agent skills를 쓰면 코딩 에이전트가 외부 데이터와 확장된 컨텍스트에 연결되어, IDE에서 만든 코드와 관측 백엔드의 실제 동작을 이어 붙일 수 있다. 이를 통해 개발 도구 안에서 생성한 변경을 곧바로 관측·평가 흐름과 연결할 수 있다.
12. 16:12
    에이전트 속도로 닫는 피드백 루프 실패한 트레이스는 다시 테스트 케이스가 되어 회귀 세트를 계속 강화해야 한다. 궁극적으로는 사람이 대시보드를 보고 고치는 구조를 넘어, 에이전트가 스스로 조사하고 수정안을 제안하며 자기 자신을 개선하는 방향으로 가야 한다.

실무 인사이트

• 프롬프트나 정책을 바꿀 때는 단일 성공 지표가 아니라 상충하는 지표 묶음으로 평가해야, 개선이 실제 사용자 경험 악화를 숨기지 않는다.
• 실패한 생산 트레이스를 즉시 테스트 데이터로 전환하면 회귀 방지 체계가 누적 학습되듯 강해진다.
• CI 게이트를 평가와 연결하면 배포 승인 기준이 사람의 감이 아니라 재현 가능한 숫자로 고정된다.