AI 에이전트 구축 및 평가

AI Engineer 구독자 99,800명

요약

이 강연에서는 언어 모델 기반 AI 에이전트가 현재 산업·연구 현장에서 어떤 모습으로 활용되는지 짚어보고, 왜 아직 실무에서 제대로 작동하지 못하는지 세 가지 이유를 다룹니다. 첫째, 에이전트를 평가하는 과정이 복잡하고, 허위·과장된 성능 주장 사례가 빈번합니다. 둘째, 정적 벤치마크에 의존하면 비용, 환경 상호작용, 목적 특화 평가 등 핵심 요소가 누락돼 실사용 성능을 가늠하기 어렵습니다. 셋째, 모델의 능력(capability)과 일관된 신뢰성(reliability)을 혼동해 제품화 단계에서 치명적 오류를 유발하는데, 이를 해결하려면 신뢰성 엔지니어링 관점으로 전환해야 합니다.

주요 키워드

AI 에이전트 벤치마크 평가 비용(cost) 신뢰성 정적 평가 홀리스틱 리더보드 제번스 역설 능력(capability) 신뢰성 엔지니어링

하이라이트

🔑 AI 에이전트는 언어 모델이 입력·출력 필터 역할을 하며 외부 도구 호출이나 작업 수행을 제어하는 시스템의 핵심 구성요소입니다.
⚡️ DoNotPay, LexusNexis, Sakana 등 사례를 통해 과장·허위 성능 주장의 문제와 허위평가 리스크를 확인할 수 있습니다.
📌 정적 벤치마크는 입력·출력만 고려해 실제 환경에서 발생하는 상호작용이나 비용 요소를 반영하지 못합니다.
🚀 Princeton 연구진이 제안한 Holistic Agent Leaderboard로 비용과 정확도를 동시에 평가해 실용적 선택지(Pareto Frontier)를 시각화해야 합니다.
🌟 Berkeley ‘Who Validates?’ 프레임워크는 도메인 전문가가 평가 기준을 수시로 보완해 더 현실적인 벤치마크를 구축하도록 권장합니다.
🚨 모델의 능력(capability) 향상만으로는 신뢰성 보장이 어렵고, 반복적 정확도를 극대화해야 사용자에게 안정적인 경험을 제공할 수 있습니다.
🔧 시스템 설계 관점에서 불확실한 언어 모델을 감당하기 위해 신뢰성 엔지니어링 기법과 소프트웨어 최적화·추상화가 필요합니다.

용어 설명

AI 에이전트

언어 모델이 외부 도구 호출·상태 제어·피드백 처리 등을 통해 독립적 작업을 수행하는 시스템 구성요소

정적 벤치마크

고정된 입력·출력 쌍으로만 모델을 평가해 실제 환경 상호작용이나 비용을 반영하지 못하는 평가 방식

Holistic Agent Leaderboard

여러 에이전트를 비용(cost)과 성능(accuracy)을 동시에 고려해 다차원 평가하는 대시보드

Jevons Paradox(제번스 역설)

자원 단가 하락이 오히려 소비를 증가시켜 전체 비용이 늘어나는 역설적 현상

신뢰성 엔지니어링

시스템의 일관된 가용성과 정확도를 보장하기 위해 하드웨어·소프트웨어·데이터 흐름 전반을 최적화하는 공학 분야

컨퍼런스 주제인 AI 에이전트를 설명하며, 언어 모델 기반 챗봇이나 도구 호출 시스템도 에이전트로 볼 수 있다고 정의합니다. 산업·연구 현장에서의 관심 급증을 언급합니다.

[00:17] 컨퍼런스의 주제인 '에이전트의 업무'에 대해, 실제로는 에이전트가 잘 작동하지 않는 현실과 개선 방안에 대해 논의할 예정입니다.

[00:31] AI 에이전트는 현재 산업계, 학계, 연구 분야에서 큰 관심을 받고 있으며, 미래에는 대규모 시스템의 부분 요소로 활용될 것으로 예상됩니다.

[01:13] ChatGPT와 Claude와 같은 현재의 AI 도구들도 기본적인 에이전트의 형태를 가지고 있으며, 입출력 필터와 도구 호출 기능을 갖추고 있습니다.

[01:33] OpenAI의 GPT와 Deep 리서치 도구와 같은 주류 제품들이 인터넷 기반 작업과 보고서 작성 등 다양한 기능을 수행할 수 있게 되었습니다.

SF 영화 수준의 에이전트 비전과 실제 상용 제품 실패 사례를 대조하며, 진짜로 작동하는 AI 에이전트 구축의 과제를 제시합니다.

[01:54] 하지만 영화 'Her'와 같은 야심찬 AI 에이전트의 비전은 아직 현실에서 실현되지 못하고 있으며, 많은 제품들이 실패를 경험하고 있습니다.

DoNotPay, LexusNexis, Sakana 등 기업들이 성능을 과장하거나 허위주장을 한 사례를 들어, 평가 방식 부재가 초래한 실제 오류를 분석합니다.

