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 같은 표기가 여기에 해당하며, 런타임은 반환값이 이 계약을 지켰는지 검사합니다.
실제 파이썬 코드가 작성된 method는 일반 프로그램처럼 실행됩니다. 위 예시의 환불 조건처럼 규칙이 명확한 일은 LLM의 판단에 맡기지 않지요.
반대로 NOOA의 에이전트 class에서 method 안에 실제 실행 코드 대신 '...'만 적혀 있으면, 해당 method는 LLM이 수행하도록 처리됩니다. 실행 방식은 method마다 다르게 지정할 수 있는데요. 실제 예시에서 classify()는 한 번의 모델 호출로 결과를 내고, triage()는 파이썬 코드를 작성하고 실행하는 과정을 반복합니다. 여기서 중요한 점은 일반 코드와 모델의 판단을 같은 class 안에서 분명하게 나눌 수 있다는 사실입니다. NOOA는 규칙과 계산, 파싱과 상태 변경은 파이썬에 두고, 분류나 조사, 종합처럼 의미 판단이 필요한 일은 LLM에 맡기는 구성을 권장합니다.
타입 주석은 결과의 모양만 정하는 데서 끝나지 않습니다. 예를 들어 소프트웨어 수정 결과에 오류의 원인, 근거와 검증 명령을 필수 항목으로 지정하면, 모델은 이를 모두 제출해야 작업을 끝낼 수 있습니다. 빠진 항목이 있거나 형식이 맞지 않으면 런타임이 수정을 요구하지요. 즉, 타입은 에이전트가 무엇을 제출해야 완료로 인정할지를 정하는 계약으로도 쓰입니다. 다만 형식 검사가 결과의 정확성까지 보장하지는 않습니다.
모델은 대화창이 아니라 실행 환경에서 작업한다고?
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만 토큰이 들었지요. 연구진은 중간 결과를 실제 객체와 변수에 남겨두는 구조가 이런 효율에 기여했다고 분석합니다.
무엇이 새롭고, 또 어디까지 검증됐을까?
NOOA의 개별 요소가 모두 새로운 것은 아닙니다. 타입 기반 입출력, 객체 상태, 코드 실행과 참조 전달은 기존 시스템에도 있었지요. 하지만 NOOA의 차별점은 개발자가 보는 소프트웨어 구조와 모델이 실제로 사용하는 작업 구조를 하나로 맞추려 했다는 점에 있습니다.
기존 프레임워크에서는 개발자가 그래프와 상태 저장소, 도구 실행기를 구성하지만, 모델은 주로 대화 메시지와 JSON 형태의 도구 목록을 봅니다. 반면 NOOA에서는 모델도 class와 method, 타입, 변수와 실행 결과를 중심으로 작업하지요. 개발자가 정의한 구조가 모델에게도 그대로 작업 인터페이스가 되는 셈인데요. 연구진은 조사한 기존 시스템 가운데 이 기능들을 하나의 인터페이스에 모두 담은 도구는 NOOA가 처음이라고 주장합니다.
다만 이번 연구의 평가 결과를 객체지향 설계 하나의 효과라고 단정하기는 어렵습니다. 실제 시스템에는 타입 검증, 코드 실행, 객체 참조, 컨텍스트 구성과 종료 조건이 함께 적용됐기 때문이지요.
분리 검증은 메모리 기능에 대해서만 이뤄졌는데요. 낯선 게임 환경에서 규칙을 스스로 알아내야 하는 ARC-AGI-3에서 같은 에이전트의 메모리를 마크다운 파일로 대체했더니 점수가 11.8포인트 낮아졌습니다. 반면 타입 검증이나 객체 참조 같은 나머지 요소가 각각 얼마나 기여했는지는 따로 확인되지 않았습니다. 또한 모델이 작성한 코드를 안전하게 실행하려면 별도의 격리 환경이 필요합니다. 평가에 쓰인 네 벤치마크도 결국 모델이 코드를 써서 푸는 과제라는 공통점이 있는데요. 문서 작성이나 고객 응대처럼 코드 실행이 개입할 여지가 적은 업무에서도 같은 효과가 나타나는지는 추가 검증이 필요합니다.
