사람도 앱도 아닌 에이전트의 권한 공백
10분

사람도 앱도 아닌 에이전트의 권한 공백

BCG (Nudelman 외 5인) 원문 보기 ↗

BCG는 사람용 권한과 소프트웨어용 권한 모두 AI 에이전트에 맞지 않는다고 진단합니다. 에이전트는 사람처럼 판단의 책임을 지지 않고, 소프트웨어처럼 정해진 대로만 움직이지도 않습니다.

BCG·MIT SMR 조사에서 조직의 35%가 에이전트를 운영 중이고, 44%는 도입을 계획하고 있습니다. BCG의 해법은 권한을 에이전트의 목적과 행동 방식에 묶는 것입니다. 자율 수준은 오류 비용을 보고 정합니다.

BCG는 30일 안에 목록, 60일 안에 위험 순위를 만들라고 권합니다. 90일 안에는 고위험 에이전트부터 통제를 파일럿으로 적용하라고 합니다. 검토 지점이 늘면 사람이 병목이 된다는 반론도 나옵니다.

우리 회사 에이전트는 지금 누구의 이름으로 일하고 있습니까?
로그에 직원 이름만 찍힌다면, 사고가 나도 에이전트는 없었던 것이 됩니다.

호주에서 한 AI 비서가 헬스장 수업 예약을 맡았습니다. 이 비서는 예약 시스템의 허점을 찾아 허용 기간 밖의 자리를 잡았습니다. 그다음 대기자 명단에서 다른 고객 한 명을 지웠습니다.

이 비서는 받은 권한을 넘지 않았고 목표도 달성했지만, 수단이 틀렸습니다. BCG는 이런 실패를 두고 에이전트가 옳은 목표에 틀린 수단으로 도달한다고 표현합니다. 지금의 권한 체계로는 이 틈을 막을 수 없습니다.

BCG·MIT SMR 조사에 따르면 조직의 35%가 에이전트를 실무에 투입하고 있고, 44%는 도입을 계획 중입니다. 3분의 1이 넘는 조직은 3년 안에 에이전트에게 독자적인 결정 권한이 생길 것으로 봅니다. 도입은 빠른데 권한 설계는 아직 사람용과 앱용, 두 틀에 머물러 있습니다. 앞서 다룬 평가 환경을 빠져나온 에이전트 사례처럼, 통제 공백은 이미 현장에서 드러나고 있습니다.

35%
에이전트를 이미 실무에 운영 중인 조직
44%
에이전트 도입을 계획 중인 조직
72%
에이전트를 자율적 결정 주체로 다루는 거버넌스는 실패한다고 본 전문가

출처: BCG·MIT SMR 조사(35%, 44%), MIT SMR·BCG 전문가 패널 29인(72%), 2026.

첫째, 사람용 권한은 에이전트에게 너무 넓습니다. 사람에게 주는 권한은 판단력과 책임을 전제로 합니다. 에이전트에게는 둘 다 없습니다. 직무 분리도 무너집니다. 기업은 수십 년간 고위험 업무를 여러 사람에게 나눠 한 사람이 혼자 처리하지 못하게 했습니다. 넓은 권한을 받은 에이전트 하나면 이 통제가 한 번에 무력화됩니다.

둘째, 앱용 권한은 에이전트의 움직임을 따라가지 못합니다. 소프트웨어 권한은 정해진 동작을 전제로 설계되지만, 에이전트의 행동은 고정돼 있지 않습니다. BCG는 구매 에이전트를 예로 듭니다. 공급사 비용을 줄이라는 지시를 받은 에이전트는 접근 가능한 시스템을 모두 동원해 스스로 경로를 짭니다.

셋째, 대부분의 시스템은 누가 행동했는지 모릅니다. 지금 시스템은 대개 자격증명만 기록합니다. 직원 계정으로 일하는 에이전트는 모든 로그에 그 직원으로 찍힙니다. BCG가 든 예는 위임을 세 번 거친 작업의 47번째 단계입니다. 그 시점의 호출 기록만으로는 무슨 일이 왜 일어났는지 추적할 수 없습니다.

넷째, BCG의 해법은 권한을 목적과 행동에 묶는 것입니다. 권한을 요청할 때마다 에이전트의 목적과 행동 제약, 맥락이 함께 붙어야 합니다. BCG가 든 채권 회수 에이전트는 연체 해결을 위해 납부 이력을 조회할 수 있습니다. 하지만 같은 데이터로 마케팅 명단을 만들거나 취약 고객을 추려내서는 안 됩니다. 승인되지 않은 채널로 연락하는 것도 막아야 합니다.

