요약 (tl;dr): 저는 제한적이고 통제된 액세스 권한을 가진 AI 에이전트를 위해 컨테이너화된 개발 환경을 실행하는 방법을 구축했습니다. 에이전트들은 필요한 자격 증명(credentials)과 네트워크 액세스만 부여받으므로, 보안을 타협하지 않으면서도 매번 권한을 요청할 필요 없이 작업을 계속할 수 있습니다. 로컬 세션은 몇 초 만에 시작되며, 노트북에서 벗어나고 싶을 때는 동일한 이미지를 Cloud Run에 배포할 수 있습니다.

The dashboard running five cloud sessions in parallel, with live terminals

출처: github.com/ykdojo/antigravity-cloud-run

권한 피로 (permission fatigue) 방지

Antigravity CLI를 사용하는 데에는 몇 가지 옵션이 있습니다. 각 요청을 수동으로 승인할 수 있습니다. 특정 유형의 요청은 자동으로 수락되도록 구성할 수도 있습니다. 또는 --dangerously-skip-permissions 옵션으로 실행하여 승인 과정을 완전히 건너뛸 수도 있습니다.

세 번째 옵션은 편리하지만 위험합니다. 사용자의 자격 증명(credentials)을 가지고 메인 머신에서 실행할 경우, 로컬 환경뿐만 아니라 GitHub, 이메일 등 로그인되어 있는 다른 계정들에까지 큰 피해를 줄 수 있습니다.

그래서 저는 모든 요청을 일일이 승인하지 않고도 --dangerously-skip-permissions를 사용하여 실행할 수 있도록, 대신 컨테이너(container) 안에 넣기로 결정했습니다. 에이전트는 별도의 GitHub 계정과 필요한 특정 키(keys)만 할당받습니다. 예를 들어, 에이전트가 스스로 게시물을 올리는 것을 원치 않는다면 계정에 대한 읽기 전용(read-only) 키를 줄 수 있습니다. 그렇게 하면 영향 범위(blast radius)를 제한할 수 있습니다.

액세스 권한을 갖는 항목

첫째, 이 시스템은 Antigravity를 위한 나의 OAuth 토큰을 가져오므로, 내 구독의 사용량 할당량(usage quota)을 사용할 수 있습니다. 현재는 API 키 옵션이 없으며, 오직 해당 토큰 파일만 존재합니다. 이 기능이 구현될 때까지(관련 이슈 요청 사항), 저는 이 방식을 사용하기로 결정했습니다. 컨테이너 내부에서 한 번 로그인하면, 그 이후의 모든 세션은 로컬과 클라우드 모두에서 해당 토큰을 통해 시드(seeded)됩니다.

또한 환경 변수(environment variables) 목록을 제공하면, 로컬이나 클라우드에서 세션을 시작할 때마다 컨테이너에 자동으로 주입됩니다.

저는 세션을 관리할 수 있는 대시보드도 구축하여, 몇 초 만에 세션을 시작하거나 중지 또는 삭제할 수 있습니다. 이것이 컨테이너의 장점입니다. 하나를 버리고 새로 시작하는 것이 매우 쉽습니다.

대화 기록(conversation history)은 세션 이름을 동일하게 지정하는 한 세션 간에 유지됩니다. 로컬에서는 볼륨 마운트(volume mount)를 통해 내 머신에 저장됩니다.

Cloud Run에서도 거의 동일한 방식으로 작동합니다. 키는 Secret Manager로 동기화되어 환경 변수로 서비스에 연결되며, 대화 기록은 세션당 하나씩 Cloud Storage 버킷으로 전송됩니다. 이 버킷은 60초마다 한 번, 그리고 종료 시에 다시 동기화됩니다. 따라서 재시작한 세션은 로컬과 마찬가지로 중단된 지점부터 다시 시작합니다.

클라우드 세션은 IAM으로 보호되며 절대 공개되지 않습니다. gcloud run services proxy를 실행하여 세션에 접속할 수 있는데, 이 명령은 머신에 로컬 포트를 열고 이를 컨테이너로 터널링합니다. 따라서 브라우저에서 localhost를 열고 그곳에서 에이전트 및 에이전트의 셸(shell)과 통신할 수 있습니다. 대시보드는 세션별로 이 작업을 대신 수행해 줍니다.

Tailscale 네트워크에 추가하기

이 부분은 선택 사항이지만, 이미 Tailscale을 사용하고 있다면 이 용도로 사용하는 것을 추천합니다.

이것이 필요한 이유는 Cloud Run이 서비스당 외부에서 접근 가능한 포트를 단 하나만 허용하며, 그 포트는 이미 웹 터미널(web terminal)이 사용하고 있기 때문입니다. 따라서 에이전트(agent)가 세션 내부에서 서버를 시작하고 이를 확인하고 싶더라도, 접근할 방법이 없습니다. Tailscale은 이를 해결하기 위한 우회책(workaround)입니다.

각 세션은 저의 개인 네트워크에 자체 노드(node)로서 참여하므로, 3000번 포트에서 실행 중인 서버는 제 노트북이나 제 tailnet에 있는 어떤 기기에서도 http://<session-name>:3000을 통해 접근할 수 있습니다. 액세스 규칙(access rules)이 설정된 방식 덕분에 이는 단방향으로만 작동합니다. 즉, 제가 컨테이너(container)에 접근할 수는 있지만, 컨테이너가 제 기기에 접근할 수는 없습니다.

Tailscale 키(key)가 있으면, 세션은 시작 시 에이전트의 AGENTS.md 파일에 자체 주소를 기록합니다. 덕분에 에이전트는 자신의 위치를 알 수 있으며, localhost 대신 실제로 작동하는 URL을 사용자에게 전달할 수 있습니다.

이것은 어디에 유용할까요?

사람들이 제게 이 질문을 던지곤 하는데, 질문의 이면에는 보통 제가 무언가를 24시간 내내 실행하고 싶어 할 것이라는 가정이 깔려 있습니다. 하지만 저는 딱히 그렇지 않습니다.

제가 원하는 것은 에이전트(agent)를 자유롭게 풀어놓을 수 있는 공간입니다. 장시간 실행되는 작업이나, 제 메인 컴퓨터에서 실행하고 싶지 않은 작업들을 위해서 말이죠. 연구(Research)가 그중 하나입니다. 수많은 YouTube 영상이나 Reddit 스레드를 훑어보는 작업 같은 것 말입니다. 이런 작업을 반드시 제 메인 컴퓨터에서 실행하고 싶지는 않습니다.

사이드 프로젝트(side project)의 기능을 구축하는 것도 또 다른 사례입니다. 제 메인 컴퓨터의 리소스(resources)를 사용하고 싶지 않기 때문에, 컨테이너(container)에서 실행하는 것이 편리합니다. 예를 들어, 에이전트가 스스로 초안 PR(draft PR)을 생성하고, Playwright를 사용하여 스크린샷을 찍은 뒤, 이를 해당 PR에 첨부하여 저에게 보내주면 제가 확인하고 머지(merge)할 수 있도록 하는 방식이 좋습니다.