에이전트는 과제를 통과했다, 다시 시키면 어떨까

이번에 다룰 글은 IBM 리서치 팀이 허깅페이스 블로그에 올린 Your Agent Aced the Task. Will It Do It Again? 입니다. 이 글은 에이전트의 한 번짜리 성공률이 현장 성능을 부풀린다고 진단합니다. 그래서 반복해도 통하는 일관성을 기준으로 삼자고 제안하는데요. 원문 링크는 제목 아래에 붙어 있습니다.

데모를 보고 돌아오는 길에 저는 묘한 찝찝함을 느낄 때가 많습니다. 화면 속 에이전트는 주문을 넣고, 문서를 찾고, 표를 정리하는 일을 막힘없이 해내는데요. 그런데 막상 저희 환경에 올려보면 그 매끄러움이 그대로 재현되지 않습니다. 어제는 되던 예약이 오늘은 중간에서 멈추고, 어제는 찾던 문서가 오늘은 다른 경로로 돌아갑니다. 그렇다면 문제는 모델이 나빠서가 아니라, 성공을 한 번으로 판단하는 방식에 있는 게 아닐까요. 오늘은 그 질문을 처음부터 차근차근 따라가 보겠습니다.

데모에서는 되던 게 왜 운영에서는 흔들릴까

여러 사람이 함께 일하다 보면, 컨디션이 좋은 날의 모습만으로 그 사람을 평가하지는 않습니다. 바쁜 월요일 아침에도, 피곤한 금요일 밤에도 비슷한 결과를 내는지 함께 보죠. 그런데 에이전트 앞에서는 이상하게 관대해집니다. 한 번 잘하는 장면을 보면 마음속으로 채용 도장을 찍어버리니까요. 저는 이 글에서 가장 흥미롭게 본 부분이 바로 그 지점의 지적이었습니다.

에이전트의 성공은 사람처럼 보여서 더 헷갈립니다. 계획을 세우고, 도구를 고르고, 결과를 확인하는 흐름이 언뜻 보면 직원의 하루와 닮았는데요. 하지만 그 흐름을 지탱하는 바닥은 훨씬 미끄럽습니다. 같은 입력에도 출력이 조금씩 달라지는 언어 모델의 샘플링, 모호하게 적힌 계획 한 줄, 아침과 밤이 다른 외부 웹 화면이 매 실행마다 다른 판을 깝니다. 그래서 한 번의 성공은 그날의 운이 좋았다는 기록에 가깝고, 실력에 대한 증명과는 거리가 있습니다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 데모 한 번으로 통과 판정을 내린 에이전트를 운영에 올려도 될까요. 저는 여기서 멈칫했습니다. 어제의 성공이 오늘의 성공을 보장하지 않는다면, 우리가 사야 하는 건 성공 자체가 아니라 성공의 반복 가능성이기 때문입니다. 이 글의 문제의식도 같은 곳을 향합니다. 잘했다는 결과보다, 다시 해도 잘하는지를 보자는 것이죠.

한 번의 성공이 실력을 말해주지 않는 이유

그렇다면 한 번의 성공은 왜 이렇게 믿음직하지 못할까요. 이유는 에이전트의 일이 한 방짜리 답 맞히기가 아니라 여러 단계가 이어진 일이기 때문입니다. 검색하고, 읽고, 고르고, 입력하고, 확인하는 단계마다 작은 선택이 들어가는데요. 그 선택이 한 번만 어긋나도 뒤 단계는 다른 세계로 넘어갑니다. 특정 날짜의 항공권을 고르는 일이라고 해보죠. 날짜를 하루 잘못 읽으면 뒤에 따라오는 가격 비교와 예약 버튼이 전부 엉뚱한 전제를 깔고 돌아갑니다.

여기서 재미있는 질문이 생깁니다. 실패한 실행과 성공한 실행은 어디서 갈라질까요. 겉으로 보기에는 마지막 버튼을 못 눌러서 실패한 것처럼 보이지만, 실제로는 세 단계 앞에서 문서를 잘못 고른 것이 원인인 경우가 많습니다. 그런데 한 번만 실행하면 그 갈림길을 볼 수 없습니다. 성공한 궤적 하나만 남고, 실패할 수도 있었던 가지들은 기록에 남지 않으니까요. 그래서 한 번의 점수는 에이전트가 가진 분포 전체가 아니라, 그 분포에서 우연히 뽑힌 한 점을 보여줄 뿐입니다.

