무엇인가 (What): Dockerless (arXiv 2606.28436) 논문은 코딩 에이전트(coding agent)의 코드 패치(code patch)가 올바른지 결정하는 방법이지만, 저장소(repository)의 테스트를 실행하지는 않습니다. "실행이 필요 없는(execution-free)" 판정관은 대신 저장소를 탐색하고 변경 사항에 대해 추론합니다.

왜 필요한가 (Why): 코딩 에이전트를 훈련하거나 평가하려면 생성된 각 패치가 실제로 문제를 해결하는지 알아야 합니다. 표준적인 확인 방식은 저장소별 Docker 컨테이너 내부에서 단위 테스트(unit tests)를 실행하는 것이며, 해당 컨테이너를 빌드하는 과정이 느리고 비용이 많이 드는 부분입니다. 이 과정은 모든 저장소에 대해 반복됩니다.

기존 방식과의 차이 (vs prior): 일반적인 접근 방식은 **실행 기반 검증(execution-based verification)**입니다. 즉, 저장소마다 Docker 이미지를 빌드하고 테스트를 실행합니다. Dockerless는 컨테이너를 없애고 **에이전트 기반의 증거 수집(agentic evidence-gathering)**을 통해 판단하므로, 환경 구축 없이도 동일한 신호를 SFT(Supervised Fine-Tuning)와 RL(Reinforcement Learning) 학습 모두에 사용할 수 있습니다.

비유하자면

CI(지속적 통합)를 실행하는 것이 아니라, 풀 리퀘스트(pull request)를 읽고 승인하는 시니어 리뷰어와 같습니다.

               A CODING AGENT'S PATCH
                        │
          ┌─────────────┴─────────────┐
...

• code patch = 정답/오답 판정을 기다리는 풀 리퀘스트(pull request)
• Docker에서 단위 테스트 실행 = 저장소를 빌드하고 전체 테스트 스위트(test suite)를 실행하기 위해 CI를 구동하는 것
• execution-free judge = 코드를 실행하는 대신 diff를 읽고 추론하는 시니어 리뷰어
• agentic repository exploration = 증거를 수집하기 위해 주변 파일들을 열어보는 리뷰어의 행동
• SFT와 RL을 위한 하나의 신호 = 읽고 판단하는 동일한 판정 결과가 학습 데이터를 선택하고 보상(reward) 점수를 매김

빠른 용어 정리

SWE-bench (Verified / Multilingual / Pro) — 에이전트가 문제를 해결하는 패치를 생성해야 하는 실제 GitHub 이슈들의 벤치마크(benchmark)입니다. _Verified_는 사람이 확인한 하위 집합이며, _Multilingual_과 _Pro_는 다른 분할 버전입니다. 점수는 해결률(resolve rate), 즉 패치가 실제로 해결한 이슈의 비율을 나타냅니다.

실행 기반 검증 (Execution-based verification) — 일반적으로 해당 저장소(repository)를 위해 빌드된 Docker 이미지 내부에서 저장소의 유닛 테스트 (unit tests)를 실제로 실행하여 패치를 확인하는 방식입니다. 정확하지만, 저장소별 환경 설정에 비용이 많이 든다는 단점이 있습니다.

실행 불필요 / 환경 불필요 (Execution-free / environment-free) — 코드를 읽고 추론함으로써 저장소를 빌드하거나 실행하지 않고 정답 여부를 판단하는 방식입니다. Dockerless의 핵심 아이디어는 컨테이너도, 테스트 실행도 필요 없다는 것입니다.

에이전트 기반 저장소 탐색 (Agentic repository exploration) — 판단자(judge)가 에이전트로서 동작하며 파일을 열고, grep을 수행하고, 주변 코드를 읽어 변경 사항이 올바른지에 대한 **증거를 수집 (gather evidence)**하도록 하는 방식입니다.

SFT (supervised fine-tuning, 지도 미세 조정) — 선별된 예시 **궤적 (trajectories)**을 통해 모델을 학습시키는 것입니다. 여기서 실행 불필요(execution-free) 판정은 학습할 가치가 있는 궤적이 어느 것인지를 선택하는 역할을 합니다.

RL 보상 (RL reward) — 강화학습 (RL)이 최적화하는 신호입니다. Dockerless는 실제 테스트 실행의 통과/실패 대신, 실행 불필요 방식의 정답/오답 (correct/not verdict) 판정을 보상으로 사용합니다.

궤적 (Trajectory) — 에이전트가 패치를 생성하기 위해 수행한 일련의 행동과 편집 과정입니다. **궤적 선택 (Trajectory selection)**은 올바른 패치로 이어진 궤적만을 남깁니다.

