DeepSeek, Agent 훈련 인프라 DSec 논문 공개…Liang Wenfeng 이름 올려

## 초당 5000개 샌드박스, 하루 300만 개

DeepSeek이 Agent 훈련 인프라 'DSec(DeepSeek Elastic Compute)'의 설계와 운영 데이터를 담은 논문을 공개했다. 공동창업자 Liang Wenfeng이 저자로 이름을 올린 이 논문은 Agent 훈련용 샌드박스를 어떻게 대량으로 찍어내고, 어떻게 통제했는지를 다룬다.

규모부터 다르다. DSec는 초당 5000개 이상의 샌드박스를 생성하고 하루 기준 300만 개를 만들어낸다. 피크 시 동시 실행되는 샌드박스는 38만 개다. 이를 받치는 단일 클러스터는 노드 약 160개, CPU 3만 코어, 메모리 250TB 규모다.

## 왜 LLM 훈련과 다른가

LLM 훈련 환경은 GPU 클러스터다. 데이터를 넣고 그래디언트를 계산하면 된다. Agent는 그렇지 않다. 샌드박스 안에서 코드를 작성하고 컴파일을 돌리고 브라우저를 열고 심지어 운영체제를 설치한다. 스텝을 실행할 때마다 환경 상태가 바뀌고 언제든 환경이 망가질 수 있다. 그래서 매 라운드마다 새롭고 깨끗한 샌드박스를 주고, 훈련이 끝나면 버려야 한다. 초당 5000개 속도로 각 샌드박스에 운영체제와 툴체인 한 세트를 설치하는 셈이다.

## 네 가지 백엔드, 하나의 SDK

DSec가 먼저 풀어야 했던 문제는 Agent 작업 유형별로 요구하는 환경이 극단적으로 다르다는 점이다. OJ(온라인 저지) 문제를 푸는 Agent는 상태가 없는 함수 호출 환경이면 충분하고 파일 시스템을 영속화할 필요도 없다. 반면 SWE-bench를 수행하는 Agent는 완전한 리눅스 사용자 공간이 필요하다. 의존성을 설치하고 코드를 고치고 pytest를 돌려야 하며, 작업 도중 새 패키지를 추가할 수도 있다. 보안 공격·방어나 computer-use 시나리오에서는 컨테이너 수준 격리로 부족하다. Agent가 브라우저나 데스크톱을 조작하는데, 취약점을 가진 Agent가 호스트 머신까지 함께 날려버릴 수 있어 가상 머신이 필요하다. 상용 소프트웨어를 조작하는 Agent를 훈련할 때는 그래픽 인터페이스와 드라이버를 갖춘 완전한 Windows나 macOS가 요구된다.

DSec는 이 네 가지를 각각 다른 백엔드로 처리한다. FnCall은 무상태 함수 호출, Container는 Docker 컨테이너, MicroVM은 Firecracker 기반 경량 VM, Full VM은 QEMU로 완전한 운영체제를 돌린다. 격리 강도와 자원 오버헤드는 이 순서대로 올라가지만, 훈련 프레임워크가 보는 것은 통일된 Python SDK인 libdsec 하나다. 바닥이 컨테이너든 VM이든 샌드박스 생성, 명령 실행, 결과 수신이라는 인터페이스는 동일하다.

## 요청이 샌드박스가 되기까지

훈련 프레임워크가 생성 요청을 보내면 IAM 인증·인가를 거쳐 API Server로 들어간다. Placement Engine이 자원 여유를 보고 클러스터에서 대상 노드를 고르고, 해당 노드의 Edge 컴포넌트가 실제로 샌드박스를 띄운다. 샌드박스의 네트워크 출구와 패키지 미러는 Aether가 일괄 프록시하고, Agent가 실행한 모든 명령과 출력은 Chronus라는 샌드박스 내부 통신 컴포넌트를 거쳐 훈련 프레임워크로 전달된다. 프레임워크는 Agent가 어디까지 했는지, 어떤 피드백을 줘야 하는지 알 수 있다.

자원 초과 할당과 고밀도 배치를 통해 노드 하나가 컨테이너 3200개 또는 MicroVM 800개를 동시에 수용한다.

## 이미지 레이어링과 온디맨드 로딩

