코딩 에이전트를 Docker·GitHub Actions·VM·쿠버네티스 중 어디서 돌릴까요, OpenHands 샌드박스 비교를 보고 오늘은 에이전트에게 넘길 저장소와 비밀값 목록부터 적습니다 | DAKER 커뮤니티

코딩 에이전트를 노트북에서 권한 확인 없이 돌리고 있다면, 그 에이전트는 지금 내가 접근할 수 있는 거의 모든 것에 닿아 있습니다. AI Engineer 채널이 2026년 10월 12일 공개한 OpenHands 공동창업자·CEO Robert Brennan의 발표 「Sandboxes Aren't Optional: 4 Ways to Isolate Coding Agents」(14분 22초)는 이 문제를 노트북 Docker, Claude Code와 GitHub Actions, 전용 VM이나 Mac mini, 세션마다 쿠버네티스 파드를 띄우는 방식까지 네 가지로 나눠 비교합니다. 결론은 단순합니다. 어디서 돌릴지 정하기 전에, 에이전트가 일을 하는 데 정확히 무엇이 필요한지부터 적어야 합니다. 이 글은 발표 내용을 정리하고, 대회·해커톤 참가자가 오늘 바로 적어 볼 목록 한 장으로 마무리합니다.

따뜻한 베이지 벽 앞 책상 위의 고화질 일러스트풍 생성 이미지. 왼쪽부터 노트북이 놓인 나무 쟁반, 톱니바퀴가 든 유리 상자, 데스크톱 컴퓨터가 든 튼튼한 유리 상자, 빈 카드 더미가 든 밀폐 유리 큐브가 차례로 놓여 있고, 가운데 흰 카드에 코딩 에이전트를 어디서 돌릴까요라는 한글 문구가 있으며 오른쪽 위에 DAKER 공식 로고가 있습니다
설명용 생성 이미지입니다.

발표 개요: 누가, 어디서, 무엇을 비교했나

발표자는 OpenHands를 공동창업한 Robert Brennan입니다. 그는 OpenHands를 2년여 전 MIT 라이선스 코딩 에이전트로 시작했고, 지금은 하네스부터 인프라, 대규모 에이전트를 지켜보는 관제 기능까지 묶은 실행 플랫폼으로 넓혔다고 소개합니다. 영상 설명란에 따르면 이 발표는 샌프란시스코에서 열린 AI Engineer World's Fair 2026에서 녹화됐습니다.

발표의 흐름은 AI 개발 도구의 변화에서 시작합니다. 챗봇이 코드 조각을 써 주던 단계, Cursor나 GitHub Copilot처럼 편집기 안에서 자동 완성을 하던 단계를 지나 2024년 초부터는 에이전트가 자기가 쓴 코드를 직접 실행하고 오류 메시지를 읽으며 개발 반복을 스스로 돌리는 단계로 넘어왔다는 설명입니다. Brennan은 지금 대부분의 개발자가 Claude Code, OpenHands, Codex 같은 에이전트를 자기 노트북에서 짝 프로그래머처럼 쓰고 있고, 2026년에 조직들이 넘어가는 다음 단계가 클라우드에서 도는 에이전트라고 봅니다. 샌드박스가 중요해지는 지점이 바로 여기입니다.

클라우드 에이전트에는 두 가지가 필요합니다. 하나는 일할 장소, 즉 터미널과 파일 시스템입니다. 다른 하나는 접근 범위의 제한입니다. 사람이 옆에서 지켜보지 않는 상태에서 GitHub, DataDog, Slack 같은 시스템의 이벤트를 받아 스스로 움직이게 되면, 허용된 것에만 닿도록 미리 막아 두는 수밖에 없기 때문입니다.

권한 확인을 끄면 에이전트는 내가 가진 모든 것에 닿습니다

발표 중 Brennan은 청중에게 노트북에서 로컬 에이전트를 쓰는 사람, 그중에서도 권한 확인을 건너뛰는 옵션(--dangerously-skip-permissions)을 쓰는 사람에게 손을 들어 달라고 합니다. 두 번째 질문에서 오히려 손이 더 많이 올라왔다고 웃으며 넘어가지만, 이어지는 설명은 가볍지 않습니다.

