CodeMender CLI sandbox 운영법: AI 보안 에이전트가 로컬 명령을 실행할 때의 기본값

CodeMender CLI가 sandbox enabled by default로 바뀌었습니다. AI 보안 에이전트가 취약점을 찾고, 빌드하고, 테스트하고, 패치까지 제안하는 흐름에서는 이 기본값 하나가 큽니다. 에이전트가 로컬 명령을 실행할 수 있다면 기본은 자유 실행이 아니라 격리 실행이어야 합니다.

검색 의도: CodeMender CLI sandbox, AI code security agent, agent command execution safety를 검색하는 개발자. 이 글은 기능 소개보다 운영자가 무엇을 바꿔야 하는지에 초점을 맞춥니다. 발표 문서의 표현을 그대로 반복하지 않고, 개발팀이 이번 주에 점검할 항목으로 분해했습니다.

지금 개발팀이 봐야 하는 변화

보안 에이전트는 일반 코드 생성 도구보다 권한이 넓어지기 쉽습니다. 취약점을 검증하려면 빌드 명령을 돌려야 하고, PoC를 실행해야 하고, 테스트를 반복해야 합니다. 이 과정에서 잘못된 스크립트가 파일을 덮어쓰거나, 네트워크로 데이터를 보내거나, 개발자의 로컬 환경을 망가뜨릴 수 있습니다. CodeMender의 sandbox 기본값 변경은 AI 에이전트 운영에서 "안전장치가 옵션"이던 단계를 지나 "안전장치가 기본"으로 가는 흐름입니다.

릴리스 노트에서 확인한 핵심 근거는 Google Cloud Gemini Enterprise Agent Platform 릴리스 노트의 2026년 8월 12일 CodeMender CLI 항목입니다. CLI가 명령을 process-level sandbox 안에서 기본 실행하도록 바뀌었고, config.yaml, --sandbox=false, --unrestricted로 동작을 조정할 수 있다고 설명합니다입니다. 특히 실무 관점에서는 "쓸 수 있다"보다 "관측하고, 제한하고, 실패했을 때 복구할 수 있다"가 중요합니다. AI 기능은 데모에서는 잘 보이지만 운영에서는 비용, 지연 시간, 권한, 감사 로그, 장애 전파가 같이 움직입니다. 이번 업데이트도 결국 그 다섯 가지 중 어디를 줄여주는지로 판단해야 합니다.

기존 운영 방식에서 막히던 지점

AI 에이전트나 LLM 기능을 제품에 붙이면 초반에는 프롬프트 품질에만 관심이 쏠립니다. 하지만 트래픽이 붙는 순간 병목은 다른 곳에서 나옵니다. 첫째, 어떤 요청이 정책상 허용됐고 어떤 요청이 거절됐는지 추적하기 어렵습니다. 둘째, 모델 호출 비용이 기능 단위로 분리되지 않습니다. 셋째, 운영자가 장애를 발견했을 때 원인이 프롬프트인지 정책 엔진인지 외부 도구인지 구분하기 어렵습니다.

많은 팀이 이 문제를 로그 한 줄과 대시보드 스크린샷으로 때웁니다. 그 방식은 PoC에서는 충분하지만, 고객 데이터가 들어오는 순간 부족합니다. 예를 들어 상담 에이전트가 내부 문서를 검색하고, 결제 정책을 확인하고, 사용자에게 답변하는 흐름을 생각해보면 한 요청 안에 최소 3개의 판단 지점이 생깁니다. 어느 지점에서 차단됐는지, 차단이 정상인지, 차단 때문에 사용자 경험이 깨졌는지까지 봐야 합니다.

설계할 때 분리해야 할 4가지 계층

1계층은 파일 시스템 격리입니다. 에이전트가 읽을 수 있는 경로와 쓸 수 있는 경로를 나눕니다. 2계층은 프로세스 격리입니다. 빌드, 테스트, PoC 실행을 sandbox 안에서 돌려 예기치 않은 side effect를 줄입니다. 3계층은 네트워크 통제입니다. 취약점 검증 과정에서 외부 호출이 필요한지, 내부 mock으로 충분한지 구분합니다. 4계층은 승인 흐름입니다. sandbox를 끄는 --sandbox=false나 --unrestricted는 편의 옵션이 아니라 예외 승인 옵션으로 다뤄야 합니다.

계층을 나누면 좋은 점은 책임 소재가 명확해진다는 것입니다. 모델 품질 문제를 정책 문제로 오해하지 않고, 비용 폭증을 사용자 증가로만 해석하지 않습니다. 지연 시간이 늘었을 때도 모델 응답이 느린지, 정책 평가가 느린지, 외부 도구 호출이 느린지 따로 볼 수 있습니다.

