📰 NVIDIA, 에이전트 설계의 새 문법 제시

LLM 에이전트를 만들다 보면 구성요소가 빠르게 흩어집니다. 프롬프트는 한곳에 있고, 도구 정의는 다른 파일에 있으며, 상태는 대화 기록이나 별도 저장소에 남고, 또 출력 형식은 JSON 스키마로 관리하지요. 여기에 작업 흐름까지 그래프나 전용 DSL로 표현하기 시작하면, 시스템이 커질수록 에이전트가 무엇을 할 수 있고 현재 어떤 상태인지 파악하기 어려워지는데요.🤯

최근 엔비디아 연구진이 'NOOA(NVIDIA Object-Oriented Agents)'라는 방식으로 이 문제에 접근했습니다. 바로 에이전트를 별도의 특수한 추상화로 만들지 말고, 일반적인 Python(이하 '파이썬') 객체로 표현하자는 주장인데요. NOOA는 타입이 있는 입출력, 코드 실행, 객체 상태, 컨텍스트와 메모리를 하나의 파이썬 객체 모델 안에 통합합니다. 이후 이러한 설계가 모델의 작업 성능과 비용, 실행 신뢰성에 어떤 차이를 만드는지 평가하지요. 좀 더 자세히 알아볼까요?

NOOA에서는 하나의 파이썬 클래스 안에 에이전트가 보관할 정보, 수행할 수 있는 작업, 각 작업의 입력과 출력 규칙을 함께 정의할 수 있습니다. 아래 고객지원 에이전트를 예로 들어볼까요?

설명을 위해 단순화한 고객지원 에이전트 예시. 출처: 셀렉트스타

• Class
  에이전트의 전체 설계도로, 에이전트 자체를 정의합니다. Class 안에는 에이전트가 보관할 정보와 수행할 작업이 함께 들어갑니다.
• Field
  에이전트가 보관하는 변수로, 현재 상태나 연결된 객체를 나타냅니다. 위 예시에서는 order_db가 여기에 해당합니다.
• Method
  에이전트가 수행할 수 있는 함수입니다. 위 예시의 is_refund_eligible(), classify(), triage()가 각각 하나의 method입니다.
• docstring
  Method가 무슨 일을 하는지 적어 둔 설명문입니다. NOOA에서는 이 설명을 모델이 읽고 작업 지시로 사용합니다.
• Type annotation
  입력과 출력이 어떤 종류의 데이터여야 하는지 정합니다. str, TicketKind, Ticket 같은 표기가 여기에 해당하며, 런타임은 반환값이 이 계약을 지켰는지 검사합니다.
  
  

NOOA의 CodeAct 방식에서는 모델이 단순히 대화만 주고받지 않고, 주피터 노트북과 비슷한 환경에서 파이썬 코드를 직접 작성하고 실행합니다.

Method에 전달된 값은 파이썬 변수로 준비되는데요. 모델은 이 변수를 살펴보거나 가공할 수 있고, self를 통해 에이전트가 보관하는 상태와 다른 method에도 접근할 수 있습니다. 실행한 코드에서 결과나 오류가 나오면, 이를 확인한 뒤 다음 작업을 이어가지요. 이 방식은 모델이 한 번에 하나의 도구만 호출하는 구조와 차이가 있습니다. 예를 들어 여러 파일을 검사해야 한다면, 파일마다 도구 호출을 반복해서 생성하는 대신 아래와 같이 반복문을 작성할 수 있습니다.

모델은 작업 방법을 정하고, 반복 실행이나 데이터 정리처럼 파이썬이 더 안정적으로 처리할 수 있는 부분은 코드가 맡는 구조입니다.

큰 데이터도 모두 프롬프트에 넣지 않습니다. 전체 데이터와 중간 결과는 파이썬 변수에 보관하고, 모델에게는 필요한 미리보기만 보여줄 수 있지요. 논문은 데이터를 매번 텍스트로 복사하지 않고, 실행 환경에 있는 실제 객체를 필요할 때 참조하는 방식을 pass-by-reference라고 부릅니다. 이를 통해 큰 도구 결과가 컨텍스트를 차지하거나 같은 정보가 반복해서 토큰으로 소비되는 문제를 줄일 수 있지요.

연구진은 NOOA를 소프트웨어 수정, 터미널 조작, 취약점 탐지, 대화형 추론까지 네 종류의 벤치마크에서 평가했습니다. 그중 대표적인 SWE-bench Verified는 실제 오픈소스 프로젝트에서 보고된 버그와 이슈를 바탕으로, AI가 코드 저장소를 읽고 원인을 찾아 수정한 뒤 테스트까지 통과하는지를 확인하는 벤치마크인데요. 단순히 코드를 한 줄 생성하는 시험이 아니라, 여러 파일을 살펴보고 문제를 추적한 뒤 실제로 작동하는 수정안을 만들어야 하는 과제입니다. 

SWE-bench Verified 평가 과정 개요. 출처: 논문 <SWE-bench: Can Language Models Resolve Real-world Github Issues?>

이 평가에서 GPT-5.5의 가장 높은 추론 설정을 사용한 NOOA는 82.2%를 기록했습니다. 같은 모델을 사용한 공개 범용 에이전트인 OpenCode는 78.6%, PI는 78.2%였는데요. 이는 공개된 범용 하네스 사이의 비교입니다. 특정 과제에 맞춰 만들어진 폐쇄형 시스템과 비교하면 Codex는 88.7%로 더 높고, Claude Code는 80.8%로 NOOA와 비슷한 수준입니다. 논문은 NOOA의 성과를 '작고 벤치마크에 특화되지 않은 에이전트가 전용 시스템에 근접했다'는 맥락에서 제시합니다.

SWE-bench Verified 통과율 비교. 출처: 엔비디아.

호출 횟수와 토큰 사용량에서도 차이가 나타났는데요. 과제 하나당 NOOA는 약 28회의 모델 호출과 110만 토큰을 사용한 반면, PI는 66회 호출과 220만 토큰을 사용했습니다. OpenCode는 호출 횟수는 NOOA와 비슷했지만 약 130만 토큰이 들었지요. 연구진은 중간 결과를 실제 객체와 변수에 남겨두는 구조가 이런 효율에 기여했다고 분석합니다.🤓