AI 에이전트 도입의 진짜 병목은 모델이 아니라 권한이다

AI 에이전트를 사내에 도입할 때 모델 성능보다 먼저 풀어야 할 권한, 감사 로그, 승인 구조의 설계 원칙을 다룬다.

이 글은 사내 AI 에이전트 도입에서 권한, 승인, 감사 로그를 어떻게 설계해야 하는지 다루는 QSike Tech Notes 기술 해설입니다. 특정 제품 도입을 권유하기보다 엔터프라이즈 AI 자동화의 운영 구조를 이해하는 데 초점을 둡니다.

회사에서 AI 에이전트를 이야기할 때, 대화는 보통 모델 성능에서 시작한다.

“GPT-5.5가 더 잘하나?”
“Claude가 코딩을 더 잘하나?”
“사내 문서까지 읽게 하면 답변 품질이 얼마나 올라가나?”

물론 중요하다. 모델이 멍청하면 뒤가 없다. 그런데 실제로 사내 업무에 AI 에이전트를 넣어보면, 생각보다 빨리 다른 문제에 부딪힌다.

모델이 답을 잘하는지는 첫 번째 문제다. 그다음 질문은 훨씬 더 현실적이다.

“얘한테 어디까지 시켜도 되지?”

메일을 읽어도 되는가. 문서를 수정해도 되는가. Jira 티켓을 닫아도 되는가. DB를 조회해도 되는가. 조회만 할 수 있는가, 아니면 업데이트도 할 수 있는가. 실수하면 누가 책임지는가.

여기서부터 챗봇과 에이전트는 완전히 다른 물건이 된다.

챗봇은 말하고, 에이전트는 실행한다

챗봇은 기본적으로 답변 시스템이다. 사용자가 질문하면 텍스트를 돌려준다. 틀릴 수는 있지만, 대체로 피해는 “잘못된 답변을 믿었을 때” 발생한다.

에이전트는 다르다. 에이전트는 도구를 잡는다.

파일을 읽고, API를 호출하고, 워크플로를 실행하고, 문서를 고치고, 코드를 커밋하고, 메시지를 보낸다. 답변에서 끝나지 않고 시스템 상태를 바꾼다.

챗봇은 주로 답변을 반환하지만, 에이전트는 도구를 호출하고 시스템 상태를 바꿀 수 있다. 그래서 권한 설계가 본질적인 문제가 된다.

이 차이가 크다.

예를 들어 이런 요청을 생각해보자.

“지난주 장애 원인 정리해서 관련 담당자들에게 공유해줘.”

챗봇이라면 장애 원인 요약문을 만들어준다. 에이전트라면 로그를 읽고, 장애 티켓을 찾고, 관련 문서를 업데이트하고, 담당자에게 메시지를 보낼 수 있다.

멋있다. 동시에 위험하다.

장애 원인 문서를 잘못 수정하면? 공유 대상자를 잘못 잡으면? 아직 확정되지 않은 내용을 임원 채널에 보내면? 개인정보가 포함된 로그를 요약해서 외부 도구로 넘기면?

이런 문제는 모델 벤치마크 점수로 해결되지 않는다.

사내 시스템은 권한 덩어리다

회사 업무는 권한 위에 얹혀 있다.

문서함에도 권한이 있고, 메일에도 권한이 있고, 소스코드 저장소에도 권한이 있다. 데이터베이스, 협업툴, 결재 시스템, 배포 시스템은 말할 것도 없다.

사람은 보통 자기 권한 안에서 일한다. 물론 사람도 실수한다. 하지만 최소한 조직은 사람에게 역할을 부여하고, 그 역할에 따라 접근권한을 준다.

AI 에이전트도 같은 원칙을 따라야 한다.

문제는 에이전트가 애매하다는 점이다. 사용자 대신 움직이는 것 같기도 하고, 시스템 계정처럼 보이기도 한다. 때로는 여러 사용자의 요청을 처리하고, 여러 도구를 동시에 쓴다.

그러면 질문이 생긴다.

• 에이전트는 사용자의 권한을 그대로 따라야 할까?
• 별도 서비스 계정 권한을 가져야 할까?
• 사용자는 읽을 수 있지만 수정하면 안 되는 문서를 에이전트가 수정해도 될까?
• 팀 문서를 요약할 때, 접근권한이 없는 사람에게 결과를 보여줘도 될까?
• 에이전트가 만든 결과물의 작성자는 누구인가?

이 질문에 답하지 않은 상태에서 “AI 에이전트 도입”을 시작하면, 결국 누군가는 브레이크를 건다. 보안팀이든, 법무팀이든, 현업 리더든.

그리고 그 브레이크는 대체로 맞다.

최소권한이 없으면 에이전트는 곧 위험해진다

사람에게도 필요 이상으로 권한을 주면 사고가 난다. 에이전트는 더 조심해야 한다.

