개발자의 노트북은 에이전트를 위한 첫 번째 프로덕션 환경이다

Docker는 이번 주 AI 에이전트(AI agents) 보안에 관한 게시물을 발표했는데, 가장 흥미로운 부분은 사실 Docker 자체가 아니었습니다.

해당 게시물은 에이전트에게 실행 격리(execution isolation), 도구 접근 제어(tool access control), 신원 및 자격 증명 관리(identity and credential management), 그리고 런타임 모니터링(runtime monitoring)이 필요하다는, 이제는 익숙해진 주장을 펼치고 있습니다. 또한, 말하기 조심스러운 부분인 '권한 승인 프롬프트(permission prompts)만으로는 충분하지 않다'는 점을 명확히 짚었습니다.

이는 당연한 일이어야 합니다.

하지만 충분히 당연하게 여겨지지는 않고 있습니다.

코딩 에이전트(coding agents)를 둘러싼 대부분의 논의는 여전히 개발자의 컴퓨터를 마법이 일어나는 편리한 장소로 취급합니다. 에이전트는 에디터(editor)에서 실행됩니다. 저장소(repository)를 볼 수 있습니다. 도구를 호출할 수 있습니다. 로그를 읽고, 테스트를 실행하며, 패키지를 설치하고, 브라우저를 열고, API를 호출하며, 때로는 코드를 푸시(push)할 수도 있습니다. 만약 에이전트가 무서운 일을 하기 전에 정중하게 물어본다면, 우리는 그것을 보안이라고 부릅니다.

이것은 앞뒤가 바뀌었습니다.

개발자의 노트북은 에이전트를 위한 첫 번째 프로덕션 환경(production environment)이 되어가고 있습니다.

로컬(local)이 저위험을 의미하지는 않는다

우리는 로컬 개발(local development)이 프로덕션보다 규모가 작다는 이유로 더 안전하다고 취급하는 나쁜 습관이 있습니다.

프로덕션에는 고객 데이터, 가동 시간 보장(uptime guarantees), 컴플라이언스(compliance) 규칙, 그리고 대시보드가 있습니다. 노트북에는 절반쯤 완성된 브랜치(branch), 터미널(terminal), 그리고 근처에 있는 사람이 있으니 우리는 안심합니다.

하지만 현대적인 개발자 환경은 훌륭한 공격 대상입니다.

그곳에는 소스 코드, 클라우드 자격 증명(cloud credentials), 패키지 매니저 토큰(package manager tokens), SSH 키, 브라우저 세션, 프로덕션 형태의 데이터가 복사된 로컬 데이터베이스, 그리고 프로덕션보다 보안이 느슨한 경우가 많은 스테이징 시스템(staging systems)에 대한 접근 권한이 있습니다. 또한 임의의 코드를 실행할 수 있는 빌드 스크립트(build scripts)도 있습니다.

이제 그 기계에 에이전트를 올려두고 시니어 엔지니어가 사용하는 것과 동일한 도구 인터페이스(tool surface)를 부여해 보십시오.

그것은 더 이상 챗봇(chatbot)이 아닙니다.

그것은 회사에서 가장 특권이 부여된 환경 중 하나 내부에서 활동하는 자동화 액터(automation actor)입니다.

권한 승인 프롬프트는 사용자 인터페이스(UI)이지, 경계(boundary)가 아니다

명확한 해답은 인간에게 권한을 요청하는 것입니다.

이 명령어를 실행해도 될까요?

이 파일을 수정해도 될까요?

네트워크에 접속해도 될까요?

이 의존성(dependency)을 설치해도 될까요?

프롬프트(Prompts)는 유용합니다. 저는 프롬프트를 좋아합니다. 프롬프트는 적절히 속도를 늦춰주어, 에이전트(agent)가 가끔 어리석은 행동을 하려는 순간을 알아차릴 수 있게 해줍니다.

하지만 프롬프트는 보안 모델(security model)이 아닙니다.

프롬프트는 프롬프트가 나타나는 순간 인간이 행동의 모든 결과를 이해한다는 전제에 의존합니다. 명령어가 npm install이고, 의존성 그래프(dependency graph)가 800개의 패키지 깊이로 얽혀 있으며, 에이전트가 이를 다음 단계로 당연한 과정처럼 제시할 때 인간에게 이를 요구하는 것은 너무나 큰 부담입니다.

