🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

이 글은 CodeAgent의 유연한 코드 실행 방식에 구조화된 JSON 출력을 결합하면, 충분히 강한 모델에서 파싱 안정성과 추론 명시성이 높아져 여러 벤치마크 성능이 개선된다고 설명한다.

📌 핵심 요약

• 전통적인 JSON 기반 도구 호출 에이전트는 안정적이지만, 사전에 정의된 도구에 묶이고 중간 상태를 유지하거나 여러 도구 결과를 조합하는 데 한계가 있다.
• CodeAgent는 모델이 직접 실행 가능한 파이썬 코드를 작성하게 하여 반복문, 조건문, 함수, 변수 상태를 활용할 수 있고 도구 호출을 코드 안에서 유연하게 구성할 수 있다.
• 저자들은 CodeAgent가 생각과 코드를 모두 구조화된 JSON 형식으로 생성하도록 강제하면, 마크다운 코드 블록 파싱 오류를 줄이면서 코드 실행의 표현력을 유지할 수 있다고 주장한다.
• GAIA, MATH, SimpleQA, Frames를 포함한 벤치마크에서 구조화된 CodeAgent는 일반 CodeAgent보다 대체로 2~7%포인트 높은 성능을 보였고, 특히 충분히 강한 모델에서 효과가 뚜렷했다.
• 다만 작은 모델은 JSON 형식, 파이썬 문법, 문제 해결을 동시에 처리하는 부담 때문에 오히려 오류가 늘 수 있으며, 이 글은 이를 ‘structure tax’라고 부른다.

🧩 주요 포인트

1. 전통적인 JSON 기반 도구 호출 에이전트는 안정적이지만, 사전에 정의된 도구에 묶이고 중간 상태를 유지하거나 여러 도구 결과를 조합하는 데 한계가 있다.
2. CodeAgent는 모델이 직접 실행 가능한 파이썬 코드를 작성하게 하여 반복문, 조건문, 함수, 변수 상태를 활용할 수 있고 도구 호출을 코드 안에서 유연하게 구성할 수 있다.
3. 저자들은 CodeAgent가 생각과 코드를 모두 구조화된 JSON 형식으로 생성하도록 강제하면, 마크다운 코드 블록 파싱 오류를 줄이면서 코드 실행의 표현력을 유지할 수 있다고 주장한다.
4. GAIA, MATH, SimpleQA, Frames를 포함한 벤치마크에서 구조화된 CodeAgent는 일반 CodeAgent보다 대체로 2~7%포인트 높은 성능을 보였고, 특히 충분히 강한 모델에서 효과가 뚜렷했다.
5. 다만 작은 모델은 JSON 형식, 파이썬 문법, 문제 해결을 동시에 처리하는 부담 때문에 오히려 오류가 늘 수 있으며, 이 글은 이를 ‘structure tax’라고 부른다.

🧠 상세 정리

1. 문제의식: 코드 기반 행동과 구조화 생성의 결합

글은 AI 에이전트가 외부 세계에서 행동을 수행해야 한다는 점에서 출발한다. API 호출, 데이터 처리, 복잡한 문제 풀이처럼 에이전트의 행동 표현 방식은 성능과 안정성에 직접 연결된다. 저자들은 코드 기반 액션의 표현력과 구조화 생성의 신뢰성을 결합하는 연구를 소개한다. 핵심 주장은 CodeAgent가 생각과 코드를 구조화된 JSON 형식으로 생성하도록 강제하면, 기존 방식보다 여러 벤치마크에서 더 나은 결과를 낼 수 있다는 것이다.

2. 전통적인 JSON 도구 호출 에이전트의 장점과 한계

전통적인 JSON 에이전트는 미리 정의된 도구 목록 중 하나를 선택하고, 정해진 인자 형식에 맞춰 호출을 생성한다. 이 방식은 OpenAI의 function calling API를 통해 널리 알려졌고, 도구 호출을 안정적으로 처리하는 데 강점이 있다. 그러나 행동 범위가 사전 정의된 도구로 제한되고, 여러 도구의 결과를 이어서 비교하거나 처리해야 하는 상황에서는 제약이 크다. 병렬 도구 호출을 지원하는 모델도 있지만, 한 도구의 출력이 다음 행동을 결정하거나 중간 상태를 유지해야 하는 흐름에는 적합하지 않다고 글은 설명한다.

3. CodeAgent가 제공하는 코드 실행의 유연성

CodeAgent는 에이전트가 직접 실행 가능한 파이썬 코드를 작성하게 하는 접근이다. 글은 CodeAct 논문에서 제시된 방향을 언급하며, 도구를 코드 내부에서 직접 호출할 수 있다는 점을 핵심 장점으로 든다. 이렇게 하면 변수와 상태 관리가 훨씬 자연스러워지고, 반복문·함수·조건문 안에서 도구를 호출할 수 있다. 결과적으로 에이전트는 매 행동마다 동적인 도구 실행 그래프를 생성하는 것처럼 움직일 수 있으며, 가설을 세우고 테스트하는 방식의 문제 해결도 가능해진다.

4. 구조화 출력으로 CodeAgent를 보강하는 방식

저자들이 제안하는 방식은 CodeAgent의 출력 자체를 JSON 구조로 강제하는 것이다. 예시에서는 thoughts 필드에 행동 직전의 추론을 담고, code 필드에 실행할 파이썬 코드를 담는다. 중요한 차이는 단순히 프롬프트로 생각과 코드를 쓰라고 요구하는 것이 아니라, 구조화 출력 기능으로 정해진 형식을 지키도록 강제한다는 점이다. 이 접근은 코드 실행의 표현력은 유지하면서도 JSON 파싱의 안정성을 얻고, 계획과 실행을 더 명확히 분리하는 효과를 노린다.