저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 같은 과제를 열 번 시켰을 때 여덟 번은 되고 두 번은 안 된다면, 그 에이전트는 여덟 번짜리 실력을 가진 셈인데요. 반면 열 번 중 한 번만 되고 아홉 번은 안 된다면, 그 한 번은 실력이 아니라 요행에 가깝습니다. 그런데 바깥에 공개되는 점수는 대개 후자의 요행 쪽을 크게 보여줍니다. 가장 잘 나온 한 번을 골라 내놓는 best-of-N 방식이 굳어져 있기 때문입니다. 현장에서 필요한 건 가장 빛나던 순간이 아니라, 지루하게 반복되는 보통의 날들이죠.

같은 일을 시켰는데 왜 매번 다르게 행동할까

문제는 그다음입니다. 왜 에이전트는 같은 일을 시켜도 매번 조금씩 다르게 행동할까요. 첫 번째 이유는 언어 모델 자체의 샘플링 때문입니다. 온도가 0이 아닌 이상, 모델은 다음 토큰을 확률적으로 고르는데요. 그 작은 흔들림이 계획 문장 하나를 바꾸고, 바뀐 문장이 도구 선택을 바꾸고, 도구 선택이 전체 궤적을 바꿉니다. 같은 질문을 던져도 결과가 크게 달라질 수 있다는 것을 경험으로 알고 있죠. 에이전트에서는 그 달라짐이 한 문장으로 끝나지 않고 행동의 갈림길로 증폭됩니다.

두 번째 이유는 계획의 모호함입니다. 사람의 지시는 대개 빈틈이 있는데요. 이를테면 가장 싼 표를 사라는 말은 수수료 포함인지, 환불 가능 조건인지, 경유 허용인지에 따라 전혀 다른 일이 됩니다. 에이전트는 그 빈틈을 매번 스스로 메우는데, 메우는 방식이 실행마다 달라집니다. 오늘은 가격순 정렬을 먼저 하고, 내일은 항공사 필터를 먼저 거는 식이죠. 어느 쪽도 틀린 건 아니지만, 두 경로는 실패 확률이 서로 다릅니다.

세 번째 이유는 바깥 도구의 불안정함인데, 현장에서는 이게 가장 큽니다. 웹 페이지는 어제와 오늘이 다르고, 검색 API는 같은 질의에도 순서를 바꾸고, 사내 시스템은 점검 시간에 응답을 늦춥니다. 에이전트는 이런 흔들리는 바닥 위에서 매번 새로 균형을 잡아야 합니다. 사람이야 화면이 바뀌어도 대충 눈치껏 넘어가지만, 정해진 선택자나 순서에 기대는 에이전트는 작은 변화에도 길을 잃죠. 그래서 같은 과제의 반복 실패를 모델 탓으로만 돌리기 전에, 도구가 매번 같은 답을 돌려주는지를 먼저 의심해야 합니다.

긴 일일수록 앞에서 삐끗하면 뒤가 무너진다

그렇다면 긴 일에서는 무슨 일이 생길까요. 짧은 답 맞히기는 한 번 삐끗해도 다시 고칠 기회가 있지만, 여러 단계가 이어진 일은 그렇지 않습니다. 앞에서 잘못 읽은 전제가 뒤 단계의 입력이 되면서 실수가 눈덩이처럼 불어나는데요. 생각해보면 사람도 비슷하게 배웁니다. 여행 일정을 짤 때 첫날 비행 날짜를 잘못 적어두면, 그 뒤에 붙는 숙소와 회의가 전부 어긋나죠. 에이전트의 긴 궤적도 같은 구조를 가집니다.

이 눈덩이 효과는 단계가 길어질수록 가파르게 커집니다. 각 단계가 95퍼센트씩 맞는다고 가정해 보죠. 한 단계짜리 일이면 95퍼센트로 충분해 보이지만, 열 단계가 이어지면 이야기가 달라집니다. 매번 95퍼센트를 곱해 나가면 전체 성공률은 절반 언저리까지 떨어지는데요. 이건 모델이 갑자기 멍청해져서가 아니라, 곱셈의 수학이 원래 그렇기 때문입니다. 그래서 긴 horizon 과제의 평가는 짧은 과제와 다른 잣대가 필요합니다. 단계가 늘어날수록 한 번의 성공이 말해주는 정보는 점점 옅어집니다.

여기서 조심해서 읽을 필요가 있습니다. 긴 과제의 실패를 보면 흔히 마지막 단계의 도구 호출을 고치려 드는데요. 실제로는 앞 단계의 계획과 중간 확인이 더 큰 지렛대일 때가 많습니다. 어디서 처음 어긋났는지를 찾아내는 일, 다시 말해 실패의 첫 번째 갈림길을 찾는 일이 사후 분석의 출발점입니다. 저는 앞으로 보고 싶은 것이 바로 이런 분석을 돕는 기록 방식입니다. 어느 단계에서 무엇을 보고 어떤 선택을 했는지가 남지 않으면, 눈덩이가 어디서 굴러떨어졌는지 알 수가 없으니까요.

