AlphaDiana: 답을 넘어 과정을 재는 에이전트 측정 시스템

도구를 쥐여줘도 점수가 오르지 않는 이유를 실행 과정과 자원 기록까지 묶어 설명하는 측정 시스템 AlphaDiana를 해설합니다.

원문 논문 보기
'AlphaDiana: 답을 넘어 과정을 재는 에이전트 측정 시스템' 기사 커버 이미지

AlphaDiana: A Measurement System for Agents in Verifiable Reasoning Tasks라는 논문이 arXiv 2610.20675로 공개됐습니다. 원문 링크는 제목 아래에 걸어두었습니다. 이 연구가 내세우는 주장은 한 문장으로 정리됩니다. 답의 정오만 재는 평가를 넘어, 실행 과정과 자원 기록까지 함께 묶어야 에이전트를 제대로 비교하고 고장을 진단할 수 있다는 것입니다.

답만 맞으면 된다는 말에 저는 고개를 갸웃했습니다

안녕하세요, 패트릭입니다.

시험을 떠올려보시면 이해가 빠릅니다. 같은 90점이라도 한 학생은 처음부터 술술 풀었고, 다른 학생은 답안지를 세 번 갈아엎은 끝에 간신히 맞췄다면 두 90점을 같다고 말하기 어렵죠. 그런데 에이전트 평가는 오랫동안 앞의 숫자만 봤습니다. 답이 맞았는지, 점수가 몇 점인지가 거의 전부였습니다. 저는 이 논문에서 가장 흥미롭게 본 부분이 바로 이 지점입니다. 답이 아니라 과정을 재겠다고 선언했기 때문입니다.

AlphaDiana는 에이전트 측정을 위한 시스템입니다. 데이터셋과 에이전트, 환경, 그리고 점수를 매기는 scorer를 모듈식 인터페이스로 나눠 놓았는데, 이 나눔이 생각보다 중요합니다. 보통 평가 코드는 데이터 불러오기부터 실행, 채점까지 한 덩어리로 얽혀 있어서 조건 하나를 바꾸면 전체를 뜯어고쳐야 하니까요. 그래서 조건을 맞춘 비교가 말처럼 쉽지 않습니다. 반면 여기는 부품을 갈아 끼우듯 바꿀 수 있고, 그 덕분에 같은 과제와 같은 자원 규칙 아래에서 에이전트를 나란히 놓고 볼 수 있습니다. 답의 정오와 실행 상태를 trace와 자원 기록에 연결해 두었다는 점도 눈에 띕니다. 점수가 왜 나왔는지, 어디에서 막혔는지를 나중에 되짚을 수 있기 때문입니다.

그렇다면 이 시스템은 실제로 무엇을 보여줬을까요. 그 이야기는 아래에서 하나씩 풀어보겠습니다.

답만 보는 점수판과 실행 과정까지 묶어 보는 측정 방식을 나란히 보여주는 개념도
답만 보는 점수판과 실행 과정까지 묶어 보는 측정 방식을 나란히 보여주는 개념도

도구를 건넸는데 왜 점수는 그대로일까요

계산기를 쥐여주면 수학 시험 점수가 오를 것 같지만, 막상 시험지를 받아보면 익숙하지 않은 도구를 만지작거리다가 시간만 쓰는 학생도 있습니다. 에이전트도 이와 비슷합니다. 추론 모델 곁에 도구를 실행하고 호출을 정리해주는 하네스를 붙이면 당연히 좋아질 것 같지만, 실제로는 그렇지 않은 경우가 많으니까요. 이 논문이 다룬 평가 범위는 작지 않습니다. 세 개의 오픈소스 모델과 세 개의 오픈소스 하네스를 다섯 개의 답 기반 벤치마크에서 비교했고, 그중 두 모델은 상호작용형 벤치마크 두 개에서도 추가로 시험했습니다.

