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

메타데이터

• 원문 제목: Designing Agents (The Floor Is the Frontier) — Ben Hylak, Raindrop
• 채널: aiDotEngineer (영상 메타데이터상 채널명: AI Engineer)
• 발표자: Ben Hylak, Raindrop CTO 겸 공동창업자
• 발행일: 2026-08-12 (요청 처리일: 2026-08-13)
• 영상 길이: 19분 45초
• 원문 URL: https://www.youtube.com/watch?v=jHMiYtjoJfA
• 주제: 에이전트의 오프라인 평가, 프로덕션 이슈 발견, 신뢰를 지키는 ‘바닥(floor)’ 개선
• 자막: YouTube 영어 자동 생성 자막을 바탕으로 번역·정리

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==에이전트의 최첨단 능력(ceiling)을 더 높이는 것보다, 사용자가 절대 용납하지 못할 최악의 동작(floor)을 먼저 끌어올리는 것이 실제 제품을 더 낫게 만든다.==

• 에이전트는 정해진 정답을 내는 챗봇보다 훨씬 유연하고 창의적이지만, 그 창의성이 예측 불가능하고 파괴적인 행동으로 이어질 수 있다.
• 랩의 범용 벤치마크나 ‘1,000개 평가 데이터셋’ 같은 챗봇 시대의 평가법은 모델·하네스·도구가 바뀌는 에이전트 환경에서 쉽게 낡는다.
• 실제 개선에는 발견한 이슈가 언제 시작됐는지와 몇 명의 사용자에게 영향을 주는지를 아는 운영 정보가 필수다.
• 클러스터링이나 에이전트의 자율적 이상 탐지에 모든 것을 맡기기보다, 코드로 재현 가능한 분류기와 결정론적 신호를 먼저 만들고 에이전트는 조사·분석에 사용해야 한다.

발표자는 ‘더 좋은 에이전트’를 만드는 문제를 최고 성능 경쟁(benchmark maxing)과 최악의 실패를 줄이는 바닥 올리기(floor raising)의 구분으로 설명한다. 에이전트의 무한한 문제를 모두 없애는 것은 불가능하므로, 제품·사용자·위험도에 맞춰 신뢰를 무너뜨리는 실패부터 줄이는 것이 현실적인 전략이다.

1. 챗봇에서 에이전트로: 바뀐 문제의 성격

에이전트는 단순히 다음 토큰을 예측하는 시스템이 아니라 환경을 돌아다니며 도구를 사용하고, 막히면 새로운 해결책을 만들어내는 실행 주체에 가까워졌다.

1.1. 발표의 출발점과 ‘계속 학습’의 현실

1. 발표 주제는 ‘바닥을 높이는 것’이다

   1. Ben Hylak은 청중에게 와 준 것에 감사하며, 오늘은 에이전트의 바닥(floor)을 높이는 이야기를 하겠다고 시작한다.
   2. 추상적인 프레임워크나 멋진 용어보다 실제 세계에서 무엇이 작동하고 사람들이 에이전트를 어떻게 개선하는지를 매우 실용적으로 다루겠다고 말한다.

2. 현실에는 아직 지속적 학습이 많지 않다

   1. 행사 트랙의 제목은 ‘continual learning’이지만, 실제 랩이나 제품에서 지속적 학습이 많이 적용되는 모습은 거의 보이지 않는다고 지적한다.
   2. 발표자가 20분 동안 프레임워크와 용어를 나열하는 대신 대화형 형식을 택한 이유는, 현실에 좋은 표준이나 모든 상황에 맞는(one-size-fits-all) 해법이 없기 때문이다.

3. 청중의 현장 경험을 발표의 일부로 삼는다

   1. 발표자는 슬라이드가 있기는 하지만, 에이전트를 실제로 만드는 사람들의 질문과 불편한 지점을 듣고 싶다고 한다.
   2. 온라인의 Twitter 평가(evals) 담론이 어디서 실패했는지, 실제 플로우에서 어떤 문제가 반복되는지 생각해 달라고 요청한다.
   3. 원래 Q&A에 시간을 많이 남기려 했으며, 발표 형식을 미리 정해진 강연보다 현장 대화에 가깝게 만들려 했다.

