CodeAct: 실행 가능한 파이썬 코드가 LLM 에이전트의 정확도를 20% 높이는 이유

지난주 "자가 수정 불가(cannot self-correct)" 논문을 읽고 나면 자연스럽게 다음과 같은 의문이 생깁니다. LLM이 자신의 출력을 안정적으로 감사(audit)할 수 없다면, 에이전트가 오류를 자동으로 감지하고 복구할 수 있는 최선의 액션 형식은 무엇일까요? Xingyao Wang 등이 발표하고 ICML 2024에 채택된 CodeAct는 그 답이 파이썬 코드라고 주장합니다. 코드가 마법이라서가 아니라, 파이썬 인터프리터가 자가 수정 문헌에서 LLM에게 절실히 필요하다고 지적하는 외부적이고 결정론적인 피드백을 정확히 제공하기 때문입니다.

논문 개요

Xingyao Wang, Yangyi Chen, Lifan Yuan, Yizhe Zhang, Yunzhu Li, Hao Peng, Heng Ji의 "실행 가능한 코드 액션이 더 나은 LLM 에이전트를 유도한다(Executable Code Actions Elicit Better LLM Agents)"(arXiv:2402.01030)는 도구 호출 에이전트에서 흔히 쓰이는 JSON 및 텍스트 액션 형식을 실행 가능한 파이썬 코드로 대체할 것을 제안합니다. 핵심 아이디어는 코드가 자연어 지침이나 구조화된 JSON보다 에이전트 액션을 위한 더 나은 공용어(lingua franca)라는 점입니다. 코드는 이미 제어 흐름, 데이터 종속성 및 다단계 구성을 인코딩하고 있으며, LLM이 이미 방대한 양의 코드로 사전 학습되었기 때문입니다.

이 논문은 세 가지 기여를 합니다. (1) 통합 액션 공간으로서의 코드에 대한 개념적 논증, (2) 다중 도구 구성이 필요한 82개의 인간 큐레이션 작업으로 구성된 새로운 벤치마크 M3ToolEval, (3) 정보 검색, 소프트웨어 패키지, 외부 메모리 및 로봇 계획을 아우르는 7,139개의 다회차 코드 기반 궤적 데이터셋인 CodeActInstruct로 미세 조정된 7B 모델 CodeActAgent입니다.

핵심 아이디어

• M3ToolEval에서 CodeAct를 사용하는 GPT-4는 텍스트 액션(53.7%) 대비 74.4%의 성공률을 기록하여, 가장 까다로운 다중 도구 설정에서 약 20%포인트의 절대적인 향상을 보였습니다.
• CodeAct는 동일한 작업에서 JSON 기반 에이전트보다 상호 작용 횟수가 약 30% 적습니다. 횟수가 적다는 것은 중요합니다. 추가적인 왕복(round-trip)이 발생할 때마다 오류가 전파될 가능성이 커지기 때문입니다.
• 파이썬 인터프리터는 자동적이고 비용이 들지 않는 오류 신호 역할을 합니다. 잘못된 중간 계산은 즉시 예외(exception)를 발생시키며, 에이전트는 별도의 비판(critique) 단계 없이 트레이스백(traceback)을 보고 수정할 수 있습니다.
• 오픈 소스 모델이 폐쇄형 모델보다 더 큰 혜택을 입습니다. CodeActAgent(Mistral 7B)는 M3ToolEval에서 12.2%를 기록한 반면, 이전의 가장 강력한 오픈 소스 에이전트인 Lemur-70B(텍스트 기반)는 3.7%에 그쳤습니다. 파이썬은 사전 학습 데이터에 풍부하지만 특수한 JSON 도구 호출 형식은 그렇지 않기 때문에 레버리지가 더 높습니다.
• CodeActInstruct는 구성을 집중적으로 테스트하기 위해 특별히 선택된 네 가지 도메인(정보 검색, 패키지 호출, 외부 메모리 조작, 로봇 계획)에서 학습합니다. 이들은 모두 다단계이며 상태에 의존적인 작업들로, JSON 에이전트가 흔히 실패하는 모드들입니다.

유효한 점과 그렇지 않은 점

M3ToolEval에서의 20% 향상은 실제적이지만, M3ToolEval은 82개의 작업으로 구성되어 있습니다. 이는 작은 샘플이며 논문에는 신뢰 구간이 보고되지 않았습니다. 또한 벤치마크가 방법론을 제안한 동일한 팀에 의해 큐레이션되었다는 점은 해당 분야에서 일반적이긴 하지만 유의할 필요가 있습니다. 74.4%라는 수치를 신뢰하기 전에 완전히 독립적인 벤치마크에서의 재현 결과를 보고 싶습니다.

