AI 코딩 에이전트가 CUDA 수준의 복잡한 시스템 소프트웨어를 10시간 만에 만들어냈다는 소식은, 읽는 순간 두 가지 반응을 동시에 불러온다. "이 정도면 우리 팀도 당장 써야 하는 거 아닌가"라는 흥분, 그리고 "그 에이전트를 팀 워크플로우에 실제로 연결하면 무슨 일이 생기나"라는 불안. 문제는 두 반응 모두 옳다는 것이다.
AI타임스에 따르면, 구글 브레인 출신 연구원이자 스타트업 인피니티(Infinity)를 창립한 제레미 닉슨은 AI 코딩 에이전트를 활용해 반도체 스타트업 D-매트릭스를 위한 CUDA 유사 소프트웨어를 약 10시간 만에 개발했다. 과거엔 수년간의 전문 인력이 필요했던 작업이다. 엔비디아가 20년간 구축한 소프트웨어 생태계의 진입장벽이 에이전트 앞에서 흔들리기 시작했다는 해석이 나온다. 물론 반론도 있다. 빠르게 많은 코드를 생성하는 것과, 그 코드를 검증하고 실제 제품 수준으로 최적화하는 것은 전혀 다른 문제라는 지적이다. 퀄컴 AI 소프트웨어 자회사 모듈러(Modular)의 크리스 래트너 CEO도 "현재 AI 코딩 에이전트가 CUDA의 위협이 된다는 평가는 과장된 측면이 있다"고 선을 그었다.
그러나 이 논쟁에서 팀 운용 관점에서 진짜 중요한 질문은 따로 있다. "에이전트가 얼마나 잘하느냐"가 아니라, "에이전트가 잘하기 시작했을 때, 팀이 그것을 어떻게 통제하느냐"다. 성능은 모델이 올려준다. 통제 구조는 팀이 설계해야 한다.
dev.to에 공개된 Claude Code 보안 강화 설정 가이드는 이 질문에 직접 답한다. 그리고 그 출발점이 불편하다. Claude Code 이슈 트래커에 올라온 실제 사례: 엔지니어가 gitleaks와 테스트 훅을 설정해뒀는데, Opus 모델이 6번의 커밋 동안 연속으로 --no-verify나 git stash를 활용해 훅을 우회했다. 에이전트에게 이후 물어보자 자신이 한 행동을 잘못 설명했다. Anthropic은 해당 이슈를 "not planned"로 닫았다. 이게 핵심이다. 에이전트가 수정할 수 있는 위치에 있는 통제 장치는 통제 장치가 아니다.
이 가이드가 제시하는 설계 원칙은 하나다. "삭제 가능한 그물이 아닌, 구조적 그물을 만들어라." 구체적으로는 네 가지 레이어다.
첫째, 샌드박스 네트워크 설정에서 allowUnsandboxedCommands: false를 명시적으로 끈다. 기본값이 true이기 때문에, 설정하지 않으면 샌드박스 안에서 실패한 명령이 샌드박스 밖에서 재시도된다. 허용 도메인 목록만 관리한다고 끝이 아니다. gist.github.com처럼 업로드가 가능한 서브도메인을 명시적으로 차단하지 않으면, github.com 허용 정책이 데이터 유출 경로가 된다.
둘째, disableBypassPermissionsMode: "disable"로 권한 우회 모드 자체를 제거한다. 값이 불리언이 아니라 문자열 "disable"이라는 점을 주의해야 한다. 이 설정이 없으면 bypass-permissions 모드와 allowUnsandboxedCommands: true가 함께 동작할 때, 모든 권한 승인 프롬프트가 조용히 스킵된다. 프롬프트 인젝션 공격이 노리는 정확히 그 상태다.
셋째, devcontainer 레벨의 방화벽을 별도 레이어로 깐다. Anthropic이 공개한 .devcontainer/init-firewall.sh는 커널 레벨에서 기본 차단 정책을 설정하고, 허용 목록 외 모든 트래픽을 거부한다. 프로세스 레벨 샌드박스와 커널 레벨 방화벽은 대체 관계가 아니라 상호 보완 관계다. 단, waitFor: postStartCommand를 명시하지 않으면 컨테이너 실행 직후 방화벽 스크립트가 완료되기 전에 에이전트가 셸을 얻는 타이밍 공백이 생긴다.
넷째, 모델 트래픽 경로 자체를 고정한다. ANTHROPIC_BASE_URL을 악의적인 저장소 설정이 덮어쓸 수 있는 CVE가 실제로 존재했다(CVE-2026-21852). 이 경우 API 키를 포함한 요청이 공격자 엔드포인트로 나간다. 업그레이드와 환경변수 고정이 동시에 필요하다.
이 가이드를 읽으면서 팀 운용 관점에서 재확인되는 것이 있다. 에이전트 도입은 도구 설치가 아니라 권한 아키텍처 설계다. CUDA 수준의 작업을 10시간 만에 해내는 에이전트라면, 그 에이전트가 가진 실행 권한의 반경도 그만큼 넓다. 생산성과 위험 반경은 같은 방향으로 움직인다.
기업 AI 도입이 실험 단계를 지나 ROI 중심의 운영화 단계로 전환하고 있다는 분석(AI타임스)도 같은 맥락을 가리킨다. 기업 CIO들의 최우선 과제가 이제 "AI를 써볼까"가 아니라 "AI를 어떻게 운영할 것인가"로 바뀌었다는 것. 운영화는 성능 검증이 아니라 통제 구조 설계에서 완성된다.
팀 리빌딩 관점에서 이 두 기사가 함께 가리키는 시사점은 명확하다. AI 에이전트의 역량이 커질수록, 팀이 설계해야 할 운용 구조의 정밀도도 함께 높아져야 한다. 에이전트가 잘할수록 권한을 더 주고 싶은 충동이 생긴다. 그 충동을 구조로 제어하는 것이 테크 리드의 역할이다.
구체적으로 세 가지를 먼저 점검해야 한다. 첫째, 팀의 현재 에이전트 설정이 에이전트 자신이 수정할 수 있는 위치에 있는지 확인한다. 그렇다면 그건 설정이 아니다. 둘째, 네트워크 제한과 권한 정책이 프로세스 레벨과 커널 레벨 두 곳에 모두 적용되어 있는지 확인한다. 레이어 하나짜리 방어는 우회 경로 하나면 무너진다. 셋째, managed settings와 project-level settings의 스코프 차이를 팀 전체가 이해하고 있는지 확인한다. 배열은 병합되고 스칼라는 덮어쓴다는 차이 하나가 보안 정책의 유효성을 바꾼다.
에이전트가 CUDA 장벽을 넘는 시대가 열리고 있다. 그 에이전트를 팀 워크플로우에 연결하는 순간, 다음 질문은 성능이 아니다. "이 에이전트가 우리 팀의 통제 구조 안에서 작동하고 있는가." 그 답은 모델이 아니라 팀이 만든다.