로컬 에이전트에게는 사실상 두 가지 선택지만 있습니다. 승인 버튼을 계속 누르며 옆에서 지켜보거나, 확인을 끄고 에이전트가 중요한 파일을 지우거나 운영 데이터베이스에 들어가지 않기를 믿는 것입니다. 확인을 끈 에이전트는 로컬 파일 시스템 전체, 환경 변수에 든 비밀값, 홈 디렉터리에 저장된 인증 정보, 연결돼 있는 운영 데이터베이스나 운영 쿠버네티스 클러스터에까지 닿을 수 있다고 Brennan은 짚습니다.

에이전트는 기본적으로 내가 접근할 수 있는 모든 것에 접근할 수 있습니다. 지켜보든지, 필요한 것만 남기고 나머지를 끊든지 둘 중 하나입니다.

그가 꺼내는 해법은 새로운 개념이 아니라 오래된 보안 원칙인 최소 권한 원칙입니다. 사람이든 에이전트든 일에 필요한 것에만 접근해야 한다는 원칙입니다. 저장소를 고치는 에이전트라면 그 GitHub 저장소 하나와 로컬 데이터베이스에 붙기 위한 비밀값 몇 개면 충분합니다. 이렇게 범위를 좁혀 두면 프롬프트 인젝션 공격을 받거나 에이전트가 지시를 잘못 이해했을 때 피해가 번지는 범위, 발표 표현으로는 블라스트 반경이 함께 줄어듭니다.

샌드박스를 만들기 전에 이 에이전트가 일을 하려면 정확히 무엇이 필요한지부터 봐야 합니다. 그다음 딱 그만큼만 담은 샌드박스를 만듭니다.

첫째 방식: 노트북 위 Docker 컨테이너

많은 개발자가 처음 시도하는 방식은 노트북에서 Docker 컨테이너 안에 에이전트를 띄우는 것입니다. Brennan은 OpenHands도 처음에는 대화를 시작할 때마다 새 Docker 컨테이너를 하나씩 띄우는 구조로 출시했다고 설명합니다.

장점은 일회성입니다. 에이전트가 rm -rf로 모든 파일을 지워도 컨테이너를 없애고 다시 시작하면 됩니다. 또 노트북 위에서 돌기 때문에 Git 저장소처럼 필요한 폴더만 골라 연결(마운트)할 수 있고, 포트를 열어 에이전트가 띄운 앱을 내 브라우저로 확인하거나, 특정 비밀값과 환경 변수만 넘기거나, MCP 서버를 노트북이나 컨테이너 안에서 돌릴 수도 있습니다. 에이전트가 내 로컬 코드 사본을 그대로 고치고, 푸시 시점은 내가 정한다는 점에서 평소 작업 방식과도 가깝습니다.

한계는 규모와 트리거입니다. 노트북 한 대에서 띄울 수 있는 컨테이너 수에는 끝이 있고, 노트북은 Slack이나 DataDog에서 오는 이벤트를 상시 듣고 있을 수 없습니다.

Claude Code 공식 문서의 개발 컨테이너(dev container) 안내도 같은 방향의 주의점을 적어 둡니다. 컨테이너가 비루트 사용자로 Claude Code를 실행하고 명령 실행을 컨테이너 안으로 한정하므로 무인 실행에 권한 확인 생략 옵션을 쓸 수 있지만, 이 옵션은 루트로 실행하면 거부됩니다. 또 바인드 마운트된 작업 폴더의 파일은 여전히 고칠 수 있고 그 변경은 호스트에 바로 나타나며, 네트워크 정책이 허용하는 곳에는 접속할 수 있다고 설명합니다. 그래서 문서는 외부 송신 제한(방화벽)과 함께 쓰라고 권하고, 호스트의 ~/.ssh나 클라우드 인증 파일을 컨테이너에 마운트하지 말고 저장소 범위의 단기 토큰을 쓰라고 안내합니다. 신뢰할 수 있는 저장소에서만 쓰라는 경고도 함께 붙어 있습니다.

둘째 방식: Claude Code와 GitHub Actions