프롬프트는 "테스트를 실행하시겠습니까?"라고 말합니다.

테스트 러너(test runner)는 라이프사이클 스크립트(lifecycle scripts)를 실행합니다.

라이프사이클 스크립트는 환경 변수(environment variable)를 읽습니다.

환경 변수에는 스테이징(staging) 환경에 배포할 수 있는 토큰(token)이 포함되어 있습니다.

인간은 테스트를 실행하는 것이 일반적인 일이기에 '예'를 클릭했습니다.

이것이 바로 런타임 격리(runtime containment)가 중요한 이유입니다. 유용한 프롬프트는 의도(intent)를 물을 수 있습니다. 하지만 진정한 경계(boundary)는 의도와 결과가 어긋날 때 폭발 반경(blast radius)을 제한합니다.

에이전트는 개발자보다 더 적은 신뢰를 필요로 한다

여기에는 불편한 지점이 있습니다. 에이전트는 일반적으로 그들을 감독하는 개발자보다 권한이 적어야 합니다.

이는 비효율적으로 들릴 수 있습니다. 하지만 이는 다른 모든 자동화 시스템이 결국 성장해 나가는 방식이기도 합니다.

우리는 테스트를 실행해야 한다는 이유로 CI(지속적 통합)에 CEO의 노트북을 주지 않습니다. 하나의 배포 단계에 하나의 자격 증명(credential)이 필요하다고 해서 GitHub Action에 모든 클라우드 권한을 부여하지 않습니다. 언젠가 편리할지도 모른다는 이유로 빌드 워커(build worker)가 모든 리포지토리(repository)에 자유롭게 쓸 수 있도록 허용하지도 않습니다.

우리가 자동화의 범위를 제한(scope)하는 이유는 자동화가 빠르고, 문자 그대로만 실행하며, 주변 맥락(context)이 변했을 때 이를 인지하는 능력이 부족하기 때문입니다.

코딩 에이전트(coding agents)도 이와 동일한 범주의 문제이며, 단지 더 매력적인 인터페이스를 가지고 있을 뿐입니다.

README를 편집하는 에이전트에게 AWS 자격 증명이 필요하지는 않습니다. 파서(parser)를 리팩터링(refactoring)하는 에이전트에게 기본적으로 네트워크 권한이 필요하지는 않습니다. 마이그레이션(migration)을 생성하는 에이전트는 그것이 명시적이고 격리된 워크플로(workflow)가 아닌 한, 공유 데이터베이스에 이를 적용할 수 없어야 합니다. 버그를 조사하는 에이전트에게는 인간이 접근할 수 있는 모든 것에 접근 가능한 셸(shell)이 아니라, 제한된 도구를 통한 비식별화된 로그(redacted logs)가 필요할 수 있습니다.

유용한 기본 설정은 "이것은 나의 어시스턴트이므로 내 머신(machine)의 권한을 상속받는다"가 아닙니다.

유용한 기본 설정은 "이것은 자동화 프로세스(automation process)이므로, 작업을 완료할 수 있는 가장 작은 작업 공간(workspace)과 도구 세트(tool set)를 할당받는다"입니다.

오래된 샌드박스(sandbox) 담론의 귀환

이 부분은 피곤할 정도로 우스꽝스럽게 느껴집니다.

우리는 수년 동안 컨테이너(containers), 마이크로VM(microVMs), CI 격리(CI isolation), 네트워크 정책(network policies), 서비스 계정(service accounts), 비밀 관리자(secret managers), 그리고 감사 추적(audit trails)을 구축하는 데 시간을 보냈습니다. 그러다 AI 코딩 도구들이 등장했고, 많은 데모가 로컬의 마법(local magic)이 방해받기에는 너무나 강력했기에 이러한 교훈들을 조용히 우회해 버렸습니다.

이제 우리는 동일한 아키텍처(architecture)를 다시 발견하고 있습니다.