30% 적은 상호 작용 횟수라는 효율성 주장은 그럴듯하지만 두 가지 요인이 섞여 있습니다. 횟수가 적다는 것이 에이전트가 단계당 더 정확하다는 뜻일 수도 있고, 실패 시 더 빨리 종료된다는 뜻일 수도 있습니다. 논문은 이를 명확하게 분해하여 보여주지 않습니다.

오픈 소스와 폐쇄형 모델 사이의 격차는 여전히 크며 CodeAct만으로는 설명되지 않습니다. CodeActAgent(Mistral 7B)의 12.2%는 Lemur-70B의 3.7%보다는 훨씬 낫지만, CodeAct를 사용한 GPT-4는 74.4%에 도달했습니다. 형식이 도움이 되긴 하지만 60포인트에 달하는 능력 격차를 메워주지는 못합니다. 오픈 소스 Beancount 에이전트를 배포하려는 사람이라면 이 수치를 신중하게 검토해야 합니다.

샌드박싱 문제는 단 한 단락으로 처리되었습니다. 금융 맥락에서 임의의 코드 실행은 사소한 엣지 케이스가 아니라 가장 중요한 보안 문제입니다. 논문은 에이전트가 파일을 삭제하거나 네트워크 호출을 시도하거나 예상치 못한 라이브러리를 임포트하는 코드를 생성할 때 어떤 일이 벌어지는지 깊게 다루지 않습니다. 상용 회계 에이전트에게 샌드박스 설계는 액션 형식만큼이나 중요합니다.

금융 AI에 중요한 이유

Beancount의 라이트백(write-back) 문제는 본질적으로 CodeAct가 해결하려는 문제와 동일합니다. 에이전트는 특정 순서에 따라 여러 작업(현재 잔액 읽기, 트랜잭션 검증, 새 포스팅 작성, 균형 방정식 확인)을 구성해야 하며 데이터가 단계 사이를 흘러야 합니다. JSON 도구 호출은 각 호출이 격리되어 있기 때문에 이를 제대로 처리하지 못하지만, 파이썬은 이를 자연스럽게 처리합니다.

더 구체적으로, CodeAct 방식의 Beancount 에이전트는 전체 대조 워크플로우를 하나의 파이썬 스크립트로 표현할 수 있습니다. 라이브러리를 통해 원장을 쿼리하고, 차이를 계산하고, 새 항목을 제안하고, 결과에 대해 bean-check를 실행하는 모든 과정을 실제로 반영하기 전에 수행할 수 있습니다. 인터프리터가 명백한 오류를 잡아내면, LLM은 의미론적인 오류만 처리하면 됩니다. 이는 LLM에게 자신의 JSON을 스스로 검증하게 하는 것보다 훨씬 나은 분업입니다.

보안 문제는 반대 방향으로 작용합니다. 금융 원장에 대해 제한 없는 파이썬 실행 권한을 가진 에이전트는 상당한 공격 표면(attack surface)이 됩니다. 올바른 설계는 지정된 임시 디렉토리 외의 파일 시스템 쓰기 금지, 네트워크 액세스 금지, 쉘 명령 금지 등 고도로 제한된 샌드박스여야 하며, 파일이 수정되기 전에 의무적인 bean-check 게이트를 거쳐야 할 것입니다. CodeAct는 액션 형식을 제공할 뿐, 안전한 환경을 구축하는 것은 여전히 우리의 몫입니다.

다음 읽을거리

• OpenHands (구 OpenDevin) — 동일한 연구 그룹이 CodeAct를 기반으로 구축한 상용 에이전트 시스템으로, 샌드박싱과 실행 환경이 실제로 어떻게 구현되는지 보여줍니다 (arXiv:2407.16741)
• ToolBench / ToolLLM — 파이썬 대신 REST API를 사용하는 도구 호출 에이전트를 위한 벤치마크 및 학습 데이터로, CodeAct의 코드 우선 접근 방식과 대비되는 유용한 자료입니다 (arXiv:2307.16789)
• SWE-bench — 실제 GitHub 이슈를 통해 에이전트를 평가하며, 다단계 코드 실행 및 파일 편집이 필요합니다. Beancount 라이트백 에이전트가 통과해야 할 가장 유사한 기존 벤치마크입니다 (arXiv:2310.06770)