에이전트 샌드박스(Agent Sandboxes)는 새로운 기업용 데스크톱이다
요약
GitHub가 Copilot을 위한 클라우드 및 로컬 샌드박스 기능을 공개 미리보기로 출시했습니다. 이는 에이전트가 개발자의 로컬 환경에 직접 접근할 때 발생할 수 있는 보안 위험을 격리된 환경을 통해 해결하려는 시도입니다.
핵심 포인트
- Copilot이 격리된 로컬 및 클라우드 샌드박스 내에서 실행 가능
- 에이전트의 셸 명령어 실행 시 파일 시스템 및 네트워크 권한 제한
- 클라우드 모드를 통해 기업 정책이 적용된 일시적 Linux 환경 제공
- 에이전트 실행 환경을 개인 기기에서 관리 가능한 작업 환경으로 전환
GitHub는 이번 달에 Copilot을 위한 클라우드 및 로컬 샌드박스(Sandboxes)라는, 평범하게 들리는 기능을 공개 미리보기(Public Preview)로 출시했습니다.
'평범하다'는 말에는 많은 의미가 담겨 있습니다.
이번 릴리스에 따르면 Copilot은 이제 개발자의 로컬 머신이나 GitHub가 호스팅하는 클라우드 환경 내에서 보안이 유지되는 격리된 샌드박스(Sandboxes) 내부에서 실행될 수 있습니다. 로컬 모드는 Copilot에 의해 시작된 셸(Shell) 명령어가 사용할 수 있는 파일 시스템, 네트워크 및 시스템 권한을 제한합니다. 클라우드 모드는 에이전트(Agent)에게 기업 정책이 적용된 일시적인(Ephemeral) Linux 환경을 제공합니다.
이것은 단순히 제품의 체크박스 항목 하나를 추가한 것처럼 들릴 수 있습니다.
하지만 저는 이것이 새로운 범주의 기업용 데스크톱(Enterprise Desktop)에 더 가깝다고 생각합니다.
당신의 노트북은 기본 샌드박스(sandbox)였습니다
많은 개발자 도구(developer tooling)에 있어, 노트북은 게으른 해답이 되어 왔습니다.
CLI를 설치합니다. 저장소(repo)를 클론(clone)합니다. 회사의 절반 정도에 인증합니다. 클라우드 자격 증명(credentials)을 편리한 곳에 둡니다. 패키지 레지스트리(package registry)를 위한 토큰을 추가합니다. GitHub를 위한 또 다른 토큰을 추가합니다. 에디터를 엽니다. 어시스턴트(assistant)가 워크스페이스(workspace)를 볼 수 있게 합니다. 터미널(terminal)이 터미널의 역할을 수행하게 합니다.
인간은 어떤 명령어가 위험한지 대략적으로 알고 있었습니다. 인간은 스크립트가 이상해 보이면 알아차렸습니다. 인간은 프로덕션(production) 자격 증명이 무작위 셸(shell) 세션에 놓여 있어서는 안 된다는 점을 이해하고 있었습니다. 적어도 운이 좋은 날에는 말이죠.
에이전트(Agents)는 그 가정을 약화시킵니다.
에이전트는 그럴듯해 보이는 로컬 작업을 수행하는 데 매우 능숙합니다. 또한 무언가를 시도하는 데도 매우 능숙합니다. 그들은 재시도합니다. 탐색합니다. 세상을 조사하기 위해 명령어를 실행합니다. 도구(tool)의 출력을 따라 다음 단계로 넘어갑니다.
그것은 유용합니다.
하지만 바로 그 점 때문에 실행 환경(execution environment)이 사후 고려 사항이 되어서는 안 됩니다.
만약 코딩 에이전트(coding agent)가 개발자의 노트북을 상속받는다면, 파일, 자격 증명, 네트워크 액세스, 로컬 데몬(local daemons), 패키지 매니저 캐시(package manager caches), SSH 설정, 그리고 우발적인 권한들이 뒤섞인 지저분한 묶음을 상속받게 됩니다. 그중 일부는 필요하지만, 상당수는 필요하지 않습니다.
노트북은 결코 깨끗한 보안 경계(security boundary)였던 적이 없습니다. 그저 편리했을 뿐입니다.
클라우드 샌드박스(cloud sandboxes)는 소유 모델을 변화시킵니다
클라우드 샌드박스는 에이전트 실행을 개인용 기기에서 관리되는 작업 환경으로 전환한다는 점에서 흥미롭습니다.
노트북에서는 플랫폼 팀(platform teams)이 가이드를 게시하고, 기기를 관리하며, 엔드포인트 정책(endpoint policies)을 밀어넣고, 개발자들이 로컬 환경을 적절히 정상적으로 유지하기를 바랄 수 있을 뿐입니다. 클라우드 샌드박스에서는 조직이 베이스 이미지(base image), 네트워크 정책(network policy), 비밀 정보 경로(secrets path), 파일 시스템 생명주기(filesystem lifecycle), 로깅(logging), 리소스 제한(resource limits), 그리고 폐기 동작(teardown behavior)을 직접 정의할 수 있습니다.
그렇다고 해서 그것이 마법처럼 안전해지는 것은 아닙니다.
그것을 조사 가능(inspectable)하게 만들 뿐입니다.
특정 작업에 필요한 리포지토리(repository)와 자격 증명(credentials)만 부여된 상태에서, 해당 작업을 위한 일시적인(ephemeral) Linux 샌드박스(sandbox)를 생성하여 실행 과정을 관찰하고, 작업이 완료되면 파괴할 수 있습니다. 이 작업은 이슈(issue), 브랜치(branch), 풀 리퀘스트(pull request), 비용 센터(cost center), 그리고 감사 추적(audit trail)과 연결될 수 있습니다.
이는 "에이전트가 Alice의 노트북 어딘가에서 실행되었고, 아마도 Alice가 모든 곳에 사용하는 것과 동일한 토큰을 사용했을 것이다"라는 상황보다 훨씬 더 나은 형태입니다.
여기서 중요한 단어는 아마도(probably)입니다.
보안 시스템은 이 '아마도'를 줄이기 위해 존재합니다.
로컬(local)도 여전히 중요하다
클라우드 샌드박스(cloud sandboxes)가 로컬 샌드박스(local sandboxes)를 무의미하게 만든다고 생각하지 않습니다.
개발자들에게는 여전히 빠른 피드백이 필요합니다. 그들은 여전히 복잡한 리포지토리(repos)에서 작업해야 합니다. 또한 원격 환경의 지연 시간(latency)과 절차적 비용(ceremony tax)을 지불하지 않고 작은 것들을 시도해 볼 필요가 있습니다.
따라서 로컬 샌드박싱(local sandboxing)은 단순한 장난감 기능이 아닙니다. 그것은 가교(bridge)입니다.
만약 Copilot이 파일 시스템(filesystem), 네트워크(network), 그리고 시스템 기능(system capabilities)에 대한 접근을 제한한 상태로 로컬에서 셸 명령(shell commands)을 실행할 수 있다면, 개발자는 에이전트에게 기계 전체를 넘겨주지 않고도 에이전트가 작업하도록 허용할 수 있습니다.
그것이 올바른 직관입니다.
실수는 로컬 샌드박싱을 개발자의 선호 사항으로 취급하는 것입니다.
기업의 경우, 이것은 정책(policy)이 되어야 합니다. 에이전트 명령이 읽거나 쓸 수 있는 디렉토리(directories)는 어디까지인가? 네트워크에 접근할 수 있는가? 내부 호스트(internal hosts)에 도달할 수 있는가? 환경 변수(environment variables)를 볼 수 있는가? Docker를 호출할 수 있는가? 패키지(packages)를 설치할 수 있는가?
이러한 질문들은 에이전트가 잘못된 명령을 실행하기 전까지는 지루하게 들릴 것입니다.
하지만 일단 실행되고 나면, 이 질문들이 곧 사고(incident) 그 자체가 됩니다.
이것은 코딩보다 더 큰 문제다
동일한 패턴이 에이전트 스택(agent stack)의 나머지 부분에서도 나타나고 있습니다.
AWS는 에이전트의 위치(location)가 보안 결정(security decision)이라는 단순한 논거를 제시해 왔습니다. 에이전트는 컴퓨팅 환경(compute environment)에서 실행되는 애플리케이션 코드(application code)입니다. IAM, VPC 경계(boundaries), 로그(logs), 그리고 심층 방어(defense-in-depth) 제어 기능이 이미 존재하는 곳에 에이전트를 배치하면, 제어 평면(control plane)은 모델이 우연히 무엇을 "생각"하느냐보다 훨씬 더 결정론적(deterministic)이 됩니다.
Docker의 MCP Gateway 역시 도구(tooling) 측면에서 동일한 방향을 지향합니다. 도구들은 패키징되어 게이트웨이를 통해 노출되고, 프로필별로 필터링되며, 공급망 검사(supply-chain checks) 및 범위가 제한된 비밀 정보 접근(scoped secret access)과 함께 실행됩니다. 에이전트는 단순히 마법 같은 도구들을 받는 것이 아닙니다. 통제된 역량(capabilities) 세트를 부여받는 것입니다.
OpenAI는 플러그인, 주석(annotations), 공유 가능한 작업(shareable work)을 통해 다양한 역할과 워크플로우 전반에 걸쳐 Codex를 밀어붙이고 있습니다. 이는 유용하지만, 에이전트가 도구, 문서, 대시보드, 코드 및 비즈니스 컨텍스트에 접근해야 하는 지점의 수를 확장시키기도 합니다.
이 패턴은 미묘하지 않습니다.
에이전트는 비인간 협업자(non-human collaborators)를 위한 워크스테이션이 되어가고 있습니다. 이는 기존의 엔드포인트 관리(endpoint management) 질문들이 다시 돌아오고 있음을 의미합니다: 어떤 ID(identities)가 존재하는가, 비밀 정보(secrets)는 어디에 저장되는가, 어떤 네트워크에 도달 가능한가, 어떤 파일이 영구적으로 남는가, 어떤 활동이 로그로 기록되는가, 그리고 접근 권한은 어떻게 취소되는가와 같은 질문들 말입니다.
이것이 기업 IT처럼 들린다면, 맞습니다.
그것이 바로 핵심입니다.
샌드박스에는 제품 감각(product taste)이 필요하다
모든 에이전트 작업이 12번의 승인으로 시작하여 아무도 읽지 않는 PDF로 끝나는 나쁜 버전의 미래가 존재합니다. 그런 방식은 실패할 것입니다. 개발자들은 이를 우회할 것이고, 실제 작업은 공식적인 경로 밖에서 계속될 것입니다.
샌드박스는 사용하기에 충분히 좋아야 합니다.
즉, 빠른 시작, 예측 가능한 베이스 이미지(base images), 쉬운 리포지토리(repository) 접근, 명확한 권한 요청, 양호한 로그, 저렴한 해체(teardown), 그리고 단순한 권한 상승(escalation)을 의미합니다.
워크플로우를 무시하는 보안 제어는 보여주기식(theater)에 불과하게 됩니다.
에이전트 샌드박스에 제품 감각이 필요한 이유는 그것들이 단순한 보안 인프라가 아니기 때문입니다. 그것들은 개발자 경험(developer experience) 인프라입니다.
안전한 경로가 고통스럽다면, 안전하지 않은 경로가 승리하게 됩니다.
결론(the punchline)
에이전트 샌드박스는 불안해하는 보안 팀을 위한 부가적인 기능이 아닙니다.
그것들은 새로운 종류의 노동자를 위한 실행 계층(execution layer)입니다.
모델은 제안할 수 있습니다. 에이전트는 행동할 수 있습니다. 샌드박스는 그 행동이 무엇을 의미하는지를 결정합니다.
그것이 샌드박스를 시스템에서 가장 중요한 부분 중 하나로 만듭니다. 샌드박스는 파일 시스템 도달 범위 (filesystem reach), 네트워크 도달 범위 (network reach), 도구 도달 범위 (tool reach), 자격 증명 도달 범위 (credential reach), 비용 도달 범위 (cost reach), 그리고 작업 중에 발생하는 모든 일의 지속성 (durability)을 정의합니다.
이를 잘 처리하는 기업들이 제어된 실행 (controlled execution)을 에이전트 작업이 일어나는 기본 장소로 만들 것입니다.
만약 에이전트가 풀 리퀘스트 (pull request)를 생성한다면, 리뷰에는 단순히 차이점 (diff)과 테스트 결과만 보여서는 안 됩니다. 작업이 어디에서 실행되었는지도 보여주어야 합니다: 샌드박스 유형 (sandbox type), 베이스 이미지 (base image), 신원 (identity), 네트워크 정책 (network policy), 쓰기 가능한 경로 (writeable paths), 마운트된 비밀 정보 (mounted secrets), 명령 (commands), 외부 엔드포인트 (external endpoints), 비용 (cost), 그리고 런타임 (runtime) 등이 포함되어야 합니다. 코드는 괜찮아 보일 수 있지만, 그 코드를 생성한 환경이 너무 강력했을 수도 있기 때문입니다.
로컬이 필요할 때는 로컬에서.
격리되어야 하고, 재현 가능하며 (reproducible), 관찰 가능해야 (observable) 할 때는 클라우드에서.
언제나 리뷰어가 에이전트에게 허용된 작업이 무엇인지 이해할 수 있을 만큼 경계가 명확해야 합니다.
과거의 기업용 데스크톱은 인간을 위한 관리형 머신 (managed machine)이었습니다.
새로운 데스크톱은 에이전트를 위한 일시적인 샌드박스 (ephemeral sandbox)가 될 수도 있습니다.
지루한 질문들은 동일합니다.
하지만 손은 훨씬 더 빠릅니다.
references
- GitHub Changelog: Cloud and local sandboxes for GitHub Copilot now in public preview
- AWS: Why the location of your AI agent is a security decision
- Docker: MCP Toolkit and Gateway, Explained
- OpenAI: Codex for every role, tool, and workflow
제 프로젝트를 테스트하기 위해 저는 Railway를 사용합니다. 시작할 때 20달러(USD)를 받고 싶다면 이 링크를 사용하세요.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기