6 분 소요

AI 에이전트를 파일시스템에 바로 풀어놓으면 왜 위험한가

AI 에이전트를 실제 작업에 붙이기 시작하면 처음에는 모델 성능, 툴 연결, 응답 속도 같은 요소가 더 눈에 들어온다. 어떤 모델이 코드를 더 잘 쓰는지, 어떤 작업기가 더 빠른지, 어떤 프롬프트가 더 안정적인지 같은 이야기다.

그런데 운영 쪽으로 조금만 들어가 보면 체감이 달라진다. 실제로 문제를 만드는 건 모델의 똑똑함보다 어디까지 접근하게 둘 것인가, 어디서 멈추게 만들 것인가, 무엇을 기본값으로 막아 둘 것인가 쪽인 경우가 많다.

특히 파일 읽기, 파일 수정, 셸 실행, Git 조작이 한 번에 가능한 에이전트라면 더 그렇다. 이때 “에이전트가 뭘 할 수 있나”보다 먼저 봐야 하는 건 에이전트가 어디까지 닿을 수 있나다.

최근 GeekNews와 Hacker News 쪽에서도 에이전트 운영을 다루는 글들이 계속 올라오고 있다. Codex 활용 사례, .claude/ 폴더 구조, 장기 실행 애플리케이션용 하네스 설계, 그리고 Stanford의 “Go hard on agents, not on your filesystem” 같은 글들이 공통으로 건드리는 지점도 결국 비슷하다. 에이전트 자체보다 경계와 운영 구조가 중요하다는 얘기다.

이 글에서는 왜 파일시스템 경계를 먼저 설계해야 하는지, 그리고 실전에서 최소한 어떤 선은 그어 두는 편이 좋은지 정리해 본다.

모델 성능보다 먼저 터지는 건 대개 경계 문제다

데모에서는 보통 이런 장면이 강조된다.

  • 에이전트가 저장소를 읽는다
  • 필요한 파일을 찾는다
  • 코드를 수정한다
  • 테스트를 돌린다
  • 커밋까지 만든다

여기까지만 보면 정말 편하다. 실제로도 생산성이 크게 올라간다.

하지만 운영 단계에서는 곧 다른 질문이 생긴다.

  • 잘못된 디렉터리에서 작업하면 어떻게 되나
  • 민감한 파일을 읽어도 되나
  • 홈 디렉터리 전체를 탐색해도 되나
  • 여러 저장소를 오가며 수정해도 되나
  • 긴 작업 중에 의도하지 않은 파일을 건드리면 누가 복구하나

이건 모델이 똑똑하냐의 문제가 아니다. 권한과 작업 공간 설계의 문제다.

내 기준으로 에이전트 운영의 사고는 대체로 두 종류다.

  1. 에이전트가 못 해서 생기는 문제
  2. 에이전트가 너무 많이 할 수 있어서 생기는 문제

두 번째가 보통 더 아프다. 첫 번째는 재시도나 검토로 고칠 여지가 있지만, 두 번째는 이미 손댄 범위가 넓어져서 복구 비용이 커지기 쉽다.

파일시스템은 가장 넓고 가장 조용한 권한이다

브라우저 자동화나 API 호출은 보통 대상이 비교적 명확하다. 어느 사이트를 열었는지, 어느 엔드포인트를 호출했는지, 어떤 채널에 메시지를 보냈는지가 눈에 보인다.

반면 파일시스템은 범위가 너무 넓다. 특히 에이전트가 셸까지 쓸 수 있으면 사실상 아래가 한 묶음이 된다.

  • 파일 읽기
  • 파일 쓰기
  • 디렉터리 탐색
  • 검색
  • Git 상태 변경
  • 빌드 산출물 생성
  • 삭제 또는 덮어쓰기

게다가 이 권한은 겉으로 크게 티가 안 난다. 메시지를 외부로 보낸 것도 아니고, 브라우저 탭이 튄 것도 아니어서 조용히 지나가기 쉽다. 그래서 더 위험하다.

예를 들어 아래 같은 실수는 생각보다 흔하다.

  • 현재 저장소가 아닌 상위 디렉터리에서 명령 실행
  • 임시 파일 정리 중 다른 파일까지 삭제
  • 잘못된 glob 패턴으로 여러 파일 일괄 수정
  • 생성 파일 경로를 잘못 잡아 기존 문서 덮어쓰기
  • 여러 repo가 섞인 workspace에서 엉뚱한 repo에 커밋

이런 건 “모델이 말을 이상하게 했다”보다 훨씬 골치 아프다.