결과는 예상을 살짝 빗나갑니다. 하네스가 추론 정확도를 일관되게 끌어올리지 못했기 때문입니다. 언뜻 보면 도구가 할 일을 다한 것처럼 보이는데, 숫자를 뜯어보면 사정이 달라집니다. 이전에는 못 풀던 문제를 새로 푸는 이득이 생기지만, 동시에 도구가 없을 때는 맞췄던 문제를 새로 틀리는 손실도 함께 생깁니다. 그래서 전체 점수는 제자리걸음을 하거나 오히려 뒤로 물러서기도 합니다. 이 차이는 생각보다 중요합니다. 도구가 도움이 됐다는 말과 점수가 올랐다는 말이 같은 말이 아니라는 뜻이니까요.

여기서는 조금 조심해서 읽을 필요가 있습니다. 이 결과는 도구가 쓸모없다는 말이 아닙니다. 도구가 푸는 문제와 망치는 문제가 따로 있다는 말에 가깝습니다. 그렇다면 다음 질문은 자연스럽게 이렇게 이어집니다. 하네스는 정확히 무엇을 더하고 무엇을 빼앗는 걸까요.

같은 추론 문제를 푸는 세 하네스의 실행 흐름이 하나의 평가기로 모이는 구조도
같은 추론 문제를 푸는 세 하네스의 실행 흐름이 하나의 평가기로 모이는 구조도

그렇다면 하네스는 무엇을 더하고 무엇을 빼앗을까요

같은 재료를 줘도 주방마다 맛이 달라지는 이유는 조리 순서가 다르기 때문입니다. 하네스도 비슷합니다. 모델 호출을 언제 하고, 도구를 언제 실행하며, 어떤 기록을 다음 단계로 넘길지를 정하는 통제 고리(control loop)가 저마다 다릅니다. AlphaDiana는 이 고유한 통제 고리를 그대로 살리면서 측정하겠다고 합니다. 하네스를 뜯어고쳐서 하나로 통일하는 대신, 각 하네스가 원래 하던 방식대로 돌게 두고 바깥에서 조건을 맞추는 길을 택했기 때문입니다.

이 선택이 마음에 드는 이유는 현실과 가깝기 때문입니다. 실제 현장에서는 하네스를 논문용으로 다듬은 버전이 아니라 각 팀이 매일 쓰는 그대로 돌립니다. 그런데 통제 고리를 건드리면 측정 편의를 위해 현실을 바꾼 셈이 되고, 그 결과는 현장으로 돌아가기 어렵습니다. 반면 AlphaDiana처럼 고유한 흐름을 살리면 비교가 조금 까다로워지는 대신 결과가 실무에 가깝게 남습니다. 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 무엇을 재는지가 어떻게 만드는지를 결정하니까요.

문제는 그다음입니다. 하네스가 새로 푸는 문제는 대개 도구 실행이 꼭 필요한 부류이고, 새로 틀리는 문제는 원래 모델 혼자 잘 풀던 부류에서 나옵니다. 다시 말해 도구가 개입하면서 생긴 추가 단계가 새로운 실패 지점이 되기도 합니다. 도구를 호출하는 형식이 어긋나거나, 돌아온 결과를 읽는 데서 미끄러지거나, 멀쩡하던 풀이 흐름이 중간에 끊기는 식입니다. 그래서 하네스 평가는 맞춘 개수만 세는 게 아니라 어디에서 새로 맞고 어디에서 새로 틀리는지를 함께 봐야 합니다. 이 시스템이 정오와 실행 상태를 trace에 묶어두는 이유도 여기에 있습니다.

스킬 설명과 지난 대화가 점수를 못 올리는 이유

