코딩 에이전트를 평가할 때는 정답률만큼 실행 환경도 중요하다. 에이전트는 과제를 푸는 동안 패키지를 설치하고, 파일을 수정하고, 명령을 실행한다. 이런 작업을 반복하는 벤치마크에서는 생성된 코드가 어디까지 접근할 수 있는지, 이전 과제의 변경 사항이 다음 평가에 영향을 주지 않는지까지 살펴야 한다.
Docker가 2026년 10월 14일 발표한 Harbor와 Docker Sandboxes의 연동은 이 실행 환경을 다룬다. 오픈소스 평가 프레임워크인 Harbor가 과제 실행과 결과 수집을 맡고, Docker Sandboxes가 각 과제를 실행할 격리 환경을 제공하는 구성이다. 현재 연동의 적용 범위는 CPU에서 실행하는 단일 컨테이너 과제다. GPU나 여러 컨테이너가 필요한 평가라면 발표된 지원 범위부터 구분해서 읽어야 한다.
Harbor는 평가를 관리하고, Sandboxes는 실행 공간을 나눈다
에이전트 평가에는 서로 다른 두 종류의 일이 있다. 하나는 과제를 전달하고, 에이전트가 작업하도록 한 뒤, 결과를 검사하고 점수와 로그를 모으는 일이다. 다른 하나는 그 작업이 진행되는 동안 호스트 컴퓨터와 다른 과제를 보호하고, 과제마다 일관된 시작 조건을 제공하는 일이다.
Harbor는 첫 번째 역할을 맡는다. Docker의 설명에 따르면 Terminal-Bench 같은 벤치마크를 받아 평가 실행 과정을 정리하는 오픈소스 프레임워크다. Docker Sandboxes와의 연동은 여기에 과제별 실행 환경을 연결한다. 따라서 이번 소식은 새로운 코딩 에이전트의 출시라기보다, 기존 에이전트를 비교하고 검증하는 기반의 변화로 보는 편이 정확하다.
개인 개발자에게는 로컬에서 평가 환경을 분리할 수 있는지가 관심사다. 학생과 연구자에게는 실험 조건을 설명하고 반복할 수 있는지가 중요하다. 개발팀이라면 모델이나 에이전트 설정을 바꿀 때 동일한 과제를 다시 실행해 품질 변화를 확인하는 흐름에 연결할 수 있는지 살펴볼 만하다.
MicroVM 격리가 줄여 주는 위험과 별도로 남는 문제
Docker Sandboxes는 MicroVM 기반 환경이다. 발표에서는 과제마다 자체 커널을 가진 MicroVM에서 실행할 수 있다는 점을 강조한다. 에이전트가 설치한 도구나 수정한 파일을 과제 환경 안에 가두고, 호스트와 다른 과제에 미치는 영향을 줄이려는 설계다.
이는 일반적인 컨테이너 실행과 비교할 때 확인할 핵심 차이다. 다만 격리 구조에 대한 설명만으로 모든 환경에서 안전이 보장된다고 판단해서는 안 된다. 실제 적용에서는 에이전트에 전달하는 파일, 인증 정보, 외부 서비스 접근 권한이 무엇인지 함께 확인해야 한다. 평가에 필요하지 않은 저장소나 개인 자료를 넣지 않는 것부터 시작하는 편이 좋다.
실행 환경의 격리와 평가 점수의 신뢰성은 따로 검토해야 한다. 원문은 에이전트가 과제를 해결하는 대신 테스트를 변조하거나 점수를 기록하는 파일을 덮어써 통과할 수 있는 사례를 언급한다. 이런 보상 해킹은 평가 대상이 채점 방식의 허점을 이용하는 문제다. MicroVM으로 호스트를 보호하더라도 과제 내부에서 채점 자원에 접근할 수 있다면 점수가 왜곡될 여지는 별도로 남는다.
따라서 평가를 설계할 때는 에이전트가 수정해도 되는 파일과 채점에 사용하는 자원을 구분하고, 성공 판정이 실제 결과를 반영하는지 점검해야 한다. 이번 발표를 보상 해킹을 자동으로 해결하는 기능으로 읽기보다는, 격리 환경 위에서 더 엄격한 평가 조건을 구성할 수 있게 된 변화로 이해하는 편이 적절하다.
설치 단계와 풀이 단계의 네트워크를 구분하는 이유
이번 연동에서 실험 설계와 직접 연결되는 기능은 사용자 지정 네트워크 정책이다. Docker는 준비 단계에서는 필요한 항목을 내려받게 하고, 에이전트가 실제 과제를 수행할 때는 인터넷 연결을 차단하는 구성을 예로 든다.
이 구분은 평가 결과의 해석에 영향을 준다. 어떤 실행에서는 외부 문서를 검색할 수 있고 다른 실행에서는 검색할 수 없다면, 점수 차이가 에이전트 자체의 능력 때문인지 접근 가능한 정보 때문인지 구분하기 어렵다. 외부 연결이 허용된 경우에도 패키지 저장소나 서비스의 상태가 달라지면 실행 결과가 흔들릴 수 있다.
반대로 인터넷을 차단하는 것이 모든 평가에 알맞은 것은 아니다. 자료 검색이나 외부 API 사용이 과제의 핵심이라면 연결을 막는 순간 측정하려던 작업과 다른 평가가 된다. 먼저 측정하려는 능력을 정하고, 그에 맞춰 허용할 목적지와 연결 시점을 정해야 한다.
- 코드 수정 능력을 비교한다면 의존성 준비를 마친 뒤 외부 정보 접근을 제한하는 구성을 검토한다.
- 검색 도구 활용 능력을 평가한다면 필요한 연결을 허용하고, 접근 범위가 각 실행에서 동일한지 확인한다.
- 패키지 설치 자체가 과제에 포함된다면 설치 단계의 네트워크 제한이 평가 목적과 충돌하지 않는지 살핀다.
재현성을 높이려면 네트워크 정책 외에도 과제 버전, 의존성, 에이전트 설정, 실행 자원 같은 조건을 함께 기록하는 것이 좋다. 이는 발표에서 자동으로 보장한다고 확인된 기능이 아니라, 결과를 비교하기 위해 사용자가 관리해야 할 실험 조건이다.
로컬 실행과 클라우드 확장을 선택하는 기준
Docker는 같은 과제를 로컬과 Docker Cloud Sandboxes에서 실행할 수 있다고 설명한다. 노트북에서 과제 구성을 확인하고, 이후 클라우드에서 여러 작업을 병렬로 실행하는 흐름을 제시한다. 로컬에서 평가 정의를 다듬고 더 많은 실행이 필요할 때 확장하려는 사용자에게 관련성이 있다.
소수의 과제에서 오류를 찾는 단계라면 로컬 실행이 관리하기 쉬울 수 있다. 설치 실패나 파일 경로 문제를 가까이서 확인할 수 있기 때문이다. 여러 에이전트 설정을 비교하거나 반복 횟수를 늘리는 단계에서는 클라우드의 병렬 실행이 검토 대상이 된다. 다만 로컬에서 성공했다는 사실만으로 클라우드에서도 시간과 결과가 같다고 가정해서는 안 된다. 실행 자원과 네트워크 정책, 로그 회수 방식이 의도대로 적용되는지 확인해야 한다.
원문에는 Docker Cloud Sandboxes에서 동시 작업자 64개로 Harbor를 시험했다는 설명이 있다. 이는 Docker가 공개한 시험 사례다. 모든 계정의 기본 한도나 보장된 처리량, 사용자가 얻을 성능으로 해석할 근거는 없다. 자신의 계정에서 허용되는 동시 실행 수와 자원 조건을 확인한 뒤 실행 규모를 정해야 한다.
CPU 단일 컨테이너라는 경계를 먼저 확인한다
발표의 핵심 요약에는 각 평가 과제를 Sandboxes에서 실행할 수 있다는 설명이 있지만, 실제 적용 판단에서는 지원 범위에 관한 구체적인 문장을 우선해야 한다. 발표 시점의 연동은 CPU 기반 단일 컨테이너 과제를 지원하며, GPU와 다중 컨테이너 지원은 향후 제공 대상으로 언급됐다.
평가 과제가 하나의 실행 환경 안에서 끝나는지 먼저 살펴보자. 별도의 데이터베이스나 여러 서비스가 함께 떠야 하는 과제, GPU 연산에 의존하는 과제는 현재 지원 범위에 맞는지 추가 확인이 필요하다. 향후 지원 예고만으로 기존 평가 구성을 그대로 옮길 수 있다고 판단해서는 안 된다.
학생이나 연구자는 사용하려는 벤치마크의 요구사항부터 대조하는 편이 좋다. 개발자는 실제 제품 전체를 평가할 것인지, 일부 코드 수정 과제만 분리해 평가할 것인지 결정해야 한다. 분리 과정에서 실제 작업의 중요한 조건이 빠진다면 실행이 가능해져도 점수의 활용도는 낮아질 수 있다.
첫 실행에서 확인할 계정과 인증 조건
원문은 Harbor의 Sandboxes 연동 구성 요소를 설치한 뒤 클라우드 접근을 활성화하고, Docker 계정의 개인 액세스 토큰을 생성하는 절차를 제시한다. 토큰의 접근 권한에서는 Cloud Sandboxes를 선택하도록 안내한다. 생성한 토큰은 한 번만 표시되므로 보관 방식도 준비해야 한다.
클라우드 실행 예시는 Docker ID와 토큰을 각각 SBX_DOCKER_USERNAME, SBX_DOCKER_PAT 환경 변수로 전달하고, hello-world 과제를 oracle 에이전트로 실행하는 구성이다. 이 예시는 연결과 기본 실행 경로를 확인하는 출발점으로 볼 수 있다. 자신이 비교하려는 코딩 에이전트의 성능을 확인하려면 해당 에이전트와 과제에 맞는 설정을 따로 갖춰야 한다.
로컬 실행에는 Docker Sandboxes CLI 설치와 sbx login이 필요하며, 제시된 실행 명령에 –ek target=local 옵션을 추가하도록 안내한다. 실제 설치를 진행할 때는 연결된 공식 문서에서 현재 명령과 필요한 환경을 다시 확인하는 것이 좋다.
인증 정보는 평가 결과와 함께 관리할 자료가 아니다. 공유 노트북, 공개 저장소, 연구 결과 첨부 파일에 토큰이 포함되지 않도록 하고, 실패 로그를 공유하기 전에도 자격 증명이 노출되는지 확인해야 한다. 특히 여러 사람이 쓰는 실행 환경에서는 누가 어떤 계정의 권한으로 평가를 돌리는지 명확히 해 두는 편이 좋다.
무료 시작 문구만으로 총비용을 판단하지 않는다
Docker는 로컬 환경의 Docker Sandboxes에서 무료로 시작해 클라우드로 확장하는 흐름을 소개한다. 그러나 제공된 본문에는 클라우드의 구체적인 단가, 무료 사용량, 계정별 제한이 제시되어 있지 않다. 따라서 클라우드 평가까지 무료라고 해석하거나 특정 규모의 월 비용을 계산할 근거는 부족하다.
실제 비용을 비교할 때는 샌드박스 실행 비용과 에이전트가 사용하는 모델·API 비용을 구분해서 확인해야 한다. 과제 하나의 실행 시간뿐 아니라 재시도 횟수, 비교할 설정 수, 반복 실행 횟수도 전체 지출에 영향을 줄 수 있다. 과금 항목과 한도는 사용하는 서비스의 현재 조건을 기준으로 확인해야 한다.
기존 평가 환경이 있다면 전환의 가치는 반복 작업이 얼마나 줄어드는지로 판단할 수 있다. 이미 환경 초기화와 결과 수집이 안정적이라면 연동을 추가하는 작업량도 비교해야 한다. 반대로 과제 사이의 상태 오염이나 실행 환경 차이를 자주 조사하고 있다면, 과제별 격리와 공통 실행 경로가 그 부담을 줄이는지 확인할 이유가 있다.
대표 과제로 실행 실패와 풀이 실패를 구분한다
처음부터 전체 벤치마크를 옮기기보다는 자신의 작업을 대표하는 소수의 과제를 골라 실행 경로를 확인하는 편이 좋다. 단순히 점수가 나오는지만 보지 말고, 실패한 이유를 설명할 수 있는지까지 확인해야 이후 비교가 의미를 갖는다.
- 현재 지원 범위에 맞는 CPU 단일 컨테이너 과제를 고르고, 필요한 파일과 의존성을 정리한다.
- 기본 예제로 Harbor와 Sandboxes의 연결을 확인한 뒤 실제 평가할 에이전트 설정을 적용한다.
- 준비 단계와 풀이 단계에 필요한 네트워크 접근을 구분하고, 정책이 의도대로 작동하는지 확인한다.
- 같은 조건으로 반복 실행하면서 점수, 소요 시간, 실패 원인, 로그의 충분성을 비교한다.
- 클라우드 확장 시 계정 한도와 비용 조건을 확인하고, 로컬 결과와 차이가 생기는 지점을 살핀다.
의존성 다운로드 실패와 에이전트의 코드 수정 실패는 같은 결과로 묶지 않는 편이 좋다. 전자는 실행 환경의 문제일 수 있고, 후자는 평가하려는 능력과 직접 관련될 수 있다. 채점 파일 변경처럼 의심스러운 통과 사례도 점수만 남기지 말고 결과물과 실행 기록을 함께 확인해야 한다.
이번 연동의 실용적인 가치는 에이전트를 더 많이 실행하는 데서 끝나지 않는다. 각 실행이 어떤 조건에서 이뤄졌는지 설명하고, 환경 문제와 에이전트의 한계를 구분할 수 있어야 한다. 자신의 과제가 현재 지원 범위에 들어가고, 격리·네트워크 제어·실행 확장이 기존 평가의 구체적인 부담을 줄여 줄 때 적용을 검토할 만하다.
출처와 검증
출처는 Docker Blog의 2026년 10월 14일 발표 Harbor + Docker Sandboxes: Run Safe, Reproducible Agent Evals다. Harbor와 Docker Sandboxes의 역할, MicroVM 기반 실행, 네트워크 정책, 로컬·클라우드 실행 방식, CPU 단일 컨테이너 지원 범위, 동시 작업자 64개 시험 사례는 제공된 원문에 근거했다.
GPU와 다중 컨테이너는 발표 당시 향후 지원 대상으로 안내됐다. 클라우드 가격과 무료 범위, 계정별 동시 실행 한도, 데이터 보존·삭제 조건은 제공된 내용만으로 확정할 수 없다. 적용 시에는 원문에서 연결하는 Docker Sandboxes 및 Harbor 공식 문서와 현재 계정의 이용 조건을 확인해야 한다. 위의 실험 설계와 인증 정보 관리 항목은 발표 내용을 실제 평가에 적용하기 위한 점검 기준이다.