그래서 필요한 건 똑똑한 모델보다 좁은 작업장이다

에이전트를 운영할 때 내가 더 선호하는 방향은 이렇다.

  • 가능한 한 작은 작업 디렉터리를 준다
  • 작업 목적에 맞는 전용 workspace를 준다
  • 장기 세션과 실험 세션을 분리한다
  • 민감한 파일이 있는 루트와 작업 루트를 섞지 않는다
  • destructive command는 기본적으로 좁은 범위에서만 허용한다

이건 에이전트를 못 믿어서가 아니라, 사람이 해도 필요한 기본 안전장치다. 숙련된 개발자도 잘못된 디렉터리에서 git add .를 치면 사고가 난다. 에이전트라고 예외일 리 없다.

에이전트 작업은 “능력”보다 “경계”가 먼저 설계돼야 한다

실전에서는 보통 아래 네 가지를 먼저 정하는 편이 좋다.

1. 어디서 작업할지

가장 먼저 정해야 할 건 작업 루트다.

  • 특정 repo 안에서만 작업할 것인지
  • 임시 작업 디렉터리에서 복사본으로 작업할 것인지
  • 여러 프로젝트를 동시에 볼 수 있게 둘 것인지

이게 안 정해져 있으면 나머지 안전장치가 다 약해진다. 예를 들어 PR 리뷰용 에이전트라면 원본 저장소 루트가 아니라 임시 디렉터리 클론본에서 먼저 작업하게 두는 편이 훨씬 안전하다.

2. 무엇을 읽게 할지

읽기 권한은 종종 가볍게 여겨지지만, 실제로는 민감한 정보 노출과 바로 연결된다.

예를 들면:

  • SSH 키
  • 개인 메모
  • API 키가 들어 있는 .env
  • 브라우저 프로필 또는 세션 관련 파일
  • 다른 프로젝트의 비공개 문서

에이전트가 파일을 읽을 수 있다는 건 단순히 분석이 가능하다는 뜻이 아니다. 맥락을 가져갈 수 있다는 뜻이다. 그래서 읽기 범위도 최소화하는 편이 낫다.

3. 무엇을 쓰게 할지

쓰기 권한은 더 직접적이다. 새 파일 생성만 허용할지, 기존 파일 수정까지 허용할지, 삭제는 금지할지 같은 선을 정해야 한다.

내가 보기에 기본값은 이쪽이 안전하다.

  • 생성은 비교적 쉽게 허용
  • 수정은 작업 루트 안에서만 허용
  • 삭제는 명시적 승인 또는 recoverable path 우선
  • 대량 변경은 diff 확인 전 단계에서 멈춤

특히 자동 포맷, 일괄 치환, 스캐폴딩, 코드모드 리팩터링 같은 작업은 범위가 예상보다 쉽게 커진다.

4. 언제 사람 검토를 끼울지

완전 자동화가 늘 좋은 건 아니다. 아래 같은 단계에는 사람이 한 번 끼는 게 비용 대비 효율이 좋다.

  • 외부 전송 직전
  • 삭제성 변경 직전
  • 많은 파일을 건드린 변경 직후
  • 다른 repo나 다른 디렉터리로 범위가 넓어질 때
  • 권한 상승이 필요할 때

이 검토 지점이 있어야 사고가 커지기 전에 멈출 수 있다.

파일시스템 경계가 약하면 프롬프트가 길어져도 소용이 없다

많은 경우 문제를 프롬프트로 해결하려고 한다.

예를 들어 이런 식이다.

  • “절대 홈 디렉터리 전체를 건드리지 마”
  • “현재 프로젝트 외 파일은 수정하지 마”
  • “삭제는 하지 마”
  • “민감한 파일은 읽지 마”

이런 문장은 분명 도움이 된다. 하지만 이건 정책 설명이지, 강제 경계는 아니다.

프롬프트에 금지사항이 아무리 길게 적혀 있어도, 실제 도구 권한이 넓게 열려 있으면 결국 모델 해석에 의존하게 된다. 그리고 반복 작업에서는 이 의존성이 언젠가 문제를 만든다.

그래서 내 기준으로는 순서가 이렇다.

  1. 도구와 작업 공간으로 물리적 경계를 먼저 만든다
  2. 그 위에 프롬프트로 의도를 보강한다
  3. 마지막으로 리뷰/승인 단계로 보수한다

프롬프트만으로 안전을 만들겠다는 접근은 오래 못 간다.

장기 실행 에이전트일수록 더 보수적으로 가야 한다

