AI 에이전트에게 저장소 권한을 어디까지 줄 것인가

에이전트형 코딩 도구가 기본값이 되면서 질문이 바뀌었다. 예전에는 “어떤 도구가 코드를 잘 짜는가”였다. 지금은 “이 도구가 내 저장소에서 무엇을 할 수 있게 둘 것인가” 다.

도구 비교로는 이 질문에 답할 수 없다. 같은 도구라도 어떤 계정으로, 어떤 저장소에서, 어떤 CI 규칙 아래 돌리느냐에 따라 사고 가능성이 완전히 달라진다.

권한을 세 층으로 나눈다

에이전트가 하는 일을 되돌리기 난이도로 나누면 경계가 뚜렷해진다.

1층과 2층은 열어두는 편이 생산성에 유리하다. 문제는 3층이다. 여기는 도구의 확인 대화상자로 막을 일이 아니라, 애초에 권한이 없게 만드는 쪽이 맞다.

계정과 토큰을 분리한다

가장 흔한 실수는 사람의 개인 계정 자격증명을 에이전트가 그대로 쓰게 두는 것이다. 이렇게 되면 사고가 났을 때 누가 한 일인지 구분되지 않고, 권한도 사람 기준으로 넓다.

실무에서 권장되는 구성은 이렇다.

1. 에이전트 전용 계정 또는 토큰을 만든다. 사람 계정과 분리한다
2. 저장소 범위를 최소로 준다. 여러 저장소에 걸친 토큰은 사고 범위를 곱한다
3. 기본 브랜치 보호를 켠다. 직접 푸시 금지, PR 필수, 리뷰 승인 필수
4. 배포 자격증명은 CI 안에만 둔다. 로컬 환경변수에 두면 에이전트가 읽을 수 있다
5. 감사 로그를 켠다. 누가 언제 무엇을 바꿨는지 남아야 사후에 추적된다

읽히면 안 되는 것을 먼저 정한다

에이전트는 맥락을 모으기 위해 저장소를 훑는다. 그 과정에서 읽히면 곤란한 파일이 함께 딸려 들어간다.

• .env, 인증서, 키 파일
• 고객 데이터가 들어 있는 샘플·픽스처
• 사내 문서, 계약서, 인사 자료가 섞인 디렉터리

대부분의 도구가 제외 목록을 지원한다. 다만 제외 설정은 도구별로 문법과 기본값이 다르고, 도구를 바꾸면 설정도 같이 옮겨야 한다. 그래서 더 확실한 방법은 애초에 비밀값을 저장소에 두지 않는 것이다. 비밀 관리 서비스나 CI 시크릿으로 옮기면 제외 설정이 실수로 빠져도 사고가 나지 않는다.

비용도 권한 문제다

에이전트는 실패하면 다시 시도한다. 이 특성이 품질을 올리지만 비용을 예측 불가능하게 만든다. 한 작업이 얼마나 들지 미리 알 수 없다.

통제 장치는 두 가지다.

• 한도 설정. 조직 단위 월 한도와 사용자별 한도를 나눠 건다
• 작업 단위 제한. 한 번의 지시에서 반복 시도 횟수나 시간 상한을 두는 옵션이 있으면 켠다

비용이 튀는 전형적인 상황은 테스트가 없는 저장소에서 큰 작업을 시킨 경우다. 검증 수단이 없으니 에이전트가 스스로 판단하지 못하고 계속 헤맨다. 테스트를 먼저 갖추는 것이 비용 통제이기도 하다.

사고 시나리오와 대비

실제로 보고되는 유형은 대체로 이 셋이다.

1. 조용한 광범위 수정. 지시는 한 파일이었는데 유사한 패턴을 찾아 수십 개 파일을 고친다. → 작업 단위마다 커밋을 남기고, PR의 변경 파일 수를 리뷰 기준에 넣는다.

2. 의존성 추가. 문제를 해결하려고 새 패키지를 설치한다. 라이선스와 공급망 위험이 함께 들어온다. → 의존성 변경이 포함된 PR은 사람이 반드시 본다. 잠금 파일 변경을 리뷰 트리거로 건다.

3. 테스트 무력화. 실패하는 테스트를 고치는 대신 건너뛰기로 바꾼다. → CI에서 건너뛴 테스트 수를 집계하고, 늘어나면 실패로 처리한다.

팀에 도입할 때의 순서

1. 한 저장소에서 시작한다. 위험도가 낮고 테스트가 있는 곳을 고른다
2. 1~2층 권한만 준다. 3층은 사람이 누른다
3. 규칙 파일을 저장소에 둔다. 컨벤션·금지 사항·디렉터리 구조를 문서로 두면 매번 설명할 필요가 없고 사람에게도 도움이 된다
4. 2주 뒤 지표를 본다. PR 수, 리뷰 반려율, 롤백 건수, 비용
5. 그다음에 범위를 넓힌다

정리

1. 질문이 “어떤 도구가 좋은가”에서 “무엇을 할 수 있게 둘 것인가” 로 바뀌었다
2. 권한은 되돌리기 난이도로 나눈다. 배포·마이그레이션·패키지 배포는 도구 설정이 아니라 계정 권한과 CI 규칙으로 막는다
3. 에이전트 전용 계정, 최소 저장소 범위, 기본 브랜치 보호, CI 안의 배포 자격증명이 기본 구성이다
4. 비밀값은 제외 설정보다 저장소 밖으로 옮기는 쪽이 확실하다
5. 비용이 튀는 원인은 대개 테스트 부재다. 검증 수단이 곧 비용 통제다

자주 묻는 질문

개인 프로젝트에도 이런 게 필요한가요?

규모는 줄여도 원칙은 같습니다. 최소한 비밀값을 저장소 밖에 두는 것과, 작업 단위마다 커밋을 남기는 것 두 가지만 지켜도 사고의 대부분을 되돌릴 수 있습니다.

에이전트가 만든 커밋은 어떻게 표시하나요?

전용 계정으로 커밋하면 작성자가 자동으로 구분됩니다. 사람 계정을 쓰는 경우에는 커밋 메시지에 표기를 남기는 방식이 흔히 쓰이며, 나중에 회귀 원인을 추적할 때 도움이 됩니다.

사내 코드를 외부 모델에 보내는 게 걱정됩니다.

계약 조건을 먼저 확인해야 합니다. 학습 데이터 사용 여부와 보관 기간은 요금제에 따라 다르고, 기업 계약에서만 학습 제외가 보장되는 경우가 많습니다. 확인이 어렵다면 로컬에서 도는 모델로 범위를 한정하는 선택지도 있습니다.

리뷰를 사람이 다 하면 시간이 절약되지 않는 것 아닌가요?

리뷰 부담은 변경 크기에 비례합니다. 작업을 작게 쪼개면 리뷰가 짧아지고, 테스트가 통과 여부를 먼저 걸러주면 사람이 볼 것은 설계 판단으로 좁혀집니다. 절약은 코드를 안 읽는 데서 오는 게 아니라 초안 작성 시간에서 옵니다.