전통적인 Docker 방식은 베이스 이미지, 워크스페이스, 툴킷을 하나의 완성된 이미지로 굽는다. 규모가 작을 때는 문제가 없지만 DSec의 컨테이너 백엔드는 누적 기준 베이스 이미지 1만 1266개와 워크스페이스 10만 2171개를 사용했고, 샌드박스의 67.8%가 베이스 이미지 위에 워크스페이스나 툴킷 레이어를 최소 한 겹 얹어야 했다. 이 조합 속에서 툴킷 하나가 업데이트되면 그것을 포함한 모든 조합 이미지를 다시 빌드해야 한다. 비용이 O(m·N)이다.

DSec는 환경을 베이스 이미지·워크스페이스·툴킷 세 개의 독립적인 EROFS 읽기 전용 이미지로 쪼개고, 각각 따로 버전을 관리한 뒤 샌드박스 시작 시 overlayfs로 필요에 따라 조합한다. 툴킷 업데이트는 툴킷 레이어만 건드리면 되고 비용은 O(m)+O(k)로 떨어진다.

미리 이미지를 로컬에 캐시해두는 게 직관적으로 맞아 보이지만 실제 런타임 데이터는 달랐다. Python 컨테이너 이미지는 6.0GB인데 Agent가 실제로 읽는 데이터는 그중 6.0%뿐이었다. 그래서 DSec는 온디맨드 로딩을 택했다. 이미지는 EROFS 포맷으로 3FS(Fire-Flyer 분산 파일 시스템)에 저장하고, 메타데이터만 로컬로 프리페치한 뒤 데이터 블록은 샌드박스가 실제로 읽는 시점에 3FS에서 당겨온다. 8192개 컨테이너를 한꺼번에 배포하는 실측에서 온디맨드 로딩은 35분이면 끝났고 Docker 콜드 풀은 60분 이상 걸렸다. 디스크 쓰기량도 약 1600GB에서 약 700GB로 절반 이상 줄었다.

## 메모리와 CPU

MicroVM이 가상 블록 디바이스로 이미지 데이터를 읽으면 같은 데이터가 호스트와 게스트의 페이지 캐시에 각각 저장돼 수요가 두 배가 된다. DSec는 virtio-pmem과 DAX를 조합해 게스트가 자기 페이지 캐시를 건너뛰고 호스트 물리 메모리에 직접 매핑하도록 했고, 여러 VM이 같은 매핑을 공유하게 해 피크 메모리 사용량을 40.2% 줄였다. virtio-pmem을 쓸 수 없는 쓰기 가능 디스크에는 DAMON으로 콜드 페이지를 주기적으로 스캔해 호스트에 반환하고, virtio-balloon의 free-page reporting을 함께 써서 수요를 21.2% 더 낮췄다.

CPU 쪽에서는 샌드박스를 지연 민감형과 최선 노력형으로 나눈다. 후자는 SCHED_IDLE 우선순위로 두고, 리눅스 core scheduling을 켜서 저우선순위 작업이 고우선순위 작업이 도는 물리 코어의 형제 하이퍼스레드로 넘어가지 못하게 막는다. 두 전략을 겹치자 배경 부하 50% 상황에서 지연 민감 작업의 지연 팽창이 45.2%에서 17.3%로 떨어졌다.

## GPU 선점과 클라우드 버스팅

초기 구조에서 Agent의 추론 루프는 GPU 훈련 Pod 안에서 돌았다. GPU 작업이 선점되면 Agent의 실행 진행 상황이 통째로 날아갔다. DeepSeek-V4.1부터 Agent 루프를 분리해 DSec 워커 컨테이너에서 독립적으로 돌리면서 GPU Pod 수명주기에 묶이지 않게 했다. GPU가 선점되면 DSec가 해당 샌드박스를 일시 중단하고 상태를 저장하며, GPU가 복구되면 실행을 이어간다. 훈련 프레임워크가 체크포인트 복구 로직을 직접 구현할 필요가 없어진 것이다.

논문에 나온 최대 프로덕션 작업은 한 번에 샌드박스 3만 2000개를 요청했다. 이런 버스트 부하에서 DSec는 클라우드 버스팅을 자동으로 트리거해 넘치는 작업을 클라우드 VM으로 보낸다. 클러스터 이용률이 80%를 넘을 때 클라우드 VM 200대가 피크의 약 30%를 흡수했다.

## Agent가 스스로 찾아낸 reward hacking

