업계가 계속해서 믿으려고 애쓰는 문장이 하나 있습니다:

"더 나은 지침(Instructions)을 통해 에이전트를 안전하게 만들 수 있다."

왜 그런지 이해합니다. 지침은 비용이 저렴합니다. 정책(Policies)은 익숙합니다. 시스템 프롬프트(System prompt)는 진지한 성인들이 "절대 안 됨", "반드시", "승인 시에만"과 같은 진지한 단어들을 작성할 수 있는 공간처럼 느껴집니다. 하지만 그 후 에이전트는 인터넷에서 README를 읽고, 패키지를 설치하고, 브라우저를 열고, MCP 서버를 호출하고, 리포지토리(Repository)를 건드리기 시작합니다. 그러고 나면 그 진지한 단어들은 마치 포스트잇 정도의 권위만 가진 채 실시간 워크플로(Workflow)를 통제하려 들게 됩니다.

이것이 바로 최근 Docker의 AI Engineer World's Fair 보고서가 제 눈길을 끈 이유입니다. 헤드라인은 에이전트 신뢰(Agent trust)에 관한 것이지만, 유용한 부분은 덜 극적입니다. 즉, 에이전트가 구축하는 기반을 강화하고, 실행되는 곳을 격리하며, 접근할 수 있는 범위를 제어하고, 이 모든 것을 한 곳에서 관리하라는 것입니다.

그것은 플랫폼 엔지니어링(Platform engineering)이 새로운 옷을 입고 방금 도착한 척하고 있는 것에 불과합니다.

agent reading every rule at once

좋습니다. 우리는 지난 10년 동안 유용한 소프트웨어에는 지루한 경계(Boundaries)가 필요하다는 것을 배워왔습니다. 컨테이너(Containers)에는 이미지 정책(Image policy), 네트워크 정책(Network policy), 레지스트리(Registries), 스캐너(Scanners), 서명된 아티팩트(Signed artifacts), 비밀 관리(Secrets management), 그리고 감사 로그(Audit logs)가 필요했습니다.

에이전트 역시 똑같은 취급을 받아야 마땅합니다.

에이전트가 반드시 악할 필요는 없습니다

쉬운 보안 시나리오는 에이전트가 파괴적인 명령을 실행할 수도 있다는 것입니다.

그것은 실제 상황이지만, 만화적인 버전이기도 합니다.

더 흔한 위험은 훨씬 조용합니다. 에이전트가 너무 많은 것을 읽는 것입니다. 연결되어서는 안 될 점들을 연결합니다. 비공개 리포지토리(Private repository)의 컨텍스트(Context)를 공개적인 도구 호출(Tool call)로 복사합니다. 새로운 네트워크 경로를 여는 의존성(Dependency)을 설치합니다. 서버 설명이 도움이 될 것 같고 오후 시간이 이미 길어졌다는 이유로 검토되지 않은 MCP 서버를 호출합니다.

악당은 필요 없습니다.

유용한 에이전트의 짜증 나는 점은 바로 이것입니다. 유용성은 접근 권한 (access)에서 나옵니다. 파일을 읽거나, 테스트를 실행하거나, 에러를 조사하거나, 의존성 (dependencies)을 설치하거나, 문서 도구를 호출하거나, 브라우저를 사용하거나, 혹은 풀 리퀘스트 (pull request)를 열 수 없는 코딩 에이전트는 기본적으로 자신감 문제만 있는 자동 완성 (autocomplete) 기능에 불과합니다.

따라서 질문은 "에이전트에게 접근 권한을 주어야 하는가?"가 아닙니다.

질문은 "그 접근 권한이 어디에서 중재 (mediated)되는가?"입니다.

만약 그 답이 "프롬프트 (prompt) 안"이라면, 우리는 "이것을 곧 교체해 주세요"라는 제목의 위키 (wiki) 페이지에 운영 환경 자격 증명 (production credentials)을 저장해 두는 팀처럼 낙관적으로 생각하고 있는 것입니다.

프롬프트는 의도를 형성하고, 런타임 (runtime)은 현실을 강제합니다

프롬프트는 중요합니다. 저는 지시 사항이 쓸모없다고 가장하는 세련된 척하는 사람들의 모임에 합류하지 않겠습니다. 명확한 지시는 행동을 개선할 수 있습니다. 좋은 시스템 프롬프트 (system prompt)는 작업 범위 (task scope), 에스컬레이션 규칙 (escalation rules), 그리고 기대치를 정의할 수 있습니다.

하지만 프롬프트는 확률 (probabilities)을 형성합니다.

런타임 (runtimes)은 경계 (boundaries)를 강제합니다.

그 차이가 중요합니다.

프롬프트는 "문서화를 제외하고는 네트워크에 접속하지 마세요"라고 말할 수 있습니다. 런타임은 허용되지 않은 네트워크 목적지를 실제로 차단할 수 있습니다. 프롬프트는 "저장소 (repository) 외부에는 쓰지 마세요"라고 말할 수 있습니다. 샌드박스 (sandbox)는 저장소는 읽기-쓰기 (read-write)로 마운트하고, 그 외의 모든 것은 읽기 전용 (read-only)으로 설정하거나 아예 접근하지 못하게 할 수 있습니다. 프롬프트는 "승인된 도구만 사용하세요"라고 말할 수 있습니다. 게이트웨이 (gateway)는 승인되지 않은 MCP 호출이 발생하기 전에 이를 거부할 수 있습니다.