사람은 적어도 “이건 좀 이상한데?” 하고 멈출 때가 있다. 에이전트도 멈출 수 있지만, 멈추도록 설계해야 멈춘다. 그냥 도구를 많이 붙여놓으면 성실하게 실행한다. 성실한 자동화가 항상 좋은 것은 아니다.

그래서 에이전트 권한은 작게 시작해야 한다.

처음부터 “메일 읽기, 문서 수정, DB 업데이트, 배포 실행”을 모두 열어두면 안 된다. 업무를 잘게 나누고, 각 업무에 필요한 최소 권한만 줘야 한다.

예를 들어 장애 리포트 에이전트라면 첫 단계는 이 정도가 적당하다.

• 장애 티켓 읽기
• 로그 요약 파일 읽기
• 관련 문서 검색
• 첫 정리안 작성
• 사람에게 승인 요청

여기까지는 비교적 안전하다. 문서 업데이트나 전체 공지는 다음 단계다. 승인 흐름이 생긴 뒤에 열어도 늦지 않다.

이 접근이 답답해 보일 수 있다. 하지만 사내 자동화는 처음부터 강하게 만드는 것보다, 나중에 꺼도 되는 구조로 만드는 게 더 중요하다.

감사 로그는 선택사항이 아니다

에이전트가 실행을 시작하면 로그가 필요하다.

단순한 시스템 로그 말고, 사람이 읽을 수 있는 감사 로그가 필요하다.

최소한 이런 정보는 남아야 한다.

• 누가 요청했는가
• 에이전트가 어떤 판단을 했는가
• 어떤 도구를 호출했는가
• 어떤 데이터에 접근했는가
• 무엇을 변경했는가
• 실행 전후 상태가 어떻게 달라졌는가
• 사람 승인이 있었는가

이게 없으면 문제가 생겼을 때 아무것도 설명할 수 없다.

“AI가 알아서 했습니다”는 회사에서 통하지 않는다. 누가 시켰고, 어떤 권한으로 실행됐고, 어떤 근거로 그렇게 했는지 남아 있어야 한다.

특히 사내 시스템에서는 “정답을 잘 냈는가”보다 “나중에 설명할 수 있는가”가 더 중요할 때가 많다. 잘못된 실행도 문제지만, 설명할 수 없는 실행은 더 큰 문제다.

사람 승인은 느린 장치가 아니라 안전장치다

AI 자동화를 이야기하면 사람 승인을 병목처럼 보는 경우가 있다.

“사람이 매번 승인하면 자동화가 아니잖아.”

반은 맞고, 반은 틀렸다.

모든 작업에 승인이 필요하면 자동화 효과가 줄어든다. 하지만 모든 작업을 무승인으로 열어두면 도입 자체가 어려워진다.

중요한 건 작업을 나누는 것이다.

승인 없이 해도 되는 작업:

• 문서 검색
• 요약안 작성
• 로그 분석
• 후보 목록 생성
• 중복 데이터 탐지
• 변경안 미리보기

승인이 필요한 작업:

• 외부 발송
• 권한 변경
• 원본 문서 수정
• 운영 DB 업데이트
• 배포
• 비용이 발생하는 작업
• 고객이나 임직원에게 영향을 주는 조치

이렇게 나누면 에이전트는 충분히 빠르게 일할 수 있다. 사람은 마지막 위험 구간에서만 개입하면 된다.

좋은 에이전트 설계는 사람을 완전히 빼는 게 아니다. 사람이 봐야 하는 순간을 줄이고, 봐야 할 때는 정확히 멈추게 만드는 것이다.

MCP와 워크플로 도구가 필요한 이유

요즘 MCP 같은 도구 연결 방식이 주목받는 이유도 여기에 있다.

LLM 하나만으로는 사내 시스템에 안전하게 붙기 어렵다. 모델은 언어를 잘 다루지만, 권한 관리 시스템은 아니다. 감사 로그 시스템도 아니고, 승인 워크플로 엔진도 아니다.

에이전트 아키텍처는 대략 이렇게 나뉘어야 한다.

사내 에이전트는 모델 하나가 아니라 도구 연결, 권한, 워크플로, 로그, 사용자 인터페이스가 분리된 실행 구조에 가깝다.

• 모델: 판단과 언어 처리
• 도구 계층: API, DB, 문서, 업무 시스템 연결
• 권한 계층: 누가 무엇을 할 수 있는지 제한
• 워크플로 계층: 실행 순서, 승인, 재시도, 실패 처리
• 로그 계층: 요청, 판단, 실행, 결과 기록
• 사용자 인터페이스: 사람이 검토하고 승인하는 화면

MCP는 이 중에서 도구 연결을 표준화하는 쪽에 가깝다. 현재는 특정 제품 기능이라기보다 LLM과 외부 도구·데이터 소스를 연결하는 오픈 프로토콜에 가깝게 논의된다. n8n 같은 워크플로 도구는 실행 흐름과 승인 단계를 만들기 좋다. RAG는 사내 지식을 가져오는 데 필요하다.