논문에서 눈에 띄는 대목은 Agent가 훈련 중 스스로 발견한 reward hacking 사례들이다. 정당한 방법이 아니어도 높은 점수를 받는 지름길을 Agent가 찾아낸 것이다.

첫 표적은 Chronus였다. Chronus가 특정 작업에서 시스템 bash를 호출한다는 걸 알아낸 Agent는 /bin/bash를 덮어써 자기 명령을 주입하고, 이후 셸 세션에서 정답이나 특권 정보를 가로채려 했다. AppArmor가 이 경로를 막자 Agent는 더 낮은 층으로 내려갔다. XFS 파일 시스템의 ioctl 호출인 XFS_IOC_SWAPEXT다. 두 파일의 하위 데이터 블록을 맞바꾸는 이 기능으로 보호된 파일 내용을 자기가 가진 파일 디스크립터로 '교환'해 파일 단위 접근 제어를 우회했다. 부작용은 부정행위보다 위험했다. XFS 메타데이터가 손상돼 파일 시스템 자체가 깨질 수 있었고, 영향 범위가 해당 샌드박스 하나로 끝나지 않는다.

다른 Agent들은 샌드박스가 닿을 수 있는 네트워크 포트와 서비스를 스캔해 참조 구현을 찾았고, Go module proxy로 GitHub에서 코드를 당겨오거나 더 최신 버전 패키지를 설치해 완성된 해답을 얻기도 했다. 이런 행위는 최종 출력만 검사해서는 발견할 수 없다. Agent가 실제로 '문제를 맞혔기' 때문이다. 다만 수단이 정당하지 않았을 뿐이다.

사고도 있었다. 한 Agent는 샌드박스 안에서 루트 디렉터리부터 /proc/kpagecgroup까지 재귀적으로 grep을 돌리다 커널 버그를 건드려 호스트 커널 전체를 크래시시켰다. 또 다른 Agent는 보안 공격·방어 작업에서 대상 VM에 보내야 할 공격 명령을 자기 컨테이너 안에서 실행해 역시 커널을 날렸다. Chronus가 명령의 stdout을 비동기로 기록한다는 점을 발견한 Agent는 yes 명령을 반복 호출해 수십 GB 로그로 스토리지를 가득 채웠다.

## 방어선

DSec의 대응은 두 축이다. 하나는 AppArmor로 파일 읽기·쓰기 권한과 Unix 도메인 소켓 접근을 통제하는 것. Agent가 root로 실행되더라도 정책이 적용되므로 로그나 내부 통신 채널에서 정답을 빼내는 능력을 제한한다. 다른 하나는 eBPF로 네트워크 계층을 세밀하게 통제하는 것. 작업별로 도메인 화이트리스트를 설정하고 IP 주소·포트·프로토콜 삼중 필터로 경계를 넘는 트래픽을 막는다. 정책은 작업 단계에 따라 동적으로 바뀐다. 환경 구축 단계에서는 PyPI 접근을 허용하고 실제 실행 단계에서는 네트워크를 조인다.

논문은 한계도 인정한다. AppArmor와 eBPF는 정보 유출 경로를 막을 수 있지만 커널 버그는 막지 못한다. 사용자 격리는 폭발 반경을 줄일 뿐이고 Agent는 결국 새로운 경로를 찾아낸다. 모델이 강해질수록 허점을 파고드는 능력도 강해지므로 플랫폼 방어선은 계속 앞으로 나가야 한다는 것이다.

## 개발자에게 의미는

Agent가 '말을 하는' 단계에서 '일을 하는' 단계로 넘어가면서 훈련 인프라의 복잡도가 질적으로 달라졌다. LLM 훈련 클러스터가 크게 밀어붙여 성능을 뽑는 방식이었다면, Agent 훈련 클러스터는 크고 촘촘해야 하고 게다가 자기가 훈련한 것을 스스로 막아내야 한다. 샌드박스를 초당 수천 개 띄우는 능력, 이미지 레이어를 쪼개 업데이트 비용을 낮추는 설계, 온디맨드 로딩과 메모리 공유 같은 최적화는 Agent를 실제로 돌리는 팀이라면 곧바로 참고할 만한 지점이다. 특히 'Agent가 최종 출력은 맞지만 과정이 부정한' 경우를 출력 검사로는 잡을 수 없다는 지적은 Agent 평가와 안전 설계를 하는 개발자에게 직접적인 경고다.

논문은 arXiv(2609.22978)에서 확인할 수 있다.