AI 에이전트 권한 설계: 읽기, 쓰기, 실행을 왜 나눠야 할까

1. 개요: 권한 설계는 곧 운영 설계다

많은 회사가 "AI가 답변한다"에서 "AI가 회사 도구를 쓴다"로 너무 빨리 넘어갑니다. 데모에서는 Notion을 열고, Google Drive를 검색하고, CRM 행을 수정하고, 이메일 초안을 만들고, 자동화 워크플로우를 실행하는 장면이 멋져 보입니다. 하지만 연결되는 도구가 하나 늘 때마다 위험의 모양도 바뀝니다.

OpenAI의 에이전트 안전 가이드는 MCP 도구를 사용할 때 읽기와 쓰기를 포함한 작업을 사용자가 검토하고 확인할 수 있도록 승인 기능을 켜두라고 설명합니다. OWASP 역시 과도한 권한, 과도한 자율성, 프롬프트 인젝션, 민감정보 노출을 LLM 및 에이전트 보안의 핵심 위험으로 봅니다.

실무적인 답은 건물 출입카드처럼 권한을 설계하는 것입니다. 방문자 카드는 로비만 열고, 직원 카드는 사무실을 열고, 재무 담당자 키는 결제 승인까지 열 수 있습니다. AI 에이전트도 회사 시스템에 닿기 전에 같은 방식의 분리가 필요합니다.

2. 쉬운 용어 정리: 권한, 범위, 역할, 로그

권한은 AI에게 주는 열쇠입니다. 어떤 열쇠는 한 방만 열고, 어떤 열쇠는 여러 방을 열고, 어떤 열쇠는 건물 전체를 엽니다. 범위는 그 열쇠가 어디까지 열 수 있는지, 어떤 행동까지 할 수 있는지를 정한 선입니다.

역할은 열쇠에 붙은 직무 이름입니다. 고객지원 초안 에이전트, 재무 검토 에이전트, 대표 보조 에이전트가 모두 같은 모델을 쓴다고 해서 같은 권한을 가져서는 안 됩니다.

최소 권한은 필요한 가장 작은 열쇠만 주는 원칙입니다. 정책을 요약하는 AI에게 정책 폴더 수정 권한은 필요 없습니다. 이메일 초안만 만드는 AI에게 실제 발송 권한은 필요 없습니다.

임시 인증은 만료 시간이 있는 대여 열쇠입니다. 영구 마스터키를 주는 대신, 한 작업이나 한 세션에만 짧게 쓸 수 있는 접근 권한을 주는 방식입니다.

감사 로그는 영수증이나 CCTV 기록에 가깝습니다. AI가 무엇을 읽었고, 무엇을 바꿨고, 어떤 도구를 호출했고, 누가 승인했는지 남기는 기록입니다.

• 읽기: AI가 정책 문서, 티켓, 회의록, 고객 기록 같은 정보를 볼 수 있는 권한.
• 쓰기: AI가 초안, 내부 메모, CRM 필드, 티켓 상태, 스프레드시트 행, 제안 문서를 만들거나 수정할 수 있는 권한.
• 실행: AI가 발송, 결제, 삭제, 게시, 서명, 주문, 초대, 외부 API 호출처럼 되돌리기 어렵거나 외부에 영향을 주는 행동을 할 수 있는 권한.
• MCP: AI 애플리케이션이 외부 데이터, 도구, 워크플로우에 연결되도록 해주는 표준 연결 방식.
• 사람 승인 게이트: AI가 멈추고 사람이 다음 행동을 확인하는 체크포인트.

3. 읽기 권한: 행동보다 지식 연결부터 시작한다

읽기 권한은 보통 가장 먼저 가치가 나는 단계입니다. 에이전트가 일반론이 아니라 회사 맥락을 바탕으로 답할 수 있게 해줍니다. SOP, 환불 정책, 제품 스펙, 과거 티켓, 온보딩 문서, 고객 이력, 회의록을 읽을 수 있기 때문입니다.