하지만 어느 하나만으로 완성되지 않는다.

MCP 서버를 많이 붙였다고 좋은 에이전트가 되는 게 아니다. 오히려 도구가 많아질수록 권한과 로그가 더 중요해진다.

사내 AI 에이전트 도입은 작게 시작해야 한다

처음부터 “전사 업무를 처리하는 범용 에이전트”를 만들려고 하면 거의 실패한다. 범위가 너무 넓고, 권한도 복잡하고, 책임 소재도 흐려진다.

처음에는 작고 명확한 업무가 낫다.

예를 들면:

• 회의록에서 액션아이템 추출
• 장애 리포트 작성안 만들기
• 반복 문의에 대한 근거 문서 링크 제안
• 코드 리뷰 체크리스트 자동 생성
• 운영 로그 이상 징후 요약
• 업무 요청 티켓 분류
• 사내 문서 변경안 작성

공통점이 있다. 대부분 “작성안”, “요약”, “분류”, “제안”이다.

이 단계에서는 에이전트가 사람을 대체하지 않는다. 사람이 시작하기 귀찮은 일을 먼저 정리해준다.

그다음 신뢰가 쌓이면 실행 권한을 조금씩 열 수 있다. 읽기에서 쓰기로, 작성안에서 수정으로, 내부 검토에서 외부 발송으로.

이 순서를 건너뛰면 조직이 불안해한다. 그리고 그 불안은 비합리적이지 않다.

좋은 에이전트는 똑똑한 모델보다 통제 가능한 실행 구조에서 나온다

AI 에이전트의 성능을 모델 순위표로만 보면 중요한 부분을 놓친다.

회사에서 필요한 것은 “가장 똑똑한 답변자”가 아니다. 안전하게 실행하고, 멈춰야 할 때 멈추고, 나중에 설명할 수 있는 시스템이다.

그래서 사내 에이전트 도입의 핵심 질문은 이렇게 바뀌어야 한다.

“어떤 모델을 쓸까?”에서
“이 에이전트에게 어떤 권한을 줄 것인가?”로.

“얼마나 자동화할까?”에서
“어디서 사람 승인을 받을 것인가?”로.

“답변이 맞는가?”에서
“근거와 실행 로그가 남는가?”로.

AI 에이전트는 결국 조직의 업무 시스템 안으로 들어와야 한다. 그 순간부터 기술 문제는 운영 문제와 분리되지 않는다.

모델은 점점 좋아질 것이다. 하지만 사내에서 진짜 차이를 만드는 건 모델 이름이 아닐 가능성이 크다.

권한을 작게 나누고, 실행을 기록하고, 위험한 순간에 사람을 세우는 구조. 그게 없으면 에이전트는 데모에서는 멋있고, 실제 업무에서는 무서운 도구가 된다.

반대로 그 구조가 있으면, 모델이 조금 부족해도 쓸 수 있다. 처음에는 작성안을 만들고, 다음에는 검토를 돕고, 언젠가는 제한된 범위에서 실행까지 맡길 수 있다.

에이전트 도입은 “AI를 얼마나 믿을 것인가”의 문제가 아니다. 믿지 않아도 쓸 수 있게 만드는 설계의 문제다.

독자 질문

우리 회사에서 AI 에이전트에게 가장 먼저 열어줄 수 있는 권한은 무엇일까? 반대로, 마지막까지 사람 승인이 필요한 권한은 무엇일까?

한 문장 요약

사내 AI 에이전트의 병목은 모델 성능보다 권한, 승인, 감사 로그를 포함한 실행 통제 구조에 있다.

다음에 읽을 글

AI 에이전트를 조직에 넣을 때 권한과 승인 구조가 왜 중요한지 이해했다면, 다음에는 에이전트가 실제로 얼마나 많은 추론 자원을 쓰는지도 함께 볼 필요가 있습니다. 메타 클라우드, AI 에이전트 병목을 풀까는 에이전트 확산이 GPU와 클라우드 처리 용량 문제로 어떻게 이어지는지 설명합니다.

체크포인트

• 이 에이전트가 접근할 수 있는 데이터와 도구의 범위는 어디까지인가
• 실행 전 승인, 실행 중 모니터링, 실행 후 감사 로그가 분리되어 있는가
• 실패했을 때 사람이 개입할 수 있는 중단 지점이 있는가
• 권한 설계와 추론 비용 설계를 함께 보고 있는가

확인한 출처 / 근거

• NIST SP 800-207, Zero Trust Architecture — 요청 단위 검증과 최소 권한 원칙.
• OWASP, LLM06:2025 Excessive Agency — 과도한 에이전트 권한과 사람 승인 필요성.
• Model Context Protocol, Architecture — 모델과 외부 도구 연결 계층의 구조.
• MCP Authorization Specification — OAuth 기반 승인과 토큰 검증 범위.