에이전트(agent)를 격리된 작업 공간(isolated workspace)에서 실행하십시오. 필요한 파일만 마운트(mount)하십시오. 명시적인 네트워크 정책(network policy)을 부여하십시오. 주변 환경 변수(ambient environment variables) 대신 범위가 지정된 도구(scoped tools)를 통해 자격 증명(credentials)을 전달하십시오. 읽기 전용 검사(read-only inspection)와 쓰기 가능 작업(write-capable actions)을 분리하십시오. 인간 검토자(human reviewer)가 프롬프트(prompt)부터 디프(diff)까지의 경로를 재구성할 수 있도록 충분한 증거를 남기십시오.

이 중 어느 것도 생소한 것이 아닙니다. 이는 단지 개발자 머신(developer machine)에 적용된 플랫폼 엔지니어링(platform engineering)일 뿐입니다.

Docker가 에이전트 격리(agent isolation)에 대해 이야기하는 것은 흥미롭습니다. 왜냐하면 Docker는 이미 "이 프로세스는 파일 시스템(filesystem), 네트워크 형태(network shape), 그리고 경계(boundary)를 할당받는다"라는 사고 모델(mental model)에서 승리했기 때문입니다. 마이크로VM(microVMs)은 그 경계를 더욱 확장합니다. 운영 체제(operating system) 기능들도 계속해서 같은 방향으로 움직일 것입니다. Microsoft는 이미 플랫폼 계층(platform layer)에서의 에이전트 런타임 경계(agent runtime boundaries)에 대해 논의하고 있습니다.

방향은 명확합니다. 에이전트 보안(agent security)은 앱(app)과 에디터(editor) 아래 단계로 이동하고 있습니다.

그래야만 합니다.

노트북은 정책이 가장 먼저 테스트되는 곳이다

이 논의의 기업용 버전은 결국 매우 공식화될 것입니다.

에이전트 ID(agent identities), 감사 API(audit APIs), 정책 엔진(policy engines), 승인된 도구 카탈로그(approved tool catalogs), 모델 라우팅 규칙(model routing rules), 그리고 예산 제어(budget controls)가 존재하게 될 것입니다. 어떤 에이전트가 어떤 인간 감독자(human supervisor)의 관리하에 어떤 리포지토리(repo)를 건드렸는지 보여주는 대시보드(dashboards)도 있을 것입니다.

그 이전에, 노트북이 있습니다.

그곳에서 첫 번째 잘못된 패턴들이 나타납니다:

필요하지 않은 파일을 읽는 에이전트 (agents reading files they did not need)
검토 없이 퍼블릭 인터넷에서 패키지를 설치하는 에이전트 (agents installing packages from the public internet without review)
권한 범위가 제한된 자격 증명 (scoped credentials)이 번거롭다는 이유로 광범위한 사용자 자격 증명을 사용하는 에이전트 (agents using broad human credentials because scoped credentials are annoying)
충분한 실행 증거 (execution evidence) 없이 차이점 (diffs)을 생성하는 에이전트 (agents producing diffs without enough execution evidence)
아무도 부작용 (side effects)을 검사하지 않은 명령을 실행하는 에이전트 (agents running commands whose side effects nobody inspected)
신뢰할 수 있는 프로젝트 상태와 신뢰할 수 없는 생성물 (untrusted generated artifacts)을 혼합하는 에이전트 (agents mixing trusted project state with untrusted generated artifacts)

이것들은 가상의 기업 거버넌스 (enterprise governance) 문제가 아닙니다. 도구가 계속 사용하기에는 충분히 좋지만 완전히 신뢰하기에는 아직 미성숙한, 일반적인 개발 과정 중에 실제로 발생하는 일들입니다.

노트북은 정책이 사용하기 편리해지느냐, 아니면 사장되느냐가 결정되는 지점입니다.

보안 경로가 너무 느리면 개발자들은 이를 우회할 것입니다. 격리된 환경 (isolated environment)에서 프로젝트를 실행할 수 없다면, 그들은 이를 꺼버릴 것입니다. 자격 증명 범위 제한 (credential scoping)이 유용한 모든 워크플로 (workflow)를 망가뜨린다면, 다시 광범위한 토큰 (broad token)을 사용하게 될 것입니다. 감사 추적 (audit trail)을 읽을 수 없다면, 검토자들은 이를 무시할 것입니다.

