안녕하세요, 비즈니스 혁신 파트너 BSG입니다.
요즘 AI 이야기의 중심은 '에이전트'입니다. 묻는 말에 답만 하는 게 아니라, 목표를 주면 스스로 판단해 일을 처리하는 AI죠.
그런데 여기서 아무도 피해갈 수 없는 질문이 하나 등장합니다.
"그럼 그 AI에게, 우리 시스템 열쇠를 어디까지 쥐여줘야 하죠?"
오늘은 화려한 데모 뒤에 숨은 이 진짜 숙제를 이야기해보겠습니다.
먼저 왜 이게 새로운 문제인지 짚어야 합니다.
기존 프로그램은 정해진 대로만 움직입니다.
"이 버튼을 누르면 이 동작"이 고정돼 있죠.
그래서 권한도 예측 가능합니다.
에이전트는 다릅니다.
허용된 범위 안에서 무엇을 할지 스스로 고릅니다.
상황을 보고 A를 할지 B를 할지 판단하죠.
여기서 결정적인 차이가 생깁니다.
에이전트에게 부여한 권한 목록 전체가, 곧 그 시스템의 공격 표면이 된다는 것입니다.
"쓸 일은 없겠지만 혹시 몰라서" 열어둔 권한 하나가, 실제로 사용될 수 있다는 뜻입니다.
업계에서 지적하는 가장 흔한 실패 패턴이 있습니다.
바로 테스트 단계에서 쌓인 권한을 그대로 달고 프로덕션에 올라가는 것입니다.
개발할 때는 편의상 권한을 넉넉히 줍니다.
이것도 되게 하고, 저것도 되게 하고. 그러다 잘 돌아가니 그대로 실서비스에 올립니다.
결과적으로 에이전트는 필요 없는 권한까지 잔뜩 쥔 채 실제 업무 데이터 위에서 돌아가게 됩니다.
전통적인 시스템에서도 나쁜 습관이지만, 에이전트에서는 훨씬 위험합니다.
사람이 실수하면 한 건으로 끝나지만, 에이전트의 잘못된 판단은 후속 작업으로 자동 연쇄되니까요.
에이전트 특유의 리스크는 크게 세 갈래로 정리됩니다.
첫째, 자격증명 노출.
에이전트는 외부 서비스를 호출하려고 토큰이나 API 키를 들고 있습니다.
문제는 AI 모델이 그 값을 응답에 포함해버릴 수 있다는 점입니다.
"모델의 문맥에 들어간 것은 언제든 출력에 나올 수 있다"고 가정하고 설계해야 합니다.
둘째, 권한 상승과 프롬프트 인젝션.
에이전트에게 도구를 많이 쥐여줄수록, 악의적인 입력으로 의도하지 않은 도구를 호출하게 만들 여지가 커집니다.
메일을 보내거나 데이터를 지우는 것처럼, 되돌릴 수 없는 작업이라면 문제가 커집니다.
셋째, 대리인 혼동.
권한이 높은 서비스가 낮은 권한의 요청에 속아 대신 일을 처리해주는 상황입니다.
에이전트가 다른 에이전트를 부르고, 그게 다시 도구를 호출하는 다단계 구조에서 특히 위험합니다.
다행히 정석은 명확합니다.
새로운 마법이 아니라, 기본기를 에이전트에 맞게 다시 적용하는 것입니다.
최소 권한이 출발점입니다.
"혹시 모르니 넓게"가 아니라, 이 에이전트가 실제로 쓰는 것만 허용하는 방식입니다.
정확히 어떤 모델, 어떤 데이터, 어떤 함수, 어떤 저장 경로를 쓰는지 파악해 딱 그만큼만 여는 것이죠.
AWS도 생성형 AI 설계 원칙에서 에이전트 실행 역할에 최소 권한을 적용하고, 부여 가능한 권한의 상한선을 미리 걸어두라고 권고합니다.
자격증명은 에이전트가 직접 들지 않게 합니다.
코드나 로그에 키가 남지 않도록 별도 계층에서 관리하고, 도구마다 필요한 최소 범위만 부여하는 방식입니다.
되돌릴 수 없는 일에는 사람을 세웁니다.
조회나 분석은 맡기더라도, 발송·삭제·결제처럼 파급이 큰 작업은 사람의 승인을 거치게 하는 것입니다.
신뢰는 한 번에 주지 않고 쌓아갑니다.
AWS가 최근 선보인 보안 서비스도 같은 접근을 취합니다.
처음에는 '학습 모드'로 감독 아래 관찰만 하다가, 검증된 영역부터 하나씩 자율 권한을 넓혀가는 방식이죠.
자율성과 통제 사이에서 균형을 잡는 현실적인 해법입니다.
에이전트 도입을 검토 중이라면, 최소한 이 질문들에는 답할 수 있어야 합니다.
이 에이전트가 접근할 수 있는 데이터의 범위는 어디까지인가.
사용자마다 볼 수 있는 정보가 다른데, 에이전트도 그 구분을 지키는가. 에이전트가 한 일을 나중에 추적하고 감사할 수 있는가.
그리고 무엇보다, 되돌릴 수 없는 작업은 무엇이고 거기엔 사람이 있는가.
이 질문들에 답이 없다면, 아직 프로덕션에 올릴 준비가 안 된 것입니다.
데모가 잘 돌아가는 것과 실제 업무에 안전하게 올리는 것 사이에는, 바로 이 간극이 있습니다.
AI 에이전트 도입에서 진짜 어려운 부분은 모델을 고르는 일이 아닙니다.
"이 AI에게 무엇을 맡기고, 무엇은 맡기지 않을 것인가"를 정하고, 그 결정을 시스템에 정확히 새기는 일입니다.
권한을 너무 좁게 주면 에이전트는 아무것도 못 하고, 너무 넓게 주면 사고가 났을 때 걷잡을 수 없습니다.
그 사이의 적정선을 찾는 것 — 이건 기술 문제이자 거버넌스 문제입니다.
BSG는 AWS MSP 파트너로서 클라우드의 보안과 운영을 함께 설계해왔습니다.
AI 에이전트를 실제 업무에 올리는 여정을 고민 중이시라면, 권한 설계부터 함께 짚어보시죠.
출처 : AWS Well-Architected 생성형 AI 렌즈, Amazon Bedrock AgentCore 보안 모범사례 문서, 업계 분석 종합
기획 : 도예원