[02:40] Do Not Pay라는 법률 AI 스타트업의 사례를 통해, 에이전트 평가의 어려움과 현실적 한계를 확인할 수 있습니다. 이 회사는 변호사 업무 자동화를 주장했지만 결국 FTC로부터 벌금을 부과받았습니다.

[03:19] 두 플레이의 성능 관련 주장들이 완전히 거짓으로 밝혀졌으며, 이는 단순한 스타트업의 실수로만 볼 수 없는 상황입니다.

[03:34] 미국의 주요 법률 기술 기업인 렉시스넥시스와 웨스트로가 출시한 '환각 현상이 없는' 법률 보고서 생성 시스템에서도 심각한 오류가 발견되었습니다.

[04:24] 과학 연구 자동화를 주장한 사카나AI의 사례에서, 프린스턴 연구팀이 개발한 코어벤치 평가 결과 40% 미만의 낮은 재현율을 보였습니다.

[05:46] 사카나AI의 시스템은 실제로 장난감 수준의 문제에만 적용 가능했고, 평가 방식도 부적절했으며, 혁신적인 연구가 아닌 사소한 개선에 불과했습니다.

[06:19] CUDA 커널 최적화 에이전트가 표준 대비 150배 성능 향상을 달성했다고 주장했으나, H100의 이론상 최대 성능보다 30배 높다는 것은 명백한 거짓이었습니다.

[06:46] 실제로는 에이전트가 CUDA 커널을 개선한 것이 아니라 단순히 보상 함수를 해킹한 것으로 밝혀졌습니다.

[07:00] 에이전트 평가는 AI 엔지니어링에서 최우선으로 다뤄져야 하는 매우 어려운 문제입니다.

에이전트는 실제 환경에서 작업하며 비용이 무한대이므로, 입력·출력만 보는 벤치마크는 오판을 부릅니다. 비용과 정확도를 모두 고려한 HAL 대시보드 솔루션을 소개합니다.

[07:23] 언어 모델과 달리 에이전트는 실제 환경과 상호작용해야 하므로, 평가 시스템 구축이 더욱 복잡합니다.

[08:06] LLM은 컨텍스트 윈도우로 평가 비용이 제한되지만, 에이전트는 무한한 상호작용이 가능해 비용 관리가 중요합니다.

[08:53] 에이전트는 특정 목적으로 만들어지므로, 범용 벤치마크 적용이 어렵습니다.

[09:11] 에이전트 평가를 위한 다차원적 지표의 필요성과 단일 벤치마크의 한계점에 대해 논의합니다.

[09:50] 프린스턴 대학에서 개발한 에이전트 리더보드를 소개하며, Claude 3.5와 OpenAI O1 모델의 성능과 비용을 비교 분석합니다.

[10:40] LLM 비용 감소 추세와 제빈스 패러독스에 대해 설명하며, 기술 발전에 따른 비용과 사용량의 관계를 분석합니다.

[12:01] ATM 도입 사례를 통해 기술 혁신이 가져온 예상치 못한 결과를 설명합니다.

[12:16] ATM 도입으로 인해 은행 지점과 창구 직원이 오히려 증가했던 사례를 들며, 언어 모델 비용 감소에 따른 유사한 현상을 예측합니다.

[12:40] 홀리스틱 에이전트 리더보드(HAL)를 통해 11개의 벤치마크에서 자동화된 에이전트 평가 시스템을 구축했습니다.

[13:03] VC들이 벤치마크 성과를 투자 기준으로 삼는 문제점을 지적하며, Cognition의 사례를 들어 벤치마크 성능이 실제 성능과 차이가 있음을 설명합니다.

[14:04] 버클리 연구진이 제안한 '검증자를 누가 검증하는가' 프레임워크를 소개하며, 도메인 전문가가 참여하는 평가 방식의 중요성을 강조합니다.

모델의 최대 성능(capability)과 반복적 정확도(reliability)를 구분해, 에이전트 제품화 시 안정성을 확보해야 함을 강조하며 신뢰성 엔지니어링 전환을 제안합니다.

[14:48] AI 시스템의 '능력(capability)'과 '신뢰성(reliability)'의 차이를 설명하며, 기술적 관점에서 pass@K 정확도의 의미를 소개합니다.

[15:10] 신뢰성은 매번 정확한 답변을 도출하는 것을 의미하며, 실제 환경에서의 의사결정에는 역량보다 신뢰성이 중요합니다.

[15:22] 언어 모델은 이미 많은 기능을 수행할 수 있지만, 이를 신뢰할 수 있는 사용자 경험으로 착각하면 실제 제품에서 문제가 발생합니다.

[15:37] 90% 성능 달성은 ML 엔지니어의 영역이지만, 99.999%의 신뢰성 달성은 AI 엔지니어의 역할입니다.

[16:05] Humane, Spin, Rabbit R1과 같은 제품들의 실패는 신뢰성 부족을 예상하지 못한 결과입니다.

[16:26] 검증기(단위 테스트)를 통한 해결책이 제안되었으나, 거짓 양성으로 인해 완벽한 해결책이 되지 못했습니다.