짧은 단발성 작업보다 장기 실행 에이전트가 더 까다로운 이유는 시간이 길어질수록 문맥이 흐려지고, 작업 범위가 넓어지기 쉽기 때문이다.

예를 들어 처음에는 문서 하나 수정이 목적이었는데, 중간에 다음 작업이 붙고, 또 다른 repo를 참고하고, 관련 스크립트를 실행하고, 로그 파일까지 읽기 시작하면 처음 의도보다 훨씬 넓은 권한을 사실상 사용하게 된다.

이럴수록 필요한 건 더 좋은 추론보다 작업을 좁게 유지하는 구조다.

  • 세션별 전용 작업 디렉터리
  • 하위 작업별 분리 실행
  • 긴 작업은 별도 러너로 분리
  • 완료 후 정리 가능한 임시 산출물 사용
  • 로그와 결과물 위치를 고정

즉 장기 실행 문제를 모델의 집중력 문제로만 보면 놓치는 게 많다. 운영 구조를 좁히는 편이 더 효과적인 경우가 많다.

내가 선호하는 최소 안전 원칙

거창한 보안 체계를 만들지 않아도, 아래 정도만 지켜도 체감 안정성은 꽤 올라간다.

원칙 1. 기본 작업장은 하나로 제한한다

에이전트마다 기본 workspace를 분리하고, 특별한 이유가 없으면 그 바깥은 안 보게 두는 편이 좋다.

원칙 2. 민감한 루트와 실험 루트를 섞지 않는다

개인 문서, 비밀 정보, 운영 설정 파일이 있는 곳과 실험용 작업 디렉터리를 같은 레벨에서 다루지 않는 편이 안전하다.

원칙 3. 대량 변경 전에 항상 중간 확인 지점을 둔다

검색-치환, 자동 포맷, 다중 파일 수정은 중간 diff 확인 없이 끝까지 가게 두지 않는 게 낫다.

원칙 4. 삭제보다 복구 가능한 경로를 우선한다

완전 삭제보다 휴지통, 백업, 브랜치 분리, 임시 디렉터리 활용처럼 되돌릴 수 있는 선택지를 먼저 둔다.

원칙 5. 외부 전송 권한은 파일 수정 권한과 분리해서 본다

파일을 읽을 수 있다고 해서 곧바로 외부로 보낼 수 있게 두는 건 다른 문제다. 읽기/수정과 송신은 별도 경계로 보는 편이 좋다.

결국 에이전트 운영은 샌드박싱의 현실 버전이다

요즘 에이전트 얘기를 하면 다들 모델 성능 경쟁에 먼저 시선이 간다. 물론 중요하다. 하지만 실제 운영 관점에서는 그보다 먼저 샌드박스를 어떻게 자르느냐, 작업장을 얼마나 좁게 유지하느냐, 사고가 났을 때 얼마나 빨리 되돌릴 수 있느냐가 더 오래 남는다.

잘 만든 에이전트 시스템은 단순히 많이 할 수 있는 시스템이 아니다. 할 수 있는 일을 명확히 제한하면서도 필요한 일은 끝낼 수 있는 시스템에 더 가깝다.

그래서 에이전트를 새로 붙일 때 내가 먼저 보는 질문은 이것들이다.

  • 이 에이전트는 어디서 작업하나
  • 어디까지 읽을 수 있나
  • 어디까지 쓸 수 있나
  • 어디서 사람 검토가 들어가나
  • 실수했을 때 얼마나 쉽게 되돌릴 수 있나

이 다섯 가지가 흐리면, 나머지 설계가 좋아도 운영은 금방 불안해진다.

마무리

AI 에이전트는 점점 더 많은 일을 대신할 수 있게 되고 있다. 그래서 더 중요한 건 능력을 계속 넓히는 것만이 아니라, 그 능력이 작동하는 경계를 선명하게 만드는 것이다.

정리하면 이렇다.

  • 파일시스템은 가장 넓고 조용한 권한이다
  • 사고는 종종 모델 부족보다 과한 권한에서 나온다
  • 프롬프트는 보조 수단이지 강제 경계가 아니다
  • 장기 실행 에이전트일수록 좁은 작업장이 중요하다
  • 좋은 운영은 높은 성능보다 좋은 경계에서 시작된다

에이전트를 실무에 계속 붙일 생각이라면, 다음 번에는 모델 비교표보다 먼저 작업 디렉터리, 읽기 범위, 쓰기 범위, 검토 지점부터 설계해 보는 편을 추천한다.

status: approved

댓글남기기