4. 슬라이드가 늦어진 것은 농담이지만 현실 인식과도 연결된다

   1. 발표자는 슬라이드를 미루다가 Fable이 늦어져 그 결과에 기대고 있었다고 농담한다.
   2. 그러나 즉흥적인 대화 형식은 단순한 준비 부족 때문이 아니라, 이 분야 자체가 빠르게 변하고 표준화되지 않았기 때문에 더 적합하다고 설명한다.

1.2. 에이전트는 왜 챗봇과 다른가

1. 1년 전과 지금의 속도 차이

   1. 불과 1년 전에는 에이전트가 거의 존재하지 않았고, 사람들은 에이전트가 계속 좋아질지조차 이야기하던 단계였다고 회고한다.
   2. 당시 대부분의 제품은 사실상 챗봇이었고, 행사 참석자들이 일반적인 시장보다 조금 앞서 있었을 뿐이라고 말한다.

2. 챗봇 시대의 평가는 정답 확인에 가까웠다

   1. 예전 평가 담론은 “미국의 수도는 어디인가?”라는 질문에 “워싱턴 D.C.”를 반환하는지 확인하는 식이었다.
   2. 챗봇의 유연성이 낮았기 때문에 사용자가 물을 질문의 정답을 미리 알고, 사실 확인용 테스트를 만들기가 비교적 쉬웠다.
   3. 발표자는 사용자가 할 질문의 약 80~90% 정도는 답을 알고 있었다는 뜻에서 당시가 더 단순했다고 설명한다.

3. 에이전트의 자기주도성과 양면성

   1. 에이전트는 환경을 돌아다니고 도구를 사용하며, 장애물에 부딪히면 매우 창의적인 우회 방법을 찾는다.
   2. 이 특성이 강력함의 근거다. 사람이 예상하지 못한 막힌 경로를 뚫어 유용한 결과를 낼 수 있다.
   3. 동시에 에이전트가 코드를 디컴파일하거나, 사용자가 가능하다고 생각하지도 못한 행동을 수행할 수 있다는 점에서 치명적일 수 있다.
   4. 창의적인 해결책은 어느 때는 도움이 되지만, 다른 때는 실제 피해를 만들어 낸다.

4. 배포 범위가 위험도와 책임을 높인다

   1. 에이전트는 금융(finance), 의료(healthcare), 국방(defense) 분야에 이미 배포되고 있다.
   2. 따라서 단순한 텍스트 품질이나 정답률만으로는 충분하지 않으며, 도구 호출과 외부 세계에 미치는 결과까지 평가해야 한다.

1.3. ‘에이전트’라는 이름과 평가의 낡은 틀

1. 발표자도 처음에는 ‘에이전트’라는 말을 싫어했다

   1. 초기에는 “그저 LLM일 뿐인데 왜 에이전트라고 부르는가”라는 입장이었고, 주변에도 같은 생각을 가진 사람이 많았다고 한다.
   2. 하지만 도구와 환경 속에서 스스로 움직이고, 장애물에 대응해 행동을 바꾸는 모습을 보면서 ‘에이전트’라는 말이 유용하다고 판단했다.

2. 대부분의 온라인 평가론은 챗봇 시대에 머물러 있다

   1. 흔히 제안되는 방식은 1,000개의 평가 데이터셋을 만들고, 미리 정한 답과 비교하는 것이다.
   2. 실제 팀 중 그렇게 하는 곳은 많지 않으며, 설령 구축해도 새 모델을 도입하거나 하네스(harness)를 바꾸는 순간 평가가 깨진다.
   3. 특정 질문에 반드시 특정 도구를 호출해야 한다는 식으로 평가를 작성하면, Claude Code CLI처럼 실행 구조가 바뀌었을 때 기존 평가의 80%가 무용해질 수 있다.