approval gate energy

이것이 런타임 거버넌스 (runtime governance) 연구가 방향성 측면에서 옳게 느껴지는 이유입니다. 최근의 한 논문은 에이전트의 행동이 경로 의존적 (path-dependent)이라고 주장합니다. 즉, 위험은 단일 행동뿐만 아니라 그 행동에 이르게 된 일련의 행동 순서 (sequence of actions)에 달려 있다는 것입니다. 정적 접근 제어 (static access control)는 일부 사례를 잡아냅니다. 프롬프트 규칙은 일부 행동을 잡아냅니다. 하지만 에이전트가 도구를 통해 행동하기 시작하면, 실행 경로 (execution path) 자체가 관찰하고 거버넌스해야 할 대상이 됩니다.

실제 에이전트가 작동하는 모습을 보기 전까지는 그 말이 학술적인 이야기처럼 들릴 것입니다.

에이전트는 이슈를 읽습니다. 저장소 (repo)를 검색합니다. 문서를 엽니다. 패키지를 설치합니다. 테스트를 실행합니다. 에러를 따라 블로그 포스트로 이동합니다. 예시를 복사합니다. 코드를 수정합니다. 다른 명령어를 실행합니다. 브라우저 경로를 시도합니다. 풀 리퀘스트 (PR)를 엽니다.

각 단계는 단독으로는 정당해 보일 수 있습니다.

하지만 그 시퀀스 (sequence)가 문제가 될 수 있습니다.

MCP는 도구 계층을 모두의 문제로 만들었습니다

Model Context Protocol (MCP)는 에이전트에게 도구를 호출하는 공통된 방식을 제공하기 때문에 유용합니다. 하지만 정확히 그와 동일한 이유 때문에 위험하기도 합니다.

도구 접근 권한이 이식 가능해지면, 도구 거버넌스 (tool governance)는 피할 수 없는 과제가 됩니다.

MCP 서버는 단순한 플러그인이 아닙니다. 그것은 데이터베이스, 티켓 시스템, 클라우드 API, 내부 문서, 메시징 도구, 브라우저, 빌드 시스템, 그리고 고객 맞춤형 데이터로 들어가는 경로가 될 수 있습니다. 만약 개발자들이 보안 팀이나 플랫폼 팀이 검토하는 속도보다 더 빠르게 이러한 서버들을 추가할 수 있다면, 축하합니다. 당신은 운영 환경의 자격 증명 (production credentials)을 가진 브라우저 확장 프로그램을 재발명한 셈입니다.

Docker의 거버넌스 페이지는 샌드박스 (sandbox), 네트워크, 그리고 MCP 접근에 대한 중앙 제어를 언급하며, 정책 이벤트가 SIEM 및 컴플라이언스 (compliance) 시스템으로 내보내진다고 설명합니다. 제품의 세부 사항은 변할 것이고 다른 벤더들도 자신들만의 버전을 만들겠지만, 중요한 것은 그 형태입니다.

에이전트 도구에는 허용 목록 (allowlist)이 필요합니다. 소유권이 필요합니다. 검토가 필요합니다. 감사가 필요합니다. 민감한 시스템에 접근할 수 있는 것들에 대해서는 기본 거부 (default-deny) 원칙이 필요합니다.

개발자들이 무책임하기 때문이 아닙니다.

진지한 도구에는 진지한 경계가 필요하기 때문입니다.

노트북은 플랫폼 밖에 있지 않습니다

Docker의 주장 중 한 가지 미묘한 점은 많은 에이전트 작업이 개발자의 노트북에서 시작된다는 것입니다.

당연한 소리처럼 들리겠지만, 많은 기업 보안 논의는 여전히 실제 플랫폼이 CI나 클라우드에서 시작되는 것처럼 행동합니다. 노트북은 지저분한 전주곡처럼 취급됩니다. 공식적인 시스템은 나중에, 즉 풀 리퀘스트 이후, 빌드 이후, 배포 파이프라인이 깨어나서 배지를 다는 시점부터 시작된다고 간주됩니다.

에이전트는 그러한 사고 모델을 약화시킵니다.

만약 에이전트가 코드가 CI(지속적 통합)에 도달하기도 전에 저장소(repository)를 읽고, 로컬 도구(local tools)를 실행하며, 네트워크 서비스(network services)를 호출하고, 브라우저를 사용하며, MCP 서버와 상호작용할 수 있다면, 개발자의 머신은 이미 반자율적(semi-autonomous) 작업을 위한 실행 환경(execution environment)이 된 것입니다.

the boring platform path for scaling signals

이는 노트북 상의 에이전트 런타임(agent runtime)이 플랫폼 인벤토리(platform inventory)에 포함되어야 함을 의미합니다.