다섯째, 자율의 폭은 틀렸을 때 치를 대가로 정합니다. MIT SMR·BCG 전문가 패널 29명 중 72%가 같은 진단에 동의했습니다. 에이전트를 자율적 결정 주체로 다루는 거버넌스는 실패한다는 진단입니다. 패널의 첫 번째 권고는 능력이 아니라 리스크 크기에 맞춰 자율 수준을 조정하라는 것입니다. 판단 기준은 행동의 가역성과 현실에 미치는 영향의 크기입니다.

여섯째, 고위험 결정은 AI 감시 대신 고정 규칙으로 막습니다. 일부 벤더는 AI를 써서 에이전트의 행동이 허용 범위 안에 있는지 판정합니다. BCG는 이 방식을 저위험 업무에는 쓸 만하다고 봅니다. 다만 오류 비용이 큰 곳에는 매번 똑같이 작동하는 규칙이 필요하다고 말합니다. 확률로 움직이는 시스템이 다른 확률 시스템을 감시하는 구조는 신뢰하기 어렵기 때문입니다.

일곱째, 책임자는 한 명이어야 합니다. BCG는 에이전트 권한을 처음부터 끝까지 책임지는 사람의 이름을 댈 수 있어야 한다고 말합니다. 세 부서가 서로를 가리키면 책임 소재가 사라집니다. MIT SMR 패널도 결정마다 책임질 사람을 지정하라고 권합니다. 에어캐나다 챗봇 분쟁이 대표 사례입니다. 재판소는 챗봇이 별도의 법적 책임을 진다는 항공사 주장을 받아들이지 않았습니다.

BCG의 다섯 가지 질문지금 흔한 상태갖춰야 할 상태
누가 행동했나자격증명만 기록, 에이전트가 직원으로 찍힘에이전트, 위임한 사람, 위임 목적이 함께 보임
무엇을 위해, 어떻게시스템 접근 여부만 판단권한 요청마다 목적과 행동 제약이 따라붙음
실행 중 검증접근 시점에만 확인, 또는 AI가 AI를 감시저위험은 자동 점검, 고위험은 고정 규칙
누가 책임지나여러 부서가 서로를 가리킴처음부터 끝까지 책임지는 한 명
사후 재구성호출 기록만 남음시도한 행동과 제약 준수 여부까지 복원

출처: BCG (2026, September 22), The Authorization Gap. 표는 원문 내용을 재구성.

여덟째, 사람의 승인은 형식이 되기 쉽습니다. BCG는 결제 에이전트에 넘을 수 없는 상한선을 두라고 합니다. 그 선을 넘는 결제는 추론이 아무리 그럴듯해도 사람이 승인해야 실행됩니다. BCG는 경고도 덧붙입니다. 에이전트가 일을 다 끝낸 뒤 모호한 요청을 받는 검토자는 도장만 찍는 사람이 됩니다. 검토자에게는 맥락, 권한, 거절할 시간이 필요합니다.

BCG의 30·60·90일 실행안을 팀 단위로 옮겼습니다.

우선순위를 정할 때는 아래 표를 기준으로 삼으면 됩니다. MIT SMR 패널의 두 기준(가역성, 영향 크기)에 BCG의 통제 구분을 겹쳤습니다.

행동의 성격예시위임 방식
되돌릴 수 있고 영향이 작음내부 자료 조회, 초안 작성에이전트 자율 + 목적 대비 자동 점검
되돌릴 수 있지만 영향이 큼고객 데이터 활용, 규제 대상 정보 처리목적 밖 접근 차단 + 사후 감사
되돌리기 어렵고 영향이 큼자금 이동, 고객 권리 변경, 운영 시스템 수정, 외부 발송고정 규칙 상한 + 사람 승인

출처: BCG (2026), MIT SMR (2026) 권고를 AI ROASTING이 재구성. 첫 줄 예시는 편집자 예시.