3. 변화 자체가 확실한 환경에서 안전을 설계해야 한다

   1. 발표자가 확실히 약속할 수 있는 한 가지는 시스템이 계속 변한다는 사실이다.
   2. 따라서 몇 달을 들여 변화에 묶이는 평가 세트를 만드는 일은 신중해야 하며, 평가 때문에 새 모델 도입이 늦어지는지 현실적으로 물어야 한다.
   3. 새 모델을 제품에 넣기 위해 평가를 갱신하느라 2주를 실제로 미룰 것인지 물으면, 대부분의 팀은 아니라고 답할 것이라는 게 발표자의 관찰이다.

4. 안전과 안전 극장을 구분해야 한다

   1. 목표는 더 많은 안전(safety)이지, 안전해 보이는 절차를 쌓는 안전 극장(theater)이 아니다.
   2. 평가가 실제 위험을 줄이지 못하고 변화 속도만 늦춘다면, 평가를 했다는 사실 자체가 품질을 보장하지 않는다.

2. Raindrop의 관점과 개선 문제의 재정의

Raindrop은 에이전트를 이상적인 벤치마크 점수로 재단하기보다 프로덕션에서 발생하는 이슈를 발견하고 수정이 실제로 안전한지 확인하는 데 초점을 둔다.

2.1. Raindrop이 현장에서 보는 것

1. 제품의 역할

   1. Raindrop은 프로덕션 에이전트에서 중요한 이슈를 찾는다.
   2. 수정 사항이 실제로 문제를 해결했는지, 예상하지 못한 부작용을 만들지 않았는지 검증한다.
   3. 과거 행동을 바탕으로 변경 사항이 프로덕션에 들어가기 전에 결과를 시뮬레이션한다.

2. 고객과 운영 철학

   1. 세계적인 AI 기업과 Fortune 100 기업들이 사용하며, 발표자는 아직 공개할 수 없는 로고가 많다고 말한다.
   2. 공개적으로 언급한 고객 예시는 Vercel, Speak, Framer다.
   3. 다양한 고객을 보면서 실제 세계에서 작동하는 것과 작동하지 않는 것을 가까이서 관찰할 수 있다고 설명한다.

3. 계속 바뀌는 문제에는 계속 바뀌는 접근이 필요하다

   1. Raindrop의 전제는 환경이 끊임없이 바뀐다는 것이다.
   2. 그러므로 회사가 하는 일도 계속 바뀌어야 하며, 자신과 고객에게 무엇이 작동하고 무엇이 작동하지 않는지 정직하게 말하려고 한다.
   3. 작동하지 않는 기능을 작동하는 것처럼 팔지 않는 태도가 제품 전략의 핵심이라고 밝힌다.

2.2. Workshop, Raindrop, howtoeval.com

1. Workshop: 오픈소스 추적 도구

   1. Workshop은 수천 명이 사용하는 Raindrop의 오픈소스 tracing tool이다.
   2. 에이전트가 스스로 문제를 고치는 self-healing loop를 실험할 때 특히 유용하다.
   3. 도구 자체가 할 수 없는 일이 있으면 에이전트가 그 기능을 추가할 수 있다는 확장성이 장점이다.

2. Raindrop: 에이전트용 Sentry에 가까운 호스팅 제품

   1. 호스팅 서비스인 Raindrop은 에이전트의 이슈를 감지한다.
   2. 발표자는 일반 애플리케이션의 Sentry가 오류를 감지하듯 Raindrop은 에이전트의 문제를 감지한다고 비유한다.

3. howtoeval.com: 과장 없는 평가 가이드

   1. howtoeval.com은 AI 에이전트를 평가하는 방법을 다루는 인기 리소스다.
   2. 이름 그대로 “어떻게 평가할 것인가”를 다루며, 실제로 작동하는 방법만 제시하려는 ‘no-bullshit’ 가이드라는 설명이다.

2.3. “문제를 모두 없애기”에서 “더 나은 에이전트 만들기”로

1. 근본 질문은 이슈의 목록이 아니다

   1. 핵심 질문은 “내 에이전트에 어떤 문제가 있는가?”가 아니라 “내 에이전트를 어떻게 더 좋게 만들 것인가?”다.
   2. 모든 에이전트에는 잠재적으로 해결할 수 없거나, 해결 비용을 들일 가치가 없는 문제가 생긴다.