요리책을 옆에 펼쳐두면 요리가 나아질까요. 분명 도움이 될 때가 있지만, 손이 바쁘고 불 조절이 급한 순간에는 책을 읽을 겨를이 없습니다. 오히려 한눈팔다가 냄비를 태우기도 하죠. 스킬 안내와 기억 유지도 비슷합니다. 도움이 될 것 같지만, 항상 그런 것은 아닙니다. 이 연구에서는 스킬 안내(skill guidance)도, 유지된 히스토리(retained history)도 정확도를 안정적으로 끌어올리지 못했습니다.

이 대목에서 많은 분들이 갸웃하실 겁니다. 설명을 더 주고 기억을 더 남겼는데 왜 점수가 안 오르냐고요. 이유는 길이를 재보면 드러납니다. 스킬 설명은 매 호출마다 읽어야 하는 분량이 되고, 쌓인 히스토리는 다음 판단이 참조해야 하는 문맥이 됩니다. 그런데 분량이 늘면 모델이 봐야 할 것도 늘어납니다. 그래서 정작 지금 풀어야 하는 문제에 쏟을 주의가 분산되기도 합니다. 도움이 되는 정보와 소음처럼 작용하는 정보가 한 통에 담겨 오는 셈입니다.

개인적으로 인상 깊었던 점은, 이 실패가 허술해서가 아니라 조건을 맞춰서 더 또렷해졌다는 것입니다. 같은 과제와 같은 자원 규칙 아래에서 스킬과 기억을 켜고 끄며 비교했기 때문에 효과가 희미하면 희미하다고 말할 수 있었습니다. 만약 조건이 제각각이었다면 이런 말은 하기 어려웠을 겁니다. 어쩌면 스킬이 좋아서 점수가 오른 것인지, 과제가 쉬워서 오른 것인지 가릴 수 없었을 테니까요. 그렇다면 스킬과 기억은 버려야 할까요. 저는 그렇게 보지 않습니다. 언제 켜야 하는지를 모른다는 것과 쓸모가 없다는 것은 전혀 다른 말이니까요.

새로 푼 문제의 이득과 새로 틀린 문제의 손실이 저울처럼 맞서는 그림
새로 푼 문제의 이득과 새로 틀린 문제의 손실이 저울처럼 맞서는 그림

자신감 넘치는 오답 앞에서 멈춰 서야 하는 이유

사람도 확신에 차서 틀릴 때가 있습니다. 목소리가 클수록 맞는 말처럼 들리지만, 막상 따져보면 근거가 빈약한 경우죠. 모델의 행동 신호도 비슷합니다. 토큰 엔트로피(token entropy)가 낮으면 모델이 다음 토큰을 망설임 없이 고른다는 뜻이라서 언뜻 자신감처럼 보입니다. 그런데 이 연구는 낮은 엔트로피가 오답과 함께 나타날 수 있다고 말합니다. 매끈하게 틀리는 답이 있다는 뜻입니다.

이 결과는 운영 측면에서 보면 상당히 큽니다. 요즘은 답의 정오를 바로 알 수 없는 일이 많아서 행동 신호로 품질을 가늠하려는 시도가 늘었기 때문입니다. 밤늦게 돌아가는 배치 작업에서 매번 정답을 대조할 수 없으니 엔트로피나 출력 길이 같은 신호로 이상을 감지하고 싶은 마음은 충분히 이해됩니다. 하지만 매끈한 오답이 존재한다면 신호 하나만 믿고 문을 열 수는 없습니다. 자신감처럼 보이는 모양과 실제로 맞는지는 다른 문제이기 때문입니다.

그래서 이 논문이 던지는 조언은 분명합니다. 행동 신호는 정오와 함께 해석해야 한다는 것입니다. 엔트로피가 낮다는 사실 자체보다 그 답이 맞았는지를 먼저 묶어 놓고, 그 다음에 신호의 의미를 읽어야 합니다. 저는 여기서 조금 의심했습니다. 혹시 엔트로피만으로 좋은 답을 고르는 장치가 현장에 이미 들어와 있는 건 아닐까 하고요. 만약 그렇다면 이 결과는 점수 문제가 아니라 안전장치 문제에 가깝습니다. 그렇다면 비용 이야기로 넘어가기 전에 한 가지를 더 짚어야 합니다. 출력이 짧아졌다는 말이 정말로 싸졌다는 뜻일까요.

