옆에서 보는 눈이 더 정확할 때, 블랙박스 에이전트를 감사하는 법

오늘 다룰 논문은 Proxy Confidence: Auditing Black-Box LLM Agents with a Surrogate's Log-Probabilities로, arXiv에 공개된 연구이며 식별자는 2610.03894입니다. 이 연구가 내세우는 주장은 한 문장으로 정리할 수 있는데, 토큰 확률을 공개하지 않는 블랙박스 에이전트의 행동이라도 옆에서 함께 도는 작은 open-weight surrogate의 log-probability로 채점하면 실수를 훨씬 잘 골라낼 수 있다는 것입니다. 원문 링크는 제목 아래에 걸어 두었으니 필요하실 때 바로 찾아보시면 됩니다.

왜 에이전트의 실수는 실행되고 나서야 보일까

배포된 LLM 에이전트를 보고 있으면 묘한 불안이 따라옵니다. 채팅창 속 답변은 틀려도 그 자리에서 고치면 되는데, 에이전트가 내보내는 tool call이나 쿼리, 코드는 그렇지 않기 때문입니다. 삭제 명령이 나간 뒤에, 잘못된 인자가 DB 쿼리에 들어간 뒤에, 비로소 결과가 이상하다는 것을 알게 되죠. 저는 이 지점에서 이 논문을 읽기 시작했습니다. 에이전트 시대의 실수는 문장 속 오타가 아니라 이미 실행된 행동의 형태로 남으니까요.

연구가 그리는 장면은 꽤 구체적입니다. 에이전트가 어떤 도구를 호출할지, 어떤 인자를 넣을지 제안하는 순간에는 아직 아무 일도 일어나지 않았습니다. 그래서 감사(audit)가 끼어들 여지가 있는데, 문제는 그 제안을 얼마나 믿을 수 있는지 판단할 재료가 바깥에서는 거의 보이지 않는다는 점입니다. Frontier 채팅 API들은 모델 내부의 토큰 확률을 숨기고, 에이전트가 스스로 말하는 자신감은 결정적인 실수 앞에서는 동전 던지기 수준을 barely 넘깁니다. 그렇다면 우리는 무엇으로 그 제안을 걸러야 할까요.

여기서 재미있는 질문이 생깁니다. 안에서 무슨 일이 일어났는지 볼 수 없다면, 밖에서 그럴듯하게 다시 읽어보는 눈이라도 있으면 되지 않을까. 마치 수술실에 들어갈 수 없는 대신 옆방 모니터로 환자의 파형을 함께 보는 두 번째 의사처럼요. 이 논문은 그 두 번째 눈을 값싼 surrogate 모델로 만들자고 제안합니다.

스스로 매긴 점수는 왜 동전 던지기와 비슷해졌을까

에이전트에게 "네 답이 맞을 확률이 몇 퍼센트니"라고 물으면 꽤 자신 있게 숫자를 말합니다. 그런데 이 숫자가 정작 중요한 실수 앞에서는 힘을 잃는다는 것이 연구의 출발 진단입니다. 어려운 코딩 과제에서 행위자(actor) 스스로 말한 신뢰도의 AUROC는 0.598에 머물렀는데, 이는 무작위인 0.5에서 한 걸음 정도 떨어진 수준입니다.

왜 이런 일이 생길까요. 저는 이 대목을 읽으면서 사람이 자기 글의 오타를 잘 못 찾는 장면을 떠올렸습니다. 쓴 사람과 검수하는 사람이 같으면 같은 맹점이 반복되기 때문입니다. 모델이 자기 행동을 평가할 때도 비슷한 일이 벌어집니다. 이미 한 번 그럴듯하다고 판단한 호출을 두고 "정말 그럴듯하니"라고 다시 물으면, 같은 내부 경향이 같은 대답을 돌려주기 쉽죠. 그래서 겉으로는 숫자가 있지만 실제로는 변별력이 없는 상태가 됩니다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 자기 평가가 안 된다면 외부에서 빌려올 신호는 무엇일까. 토큰 확률을 달라고 API 제공자에게 요구할 수도 있겠지만, 현실의 배포 환경에서는 그 문이 닫혀 있는 경우가 많습니다. 연구는 그래서 아예 방향을 틀어, 에이전트 내부를 열지 않고도 구할 수 있는 대리 신호(proxy signal)를 찾습니다.