2. 기다려야 할 개선과 지금 할 수 있는 개선을 구분한다

   1. 어떤 능력은 곧 더 좋은 기반 모델이 제공할 것이므로 직접 훈련할 필요가 없을 수 있다.
   2. 발표자는 Fable이 존재하는 상황에서 Fable 수준의 모델을 직접 훈련할 것인지 묻고, 아마도 그렇지 않을 것이라고 답한다.
   3. 언젠가 외부 모델의 발전을 제품에 통합하면 얻을 수 있는 혜택이 있으므로, 현재 가진 도구로 할 개선과 기다릴 개선 사이의 균형이 필요하다.

2.4. Benchmark maxer와 floor raiser

1. 두 종류의 개선 방향

   1. benchmark maxer는 최첨단 능력과 벤치마크 점수를 계속 높이는 사람이다.
   2. floor raiser는 시스템이 할 수 있는 최악의 행동을 줄여 사용자 신뢰의 하한선을 높이는 사람이다.

2. ‘eval’이라는 단어가 혼란을 만든다

   1. OpenAI 같은 랩이 새로운 평가 벤치마크를 발표하고, 회사가 온라인 평가를 돌리는 상황에서 모두 같은 ‘eval’이라는 단어를 쓴다.
   2. 그러나 eval은 어떤 것을 평가한다는 뜻일 뿐, 랩의 범용 벤치마크·회사의 회귀 테스트·온라인 모니터링이 같은 것은 아니다.
   3. 기업이 랩의 언어와 벤치마크를 빌려 오지만, 실제 책임과 사용할 수 있는 도구는 완전히 다르다.

3. 랩과 제품 회사의 책임은 다르다

   1. 랩은 범용 목적의 모델을 만들며 API 수준의 오류에 책임을 진다.
   2. 제품 회사는 회사별 도메인 지식, 데이터 형태, 각 데이터의 의미, 데이터에 접근하는 방법을 에이전트에 주입해야 한다.
   3. 따라서 랩용 평가를 그대로 downstream 제품에 적용하면 제품의 실제 위험을 놓칠 수 있다.

2.5. 사용자와 책임의 분배

1. 도메인 전문가가 보조를 받는가, 대체되는가

   1. 에이전트가 하는 일을 사용자가 잘 아는 도메인 전문가인지, 아니면 에이전트가 그 사람을 사실상 대체하는지가 중요한 질문이다.
   2. Copilot, Cursor의 자동완성처럼 사용자가 결과를 바로 지우거나 수정할 수 있는 증강(augmentation) 도구는 오류의 책임 일부를 사용자에게 남긴다.

2. 코딩 에이전트의 오류는 사용자가 흡수할 여지가 있다

   1. Claude Code CLI나 Codex도 자주 잘못된 일을 하지만, 엔지니어는 설치가 잘못됐거나 실행 결과가 이상한지 알아차리고 수정할 수 있다.
   2. Devin처럼 더 많은 실행을 맡기는 제품에서는 사용자가 환경을 올바르게 구성해야 하는 부분이 있고, 실패 양상도 달라진다.

3. AI 의사와 같은 제품은 바닥의 의미가 다르다

   1. AI 의사가 틀렸을 때는 사용자가 결과를 검토하고 정정할 수 있는 정도가 훨씬 제한적일 수 있다.
   2. 사용자가 도메인 전문가가 아니거나 에이전트가 전문가를 대체하는 상황일수록, 잘못된 행동의 책임과 바닥 위험이 급격히 커진다.

2.6. Ceiling보다 Floor가 신뢰를 좌우한다

1. Ceiling: 기대하지 못한 최고 능력

   1. ceiling은 제품이나 에이전트가 보여 줄 수 있는 가장 뛰어나고 놀라운 능력, 즉 사용자가 예상하지 못한 emergent capability다.
   2. 이 능력은 제품의 차별화와 감탄을 만들지만, 평균적인 신뢰를 직접 보장하지는 않는다.

