통과만 보지 않고 과정을 읽는 법

오늘 다룰 논문은 Beyond Binary Verifiable Rewards: Behavioral Self-Rewarding for SWE Agents로, arXiv 번호 2610.12598로 공개된 연구입니다. 이 연구가 내세우는 주장은 하나로 정리되는데, 실행 가능한 테스트라는 믿을 만한 판정이 있어도 통과와 실패라는 두 칸짜리 보상만으로는 디버깅 과정의 잘잘못을 가르치기 어렵기 때문에 현재 정책을 심사위원으로 재사용해 같은 결과 안에서 과정의 차이를 가려내는 보조 보상을 얹자고 제안합니다. 원문 논문으로 이어지는 링크는 제목 아래에 붙어 있습니다.

처음 이 제목을 봤을 때 저는 통과 여부를 가르는 테스트가 있는데 무엇이 더 필요할까 싶었습니다. 소프트웨어 공학 에이전트에게 실행 가능한 테스트는 정말 든든한 감독 신호처럼 보이니까요. 그런데 논문을 따라가다 보니 질문이 바뀌었습니다. 통과했다는 도장이 두 과정의 차이를 지워버린다면, 그 지워진 차이에서 배우는 법을 따로 만들어야 하지 않을까요.

통과했다는 도장이 전부를 말해주지 않는 이유

함께 일하는 동료가 버그를 고쳤다고 해보죠. 한 사람은 로그를 좁혀가며 원인을 찾고 작은 패치로 테스트를 통과시키고, 다른 한 사람은 되는 대로 파일을 건드리다가 우연히 테스트를 통과시켰습니다. 결과표에는 둘 다 통과라고 적히지만, 다음에 비슷한 일을 맡기고 싶은 사람은 분명히 갈립니다. 그렇다면 에이전트 학습에서도 같은 일이 벌어지지 않을까요.

강화학습에서 검증 가능한 보상을 쓰는 방식은 이런 면에서 출발했습니다. 실행 가능한 테스트가 통과했는지 실패했는지를 직접 쓰기 때문에 사람의 손을 탄 점수보다 훨씬 믿을 만한데요. 테스트가 말해주니까 논쟁의 여지가 적습니다. 저희가 새로운 AI 아키텍처를 볼 때도 이런 명확한 감독 신호가 있으면 일단 안심이 되죠. 무엇이 맞았는지를 기계가 직접 확인해주니까요.

문제는 그다음입니다. 통과와 실패라는 두 칸짜리 보상은 같은 칸에 들어간 기록들을 전부 똑같이 취급합니다. 깔끔하게 원인을 좁혀간 궤적도 1점, 우왕좌왕하다 운 좋게 걸린 궤적도 1점인 셈이죠. 실패 쪽도 마찬가지라서, 거의 다 와서 막힌 시도와 처음부터 방향이 어긋난 시도가 같은 0점을 받습니다. 이렇게 되면 학습 신호는 듬성듬성해지고, 에이전트는 어떻게 고쳤는지가 아니라 고쳤는지 여부만으로 평가받습니다.

생각해보면 사람도 비슷하게 배웁니다. 시험 점수만 보는 선생님보다 풀이 과정을 보고 어디서 돌아왔는지를 짚어주는 선생님에게서 더 많이 배우죠. 이 논문이 파고드는 지점이 바로 여기입니다. 테스트라는 든든한 채점은 그대로 두되, 그 채점이 가려버린 과정의 차이를 어떻게 살려낼지를 묻습니다.

같은 통과인데 왜 어떤 과정은 더 배울 만할까

디버깅이라는 말을 풀어보면 관찰 가능한 행동의 연속입니다. 어떤 파일을 먼저 열었는지, 로그의 어느 줄에서 가설을 세웠는지, 재현 스크립트를 만들었는지, 패치를 얼마나 좁게 유지했는지, 실패한 테스트를 다시 돌려 확인했는지 같은 장면들이죠. 저는 이 논문에서 가장 흥미롭게 본 부분이 바로 이 시선을 어디에 두었는지였습니다. 최종 패치가 아니라 그 패치에 이르는 발걸음에 점수를 주자고 말하니까요.

