smolagents vs Pydantic AI v2: 에이전트를 위한 코드 실행과 타입 안전성의 균형

AI 에이전트에게 일을 시킬 때, 복잡한 JSON 데이터를 주고받는 대신 아예 코드를 직접 짜서 실행하게 만들면 어떻게 될까요? 최근 허깅페이스의 smolagents가 보여준 자유롭고 빠른 '코드 퍼스트' 방식과, Pydantic AI가 고집하는 철저한 '타입 안전성'이 개발자들 사이에서 뜨겁게 맞붙고 있습니다. 효율을 위해 에이전트에게 코드 실행의 자유를 줄 것인가, 아니면 보안을 위해 엄격한 규칙 안에 가둘 것인가에 대한 실무적인 고민을 가볍게 짚어봅니다.

JSON 대신 코드를 직접 짠다: smolagents의 파격적인 효율성

AI 에이전트에게 특정 도구를 다루게 할 때, 지금까지는 대부분 JSON이라는 규격화된 데이터를 구조에 맞춰 주고받는 방식을 썼습니다. 하지만 허깅페이스가 선보인 smolagents는 전혀 다른 길을 갑니다. 에이전트에게 복잡한 포맷에 맞춰 빈칸을 채우라고 요구하는 대신, 직접 파이썬 코드를 짜서 도구를 실행하게 하는 '코드 퍼스트' 모델을 선택한 것입니다.

이 방식은 놀라울 만큼 빠르고 효율적입니다. 복잡한 데이터를 쪼개고 분석하는 파싱 단계를 건너뛰기 때문에, 대형언어모델(LLM)이 답을 내기까지 거쳐야 하는 추론 단계를 약 30%나 줄여줍니다. 게다가 코드를 실행하다가 오류가 나면, 그 오류 내역을 에이전트의 기억 장치에 그대로 돌려주어 스스로 디버깅하며 코드를 고쳐 쓰게 만듭니다. 사람이 개발할 때 오류를 보며 고치는 흐름과 똑같습니다.

결과는 숫자로 증명되었습니다. 아주 어렵기로 소문난 AI 에이전트 평가 표준인 GAIA 벤치마크에서 무려 55%라는 높은 성공률을 기록한 것입니다. 생각할 단계를 줄이고 바로 행동으로 문제를 해결하는 이 단순한 구조가 에이전트의 실행 속도와 성공률을 모두 잡아낸 비결입니다.

하지만 공짜는 없다: 샌드박스 보안과 레이턴시 문제

에이전트가 스스로 파이썬 코드를 직접 짜서 실행하는 방식은 정말 편리합니다. 하지만 여기에는 치명적인 함정이 있습니다. 만약 에이전트가 내 컴퓨터나 서버의 핵심 시스템을 망가뜨리는 악성 코드를 짜서 실행한다면 어떻게 될까요?

실제로 27,000개가 넘는 깃허브 스타를 받으며 급성장한 smolagents도 이 문제에서 자유롭지 못했습니다. 최근 로컬 실행 환경에서 코드 인젝션 같은 심각한 보안 취약점(CVE-2026-4963 등)이 발견되어 급히 보안 패치를 진행하기도 했습니다. 에이전트가 만든 코드가 해커의 징검다리가 되어 서버 시스템을 통째로 장악할 수 있는 위험이 고스란히 증명된 셈입니다.

이를 해결하려면 에이전트의 코드를 격리된 가상 환경인 샌드박스 안에서만 돌려야 합니다. 쉽게 말해 아이가 다치지 않게 안전한 모래놀이터 안에서만 놀게 만드는 장치입니다. 하지만 안전을 챙기면 속도를 잃게 됩니다.

매번 에이전트가 코드를 실행할 때마다 가상환경을 새로 만들고 네트워크를 연결해야 하는데, 이 과정에서 어쩔 수 없이 지연 시간이 늘어납니다. 에이전트가 똑똑하게 반응하더라도 질문 하나에 몇 초씩 대기해야 한다면 답답해서 쓸 수 없겠죠. 결국 개발자는 '자유롭지만 위험한 실행'과 '안전하지만 느린 격리' 사이에서 어려운 선택을 해야 합니다.