같은 답을 또 물어보면 되지 않을까

불확실할 때 흔히 쓰는 방법은 여러 번 물어보고 답이 얼마나 일치하는지 보는 self-consistency입니다. 다섯 번 물어 다섯 번 같은 도구를 고르면 자신감이 높고, 매번 다른 답이 나오면 의심스럽다는 직관인데, 이 직관은 수학 문제처럼 답이 흔들리는 과제에서는 꽤 잘 먹혔습니다.

그런데 에이전트의 tool call 앞에서는 이 방법이 자주 헛발질을 합니다. 이유는 frontier 모델들이 지나치게 반복적(repetitive)이기 때문입니다. 같은 요청을 여러 번 던져도 같은 호출을 그대로 복제해서 내놓으니, 일치가 높다는 신호가 정확하다는 신호와 뒤섞이는 것이죠. 틀린 답을 다섯 번 모두 똑같이 틀리면 self-consistency는 "아주 자신감 높음"이라고 도장을 찍습니다.

저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 반복성은 모델의 잘못이 아니라 학습된 장점인데, 감사 관점에서는 독이 되기 때문입니다. 결정적(deterministic)에 가까운 행위자일수록 샘플링 기반 감사는 무력해집니다. 그렇다면 매번 새로 뽑는 대신, 한 번 제안된 호출을 옆에서 곱씹어 보는 방식이 필요하지 않을까요. 이 질문이 surrogate라는 아이디어로 이어집니다.

옆에서 함께 도는 작은 눈이 대안이 될 수 있을까

제가 이 논문에서 가장 흥미롭게 본 부분은 바로 여기입니다. 큰 행위자 모델을 여는 대신, 작고 값싼 open-weight 모델을 나란히 두고 제안된 행동을 채점하자는 발상인데, 구조가 생각보다 단출합니다. 에이전트가 tool call을 제안하면 그 호출 자체는 그대로 두고, surrogate가 같은 문맥과 같은 호출을 입력으로 받아 자신의 log-probability를 계산합니다. 이를테면 teacher forcing 방식으로 "나라면 이 토큰들을 얼마나 자연스럽게 내놓았을까"를 재는 것이죠.

배포 그림을 그려보면 이해가 쉽습니다. 어느 금요일 오후, 고객 요청이 들어와 에이전트가 환불 처리 함수를 호출하려 한다고 해보죠. 호출 전에는 아직 돈이 움직이지 않았습니다. 그 짧은 틈에 surrogate가 옆 라인에서 한 번의 prefill pass로 점수를 매깁니다. 에이전트 내부를 열 필요도 없고, API 제공자에게 확률을 달라고 조를 필요도 없습니다. 제안된 텍스트만 있으면 되니까요.

이 방식이 먹히는 까닭은 두 모델이 같은 분포가 아니어도 감사 신호는 살아남기 때문입니다. Surrogate가 행위자보다 작고 약해도, 이상한 인자 값 앞에서는 "나라면 이렇게는 안 쓰지"라는 반응이 나타나고, 그 반응이 log-probability의 dip으로 기록됩니다. 물론 작은 모델의 취향이 정답과 다를 수도 있는데, 연구는 이 잡음을 네 가지 채점 방식으로 다듬습니다.

하나의 호출을 보는 네 개의 렌즈는 각자 무엇을 잴까

연구가 제안하는 채점기는 하나가 아니라 넷입니다. 같은 호출을 서로 다른 각도에서 보는 렌즈들이죠. 처음 들어보면 많아 보이지만, 각자가 잡는 실수의 모양이 달라서 함께 두면 공백이 줄어듭니다.

첫째는 teacher forcing likelihood입니다. 제안된 호출 토큰들에 대한 surrogate의 log-probability를 그대로 합산하는 방식으로, 문장 전체가 surrogate의 눈에 얼마나 자연스러운지를 잽니다. 인자 값이 어긋난 경우에 특히 반응합니다. 함수 이름은 맞는데 날짜 형식이 이상하거나, ID 자릿수가 어긋난 경우처럼요. 국소적인 어색함이 확률의 골짜기로 드러나기 때문입니다.