두 번째로 많이 쓰는 방식은 Claude Code를 GitHub Actions에 붙이는 것입니다. 이제 에이전트는 내 로컬 사본이 아니라 GitHub Actions의 일회성 환경에서 저장소를 복제해 작업하고, 결과를 내보낸 뒤 실행이 끝나면 환경째 사라집니다.

Brennan이 꼽는 장점은 비용을 감당하는 만큼 병렬로 돌릴 수 있다는 점, 비밀값 저장소가 기본으로 들어 있다는 점, 그리고 일정 실행입니다. 예를 들어 매주 월요일 오전 9시에 에이전트를 띄워 의존성을 올리거나, PR이 열릴 때마다 에이전트가 코드 리뷰를 하게 만들 수 있습니다. 에이전트가 노트북을 떠나 클라우드에서 돌기 시작하면서 자동화가 가능해지는 첫 단계라는 설명입니다.

단점은 종속성입니다. GitHub Actions는 독자 규격이라 다른 곳으로 옮기기 어렵고, GitHub에서 생긴 이벤트에만 반응합니다. Slack 웹훅이나 DataDog 웹훅으로 에이전트를 깨우고 싶다면 이 방식만으로는 부족합니다.

Claude Code 공식 GitHub Actions 문서를 보면 실제로 챙길 항목이 더 분명해집니다. 인증값은 ANTHROPIC_API_KEY 또는 CLAUDE_CODE_OAUTH_TOKEN 이름의 저장소 시크릿으로 넣고, 키를 저장소에 커밋하지 말라고 안내합니다. 워크플로에는 필요한 권한만 주고, 머지 전에 변경을 검토하라고 적혀 있습니다. 일정 실행은 기본 브랜치에서만 돌고, 공개 저장소에서는 60일 동안 저장소 활동이 없으면 GitHub가 일정을 끈다는 점도 문서에 있습니다. 비용 관리를 위해 반복 횟수 상한(--max-turns), 워크플로 단위 시간 제한, 동시 실행 제어를 함께 걸라는 권고도 있습니다.

셋째 방식: 전용 VM이나 Mac mini 한 대

세 번째는 클라우드 가상 머신이나 Mac mini 같은 별도 컴퓨터를 한 대 마련해 에이전트를 모두 그 위에 올리는 방식입니다. Brennan은 이 방식이 OpenClaw 열풍 때 널리 퍼졌다고 언급합니다.

GitHub Actions와 가장 크게 다른 점은 오래 살아 있는 환경, 즉 지속성입니다. 에이전트가 시스템을 바꿔 두면 이틀 뒤 다시 돌 때도 그 상태가 남아 있습니다. 이것은 장점이자 단점입니다. 기계가 꼬인 상태로 남으면 사람이 들어가 원인을 찾아야 하기 때문입니다. 대신 일정 실행은 물론이고 Twilio 문자, Slack 메시지, DataDog 장애 알림, GitHub 이벤트 같은 웹훅을 상시 받아 에이전트를 자동으로 깨울 수 있습니다.

문제는 최소 권한이 다시 무너진다는 점입니다. 여러 에이전트가 한 머신에 같이 살면 모두 같은 자원에 닿습니다. Brennan이 드는 예는 구체적입니다. 코드 리뷰 에이전트와 DataDog 장애 분류 봇이 같은 VM에 있으면, 코드 리뷰 에이전트가 이유 없이 DataDog에 접근할 수 있고 심지어 분류 봇의 메모리를 고칠 수도 있습니다. 내 환경과는 분리됐지만 에이전트끼리는 서로 영역을 침범할 수 있는 구조입니다.

넷째 방식: 세션마다 쿠버네티스 파드

Brennan이 가장 견고하다고 평가하는 방식은 쿠버네티스처럼 확장성이 크고 일회성인 환경입니다. 에이전트 세션 하나마다 파드 하나를 띄우고, 에이전트가 저장소 사본에서 일을 마치고 PR을 올리면 파드와 환경이 함께 사라집니다.