2. Floor: 최악의 행동

   1. floor는 에이전트가 할 수 있는 최악의 일이다.
   2. 예시는 경쟁사를 추천하는 일, 데이터를 대량으로 삭제하는 일, 이메일 접근 권한을 이용해 고객에게 AI slop 메일을 실수로 보내는 일이다.

3. 사용자 신뢰는 하한선에서 무너진다

   1. 사용자는 놀라운 성공보다 한 번의 치명적인 실패를 더 오래 기억한다.
   2. 발표자는 GPT-4o의 아첨(sycophancy) 논란처럼 이미 본 사회적 문제들도 능력의 ceiling보다 floor의 문제에 가깝다고 말한다.
   3. 따라서 새로운 능력을 추가하는 일보다 신뢰를 깨는 최악의 행동을 줄이는 일이 제품을 실제로 더 낫게 만든다.

3. 에이전트 평가를 코드와 운영으로 바꾸기

에이전트 전체 하네스가 곧 제품의 동작 방식이므로, 평가도 프롬프트 문자열 비교가 아니라 코드로 실행되는 테스트와 운영 데이터에 가까워져야 한다.

3.1. 오프라인 평가의 재설계

1. 문자열 비교와 프롬프트 플레이그라운드의 한계

   1. 챗봇 시대에는 텍스트 출력에 특정 문자열이 들어 있는지 확인하는 방식이 흔했다.
   2. 프롬프트 플레이그라운드나 클라우드의 managed prompt를 중심으로 평가하는 도구도 있었지만, 에이전트 제품의 전체 행동을 설명하기에는 부족하다.

2. 이제 프롬프트는 전체 하네스다

   1. 에이전트에서 프롬프트 하나는 더 이상 독립된 문자열이 아니다.
   2. 연결된 코드, 도구, 실행 흐름, 상태, 하네스 전체가 함께 에이전트의 동작을 결정한다.
   3. 따라서 평가도 프롬프트 부분만 검사하기보다 전체 실행을 대상으로 해야 한다.

3. 평가는 테스트처럼 코드로 관리한다

   1. 오프라인 평가를 unit test나 end-to-end test처럼 작성하고 로컬에서 에이전트를 실행하는 방식이 적합하다.
   2. Sentry의 Vitest evals는 Vitest 위에 평가용 문법을 얹은 형태이고, OpenAI가 macro evals라고 부르는 방식도 같은 방향의 예다.
   3. 명칭보다 중요한 것은 평가를 코드로 유지해 변경 이력·재실행·회귀 검증이 가능하게 만드는 것이다.

3.2. Floor raising의 세 가지 운영 질문

1. 첫째: 보이지 않는 이슈를 발견한다

   1. 프로덕션 에이전트에는 사용자가 아직 보고하지 않은 unknown issue가 계속 생긴다.
   2. 바닥을 올리는 첫 단계는 그 문제를 자동 또는 반자동으로 발견할 수 있는 관측성을 만드는 것이다.

2. 둘째: 문제가 언제 시작됐는지 확인한다

   1. 같은 이상 현상에 대한 제보가 수천 건 쌓여도, 우선 “이것이 새로운 문제인가?”를 물어야 한다.
   2. 문제가 어제 또는 3~4일 전에 시작됐다면 모델을 바꿨는지, 하네스를 바꿨는지, downstream 의존성이 바뀌었는지 역추적할 수 있다.
   3. 오래전부터 있던 문제라면 새 회귀(regression)보다 우선순위가 낮을 수 있지만, 시작 시점을 알면 원인 후보와 대응 순서를 정할 수 있다.

3. 셋째: 영향을 받은 사용자 비율을 확인한다

   1. 세 명에게 발생한 문제와 10만 명에게 발생한 문제는 같은 현상이라도 긴급도가 완전히 다르다.
   2. 에이전트는 확률적으로 수많은 경로를 탐색하기 때문에 문제가 무한히 생길 수 있으며, 모든 문제를 같은 강도로 해결할 수 없다.
   3. 따라서 ‘언제 시작됐는가’와 ‘몇 퍼센트의 사용자가 영향을 받았는가’가 개선 우선순위의 최소 정보다.

3.3. 사용자 규모에 맞춘 실험 전략