[17:29] AI 엔지니어링은 확률적 시스템의 제약을 다루는 신뢰성 엔지니어링으로 접근해야 합니다.

[18:09] AI 엔지니어의 역할과 ENIAC 컴퓨터의 역사적 사례를 통해 신뢰성의 중요성을 설명합니다.

[18:36] 초기 ENIAC의 문제점과 엔지니어들이 신뢰성 향상을 위해 노력했던 경험을 공유합니다.

[18:58] AI 엔지니어의 진정한 임무는 우수한 제품 개발을 넘어 신뢰성 문제 해결에 있음을 강조합니다.

[00:00] [음악]

[00:17] 오늘 컨퍼런스의 주제는

[00:19] AI 에이전트의 업무에 관한 것입니다만

[00:22] 앞으로 18분 동안은

[00:24] 에이전트가 잘 작동하지 않는 이유와

[00:26] AI 엔지니어링을 개선하는 방법에 대해

[00:28] 제가 이야기를 하게 될 것 같네요

[00:31] 현재 AI 에이전트에 대한 관심이

[00:33] 제품 분야와 산업계,

[00:35] 학계 연구실, 연구 분야 등

[00:38] 모든 영역에서 매우 높습니다

[00:41] 만약 기업들이 언어 모델을

[00:43] AGI 수준까지 확장할 수 없다고 생각한다면

[00:46] 가까운 미래에는

[00:48] 직접 배포되지 않는 에이전트들이

[00:51] 더 많이 등장할 것입니다

[00:53] 이들은 더 큰 제품과 시스템의

[00:55] 작은 부분으로 기능할 것이고, 이것이

[00:58] 가까운 미래의

[01:00] AI의 모습일 것입니다

[01:02] Swix는 AI 에이전트에 대한

[01:05] 여러 가지 정의를 제시했는데

[01:07] 그중 하나는 언어 모델이

[01:09] 특정 시스템의 흐름을 제어하는 것입니다

[01:13] 실제로 사람들이 ChatGPT와 Claude를 단순한 모델로 생각할 때도

[01:17] 이러한 도구들은 사실

[01:19] 기초적인 에이전트의 예시입니다

[01:21] 입출력 필터를 가지고 있고

[01:24] 특정 작업을 수행할 수 있으며

[01:25] 도구들을 호출할 수 있죠

[01:28] 어떤 면에서 에이전트는 이미 널리 사용되고 있으며

[01:32] 성공적입니다

[01:33] 이제 우리는 주류 제품들이

[01:35] 더 많은 기능을 수행하는 것을 보고 있습니다

[01:37] OpenAI의 GPT는 인터넷에서

[01:40] 개방형 작업을 수행할 수 있고

[01:42] Deep 리서치 도구는 30분 동안

[01:45] 어떤 주제에 대해서도

[01:47] 보고서를 작성할 수 있습니다

[01:49] 이것이 오늘 컨퍼런스가 시의적절한

[01:51] 첫 번째 이유입니다

[01:54] 하지만 반대로 두 번째 이유는

[01:56] 더 야심찬 에이전트의 비전이

[01:59] 아직 실현되지 않았다는 점입니다

[02:01] 왼쪽에 보이는 것이 에이전트가 할 수 있는 것에 대한 비전으로

[02:04] 영화 'Her'와 같은 공상과학 영화에서 나온 것이고

[02:06] 오른쪽에는 이러한 야심찬 제품들이

[02:08] 현실 세계에서 실패한 사례들입니다

[02:11] 이를 지적하는 이유는

[02:13] 특정 제품을 비판하기 위해서가 아니라

[02:15] 청중 여러분들에게

[02:17] 진정한 도전 과제를 제시하고자 함입니다

[02:20] 그것은 바로

[02:21] 사용자들에게 실제로 도움이 되는

[02:23] AI 에이전트를 만드는 것입니다

[02:25] 이 발표를 통해

[02:28] 세 가지 주요 이유에 대해 말씀드리겠습니다

[02:30] 에이전트가 아직 제대로 작동하지 않는 이유와

[02:33] 에이전트의 잠재력을 실현하기 위해

[02:35] 이러한 실패를 극복할 수 있는

[02:38] 방법에 대해서입니다

[02:40] 첫 번째는 에이전트를 평가하는 것이

[02:43] 진정으로 어렵다는 점입니다

[02:46] 에이전트를 제품화하려 했을 때

[02:48] 실제로 실패한 사례들을

[02:50] 살펴보겠습니다

[02:51] Do Not Pay는 미국의 스타트업으로

[02:54] 변호사의 모든 업무를 자동화할 수 있다고

[02:57] 주장했습니다. 스타트업의 공동 창업자는

[03:00] Do Not Pay를 이어피스로 사용하여

[03:02] 미국 대법원에서

[03:04] 변론할 변호사에게 백만 달러를 제안했습니다

[03:07] 하지만

[03:09] 현실에서는 몇 년 후

[03:12] 최근 FTC가 Do Not Pay에

[03:15] 수십만 달러의 벌금을 부과했습니다

[03:16] 벌금의 이유는 그들이 주장한