둘째는 request-PMI입니다. 요청이 있을 때와 없을 때의 확률을 비교해서, 요청이 그 호출을 얼마나 더 그럴듯하게 만드는지를 봅니다. 호출 자체는 유창한데 요청과 무관한 경우를 가려내는 데 도움이 됩니다. 문장이 매끈하다고 해서 요청에 답한 것은 아니니까요. 조건부 확률과 무조건부 확률의 차이가 일종의 관련도 신호가 됩니다.

셋째는 discriminative verdict입니다. Surrogate에게 "이 호출이 맞니 틀리니"라고 직접 묻고 그 대답의 확률을 점수로 씁니다. 생성 확률이 토큰 단위의 어색함에 민감하다면, verdict는 호출 전체가 방향부터 틀렸는지를 봅니다. 엉뚱한 도구를 골랐거나 순서를 뒤집은 경우처럼 부분 점수로는 잡기 어려운 경우죠.

넷째는 tool-choice competition입니다. 같은 자리에서 고를 수 있었던 다른 도구들에 비해 선택된 도구가 얼마나 우세했는지를 비교합니다. 두 후보가 박빙이면 자신감을 깎고, 압도적이면 인정하는 방식인데, 함수 선택의 경계에 선 경우를 다룹니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 네 가지가 모두 항상 필요한 것은 아니고, 실수의 종류에 따라 잘 맞는 렌즈가 달라지기 때문입니다. 그래서 연구가 내린 처방은 ensemble입니다. 어떤 실수가 올지 모를 때는 여러 렌즈를 합친 쪽이 후회가 적다는 것인데, 저도 이 판단에는 동의합니다. 감사는 평균적인 날이 아니라 낯선 실수가 오는 날을 대비하는 일이니까요.

인자 값이 틀린 것과 방향 자체가 틀린 것은 왜 다르게 잡힐까

앞선 네 가지 렌즈 뒤에는 하나의 구분이 놓여 있습니다. 생성 확률(generative likelihood)은 잘못된 인자 값을 잘 짚어내고, verdict는 전체적으로 잘못된 호출을 잘 잡는다는 구분인데, 저는 이 대목이 논문 전체에서 가장 실무적인 문장이라고 봅니다.

예를 들어 환불 금액 필드에 10000 대신 1000000이 들어갔다고 해보죠. 함수 선택은 맞고 구조도 맞지만 숫자 하나가 어긋난 경우입니다. 이때는 전체 판단보다 토큰 단위 확률이 먼저 반응합니다. Surrogate의 눈에 그 숫자 나열이 낯설게 느껴지기 때문입니다. 반대로 금액은 멀쩡한데 엉뚱한 계정에 환불을 찍었다면 토큰 하나하나는 매끈할 수 있습니다. 이런 경우에는 "이 호출이 맞니"라는 verdict가 방향의 어긋남을 잡습니다.

문제는 그다음입니다. 실제 배포에서는 어떤 실수가 올지 미리 알 수 없습니다. 숫자 실수만 오는 날도 없고 방향 실수만 오는 날도 없죠. 그래서 연구는 error type이 unknown일 때 ensemble을 low-regret default로 두자고 말합니다. 모든 날에 최고는 아니어도 어느 날에도 크게 망하지 않는 선택이라는 뜻인데, 운영을 해본 사람이라면 이 표현의 무게를 알 것입니다. 감사 장치는 똑똑해야 하는 동시에 무너지지 않아야 하니까요.

어려운 코딩 과제에서 0.825와 0.598은 어떻게 갈렸을까

이제 숫자를 볼 차례입니다. 어려운 코딩 과제에서 proxy confidence는 AUROC 0.825에 도달했고, 같은 자리에서 행위자 스스로의 신뢰도는 0.598에 머물렀습니다. 0.5가 무작위라는 점을 떠올리면, 한쪽은 실수를 꽤 가려내고 다른 한쪽은 거의 가리지 못했다는 차이가 됩니다.

