에이전트의 힘은 권한에서 나온다
AI 모델이 아무리 뛰어나도 도구를 쓸 수 없다면 컴퓨터 안의 세상을 바꿀 수 없다.
반대로:
- 파일 읽기 / 쓰기
- 터미널 명령어 실행
- 브라우저 제어
- 이메일 발송
- 데이터베이스 접근
- 결제 및 외부 API 연동
권한을 부여하면 할 수 있는 일이 폭발적으로 늘어난다. 동시에 사고가 났을 때 피해 범위도 그만큼 커진다.
최소 권한의 원칙 (Principle of Least Privilege)
처음 사용하는 에이전트에게 내 PC 전체나 회사 서버 루트 권한을 맡길 이유는 없다.
- 프로젝트 코딩 작업이라면 해당 프로젝트 폴더만 연결한다.
- 문서 정리라면 전용 작업용 폴더만 넘겨준다.
- 메일이나 로그를 분석할 때는 가능한 '읽기 전용(Read-only)' 권한부터 부여한다.
권한 레벨별 위험도
| 레벨 | 권한 유형 | 대표 행위 | 위험도 및 권장 안전장치 |
|---|---|---|---|
| Level 1 | 읽기 (Read) | 파일 조회, 웹 검색, 코드 분석 | 낮음 (사내 기밀 유출 여부만 주의) |
| Level 2 | 쓰기 (Write) | 파일 수정, 새 문서 생성 | 중간 (작업 전 Git 커밋 또는 백업 필수) |
| Level 3 | 실행 (Execute) | 터미널 명령 실행, 스크립트 가동 | 높음 (명령어 허용 화이트리스트 적용) |
| Level 4 | 외부 행동 (External) | 메일 발송, 결제, 배포, DB 삭제 | 매우 높음 (반드시 사람의 1회용 수동 승인) |
승인 팝업은 귀찮지만 생명줄이다
에이전트를 쓰다 보면 Allow, Approve, Accept 팝업이 계속 떠서 귀찮아질 수 있다. 모든 승인을 자동으로 켜두면 속도는 매우 빨라지지만, 에이전트의 환각이나 오작동에 대한 방어선이 사라진다.
따라서 작업 성격에 따라 차등 적용해야 한다.
- 개발/실험 환경 (Git 백업 완비): 빌드·테스트·코드 수정 등은 자동 승인 허용
- 운영 환경/개인정보/결제/이메일: 모든 외부 영향 행위에 대해 수동 승인 유지
권한 부여 전 스스로 던져야 할 핵심 질문
"이 AI 에이전트가 지금 완전히 틀린 판단을 내렸을 때, 최악의 경우 어디까지 망가질 수 있는가?"
그 파괴 범위를 사람이 감당할 수 있는 크기로 좁히는 것이 바로 권한 설계다.
그래서 무엇을 다르게 할 것인가
- 에이전트에게 작업을 맡길 때는 항상 "최소한의 폴더와 최소한의 실행 권한"만 준다.
- 외부 전송, 결제, 삭제 명령은 절대로 자동 승인으로 켜두지 않는다.