1. 사용자 수를 먼저 묻는다

   1. 발표자가 고객에게 “무엇을 해야 하나요?”라는 질문을 받으면 가장 먼저 사용자 수를 묻는다.
   2. Raindrop에는 수백만 사용자를 가진 고객도 있고, 사용자가 다섯 명뿐인 고객도 있다.

2. 작은 사용자 수가 중요도가 낮다는 뜻은 아니다

   1. 사용자가 다섯 명뿐이어도, 기업 내부 앱에서 중요한 정보를 제공한다면 정확성이 매우 중요할 수 있다.
   2. 다만 사용자 수와 책임 구조가 다르므로 개선·검증 방법은 급격히 달라져야 한다.

3. 대규모 서비스는 실험을 활용한다

   1. 하루 1,000만·2,000만·1억 개 수준의 메시지를 처리하는 제품에서는 실험이 매우 가치 있다.
   2. 무료 티어가 있다면 그중 아주 작은 표본에 변경 사항을 적용해 새 모델이나 하네스를 검증할 수 있다.
   3. 대규모 표본에서는 작은 비율의 실험도 실제 회귀를 빠르게 발견하는 데 도움이 된다.

4. 소규모 서비스에는 A/B 테스트가 맞지 않을 수 있다

   1. 사용자가 다섯 명이나 열 명이라면 실험이나 A/B 테스트를 권하지 않는다.
   2. 표본이 너무 작아 통계적 결론을 만들기 어렵고, 개별 사용자의 맥락과 위험도를 직접 검토하는 방식이 더 적합할 수 있다.

4. Raindrop에서 얻은 세 가지 전술적 교훈

발표자는 Q&A에 들어가기 전에 이슈 발견·분석에서 얻은 세 가지 실용적 교훈을 공유한다. 경쟁사에게도 유용한 내용이라며 농담하고, 청중의 웃음과 함께 핵심 원칙을 제시한다.

4.1. 클러스터는 이슈가 아니다

1. 클러스터링은 일회성 분석에는 쓸 수 있다

   1. 모든 trace를 모아 클러스터링하면 데이터에 무엇이 존재하는지 개략적으로 볼 수 있다.
   2. 로그 더미를 몇 가지 패턴으로 바꾸는 error analysis나 탐색적 분석에는 도움이 된다.

2. 운영 이슈로는 시간축이 부족하다

   1. 일반 telemetry가 로그를 무작정 클러스터링하지 않는 이유는 소프트웨어 운영에서 문제가 언제 시작됐는지와 얼마나 커졌는지가 중요하기 때문이다.
   2. 클러스터는 시간이 지나며 경계와 구성원이 바뀌어 같은 문제를 안정적으로 추적하기 어렵다.
   3. temporal clustering 연구가 있지만, 프로덕션에서 신뢰성 있게 유지하기는 여전히 어렵다.

3. 이슈의 경계를 제품이 정한다

   1. 무엇을 같은 이슈로 볼지는 회사와 제품의 맥락에 따라 다르다.
   2. 예를 들어 잘못된 가격 견적과 잘못된 환불 계산은 모두 ‘가격 관련 문제’로 묶일 수 있지만, 실제 근본 원인은 완전히 다를 수 있다.
   3. ‘가격 문제’라는 큰 클러스터만으로는 원인·시작 시점·성장률·영향 사용자 비율을 제대로 추적할 수 없다.

4.2. Trace에는 Code Mode가 잘 맞는다

1. MCP에서 쓰는 Code Mode를 trace에 적용한다

   1. MCP 맥락에서 알려진 Code Mode의 발상을 에이전트 trace 분석에도 적용할 수 있다.
   2. 거대한 자연어 질의 하나에 모든 판단을 맡기기보다, 필요한 분류기(classifier)를 코드로 작성한다.

2. 샌드박스와 프로덕션 규모에서 실행한다

   1. 분류기를 sandbox에서 안전하게 실행해 결과를 확인할 수 있다.
   2. 같은 코드를 production scale의 trace에 적용하면 반복 가능하고 확장 가능한 이슈 분류 파이프라인이 된다.
   3. Raindrop에는 이 과정을 쉽게 만드는 기능이 있지만, 특정 제품을 쓰지 않아도 직접 구현할 수 있다는 것이 발표자의 권고다.