이 차이는 한 행위자에만 머물지 않았습니다. 세 개의 다른 행위자에게 같은 감사를 붙여도 proxy 쪽이 0.07에서 0.28만큼 앞섰는데, 범위가 제법 넓다는 점이 오히려 이야기가 됩니다. 어떤 행위자는 격차가 작고 어떤 행위자는 격차가 큰데, 그럼에도 방향은 바뀌지 않았기 때문입니다. Surrogate가 특정 모델의 버릇에만 과적합된 것이 아니라 꽤 넓게 통한다는 뜻이죠.

저는 여기서 한 가지를 덧붙이고 싶습니다. AUROC 같은 순위 지표는 임계값을 정하기 전의 잠재력을 보여주지, 곧바로 배포 정확도를 뜻하지는 않습니다. 순서를 잘 매긴다는 것과 어디서 끊을지는 다른 문제이기 때문입니다. 그래서 다음으로 봐야 할 것은 이 점수를 실제 게이트에 걸었을 때 벌어지는 일입니다. 논문도 그 순서로 이야기를 이어가는데, 이런 구성은 마음에 듭니다. 지표 자랑에서 멈추지 않고 운영의 문턱까지 걸어가니까요.

한 번의 prefill로 여러 번의 샘플링을 이기는 구조는 무엇일까

Self-consistency와의 비교는 비용 이야기와 함께 읽어야 합니다. Near-deterministic한 행위자 앞에서는 proxy confidence가 0.14에서 0.19만큼 앞섰는데, 비용은 샘플 수 K에 대해 1/K 수준이었습니다. K번 되묻는 대신 한 번의 prefill pass로 끝내기 때문입니다.

이 차이는 생각보다 중요합니다. 샘플링은 행위자 모델을 K번 돌려야 해서 비싸고 느린데, 그 비싼 대가가 반복성 앞에서는 정확도로 돌아오지도 않습니다. 반면 surrogate 채점은 행위자의 tool call과 함께 나란히 한 번 돌면 됩니다. 행위자 내부를 들여다보지 않으니 블랙박스 API와도 그대로 붙습니다.

저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 이 논문으로 돌아오면, 바뀐 것은 감사 주체가 행위자 자신에서 옆 모델로 옮겨갔다는 점이고, 비용 구조는 행위자 재호출에서 surrogate 1회 prefill로 가벼워졌다는 점입니다. 정확도와 비용이 같은 방향으로 움직였다는 것이 이 대목의 진짜 소득입니다. 물론 surrogate를 띄우는 GPU 비용 자체는 들지만, frontier 모델을 여러 번 돌리는 것과 비교하면 운영 계산이 서는 경우가 많습니다.

그렇다면 이 한 번의 채점이 얼마나 안정적일까요. 생성 확률 하나만 쓰면 surrogate의 취향에 흔들릴 수 있는데, 연구는 PMI와 verdict, 도구 경쟁을 합쳐 흔들림을 줄입니다. 한 번 본다는 것이 얕게 본다는 뜻은 아니라는 것이죠.

문을 열어줄지 말지 그 자리에서 고르면 정확도가 어떻게 달라질까

배포 실험에서 가장 눈에 들어온 장면은 실시간 게이트입니다. 들어오는 action마다 proxy 점수를 매기고, 점수가 낮은 절반은 일단 보류하고 높은 절반만 통과시키는 방식인데, 통과된 action의 정확도가 0.05에서 0.30만큼 올랐습니다. Coverage를 50%로 잡았다는 조건이 붙지만, 그 조건 자체가 운영의 언어로 쓰여 있다는 점이 좋습니다.

상상해보면 어느 월요일 아침, 에이전트가 백 개가 넘는 DB 쓰기 작업을 제안합니다. 전부 막자니 일이 안 되고 전부 풀자니 사고가 걱정되는 상황인데, 점수 상위 절반만 자동 통과시키고 나머지는 사람이나 더 비싼 검증으로 넘기는 것이죠. 개선 폭이 0.05에서 0.30까지 넓게 퍼진 것은 환경마다 실수의 밀도가 다르기 때문일 텐데, 저는 이 편차를 나쁘게 보지 않습니다. 어려운 환경일수록 게이트의 덕이 커진다는 뜻일 수 있으니까요.