선 검증 후 실행: Pydantic AI v2가 제시하는 타입 안전성

에이전트에게 코드를 마음대로 실행할 자유를 주는 대신, 철저히 통제된 설계도 안에서만 안전하게 움직이게 하는 진영도 있습니다. 데이터 검증의 대명사로 불리는 Pydantic AI v2가 대표적입니다. 이들은 개발자가 미리 정해둔 정확한 데이터 구조에 맞춰서만 에이전트가 입출력을 주고받도록 제한하는 '타입 안전성'을 최우선으로 내세웁니다.

특히 Pydantic AI v2에서 새롭게 도입된 '카파빌리티(Capabilities)' 기능은 매우 유용한 안전장치입니다. 에이전트가 사용할 도구와 실행 규칙을 하나의 단위로 묶어서 관리합니다. 만약 입력된 데이터에 규칙에 어긋나는 오류가 있다면, 에이전트가 도구를 실행하기도 전에 입구에서 즉시 걸러냅니다. 게다가 에이전트에게 모든 도구 정보를 처음부터 쥐여주는 대신 필요할 때만 불러와서 쓰는 온디맨드 로딩 방식을 지원해 메모리와 토큰 낭비도 획기적으로 줄였습니다.

이 방식은 코드를 돌릴 격리 환경을 따로 만들고 모니터링해야 하는 복잡함과 지연 시간이 전혀 없습니다. 덕분에 금융 결제나 블록체인 거래처럼 한 치의 오차도 허용할 수 없는 가상자산 에이전트 환경에서 압도적으로 유리합니다. 위험할 수 있는 코드 실행 권한을 에이전트에게 통째로 넘겨주는 대신, 정밀하게 짜인 레일 위를 안정적으로 달리게 만드는 영리한 선택지입니다.

실무에서 쓰이는 해법: 두 세계를 융합한 하이브리드 아키텍처

자유분방한 smolagents와 깐깐한 Pydantic AI 중 무조건 하나만 골라야 할까요? 현장의 개발자들은 이 두 가지 장점을 결합한 하이브리드 아키텍처에서 현실적인 답을 찾고 있습니다. 자유도와 안전성이라는 상반된 가치 사이에서 영리하게 균형을 잡는 것이죠.

가장 대표적인 방법은 에이전트의 역할을 기획과 실행으로 나누는 설계입니다. 복잡한 데이터를 분석하고 여러 계산이 필요한 기획 단계에서는 smolagents가 활약합니다. 까다로운 형식에 구애받지 않고 파이썬 코드를 짜서 자유롭게 최적의 해법을 찾아내도록 풀어두는 방식입니다.

하지만 분석이 끝난 뒤 실제 데이터베이스를 고치거나 외부 결제 API를 호출하는 실행 단계에서는 흐름을 바꿉니다. 이때는 Pydantic AI를 앞세워 입력값이 약속된 규격에 맞는지 타입 검증을 철저하게 거칩니다. 에이전트에게 생각할 자유는 넓게 주되, 실제 시스템에 반영할 때는 튼튼한 안전벨트를 채우는 셈입니다.

결국 프로젝트의 목적이 에이전트의 구조를 결정합니다

가벼운 데이터 분석이나 빠른 파일 처리가 목표라면, LLM이 파이썬 코드를 직접 짜서 실행하는 smolagents가 훌륭한 출발점입니다. 반대로 금융이나 기업용 데이터 시스템처럼 단 한 번의 에러도 허용할 수 없는 환경이라면, 입출력을 엄격하게 통제하는 Pydantic AI가 더 안전한 선택이 될 것입니다.

결국 핵심은 에이전트의 실행 속도와 보안 경계 사이에서 우리 서비스에 딱 맞는 타협점을 찾는 일입니다. 어떤 도구가 무조건 정답이라고 하기보다, 만들고자 하는 서비스의 성격에 맞춰 하이브리드 설계까지 폭넓게 고민해 보는 것을 추천합니다.