그렇다고 읽기 권한이 무해한 것은 아닙니다. OpenAI는 연결된 도구로 모델이 예상보다 많은 데이터를 공유할 수 있는 private data leakage 위험을 설명합니다. OWASP도 민감정보 노출을 LLM 애플리케이션의 핵심 위험으로 봅니다. 그래서 읽기에도 범위가 필요합니다.

실무 기준은 단순합니다. 그 역할의 신입 직원에게 보여줄 수 있는 것만 AI에게 먼저 보여주세요. 고객지원 AI는 고객 티켓과 정책을 읽어도 되지만, 급여, 대표 개인 메모, 비공개 투자 자료, 원본 비밀키까지 읽을 필요는 없습니다.

• 좋은 읽기 범위: 공개 정책, 승인된 SOP, 고객용 문서, 분류된 티켓, 제품 FAQ, 민감하지 않은 지식 노트.
• 위험한 읽기 범위: 원본 메일함 전체, 비공개 DM, 급여, 법적 분쟁, 인증정보, 건강정보, 미공개 재무자료, 모든 파일 접근.
• 읽기 통제: 출처 허용목록, 문서 민감도 등급, 검색 로그, 개인정보 필터, 답변 출처 표시.

4. 쓰기 권한: 초안과 공식 기록을 분리한다

쓰기 권한에서 많은 팀이 선을 흐립니다. 초안은 공식 기록이 아닙니다. CRM 변경 제안은 실제 CRM 변경이 아닙니다. 환불 메모는 환불 실행이 아닙니다.

가장 안전한 중간 단계는 초안 전용 쓰기입니다. AI는 답변 초안, 입력 폼, 태그 제안, 검토용 테이블, 내부 메모를 만들 수 있습니다. 하지만 최종 반영은 사람이나 명확한 규칙이 담당해야 합니다.

이 단계에서는 검토 비용도 드러납니다. AI가 너무 자유롭게 많이 쓰면 팀은 숨은 오류를 찾느라 시간을 씁니다. 좋은 쓰기 권한은 작은 변경, 확인 가능한 출처, 눈에 보이는 diff를 남겨야 합니다.

• 낮은 위험의 쓰기: 답변 초안, 통화 요약, 태그 제안, 체크리스트 생성, 리포트 목차, 검토 대기열의 필드 채우기.
• 중간 위험의 쓰기: CRM 단계 변경, 티켓 상태 변경, 내부 문서 수정, 공유 스프레드시트 입력.
• 쓰기 통제: 스테이징 영역, diff 화면, 담당자 리뷰, 롤백 경로, 필드별 권한, 샘플 QA.

5. 실행 권한: 외부에 영향을 주는 행동은 고위험이다

실행 권한은 AI가 바깥 세계에 영향을 주는 순간입니다. 이메일 발송, 카드 결제, 데이터 삭제, 페이지 게시, 계약 생성, 권한 변경, 운영 API 호출은 법적, 금전적, 브랜드, 고객 신뢰 리스크를 만들 수 있습니다.

OpenAI의 에이전트 가이드는 도구의 위험도를 읽기 전용인지, 쓰기 권한인지, 되돌릴 수 있는지, 계정 권한과 금전 영향이 있는지에 따라 나누라고 설명합니다. 쉽게 말하면 되돌리기 어렵고, 돈이 움직이고, 개인정보가 노출되고, 다른 사람이 보는 내용이 바뀌면 위험도가 올라갑니다.

비전문가 팀의 규칙은 단순해도 됩니다. AI는 추천할 수 있습니다. AI는 초안화할 수 있습니다. AI는 준비할 수 있습니다. 하지만 영향이 큰 실행은 승인 게이트, 이름이 있는 책임자, 로그가 있어야 합니다.

• 항상 승인해야 하는 행동: 외부 이메일 발송, 환불 또는 결제, 데이터 삭제, 고객용 콘텐츠 게시, 계약 서명, 사용자 초대, 권한 변경, 배포 실행.
• 초기에는 피해야 하는 행동: 넓은 shell 접근, 비밀 파일 접근, 결제 실행, 법적 약속, 대량 메시지, 파괴적 일괄 변경.
• 실행 통제: 사람 승인, 고위험 이중 검토, 호출 횟수 제한, 도메인 허용목록, 임시 인증, 롤백 계획, 감사 로그.

