Agentic Code Reasoning: 판단에 근거를 붙이기

코딩 에이전트의 패치를 검토하는 개발자에게 “두 수정은 같은 결과를 냅니다”라는 답만으로는 부족하다. 테스트를 실행하기 어려운 상황에서 그 판단을 얼마나 믿을 수 있으며 어떤 근거를 요구해야 할까? Agentic Code Reasoning은 코드 위치와 호출 경로를 기록하는 검증 형식이 판단 정확도를 높이는 조건과 그 비용을 보여 준다.

Shubham Ugare와 Satish Chandra의 Agentic Code Reasoning, 2026년 arXiv v2를 기준으로 읽는다. 아래 실험 수치는 저자 보고이며 이 글에서 해당 벤치마크를 재현한 결과는 아니다. Agentic Code Reasoning 원문

같은 식처럼 보여도 다른 함수를 부른다

다음은 이름을 보고 동작을 짐작하는 위험을 설명하려고 만든 독립 가상 예제다. 목록 [4, 5]의 합이 9인지 확인하는 테스트가 있고 한 패치는 sum(values)를, 다른 패치는 builtins.sum(values)를 쓴다고 하자.

import builtins

# 같은 모듈에 이미 있는 청구서용 함수
def sum(invoice):
    return invoice.total

# 패치 A
def total_a(values):
    return sum(values)

# 패치 B
def total_b(values):
    return builtins.sum(values)

두 호출을 문자열로만 비교하면 같은 합계 계산처럼 보인다. 하지만 이 모듈의 sum은 목록을 더하는 내장 함수가 아니다. 첫 패치는 목록의 total 속성을 읽으려다가 AttributeError를 일으키고 두 번째는 9를 반환한다. 함수 이름을 아는 것과 그 이름이 이 위치에서 가리키는 정의를 확인하는 것은 다른 작업이다.

논문의 실제 사례에서도 같은 문제가 나온다. 연도의 마지막 두 자리를 만드는 패치가 format을 호출하는데 해당 모듈에는 Python 내장 함수와 이름이 같은 자체 format이 있다. 숫자에 내장 포맷을 적용한다고 가정한 판단은 틀렸고 정의와 호출 경로를 확인한 판단은 예외가 발생한다는 차이를 찾았다. 원문의 패치 비교 사례

증명서 형식은 무엇을 요구하나

저자들이 사용하는 준형식 검증 기록(semi-formal certificate)은 자연어 설명에 구조를 부여한다. 먼저 두 패치가 각각 무엇을 바꾸는지 적고 관련 테스트가 요구하는 동작을 명시한다. 이후 테스트별로 각 패치의 호출 경로를 따라 예상 통과·실패를 설명하고 다른 결과를 낸다면 구체적인 반례 테스트를 제시한다.

가상 예제를 그 구조로 줄이면 다음과 같다. 원문 Figure 2의 절차를 적용한 자체 설명 표이며 원문 검증 기록을 그대로 옮긴 것은 아니다.

이 과정은 답변의 모양만 길게 만드는 작업이 아니다. “어느 정의가 호출되는가”라는 빈칸을 채우려면 실제 파일을 찾아 읽어야 한다. 검증 형식이 탐색을 유도한다. 다만 Lean이나 Coq가 검사한 정식 증명은 아니며 기록에 붙은 근거와 추론 자체가 틀릴 수 있다. 검증 기록 형식

여기서 테스트 기준 패치 동등성(patch equivalence modulo tests)은 두 패치에 저장소의 지정된 테스트를 적용했을 때 통과·실패 결과가 같은지를 뜻한다. 버그를 고쳤는지 확인하는 F2P 테스트와 기존 동작을 보존하는 P2P 회귀 테스트가 기준이다. 모든 가능한 입력에서 프로그램이 같은지는 이 정의로 주장하지 않는다. 둘 다 같은 테스트를 실패해도 이 정의로는 동등할 수 있고 테스트가 살펴보지 않는 입력에서 두 구현이 달라도 판정에 드러나지 않는다.