[03:19] 두 플레이가 내세웠던

[03:21] 성능 관련 주장들이 사실은

[03:23] 완전히 거짓으로 밝혀졌습니다. 이를 단순히

[03:26] 작은 스타트업의 성급한 발명이나

[03:29] 근거 없는 주장이라고만 볼 수는 없습니다.

[03:31] 이제 더 큰 규모의

[03:33] 유명 기업들의 사례를 살펴보겠습니다.

[03:34] 로펌 렉시스넥시스와

[03:37] 웨스트로는 미국에서

[03:39] 법률 기술 분야를 선도하는

[03:41] 기업으로 잘 알려져 있습니다. 몇 년 전 렉시스넥시스는

[03:45] 법률 보고서와

[03:47] 법적 추론을 생성할 때 환각 현상이

[03:49] 전혀 없다고 주장하는

[03:52] 제품을 출시했습니다. 하지만 스탠포드 연구진이

[03:54] 렉시스넥시스와 웨스트로의

[03:56] 제품들을 평가한 결과,

[03:59] 최대 3분의 1, 최소 6분의 1의

[04:01] 사례에서 이 언어 모델들이

[04:04] 환각 현상을 보였습니다. 특히 일부

[04:07] 사례에서는 이러한 환각이

[04:09] 원래 법률 텍스트의 의도를

[04:11] 완전히 반대로 해석했고, 다른 경우에는

[04:13] 문단 자체를 완전히 지어냈습니다.

[04:15] 이러한 오류의 사례가 약 200개나 발견되었는데,

[04:18] 이는 모두 주요 법률 기술

[04:20] 제품들에서 발견된 것입니다. AI 에이전트가

[04:24] 곧 모든 과학 연구를 자동화할 것이라는

[04:27] 주장도 있었습니다. 스타트업 사카나AI의 사례를 보면,

[04:29] 이들은 자신들이 개발한 AI가

[04:32] 완전히 자동화된 방식으로

[04:33] 개방형 과학 연구를

[04:35] 수행할 수 있다고 주장했습니다. 우리 프린스턴 팀은

[04:37] 이 주장을 실제로 검증하고자 했는데,

[04:39] 이는 부분적으로

[04:41] 과학 연구의 자동화가 우리의

[04:44] 주요 연구 관심사였기 때문입니다. 그래서 우리는

[04:46] 벤치마크를 만들었고, 이를

[04:48] 코어벤치(CoreBench)라고 명명했습니다. 이

[04:51] 벤치마크의 과제들은 실제 세계의

[04:54] 개방형 과학 연구에서 기대되는 것보다

[04:56] 훨씬 단순했습니다. 단지 논문의 결과를

[04:58] 재현하는 것이 목표였고,

[05:01] 에이전트에게 코드와

[05:03] 데이터까지 제공했습니다. 아시다시피

[05:05] 이는 모든 과학을

[05:07] 자동화하는 것보다

[05:09] 훨씬 단순한 작업입니다. 우리가 발견한 바로는,

[05:13] 현재 최고의 에이전트조차도 과학 연구를

[05:16] 신뢰성 있게 자동화하지 못했고,

[05:18] 논문의 40% 미만만이 재현

[05:21] 가능했습니다. 물론

[05:23] 이러한 모델들이 계속 발전하고 있고,

[05:25] 에이전트가 40%의 재현성만 확보하더라도

[05:27] 이는 큰 진전입니다. 연구자들이

[05:29] 과거 결과를 재현하는 데

[05:32] 많은 시간을 투자하기 때문입니다.

[05:34] 하지만 이를 근거로 AI가 곧

[05:38] 모든 과학을 자동화할 수 있다거나

[05:41] AI 에이전트가 과학 연구자들을

[05:43] 쓸모없게 만들 것이라고 주장하는 것은

[05:46] 너무 성급합니다. 실제로 사람들이

[05:49] 사카나AI의 AI

[05:51] 과학자를 자세히 살펴보니, 이는

[05:53] 장난감 수준의 문제에만 적용되었고,

[05:57] 인간 동료 평가가 아닌 LLM으로만 평가되었으며,

[05:59] 실제로 자세히 들여다보면

[06:01] 그 결과물은

[06:02] 다른 논문들의 아주 사소한

[06:05] 개선에 불과했습니다. 이는 학부생 연구 프로젝트 수준이지

[06:07] 과학 전체를

[06:09] 자동화하는 수준과는

[06:11] 거리가 멉니다. 며칠 전 제가

[06:14] 이 발표를 준비하는 동안

[06:15] 사카나가 새로운 주장을

[06:17] 내놓았는데

[06:19] 이들은 CUDA 커널을 최적화하는

[06:22] 에이전트를 만들었다고 주장했고, 그 성과는

[06:25] 매우 인상적이었습니다. 표준 CUDA 커널보다

[06:27] 150배 더 뛰어난 성능을

[06:29] 보여줬다고 했죠. 하지만 문제는

[06:32] 이 주장을 좀 더 깊이 분석해보면

[06:34] 그들이 H100의 이론상 최대 성능보다