4.3. 에이전트에게 이상 탐지를 맡기지 않는다

1. 에이전트는 이상 탐지에 약하다

   1. 에이전트에게 “이상한 것을 전부 찾아라”라고 하면 확률적이고 개방적인 탐색 때문에 신뢰하기 어려운 결과가 나온다.
   2. 에이전트는 무엇이 정상인지에 대한 안정적인 기준을 스스로 세우기 어렵고, 무해한 변동도 이슈로 과대 해석할 수 있다.

2. 결정론적 신호로 후보를 먼저 좁힌다

   1. 키워드 빈도처럼 계산 가능한 신호를 먼저 추출한다.
   2. 특정 키워드가 갑자기 급증했다고 해서 반드시 이슈라는 뜻은 아니지만, 조사할 수 있는 구체적이고 다루기 쉬운 후보가 된다.

3. 에이전트는 후보 조사에 투입한다

   1. 결정론적 탐지기가 만든 후보를 에이전트에게 조사하게 한다.
   2. 즉, “이상 탐지”는 코드와 통계가 담당하고, “왜 이런 변화가 생겼는가”를 해석하고 관련 trace를 설명하는 일은 에이전트가 담당한다.
   3. 이 역할 분리가 에이전트의 창의성을 활용하면서도 오탐과 불안정성을 줄이는 방법이다.

주요 발언 모음

“오늘 이야기하고 싶은 것은 에이전트의 바닥을 높이는 일이다.”

“실제 세계에서 지속적 학습은 생각보다 많지 않다.”

“에이전트를 더 좋게 만드는 방법이 핵심 질문이지, 에이전트의 모든 문제를 없애는 방법이 핵심은 아니다.”

“당신은 벤치마크 점수를 올리는 사람인가, 아니면 바닥을 올리는 사람인가?”

“안전을 더 원하지만 안전 극장은 원하지 않는다.”

“클러스터는 이슈가 아니다.”

“에이전트에게 이상을 찾으라고 하지 말고, 이미 찾아낸 이상을 조사하라고 하라.”

“문제를 개선하려면 그 문제가 언제 시작됐고 몇 퍼센트의 사용자에게 영향을 주는지 알아야 한다.”

핵심 데이터 & 수치

• 19분 45초: 영상 전체 길이.
• 약 1년 전: 발표자가 에이전트가 거의 존재하지 않았고 대부분이 챗봇이던 시점으로 회고한 기간.
• 80~90%: 챗봇 시대에는 사용자가 물을 질문의 정답을 미리 알고 있었다는 설명에 등장하는 비율.
• 1,000개 평가 데이터셋: 챗봇 시대에 흔히 권장된 오프라인 평가의 상징적 예시.
• 2주: 새 모델 도입보다 평가 갱신을 위해 실제로 제품 업데이트를 미룰 것인지 묻는 가상의 기간.
• 3명 대 10만 명: 같은 이슈라도 사용자 영향 규모에 따라 우선순위가 달라지는 예시.
• 5명 또는 10명: 소규모 내부 앱의 사용자 수 예시로, A/B 테스트보다 맥락 중심 검토가 적합할 수 있다.
• 1,000만·2,000만·1억 메시지/일: 대규모 서비스에서 작은 표본 실험이 특히 유용해지는 규모의 예시.
• 수천 명: Raindrop의 오픈소스 Workshop을 사용하는 사람의 규모에 대한 발표자의 설명.

결론 및 시사점