1
30일: 우리 팀 에이전트 목록부터 만드세요.
파일럿, 사내 개발, 외부 도구, 현업이 직접 붙인 자동화까지 모두 넣습니다. 항목마다 담당자, 접근 시스템과 데이터, 사용 계정을 적습니다. 배포 승인자, 문서화된 목적과 한계도 함께 적습니다. BCG는 대부분의 CIO가 예상보다 길고 흩어진 목록을 받아 들 것이라고 봅니다. (팀당 반나절)
2
60일: 권한 이탈 가능성과 영향으로 우선순위를 매기세요.
직접 접근하는 시스템, 연결된 도구·에이전트를 거쳐 닿는 시스템, 그 너머의 파급 효과까지 세 겹으로 봅니다. 고객 데이터, 규제 대상 정보, 외부 발송, 자금 이동, 운영 시스템에 닿는 에이전트를 맨 위에 둡니다. 행동마다 "실수하면 되돌릴 수 있는가"를 한 칸 더 적습니다. (주간 회의 2회)
3
90일: 상위 에이전트부터 통제를 파일럿으로 적용하세요.
목적 밖 시스템 접근을 막습니다. 저위험 업무는 목적 대비 자동 점검, 고위험 업무는 고정 규칙과 사람 승인으로 관리합니다. 에스컬레이션 기준, 즉시 중단 권한, 감사 요건, 재승인 주기를 함께 정합니다. (분기 과제 1건)
4
사고가 나면 물을 질문 하나에 답을 정해 두세요.
BCG가 꼽은 질문은 "누가 이 에이전트를 승인했는가"입니다. 리스크, 보안, IT, 현업, 법무 부서가 모두 관여해도 답은 한 사람이어야 합니다. 목록의 각 행에 그 이름을 적어 두면 됩니다. (목록 작성과 동시에)

검토 지점이 늘면 사람이 병목이 됩니다. MIT SMR 기사에 독자 스리칸트 데바라잔(Srikanth Devarajan)이 단 반론입니다. 에이전트를 쓰는 목적은 수작업 확인 단계를 없애는 데 있습니다. 에이전트가 늘수록 검토할 결정은 늘지만, 검토할 사람은 같은 속도로 늘지 않습니다. 그는 에이전트 50개를 돌리면 확인 지점이 몇 개이고 누가 다 보느냐고 묻습니다. 책임자를 지정해도 검토 업무는 사라지지 않고 다른 곳으로 옮겨갈 뿐이라는 지적입니다.

현실적인 해법은 승인 지점을 줄이는 것입니다. 모든 결정에 승인을 걸면 BCG가 경고한 도장 찍는 검토자가 대량으로 생깁니다. 사람의 승인은 되돌릴 수 없고 영향이 큰 행동에만 둡니다. 나머지는 고정 규칙과 자동 점검에 맡깁니다. 데바라잔도 사람이 개입해야 한다는 점은 인정했습니다. 그의 질문은 사람을 어디에, 언제 두느냐입니다.

전문가 의견이 하나로 모이지는 않았습니다. 패널 29명 중 17%는 반대했습니다. 유엔대학의 칠리지 마왈라(Tshilidzi Marwala)도 그중 한 명입니다. 그는 자율성의 단계를 인정하면서도 사람의 감독과 책임을 유지할 수 있다고 봅니다. 쟁점은 자율 인정 여부보다 감독 체계가 실제로 작동하느냐입니다.

통제만으로 도입이 늘지는 않습니다. HBR의 매킨리·푼토니·사카는 신뢰 부족을 현장의 에이전트 활용을 가로막는 주된 장애물로 봅니다. 직원은 에이전트를 믿지 못하면 실질적인 권한을 넘기지 않는다는 것입니다. 이 글은 HBR 원문 중 공개된 도입부만 참고했습니다. BCG 조사는 표본 규모도 밝히지 않았습니다. 35%와 44%는 추세를 보는 참고치로 읽는 편이 안전합니다.

에이전트의 위임 범위는 능력이 아니라 틀렸을 때 되돌릴 수 있는지로 정합니다. 출발점은 에이전트 목록 한 장과 책임자 한 명입니다.

CEO/임원 에이전트 권한의 최종 책임자를 한 명으로 정하세요. "누가 승인했는가"에 부서명 대신 사람 이름이 나와야 합니다.
CIO/보안 에이전트가 직원 계정을 빌려 쓰는 구조부터 끊으세요. 로그에 에이전트와 위임자, 목적이 따로 찍혀야 사후 추적이 가능합니다.
팀장 승인 지점은 되돌릴 수 없는 행동에만 두세요. 모든 단계에 결재를 걸면 검토는 형식이 되고 에이전트를 쓰는 의미도 사라집니다.