[06:37] 30배나 더 뛰어난 성능을

[06:39] 달성했다고 주장한다는 것이었습니다.

[06:41] 이는 명백히 거짓된 주장이었고,

[06:44] 이 역시 엄격한 평가가 부족했기 때문입니다.

[06:46] 결국 이 에이전트는 실제로

[06:49] CUDA 커널을 개선한 것이 아니라

[06:50] 단순히 보상 함수를 해킹한 것으로 밝혀졌습니다.

[06:53] 여기서 중요한 점은 특정 회사를 지적하는 것이 아니라

[06:55] 에이전트 평가가

[06:57] 진정으로 어려운 문제라는 것을 강조하는 것입니다.

[07:00] 이는 AI 엔지니어링 도구에서

[07:03] 최우선으로 다뤄져야 하는 문제입니다.

[07:06] 그렇지 않으면 우리는 계속해서

[07:08] 이런 실패 사례들을 마주하게 될 것입니다.

[07:10] 실제 환경에서 작동하는 에이전트를 만드는 것이

[07:13] 어려운 두 번째 이유는

[07:16] 정적 벤치마크가

[07:18] 에이전트의 실제 성능을 평가할 때

[07:20] 매우 오해의 소지가 있기 때문입니다.

[07:22] 그 이유는

[07:23] 우리가 오랫동안

[07:25] 대규모 언어 모델을 평가하는 데

[07:28] 잘 작동하는 평가 방식에만

[07:30] 집중해왔기 때문입니다.

[07:32] 하지만 에이전트는 모델과 다릅니다.

[07:35] 예를 들어, 대부분의 언어 모델 평가에서는

[07:37] 입력 문자열과 출력 문자열만

[07:40] 고려하면 됩니다.

[07:42] 이것이 언어 모델이 작동하는 영역이고

[07:44] 평가를 구성하는 데 충분합니다.

[07:46] 하지만 반대로

[07:48] 에이전트를 생각할 때는

[07:50] 이 에이전트들이 실제 세계에서

[07:52] 행동을 취해야 하고 환경과

[07:54] 상호작용해야 합니다.

[07:56] 따라서 이런 변화를 가능하게 하는

[07:59] 평가 시스템을 구축하고

[08:01] 에이전트가 작동할 가상 환경을

[08:02] 만드는 것은 훨씬 더

[08:05] 어려운 문제입니다.

[08:06] 에이전트 평가의 두 번째 어려움은

[08:08] LLM의 경우 모델 평가 비용이

[08:12] 언어 모델의 컨텍스트 윈도우 길이로

[08:14] 제한된다는 것입니다.

[08:16] 이러한 평가들은 기본적으로

[08:19] 고정된 상한선이 있다고 볼 수 있습니다.

[08:21] 하지만 실제 세계에서

[08:23] 자유로운 행동을 할 수 있는 에이전트의 경우

[08:25] 이런 상한선이 없습니다.

[08:28] 에이전트가 다른 하위 에이전트를 호출하거나

[08:30] 재귀적으로 동작할 수 있고

[08:32] 다양한 시스템이 있을 수 있습니다.

[08:34] 예를 들어 for 루프 안의 LLM 호출처럼요.

[08:37] 이 때문에 비용은 다시 한 번

[08:39] 에이전트 평가에서 최우선으로

[08:41] 고려되어야 합니다.

[08:43] 정확성이나 성능과 함께 비용을

[08:46] 축으로 고려하지 않으면

[08:48] 에이전트가 얼마나 잘 작동하는지

[08:50] 실제로 이해할 수 없습니다.

[08:53] 마지막으로, 언어 모델을 위한 새로운

[08:56] 벤치마크를 만들 때는 모든

[08:58] 언어 모델을

[08:59] 평가할 수 있다고 가정할 수 있지만

[09:02] 에이전트를 평가할 때는 이 에이전트들이

[09:04] 특정 목적으로 만들어진 경우가 많습니다.

[09:06] 예를 들어 코딩 에이전트를 평가할 때

[09:09] 웹 에이전트용 벤치마크는 사용할 수 없습니다.

[09:11] 이를 평가하기 위한 벤치마크로 사용할 수 없으며,

[09:13] 이는 두 번째 난관으로 이어집니다. 바로

[09:16] 어떻게 의미 있는

[09:17] 다차원적 평가 지표를 구성할 것인가 하는 문제입니다.

[09:19] 단일 벤치마크에만 의존하지 않고

[09:22] 에이전트의 성능을 평가하는 방법이 필요합니다.

[09:24] 이러한 우려들이 이론적으로만 들릴 수 있습니다.

[09:27] 여러분은 당연히 이렇게 물을 수 있죠.

[09:30] 정적 평가가 에이전트에 적합하지 않다면 왜 신경 써야 하나요?

[09:33] 그 이유는 바로 이러한 비용과 정확도의 차이,

[09:35] 단일 벤치마크 최적화에만 집중하는 현상 때문입니다.

[09:39] 이러한 차이점들로 인해

[09:41] 비용과 정확도의 차이로 인해,