뉴스. 2026년 7월 1일, 연구진은 저장소별 컨테이너 없이 코딩 에이전트의 패치를 검증하는 방법인 Dockerless (arXiv 2606.28436)를 발표했습니다. 이 연구의 출발점은 기존의 표준적인 실행 기반 검증이 "Docker 이미지와 같은 저장소별 환경 내부에서 유닛 테스트를 실행해야 하므로 상당한 환경 설정 비용이 발생한다"는 점이었습니다. Dockerless는 이를 에이전트 방식으로 저장소를 탐색하고 정답 여부를 결정하기 위한 증거를 수집하는 **환경 불필요 판단자 (environment-free judge)**로 대체합니다. Dockerless는 SWE-bench Verified에서 62.0%의 해결률 (resolve rate) (Multilingual 50.0%, Pro 35.2%)을 달성하였으며, 이는 Qwen3.5-9B 베이스라인을 2.4 / 8.7 / 2.9 포인트 차이로 앞지르고 환경 기반 사후 학습 (environment-based post-training)과 대등한 수준입니다. 논문 읽기 →

여러분의 리뷰 큐(review queue)에 풀 리퀘스트(pull request)가 도착하는 상황을 상상해 보세요. 정석적인 승인 방식은 **CI를 실행(spin up CI)**하는 것입니다. 프로젝트 전체를 빌드하고 모든 유닛 테스트(unit test)를 실행하는 것이죠. 철저한 방식이지만, 각 저장소(repository)마다 고유한 빌드 환경이 필요하며, 그 환경을 구축하는 과정이 느리고 비용이 많이 드는 부분입니다. 시니어 리뷰어는 종종 완전히 다른 방식을 취합니다. 그들은 diff를 읽고, 주변 파일을 열어보며, 변경 사항이 코드에 어떻게 파급되는지 추적하고, 추론(reasoning)을 통해 승인합니다. CI를 전혀 실행하지 않고 말이죠.

두 번째 방식이 바로 Dockerless가 코딩 에이전트(coding agent)를 위해 수행하는 일입니다. 에이전트를 훈련하거나 평가하려면, 에이전트가 생성한 패치(patch)가 실제로 버그를 수정했는지 알아야 합니다. 표준적인 검증 방식은 저장소별 Docker 이미지 내부에서 해당 저장소의 유닛 테스트를 실행하여 통과 여부를 결정하는데, 저장소당 한 번씩 이 이미지를 빌드하는 과정에서 비용이 발생합니다. Dockerless는 컨테이너를 완전히 제거합니다. 실행이 필요 없는 판정관(execution-free judge)이 에이전트 방식(agentically)으로 저장소를 탐색하고, 변경 사항에 대한 증거를 수집하며, 테스트를 실행하는 대신 추론을 통해 정답 여부를 결정합니다.

이것이 Dockerless를 단순한 저비용 평가 도구 이상으로 만드는 핵심이자 전체 아이디어입니다. 동일한 실행 없는 판정(execution-free verdict)이 훈련에서도 이중 역할을 수행합니다. 지도 미세 조정(supervised fine-tuning)에서는 어떤 궤적(trajectories)이 학습할 가치가 있는지 선택합니다. 즉, 정답으로 판정된 것은 유지하고 나머지는 버립니다. 강화학습(reinforcement learning)에서는 이것이 곧 보상(reward)이 됩니다. 두 단계 모두 코드를 전혀 실행하지 않기 때문에, 전체 사후 훈련(post-training) 파이프라인이 **환경 독립적(environment-free)**이 됩니다. 평가를 위해서나 보상을 위해서나 저장소별 컨테이너가 어디에도 필요하지 않게 됩니다. 인프라를 구축해야 했던 오프라인 평가(offline eval)가 모델이 저장소를 읽는 과정으로 축소됩니다.

비용을 따져봅시다. 이 작업의 사후 학습(post-train) 대상인 베이스 모델인 Qwen3.5-9B는 고정한 채, _각 패치가 검증되는 방식_만 변경합니다. 예를 들어 패치 확인이 두 부분으로 나뉜다고 가정해 봅시다: 환경 구축 (standing up the environment) (해당 저장소를 위한 Docker 이미지 빌드)과 확인 실행 (running the check) (테스트 실행). 실행 기반(Execution-based) 방식은 이 두 가지 비용을 모두 지불하며, 그중 환경 구축이 지배적인 부분입니다 — (예시) 모든 저장소마다 반복되기 때문에 대략 **검증 비용의 80%**를 차지한다고 볼 수 있습니다. Dockerless는 읽고 추론하는 부분만 비용을 지불하므로, 이 환경세(environment tax)를 제거합니다. 그러면서도 **SWE-bench Verified에서 62.0%**를 달성했는데, 이는 동일한 Qwen3.5-9B 베이스보다 2.4포인트 높으며 컨테이너 기반 파이프라인과 동등한 수준입니다. 측정된 패턴은 다른 분할(splits)에서도 반복됩니다: 50.0% Multilingual (+8.7) 및 35.2% Pro (+2.9).