같은 통과 판정을 받은 두 궤적을 놓고 보면 차이가 금방 드러납니다. 하나는 이슈를 재현하고 관련 코드를 좁혀가며 가설을 검증하고, 다른 하나는 넓게 파일을 뒤적이다가 테스트가 우연히 녹색으로 바뀌는 데서 멈춥니다. 겉으로는 둘 다 성공이지만, 다음 과제로 옮겨갈 때 힘이 되는 쪽은 분명합니다. 그런데 이분법 보상은 이 둘에게 같은 숫자를 줍니다. 그래서 에이전트는 헤맸던 습관을 버릴 이유를 보상에서 찾지 못합니다.

여기서 재미있는 질문이 생깁니다. 과정의 좋고 나쁨을 누가 판단할 수 있을까요. 사람을 불러 매 궤적마다 손으로 점수를 매기면 정확하겠지만 비용이 감당되지 않고, 별도의 보상 모델을 학습시키면 그 모델을 만들고 유지하는 일이 또 하나의 큰 과제가 됩니다. 그렇다면 이미 궤적을 만들 줄 아는 현재 정책이 스스로 비교자 역할을 할 수는 없을까요. 이 논문은 그 가능성을 정면으로 시험합니다.

자기 자신을 심사위원으로 앉히면 무슨 일이 생길까

제안된 방법은 이름 그대로 Behavioral Self-Rewarding, 줄여서 BSR입니다. 현재 정책을 그대로 심사위원으로 재사용해서 디버깅 행동을 비교하는데요. 바깥에서 새로운 보상 모델을 데려오지 않는다는 점이 무엇보다 새롭습니다. 이미 학습 중인 정책이 궤적을 읽고 어느 쪽의 과정이 더 나았는지를 가려내는 것이죠.

이 발상이 처음에는 순환논증처럼 들릴 수도 있습니다. 아직 배우는 중인 모델이 자기를 평가하면 점수가 엉망이 되지 않을까요. 저도 여기서 잠깐 멈칫했습니다. 그런데 논문의 설정은 절대 점수를 매기는 일이 아니라 비교를 시키는 일이라서 결이 다릅니다. 잘했는지 100점 만점으로 매기라는 게 아니라, 같은 과제에서 같은 판정을 받은 두 기록을 놓고 어느 쪽의 디버깅이 더 나았는지를 고르라는 주문이죠. 비교는 채점보다 훨씬 쉬운 일이고, 모델이 이미 가진 읽기 능력이 바로 쓰이는 자리입니다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 이런 자기 평가를 믿고 보상으로 써도 학습이 어긋나지 않을까요. 논문의 답은 비교 범위를 좁히는 데 있습니다. 아무 궤적끼리나 붙이는 게 아니라 같은 과제에서 나왔고 검증자의 판정까지 같은 것끼리만 묶어서 비교합니다. 과제의 난이도나 운 같은 변수를 바깥으로 밀어낸 뒤에 남는 과정의 차이만 보겠다는 것이죠. 그래서 심사위원이 서툴러도 방향이 크게 빗나갈 여지가 줄어듭니다.

같은 출발선에 선 기록끼리만 비교하는 이유

같은 과제, 같은 판정이라는 조건은 생각보다 중요합니다. 과제가 다르면 비교가 난이도 비교로 오염되고, 판정이 다르면 통과냐 실패냐라는 원래 신호가 묻히기 때문입니다. BSR은 검증자가 매긴 통과와 실패라는 큰 틀을 그대로 두고, 그 틀 안에서만 우열을 가립니다. 통과한 것끼리 모아놓고 누가 더 단단하게 통과했는지를 묻고, 실패한 것끼리 모아놓고 누가 더 멀리 갔는지를 묻는 식이죠.

이 방식은 학습 신호의 결을 바꿉니다. 기존에는 통과한 궤적이 전부 같은 보상을 받아서 서로 가르칠 것이 없었는데, 이제는 통과한 무리 안에서도 줄이 섭니다. 실패한 무리 안에서도 줄이 서고요. 줄이 선다는 것은 기울기가 생긴다는 뜻이라서, 정책은 어느 쪽으로 한 걸음 옮겨야 하는지를 매번 조금씩 듣게 됩니다. 테스트가 알려주지 않던 디버깅 습관의 차이가 숫자로 번역되는 셈입니다.

여기서 쌍별 비교라는 장치가 등장합니다. 두 궤적을 짝지어 어느 쪽이 나았는지를 반복해서 묻고, 그 승패를 과제 안에서 모아 점수로 만듭니다. 한 번의 판단이 아니라 여러 번의 비교가 쌓여 순위가 되는 구조라서, 한두 번의 엇갈린 판단이 전체를 뒤집기 어렵습니다. 여러 사람의 의견을 모아 순위를 정하는 일과 비슷한데요. 개인의 실수가 섞여도 전체 그림은 어느 정도 자리를 잡습니다.