에이전트 보안은 지루할 정도로 단순하고, 로컬 (local) 중심적이며, 사람들이 이를 계속 켜두고 싶을 만큼 충분히 빨라야 합니다.

내가 지금 한다면 (what i would do now)

만약 내가 엔지니어링 팀에 코딩 에이전트 (coding agents)를 도입하는 책임을 맡았다면, 거창한 AI 거버넌스 (AI governance) 문서를 작성하기 전에 로컬 격리 (local containment)부터 시작할 것입니다.

첫째, 작업 공간 (workspaces)을 분리하십시오. 에이전트는 실수로 인한 쓰기 작업의 비용이 저렴한 복사본, 브랜치 (branch), 컨테이너 (container) 또는 샌드박스 (sandbox) 내에서 작동해야 합니다. 그러면 사람이 결과를 검토하고 승격 (promote)할 수 있습니다.

둘째, 네트워크 액세스 (network access)를 명시적으로 만드십시오. 많은 코딩 작업은 인터넷이 필요하지 않습니다. 인터넷이 필요한 작업은 그 이유를 밝혀야 합니다. 패키지 설치는 배경 소음이 아니라 공급망 이벤트 (supply-chain event)로 취급되어야 합니다.

셋째, 주변 자격 증명 (ambient credentials)을 제거하십시오. 에이전트가 서비스 호출이 필요하다면, 해당 작업에 대해 범위가 제한된 도구 (scoped tool)나 수명이 짧은 자격 증명 (short-lived credential)을 부여하십시오. 개발자가 셸 (shell)에 우연히 가지고 있던 모든 토큰을 에이전트가 상속받게 해서는 안 됩니다.

넷째, 증거를 보존하십시오. 실행된 명령(commands), 출력(outputs), 변경된 파일, 실행된 테스트, 그리고 외부 호출(external calls)은 검토 가능한 흔적(reviewable trail)으로 남아야 합니다. 인간 검토자가 무슨 일이 일어났는지에 대해 에이전트의 요약(summary)만을 믿어야 하는 상황이 되어서는 안 됩니다.

다섯째, 안전한 경로를 즐겁게 만드십시오. 이것은 지루한 제품 작업(product work)입니다. 만약 샌드박스(sandbox)를 시작하는 데 5분이 걸린다면, 아무도 그것을 사용하지 않을 것입니다. 만약 오타 하나를 수정하는 데 20번의 승인이 필요하다면, 사람들은 보안 설정을 비활성화할 것입니다. 일상적인 개발 과정을 견뎌낼 수 없는 보안은 시스템이 아니라 단순한 메모(memo)에 불과합니다.

핵심 요약 (the punchline)

로컬 코딩 에이전트(Local coding agents)는 에디터 안에 자리 잡고 1인칭으로 말하기 때문에 개인적인 느낌을 줍니다.

운영 측면에서 보면, 이들은 권한이 부여된 환경(privileged environment) 내부에서 실행되는 자동화 시스템(automation systems)입니다.

그 차이가 중요합니다.

개발자의 노트북에는 소스 코드, 자격 증명(credentials), 빌드 도구(build tools), 스테이징 접근 권한(staging access), 그리고 제품을 출시하기 위해 분주히 움직이는 인간이 있습니다. 로컬이라고 해서 단순히 장난감 환경(toy environment)인 것은 아닙니다. 에이전트에게 있어 노트북은 첫 번째 프로덕션 환경(production environment)이며, 프로덕션에 걸맞은 경계(production-shaped boundaries)를 갖춰야 합니다.

권한 승인 프롬프트(Permission prompts)는 유용합니다. 하지만 그것만으로는 충분하지 않습니다.

진정한 제품은 격리(containment), 신원(identity), 범위가 지정된 도구(scoped tools), 감사 추적(audit trails), 그리고 개발자들이 실제로 계속 켜두고 싶어 할 워크플로(workflow)입니다.

소프트웨어 엔지니어링의 세계에 다시 오신 것을 환영합니다. 에이전트는 새로운 것이지만, 보안 문제는 새로운 것이 아닙니다.

참고 문헌 (references)

제 프로젝트를 테스트하기 위해 저는 Railway를 사용합니다. 시작할 때 20달러(USD)를 받고 싶다면 이 링크를 사용하세요.