coding agent에게 작업을 맡길 때 가장 불안한 순간은 실패할 때보다 성공했다고 말했는데 예상보다 많은 파일이 바뀌었을 때였다.
AI는 목표를 달성하기 위해 사람이 생각하지 않은 경로를 선택할 수 있다. 그 유연함이 장점이지만, 작은 수정에서는 오히려 위험해진다.
그래서 작업 자동화에 write-path guard를 두기 시작했다.
“테스트가 통과했다”만으로 성공이라고 할 수 없었다
예를 들어 기존 테스트 파일의 문법 오류 하나를 고치는 작업에서 agent가 새 테스트 파일을 만든 적이 있다.
새 테스트가 프로젝트에 도움이 될 수도 있다. 하지만 이번 작업에서 요청한 것은 새 테스트 설계가 아니었다.
이런 변경을 계속 허용하면 작은 수정 하나가 새로운 코드와 규칙을 남기고, 다음 agent는 그 결과를 다시 기존 설계의 일부로 받아들인다. 몇 번만 반복해도 원래 기획과 현재 코드의 차이가 커진다.
작업 전에 허용 경로를 정한다
방법은 단순했다.
작업을 시작하기 전에 이번 task가 수정할 수 있는 파일이나 디렉터리를 정한다.
예를 들면 다음처럼 생각할 수 있다.
- 수정 허용:
tests/shoppingList.test.ts - 읽기 허용: 프로젝트 전체
- 새 파일 생성: 금지
- 설정 파일 변경: 금지
agent는 프로젝트 전체를 읽을 수 있어야 영향 범위를 이해할 수 있지만, 읽을 수 있다고 해서 모두 쓸 수 있어야 하는 것은 아니다.
작업 후 Git diff를 규칙과 비교한다
agent가 끝났다고 보고하면 바로 성공 처리하지 않는다.
먼저 실제 변경 파일 목록을 확인하고, 허용된 경로와 비교한다. 예상하지 않은 파일이 하나라도 포함되면 해당 실행을 실패로 처리한다.
이 방식의 장점은 특정 모델의 행동을 믿지 않아도 된다는 것이다. 모델이 바뀌어도 동일한 규칙으로 검증할 수 있다.
원복도 자동화의 일부다
범위를 벗어난 변경을 발견하고 사람에게 “확인해 주세요”만 보내면 자동화가 금방 멈춘다.
그래서 명확하게 잘못된 범위 변경은 원래 상태로 되돌리고, 다음 fallback이 같은 task를 다시 시도할 수 있게 만들었다.
이때 중요한 것은 원복 기준이 명확해야 한다는 점이다. agent가 만든 모든 변경을 무조건 지우는 게 아니라, task 시작 시점의 Git 상태를 기준으로 되돌린다.
큰 작업은 경로 제한을 넓게, 위험한 작업은 더 좁게
모든 작업을 파일 하나에 가둘 수는 없다.
새 기능처럼 여러 레이어를 바꿔야 하는 작업은 허용 범위가 넓어질 수밖에 없다. 대신 이런 작업은 먼저 영향 범위를 분석하고, 예상 변경 경로를 task에 명시한다.
반대로 오타 수정, 테스트 문법 수정, 특정 컴포넌트 스타일 변경처럼 범위가 명확한 작업은 최대한 좁게 제한한다.
AI Agent에게 필요한 건 자유와 경계 둘 다다
agent에게 너무 좁은 범위만 주면 문제를 제대로 해결하지 못한다. 반대로 저장소 전체 쓰기 권한을 항상 열어두면 작은 요청도 예상보다 크게 변할 수 있다.
내가 찾은 균형은 이랬다.
읽기는 넓게, 쓰기는 task에 필요한 만큼만.
모델의 성능이 좋아질수록 이런 guard가 필요 없어질 거라고 생각할 수도 있다. 하지만 자동화에서는 성능보다 재현성과 변경 통제가 더 중요할 때가 많았다.