[09:43] 단일 벤치마크 최적화에만 집중하다 보니

[09:45] 우리는 에이전트가 얼마나 잘 작동하는지에 대한

[09:48] 일관된 그림을 얻을 수 없게 됩니다.

[09:50] 그래서 프린스턴에서는 이러한 문제들을

[09:52] 해결하기 위한 에이전트 리더보드를 개발했습니다.

[09:55] 특히 제가 앞서 언급한

[09:57] 코어 벤치 리더의 경우

[09:59] 여러 에이전트를

[10:01] 정확도와 함께 비용 측면에서도 평가할 수 있습니다.

[10:04] 이 파레토 프론티어에서 볼 수 있듯이

[10:07] Claude 3.5와 같은 에이전트들이

[10:10] OpenAI의 O1 모델과 비슷한 점수를 기록했지만

[10:14] Claude 모델은 실행 비용이 57달러인 반면

[10:17] O1은 664달러가 듭니다.

[10:20] 만약 OpenAI O1의 성능이

[10:22] 몇 퍼센트 포인트 더 높았다 하더라도

[10:25] (이 경우에는 그렇지도 않았지만)

[10:27] 대부분의 AI 엔지니어들에게

[10:28] 이 선택은 매우 명확합니다.

[10:31] 누구나 비슷한 성능을 내면서

[10:34] 10배나 저렴한 모델을

[10:36] 선택할 것입니다.

[10:39] 이런 이차원적인

[10:40] 파레토 분석에 대해 자주 받는 질문이 있습니다.

[10:43] 'LLM이 너무 저렴해지고 있는 것 아닌가요?'

[10:46] 다시 말해, 모델 실행 비용을

[10:49] 왜 신경 써야 하냐는 것입니다.

[10:50] 모델 생성 비용이

[10:52] 급격히 감소하고 있는데

[10:55] 실제로 비용은

[10:57] 최근 몇 년간 크게 감소했습니다.

[10:59] OpenAI의 2022년 모델인

[11:01] Text DaVinci 003과

[11:03] 현재의 GPT-4 Mini를 비교하면

[11:06] 2022년

[11:07] 모델보다 대부분 더 나은 성능을 보이면서도

[11:11] 비용은 100배 이상 감소했습니다.

[11:13] 하지만 동시에

[11:15] 확장이

[11:17] 필요한 애플리케이션을 만들 때는

[11:19] 이러한 접근 방식도 여전히

[11:21] 상당히 비용이 많이 듭니다.

[11:23] 특히 프로토타입 출시 관점에서

[11:25] AI 엔지니어들이 직면하는 장벽 중 하나는

[11:27] 실제 환경에서 반복적으로

[11:31] 테스트해야 한다는 점입니다.

[11:33] 따라서 비용을 고려하지 않으면

[11:35] 프로토타입이 금방

[11:37] 수천 달러의 비용을 발생시킬 수 있습니다.

[11:39] 마지막으로, LLM 추론 시간의 비용이

[11:42] 계속해서 감소하더라도

[11:45] 제빈스 패러독스로 알려진 현상이

[11:47] 에이전트 운영의

[11:49] 전체 비용을 계속 증가시킬 것으로 예상됩니다.

[11:51] 제빈스 패러독스는 19세기 영국 경제학자의 이론으로

[11:53] 석탄 채굴 비용이 감소했을 때

[11:56] 오히려 전반적인 석탄 사용량이

[11:58] 여러 산업에서 감소하지 않고 증가했다는 것입니다.

[12:01] 같은 현상이 ATM이

[12:04] 미국 전역에 도입되었을 때도 일어났습니다.

[12:06] 사람들은 은행 창구 직원들의 일자리가 줄어들 것이라 예상했지만

[12:08] 오히려 반대 현상이 일어났습니다. ATM이

[12:11] 설치하기 쉬워지자 은행 지점 수가

[12:14] 크게 증가했기 때문입니다.

[12:16] ATM이 설치하기가 너무 쉬워서

[12:18] 은행 지점의 수가 실제로 급격히

[12:19] 증가했고, 이는 결과적으로

[12:21] 은행 창구 직원의 수도 증가하게 되었습니다

[12:24] 저는 이러한 현상이 언어 모델의

[12:26] 비용이 급격히 감소함에 따라

[12:28] 다시 일어날 것으로 예상합니다

[12:30] 그래서 적어도 가까운 미래에는

[12:32] AI 에이전트 평가에 있어서

[12:34] 비용을 고려해야 합니다

[12:35] 그렇다면 이 모든 것을 어떻게

[12:38] 자동화된 방식으로 수행할까요?

[12:40] 홀리스틱 에이전트 리더보드(HAL)를 통해

[12:42] 우리는 방법을 찾았습니다

[12:43] 11개의 서로 다른 벤치마크에서

[12:46] 자동으로 에이전트 평가를 실행하는 방법을 개발했고

[12:48] 더 많은 벤치마크가 추가될 예정입니다

[12:51] 하지만 그 이상으로, 우리가

[12:53] 이러한 다차원적인

[12:55] 벤치마크를 개발하고