평균과 분산을 봐야 진짜 실력이 보인다

이제 측정의 이야기로 넘어가 보죠. 한 번이 아니라 여러 번 실행한다면 무엇을 재야 할까요. 이 글이 제안하는 방향은 단순합니다. 같은 과제를 같은 조건에서 여러 번 돌리고, 그 결과들의 평균과 흩어짐을 함께 보는 것입니다. 평균은 평소 실력을 말해주고, 분산은 그 실력이 얼마나 들쭉날쭉한지를 말해주는데요. 평균이 높아도 분산이 크면 현장에서는 쓰기 어렵습니다. 월요일에는 만점인데 금요일에는 낙제인 직원을 주력으로 쓰기 어려운 것과 같은 이치죠.

저희가 새로운 아키텍처를 볼 때도 숫자 하나만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 운영에서 어떤 비용 구조를 만드는지를 함께 봅니다. 에이전트 평가도 마찬가지입니다. 평균 성공률이 조금 올랐더라도, 그게 운 좋은 몇 번이 끌어올린 평균인지, 아니면 실패하던 가지가 통째로 사라진 결과인지를 구분해야 합니다. 전자라면 다음 주에 다시 떨어질 수 있고, 후자라면 운영 투입을 진지하게 고민해볼 수 있으니까요.

좋은데, 이걸 어디에 올릴까요. 현장의 대시보드에 평균만 올려두면 절반의 진실만 보는 셈입니다. 같은 칸에 반복 횟수와 흩어짐을 같이 두는 편이 훨씬 정직하죠. 이를테면 다섯 번 실행해서 네 번 성공했다는 기록은, 한 번 실행해서 성공했다는 기록보다 훨씬 많은 말을 합니다. 평가를 설계하는 입장에서 보면 반복 실행은 비용이 들지만, 그 비용을 아끼면 더 큰 운영 비용으로 되돌아옵니다. 미리 여러 번 돌려보는 편이 장애 대응으로 밤을 새우는 것보다 쌉니다.

pass^k라는 낯선 지표가 말하는 것

그렇다면 반복 성공을 하나의 숫자로 말하려면 어떻게 해야 할까요. 여기서 pass^k라는 지표가 등장합니다. 아이디어는 직관적인데요. 같은 과제를 여러 번 돌렸을 때, 그중에서 k번을 뽑아도 전부 성공일 확률이 얼마인지를 재는 것입니다. 한 번 뽑아서 성공할 확률이 아니라, 연속으로 뽑아도 계속 성공할 확률을 묻죠. 마치 신입 직원을 뽑을 때 하루만 보고 뽑지 않고, 일주일 내내 옆에서 지켜본 뒤에 결정하는 것과 비슷합니다.

표면적으로 보면 단순합니다. 실제로는 그렇지 않습니다. 이 지표가 엄격한 이유는 운을 걷어내기 때문입니다. 열 번 중 아홉 번은 되고 한 번만 안 되는 에이전트도, k를 키우면 언젠가는 그 한 번의 실패가 걸립니다. 그래서 pass^k는 k가 커질수록 빠르게 낮아지는데요. 그 낮아지는 모양 자체가 정보입니다. 천천히 낮아지면 꾸준한 실력이고, 급격히 낮아지면 어쩌다 한 번 터지는 실력입니다. best-of-N이 가장 빛나던 순간을 골라 보여주는 지표라면, pass^k는 가장 평범한 날들을 모아 보여주는 지표라고 할 수 있습니다.

저는 이 지표를 현장의 언어로 바꾸면 이렇게 읽힌다고 봅니다. 고객 앞에 내놓아도 밤에 깨지 않을 자신감이 있는가. k는 그 자신감의 길이를 숫자로 표현한 것이죠. 한 번만 되면 되는 데모라면 k가 1이어도 충분합니다. 하지만 매일 수백 건을 처리하는 운영이라면 k를 크게 잡고 봐야 합니다. 물론 이 지표를 잴 때는 조건을 공정하게 묶어야 합니다. 온도와 도구 상태, 시간대 같은 실행 조건이 매번 달라지면, 재는 건 에이전트 실력이 아니라 환경의 날씨가 되니까요.

도구를 다듬는 것만으로 반복 성공이 올라갈까