이긴 기록과 진 기록의 순서를 흐트러뜨리지 않는 법

보조 보상을 얹을 때 가장 조심해야 할 일은 원래 채점을 해치지 않는 것입니다. 아무리 과정이 좋아도 실패한 궤적이 통과한 궤적보다 높은 보상을 받으면 테스트라는 기준이 흔들리니까요. 논문은 이 선을 분명히 긋습니다. 보조 보상은 폭이 제한된 형태로 들어가서 통과와 실패의 순서를 뒤집지 않습니다.

이 차이는 생각보다 중요합니다. 검증자가 정한 통과와 실패의 위계는 그대로 두고, 그 안에서만 보상의 높낮이를 만든다는 뜻이기 때문입니다. 통과한 궤적은 실패한 어떤 궤적보다 여전히 높은 보상을 받고, 실패한 궤적끼리의 비교는 실패라는 범위 안에서만 움직입니다. 테스트의 권위는 지키면서 과정의 정보를 얹는 것이죠. 그래서 BSR은 테스트를 대체하는 점수가 아니라 테스트를 다듬는 점수에 가깝습니다.

저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 보상을 크게 주는 일이 목표가 아니라 보상에 대비를 만드는 일이 목표이기 때문입니다. 같은 점수표 안에서 줄을 세우면 정책은 어느 행동이 조금 더 나았는지를 매번 배우고, 그 작은 차이가 쌓여 디버깅 습관을 바꿉니다. 마치 시험 점수는 그대로 두되 풀이 과정에 별점을 덧붙여주는 일과 같습니다. 합격선은 그대로인데 공부하는 방법이 달라지죠.

새로 실행하지 않고도 가르침을 늘리는 셈법

에이전트 학습에서 가장 비싼 자원은 환경과의 상호작용입니다. 코드를 돌리고 테스트를 실행하고 도구를 호출하는 매 걸음이 시간과 계산을 먹으니까요. 그런데 BSR은 이미 모아둔 궤적에서 추가 감독 신호를 뽑아냅니다. 새로운 실행 없이 이미 수집된 기록을 다시 읽고 비교해서 보상을 다듬는 것이죠.

이 대목에서 예산을 어디에 쓸지 고르는 이야기가 됩니다. 보통 보상을 더 촘촘하게 만들려면 환경을 더 돌려야 해서 비용이 따라오는데, 여기서는 읽기만으로 신호를 늘립니다. 정책이 이미 궤적을 판단할 만큼 읽는 능력이 있다는 전제 위에서, 그 능력을 보상 쪽으로 돌려쓰는 셈입니다. 실행 비용은 그대로 두고 학습 신호의 밀도만 올리는 교환이라서 운영 관점에서도 눈에 들어옵니다.

물론 공짜 점심은 없습니다. 비교와 집계에도 계산이 들고, 정책이 서툰 시기에는 비교의 질도 흔들릴 수 있습니다. 그럼에도 방향은 분명합니다. 버려질 뻔했던 같은 점수표 안의 기록들에서 대비를 뽑아내니, 같은 실행 예산으로 더 많은 가르침을 얻는 구조가 되니까요. 저는 그래서 이 부분을 연구실 점수 이상으로 평가했습니다. 밤새 에이전트를 돌리는 팀에게 실행 한 번을 아끼는 장치는 곧바로 예산과 직결되기 때문입니다.

작은 모델과 큰 모델에서 같이 통했을까

논문은 Qwen3의 14B와 32B 구성을 SWE-bench Verified와 SWE-bench-Live에서 평가했는데요. 두 크기에서 일관된 개선이 보고됐습니다. 작은 구성에서만 통하는 요령이 아니었고, 큰 구성에서도 같은 방향의 이득이 이어졌다는 점이 눈에 띕니다.