1. 에이전트의 최고 성능을 계속 높이는 일과 사용자가 겪을 최악의 실패를 줄이는 일은 다른 작업이며, 프로덕션 신뢰에는 후자가 우선일 때가 많다.
2. 챗봇용 정답 데이터셋과 문자열 비교를 그대로 확장하지 말고, 전체 하네스를 실행하는 코드 기반 테스트로 평가를 재구성해야 한다.
3. 평가 세트는 모델·도구·하네스가 바뀌어도 불필요하게 제품의 발목을 잡지 않도록 작고 실행 가능하며 변화에 대응할 수 있어야 한다.
4. 프로덕션 이슈를 우선순위화하려면 이슈의 시작 시점과 영향을 받은 사용자 비율을 반드시 기록해야 한다.
5. 사용자 수가 수백만 명인 제품과 다섯 명뿐인 중요한 내부 앱은 같은 실험·검증 전략을 사용할 수 없다.
6. trace 클러스터는 탐색적 분석에는 유용하지만, 시간에 따른 이슈 추적과 제품별 근본 원인 관리를 대체하지 못한다.
7. 이슈 분류는 결정론적 코드와 샌드박스 실행으로 확장하고, 에이전트는 이미 좁혀진 후보의 원인 조사와 설명에 사용해야 한다.
8. 영상 후반 Q&A는 시간 부족으로 진행되지 않았고, 발표자는 이후 한 시간 동안 청중과 직접 대화하겠다고 안내했다. 이는 이 주제가 완성된 표준보다 실제 팀의 맥락과 대화에 의존한다는 메시지를 다시 강조한다.

핵심 요약 (20줄)

1. Ben Hylak은 에이전트의 최첨단 능력보다 사용자가 겪을 최악의 실패를 줄이는 ‘바닥 올리기’를 강조한다.
2. 실제 제품과 랩에서는 지속적 학습이 담론만큼 널리 구현되어 있지 않다.
3. 에이전트 분야에는 모든 제품에 맞는 단일 표준이나 평가 해법이 아직 없다.
4. 에이전트는 환경과 도구를 탐색하고 막히면 창의적인 우회책을 만드는 점에서 챗봇과 다르다.
5. 그 창의성은 유용한 해결책이 될 수도 있고 데이터를 삭제하는 재앙이 될 수도 있다.
6. 금융·의료·국방에 에이전트가 배포되면서 단순한 텍스트 정답률만으로는 안전을 설명할 수 없다.
7. 챗봇 시대의 1,000개 평가 데이터셋은 모델이나 하네스가 바뀌면 쉽게 깨질 수 있다.
8. 평가를 위해 새 모델 도입을 몇 주씩 늦추는 절차는 안전을 높이지 못하는 안전 극장이 될 수 있다.
9. 랩과 제품 회사는 책임과 보유한 도메인 지식이 다르므로 같은 벤치마크를 그대로 사용할 수 없다.
10. 사용자가 도메인 전문가인지 에이전트가 사용자를 대체하는지에 따라 허용 가능한 오류의 바닥이 달라진다.
11. ceiling은 놀라운 최고 능력이고 floor는 경쟁사 추천·데이터 삭제·잘못된 고객 메일 같은 최악의 행동이다.
12. 사용자 신뢰는 보통 최고 성능보다 한 번의 치명적 최저 성능에서 무너진다.
13. 오프라인 평가는 프롬프트 문자열보다 전체 에이전트 하네스를 실행하는 코드 기반 테스트에 가까워져야 한다.
14. 바닥을 올리려면 보이지 않는 이슈를 발견하고 시작 시점과 영향 사용자 비율을 파악해야 한다.
15. 같은 이슈가 어제 시작됐는지 오래전부터 있었는지는 모델·하네스·다운스트림 변경을 추적하는 핵심 단서다.
16. 세 명에게 발생한 문제와 10만 명에게 발생한 문제는 같은 현상이어도 우선순위가 다르다.
17. 클러스터는 일회성 탐색에는 유용하지만 시간축·경계·근본 원인을 안정적으로 보존하지 못한다.
18. MCP에서 쓰는 Code Mode처럼 trace 분류기를 코드로 만들고 샌드박스와 프로덕션 규모에서 실행하는 방법이 확장성이 높다.
19. 에이전트에게 이상을 직접 찾게 하지 말고 키워드 빈도 같은 결정론적 신호로 후보를 만든 뒤 원인을 조사하게 해야 한다.
20. 더 나은 에이전트는 모든 문제를 없애는 시스템이 아니라, 변화 속에서도 신뢰를 깨는 바닥의 문제를 빠르게 발견하고 줄이는 시스템이다.