측정 이야기가 정리됐으니, 이제 처방으로 넘어가 보죠. 가장 먼저 손댈 곳은 의외로 모델이 아니라 도구입니다. 에이전트가 손을 뻗는 외부 세계가 흔들리면, 아무리 똑똑한 계획도 매번 다른 결과를 내는데요. 그래서 도구 쪽을 단단하게 감싸는 작업이 반복 성공을 올리는 지름길이 됩니다. 입력 형식을 미리 정해두고, 받은 답이 모양에 맞는지 검사하고, 실패하면 정해진 방식으로 다시 시도하는 장치가 그것입니다.

구체적인 장면을 떠올려 보죠. 항공권 검색 API가 가끔 빈 목록을 돌려준다고 해보겠습니다. 그대로 두면 에이전트는 빈 목록을 보고 없는 표라고 판단하고 다른 날짜로 넘어갑니다. 그런데 같은 호출을 한 번 더 했더라면 표가 돌아왔을지도 모르죠. 여기서 재시도와 타임아웃, 응답 모양 검사가 들어가면 이야기가 달라집니다. 빈 응답을 실패로 판정하고 같은 요청을 정해진 횟수만큼 다시 보내면, 환경의 딸꾹질이 에이전트의 판단 실수로 둔갑하는 일이 줄어듭니다. 같은 요청을 여러 번 보내도 결과가 두 번 처리되지 않게 만드는 멱등 처리도 같은 역할을 합니다. 결제나 예약처럼 두 번 누르면 사고가 나는 곳에서는 이 장치가 곧 안전장치죠.

반면 도구를 감싼다고 해서 모든 흔들림이 사라지는 건 아닙니다. 웹 화면이 통째로 바뀌거나, 외부 서비스가 멈추면 감싸는 쪽에서도 손을 쓸 수 없는데요. 그래서 도구 래퍼는 만능 해결책이 아니라 바닥을 고르는 작업에 가깝습니다. 바닥이 평평해지면 그 위에서 벌어지는 계획의 흔들림이 더 또렷하게 보입니다. 저는 그래서 이 순서를 권하고 싶습니다. 모델을 키우기 전에 도구의 응답을 먼저 묶어두는 것이죠. 비용도 적게 들고, 효과도 바로 눈에 들어옵니다.

스스로 점검하고 되돌아가는 구조는 뭐가 다를까

도구 바닥을 다졌는데도 실행이 흔들린다면, 다음은 에이전트 안쪽의 구조를 볼 차례입니다. 한 번 달려서 끝까지 가는 구조와, 중간에 멈춰서 점검하고 되돌아가는 구조는 반복 성공에서 큰 차이를 보이는데요. 후자의 대표 주자가 검증 에이전트와 스스로 되짚는 고리, 그리고 중간 저장 지점입니다. 일종의 교차 검토처럼요. 쓴 초안을 다른 눈으로 다시 읽고, 어긋난 부분을 표시한 뒤, 고칠 수 있는 지점으로 되돌아가는 흐름입니다.

예를 들어 경비 정산 에이전트를 생각해 보죠. 영수증을 읽고, 항목을 분류하고, 합계를 내는 일을 한 번에 끝내면 중간 실수가 그대로 보고서에 남습니다. 그런데 항목 분류가 끝난 지점에서 검증자가 한 번 훑어보면 이야기가 달라지는데요. 날짜를 잘못 읽은 항목을 그 자리에서 잡아내면, 뒤에 따라오는 합계와 제출 단계는 깨끗한 입력을 받습니다. 체크포인트는 이 되돌아가기를 가능하게 만드는 표시판입니다. 매 단계의 입력과 출력을 저장해두면, 실패가 발견됐을 때 처음부터 다시 시작하지 않고 마지막으로 올바랐던 지점으로 돌아갈 수 있죠.

다만 이 구조에도 대가가 있습니다. 검증자를 붙이면 매번 토큰과 시간이 더 들고, 되돌아가기가 잦으면 전체 지연이 늘어납니다. 그래서 무작정 모든 단계에 검증을 붙이는 건 현명하지 않은데요. 현장에서는 실패 비용이 큰 지점에만 골라 붙이는 편이 낫습니다. 결제 직전, 제출 직전, 삭제 직전 같은 되돌리기 어려운 곳이 그런 자리입니다. (참고로 검증자를 붙였다고 해서 계획 자체가 좋아지는 건 아닌데요. 앞 단계의 선택지가 전부 나쁘면, 검증자는 그중 덜 나쁜 것을 고를 뿐입니다.) 그럼에도 반복 성공의 관점에서 보면, 점검과 되돌아가기는 가장 확실한 안전망입니다. 한 번의 천재성보다 꾸준한 검토가 현장에서는 더 오래 갑니다.

