AI 에이전트에게 어디까지 맡길 것인가 — 매일 돌려보는 팀의 실전 규칙 7가지

며칠 전 r/devops에 올라온 스레드 하나가 계속 머릿속에 남았다. 질문은 단순했다: "레포 안에서 명령어를

실행하는 AI 에이전트에게 안전선을 어디에 그을 것인가?" (원문 스레드)

댓글 28개가 달렸는데, 다들 방향은 비슷했지만 선을 긋는 지점이 조금씩 달랐다. 몇 개만 추려보면:

패키지 설치가 CI yaml 수정보다 더 위험하다는 의견이 있었다. CI 설정을 잘못 고치면 빌드가
깨지고 눈에 바로 띄지만, 패키지 설치는 타이포스쿼팅(오타 노린 악성 패키지)이나 프롬프트 인젝션으로
에이전트가 속아서 악성 코드를 그대로 설치해버릴 수 있다는 지적이었다.
"유닛테스트를 벗어나는 명령은 전부 승인을 요구해야 한다"는 더 보수적인 의견도 있었다. 느려지는
건 감수하더라도, 에이전트가 실수로 DB를 날리는 것보다는 낫다는 논리다.
"사람이 짰든 LLM이 짰든 코드리뷰는 통과해야 한다"는 의견도 많았다. 코드/README/CI 스크립트를
작성하는 것까지는 괜찮지만, 테스트 환경이라도 에이전트가 스스로 배포까지 해버리는 건 안 된다는
입장.
가장 명확하게 선을 그은 댓글은 "워킹트리 밖에서 코드 실행 방식을 바꾸는 것"을 기준으로 삼았다.
CI 설정, Dockerfile, 패키지 설정, env 로딩, scripts/ 밑 셸스크립트처럼 "지금 이 저장소를 어떻게
실행할지"를 바꾸는 파일들은 워킹트리 밖의 효과를 낸다는 것.

우리도 실제로 AI 에이전트 여러 개를 같은 레포에서 매일 동시에 돌리고 있다. 그러다 보니 이 스레드의

논의가 남 얘기가 아니라 매일 마주치는 문제였다. 우리가 실제로 쓰고 있는 규칙 7가지를 정리해봤다.

1. 효과가 워킹트리 안에 머무는 일은 자동 허용한다

코드 수정, 테스트 실행, 로컬 빌드처럼 결과가 그 저장소 디렉토리 밖으로 안 나가는 작업은 에이전트가

바로 실행하게 둔다. 잘못돼도 git diff로 되돌리면 그만이고, 사람이 매번 확인할 이유가 없다. 여기서

막으면 에이전트를 쓰는 의미 자체가 없어진다.

배포, CI 설정 변경, 패키지 설치, env 변수 로딩처럼 효과가 저장소 밖(실제 서버, 외부 레지스트리,

운영 환경)으로 나가는 작업이 레딧 스레드에서 공통으로 지적한 위험 지점이다. 이런 건 에이전트가

스크립트나 설정 파일을 작성하는 것까지는 맡기되, 실제로 그걸 실행하는 버튼은 사람이 누른다. 코드

리뷰와 똑같은 이유다 — 짠 사람이 사람이든 에이전트든, 실행 전에 누군가는 봐야 한다.

우리는 배포 브랜치를 트렁크와 분리해두고, 거기로 push가 들어가면 blue/green 배포 파이프라인이

돌지만 반드시 승인을 거치게 만들어놨다. 에이전트가 아무리 확신을 가지고 "이제 배포해도 될 것 같다"고

판단해도, 그 판단과 실제 운영 반영 사이에 사람이 한 번 서 있는 구조다. 이 한 단계가 없으면 사소한

착각 하나가 바로 사용자에게 노출된다.

여러 에이전트가 같은 레포에서 동시에 작업할 때 제일 위험한 순간은 "누가 뭘 커밋했는지 뒤섞이는

것"이다. 그래서 git add -A처럼 전체를 쓸어 담는 커밋은 금지하고 자기가 건드린 파일만 커밋하게

한다. 에이전트 하나당 브랜치 하나를 쓰게 하고, 공유 브랜치에는 force push를 못 하게 막는다. 다른

에이전트가 지금 뭘 하고 있는지 항상 알 수 있는 건 아니기 때문에, 애초에 서로의 작업 범위가 겹치지

않게 만드는 게 제일 확실하다.

스키마를 바로 반영하는 지름길(예: 마이그레이션 없이 스키마를 바로 밀어넣는 명령)은 에이전트가 쓸 수

없게 막아둔다. 마이그레이션 파일을 거치면 변경 이력이 남고, 사람이 리뷰할 수 있고, 문제가 생기면

되돌릴 방법이 있다. 지름길은 그 순간엔 편해도 되돌릴 방법이 없다는 게 진짜 문제다.

권한을 코드로 막는 것보다 확실한 방법은, 애초에 그 권한 자체를 에이전트가 접근할 수 있는 환경에

놓지 않는 것이다. 에이전트가 실수로든 속아서든 프로덕션 자격증명을 쓸 수 있는 상황 자체를 만들지

않으면, 위에 나온 규칙들이 뚫려도 최악의 시나리오로는 안 간다.

이건 태도에 가깝다. "이 에이전트 믿을 만한가"를 판단하려고 하지 말고, 매번 나온 결과물(diff, PR,

로그)을 사람이 하던 방식 그대로 리뷰하면 된다. 에이전트를 신뢰의 대상으로 삼는 순간 검증을 건너뛰게

되고, 그게 사고로 이어진다. 결과물만 보면 에이전트가 몇 개든, 무슨 모델을 쓰든 리뷰 기준이 흔들리지

않는다.

레딧 스레드의 결론과 크게 다르지 않다. 워킹트리 안이냐 밖이냐로 자동/승인을 가르고, 밖으로 나가는

일일수록 사람이 한 번 더 보는 구조를 만드는 것 — 이게 여러 에이전트를 매일 굴리면서 지금까지 사고

없이 버틴 이유다.