매끈한 저엔트로피 곡선 옆에 오답 표시가 붙은 신뢰 신호의 함정을 보여주는 그림
매끈한 저엔트로피 곡선 옆에 오답 표시가 붙은 신뢰 신호의 함정을 보여주는 그림

적게 썼는데 왜 더 비싸졌다는 말이 나올까요

가계부를 떠올려보시면 됩니다. 한 번 장볼 때 쓴 돈은 줄었는데, 버리는 반찬이 늘어 한 달 식비가 오히려 오른 경우가 있습니다. 한 번의 실행당 출력이 줄었다는 지표도 이와 비슷합니다. 적게 뱉었으니 효율적이라고 말하고 싶지만, 정확도가 함께 떨어졌다면 이야기가 달라집니다. 이 논문은 실행당 출력이 줄어도 정답 하나당 출력 토큰은 오히려 늘어날 수 있다고 말합니다. 정확도가 떨어지면 맞는 답 하나를 건지기 위해 더 많은 시도가 필요해지기 때문입니다.

이 연결은 실무자에게 꽤 아프게 다가옵니다. 대시보드에 찍히는 토큰 그래프는 얌전해졌는데, 막상 정산해보면 정답 하나를 얻는 데 든 돈이 더 커지는 상황이 생기기 때문입니다. 특히 도구를 쓰는 에이전트는 출력 토큰 말고도 실행 비용이 따로 붙습니다. 도구를 몇 번 호출했는지, 환경을 얼마나 오래 붙잡고 있었는지, 실패한 시도가 얼마나 쌓였는지가 함께 비용으로 잡힙니다. 그래서 실행당 출력이라는 한 가지 숫자만 보면 효율을 오해하기 쉽습니다. 분모가 실행인지 정답인지에 따라 결론이 정반대로 갈리니까요.

여기서 재미있는 질문이 생깁니다. 효율을 이야기할 때 우리는 보통 속도와 분량을 먼저 보는데, 정답률과 묶지 않은 효율 지표가 과연 효율을 말하고 있는 걸까요. 저는 이 대목을 읽으면서 저희가 새로운 AI 구조를 볼 때 benchmark 숫자만 보지 않는 이유를 다시 떠올렸습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 보기 때문입니다. 그렇다면 이런 미묘한 차이를 잡아내려면 측정 장치가 어떤 모양이어야 할까요.

전체를 보고 부분을 찔러보는 측정이 필요한 이유

건강검진과 정밀검사는 역할이 다릅니다. 전체를 훑어보는 검사가 있어야 큰 이상을 놓치지 않고, 의심되는 부위를 찌르는 검사가 있어야 원인을 확정할 수 있죠. AlphaDiana가 말하는 매크로 분석과 마이크로 개입도 이와 비슷합니다. 완성된 에이전트 전체를 놓고 보는 거시 분석이 한 축이고, 도구와 스킬, 기억 같은 부품을 같은 조건 아래에서 하나씩 건드려보는 미시 개입이 다른 축입니다.