검증 방식	패치 확인 방법	저장소당 인프라	SWE-bench Verified 해결률
실행 기반 (Docker)	컨테이너 빌드, 저장소의 유닛 테스트 실행	저장소당 Docker 이미지 1개 + 테스트 실행	기준점 (동등함)
Dockerless (arXiv 2606.28436)	에이전트 기반 저장소 탐색 → 패치에 대해 추론, 실행 없음	없음	62.0% (+베이스 대비 +2.4; Multilingual / Pro에서 50.0% / 35.2%)

정확성이 실행이 아닌 읽기를 통해 결정되기 때문에, 학습 루프는 정확도를 포기하지 않으면서도 저장소 수에 따라 확장되던 단 하나의 구성 요소, 즉 저장소당 컨테이너를 제거할 수 있습니다. 핵심은 새로운 아키텍처나 더 높은 한계치가 아닙니다. 바로 코딩 에이전트가 학습하는 검증 신호가 반드시 실행된 테스트로부터 올 필요는 없다는 것, 즉 저장소를 탐색하고 추론할 수 있는 모델이 전체 환경을 대신할 수 있다는 것입니다.

더 자세한 내용: AI Agents → Evals & Diagnostics → Pass/Fail vs Score

관련 설명서

• The Verification Horizon — co-evolving verifiers — 코딩 에이전트를 검증하는 것이 왜 그 자체로 어려운 문제인지, 그리고 코더 (coder)와 함께 검증기 (verifier)를 학습시키는 방식으로 접근하는 이유
• MaxProof — defense-in-depth generative verifier — 단순히 실행만 하는 것이 아니라 정답 여부에 대해 추론하는 또 다른 검증기 (verifier)
• NatureBench — discovery vs reproduction — 코딩 에이전트가 실제의 어려운 소프트웨어 작업에서 어떻게 성과를 내는지에 대하여
• FutureSim — harness-level agent eval — 단일 답변이 아닌 전체 실행 과정을 통해 에이전트를 평가하는 방식

FAQ

실행 없는 패치 검증 (execution-free patch verification, Dockerless)이란 무엇인가요?

실행 없는 패치 검증 (execution-free patch verification)은 저장소의 테스트를 실행하지 않고도 코딩 에이전트의 코드 패치가 올바른지 결정하는 방식입니다. Dockerless (arXiv 2606.28436)는 프로젝트를 빌드하고 단위 테스트 (unit tests)를 실행하는 표준적인 저장소별 Docker 컨테이너를, 에이전트 방식으로 저장소를 탐색하고 변경 사항에 대한 증거를 수집하며 정답 여부를 추론하는 심판 (judge)으로 대체합니다. Dockerless는 저장소별 컨테이너를 완전히 제거하면서도 SWE-bench Verified에서 62.0%의 해결률 (resolve rate)을 달성했습니다.

왜 테스트를 실행하지 않고 코딩 에이전트의 패치를 검증하나요?

테스트를 실행하는 것은 정확하지만, 저장소별 환경 (일반적으로 Docker 이미지)을 빌드하고 실행해야 하며, 이 환경 설정 과정이 느리고 비용이 많이 드는 부분입니다. 또한 검증하려는 모든 패치에 대해 모든 저장소마다 이 과정을 반복해야 합니다. 실행 없는 심판 (execution-free judge)은 컨테이너를 건너뛰므로, 평가 및 보상 생성 (reward generation) 비용이 오직 읽기 및 추론 (read-and-reason) 단계에만 소요됩니다. Dockerless는 이러한 환경 독립적인 신호 (environment-free signal)가 정확도를 속도로 맞바꾸는 것이 아니라, 환경 기반의 사후 학습 (post-training)과 일치함을 보여줍니다.

Dockerless는 SWE-bench 및 RL 보상 생성 (reward generation)과 어떤 관련이 있나요?

SWE-bench는 에이전트가 패치(patch)를 통해 해결해야 하는 실제 GitHub 이슈들을 다루는 벤치마크(benchmark)이며, 해결률(resolve rate)로 점수가 매겨집니다. Dockerless의 핵심적인 움직임은 실행이 필요 없는 동일한 판정(verdict)이 두 가지 학습 단계(training stages)를 동시에 구동한다는 점입니다. 즉, 지도 미세 조정 (Supervised Fine-Tuning, SFT) 단계에서는 학습할 궤적(trajectories)을 선택하고, 강화 학습 (Reinforcement Learning, RL) 단계에서는 보상 (reward) 역할을 수행합니다. 두 단계 모두 코드를 실행하지 않기 때문에, 전체 사후 학습 (post-training) 파이프라인은 환경으로부터 자유롭습니다(environment-free). 이를 통해 Verified 62.0%, Multilingual 50.0%, Pro 35.2%를 기록하며 (Qwen3.5-9B 베이스라인 대비 각각 +2.4 / +8.7 / +2.9 상승), Learn AI Visually에 처음 게시되었습니다.