ReAct냐 CodeAct냐, 그것이 문제로다

여러분,

제 생각은 좀 다르겠지만, AI 엔지니어링 분야에서 가장 큰 논쟁 중 하나는 바로 이 이슈라고 봅니다: ReAct vs. CodeAct.

완전히 다른 두 가지 오케스트레이션 방식이죠(사실 둘 다 함수 호출 방식이지만 접근 방식이 다릅니다).

ReAct: JSON을 사용하여 작업을 수행합니다(각 작업마다 하나의 ReAct 루프 사용). 실제로 작동하고 현재 주류 방식이긴 하지만, 하지만 여기에는 3가지 큰 문제가 있습니다:

• 다중 도구 및 대규모 다단계 작업에서 느림: 작업이 클수록 반복 횟수가 많아집니다.
• 데이터 관리 및 분석이 매우 어려움: 예를 들어, API나 MCP가 매우 큰 결과를 반환하면 전체 컨텍스트 윈도우가 터져버릴 수 있고, 무엇을 통과시킬지 선택할 쉬운 방법이 없습니다.
• 복잡한 흐름 제어 불가(IF, FOR, WHILE): 할 수는 있지만, 각 작업마다 JSON과 추가 반복이 필요해서 컨텍스트 비용이 기하급수적으로 증가합니다($$$).

물론 모든 게 나쁜 건 아닙니다. 채팅을 기본적으로 아주 잘 처리하고 환경에 꽤 잘 적응하죠.

CodeAct: 오케스트레이터 LLM이 코드를 반환하고, 이 코드가 샌드박스에서 실행되어 도구를 호출합니다. 현재 매우 구체적인 도메인(ETL 작업, 데이터 집약적 작업 또는 매우 정의된 워크플로우 등)에서는 주류입니다. 이런 경우, 토큰이나 지연 시간 측면에서 ReAct를 말 그대로 압살합니다. 대규모 다중 도구 작업이라도 전체 작업을 단일 스크립트 생성으로 한 번에 끝낼 수 있기 때문입니다. 각 함수 호출마다 JSON이 필요하지 않죠.

현재 smolAgents 같은 프레임워크가 있는데, 이 장점을 활용하지 못하고 있습니다. ReAct처럼 각 함수 호출마다 아주 작은 스니펫을 생성하기 때문에, 두 방식의 단점만 모아놓은 꼴이죠.

이걸 고민하다가 직접 프레임워크를 만들기 시작했고, 오픈 소스로 공개했습니다(원하시면 댓글에 링크를 남기겠습니다).

CodeAct의 장점:

• 복잡한 작업을 단일 LLM 호출로 한 번에 처리 가능(매우 효율적).
• 파이썬의 모든 기능을 활용할 수 있고, Pandas, NumPy 등 유틸리티 라이브러리를 사용할 수 있어 매우 유용하고 적응력이 뛰어남.
• 파이썬 자체를 사용하여 흐름과 오류를 매우 쉽게 관리할 수 있음.

물론 문제점도 있습니다. 제대로 된 샌드박스가 없으면 완전히 끝장나고, 잘 만들어진 추적 시스템도 필요하죠.

이 논쟁에 대해 어떻게 생각하시나요? 솔직히 역대급으로 너드한 글인 것 같네요.