모델 크기를 가로지르는 결과는 해석할 때 조심해야 합니다. 큰 모델이 원래 잘해서 오른 것인지, 보조 보상이 얹은 과정 신호 덕분인지를 가려야 하니까요. 그런데 두 구성에서 함께 개선이 나타났다는 보고는 과정 비교라는 신호가 특정 크기에서만 먹는 우연이 아니라는 쪽에 힘을 싣습니다. 14B가 배우는 디버깅 습관과 32B가 배우는 디버깅 습관이 서로 다르겠지만, 같은 판정 안에서 과정을 가려내는 일 자체는 두 크기 모두에게 남는 숙제이기 때문입니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 공개된 요약만으로는 개선의 폭이나 조건별 편차를 따질 수 없습니다. 어떤 과제군에서 더 올랐는지, 실패 궤적 안의 비교가 더 먹혔는지 통과 궤적 안의 비교가 더 먹혔는지 같은 이야기는 원문의 실험 표를 직접 봐야 합니다. 그럼에도 일관된 방향이라는 보고는 가볍지 않습니다. 테스트만으로는 가르치기 어려운 부분을 스스로의 비교로 메운다는 발상이 크기를 가리지 않고 동작했다는 뜻이니까요.

스스로 매긴 점수를 믿어도 되는 걸까

자기 평가라는 말이 들어가면 으레 따라오는 의심이 있습니다. 스스로를 심사하면 좋은 점만 주려는 편향이 생기지 않을까요. 이 의심은 정당해서, 논문의 설계가 그 의심을 어디까지 덜어주는지를 따져봐야 합니다.

제가 보기에 이 설계가 기대는 버팀목은 세 가지입니다. 첫째, 절대 점수가 아니라 쌍별 비교라서 후하게 주기와 같은 일괄 편향이 순위를 바꾸기 어렵습니다. 둘째, 비교 상대가 같은 과제에서 같은 판정을 받은 기록으로 묶여 있어서 과제 난이도나 결과의 후광이 끼어들 자리가 좁습니다. 셋째, 보조 보상의 폭이 제한되고 통과와 실패의 순서가 보존돼서 설령 비교가 흔들려도 원래 채점이 무너지지 않습니다. 편향이 0이 되지는 않지만, 피해가 학습 전체로 번지는 길을 미리 좁혀둔 것이죠.

그렇다면 반대쪽 질문도 남습니다. 정책이 아직 서툴 때 내린 비교가 정말 더 나은 디버깅을 가리킬까요. 초기에는 비교의 질도 거칠 수밖에 없는데, 그 거친 신호로 학습하면 방향이 틀어지지 않을까요. 이 대목은 원문의 절제된 표현을 그대로 받아들일 필요가 있습니다. 연구가 말하는 바는 자기 비교가 별도의 보상 모델 없이도 쓸 만한 보완 신호가 된다는 정도이고, 테스트를 대체하는 심판이 생겼다는 뜻이 아닙니다. 테스트라는 기준이 있어서 자기 평가의 실수가 큰 사고로 번지지 않는 구조라는 점을 함께 읽어야 합니다.

한 줄 요약이 놓치는 부분은 어디일까요

이 연구를 한 줄로 줄이면 스스로 점수를 매겨 보상을 촘촘하게 만들었다는 말이 됩니다. 틀린 말은 아닌데, 이 요약만 들고 가면 놓치는 것이 있습니다. 무엇이 비교되고 무엇이 보존되는지를 빼먹기 때문입니다.

비교의 대상은 결과가 아니라 행동입니다. 패치의 모양이 아니라 디버깅의 발걸음이 비교되고, 그 비교는 같은 과제와 같은 판정이라는 울타리 안에서만 일어납니다. 그리고 보상의 모양은 대비를 얹되 순서를 지키는 형태라서, 검증자가 정한 통과와 실패의 위계는 그대로 남습니다. 이미 모은 기록을 재사용한다는 점도 요약에서 자주 떨어져 나가는데, 실행 예산을 늘리지 않고 신호를 늘렸다는 대목은 실제 운영에서 꽤 크게 다가옵니다. 한 줄 요약은 이 조건들을 지우고 결과만 남기는데, 정작 이 연구의 몸통은 그 조건들에 있습니다.

무엇을 달리해야 할지 보여주는 보상

기존 보상과 BSR 쪽 보상을 나란히 놓고 보면 학습 풍경이 달라집니다. 기존에는 통과한 궤적이 모두 같은 높이에 서 있어서 정책이 어디로 움직여야 할지를 보상에서 듣기 어려웠습니다. 실패한 궤적도 마찬가지라서, 다음에는 무엇을 달리해야 할지가 가려졌죠. BSR 쪽에서는 같은 높이에 섰던 기록들 사이에 미세한 높낮이가 생깁니다. 재현을 만들고 가설을 좁혀간 쪽이 조금 더 높고, 넓게 헤맨 쪽이 조금 더 낮습니다. 그 미세한 기울기가 매 학습 걸음마다 방향을 알려줍니다.

