RootrRootr

AI 코딩 에이전트한테 저장소 접근권한 주기 전에 체크할 것들.md

Published 7/14/2026

AI 코딩 에이전트한테 저장소 접근 권한 주기 전에 확인하면 좋은 것들

요즘 팀에서 AI 코딩 에이전트(코드 자동완성을 넘어서 저장소를 직접 읽고 커밋까지 하는 도구들) 하나쯤은 다 도입하고 있는데, 막상 "얘한테 우리 코드 얼마나 보여주는 거지?"는 의외로 확인 안 하고 넘어가는 경우가 많아요. 최근 있었던 사례 하나를 보면서, 도입 전에 체크하면 좋을 포인트들을 정리해봤어요.

무슨 일이 있었나

2026년 7월 12일, 한 독립 보안 연구자가 xAI의 코딩 에이전트 "Grok Build CLI"(버전 0.2.93)를 네트워크 레벨에서 직접 분석한 결과를 공개했어요. 요지는 이렇습니다.

  • 에이전트가 실제로 열어본 파일과 무관하게, 추적 중인 Git 저장소 전체와 커밋 히스토리가 통째로 번들 형태로 외부에 업로드되고 있었어요.
  • 연구자는 업로드된 번들을 다시 클론해서, 에이전트에게 "이 파일은 읽지 마"라고 명시적으로 지시했던 파일까지 그 안에서 복구해냈어요. 프롬프트 레벨의 지시는 실제 접근 통제가 아니었던 거죠.
  • 테스트용 .env 파일에 넣어둔 가짜 API_KEY, DB_PASSWORD 값도 마스킹 없이 그대로 전송되는 게 확인됐어요.
  • 규모도 상당했는데, 12GB 저장소 기준으로 73번에 걸쳐 5.10GB가 전송됐고, 이 "저장소 업로드용 채널"이 실제 모델과 대화하는 채널보다 2만 7,800배 많은 데이터를 실어 날랐다고 해요.
  • 업로드 목적지는 grok-code-session-traces라는 이름의 구글 클라우드 스토리지 버킷이었고, xAI는 그동안 "세션 중 코드베이스에서 나가는 데이터는 없다"고 광고해왔던 터라 실제 동작과 정면으로 배치됐어요.
  • 더 문제였던 건, 도구에 있던 "Improve the model"(모델 개선에 기여) 옵트아웃 토글을 꺼도 업로드가 멈추지 않았다는 점이에요. 서버 응답에는 여전히 trace_upload_enabled: true가 찍혀 나왔다고 합니다.
  • xAI는 보고서 공개 하루 만에 disable_codebase_upload: true라는 새 서버 플래그로 조용히 문제를 막았지만, 이 글을 쓰는 시점까지 공식 입장 발표나 기존에 수집된 데이터 삭제 여부에 대한 확인은 없었어요.

체크리스트로 정리하면

특정 벤더를 저격하려는 게 아니라, 어떤 AI 코딩 에이전트를 쓰든 계약·도입 전에 확인해두면 좋을 항목들이에요.

  1. "프롬프트로 하지 말라고 하면 안 되는" 게 아니라 "물리적으로 못 하게" 막혀 있는지. "이 파일은 읽지 마" 같은 지시는 보안 경계가 아니라 그냥 부탁이에요. 진짜 통제는 파일시스템 권한이나 샌드박스(예: Linux Landlock, seccomp, 컨테이너/마이크로VM 격리) 레벨에서 이뤄져야 해요.
  2. 비밀정보 파일은 애초에 에이전트 작업 디렉토리 밖에 두기. .env, 자격증명 파일들은 .gitignore에 넣는 것과 별개로, 에이전트가 물리적으로 접근할 수 있는 경로 자체에서 빼두는 게 안전해요.
  3. 마케팅 문구가 아니라 실제 네트워크 트래픽을 한 번은 직접 확인해보기. mitmproxy 같은 도구로 세션 하나를 캡처해서 "어디로, 뭐가, 얼마나" 나가는지 실측해보는 게 제일 확실해요. "안 보낸다"는 문구는 검증 전엔 그냥 문구예요.
  4. 필요한 파일만 접근하는 구조인지, 저장소 통째로 접근하는 구조인지. 아키텍처 문서나 기술 블로그에 이 부분이 구체적으로 설명돼 있는지 확인해보면 신뢰도를 가늠할 수 있어요.
  5. 옵트아웃/데이터 최소화 옵션이 실제로 작동한다는 검증이 있는지. 토글이 있다고 끝이 아니라, 그 토글을 껐을 때의 동작을 제3자가 검증한 적 있는지가 중요해요.
  6. 데이터 보관·삭제 정책이 계약서나 문서에 명시돼 있는지. "업로드된 적 있는 데이터는 언제, 어떻게 삭제되는가"가 문서화돼 있지 않다면 물어보고 답을 받아두는 게 좋아요.

참고로 OWASP도 2026년에 에이전트형 시스템을 겨냥한 "Agentic Security Initiative Top 10"을 별도로 발표했을 정도로, 이런 유형의 리스크가 이제 일반적인 체크리스트 항목이 되어가는 분위기예요. 도구 하나 새로 붙일 때마다 위 6가지만 훑어봐도 이런 사고를 사전에 많이 걸러낼 수 있을 것 같아요.

출처: 레딧 r/LocalLLaMA에서 공유된 논의를 계기로 관련 보도들을 정리했습니다.