매번 깨끗한 환경에서 시작하므로 VM처럼 장기 상태가 꼬일 걱정이 없고, 메모리와 CPU 비용을 감당하는 만큼 에이전트를 늘릴 수 있습니다. 크론 작업으로 일정 실행을 하고, Slack·GitHub·Jira에서 오는 HTTP 이벤트로 에이전트를 깨울 수 있어 완전 자동 실행에 가장 가깝습니다. 다만 에이전트를 늘린 만큼 메모리와 CPU 비용도 함께 늘어난다는 조건을 발표자도 붙여 둡니다.

다섯 가지 기준으로 나란히 놓고 보면

Brennan은 실행 방식을 고를 때 다섯 가지를 본다고 말합니다. 로컬인지 원격인지, 얼마나 많이 돌릴 수 있는지, 격리 수준은 어떤지, 상태가 남는지, 무엇이 에이전트를 깨우는지입니다. 발표에서 직접 언급한 내용만 표로 옮기면 다음과 같습니다.

방식로컬·원격규모격리지속성트리거
노트북에서 권한 확인 생략로컬, 내 코드 사본몇 개 수준사실상 없음기본 유지사람이 직접 프롬프트 입력
노트북 Docker 컨테이너로컬, 내 코드 사본노트북 자원 안에서 제한적컨테이너 단위, 필요한 폴더·비밀값만 마운트컨테이너를 지우면 초기화사람이 직접 실행
Claude Code + GitHub Actions원격, 저장소 복제비용을 감당하는 만큼실행마다 일회성 환경실행이 끝나면 사라짐GitHub 이벤트, 일정
전용 VM·Mac mini원격머신 한 대 안에서내 환경과는 분리, 에이전트끼리는 공유기본 유지일정, 각종 웹훅
세션마다 쿠버네티스 파드원격수천 개까지세션마다 별도 작업 공간세션이 끝나면 사라짐크론, HTTP 이벤트

표에서 보듯 정답이 하나로 정해지지는 않습니다. Brennan도 발표 끝에서 OpenHands Agent Canvas를 소개하며, 내 로컬 코드를 보면서 에이전트와 빠르게 주고받아야 할 때와 이벤트를 던져 두고 몇 시간 동안 에이전트를 백그라운드로 돌려야 할 때가 서로 다르다고 말합니다. 이 도구는 Claude Code, Codex, OpenHands 하네스를 노트북, Docker, 원격 VM, 쿠버네티스 사이에서 전환하며 돌리게 해 준다는 것이 발표자의 설명이며, 발표자 회사의 제품 소개라는 점은 감안해서 보면 됩니다. 그가 덧붙인 한마디도 기억할 만합니다. Claude Code가 꺼질까 봐 노트북을 연 채로 자전거를 타고 퇴근해 본 적이 있다면, 에이전트를 클라우드로 옮길 이유가 충분하다는 것입니다.

샌드박스도 만능은 아닙니다

Brennan은 샌드박스가 만병통치약은 아니라고 분명히 말합니다. 그는 Anthropic이 Mythos를 시험하던 중 한 인스턴스가 샌드박스를 벗어나 인터넷에 접속한 사례가 있었다고 언급하고, 오래된 버전의 Docker를 쓰면 이미 알려진 컨테이너 탈출 공격에 노출될 수 있다고 설명합니다. 그래도 에이전트가 해야 할 일의 범위를 묶어 두는 첫 번째 방어선으로는 충분히 의미가 있다는 것이 그의 결론입니다.

Claude Code 공식 문서도 같은 입장입니다. 개발 컨테이너가 상당한 보호를 제공하더라도 모든 공격을 막는 시스템은 없고, 권한 확인 생략 옵션으로 실행하면 악의적인 프로젝트가 컨테이너 안에서 접근 가능한 것, 예를 들어 ~/.claude에 저장된 Claude Code 인증 정보까지 빼낼 수 있다고 경고합니다. 샌드박스를 쓴다는 사실보다 그 안에 무엇을 넣었는지가 더 중요하다는 뜻입니다.

대회·해커톤 참가자에게 바뀌는 점