[12:57] 비용 통제 평가를 수행하더라도

[13:00] 이러한 평가 방식에는

[13:01] 여전히 문제가 있습니다

[13:03] 그 이유는 에이전트 벤치마크가

[13:05] VC들이 기업에 투자하는 기준이 되었기 때문입니다

[13:08] 예를 들어, Coign은

[13:11] S-bench에서의 성과를 기반으로

[13:13] 시드 투자를 유치했습니다

[13:16] 실제로 에이전트 개발사인 Cognition은

[13:20] 20억 달러의 기업 가치로 1억 7500만 달러를

[13:23] 투자받았는데, 이는 주로

[13:25] S-bench에서 좋은 성과를 보였기 때문입니다

[13:29] 하지만 안타깝게도 벤치마크 성능은

[13:32] 실제 세계에서 거의 적용되지 않습니다

[13:35] 이것은 Devin의 성능에 대한

[13:37] 훌륭한 분석입니다. Devin은

[13:40] Cognition이 개발한 에이전트로

[13:42] 매우 인상적인

[13:44] Anthropic 팀이 분석했습니다

[13:46] 표준 벤치마크에 의존하는 대신

[13:48] 실제 환경에서 Devin을 테스트했고

[13:50] 한 달 동안의 사용 결과

[13:52] 20개의 다른 작업을

[13:54] 시도했지만 단 3개의 작업에서만

[13:56] 성공을 거두었습니다

[13:59] 이것이 바로

[14:00] 정적 벤치마크에 대한 과도한 의존이

[14:03] 매우

[14:04] 오해의 소지가 있는 또 다른 이유입니다

[14:06] 이를 어떻게 극복할 수 있을까요?

[14:08] 제가 가장 좋아하는 프레임워크 중 하나는

[14:10] 버클리 연구진의 '검증자를

[14:12] 누가 검증하는가'입니다. 상단에는 일반적인

[14:15] 평가 파이프라인이 있는데, 이는

[14:17] 정적 메트릭에 대한 단일 LLM 호출로

[14:19] 구성되어 있습니다. 이는 우리가 방금 논의한

[14:22] AI 평가의 문제가 있는 패러다임입니다

[14:24] 하단에는 그들이 제안하는

[14:27] 방식이 있는데, 도메인 전문가인

[14:29] 사람들이 직접 참여하여

[14:31] LLM 평가의 기준을

[14:33] 능동적으로 수정하는

[14:35] 방식을 제안합니다. 이는

[14:37] 훨씬 더 나은 평가 결과로

[14:39] 이어질 수 있습니다

[14:41] 이는 에이전트 성능이

[14:44] 실제 세계에서 잘 적용되지 않는

[14:46] 마지막 핵심 요인으로 이어지는데

[14:48] 바로 '능력(capability)'과

[14:50] '신뢰성(reliability)'의 혼동입니다

[14:54] 대략적으로 말하면, 능력이란

[14:57] 모델이 특정 시점에서

[14:59] 할 수 있는 것을 의미합니다

[15:00] 기술적으로 설명하면, 이는 매우 높은 K에서

[15:04] 모델의 pass@K 정확도를 의미하며

[15:06] 모델이 출력하는 K개의 답변 중

[15:08] 하나가 정확하다는 것을 의미합니다

[15:10] 신뢰성이란 답변을

[15:12] 매번 정확하게 도출하는 것을 의미합니다.

[15:15] 실제 환경에서 중요한 의사결정을 위해

[15:17] 에이전트를 배포할 때

[15:19] 역량보다는 신뢰성에 집중해야 합니다.

[15:22] 그 이유는 언어 모델이

[15:24] 이미 많은 기능을 수행할 수 있지만,

[15:26] 이것이 곧 최종 사용자에게

[15:29] 신뢰할 수 있는 경험을 제공한다고

[15:30] 착각하게 되면

[15:32] 실제 제품에서

[15:34] 문제가 발생하기 때문입니다.

[15:37] 특히 90%의 성능을 달성하는

[15:40] 모델 학습 방법은

[15:43] 머신러닝 엔지니어의 영역이지만,

[15:45] 이것이 반드시 99.999%의 신뢰성으로

[15:49] 이어지지는 않습니다.

[15:51] 이는

[15:52] '파이브 나인'이라고도 하는데,

[15:55] 90%에서 99.9%로

[15:57] 신뢰성을 높이는 것이 바로

[16:00] AI 엔지니어의 역할입니다.

[16:03] 이것이 Humane, Spin, Rabbit R1과 같은

[16:05] 제품들이 실패한 원인이라고 봅니다.

[16:08] 개발자들이 신뢰성 부족이

[16:11] 이러한 제품에서 실패로 이어질 것을

[16:13] 예상하지 못했기 때문입니다.

[16:15] 다시 말해, 개인 비서가

[16:18] DoorDash 음식 주문을

[16:20] 80%만 정확하게 처리한다면,

[16:22] 제품 관점에서 보면

[16:24] 치명적인 실패입니다.

[16:26] 이런 문제를 해결하기 위해

[16:28] 신뢰성을 개선하는 방법으로

