한눈에 보는 답
AI 에이전트 권한 설계는 모든 앱을 연결하는 일에서 시작하면 안 됩니다. 가장 좁지만 유용한 업무를 정하고, 읽기와 초안 작성과 발송과 삭제를 분리하며, 되돌리기 어려운 행동은 승인으로 막고, 외부 시스템을 바꾸는 모든 도구 호출에는 로그와 복구 경로를 둬야 합니다.
- AI 에이전트에는 앱 전체 권한보다 행동 단위 권한을 먼저 설계해야 합니다.
- 읽기, 초안, 생성, 수정, 발송, 내보내기, 삭제, 환불, 승인 권한은 서로 다릅니다.
- 사람 승인은 마지막 장식이 아니라 위험한 도구 호출 직전에 있어야 합니다.
- 외부 시스템을 바꾸는 모든 행동에는 추적 가능한 로그와 복구 방법이 필요합니다.
- 권한 확장은 단계적으로 하고, 재검토일과 회수 방법을 같이 정해야 합니다.
- 추천 대상
- AI 에이전트를 업무 시스템, API, 문서, 커뮤니케이션 도구, 자동화 플랫폼에 연결하려는 자동화 설계자, 운영자, 컨설턴트, 기술팀.
- 주제
- 자동화
- 최근 확인
- 2026년 6월 13일
업무흐름 스냅샷
이 가이드를 실제 자동화 흐름으로 바꿀 때 참고할 핵심 흐름도입니다.
- 01 입력
반복 업무, 필요한 입력 자료, 담당자, 성공 기준을 먼저 정합니다.
- 02 AI 처리
AI는 초안 작성, 분류, 요약, 라우팅, 도구 호출처럼 범위가 분명한 단계에 배치합니다.
- 03 사람 검토
승인, 예외 처리, 비용 한도, 민감한 판단은 사람이 확인하도록 남겨둡니다.
- 04 결과
결과를 체크리스트, 저장 프롬프트, SOP, 모니터링되는 자동화 실행으로 정리합니다.
- AI 에이전트
- AI 자동화
- 권한 설계
- 최소 권한
- 도구 호출
적용 전 확인
도구 바로가기보다 업무 판단 기준으로 사용하세요.
자동화하기 전에 입력 자료, 사람이 확인할 지점, 실행 후 볼 지표를 먼저 정해야 합니다.
가장 먼저 반복 가능한 단계는 무엇인가?
AI 에이전트를 실제 도구에 연결하기 전에 무엇을 읽고, 작성하고, 바꾸고, 보내고, 내보내고, 삭제할 수 있는지 결정하게 돕습니다.
6 참고한 공개 자료
바뀔 수 있는 기능과 가격은 연결된 공개 자료와 공식 문서에서 다시 확인하세요.
자료 보기
한 번에 크게 바꾸지 말고 작은 파일럿으로 시작한 뒤 검토 지점이 명확할 때 확장하세요.
- AI 에이전트에는 앱 전체 권한보다 행동 단위 권한을 먼저 설계해야 합니다.
- 읽기, 초안, 생성, 수정, 발송, 내보내기, 삭제, 환불, 승인 권한은 서로 다릅니다.
- 사람 승인은 마지막 장식이 아니라 위험한 도구 호출 직전에 있어야 합니다.
- 외부 시스템을 바꾸는 모든 행동에는 추적 가능한 로그와 복구 방법이 필요합니다.
업무 흐름
이 글이 속한 업무 흐름
지금 읽는 글이 어떤 업무 흐름에 연결되는지 확인하고, 관련 글로 이어서 볼 수 있습니다.
- 잘 맞는 경우
- 간단한 도구 구매, 내부 워크플로우 구축, 더 큰 플랫폼 도입 사이에서 결정해야 하는 팀
- 맞지 않을 수 있는 경우
- 반복되는 시작 조건, 담당자, 입력값이 아직 없다면 자동화보다 업무 흐름 정의를 먼저 하는 편이 좋습니다.
AI 에이전트는 실제 시스템에 닿는 순간부터 위험도가 달라집니다. 정책 문서를 읽는 것은 비교적 안전합니다. 하지만 CRM 단계를 바꾸고, 고객에게 이메일을 보내고, 고객 데이터를 내보내고, 환불을 승인하고, 기록을 삭제하는 것은 완전히 다른 문제입니다.
그래서 질문을 바꿔야 합니다. “이 앱에 연결할 수 있나?”가 아니라 “어떤 행동을, 어떤 데이터로, 어떤 승인 조건에서, 틀렸을 때 어떻게 되돌릴 수 있나?”를 물어야 합니다.
이 체크리스트는 AI 에이전트를 도구, API, 문서, 브라우저 작업, 자동화 플랫폼에 연결하려는 경우를 위한 권한 설계 문서입니다. 보안 검토를 대체하지는 않지만, 에이전트를 실제 업무에 넣기 전에 최소한 정해야 할 기준을 제공합니다.
빠른 결론
가장 좁지만 유용한 업무 하나에서 시작하고, 필요한 도구 호출을 전부 적으세요. 먼저 읽기 전용 권한을 주고, 발송보다 초안 작성부터 허용하세요. 생성은 수정보다 먼저, 수정은 삭제보다 훨씬 엄격해야 합니다. 내보내기, 삭제, 환불, 결제, 법무, 고객 통지, 권한 변경은 고위험 행동으로 봐야 합니다. 고위험 행동은 담당자 승인, 입력과 출력 보존, 감사 로그, 복구 경로가 있어야 합니다.
누가 권한을 소유하는지, 왜 필요한지, 에이전트가 하면 안 되는 일이 무엇인지, 어떻게 회수할지 설명할 수 없다면 아직 허용할 권한이 아닙니다.
권한은 워크플로우 설계입니다
OpenAI Agents SDK 문서는 에이전트를 모델, 도구, 지침, 핸드오프, 가드레일, 상태로 구성된 시스템으로 설명합니다. 여기서 중요한 점은 권한이 단순한 OAuth 동의 화면이 아니라 워크플로우 구조의 일부라는 것입니다.
위험 관점에서도 같은 결론이 나옵니다. OWASP Agentic Applications Top 10은 계획하고, 행동하고, 도구를 사용하고, 더 높은 자율성을 가진 시스템을 다룹니다. 에이전트가 할 수 있는 일이 많아질수록 권한은 더 구체적이어야 합니다.
실무에서는 권한을 네 층으로 나눠야 합니다.
| 층 | 질문 | 예시 |
|---|---|---|
| 데이터 | 무엇을 볼 수 있나? | 고객 프로필, 송장 상태, 계약 메모 |
| 행동 | 무엇을 할 수 있나? | 검색, 초안, 수정, 발송, 내보내기, 삭제 |
| 승인 | 언제 멈춰야 하나? | 고객 발송 전, 돈이나 계약 관련 기록 변경 전 |
| 복구 | 틀리면 어떻게 하나? | 토큰 회수, 기록 복원, 담당자 알림, 로그 재생 |
복구 층을 빼면 안 됩니다. 복구 설계가 있어야 자동화가 통제 가능한 운영 시스템이 됩니다.
먼저 권한 인벤토리를 만드세요
에이전트를 연결하기 전에 권한 인벤토리를 만드세요. 지루할 정도로 구체적이어야 합니다. 한 줄이라도 애매하면 아직 운영에 넣을 준비가 안 된 것입니다.
| 업무 단계 | 도구 | 닿는 데이터 | 에이전트 행동 | 필요한 권한 | 실행 주체 | 책임자 |
|---|---|---|---|---|---|---|
| 문의 읽기 | 공유 메일함 | 본문, 발신자, 스레드 | 읽기와 분류 | 메일함 읽기 | 서비스 계정 | 지원 리드 |
| CRM 메모 생성 | CRM | 연락처, 회사, 거래 메모 | 메모 생성 | 연락처 읽기, 메모 생성 | 봇 사용자 | 운영 담당 |
| 답변 초안 작성 | 헬프데스크 | 티켓 맥락, 정책 문서 | 초안 작성만 | 티켓 읽기, 초안 저장 | 봇 사용자 | 지원 리드 |
| 답변 발송 | 헬프데스크 | 고객 이메일 | 메시지 발송 | 승인된 티켓 발송 | 사람 승인 행동 | 지원 리드 |
| 상태 업데이트 | 프로젝트 보드 | 업무 상태, 담당자 | 단계 이동 | 상태 수정 | 봇 사용자 | 운영 담당 |
이 표는 “앱을 통째로 연결하는” 문제를 막아줍니다. 에이전트에게 필요한 것은 앱 전체가 아니라 워크플로우 안의 작은 행동 묶음입니다.
행동 권한 매트릭스를 쓰세요
가장 실용적인 권한 모델은 행동 단위입니다. 기본 허용 행동과 승인 필요 행동을 분리합니다.
| 행동 유형 | 기본 기준 | 승인 필요 | 로그 필요 | 복구 방법 |
|---|---|---|---|---|
| 검색 또는 읽기 | 범위가 좁으면 허용 | 보통 불필요 | 민감 데이터는 필요 | 권한 회수 |
| 요약 | 허용 | 불필요 | 출처 ID 저장 | 다시 생성 |
| 초안 작성 | 허용 | 내부 초안은 불필요 | 프롬프트와 출처 저장 | 초안 폐기 |
| 내부 기록 생성 | 조건부 허용 | 경우에 따라 필요 | 생성 기록 저장 | 보관 또는 삭제 |
| 외부 기록 수정 | 제한 | 고객, 재무, 법무, 컴플라이언스 필드는 필요 | 변경 전후 값 저장 | 이전 값 복원 |
| 메시지 발송 | 제한 | 낮은 위험의 템플릿이 아니면 필요 | 수신자, 내용, 승인자 저장 | 정정 안내와 사고 기록 |
| 데이터 내보내기 | 제한 | 필요 | 범위와 목적지 저장 | 링크 회수, 토큰 교체, 담당자 알림 |
| 삭제, 환불, 승인, 서명 | 기본 차단 | 항상 필요 | 전체 감사 추적 | 수동 복구 계획 |
원칙은 단순합니다. 워크플로우 바깥의 사람이나 시스템에 영향을 줄수록 자율성은 낮아져야 합니다.
승인 게이트는 너무 늦으면 안 됩니다
마지막에 한 번 승인하는 방식은 자주 늦습니다. 좋은 승인 게이트는 비용이 큰 행동이 실행되기 전에, 판단에 필요한 맥락이 보일 때 멈춥니다.
다음 조건에서는 승인 게이트가 필요합니다.
- 조직 밖으로 메시지를 보낸다.
- 돈, 계약, 계정, 법무, 고객 상태 데이터를 바꾼다.
- 처음 쓰는 권한으로 도구를 호출한다.
- 불확실한 자료에 의존해 결론을 낸다.
- 불만, 보안 문제, 환불, 법적 표현, 해지, 계정 변경 요청이 포함된다.
- 에이전트가 자신의 도구 접근을 넓히거나 다른 자동화를 바꾸려 한다.
OpenAI Agents SDK의 human-in-the-loop 패턴처럼 워크플로우가 멈추고, 승인 또는 거절을 받은 뒤, 그 결정으로 이어서 실행되는 구조가 좋습니다.
OAuth와 API 권한은 좁게 잡으세요
OAuth scope와 API 권한에서 많은 에이전트 프로젝트가 과해집니다. “Google Workspace 연결”, “Microsoft Graph 연결”은 권한 설계가 아닙니다. 경계가 없는 위험 모델입니다.
권한을 승인하기 전 아래 표를 확인하세요.
| 요청 권한 | 더 좁은 대안 | 유지해도 되는 경우 |
|---|---|---|
| 모든 파일 읽기 | 선택된 폴더 또는 파일 선택기 결과만 읽기 | 넓은 검색이 꼭 필요하고 출처 로그가 있을 때 |
| 사용자 대신 이메일 발송 | 초안 생성만 허용 | 승인 템플릿과 발송 게이트가 있을 때 |
| 모든 CRM 기록 읽기/쓰기 | 연락처 읽기와 메모 생성만 허용 | 필드 수정이 실제로 필요할 때 |
| 보고서 내보내기 | 도구 내부 요약 생성 | 외부 내보내기가 필요하고 목적지가 기록될 때 |
| 관리자 권한 | 사람의 관리자 작업으로 분리 | 안전한 에이전트 사용 사례가 거의 없음 |
Google OAuth scope 문서와 Microsoft Graph 권한 개요는 범위가 넓어질 때 어떤 위험이 생기는지 판단하는 데 도움이 됩니다. 넓은 권한을 승인하기 전에 반드시 더 좁은 대안을 먼저 검토해야 합니다.
운영자가 읽을 수 있는 로그를 남기세요
감사 로그는 원시 토큰 더미가 아닙니다. 사람이 실제로 무슨 일이 있었는지 재구성할 수 있어야 합니다.
중요한 도구 호출마다 아래 항목을 남기세요.
run_id와 워크플로우 이름- 사용자 요청 또는 트리거 출처
- 에이전트 지침 버전
- 도구 이름과 행동 유형
- 입력 레코드 또는 출처 ID
- 출력 목적지
- 수정 전후 값
- 승인 요청, 승인자, 시간
- 가능하다면 확신도 또는 판단 사유
- 오류, 재시도, fallback, 넘김 상태
- 복구 상태
고객이 문제를 제기하거나, 송장이 틀리거나, 기록이 예상치 못하게 바뀌었을 때 이 로그는 첫 질문에 답해야 합니다. “에이전트가 무엇을 했고, 왜 허용됐는가?”
권한은 단계적으로 넓히세요
자율성부터 시작하지 마세요. 관찰부터 시작하세요.
| 단계 | 허용 행동 | 차단 행동 | 확장 근거 |
|---|---|---|---|
| 1. 관찰 | 읽기, 분류, 요약 | 초안, 발송, 수정, 내보내기, 삭제 | 검토된 실행에서 분류 정확성이 확인됨 |
| 2. 초안 | 내부 초안과 메모 생성 | 외부 발송, 돈, 삭제 | 수정률이 낮고 출처 사용이 명확함 |
| 3. 승인 후 실행 | 사람 승인 뒤 실행 | 자체 승인, 권한 변경 | 승인 패턴이 예측 가능하고 로그가 완전함 |
| 4. 제한된 자동 실행 | 낮은 위험의 반복 행동 실행 | 고위험 필드, 내보내기, 파괴적 행동 | 실패율이 안정적이고 복구 테스트가 끝남 |
| 5. 범위 확장 | 새 행동을 하나씩 추가 | 광범위한 관리자 권한 | 새 권한의 책임자와 재검토일이 있음 |
이 단계식 접근은 NIST AI Risk Management Framework의 방향과도 맞습니다. 위험을 식별하고, 행동을 측정하고, 통제 수단을 관리하며, 거버넌스를 보이게 유지하는 방식입니다.
출시 전에 회수와 복구를 정하세요
권한 설계는 끄는 방법까지 정해야 완성됩니다.
비상 체크리스트는 아래 질문에 답해야 합니다.
- 어떤 토큰, 봇 계정, API 키, 워크플로우, 통합을 먼저 끌 것인가?
- 담당자가 없을 때 누가 에이전트를 일시 중지할 수 있는가?
- 정리 전에 어떤 로그를 보존해야 하는가?
- 어떤 외부 시스템에 정정 안내가 필요한가?
- 어떤 기록을 변경 전후 로그로 복원해야 하는가?
- 어떤 권한을 영구적으로 제거할 것인가?
- 어떤 근거가 있어야 다시 켤 수 있는가?
복구 설계는 비관론이 아닙니다. 실제 운영에서 자동화를 받아들일 수 있게 만드는 조건입니다.
예시: 고객 후속 연락 에이전트
문의 내용을 읽고, CRM 맥락을 확인하고, 답변 초안을 만들고, 후속 업무를 생성하고, 나중에는 메시지까지 보내는 에이전트를 생각해 보겠습니다.
첫날부터 CRM과 메일함 전체 권한을 주면 안 됩니다.
처음에는 이렇게 시작하세요.
- 특정 큐의 메일함 읽기
- 매칭된 연락처에 대한 CRM 읽기
- 내부 메모 생성
- 답변 초안 생성
- 발송 권한 없음
- 거래 금액, 상태, 환불, 구독, 담당자 필드 수정 없음
- 모든 출처와 초안 생성에 대한 로그 저장
검토된 실행에서 수정률이 낮다면 발송 게이트를 추가합니다. 에이전트는 메시지를 준비하지만 사람이 승인합니다. 낮은 위험의 템플릿 발송도 나중에야 검토해야 하며, 수신 거부, 불만, 넘김, 정정 처리까지 있어야 합니다.
자주 묻는 질문
AI 에이전트가 사람 계정을 써도 되나요?
지속적인 업무 자동화에서는 보통 권장하지 않습니다. 이름이 있는 봇 계정이나 서비스 계정이 모니터링, 회수, 제한에 유리합니다. 사용자 위임이 필요하다면 위임 사실을 명확히 보이게 하고 넓은 권한을 피하세요.
읽기 전용 권한은 항상 안전한가요?
아닙니다. 읽기 전용도 고객 정보, 재무 정보, 법무 자료, 내부 전략을 노출할 수 있습니다. 쓰기 권한보다 안전할 뿐이며, 범위와 로그와 데이터 처리 기준은 여전히 필요합니다.
언제 승인 없이 메시지를 보낼 수 있나요?
위험이 낮고, 템플릿화되어 있고, 되돌릴 수 있고, 수신자가 예상할 수 있고, 모니터링되는 경우에만 검토할 수 있습니다. 불만, 환불, 법적 표현, 계정 변경, 보안 문제, 가격 협의는 사람 승인을 유지해야 합니다.
가장 흔한 권한 실수는 무엇인가요?
행동 단위 권한을 설계하기 귀찮아서 앱 전체 권한을 주는 것입니다. 설정 시간은 줄지만 운영 리스크는 커집니다.
다음 단계
아직 업무 경계가 흐리다면 AI 워크플로우 점검 스코어카드부터 확인하세요. 이미 플랫폼과 모델 라우팅을 고르고 있다면 출시 전에 자동화 스택 비교와 함께 이 체크리스트를 권한 인벤토리로 옮겨 검토하세요.
참고한 공개 자료
본문의 기능, 가격, 비교 맥락을 확인할 때 참고한 주요 공개 페이지입니다.