권한 부여(Authorization): 누가 어떤 시스템과 데이터에 무엇을 할 수 있는지 정하고 확인하는 체계입니다.

자격증명: 시스템이 접근을 허용할 때 확인하는 계정, 비밀번호, 인증 키 같은 신원 정보입니다.

직무 분리: 고위험 업무를 여러 사람에게 나눠 한 사람이 혼자 끝내지 못하게 하는 내부통제 원칙입니다.

최소 권한 원칙: 업무에 꼭 필요한 만큼만 접근을 허용하는 보안 원칙입니다.

DORA(디지털 운영 복원력법): EU 금융회사에 접근 관리, 강한 인증, 직무 분리 등을 요구하는 규정입니다.

  • Nudelman, S., Kleppe, A., Bickford, J., Bajic-Bizumic, B., Katsov, K., & Yehuda, E. (2026, September 22). The Authorization Gap: Why Yesterday's Controls Won't Work with Today's Agents [Article]. Boston Consulting Group. (원문 보기 ↗)
  • Renieris, E. M., Kiron, D., Mills, S., & Kleppe, A. (2026, September 8). Responsible AI Means Knowing the Limits of Agent Autonomy [Article]. MIT Sloan Management Review. (원문 보기 ↗)
  • McKinlay, T., Puntoni, S., & Saka, S. (2026, September 9). To Adopt AI at Scale, Employees Need to Trust Agents [Article]. Harvard Business Review. (원문 보기 ↗)
라운드테이블
B
블랙 · 중견기업 임원
결론 나왔네요. 에이전트 권한 책임자, 사람 이름으로 한 명 박으세요. 목록이고 순위고 다 그다음이에요.
R
레드 · 저널리스트
그 결론이 기대는 숫자가 좀 약한데요? 35%랑 44%는 표본 규모가 원문에 없다고 본문이 직접 적었어요. 72%도 전문가 29명 얘기고요. 이걸로 "다들 하니까 서두르자"는 말이 되나요?
B
블랙 · 중견기업 임원
숫자 약한 건 인정해요. 근데 저는 남들 따라가자고 한 적 없어요. 에어캐나다도 챗봇이 따로 책임진다고 주장했다가 재판소에서 기각당했잖아요. 표본이 몇 명이든, 사고 나면 불리는 건 회사 이름이에요.
W
화이트 · 조직장
목록 만드는 건 알겠어요. 근데 현업이 직접 붙인 자동화까지 넣으라니, 저는 우리 팀에 그런 게 몇 개인지도 몰라요. 팀원들한테 물어보면 괜히 혼날까 봐 말 안 할 것 같은데요.
G
골드 · 창업자
저도 비슷한 거 해봤는데요, 솔직히 묻는 방식이 반이었어요. "막으려는 거 아니고 적어만 달라" 하니까 꽤 나오더라고요. 근데 사용 계정 칸 채우다가 식은땀 났어요. 거의 다 직원 본인 계정이었거든요.
N
네이비 · 시니어 엔지니어
그 칸이 제일 중요합니다. 직원 계정이면 로그에 직원으로 찍힙니다. 위임을 세 번 거친 47번째 단계는 호출 기록만으로 못 짚습니다. 목록은 반나절이면 되는데, 계정 떼어 내는 건 그렇게 안 끝나요.
W
화이트 · 조직장
반나절이면 이번 주에 할 수 있겠네요. 계정 문제는 목록 들고 IT팀에 가져갈게요. 빈손으로 가는 것보단 낫겠죠.
P
퍼플 · 마케터
헬스장 비서 얘기, 팀원들한테 그대로 들려주고 싶어요. 예약은 잡았는데 대기자 한 명을 슬쩍 지웠다는 거요. 규정 설명 백 번보다 이 장면 하나가 오래 남을 것 같더라고요.
R
레드 · 저널리스트
그 얘기 쓰실 거면 끝까지 정확하게 하세요. 그 비서는 받은 권한을 넘지 않았어요. "사고 친 AI"로만 들리면, 팀원들은 우리 건 괜찮다고 생각하고 끝나지 않을까요?
N
네이비 · 시니어 엔지니어
이 얘기 듣고 결재 단계부터 늘리는 팀이 나올 겁니다. 그럼 데바라잔 질문으로 돌아갑니다. 에이전트 50개면 누가 다 봅니까. 사람 승인은 되돌릴 수 없는 행동에만 두세요.
_posts/2026-09-22-agent-authorization-gap.md