이 발표는 회사의 운영 환경을 전제로 하지만, 대회와 해커톤에서 코딩 에이전트를 쓰는 참가자에게도 그대로 옮겨 올 수 있는 부분이 있습니다. 아래는 발표 내용을 참가자 상황에 대입해 본 정리이며, 특정 대회 규정을 설명하는 것은 아닙니다. 각 대회의 데이터 사용 규칙과 제출 방식은 반드시 DAKER 해커톤 페이지의 공지를 기준으로 확인해야 합니다.

첫째, 노트북에서 권한 확인을 끄고 밤새 에이전트를 돌리는 습관부터 점검할 필요가 있습니다. 대회용 폴더 옆에 회사 저장소, 개인 SSH 키, 다른 프로젝트의 API 키가 함께 있다면 에이전트는 그 전부에 닿을 수 있습니다. 대회 데이터와 코드만 담은 폴더를 Docker 컨테이너에 마운트하는 것만으로도 블라스트 반경이 크게 줄어듭니다.

둘째, 팀으로 참가한다면 공용 키 관리가 달라집니다. 팀원 한 명의 노트북에 모든 키를 모아 두고 에이전트를 돌리기보다, GitHub Actions 시크릿처럼 실행 환경에 필요한 키만 넣는 구조가 사고가 났을 때 피해 범위를 좁힙니다. 공식 문서 권고대로 워크플로 권한과 실행 시간 상한도 함께 걸어 두면 비용이 새는 것도 막을 수 있습니다.

셋째, 실행 위치는 작업 성격에 따라 나누면 됩니다. 모델을 고치며 결과를 바로 확인해야 하는 실험은 로컬 컨테이너가 편하고, 매일 정해진 시각에 의존성을 점검하거나 테스트를 돌리는 일은 일정 실행이 되는 원격 환경이 맞습니다. 하나의 VM에 여러 에이전트를 모아 둔다면, 각 에이전트가 서로의 메모리나 로그를 고칠 수 있는지부터 확인해야 합니다.

오늘 바로 할 한 가지: 에이전트에게 넘길 목록 한 장

네 방식 중 무엇을 고르든 출발점은 같습니다. 지금 쓰는 코딩 에이전트 하나를 골라, 그 에이전트가 일을 하는 데 정말 필요한 것만 한 장에 적어 보십시오. 이 목록이 곧 샌드박스 설계도가 됩니다.

  1. 작업 폴더: 에이전트가 고쳐야 하는 저장소나 폴더 경로를 하나만 적습니다. 홈 디렉터리 전체가 적혀 있다면 범위를 다시 좁힙니다.
  2. 비밀값: 에이전트가 실제로 쓰는 API 키와 토큰만 적고, 저장소 범위의 단기 토큰으로 바꿀 수 있는지 표시합니다. SSH 키나 클라우드 인증 파일은 목록에서 뺍니다.
  3. 네트워크: 에이전트가 접속해야 하는 주소를 적습니다. 모델 API와 패키지 저장소 외에 꼭 필요한 곳이 있는지 확인합니다.
  4. 트리거: 이 에이전트를 사람이 직접 깨우는지, 일정으로 깨우는지, 외부 이벤트로 깨우는지 적습니다.
  5. 상태: 실행이 끝난 뒤 남아야 하는 것(결과 파일, 로그, PR)과 지워져도 되는 것을 나눕니다.

목록이 완성되면 표의 다섯 기준과 맞춰 봅니다. 트리거가 사람뿐이고 로컬 코드를 직접 봐야 한다면 노트북 Docker 컨테이너로 충분합니다. 일정 실행이 필요하고 GitHub 이벤트만 다룬다면 GitHub Actions가 맞고, 여러 외부 이벤트를 받아야 한다면 원격 VM이나 쿠버네티스를 검토할 차례입니다. 어느 쪽이든 목록에 없는 폴더와 키는 넣지 않는 것이 이 발표가 말하는 최소 권한의 실천입니다.

여러분은 지금 코딩 에이전트를 어디에서 돌리고 계십니까? 노트북, 컨테이너, GitHub Actions, 원격 서버 중 어떤 방식을 쓰는지, 그리고 에이전트에게 넘긴 키 가운데 오늘 뺄 수 있는 것이 있었는지 댓글로 나눠 주십시오.

출처