적용 순서: 크게 바꾸지 말고 한 경로부터 고정하기

팀에 바로 적용하려면 먼저 프로젝트별 위험도를 나눕니다. 오픈소스 라이브러리 스캔, 내부 백엔드, 결제·인증 코드, 고객 데이터 처리 코드의 기준은 달라야 합니다. 기본 템플릿은 sandbox on, 네트워크 제한, write 제한, 테스트 명령 allowlist입니다. 빌드가 sandbox에서 실패하는 프로젝트는 실패 원인을 기록한 뒤 필요한 권한만 추가합니다. sandbox를 꺼야 할 때는 PR 코멘트나 보안 티켓에 사유를 남깁니다.

처음부터 전 요청에 적용하면 팀이 원인 분석을 못 합니다. 가장 위험도가 높은 기능 하나를 정하고, 그 경로의 입력·정책·모델·도구·응답을 끝까지 이어서 봐야 합니다. 추천 순서는 관리자 기능, 고객 데이터 조회, 결제/권한 변경, 외부 발송 기능입니다. 단순 요약이나 내부 검색보다 실패 비용이 큰 곳부터 붙이는 편이 낫습니다.

흔한 실수와 피하는 법

첫 번째 실수는 정책을 프롬프트로만 해결하려는 것입니다. "민감 정보는 말하지 마" 같은 지시문은 필요하지만 충분하지 않습니다. 정책은 코드, 설정, 로그, 알림으로 남아야 합니다. 두 번째 실수는 성공 응답만 샘플링하는 것입니다. 운영에서는 거절, 타임아웃, 재시도, 사용자가 중간에 나간 케이스가 더 중요합니다. 세 번째 실수는 비용을 월말 청구서에서만 확인하는 것입니다. AI 비용은 기능 릴리스 직후 24시간 안에 봐야 합니다.

네 번째 실수는 권한을 넓게 열어두는 것입니다. 에이전트가 파일을 읽거나 명령을 실행하거나 외부 API를 호출할 수 있다면 기본값은 차단이어야 합니다. 필요한 도구만 허용하고, 허용 사유를 남기고, 위험 도구는 별도 승인 경로를 둬야 합니다. 마지막 실수는 검증 없이 모델만 교체하는 것입니다. 같은 프롬프트라도 모델이 바뀌면 거절률, 응답 길이, 도구 호출 횟수, 비용이 모두 달라질 수 있습니다.

팀 안에서 합의해야 할 운영 기준

운영 기준은 추상적인 원칙보다 숫자로 정하는 편이 낫습니다. 예를 들어 정책 평가 p95 지연 시간은 300ms 이하, 차단율은 정상 트래픽 기준 1~3% 범위, 실패한 모델 호출의 자동 재시도는 1회까지만 허용하는 식입니다. 숫자는 서비스마다 다르지만, 숫자가 없으면 회고가 감으로 흐릅니다.

또한 배포 전 체크와 배포 후 체크를 나눠야 합니다. 배포 전에는 테스트셋, 권한 설정, 롤백 경로를 봅니다. 배포 후에는 실제 사용자 로그, 비용, 오류율, 차단율을 봅니다. 이 둘을 섞으면 "테스트는 통과했는데 왜 장애가 났는지"를 설명하기 어려워집니다.

오늘 바로 할 수 있는 체크리스트

• CodeMender 실행 설정에서 sandbox 기본값을 명시한다.
• --unrestricted 사용은 CI나 PR 로그에 남기고, 개인 판단으로 상시 사용하지 않는다.
• 테스트 명령, 빌드 명령, 패키지 설치 명령을 allowlist로 분리한다.
• 에이전트가 생성한 patch는 적용 전 diff와 test result를 같이 본다.
• 취약점 PoC 실행은 네트워크 차단 환경에서 먼저 검증한다.
• sandbox 때문에 실패한 케이스를 모아 프로젝트별 예외 설정으로 관리한다.

정리하면, 이번 변화의 핵심은 AI 기능을 더 많이 쓰는 것이 아니라 더 안전하게 운영하는 것입니다. 기능을 켜기 전에 관측 기준을 먼저 만들고, 위험한 요청부터 좁게 적용하고, 비용과 거절률을 함께 봐야 합니다. 이 순서만 지켜도 AI 기능이 데모에서 운영으로 넘어갈 때 생기는 사고를 꽤 줄일 수 있습니다.