5. 벤치마크 결과: 강한 모델에서 반복적으로 나타난 성능 향상

글은 GAIA, MATH, SimpleQA, Frames를 포함한 여러 벤치마크에서 전통적 ToolCallingAgent, 일반 CodeAgent, Structured CodeAgent를 비교했다. 결과는 충분히 강한 모델에서 코드 액션과 구조화 생성을 결합한 방식이 일관되게 성능을 높인다는 패턴을 보였다. 일반 CodeAgent와 비교했을 때 구조화 방식은 평균적으로 대체로 2~7%포인트 향상된 결과를 냈다고 설명한다. OpenAI 모델은 특히 추론 중심 과제에서 큰 개선을 보였고, Claude와 Qwen 계열도 구조화 방식의 이점을 보였지만 작은 모델에서는 부담이 드러났다고 정리한다.

6. 파싱 오류가 실제 성능 저하로 이어지는 이유

구조화 생성이 중요한 이유로 글은 파싱 문제를 구체적으로 분석한다. smolagents의 CodeAgent 구현은 LLM 출력에서 파이썬 코드를 추출하는데, 마크다운 코드 블록이 불완전하거나 여러 코드 블록이 한 응답에 섞이면 실패할 수 있다. 저자들은 15,724개의 에이전트 trace를 분석했고, 첫 호출에서 파싱 오류가 발생한 비율이 2.4%였다고 밝혔다. 첫 호출에 파싱 오류가 있는 trace의 성공률은 42.3%, 없는 trace의 성공률은 51.3%였으며, 오류가 없는 경우 성공 가능성이 21.3% 더 높았다고 설명한다.

7. 명시적 추론과 structure tax의 양면성

구조화 출력은 파싱 안정성뿐 아니라 행동 직전의 추론을 명시하도록 만든다는 점에서도 의미가 있다. 글은 thoughts 필드가 에이전트에게 문제를 더 체계적으로 생각하게 하고, 논리적 오류를 조기에 포착하는 데 도움이 된다고 설명한다. 그러나 이 장점은 모든 모델에 동일하게 적용되지 않는다. 저자들은 모델이 구조화 생성의 혜택을 보려면 충분한 지시 따르기 능력과 JSON 형식에 대한 학습 경험이 필요하며, 작은 모델은 JSON 형식, 파이썬 문법, 실제 문제 해결을 동시에 처리하는 인지적 부담을 겪는다고 말한다.

8. 사용 조건, 구현 방법, 앞으로의 질문

글은 Structured CodeAgent를 사용할 조건도 분명히 제시한다. 32B 이상급 모델이나 프런티어 모델처럼 충분히 강한 모델을 쓰고, 복잡한 추론과 코드 실행이 필요하며, 에이전트 출력의 안정적 파싱이 중요할 때 적합하다고 본다. 반대로 작은 모델이 구조화 생성을 어려워하거나 단순하고 사전 정의된 워크플로만으로 충분하다면 다른 방식을 고려하라고 권한다. smolagents에서는 CodeAgent 설정에서 use_structured_outputs_internally를 활성화하면 되며, 글은 향후 어떤 구조적 개선이 더 도움이 되는지, 작은 모델에서도 이 방식을 어떻게 잘 작동하게 할지 같은 질문을 남긴다.

🧾 핵심 주장 / 시사점

• 이 글의 성능 개선 논리는 단순히 형식을 JSON으로 바꾸는 데 있지 않고, 코드 실행의 유연성을 유지하면서 첫 행동부터 실패할 수 있는 파싱 문제를 줄이는 데 있다.
• Structured CodeAgent는 강한 모델에서 효과가 크지만, 작은 모델에는 JSON 구조와 파이썬 문법을 동시에 맞추는 부담이 생기므로 모델 선택이 핵심 조건으로 제시된다.
• 저자들이 강조하는 에이전트 설계의 방향은 ‘무엇을 할 수 있는가’뿐 아니라 ‘행동 전에 어떻게 생각을 구조화하고 실행 가능한 형태로 표현하는가’를 함께 다루는 것이다.

✅ 액션 아이템

• 강한 모델군을 우선 실험군으로 지정해, 구조화된 JSON+코드 조합이 파싱 안정성·추론 명시성·중간 상태 유지를 동시에 개선하는지 성능 지표로 정량 비교한다.
• 소형 모델에서 structure tax가 드러나는 구간을 오류율 기반으로 분리해, JSON 제약과 Python 구문·문제 해결 부담이 겹치는 지점을 실험적으로 규명한다.
• 전통 도구 호출의 한계를 보완하기 위해 코드 내부에서 반복문·조건문·변수 상태를 활용한 다도구 조합 패턴을 시나리오화해 적용 가능 범위를 점검한다.

❓ 열린 질문

• GAIA, MATH, SimpleQA, Frames에서 2~7%포인트 개선이 보고된 만큼 실제 과제군에서 임계 성능 이득이 어느 영역까지 확장 가능한가?
• 구조화된 JSON 출력이 효과적이려면 어느 수준 이상의 모델 강도가 필요한가, 약한 모델에서는 어떤 실패 패턴이 주로 나타나는가?
• 소형 모델의 structure tax를 줄이려면 JSON 문법 강도를 낮출 것인지, Python 코드 복잡도 상한을 둘 것인지 어떤 기준으로 우선순위를 정할 수 있는가?