AI 에이전트, 모델보다 하네스

AI 얘기를 할 때 우리는 어느 모델이 몇 점인가부터 봅니다. 그런데 최근 발표 하나가 그 시선을 정면으로 흔들었습니다. 엔비디아가 낯선 환경을 스스로 파악해 푸는 에이전트로 벤치마크 전체 레벨을 완주했는데, 핵심이 모델이 아니라 그 모델을 감싸는 관리 시스템이었다는 겁니다. 증거도 분명합니다 — 밑에 깐 모델을 서로 다른 것으로 바꿔가며 돌렸는데도 작동했습니다.

📌 30초 요약

• 낯선 환경 벤치마크에서 25개 환경 183개 레벨을 전부 완주했다고 발표했습니다.
• 모델을 갈아끼워도 작동했습니다 — 두 회사 모델로 각각 돌렸고 성향만 달랐습니다.
• GPU 커널 최적화를 7일간 쉬지 않고 돌려 기존 최고 라이브러리보다 빠른 코드를 찾아냈습니다.
• 핵심 부품 둘 — 기억이 리셋되지 않는 메모리와 막혔을 때 방향을 틀게 하는 감독 장치입니다.
• 성능 수치는 모두 만든 쪽이 잰 값이고, "최대 몇 %"라는 표현입니다.
• 논문은 자기를 "하네스"가 아니라 다른 이름으로 부릅니다. 아래에서 짚습니다.

7일 돌려서 얻은 것

첫 시험대는 GPU 연산 코드 최적화였습니다. 이미 세계에서 가장 많이 갈고닦인 영역이라 사람이 더 짜낼 게 별로 없다고 여겨지는 자리죠. 여기에 에이전트를 붙여 7일간 쉬지 않고 돌렸습니다. 500개가 넘는 방향을 탐색해 40개의 최적화 코드를 직접 구현했다고 합니다.

비교 대상	기본 연산 방식	메모리 절약형으로 확장 후
제조사 자체 라이브러리	최대 3.5% 빠름	최대 7.0% 빠름
널리 쓰이는 고속 구현체	최대 10.5% 빠름	최대 9.3% 빠름

오른쪽 열이 흥미롭습니다. 7일 걸려 찾은 최적화를 메모리를 아끼는 다른 연산 방식으로 옮기는 데 걸린 시간이 30분이었습니다. 한 번 찾아낸 요령이 비슷한 구조로 쉽게 옮겨간다는 뜻이죠. 다만 두 열의 수치가 한쪽만 오르지 않은 것도 눈여겨볼 만합니다 — 비교 대상에 따라 격차가 늘기도 줄기도 했습니다.

모델을 갈아끼워도 됩니다

여기가 이 발표의 핵심입니다. 같은 시스템을 서로 다른 회사의 모델 위에서 돌렸습니다. 전체 평가에는 한쪽 모델을, 별도 시험에는 다른 쪽 모델을 썼는데 둘 다 작동했습니다. 차이는 성능이 아니라 성향이었습니다 — 한쪽은 특정 지점에 더 빨리 도달했고, 다른 쪽은 더 적은 행동으로 목표를 이뤘습니다.

이건 실무에 바로 닿는 얘기입니다. "어느 모델이 최고인가"에 매달릴 이유가 줄어듭니다. 잘 만든 시스템 위에서는 모델이 부품이고, 부품은 갈아끼우면 됩니다. 반대로 시스템이 부실하면 아무리 좋은 모델을 넣어도 긴 작업을 못 끝냅니다. 며칠 전 정리한 코딩 벤치 점수가 높았던 익명 모델 얘기에서 "모델 하나 바꾼다고 껍데기가 따라오지 않는다"고 적었는데, 이번 발표는 그 얘기의 반대편 증명입니다.

그 껍데기가 하는 일

그럼 껍데기가 정확히 뭘 하느냐. 발표가 꼽은 부품은 둘입니다.

🔧 리셋되지 않는 기억, 그리고 감독

①기억 — 대화가 끝나면 초기화되는 보통 방식과 달리, 컴파일 결과와 성능 측정값, 이전 추론 내용을 다음 단계로 계속 넘깁니다. 그래서 같은 실수를 반복하지 않습니다.