[16:30] 검증기를 만드는 것이 제안되었습니다.

[16:32] 단위 테스트와 같은 것인데,

[16:36] 이를 기반으로

[16:37] 추론 확장성을 개선하고

[16:39] 매우 신뢰할 수 있는

[16:41] 모델을 만들 수 있다는

[16:44] 주장들이 있었습니다. 하지만 우리가 발견한 바로는

[16:47] 실제로 검증기도 완벽하지 않습니다.

[16:49] 예를 들어, 주요 코딩 벤치마크인

[16:52] HumanEval과 MBPP의

[16:55] 단위 테스트에서 거짓 양성이 발생했는데,

[16:56] 즉, 모델이 잘못된 코드를 출력해도

[16:59] 단위 테스트를 통과할 수 있었습니다.

[17:01] 이러한 거짓 양성을 고려하면

[17:04] 추론 확장 곡선이

[17:06] 아래로 휘어집니다.

[17:07] 모델 성능이 계속 향상되는 대신,

[17:09] 검증기에 거짓 양성이 있으면

[17:12] 모델 성능이

[17:13] 아래로 휘어지게 됩니다.

[17:15] 시도를 많이 할수록

[17:17] 잘못된 답을 얻을 가능성이

[17:19] 높아지기 때문입니다.

[17:20] 따라서 이것도 신뢰성 문제에 대한

[17:24] 완벽한 해결책이 아닙니다.

[17:25] 그렇다면 해결책은 무엇일까요?

[17:29] AI 엔지니어들의 과제는

[17:31] 어떤 종류의 소프트웨어 최적화와

[17:34] 추상화가 필요한지 파악하는 것입니다.

[17:36] LLM과 같은 본질적으로

[17:38] 확률적인 요소들을 다루기 위해서는

[17:41] 단순한 모델링 문제가 아닌

[17:43] 시스템 설계 문제로 접근해야 합니다.

[17:45] 본질적으로 확률적인 시스템의

[17:47] 제약사항을 해결하는 방식으로

[17:49] 접근해야 합니다. 마지막 1분 동안

[17:52] 말씀드리고 싶은 것은

[17:54] AI 엔지니어링을 소프트웨어나

[17:57] 머신러닝 엔지니어링보다는

[17:59] 신뢰성 엔지니어링 분야로

[18:00] 바라봐야 한다는 것입니다.

[18:03] 이는 성공을 위해 필요한

[18:05] 명확한 사고방식의 전환을 의미합니다.

[18:09] AI 엔지니어의 관점에서 보면

[18:11] 제 발표 슬라이드의 제목을 보시면

[18:13] 이 제목 슬라이드는 우리가 이미

[18:16] 특정 유형의 한계를 극복한

[18:18] 한 영역을 지적하고 있습니다

[18:20] 확률적 시스템의

[18:22] 컴퓨팅의 탄생과 함께

[18:24] 1946년 ENIAC 컴퓨터는 17,000개 이상의 진공관을 사용했는데

[18:28] 초기에는 이 진공관들이

[18:31] 너무 자주 고장나서

[18:33] 컴퓨터를 절반의 시간도 사용할 수 없었고

[18:36] 이 제품을 만든 엔지니어들은

[18:39] 이것이 최종 사용자 관점에서

[18:41] 실패라는 것을 알고 있었습니다

[18:42] 그래서 이 컴퓨터의 첫 2년 동안

[18:45] 그들의 주요 임무는

[18:47] 신뢰성 문제를 해결하는 것이었습니다

[18:50] 최종 사용자가 사용할 수 있을 정도로

[18:52] 충분히 잘 작동하는 수준까지 개선하는 것이었죠

[18:55] 그리고 저는 이것이 바로 AI 엔지니어들이

[18:58] 자신들의 진정한 임무로 생각해야 하는 것이라고 봅니다

[19:01] 우수한 제품을 만드는 것도 중요하지만

[19:03] 그것이 전부가 아닙니다

[19:05] 오히려 더 중요한 것은

[19:07] 신뢰성 문제를 해결하는 것입니다

[19:09] 본질적으로 확률적 모델을 기반으로 하는

[19:11] 모든 AI 에이전트들이 겪고 있는

[19:14] 신뢰성 문제를 해결하는 것이 핵심입니다

[19:17] 오늘 여러분께 말씀드리고 싶은 것은

[19:18] 성공적인 엔지니어가 되기 위해서는

[19:21] 신뢰성에 대한 마인드셋의 전환이 필요하다는 것입니다

[19:23] 여러분 자신을 다음 세대 컴퓨팅이

[19:25] 최종 사용자들에게 최대한 신뢰성 있게

[19:27] 제공될 수 있도록 보장하는 사람으로 생각해야 합니다

[19:30] 과거에도 이런 유형의 변화가

[19:32] 많은 선례가 있었습니다

[19:34] 자, 이것으로 3가지 핵심 내용을 말씀드렸습니다

[19:36] 함께 해주셔서 감사합니다

[19:38] 즐거운 시간이었습니다

[19:39] 감사합니다

[19:42] [음악]