여기서 커버리지라는 말을 정확히 짚을 필요가 있습니다. 50% 커버리지는 절반을 버린다는 뜻이 아니라 절반은 빠르게 가고 절반은 천천히 확인한다는 뜻에 가깝습니다. 감사의 목적이 모든 행동을 막는 것이 아니라 의심스러운 행동을 골라내는 데 있다는 점을 떠올리면, 이 정도의 가름은 꽤 현실적인 타협입니다. 밤사이 쌓인 배치 작업을 아침에 풀 때도 같은 게이트를 쓸 수 있고, 실시간 고객 응대에서는 임계값을 더 보수적으로 잡을 수도 있겠죠.

점수를 다시 에이전트에게 돌려주면 무슨 일이 생길까

게이트가 행동을 가르는 일이라면, 피드백은 행동을 바꾸는 일입니다. 연구는 proxy 점수를 에이전트에게 다시 알려주었을 때 과제 성공률이 0.119와 0.137만큼 올랐다고 보고합니다. 무작위 값을 돌려준 대조군과 비교해도 0.078만큼 앞섰는데, 이 대조군이 꽤 예리합니다. 점수를 준다는 행위 자체의 플라시보가 아니라 점수 안의 정보가 실제로 작동했다는 것을 보여주기 때문입니다.

이 대목을 읽으면서 저는 사람도 비슷하게 배운다는 생각을 했습니다. "틀렸어"라는 말보다 "이 부분이 어색해"라는 말이 다음 시도를 더 낫게 만들죠. 에이전트에게 낮은 확률 구간을 알려주면 인자를 다시 확인하거나 다른 도구를 고려하게 되고, 그 과정에서 성공률이 올라갑니다. 일종의 오답 노트를 실시간으로 건네는 셈입니다.

다만 이 피드백이 만능은 아닙니다. 점수가 틀리면 에이전트를 잘못된 방향으로 몰 수도 있고, 점수에 과도하게 의존하면 스스로의 판단이 위축될 수도 있습니다. 연구가 무작위 대조군까지 두어 정보의 효과를 분리한 것은 그래서 믿음이 갑니다. 효과가 있다는 것과 항상 안전하다는 것은 다른 이야기지만, 적어도 효과의 출처가 점수 자체가 아니라 점수 안의 신호라는 점은 확인된 셈입니다.

그래서 블랙박스 감사는 어디까지 믿을 수 있을까

정리할 시간이 왔습니다. Proxy confidence는 에이전트를 고치는 기술이 아니라 에이전트의 제안을 읽는 기술입니다. 토큰 확률을 숨긴 행위자 옆에 작은 surrogate를 두고, teacher forcing과 request-PMI, verdict, 도구 경쟁이라는 서로 다른 렌즈로 호출을 채점한 뒤, 실수 종류를 모르는 현실에서는 ensemble으로 합치는 것이 후회가 적다는 처방이죠. 어려운 코딩 과제에서의 격차, 샘플링 대비 비용 우위, 게이트와 피드백에서의 개선은 모두 이 처방이 실제로 돌아간다는 쪽에 무게를 싣습니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. Surrogate 역시 모델이라서 행위자와 같은 편향을 공유할 수 있고, 분포가 크게 다른 도메인에서는 점수의 눈금이 어긋날 수 있습니다. 50% 커버리지에서의 개선이 곧 절반의 일을 공짜로 얻는다는 뜻도 아닙니다. 보류된 절반을 누가 어떻게 처리할지가 운영 비용으로 남기 때문입니다. 연구가 보여준 것은 감사가 가능하다는 쪽이지 감사가 끝났다는 쪽이 아닙니다.

그럼에도 제가 앞으로 보고 싶은 것은 분명합니다. 서로 다른 크기와 계열의 surrogate들이 같은 행위자를 어떻게 읽는지, 게이트 임계값을 환경별로 어떻게 잡아야 하는지, 그리고 피드백을 여러 턴에 걸쳐 줄 때 에이전트가 점수에 과적합되는 일은 없는지 같은 질문들입니다. 개별 모델 하나가 똑똑해지는지와 별개로, 옆에서 지켜보는 눈을 어떻게 둘 것인지는 에이전트 시대의 시스템 설계 문제로 남을 것 같습니다. 오늘 밤 배포 파이프라인을 만지는 분이라면, 행위자의 자신감 숫자 옆에 proxy 점수라는 두 번째 숫자를 두는 장면부터 상상해 보시면 어떨까요.