②감독 — 이쪽이 더 흥미롭습니다. AI가 한 가지 오류나 비생산적인 방식에 갇히는 걸 감지해서 다른 전략을 시도하도록 밀어냅니다. 오래 돌리는 작업에서 제일 자주 나는 사고가 같은 자리를 맴도는 것인데, 그걸 잡아주는 장치를 따로 둔 셈입니다.

그리고 이 구조가 완전히 다른 영역에서도 그대로 돌아간다는 걸 보이려고 두 번째 시험을 했습니다. 규칙도 목표도 알려주지 않은 낯선 환경에서 스스로 규칙을 알아내야 하는 벤치마크였는데, 25개 환경 183개 레벨을 전부 해결했다고 합니다. 화면 이미지가 아니라 64칸짜리 텍스트 격자만 보고서요. 총 6,624번의 행동으로 끝냈는데 기존에 완주한 시스템(7,542번)보다 약 12% 적은 횟수였습니다.

GPU 코드 최적화와 낯선 게임 풀기는 전혀 달라 보이는데, 발표는 기본 루프가 같다고 설명합니다 — 가설 세우기 → 해보기 → 결과 보기 → 상태 갱신 → 전략 수정. 루프를 어떻게 짜느냐가 관건이라는 얘기를 예전에 정리한 적이 있는데, 그 루프가 실제로 두 영역을 건너뛰며 작동한 사례입니다.

논문은 자기를 다르게 부릅니다

여기서 한 가지 짚고 갑니다. 국내 보도는 이 시스템을 "하네스"라는 말로 설명하는데, 논문 초록은 자기를 그렇게 부르지 않습니다. 원문이 쓰는 말은 "진화적 변이 연산자"입니다 — 오래된 최적화 기법인 진화 탐색에서, 사람이 손으로 설계하던 변형 규칙을 자율 코딩 에이전트로 갈아끼웠다는 프레임이죠.

차이가 왜 중요하냐면, "하네스"로 읽으면 "에이전트를 잘 감싸는 껍데기"로 들리고, "변이 연산자"로 읽으면 "진화 알고리즘의 한 부품을 AI로 교체한 것"으로 들립니다. 논문의 주장은 후자에 가깝습니다 — 에이전트를 후보를 만들어내는 자리에서 변형을 담당하는 자리로 격상시켰다는 것입니다. 두 설명이 가리키는 것은 같지만, 어느 계보에 놓느냐가 다릅니다.

📅 그리고 두 결과는 시점이 다릅니다

하나 더 있습니다. 논문 초록에 담긴 건 GPU 커널 최적화 결과뿐이고, 낯선 환경 벤치마크 완주는 초록에 없습니다. 논문은 올해 3월 판이고 벤치마크 발표는 최근이니, 같은 시스템의 다른 시점 결과로 보는 게 맞습니다. 한 발표문 안에 섞여 나오면 하나로 읽히기 쉬운데, 어느 게 논문에 실렸고 어느 게 이후 발표인지 구분해두면 나중에 인용할 때 헷갈리지 않습니다. 숫자가 어디서 왔는지 확인하는 습관이 이런 데서 값을 합니다.

🔁 이보다 선명한 실증이 나왔습니다

「모델보다 하네스」를 이만큼 또렷하게 보여 준 사례가 드뭅니다. 클로드가 11일 동안 페르마의 마지막 정리를 기계 검증 가능한 형태로 옮긴 작업에서, 쓴 모델은 공개된 최신형이 아니라 직전 세대급 내부 모델이었습니다. 달라진 건 판이었습니다 — 할 일을 의존 관계 그래프로 세워 무엇부터 잡을지 스스로 고르게 하고, 검사 속도를 올려 시도 비용을 낮추고, 만든 것마다 설명을 붙여 다시 찾아 쓰게 했습니다. 결과가 안 나올 때 모델을 바꾸기 전에 판을 먼저 보라는 이 글의 주장이 그대로 확인된 셈입니다.

🔁 판을 고치는 가장 싼 사례 하나

「모델보다 판」을 당장 손볼 수 있는 형태로 보고 싶다면 이 건이 좋습니다. 도구를 여러 개 한꺼번에 부르는 기능은 원래 켜져 있는데, 도구 결과를 메시지마다 쪼개 넣으면 모델이 「하나씩 부르는 대화」로 배웁니다. 공식 문서가 이걸 가장 흔한 원인으로 꼽습니다 — 프롬프트가 아니라 대화 기록의 모양이 범인이라는 겁니다. 게다가 오류가 안 나고 조용히 느려지기만 해서 알아채기 어렵습니다. 모델을 바꾸기 전에 응답당 도구 호출 개수부터 세어 보시면 판이 문제인지 바로 드러납니다.