리더보드 줄 세우기를 이제 바꿔야 할까

여기까지 오면 자연스럽게 다음 질문이 생깁니다. 그렇다면 벤치마크의 줄 세우기도 바꿔야 하지 않을까요. 지금 많은 리더보드는 한 번, 혹은 몇 번 중 가장 좋은 점수를 앞에 내세우는데요. 이 방식에서는 반복 성공이 낮은 에이전트도 운 좋은 한 번으로 윗자리를 차지할 수 있습니다. 연구실 점수는 예쁘게 나오지만, 현장에 가져오면 곧바로 흔들리는 이유가 여기에 있습니다. 점수를 매기는 규칙이 현장의 질문과 어긋나 있는 것이죠.

이 글에서 소개된 논쟁도 그 지점을 겨냥합니다. 주요 벤치마크가 일관성 보고를 의무화해야 하는지를 두고 의견이 갈린다는 것인데요. 찬성 쪽은 단순합니다. 평균과 흩어짐, 그리고 pass^k 같은 반복 지표를 함께 공개하면 요행이 가려진다고 봅니다. 반대 쪽의 걱정도 이해가 갑니다. 반복 실행은 비용이 들고, 작은 연구팀에는 부담이 되며, 무엇을 몇 번 돌려야 공정하다고 할지의 기준도 아직 없다는 것이죠. 어느 쪽이든 점수판이 바뀌면 연구의 방향도 바뀝니다. 운 좋은 한 번을 노리는 대신, 지루하게 반복되는 성공을 노리게 되니까요.

저는 여기서 조금 의심했습니다. 의무화가 능사일까요. 강제된 지표는 곧바로 최적화의 대상이 되고, 최적화된 지표는 다시 요행의 재료가 되기 때문입니다. 그럼에도 방향 자체는 옳다고 봅니다. 한 번의 점수 옆에 반복의 기록을 붙이는 것만으로도 읽는 눈이 달라지죠. 구매자와 운영자가 점수표를 볼 때 가장 좋은 한 줄이 아니라, 가장 꾸준한 한 줄을 찾게 됩니다. 리더보드가 가르치는 공부는 생각보다 큽니다. 무엇을 재는지가 무엇을 만드는지를 결정하니까요.

그래서 다음에 에이전트를 고를 때 물을 질문

이제 마무리를 위해 현장의 질문으로 돌아오죠. 다음에 에이전트를 고를 때 우리는 무엇을 물어야 할까요. 저는 spec 표의 성공률 옆에 작은 글씨로 적힌 조건부터 읽어보라고 권하고 싶습니다. 몇 번을 돌린 평균인지, 흩어짐은 얼마인지, 도구가 흔들리는 시간대에도 같은 조건이었는지를 묻는 것이죠. 판매자가 가장 좋아하는 숫자는 대개 가장 잘 나온 한 번입니다. 사야 하는 쪽은 그 옆에 가려진 보통의 날들을 물어야 합니다.

도입 과정에서도 같은 태도가 필요합니다. 파일럿을 한 번 돌리고 통과 도장을 찍는 대신, 같은 시나리오를 여러 번, 다른 시간대에, 조금씩 바뀐 입력으로 돌려보는 것이죠. 아침에 돌린 예약 흐름을 밤에도 돌려보고, 화면이 바뀐 날에도 돌려보고, API가 느려지는 시간에도 돌려봅니다. 그 과정에서 실패의 첫 갈림길이 어디인지 기록해두면, 도입 후에 터질 장애를 미리 사두는 셈이 됩니다. 운영 측면에서 보면 이 기록은 상당히 값집니다. 밤사이 외부 서비스가 느려지거나 아침에 특정 화면이 바뀌어도, 어디서 되돌아가야 할지 알 수 있기 때문입니다.

그렇다면 사람의 역할은 무엇일까요. 저는 에이전트의 한 번을 믿고 맡기는 대신, 반복을 설계하는 일이 남는다고 봅니다. 무엇을 몇 번 물을지, 어디에 검증을 붙일지, 어디까지 되돌아갈지를 정하는 일이죠. 에이전트가 과제를 통과했다는 소식은 이제 시작점처럼 느껴집니다. 진짜 질문은 그다음에 오니까요. 다시 시키면 어떨까, 바쁜 아침에도 그럴까, 도구가 흔들려도 그럴까. 그 질문들에 답할 수 있을 때, 비로소 데모 속 성공이 운영 속 실력이 됩니다.