Designing Agents (The Floor Is the Frontier) — Ben Hylak, Raindrop

한 줄 핵심

에이전트를 개선하려면 화려한 벤치마크보다 실제 운영에서 사용자 신뢰를 깨는 ‘바닥’을 낮추는 데 집중해야 하며, 평가는 코드처럼 테스트하고 문제 탐지는 시간·영향 범위·원인 조사에 맞게 설계해야 한다.

시간별 요약

1. 0:01
   실제 세계에서 에이전트는 여전히 표준이 부족하고 계속 변하기 때문에, 이론적인 프레임워크보다 현장에서 무엇이 실제로 작동하는지에 초점을 맞춰야 한다. 그래서 발표는 일방적인 설명보다 질문과 사례 중심으로 진행되며, 특히 에이전트를 만드는 사람들이 겪는 불편한 지점을 중심으로 다룬다.
2. 2:01
   지난 1년 사이 챗봇 중심의 단순한 시기에서 벗어나, 금융·의료·국방까지 에이전트가 실제 배포되는 단계로 바뀌었다. 이 변화로 인해 문제는 단순 정답률이 아니라, 에이전트가 도구와 환경 속에서 예상 밖의 행동을 하며 때로는 유용하고 때로는 치명적인 결과를 내는 데 있다.
3. 8:00
   벤치마크를 잘 맞추는 것보다 중요한 질문은 ‘benchmark maxer’인지 ‘floor raiser’인지 구분하는 일이다. 최고 성능을 높이는 ceiling보다, 데이터 삭제·오발송·경쟁사 추천 같은 최악의 행동을 줄여 사용자 신뢰를 지키는 floor가 실제 제품에서는 더 중요하다.
4. 11:01
   offline eval은 더 이상 단순한 문자열 검사나 프롬프트 놀이터 수준으로는 충분하지 않고, 코드처럼 실행 가능한 테스트로 다뤄야 한다. 단위 테스트와 end-to-end 테스트처럼 로컬에서 돌리는 eval을 코드로 관리해야 모델·하네스·도구가 바뀌어도 유지보수성이 높아진다.
5. 13:00
   문제를 개선하려면 먼저 새로 생긴 이슈인지, 그리고 얼마나 많은 사용자가 영향을 받는지 알아야 한다. 이후에는 클러스터링만으로 문제를 정의하지 말고, code mode로 분류기를 만들어 트레이스에 적용하며, 에이전트에게 이상 탐지를 맡기기보다 이미 찾은 이상 현상을 조사시키는 방식이 더 효과적이다.

실무 인사이트

• 에이전트 품질 관리는 ‘정답률 향상’보다 ‘신뢰를 깨는 실패를 얼마나 빨리, 얼마나 적은 사용자에게서, 얼마나 작게 막는가’로 재정의하는 것이 실무에 더 유리하다.
• 평가 체계는 모델 교체와 하네스 변경을 견디도록 코드 기반으로 설계하고, 새로운 모델을 늦추는 정적인 절차보다 빠르게 돌릴 수 있는 테스트와 모니터링을 우선해야 한다.
• 운영 문제 분석에서는 클러스터 결과보다 이슈의 시작 시점과 영향 범위를 추적 가능한 형태로 구조화하는 것이 재현성과 대응 속도를 크게 높인다.