논문: NVIDIA-labs OO Agents: Native Python Object-Oriented Agents (arXiv:2607.20709) 코드: NVIDIA-NeMo/labs-OO-Agents 소속: NVIDIA
왜 다시 에이전트 프레임워크인가
2025–2026년, 에이전트 프레임워크는 난립의 시대를 지나고 있다. LangChain, LangGraph, OpenAI Agents SDK, Claude Agent SDK, Microsoft Agent Framework, Google ADK, PydanticAI, smolagents, OpenHands, OpenCode, OpenClaw — 저마다 유용한 프리미티브(도구, 메모리, 워크플로우, 트레이스, 코드 실행)를 제공하지만, 에이전트 소스 코드를 프롬프트 템플릿, 스키마, 콜백, 설정 파일, 오케스트레이션 코드로 분할한다.
NVIDIA 연구팀은 여기에 하나의 질문을 던진다.
“파이썬에 이미 추상화가 있다면, 그것을 그대로 쓰면 안 되는가?”
NOOA(NVIDIA Object-Oriented Agents) 는 그 대답이다. 에이전트를 파이썬 클래스로, 액션을 메서드로, 상태를 필드로, 프롬프트를 독스트링으로, 계약을 타입 어노테이션으로 — 파이썬이 이미 가진 성숙한 추상화를 에이전트에 그대로 적용한다.
핵심 설계 원칙
NOOA는 다섯 가지 원칙에서 출발한다.
P1. 파이썬 추상화 재사용
클래스 = 에이전트, 메서드 = 기능, 필드 = 상태, 타입 어노테이션 = 계약, asyncio = 동시성, 예외 = 실패 신호. 새로운 DSL을 만들지 않고, 파이썬이 이미 가진 것을 쓴다. LLM이 이미 학습한 파이썬 코드 분포에 가장 가깝다.
P2. 에이전트 루프 = 메서드 호출
에이전트 루프를 비정형 텍스트 교환이 아니라, 타입이 지정된 입력·출력을 가진 일반 파이썬 메서드 호출로 본다. 인자는 참조(reference) 로 전달되는 살아 있는 파이썬 객체이고, 하네스는 제한된 미리보기만 렌더링한다.
P3. 결정적 작업은 루프 밖으로
LLM은 의미 판단, 합성, 개방형 작업에 쓰고, 정확한 규칙·산술·파싱·상태 전이는 결정적 메서드로. 코드 바디가 ...(ellipsis)이면 에이전트 메서드, 실제 구현이 있으면 일반 파이썬 메서드다.
P4. 모델의 파이썬 지식 활용
LLM은 이미 파이썬을 안다. 모델에게 도구 호출(JSON) 대신 일반 파이썬 코드를 쓰게 하면, 루프·조건문·asyncio·데이터베이스 클라이언트·시각화 라이브러리까지 그냥 쓸 수 있다. 새 프롬프트나 DSL을 배울 필요가 없다.
P5. 하네스를 명시적 API로 노출
컨텍스트 블록, 이벤트 히스토리, 상태 렌더링 — 이런 에이전트 특화 개념을 파이썬 API로 노출한다. 개발자와 모델이 같은 인터페이스로 접근한다.
에이전트는 어떻게 생겼는가
Figure 1은 NOOA에서 에이전트가 얼마나 단순한지 보여준다.
하나의 클래스가 소스 코드이자 프롬프트 표면이자 타입 계약이자 도구 인터페이스이자 상태 경계다. predict_issue_type은 단발성 전략(Predict), resolve는 반복적 코드 전략(CodeAct)으로 실행된다.
CodeAct 전략 루프
Figure 2는 CodeAct 전략의 내부 루프를 보여준다.
- 호출자가 메서드 호출 → 하네스가 컨텍스트 렌더링
- LLM이 파이썬 코드를 생성 → 하네스가 REPL에서 실행
- 실행 결과(이벤트)를 히스토리에 추가 → 다음 턴 컨텍스트 업데이트
- 모델이
return으로 타입 검증된 값을 제출 → 호출자에게 반환
컨텍스트 엔지니어링
Figure 3은 NOOA의 3-영역 컨텍스트 구조를 보여준다.
- 정적 블록: 시스템 프롬프트, 전략 지시사항 (한 번 계산, 턴 간 재사용)
- 이벤트 히스토리: 실행 트레이스의 append-only 시퀀스 (모델의 도구 호출, 파이썬 출력, 반환값)
- 동적 블록: 매 턴 재계산되는 live state (TODO 리스트, 에이전트 필드 등)
이 구조는 KV 캐시 재사용을 극대화하도록 설계되었다. 정적 접두사는 불변, 이벤트 히스토리는 append-only, 동적 블록은 꼬리에 배치된다.
Pass by Reference
가장 혁신적인 부분 중 하나다. 메서드 인자가 살아 있는 파이썬 객체로 전달된다. 예를 들어 100개 원소의 리스트를 받으면, 프롬프트에는 다음과 같이 표시된다.
numbers: list[int] (len=100) [42, 17, 93, ..., 88, 3, 56]
타입, 길이, head/tail 샘플만 보여주고, 실제 변수는 잘리지 않는다. 모델은 코드 안에서 numbers[0:50]처럼 전체에 접근할 수 있다. 컨텍스트 윈도우가 아니라 실행 환경이 처리 한계를 결정한다.
벤치마크 성과
SWE-bench Verified (소프트웨어 엔지니어링)
| 설정 | NOOA | OpenCode | PI |
|---|---|---|---|
| GPT-5.5 (xhigh) | 82.2% | 78.6% | 78.2% |
| GPT-5.5 (high) | 78.8% | — | — |
| Opus 4.6 (high) | 79.8% | 75.2% | 75.8% |
NOOA는 253줄의 일반 파이썬 코드로 작성된 범용 에이전트다. 특화된 시스템과 비교해도, Claude Code(80.8%)와 거의 동등하고 Codex(88.7%)에 다가간다.
Terminal-Bench 2.0 (터미널 환경)
| 설정 | NOOA | OpenCode | PI |
|---|---|---|---|
| GPT-5.5 (off) | 46.1% | 34.8% | 37.1% |
| GPT-5.5 (high) | 73.0% | 60.7% | 68.5% |
| Opus 4.6 (high) | 65.2% | 43.8% | 58.4% |
Terminal-Bench에서의 격차가 더 크다. 추론이 꺼져 있을 때 NOOA는 OpenCode를 11.3포인트 앞선다.
토큰 효율성
더 높은 패스율이 더 긴 궤적에서 오는 것이 아니다. SWE-bench xhigh에서:
- NOOA: ~28 모델 호출, ~1.1M 토큰 → 82.2%
- OpenCode: 비슷한 호출 수, ~1.3M 토큰 → 78.6%
- PI: 66 호출, ~2.2M 토큰 → 78.2%
도구 출력이 트랜스크립트를 통해 반복 직렬화되지 않고, 살아 있는 파이썬 값으로 유지되기 때문이다.
ARC-AGI-3 (인터랙티브 추론)
가장 인상적인 결과다. 기존 6개 전문 에이전트(DreamTeam)의 협업 시스템을, NOOA 에이전트 1개 + 50줄 스킬로 대체했다.
- GPT-5.5: RHAE 50.2% (베이스라인 41.7% 대비 +8.5점)
- GPT-5.6-sol: RHAE 85.1% (게임당 $20 미만)
- 동일 모델의 raw 성적은 13.3% → 6.4배 하네스 효과
14개 프레임워크 비교
논문의 부록에서는 14개 에이전트 프레임워크를 6가지 인터페이스 역량으로 비교한다.
| 역량 | 설명 |
|---|---|
| Typed I/O | 에이전트 호출에 타입이 지정된 입력·출력 |
| Pass by reference | 직렬화가 아닌 살아 있는 객체 참조 |
| Code as action | 실행 가능한 코드가 액션 인터페이스 |
| Loop engineering | 개발자·모델 모두 오케스트레이션 루프 작성 가능 |
| Object state | 모델이 볼 수 있는 타입 지정된 영속 상태 |
| Harness APIs | 컨텍스트·이벤트가 모델 호출 가능한 API |
대부분의 프레임워크가 이 역량들의 부분집합을 지원한다. 특히 OpenAI의 샌드박스 에이전트, Microsoft의 CodeMode, PydanticAI의 코드 모드 등이 NOOA 평가 기간 중 실험적으로 출시되었는데, 연구팀은 이를 “분야가 이 여섯 가지 아이디어로 수렴하고 있다”고 해석한다.
메모리 시스템
ARC-AGI-3 플릿은 이 메모리 시스템을 집요하게 활용했다: 3,262개 메모리 작성, 12,654회 자동 주입, 27,115회 의도적 도구 읽기(99% 적중률). 메모리 주입은 턴당 평균 4.1개로 억제되어 컨텍스트 폭주를 막는다.
의미와 전망
NOOA의 기여는 단순히 “또 다른 프레임워크”가 아니다. 에이전트 소프트웨어를 일반 소프트웨어로 만드는 설계 철학이다.
- 검증 가능한 종료: 모델이 도구 호출 없이 응답하면 끝나는 기존 방식과 달리, 타입 검증된
return이 있어 미지원 완료 선언을 방지한다 - 컨텍스트 효율성: pass-by-reference로 토큰 소모를 절반 수준으로 줄이면서 더 높은 성과를 낸다
- 미래 방향: 에이전트 최적화가 프롬프트 탐색을 넘어 전체 에이전트 객체(시그니처, 도우미 코드, 컨텍스트 정책, 재시도 루프)를 재작성하는 방향으로 나아가야 한다고 제안한다
- RL의 새로운 액션 공간: 하네스 자체가 RL이 학습하는 액션 공간이 된다 — 어떤 컨텍스트를 드러낼지, 어떤 변수를 보존할지, 언제 결정적 코드를 작성할지
한계도 명확하다. 모델이 작성한 코드를 에이전트 프로세스 내에서 실행하기 때문에, 샌드박싱(컨테이너, VM, 권한 시스템)은 외부에서 해야 한다. pass-by-reference를 포기하고 직렬화 복사를 받아들이는 샌드박스 코드 모드와의 트레이드오프가 존재한다.
더 실습해보고 싶은 분들께
에이전트 하네스 설계와 코드 액션 루프, 긴 호라이즌 에이전트 시스템에 관심이 생겼다면, 직접 손으로 만들어보는 것이 최고입니다. 실전 에이전트 자동화 루프와 컨텍스트 엔지니어링을 다룬 다음 두 자료를 추천합니다:
이 글은 arXiv:2607.20709 논문을 기반으로 작성되었습니다. 이미지 출처: NVIDIA (NOOA 논문).