이 둘을 같은 장치에서 할 수 있다는 점이 실용적입니다. 보통은 전체 평가와 부품 실험이 서로 다른 코드에서 돌아가서 결과를 이어 붙이기 어렵습니다. 과제는 비슷해 보여도 자원 규칙이 다르고, 기록 형식도 달라서 사과와 귤을 비교하는 일이 생기니까요. 반면 모듈식 인터페이스 위에서는 같은 과제와 같은 자원 정책 아래에서 전체를 재고, 이어서 부품 하나만 바꿔 다시 잽니다. 그래서 점수 차이가 과제 탓인지 부품 탓인지 가릴 수 있습니다. 어디가 아픈지를 찍어주는 셈입니다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 도구를 뺐을 때와 스킬을 뺐을 때, 그리고 기억을 지웠을 때 각각 무엇이 달라지는지를 같은 잣대로 말할 수 있느냐는 것입니다. 이 질문에 답할 수 있어야 다음 개발 결정을 내릴 수 있습니다. 도구를 고칠지, 설명을 고칠지, 아니면 기억 방식을 고칠지를 정해야 하니까요. 저는 그래서 매크로와 마이크로를 오가는 이 설계를 연구실 점수 이상으로 평가했습니다. 다음에 무엇을 고칠지를 알려주는 측정이기 때문입니다.

실행당 토큰은 줄었는데 정답당 토큰은 늘어나는 효율과 정확도의 관계를 보여주는 도식
실행당 토큰은 줄었는데 정답당 토큰은 늘어나는 효율과 정확도의 관계를 보여주는 도식

파일 재사용과 기억 유지를 따로 조절한다는 말의 뜻

연습장을 떠올려보시면 됩니다. 지난 풀이를 그대로 베껴 오는 것과, 지난 풀이에서 배운 요령만 기억하는 것은 다릅니다. 전자는 파일을 재사용하는 일에 가깝고, 후자는 기억을 유지하는 일에 가깝습니다. AlphaDiana는 이 둘을 따로 조절한다고 합니다. 파일 재사용과 기억 유지를 각각의 손잡이로 나눠서 어느 쪽이 점수에 영향을 주는지 따로 볼 수 있게 했기 때문입니다.

이 구분이 없으면 흔히 생기는 오해가 있습니다. 이전 실행의 흔적이 남아서 점수가 오른 것을 보고 기억이 좋아서 그렇다고 말하는 경우입니다. 하지만 실제로는 파일이 그대로 남아 있어서 다시 읽은 것뿐일 수도 있습니다. 반대로 파일을 지웠는데도 점수가 유지된다면 그때는 기억 방식이 진짜로 작동한 것일 수 있습니다. 두 손잡이를 따로 돌려보지 않으면 어느 쪽의 공인지 알 수 없습니다. 그래서 이 분리는 사소한 구현 선택이 아니라 해석의 문제와 직결됩니다.

좋은데, 이걸 실제 파이프라인에 올리면 어떻게 될까요. 파일 재사용을 허용할지, 기억을 어디까지 남길지는 비용과도 연결됩니다. 파일을 오래 두면 저장 공간과 관리 부담이 늘고, 기억을 길게 끌고 가면 매 호출의 입력이 길어집니다. 반면 둘 다 끄면 매번 처음부터 헤매는 에이전트가 됩니다. 저는 이 대목에서 측정과 운영이 만난다고 봅니다. 무엇을 따로 재느냐가 곧 무엇을 따로 청구할지를 정해주기 때문입니다.

데이터셋과 에이전트, 환경, 평가기를 잇고 파일 재사용과 기억 유지를 별도 다이얼로 조절하는 시스템 개요도
데이터셋과 에이전트, 환경, 평가기를 잇고 파일 재사용과 기억 유지를 별도 다이얼로 조절하는 시스템 개요도

실무의 눈으로 보면 이 시스템은 어디에 쓸모가 있을까요

월요일 아침 스탠드업을 상상해보시면 됩니다. 누군가 새 하네스를 가져와서 점수가 2점 올랐다고 말합니다. 박수를 칠까요, 아니면 질문을 던질까요. 저는 이 논문을 읽고 나서라면 질문부터 던질 것 같습니다. 새로 푼 문제는 무엇이고 새로 틀린 문제는 무엇인지, 스킬을 끄면 어떻게 되는지, 기억을 지우면 어떻게 되는지부터 물어볼 것 같습니다. AlphaDiana는 바로 그 질문들을 던질 수 있게 해주는 장치이기 때문입니다.