어떤 에이전트가 허용되는가? 어떤 샌드박스(sandboxes)를 사용하는가? 어떤 디렉토리(directories)를 마운트(mount)할 수 있는가? 어떤 네트워크 경로(network paths)에 도달할 수 있는가? 어떤 MCP 서버가 승인되었는가? 어떤 자격 증명(credentials)이 세션에 진입할 수 있는가? 무엇이 로그(log)로 남는가? 무엇이 보존되는가? 에이전트가 풀 리퀘스트(pull request)를 생성한 후 리뷰어는 무엇을 볼 수 있는가?

이것들은 생소한 AI 관련 질문들이 아닙니다.

이것들은 더 빠른 행위자가 등장한, 오래된 플랫폼 관련 질문들입니다.

증거 없는 자율성은 규모가 커진 느낌(vibes)일 뿐이다

에이전트 자율성의 가장 이상적인 형태는 "에이전트가 무언가를 수행했고, 그것이 괜찮기를 바라는 것"이 아닙니다.

가장 이상적인 형태는 "에이전트가 제한된 런타임(bounded runtime) 내에서, 승인된 도구(approved tools)를 사용하고, 가시적인 입출력(inputs and outputs)을 생성하며, 인간이 작업을 검토할 수 있을 만큼 충분한 증거(evidence)를 남기는 것"입니다.

그 증거는 단순히 코드 차이(code diff)여서는 안 됩니다.

차이점(diff)은 무엇이 변경되었는지는 알려줍니다. 하지만 에이전트가 읽지 말아야 할 파일을 읽었는지, 승인되지 않은 도구를 호출했는지, 수상한 패키지를 설치했는지, 의심스러운 소스에서 복사했는지, 혹은 아무도 예상하지 못한 네트워크 엔드포인트(network endpoint)에 접속했는지는 알려주지 않습니다.

에이전트가 생성한 작업의 경우, 해당 작업에 대한 출처(provenance)가 점점 더 중요해지기 시작합니다.

어디에서 실행되었는가? 어떤 이미지(image)나 환경(environment)이 사용되었는가? 어떤 도구들이 사용 가능했는가? 어떤 명령(commands)이 실행되었는가? 어떤 도메인(domains)에 접속했는가? 어떤 파일들이 마운트되었는가? 어떤 비밀 정보(secrets)가 노출되었는가? 어떤 정책 검사(policy checks)를 통과했는가? 어떤 것이 경고를 보냈는가? 어떤 것이 차단했는가?

우리는 이미 공급망 보안 (supply chain security)에서 이 교훈을 배웠습니다. 아티팩트 (artifact)만으로는 충분하지 않습니다. 결국 무엇이 그것을 빌드했는지, 어떤 입력값 (inputs)으로부터, 어떤 정책 (policy) 하에, 어떤 증명 (attestations)을 가지고 만들어졌는지 알고 싶어 하게 됩니다.

이제 에이전트 (Agents)도 그 빌드 이야기의 일부가 되었습니다.

핵심 결론 (the punchline)

에이전트 신뢰는 하나의 마법 같은 계층에서 오지 않을 것입니다.

더 나은 모델 (models)이 도움이 됩니다. 더 나은 프롬프트 (prompts)가 도움이 됩니다. 더 나은 리뷰 (reviews)가 도움이 됩니다. 하지만 지속 가능한 신뢰 경계 (trust boundary)는 런타임 (runtime)과 도구 경로 (tool path)에 존재할 것입니다: 샌드박스 (sandboxes), 네트워크 제어 (network controls), 파일 시스템 마운트 (filesystem mounts), MCP 거버넌스 (MCP governance), 자격 증명 범위 지정 (credential scoping), 감사 이벤트 (audit events), 그리고 검토 가능한 증거 (reviewable evidence) 등이 그것입니다.

이것은 AI의 화려한 측면이 아닙니다.

좋습니다.

화려한 측면은 데모 (demos)가 존재하는 곳입니다. 지루한 측면은 프로덕션 (production)이 생존하는 곳입니다.

실질적인 규칙은 간단합니다: 만약 에이전트가 개발자처럼 행동할 수 있다면, 그것을 개발자 환경 (developer environment)처럼 운영하십시오. 유용한 권한을 부여하되, 그 권한을 명시적으로 만드십시오. 빠르게 움직이게 하되, 경계 내부에서 움직이게 하십시오. 도구를 호출하게 하되, 조직이 방어할 의사가 있는 도구만 호출하게 하십시오.

프롬프트에게 런타임의 역할을 수행하라고 요구하지 마십시오.

프롬프트는 "조심해"라고 말할 수 있습니다.

런타임은 '조심하는 것'을 기본값 (default)으로 만들 수 있습니다.

그곳에서 신뢰가 실질적으로 변하기 시작합니다.

참고 문헌 (references)

• Docker Blog: AI Engineer World's Fair 2026: The Runtime Is Where Agent Trust Is Won
• Docker AI Governance
• arXiv: Runtime Governance for AI Agents: Policies on Paths
• arXiv: AgentTrust: Runtime Safety Evaluation and Interception for AI Agent Tool Use

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