정확도를 얻는 대신 탐색이 늘었다

저자들은 SWE-bench-Verified의 에이전트 패치 중 겉으로 비슷하지만 결과가 다른 쌍 등을 선별해 170쌍을 만들었다. 검증 모델은 Opus-4.5다. 두 패치, 적용된 테스트 패치, 전체 저장소를 읽을 수 있지만 테스트를 실행할 수는 없다. 정답은 실제 실행 결과로 정한다.

아래는 v2 Table 2의 수치를 한국어로 다시 구성한 표다. 분모는 전체 170쌍이며 정확도는 최종 이진 판정의 정답 비율이다. 평균 단계 수는 저자가 보고한 에이전트 탐색 단계 수로, 시간이나 토큰 비용 자체는 아니다.

저자 보고, 원문 Table 2의 일부 열만 재구성. 결과 표

정확도 차이는 10.6%p이고 단계 수는 약 2.8배다. 이 계산만으로 지연이나 비용도 정확히 2.8배라고 할 수는 없다. 준형식 판단에서도 19건은 오답이었다. 저자들은 비동등한 패치의 실행 차이를 놓치는 경우를 주요 원인으로 설명한다. 그럴듯한 기록이 완전한 경로 추적을 보장하지는 않는다.

원 표의 판정 종류별 정확도를 보면 개선이 균일하지도 않다. 비동등한 쌍에서는 78.6%에서 82.9%로, 동등한 쌍에서는 78.0%에서 93.0%로 오른다. 위험한 수정이 동등하다고 승인되는 경우를 줄이는 데 관심이 있다면 전체 88.8%보다 첫 비교를 먼저 봐야 한다. 정답 패치와 비교하는 검증에서도 잘못된 패치를 승인하는 오류와 좋은 패치를 거부하는 오류의 비용은 다르다. 이 평가 집합의 전체 정확도만으로 실제 승인 결과의 신뢰도를 구할 수는 없다. 패치 동등성 판정 결과

별도의 무작위 평가에서는 live-swe-agent가 생성한 패치와 기준 정답 패치를 비교했다. 올바른 패치 100개와 잘못된 패치 100개, 총 200개이며 테스트 코드와 저장소를 제공한다. 이 조건의 결과를 앞의 170쌍 수치와 섞으면 안 된다.

저자 보고, 원문 Table 3의 Opus-4.5 행만 재구성. 별도 검증 평가

파일을 더 주거나 도구로 더 탐색한다고 항상 나아지는 것은 아니다. 이 표에서는 일반 탐색이 파일 문맥을 제공한 단일 호출보다 낮다. 준형식 탐색의 개선은 “도구가 있으니 정확하다”보다, 어떤 행동 근거를 요구하며 탐색하게 했는가라는 질문을 뒷받침한다.

형식이 탐색을 바꿨다는 주장과 형식만의 효과는 다르다

이 연구에서 설득력 있는 부분은 근거를 기록하도록 요구한 프롬프트가 실제 탐색 행동과 최종 판정을 함께 바꿨다는 것이다. 이름 가림 사례에서 호출 정의를 읽는 행동이 오판의 전제를 없앴다. 다만 일반 판단은 평균적으로 더 일찍 멈췄다. 두 구성의 최대 단계 수를 같게 둬도 실제로 사용한 탐색량은 같지 않으므로 결과를 검증 기록의 서식만으로 생긴 효과라고 분해할 수는 없다. 비슷한 탐색 예산을 쓰게 한 일반 판단이나, 결론 전에 호출 대상만 확인하도록 요구한 단순한 지시와 비교하면 구조의 어느 부분이 필요한지 더 알 수 있을 것이다. 이 비교는 리뷰자의 제안이다.