저희가 새로운 AI 구조를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 이 시스템이 정오와 실행 상태, trace와 자원 기록을 한 묶음으로 엮는 방식은 그 눈과 잘 맞습니다. 점수가 오르고 내리는 것을 넘어 왜 그런지를 설명해주기 때문입니다. 특히 새로 맞춘 문제와 새로 틀린 문제를 가르는 분석은 다음 개발 방향을 정하는 데 직접 쓸 수 있습니다. 도구의 형식을 고칠지, 결과 해석을 고칠지, 아니면 도구를 꺼야 할 문제 목록을 따로 둘지를 정할 수 있으니까요.

여기서는 조금 조심해서 읽을 필요가 있습니다. 이 시스템이 좋은 점수를 보장해주지는 않기 때문입니다. 측정은 측정을 할 뿐, 에이전트를 똑똑하게 만들어주지는 않습니다. 그럼에도 측정이 필요한 이유는 결정을 싸게 만들기 때문입니다. 어느 부품을 고쳐야 할지를 빨리 알면 헛된 실험을 줄일 수 있습니다. 그렇다면 마지막으로 남은 질문은 이것입니다. 이런 측정이 자리 잡으면 에이전트 설계 자체는 어떻게 바뀔까요.

측정이 바뀌면 에이전트 설계도 바뀌지 않을까요

계량컵이 바뀌면 레시피가 바뀝니다. 재는 방식이 달라지면 만드는 방식도 따라 달라지기 때문입니다. 에이전트도 마찬가지일지 모릅니다. 답만 재는 시절에는 답을 맞히는 요령이 중요했지만, 과정과 자원까지 함께 잰다면 과정이 깨끗한 설계가 중요해집니다. 괜히 도구를 들락거리지 않고, 필요할 때만 부르고, 부른 뒤에는 결과를 끝까지 책임지는 흐름이 좋은 점수를 받게 되겠죠.

제가 앞으로 보고 싶은 것은 이런 측정이 상호작용형 과제에서 무엇을 보여줄지입니다. 이번 평가에서 두 모델은 상호작용형 벤치마크 두 개에서도 시험됐는데, 답을 고르는 과제와 환경을 상대로 움직이는 과제는 요구하는 능력이 다릅니다. 답 기반 과제에서 드러난 손실과 이득의 구조가 상호작용형 과제에서도 그대로 나타날지, 아니면 전혀 다른 그림이 그려질지가 궁금합니다. 또한 스킬과 기억이 어떤 조건에서는 도움이 되는지도 더 잘게 쪼개볼 필요가 있습니다. 지금은 안정적으로 이득을 주지 못한다는 결론이지만, 어떤 과제에서는 도움이 되고 어떤 과제에서는 소음이 되는지를 가르면 설계에 직접 쓸 수 있기 때문입니다.

그렇다면 사람의 역할은 무엇일까요. 측정이 좋아질수록 사람이 할 일은 줄어드는 것처럼 보이지만, 저는 반대로 본다고 말씀드리고 싶습니다. 무엇을 재야 하는지를 정하는 일, 그리고 재고 나서 무엇을 고칠지를 정하는 일은 여전히 사람의 몫이기 때문입니다. 답을 넘어 과정을 본다는 이 연구의 제안은 결국 그런 질문을 던집니다. 우리는 에이전트에게 무엇을 시키고, 그 일을 잘했다는 것을 어떻게 알아볼 것인가 하고요. 다음에 에이전트 점수표를 보실 때 답 옆의 빈칸을 한 번 떠올려보시면 좋겠습니다. 그 빈칸에 과정과 비용을 적어 넣는 순간, 점수표는 훨씬 더 정직해질 테니까요.

참고 자료

  1. AlphaDiana: A Measurement System for Agents in Verifiable Reasoning Tasks · arxiv.org

    리뷰 원문