🔁 같은 논리가 점수판에서도 확인됐습니다

이 글의 결론은 껍데기가 성능을 만든다였습니다. 그 논리가 여기서 다룬 바로 그 벤치마크의 점수판에서 다시 확인됐습니다. 같은 기관이 같은 모델로 두 번 쟀는데 62.7%와 99.9%가 나왔고, 달라진 건 요청 사이에 추론 상태를 들고 가느냐 하나였습니다. 덧붙여 점수가 높은 쪽이 7천 달러 더 쌌습니다 — 앞서 한 생각을 다시 못 쓰면 같은 추론을 매번 처음부터 해야 하니까요. 그래서 이 글의 「모델보다 하네스」는 성능뿐 아니라 비용에도 그대로 적용됩니다. 반대로 말하면 껍데기가 다른 두 점수는 나란히 놓을 수 없다는 뜻이기도 합니다.

자주 묻는 질문

Q. 3.5%면 별거 아닌 것 아닌가요?

영역에 따라 다릅니다. 이미 수년간 전문가들이 갈아 넣은 코드에서 몇 %를 더 짜내는 건 쉽지 않은 일입니다. 게다가 이 연산은 AI 서비스가 돌 때마다 수없이 반복되는 부분이라, 몇 %가 전체 비용으로 환산되면 규모가 달라지고요. 다만 "최대 몇 %"라는 표현이라는 점은 기억해두세요 — 모든 조건에서 그만큼 빠르다는 뜻이 아닙니다.

Q. 저도 이런 걸 만들 수 있나요?

규모는 다르지만 발상은 그대로 가져올 수 있습니다. 핵심은 거창한 게 아니라 둘입니다 — 이전 시도의 결과를 다음 시도에 남기는 것, 그리고 같은 자리를 맴돌 때 방향을 트는 장치를 두는 것. 실제로 에이전트를 감싸는 구조를 어떻게 짜는지는 개인 작업에서도 같은 원리로 적용됩니다. 실패 기록을 파일로 남기고 다음 프롬프트에 넣어주는 것만으로도 절반은 됩니다.

Q. 그럼 모델 성능은 이제 안 중요한가요?

그렇게 읽으면 과합니다. 이번 실험도 최상급 모델 두 개를 썼습니다. 아무 모델이나 넣어도 된다는 얘기가 아니라, 일정 수준을 넘은 모델들 사이에서는 순위표 차이보다 시스템 차이가 결과를 더 크게 가른다는 쪽에 가깝습니다. 실제로 두 모델의 성향 차이도 관찰됐고요. "모델은 무의미하다"가 아니라 "모델만으로는 부족하다"입니다.

🧾 정직하게 밝혀둡니다

• 성능 수치는 전부 만든 쪽이 발표한 값입니다. 제3자 재현 결과는 확인하지 못했습니다.
• ★"최대 몇 %"라는 표현입니다. 평가한 여러 설정 중 가장 좋은 경우이지 평균이 아닙니다.
• ★국내 보도의 "하네스"와 논문의 자기 규정이 다릅니다. 본문에 그대로 적었습니다. 어느 쪽이 틀렸다기보다 같은 것을 다른 계보에 놓고 설명하는 차이로 보입니다.
• ★커널 최적화 결과와 벤치마크 완주는 시점이 다른 발표입니다. 논문 초록에는 앞엣것만 있습니다.
• 저는 논문 초록과 보도까지만 확인했고 본문 전체를 읽지 않았습니다. 세부 조건은 원문에서 확인하세요.

✨ 정리하면

모델을 바꿔 끼워도 시스템이 버텼다는 게 이 발표의 알맹이입니다. 개인 작업에 옮길 수 있는 것도 분명합니다 — 실패를 다음 시도에 남기고, 맴돌 때 방향을 트는 장치를 두는 것. 순위표를 덜 보고 내 작업 구조를 한 번 보시는 게 낫습니다. AI 도구 비용과 설정은 AI 지출 정리 허브에 모아뒀습니다.

출처: arXiv 논문 초록 및 AI타임스 보도 (2026-08-24 확인). 성능 수치는 발표 주체의 측정값이며 평가 조건에 따라 달라집니다. 이 글은 정보 제공용입니다.