6. 실제 도입을 위한 권한 사다리

안전한 도입은 "에이전트를 쓰지 말자"가 아닙니다. 사다리를 만드는 것입니다. 하나의 반복 업무에서 시작하고, 앞 단계가 측정 가능하고, 로그가 남고, 충분히 지루할 정도로 안정된 뒤 다음 단계로 올라가야 합니다.

x-inbox-router에서 잡힌 X 신호도 같은 운영 문제를 보여줍니다. Tool Calling, MCP, Skills는 같은 말이 아니라 서로 다른 층위라는 지적이 있었습니다. 또 마크다운 회사 OS와 MCP 도구 연결은 강력하지만, 연구가 행동으로 넘어가는 순간 safeguard와 책임자가 필요하다는 사례도 있었습니다.

Guildex식 권한 사다리는 이 차이를 도구 연결 전에 눈에 보이게 만듭니다.

• 0단계: 도구 접근 없음. 사용자가 붙여넣은 맥락 안에서만 답변.
• 1단계: 승인된 지식 읽기. 출처를 인용하지만 기록은 바꾸지 않음.
• 2단계: 초안 전용 쓰기. 큐나 스테이징 영역에만 결과 작성.
• 3단계: 검토 후 쓰기. 승인 뒤 제한된 내부 변경만 반영.
• 4단계: 승인 기반 실행. 고위험 행동은 명시적 승인 뒤 실행.
• 5단계: 좁은 자동 실행. 되돌릴 수 있고 영향이 낮으며 횟수 제한이 있는 행동만 반복 검증 후 자동화.

7. 피해야 할 실패 패턴

첫 번째 실패는 마스터키 접근입니다. 편하다는 이유로 에이전트에게 모든 파일, 모든 채널, 모든 도구를 연결합니다. 그 결과는 똑똑한 직원이 아니라 책임 경계가 흐린 무제한 행위자입니다.

두 번째 실패는 숨은 행동입니다. 겉으로는 요약이나 초안처럼 보이지만, 한 번의 도구 호출이 CRM 행을 바꾸고, 메시지를 보내고, 목록을 내보냅니다. 운영자가 경계를 볼 수 없으면 통제할 수도 없습니다.

세 번째 실패는 승인 흉내입니다. 사람이 깔끔한 요약만 보고 승인 버튼을 누르지만, 출처, 변경 내용, 위험도는 보이지 않습니다. 진짜 승인 게이트는 무엇이 실행되는지, 왜 실행되는지, 어떤 데이터가 쓰였는지, 어떻게 되돌릴 수 있는지를 보여줘야 합니다.

• 읽기, 쓰기, 실행을 하나의 넓은 "AI 도구 권한"으로 합치지 않습니다.
• 에이전트가 인증정보, 급여, 법무 비공개 폴더를 읽게 하지 않습니다. 정말 필요한 경우에만 별도 검토합니다.
• 도구 설명이나 외부 텍스트가 검증 없이 권한 있는 행동을 직접 유도하게 두지 않습니다.
• 요약만 보고 승인하지 않습니다. 출처, 변경 필드, 영향받는 사용자, 롤백 방법을 함께 봅니다.
• 성공한 데모 하나를 영구 운영 권한으로 바꾸지 않습니다.

8. Guildex 기준: 에이전트보다 권한표를 먼저 만든다

실무용 권한표에는 여섯 칸이 필요합니다. 출처, 소유자, 민감도, 허용 행동, 승인 조건, 로그 위치입니다. 도입 초기에는 모델 이름보다 이 표가 더 중요합니다.

각 워크플로우마다 물어보세요. AI가 무엇을 읽어야 하는가. 무엇을 초안으로 쓸 수 있는가. 무엇은 검토 뒤 바꿀 수 있는가. 무엇은 아직 자동화하면 안 되는가.

목표는 회사를 느리게 만드는 것이 아닙니다. 책임이 사라지지 않는 방식으로 AI를 유용하게 만드는 것입니다. 좋은 권한 설계는 열쇠, 게이트, 영수증이 보이기 때문에 사람이 시스템을 믿을 수 있게 합니다.