Mozilla AI Agent Infrastructure, 모델 판단보다 규칙을 우선하다
Mozilla AI는 코딩 에이전트에 관한 핵심 전제에 이의를 제기했다. 더 나은 모델 판단만으로는 위임된 소프트웨어 작업을 안전하게 만들 수 없다는 것이다.
에이전트가 리포지토리를 검사하고, 코드를 수정하며, 테스트를 실행하고, 풀 리퀘스트를 준비할 권한을 얻는 시점에 Mozilla AI의 에이전트 인프라 주장이 나왔다. 이러한 기능은 몇 시간 걸리던 작업을 몇 분으로 단축할 수 있다. 동시에 확률적 시스템에 지속적인 결과를 낳는 작업에 대한 접근 권한을 부여한다.
Mozilla AI의 에이전트 인프라 논지는 경쟁 구도를 역량 대 역량에서 지침 대 강제 가능한 통제로 바꾼다. AGENTS.md 파일은 에이전트가 해야 할 일을 알려줄 수 있다. 하지만 절대 해서는 안 되는 행동을 막을 수 있는 것은 인프라뿐이다.
이 구분은 에이전트 자율성을 확대하는 모든 조직에 압박을 가한다. OpenAI, Anthropic, Google, GitHub 및 독립 개발자들은 서로 다른 에이전트 경험을 제공한다. 그러나 모든 배포는 결국 같은 질문에 맞닥뜨린다. 모델이 규칙을 오해했을 때에도 무엇이 유지되는가?
Mozilla AI Agent Infrastructure가 바꾸는 것
Mozilla AI는 에이전트 논의를 모델 지능에서 모든 모델 결정 주변의 시스템으로 옮기고 있다.
코딩 에이전트는 더 이상 채팅 인터페이스로만 작동하지 않는다. 코드베이스를 검색하고, 여러 파일을 수정하고, 셸 명령을 실행하며, 테스트 스위트를 돌리고, 제안 변경 사항을 구성할 수 있다. 일부 시스템은 개발자가 다른 작업을 처리하는 동안에도 계속 작업할 수 있다.
이처럼 넓어진 범위는 인프라를 구현 세부 사항이 아니라 제품의 일부로 만든다. 채팅 창의 잘못된 답변은 한 종류의 위험을 만든다. 리포지토리, 네트워크 또는 자격 증명 접근 권한을 가진 잘못된 명령은 또 다른 위험을 만든다.
Mozilla AI의 개입이 중요한 이유는 팀이 종종 하나로 섞는 세 가지 책임을 분리하기 때문이다. 지침은 바람직한 행동을 설명한다. 모델은 그 지침을 해석한다. 인프라는 어떤 행동이 기술적으로 가능한지 결정한다.
이 구분은 단순하게 들리지만, 많은 에이전트 배포는 이 위계를 뒤집는다. 먼저 광범위한 접근 권한을 부여하고, 이후 모델에 자연어 규칙을 통해 자제를 요구한다. 이 설계는 모델을 작업자이자 자체적인 주요 통제 시스템으로 만든다.
리포지토리 지침은 기능 브랜치에서 직접 게시하지 말라고 명시할 수 있다. 인증 코드를 변경하기 전에는 승인을 요구할 수 있다. 특정 디렉터리 밖의 파일을 읽지 못하도록 금지할 수도 있다.
이러한 문구는 에이전트가 이를 올바르게 읽고, 해석하고, 우선순위를 둘 때 행동을 개선한다. 하지만 운영체제 경계, 네트워크 정책 또는 승인 게이트를 만들지는 않는다. 모델은 여전히 작성된 규칙을 위반하는 작업을 요청할 수 있다.
널리 채택된 에이전트 지침 형식은 프로젝트 맥락을 위한 유용한 관례를 제공한다. 해당 공개 사이트는 AGENTS.md를 빌드 명령, 테스트 지침, 규칙 및 보안 고려 사항을 위한 예측 가능한 위치로 설명한다. 또한 6만 개가 넘는 오픈소스 프로젝트에서의 도입을 보고한다.
이러한 도입은 이식 가능한 지침이 중요한 이유를 보여준다. 팀은 모든 코딩 제품마다 같은 리포지토리 가이드를 다시 작성해서는 안 된다. 공유 형식은 규칙이 에이전트 간에 이동하고 코드 옆에서 계속 보이게 한다.
그러나 이식성은 산문을 강제 수단으로 바꾸지 않는다. Markdown은 셸, 클라우드 계정, 패키지 레지스트리 또는 프로덕션 데이터베이스에 대한 권한이 없다. 이를 읽는 모델에는 영향을 미치지만, 런타임은 여전히 접근 가능한 세계를 통제한다.
따라서 Mozilla AI는 누락된 계층을 지적하고 있다. 에이전트 배포에는 모델 루프 밖의 통제가 필요하며, 이곳에서는 잘못된 해석이 스스로에게 예외를 조용히 부여할 수 없다.
그렇다고 AGENTS.md의 가치가 줄어드는 것은 아니다. 오히려 파일의 역할을 더 명확하게 한다. 지침은 의도를 전달해야 하며, 인프라는 그 의도 주위의 경계를 강제해야 한다.
실무적 전환은 크다. 팀들은 더 나은 추론이 더 안전한 자율성으로 가는 길이라고 여겨 왔다. Mozilla AI는 신뢰할 수 있는 자율성은 추론이 때때로 실패한다는 가정에서 시작한다고 주장한다.
코딩 에이전트는 제안을 부수 효과로 전환한다
에이전트가 완료할 수 있는 작업이 많아질수록, 최종 안전 경계로서 올바른 판단에 의존하는 것은 받아들이기 어려워진다.
전통적인 코드 어시스턴트는 주로 사람이 검토할 텍스트를 제안했다. 개발자는 제안을 삽입할지, 명령을 실행할지, 변경 사항을 업스트림으로 보낼지 결정했다. 이러한 인간의 행동은 자연스러운 점검 지점을 형성했다.
에이전트형 도구는 이러한 점검 지점을 압축한다. 단일 작업 할당으로 파일 탐색, 의존성 설치, 코드 생성, 테스트 실행 및 리포지토리 작업이 촉발될 수 있다. 각 단계는 다음 모델 결정에 영향을 주는 새로운 맥락을 만든다.
이 루프가 유용한 이유는 소프트웨어 작업이 하나의 프롬프트와 하나의 답변에 좀처럼 들어맞지 않기 때문이다. 에이전트는 결과를 관찰하고, 가정을 수정하며, 다른 접근법을 시도해야 한다. 같은 루프는 초기 오류도 증폭시킨다.
실패하는 통합 테스트를 수정하라는 요청을 받은 에이전트를 생각해 보자. 환경 파일을 검사하고, 서비스를 실행하며, 의존성을 업데이트하고, 스냅샷을 다시 생성할 수 있다. 모호한 지침은 의도한 테스트 범위를 훨씬 넘어서게 할 수 있다.
이 실패에 악의적인 행동이 필요한 것은 아니다. 에이전트는 파괴적인 정리 명령이 일상적이라고 추론할 수 있다. 테스트 자격 증명을 일회용으로 해석할 수 있다. 이슈, 의존성 또는 웹페이지에서 가져온 텍스트를 신뢰할 수도 있다.
프롬프트 인젝션은 마지막 시나리오를 특히 중요하게 만든다. 에이전트는 처리하도록 요청받은 콘텐츠 안에서 적대적인 지침을 마주할 수 있다. 이후 모델은 작업을 계속하면서 작업 데이터와 명령을 구분해야 한다.
자연어 가이드는 도움이 되지만, 모델은 여전히 다른 자연어를 신뢰할 수 있는지 결정하는 구성 요소다. 이는 최종 경계를 두기에 불안정한 위치다.
실행 인프라는 결과를 제한할 수 있다. OpenAI의 샌드박스 아키텍처는 신뢰할 수 있는 하니스와 모델 지시 명령이 실행되는 환경을 분리한다. 하니스는 실행 컨테이너 밖에서 승인, 추적, 복구 및 상태를 관리할 수 있다.
이 분리는 더 넓은 메커니즘을 보여준다. 에이전트는 조직이 가진 모든 자격 증명이나 리소스를 자동으로 상속하지 않고도 환경 안에서 작업할 수 있다. 인프라는 경계를 넘는 것을 중재한다.
문서 업데이트를 맡은 코딩 에이전트에게는 패키지 게시 자격 증명이 필요하지 않아야 한다. 하나의 서비스를 수정하는 에이전트가 관련 없는 리포지토리에 자동으로 접근해서도 안 된다. 테스트 작성 작업에 프로덕션 데이터베이스 권한이 따라와서는 안 된다.
이는 프롬프트 작성 결정이 아니라 역량 결정이다. 역량이란 하나의 디렉터리에 쓰기 권한을 주거나 승인된 하나의 엔드포인트를 호출하도록 하는 등 런타임이 허용하는 행동이다. 좋은 인프라는 현재 작업에 따라 역량을 부여한다.
이 압력은 우선 플랫폼 및 보안 팀에 가해진다. 개발자는 자율성이 생산성 향상을 만들기 때문에 에이전트가 더 적은 감독 아래 행동하기를 원한다. 보안 팀은 줄어든 감독이 무제한 권한이 되지 않도록 보장해야 한다.
이는 벤더에도 적용된다. 매끄러운 에이전트 인터페이스는 취약한 운영 통제를 가릴 수 있다. 구매자는 벤치마크 결과를 넘어 시스템이 신원, 자격 증명, 승인, 로그, 재시도 및 복구를 어떻게 처리하는지 물어야 한다.
같은 문제는 개인 개발자에게도 영향을 준다. 로컬 에이전트는 한 대의 노트북에서 실행되기 때문에 제한된 것처럼 보일 수 있다. 그러나 그 기기에는 소스 코드, 브라우저 세션, 클라우드 자격 증명, 개인 문서 및 서명 키가 있을 수 있다.
에이전트가 의미 있는 피해를 일으키는 데 관리자 접근 권한은 필요하지 않다. 작업에 필요한 것보다 더 큰 권한을 가진 자격 증명 하나면 충분하다. 인프라는 이러한 불일치를 만들기 어렵게 해야 한다.
이 때문에 이 소식은 단지 책임 있는 AI를 다시 요구하는 데 그치지 않는다. Mozilla AI는 책임을 모델 행동에서 시스템 설계로 옮기고 있다. 이는 조직이 검사하고 테스트할 수 있는 구성 요소에 책임을 부과한다.
AGENTS.md는 규칙을 설명하지만 강제할 수는 없다
이제 핵심 갈등은 분명하다. 지침 파일은 인간의 의도를 표현하지만, 런타임 통제는 에이전트가 실제로 무엇을 할 수 있는지 결정한다.
AGENTS.md는 실제 협업 문제를 해결한다. 코딩 에이전트에는 명령, 리포지토리 규칙, 검증 요구 사항 및 로컬 경고가 필요하다. 이러한 맥락을 코드 가까이에 두면 가시성, 버전 관리 및 재사용성이 높아진다.
이 형식은 팀이 대규모 리포지토리 안에서 더 좁은 범위의 지침을 정의할 수 있게도 한다. 서비스마다 리포지토리 루트와 다른 테스트 명령이나 제한을 둘 수 있다. 이는 인간이 이미 사용하는 계층형 문서화와 닮아 있다.
그러나 모든 지침은 여전히 모델 해석을 거친다. 에이전트는 관련 파일을 찾고, 겹치는 규칙을 해결하며, 현재 작업에 적용하고, 긴 실행 과정에서 이를 기억해야 한다.
이 사슬의 어느 지점에서든 실패하면 규칙은 약해질 수 있다. 파일이 불완전할 수 있다. 맥락이 잘릴 수 있다. 중첩된 지침이 루트 지침과 충돌할 수 있다. 모델이 예외를 지나치게 광범위하게 일반화할 수도 있다.
완벽하게 지침을 따르더라도 모든 문제를 해결할 수는 없다. 규칙은 패키지를 게시하기 전에 승인을 받으라고 말할 수 있다. 하지만 에이전트에는 여전히 신뢰할 수 있는 승인 메커니즘과 승인 권한을 가진 신원이 필요하다.
승인이 맥락 속의 또 다른 메시지로만 존재한다면 신뢰할 수 없는 콘텐츠가 이를 모방할 수 있다. 더 강력한 시스템은 승인을 모델이 만들어낼 수 없는 외부 상태로 표현한다. 런타임은 작업을 실행하기 전에 그 상태를 확인한다.
같은 원칙은 지출 한도에도 적용된다. 에이전트에게 토큰을 절약하라고 말하는 것은 유용한 지침이다. 제어 플레인에서 강제되는 예산은 루프가 예상보다 오래 실행될 때도 계속 유효하다.
감사 가능성은 또 다른 한계를 드러낸다. 지침은 에이전트에게 선택의 이유를 설명하라고 요구할 수 있다. 하지만 그 설명이 도구 입력, 권한 상태, 파일 변경, 재시도 또는 거부된 작업의 완전한 기록이 되는 것은 아니다.
신뢰할 수 있는 감사 추적은 에이전트의 서술 밖에서 발생하는 이벤트를 포착해야 한다. 어떤 신원이 작업을 요청했는지, 어떤 정책이 평가됐는지, 어떤 입력이 도구에 도달했는지, 어떤 결과가 반환됐는지를 보여줘야 한다.
기록에는 실패도 보존되어야 한다. 허용된 경로를 찾기 전에 금지된 작업을 세 번 시도한 에이전트는 즉시 허용된 경로를 선택한 에이전트와 다른 이야기를 들려준다. 최종 출력만으로는 그 차이가 숨겨진다.
이는 사고 발생 시 중요하다. 팀은 에이전트가 무엇을 보았고 그 시점에 어떤 권한을 가지고 있었는지 재구성해야 한다. 이후 정책, 프롬프트 또는 자격 증명이 변경됐다면 현재 문서만으로는 충분하지 않다.
따라서 인프라는 작업을 특정 실행, 정책 버전, 도구 버전 및 승인 상태에 연결해야 한다. 이는 이후 검토가 기억이나 재구성된 채팅 기록에 덜 의존하게 한다.
로그는 엔지니어링 개선도 지원한다. 팀은 반복적으로 개입이 필요한 명령, 오탐을 만드는 정책, 예상 범위를 초과하는 작업을 식별할 수 있다. 이러한 패턴은 더 좁은 권한과 더 나은 워크플로를 이끄는 데 활용될 수 있다.
개발자에게는 여전히 잘 작성된 지침이 필요하다. 목표는 인간의 의도를 경직된 정책으로 대체하는 것이 아니다. 많은 소프트웨어 결정에는 파일시스템 규칙으로 포착할 수 없는 맥락이 필요하다.
더 나은 설계는 각 계층에 적절한 역할을 부여한다. AGENTS.md는 에이전트에게 프로젝트가 작동하는 방식을 알려준다. 정책 계층은 제안된 작업이 해당 작업에 허용된 범위에 맞는지 결정한다.
샌드박스는 실행에 노출되는 자원을 제한한다. 승인 서비스는 중대한 예외를 처리한다. 감사 시스템은 결정과 그 결과를 기록한다.
이 구성 요소들이 함께 작동하면 모델을 교체해도 규칙은 유지된다. 팀은 다른 벤더의 프롬프트 형식 안에서 가장 중요한 경계를 다시 구축하지 않고도 에이전트를 바꿀 수 있다.
이러한 지속성은 Mozilla AI의 주장에서 핵심적이다. 모델은 자주 바뀔 것이다. 반면 리포지토리 소유권, 컴플라이언스 의무, 프로덕션 위험은 훨씬 더 오래 지속된다.
제어 플레인이 실질적인 안전 메커니즘이 된다
신뢰할 수 있는 에이전트 인프라는 모델의 요청과 모든 중대한 도구 작업 사이에 강제 가능한 정책을 둔다.
제어 플레인은 접근 권한, 정책, 라우팅, 예산, 운영 상태를 관리하는 신뢰 계층이다. 모델은 작업을 제안할 수 있지만, 실행 여부와 실행 방식은 제어 플레인이 결정한다.
이 아키텍처는 신원에서 시작된다. 모든 에이전트 실행에는 인간 운영자 및 다른 자동화 프로세스와 구별되는 신원이 필요하다. 공유 자격 증명은 책임 소재 파악을 어렵게 하고 권한 철회를 부정확하게 만든다.
다음 요건은 최소 권한 원칙이다. 각 작업에는 필요한 파일, 명령어, 서비스, 네트워크 대상만 부여된다. 권한은 이후 실행에도 계속 남아 있기보다 작업 종료와 함께 만료되어야 한다.
OpenAI의 sandbox security guidance는 격리된 워크로드, 제한된 아웃바운드 트래픽, 분리된 자격 증명, 서드파티 서비스에 대한 중개 접근을 권장한다. 이러한 통제 장치는 모델의 의도와 독립적으로 작동한다.
중개 자격 증명은 특히 유용하다. 실행 환경은 재사용 가능한 비밀 정보를 보지 않고도 승인된 요청을 보낼 수 있다. 신뢰할 수 있는 프록시는 허용된 대상에 대해서만 자격 증명을 제공한다.
이 설계는 우발적 노출의 가치를 낮춘다. 생성된 코드가 자신의 환경을 출력하더라도 장기 프로덕션 키가 나타날 필요는 없다. 권한 철회 역시 모든 워크스페이스 내부가 아니라 브로커에서 이뤄진다.
도구 중개는 또 다른 집행 지점을 제공한다. 인프라는 인수를 검증하고, 위험한 경로를 거부하며, 요청률을 제한하고, 특정 작업에 승인을 요구할 수 있다.
Mozilla AI는 mcpd policy plugins를 통해 이러한 패턴을 탐색해 왔다. Mozilla는 인증, 검증, 속도 제한, 로깅을 에이전트와 도구 서버 사이에 배치할 수 있는 기능으로 설명한다.
이 배치가 중요한 이유는 Model Context Protocol 서버가 파일, 데이터베이스, 외부 애플리케이션 전반의 작업을 노출할 수 있기 때문이다. 중앙 중개 계층은 각 에이전트가 이를 재현할 것이라 신뢰하지 않고도 일관된 정책을 적용할 수 있다.
성숙한 제어 플레인은 상태도 관리한다. 에이전트 워크플로는 일부 작업을 완료한 뒤 성공을 기록하기 전에 실패할 수 있다. 전체 작업을 무작정 재시도하면 외부 부작용이 중복될 수 있다.
인프라는 어떤 단계가 완료됐는지, 어떤 단계는 안전하게 재시도할 수 있는지, 어떤 단계는 조정이 필요한지 파악해야 한다. 풀 리퀘스트 생성 호출, 결제 지시 또는 고객 메시지는 로컬 파일 읽기처럼 항상 반복할 수 있는 작업이 아니다.
사람의 승인은 매 단계 뒤가 아니라 선별된 경계에 배치되어야 한다. 지속적인 승인 요청은 위임의 가치를 상당 부분 없앤다. 반대로 승인이 전혀 없으면 중대한 결정이 전적으로 모델 루프 안에 남게 된다.
유용한 중간 지점은 위험 기반 에스컬레이션이다. 리포지토리 읽기는 자동으로 진행될 수 있다. 임시 브랜치 내 쓰기도 가능하다. 하지만 게시, 배포, 권한 변경 또는 고객 연락에는 명시적 승인이 필요할 수 있다.
정책은 작업을 둘러싼 맥락을 검사해야 한다. 명령어는 격리된 테스트 환경에서는 허용될 수 있지만 프로덕션 환경에서는 금지될 수 있다. 네트워크 요청은 문서화 목적이라면 허용되지만 알 수 없는 엔드포인트에는 차단될 수 있다.
예산에도 유사한 집행이 필요하다. 여러 하위 에이전트를 조율하는 에이전트는 한 사람이 하나의 채팅을 지켜보는 것보다 더 빠르게 비용을 발생시킬 수 있다. 제어 플레인은 작업, 팀, 제공업체 또는 결과별로 상한을 설정할 수 있다.
Mozilla AI의 open control plane은 이러한 거버넌스 논의를 모델 라우팅과 연결한다. Otari는 제공업체 전반의 라우팅, 예산, 접근 통제, 배포, 장애 조치를 위한 계층으로 제시된다.
라우팅은 비용 최적화에만 그치지 않는다. 작업마다 서로 다른 프라이버시 경계, 지연 시간 목표 또는 모델 기능이 필요할 수 있다. 인프라는 이러한 선택을 애플리케이션 코드 전반에 내장하는 대신 일관되게 적용할 수 있다.
이 접근 방식은 이식성도 개선한다. 조직은 정책 로직, 과거 추적 기록 또는 운영 통제를 포기하지 않고 모델을 교체할 수 있다. 에이전트는 조직이 소유한 시스템 안의 하나의 구성 요소가 된다.
엔지니어링 팀에는 이것이 조직 지식을 보존할 수 있다. 검색 가능한 technical knowledge base는 아키텍처 결정과 로컬 문서를 유지할 수 있다. 런타임 정책은 여전히 에이전트가 그 지식을 어떻게 사용하는지 통제해야 한다.
핵심은 분리다. 지식은 모델에 정보를 제공한다. 정책은 행동을 제한한다. 감사 기록은 발생한 일을 남긴다. 복구는 미완료 작업을 처리한다.
어느 한 구성 요소도 에이전트를 신뢰할 수 있게 만들지는 못한다. 제어 플레인은 이들을 조율해 한 번의 잘못된 판단이 전체 결과를 결정하지 않도록 한다.
개방형 인프라는 통제를 제공하지만, 자동으로 안전해지지는 않는다
에이전트 스택을 소유하면 검사 가능성과 이식성은 향상되지만, 공개된 코드만으로 운영 위험이 사라지지는 않는다.
Mozilla AI는 인프라 통제를 개방성과 연결한다. 이 연결은 이해할 만하다. 조직은 한 벤더의 서비스 경계 뒤에만 존재하는 제어 시스템을 완전히 검사, 수정 또는 보존할 수 없다.
개방형 인프라는 종속을 줄일 수 있다. 팀은 모델 제공업체를 바꾸면서도 정책을 유지할 수 있다. 집행 코드를 검토하고, 통합 기능을 추가하며, 민감한 구성 요소를 자신들이 통제하는 환경에 배포할 수 있다.
또한 위험을 감당하는 조직 가까이에 거버넌스를 둘 수 있다. 병원, 은행, 공공기관 또는 소프트웨어 기업에는 서로 다른 승인 규칙과 보존 정책이 필요할 수 있다. 하나의 호스팅된 기본값이 모든 의무를 대변할 수는 없다.
그러나 소유는 책임을 이전한다. 자체 호스팅 제어 플레인에는 보안 업데이트, 접근 권한 검토, 백업, 모니터링, 검증된 복구가 필요하다. 오래된 공개 구성 요소는 새로운 취약점이 될 수 있다.
투명성이 올바른 구성을 보장하지는 않는다. 팀은 느슨한 기본값, 공유 자격 증명, 불완전한 로깅 또는 제한 없는 네트워크 접근을 가진 검사 가능한 소프트웨어를 배포할 수 있다. 소스는 공개되어 있어도 배포 환경은 여전히 안전하지 않을 수 있다.
로그에는 자체적인 절충점도 있다. 풍부한 추적 기록은 조사에 도움이 되지만 독점 코드, 개인정보, 프롬프트, 도구 결과를 포착할 수 있다. 모든 것을 무기한 보관하는 일은 프라이버시와 최소화 목표에 충돌할 수 있다.
팀은 명시적인 보존 경계를 정해야 한다. 감사 시스템이 모든 민감한 입력의 영구 사본이 되지 않으면서도 책임을 입증하기에 충분한 정보를 기록해야 한다.
정책 복잡성도 또 다른 위험이다. 방대한 규칙 집합은 이해하기 어려워질 수 있다. 중복된 예외는 허점을 만들 수 있고, 지나치게 엄격한 통제는 개발자를 승인받지 않은 도구로 몰아갈 수 있다.
해답은 단순히 더 많은 정책이 아니다. 팀에는 구체적인 위험에 연결된 작고 검증 가능한 통제가 필요하다. 각 규칙에는 담당자, 이유, 검증 방법이 있어야 한다.
모델의 행동 역시 여전히 중요하다. 인프라는 금지된 작업을 차단할 수 있지만, 유용한 코드를 보장할 수는 없다. 에이전트는 권한 범위 안에 머물면서도 잘못된 구현을 만들거나 중요한 요구사항을 놓칠 수 있다.
따라서 테스트와 사람의 검토는 여전히 시스템의 일부다. 비공개 또는 독립적으로 유지되는 평가 사례는 눈에 보이는 검사만 최적화하는 에이전트를 감지하는 데 도움이 될 수 있다. 코드 소유권 규칙은 민감한 변경을 적절한 검토자에게 보낼 수 있다.
이것이 Mozilla AI 에이전트 인프라 논지의 회의적인 한계다. 더 나은 인프라는 실패를 억제하고, 증거를 보존하며, 복구를 가능하게 한다. 불확실한 추론을 결정론적 소프트웨어 엔지니어링으로 바꾸지는 않는다.
조직은 감사 로그를 안전의 증거로 간주하는 것도 경계해야 한다. 상세한 기록은 사고가 정확히 어떻게 발생했는지를 보여줄 수 있다. 사고를 예방하려면 작업 이전에 강제 가능한 통제와 검증된 정책이 필요하다.
제어 플레인을 누가 통제하는지에 관한 거버넌스 문제도 있다. 중앙 정책은 조직을 보호할 수 있지만, 불투명한 내부 권한 체계를 만들 수도 있다. 개발자는 왜 작업이 거부됐는지와 예외가 어떻게 작동하는지를 볼 수 있어야 한다.
개방형 구현은 이러한 검토에 도움이 되지만, 프로세스도 중요하다. 정책 변경은 검토, 테스트, 버전 관리를 거쳐야 한다. 긴급 재정의는 만료되어야 하며 기록에서도 계속 확인할 수 있어야 한다.
가장 강력한 접근 방식은 개방성을 보안 레이블이 아니라 소유 모델로 다룬다. 조직은 시스템을 검사하고 수정할 수 있는 능력을 얻는다. 동시에 이를 잘 운영할 책임도 받아들인다.
이러한 절충은 자동 안전을 약속하는 것보다 더 신뢰할 수 있다. 신뢰할 수 있는 위임은 하나의 제품 기능이 아니라 엔지니어링 규율에서 나온다는 점을 인정하기 때문이다.
Mozilla의 인프라 논지를 시험할 세 가지 신호
다음 시험대는 에이전트 플랫폼이 인프라 원칙을 일상 업무를 늦추지 않으면서 개발자가 검증할 수 있는 기본값으로 바꾸는지 여부다.
첫 번째 신호는 작업 범위 권한의 확산이다. 코딩 에이전트가 명시된 리포지토리, 디렉터리, 명령어, 네트워크 대상에 대해 임시 접근 권한을 받는지 지켜봐야 한다. 벤더가 다른 곳에서 안전을 홍보하더라도 광범위한 머신 수준 권한은 실제로 Mozilla AI의 주장을 약화시킬 것이다.
두 번째 신호는 증거의 품질이다. 플랫폼은 도구 호출, 승인, 정책 결정, 파일 변경, 재시도 상태에 관한 지속적인 기록을 제공해야 한다. 대화 기록만으로는 작업 당시 어떤 권한이 존재했는지 알 수 없다.
세 번째 신호는 이식성이다. 팀은 모델이나 배포 환경을 바꿀 때도 정책, 추적 기록, 워크플로 상태를 유지할 수 있어야 한다. 거버넌스가 하나의 제공업체에 계속 묶여 있다면 모델 선택은 여전히 주변 시스템을 통제하게 된다.
이 신호들은 서로를 강화한다. 범위가 제한된 권한은 가능한 피해를 줄인다. 감사 기록은 그 경계가 작동했는지를 드러낸다. 이식성은 다음 모델 마이그레이션 과정에서 그 경계가 사라지는 일을 막는다.
개발자는 일상 워크플로의 마찰도 지켜봐야 한다. 저위험 작업을 끊임없이 중단시키는 제어 계층은 저항에 부딪힐 것이다. 정책 결정을 숨기는 계층은 신뢰하거나 디버그하기 어려울 것이다.
성공적인 시스템은 안전한 작업을 일상적인 절차로 만들고 예외적인 작업은 명시적으로 처리할 것이다. 에이전트가 제한된 환경 안에서 읽고, 추론하고, 테스트하고, 변경을 준비하도록 할 것이다. 외부적이거나 되돌릴 수 없는 결과를 수반하는 작업에서는 멈출 것이다.
이러한 기능이 표준 제품 기대치가 될 때 Mozilla AI의 에이전트 인프라 주장은 강화될 것이다. 통제 장치는 선택 사항인 대시보드나 프롬프트 템플릿에 머물러 있는데 에이전트가 계속 권한을 얻는다면 그 주장은 약화될 것이다.
지금 코딩 에이전트를 도입하는 팀이 당장 물어야 할 질문은 최신 모델의 점수가 더 높은지가 아니다. 에이전트가 어디까지 접근할 수 있는지, 어떤 작업에 승인이 필요한지, 모든 결정을 나중에 재구성할 수 있는지를 물어야 한다. 그런 다음 이러한 보호 장치가 조직에 속하는지, 아니면 벤더와 함께 사라지는지를 물어야 한다. 더 나은 AI는 계속 유용하겠지만, 그 지능을 책임 있게 위임할 수 있는지는 인프라가 결정한다.