이 기울기가 가르치는 것은 요령이 아니라 습관에 가깝습니다. 로그를 먼저 좁히는지, 관련 없는 파일을 덜 건드리는지, 실패한 테스트를 다시 확인하는지 같은 반복되는 선택들이 보상에 스미니까요. 한 과제에서 통하는 잔기술이 아니라 다음 과제에서도 통하는 일하는 방식이 쌓이는 것이죠. 에이전트 학습이 테스트 통과라는 사건을 넘어 디버깅이라는 과정을 배우는 쪽으로 이동하는 셈입니다.

좋은데, 이걸 실제 파이프라인에 올리면 무엇이 달라질까요. 보상을 계산하는 단계에 비교와 집계라는 읽기 작업이 들어오니 학습 파이프라인의 모양이 조금 바뀝니다. 실행 단계와 학습 단계 사이에 기록을 다시 읽는 과정이 끼는 것이죠. 계산이 완전히 공짜는 아니지만 환경을 더 돌리는 비용과 견주면 성격이 다릅니다. 읽기 작업은 배치로 모아서 처리하기 쉽고, 실패한 실행처럼 날리는 비용이 아니기 때문입니다.

다음에 제가 보고 싶은 장면은 이것입니다

남는 질문도 분명합니다. 자기 비교가 가르치는 디버깅 습관이 과제군을 넘어 얼마나 이어질까요. 어떤 종류의 과제에서는 통하는 과정 신호가 다른 종류에서는 잡음이 될 수도 있습니다. 비교를 맡는 정책의 읽기 능력이 커질수록 비교의 질이 어떻게 달라지는지도 궁금합니다. 14B와 32B에서의 일관된 개선이 보고됐지만, 그 곡선이 더 작은 크기나 다른 계열에서도 이어지는지는 따로 확인해야 할 일입니다.

저는 앞으로 비교의 실패 사례를 보고 싶습니다. 어떤 쌍에서 정책이 엇갈렸고, 그 엇갈림이 어떤 과제에서 잦았는지를 알면 이 보조 신호의 경계가 드러나니까요. 보조 보상의 폭을 어떻게 정했는지에 따른 움직임도 궁금합니다. 폭을 넓히면 대비는 커지겠지만 원래 채점이 흔들릴 위험도 커질 텐데, 그 균형점이 어디에 있는지를 알면 실제 파이프라인에서 쓸 때 감이 잡힙니다.

통과 너머의 과정을 배우는 일

처음으로 돌아가 보죠. 테스트는 여전히 든든한 감독 신호입니다. 통과했는지 실패했는지를 기계가 직접 말해주니까요. 그렇다면 남은 일은 그 판정이 가린 차이를 살려내는 일입니다. 같은 통과 안에서도 어떤 과정이 다음에 힘이 되는지를 가려내고, 같은 실패 안에서도 어디까지 왔는지를 알아주는 일이죠. BSR은 그 일을 현재 정책의 읽기 능력으로 해보자고 말합니다.

이 논문이 흥미로운 이유는 새로운 심판을 데려오지 않았다는 데 있습니다. 이미 궤적을 만들 줄 아는 정책을 비교자로 돌려쓰고, 비교의 범위를 같은 과제와 같은 판정으로 묶고, 보상의 폭을 제한해 원래 순서를 지켰습니다. 실행을 늘리지 않고 기록을 다시 읽어 신호를 늘린 셈법도 운영 관점에서 눈에 들어옵니다. 무엇보다 배움의 대상이 사건에서 습관으로 이동했다는 점이 오래 남습니다.

그렇다면 사람의 역할은 무엇일까요. 테스트를 만드는 일, 비교가 엇갈리는 쌍을 들여다보고 기준을 다듬는 일, 보조 신호가 원래 채점을 해치지 않는지를 지키는 일은 여전히 사람의 몫으로 남습니다. 통과라는 도장 너머에 있는 과정을 읽어주는 일, 그 읽기를 보상으로 번역하는 일까지는 모델이 해낼 수 있겠지만, 무엇을 좋은 과정이라고 부를지에 대한 마지막 판단은 우리가 계속 들고 있어야 할 것 같습니다.