원문은 검증 기록이 빠뜨린 경우나 근거 없는 주장을 막는다는 강한 표현을 쓴다. 그러나 남은 오류 분석에는 지시를 받고도 경로를 끝까지 추적하지 않은 경우가 있다. 따라서 기록은 확인해야 할 항목을 드러내는 절차로 평가하는 것이 맞고 항목을 채웠다는 이유로 완전성을 보증하는 증명서로 받아들이기는 어렵다. 개선된 최종 정확도와 중간 주장 전체의 타당성은 별도의 평가 대상이다. 오류 분석

특히 검증 모델을 강화학습의 보상으로 쓰겠다는 응용은 한 단계 더 검토해야 한다. 검증 정확도를 측정한 실험은 있지만 이 보상으로 학습한 코딩 정책이 실제 실행 검증을 얼마나 잘 통과하는지 보여 준 결과는 아니다. 정책이 검증자의 반복적인 오판에 맞춰질 가능성도 있으므로 실행을 줄이는 비용 이득과 보상 오류가 학습에 미치는 영향을 함께 평가해야 한다.

긴 기록도 잘못된 확신을 만들 수 있다

이 논문의 결과를 모든 코드 이해 작업에 같은 효과로 옮기기는 어렵다. 별도의 결함 위치 평가에서는 Defects4J 100개 표본 중 평가 가능한 90개를 사용했다. 상위 다섯 예측이 수정 영역을 모두 포함해야 성공으로 보는 엄격한 지표에서, Opus-4.5는 43.3%에서 47.8%로 개선됐다. 그러나 Sonnet-4.5는 31.1%에서 30.0%로 낮아졌다. 모델과 과제에 따라 효과가 다르다.

저자 보고, 원문 Table 5의 Top-5(All) 열만 재구성. 실패 테스트 이름·코드와 저장소를 제공하고 스택 트레이스나 오류 메시지는 제공하지 않는 결함 위치 추정 과제다. 결함 위치 평가

RubberDuckBench의 15개 코드 질문 평가에서는 두 LLM이 전문가 기준표에 따라 답변을 채점한다. 테스트 실행의 이진 정답을 쓰는 대신 이 기준표를 적용한다. 이를 패치 평가의 정답 비율과 같은 지표로 읽으면 안 된다. 원문 부록의 한 사례에서는 여러 함수를 꼼꼼히 추적하고도 불필요한 검사를 필요하다고 답했다. 하위 생성자가 이미 빈 경로를 처리한다는 사실을 놓쳤다. 조사량이 늘어도 마지막 연결 고리를 빠뜨릴 수 있다. 코드 질문의 성공과 실패 사례

또한 패치 평가에서는 기준 패치와 테스트 코드가 주어진다. 실제 리뷰에서 정답 패치가 없거나 테스트가 부족한 상황은 다른 문제다. 기록의 최종 결론만 채점했으므로 정답으로 끝난 기록의 모든 중간 주장이 정확했다고 확인한 결과도 아니다.

리뷰에서 남길 근거를 바꿔 보기

이 연구를 실무에 적용한다면 “더 자세히 설명하라”는 요청부터 늘릴 필요는 없다. 가상 합계 예제처럼 호출 대상의 정의, 테스트의 단언, 두 경로가 갈라지는 지점을 요구하면 된다. 해당 근거를 찾지 못했을 때는 동등하다는 결론을 보류한다. 이는 논문에서 읽어 낸 적용 판단이며 검증된 제품 성과는 아니다.

테스트를 실행할 수 있는 환경에서는 그 실행을 없앨 이유가 없다. 검증 기록은 무엇을 실행하고 어느 차이를 살펴볼지 정리하는 데 쓰고 실제 테스트 결과와 함께 남기는 편이 이 연구의 오류 사례에도 대응한다. 검토 가능한 설명은 도움이 되지만 그 설명이 확인한 범위까지가 근거다.

원문

Shubham Ugare, Satish Chandra. Agentic Code Reasoning. arXiv:2603.01896, v2, 2026. 고정 판본 원문.