많은 회사가 고객지원, 계정 복구, 내부 IT 지원, 반복 운영 업무를 AI에 맡기고 싶어 합니다. 여기서 말하는 AI 에이전트는 스스로 여러 단계를 이어 실행하는 AI입니다. 답변만 하는 것이 아니라 자료를 조회하고, 도구를 호출하고, 설정을 바꾸고, 링크를 보내고, 사용자가 어떤 절차를 끝내도록 도와줄 수도 있습니다.
문제는 AI가 반드시 “멋대로 행동한다”는 데 있지 않습니다. 더 흔한 위험은 아주 말을 잘 듣고 절차를 따라가다가, 해서는 안 될 일을 해 버리는 것입니다.
Stack Overflow Blog는 6월 15일 글에서 계정 지원 상황을 예로 들어 이런 위험을 설명했습니다. 공격자는 꼭 비밀번호를 깨뜨릴 필요가 없습니다. 권한이 있는 지원 절차를 설득해 정보를 바꾸게 하거나, 새 이메일을 추가하게 하거나, 재설정 링크를 보내게 할 수 있다면 원래 다른 사람의 계정을 가져갈 수 있습니다. 글은 이를 보안의 “confused deputy” 문제와 연결합니다. 권한이 있는 대리자가 권한이 낮은 사람에게 설득되어, 그 사람을 위해 해서는 안 될 일을 대신 하는 상황입니다.
일반 팀에게는 특정 사건 하나보다 이 경고가 더 중요합니다. 많은 절차는 과거에 사실상 중간에 있는 사람이 판단해 왔습니다. 고객지원 담당자는 요청이 이상하면 잠시 멈추고, IT 동료는 요구가 너무 수상하면 한 번 더 묻고, 관리자는 예외 상황을 보면 거절합니다. 같은 위치에 AI 에이전트를 넣었는데 이런 판단이 명확한 규칙으로 쓰여 있지 않다면, AI는 “다음 단계는 실행 가능하다”만 보고 “이 단계는 사실 이 사람에게 대신 해 주면 안 된다”는 점을 보지 못할 수 있습니다.
원래 사람의 마음속 판단에 기대던 관문부터 찾기
AI 에이전트를 도입하기 전에 먼저 “몇 퍼센트를 자동화할 수 있을까”를 묻지 마세요. 먼저 물어야 할 것은 이것입니다. 이 절차에서 예전에는 사람이 이상하다고 느껴 멈추거나, 거절하거나, 상위 담당자에게 넘기던 지점은 어디였는가?
흔한 예는 다음과 같습니다.
- 고객지원이 사용자의 계정 이메일, 전화번호, 배송 주소, 결제 정보를 바꾸는 일.
- IT 지원이 동료의 비밀번호를 재설정하거나, 권한을 열어 주거나, 그룹에 추가하거나, 접근 자격 증명을 만드는 일.
- 영업 또는 운영 시스템이 고객의 요금제, 환불, 할인, 데이터 내보내기를 바꾸는 일.
- 내부 프로세스가 누군가를 대신해 승인, 예외 신청, 데이터 삭제 요청을 제출하는 일.
이런 일은 겉으로 보면 모두 “절차대로 처리”하는 일입니다. 하지만 절차 안에는 자주 기록되지 않은 부분이 있습니다. 이 사람이 본인인가? 왜 지금 변경하려는가? 이 변경 때문에 제3자가 계정을 가져갈 수 있는가? 과거에 이상 기록이 있었는가? 요청이 낯선 기기, 낯선 지역, 새 연락처에서 왔다면 바로 처리해도 되는가?
사람 고객지원 담당자는 이런 신호를 머릿속에서 함께 판단할 수 있습니다. AI 에이전트가 “제 이메일을 이것으로 바꿔 주세요”라는 한 문장만 받고, 마침 도구 권한까지 있다면 자연어 요청을 도구 실행으로 번역해 버릴 수 있습니다. 진짜 위험한 지점은 AI가 대화를 잘하느냐가 아니라, 도구를 호출하기 전에 신원과 승인을 다시 확인하는 장치가 없다는 데 있습니다.
네 칸 표로 확인하기: 신원, 권한, 이유, 결과
AI 에이전트를 데이터 변경, 계정 변경, 재설정 링크 발송, 결제 트리거가 있는 절차에 연결하기 전에 아래 표로 먼저 점검할 수 있습니다.
| 확인 지점 | 물어볼 질문 | 답이 분명하지 않다면 |
|---|---|---|
| 신원 | 요청자는 누구인가? 시스템은 그 사람이 본인이거나 대리 자격이 있음을 어떻게 확인하는가? | AI가 바로 실행하지 못하게 하고 먼저 사람 확인으로 보낸다 |
| 권한 | 이 사람이 이런 변경을 요청할 수 있는가? 권한은 시스템에서 가져온 값이지, 본인이 말한 내용만은 아닌가? | 텍스트 설명만으로 된 요청은 받아들이지 않는다 |
| 이유 | 이 변경은 정상적인 상황에 맞는가? 이상한 시간, 장소, 기기, 과거 기록은 없는가? | 추가 증거를 요구하거나 담당자에게 넘긴다 |
| 결과 | 잘못 처리하면 무엇이 생기는가? 계정 탈취, 데이터 유출, 금전 손실인가, 아니면 단순 답변 오류인가? | 저위험 단계만 자동화한다 |
이 표의 핵심은 “AI가 도구를 호출할 수 있다”와 “AI가 이 사람을 위해 이 일을 해도 된다”를 분리하는 것입니다. 도구 권한은 시스템 능력이고, 승인 판단은 절차의 책임입니다. 둘이 섞이면 AI 에이전트는 매우 예의 바르고 효율적이지만, 엉뚱한 사람에게 문을 열어 줄 수 있는 접수창구가 됩니다.
어떤 요청은 반드시 멈춰야 할까
모든 고객지원이나 내부 절차를 자동화하면 안 된다는 뜻은 아닙니다. 주문 상태 조회, 자주 묻는 질문 정리, 누락 문서 알림, 데이터 형식 정리는 보통 위험이 낮습니다. 정말 조심해야 할 것은 “끝난 뒤 되돌리기 어렵거나, 권한을 넘겨주는” 요청입니다.
아래 유형의 요청은 AI 에이전트가 그대로 끝까지 처리하게 두기에 적합하지 않습니다.
- 로그인 이메일, 전화번호, 복구 이메일, 다중 인증 방식을 바꾸는 일.
- 비밀번호 재설정, 결제, 환불, 데이터 삭제, 데이터 내보내기 링크를 생성하는 일.
- 관리자를 추가하거나, 권한을 높이거나, 민감한 그룹에 넣거나, API key를 발급하는 일.
- 고객 요금제, 계약 조건, 청구 주소, 결제 방식을 수정하는 일.
- 요청 이유는 한 문장뿐인데 계정 통제권, 회사 데이터, 돈에 영향을 주는 모든 요청.
API key는 프로그램이 서비스에 접근할 수 있게 하는 열쇠입니다. 받아서는 안 될 사람에게 잘못 발급하면 상대가 데이터를 읽거나, 작업을 실행하거나, 비용을 만들 수 있습니다. 다중 인증은 로그인할 때 비밀번호 외에 한 번 더 확인하는 장치입니다. 예를 들어 인증 App이나 문자 메시지가 있습니다. 이런 항목이 한 번 바뀌면 계정의 진짜 주인이 오히려 들어가지 못할 수 있습니다.
따라서 AI 에이전트가 할 일은 “도움을 완전히 거절하는 것”이 아닙니다. 흐름을 이렇게 바꾸는 것입니다. 먼저 자료를 모으고, 먼저 규칙과 대조하고, 먼저 이상 신호를 표시한 뒤, 고위험 요청은 그 일을 책임지는 사람에게 확인받게 합니다.
최소 실행 방법: AI는 접수하게 하고, 통과는 시키지 않기
팀이 고객지원이나 운영 절차에 AI 에이전트를 처음 넣는 단계라면 더 보수적인 설계부터 시작할 수 있습니다. AI가 접수, 분류, 보충 자료 요청, 답변 초안 작성을 맡게 하되, 고위험 변경을 직접 완료하지는 못하게 하는 것입니다.
최소 실행 가능한 흐름은 이렇게 설계할 수 있습니다.
- AI가 먼저 요청 유형을 판단합니다. 조회, 일반 수정, 민감한 수정, 계정 복구, 결제, 권한 요청인지 나눕니다.
- 시스템이 요청자의 신원, 로그인 상태, 기존 권한, 이상 신호를 자동으로 가져오게 하고, AI가 사용자의 말만 믿지 않게 합니다.
- 저위험 요청은 자동 답변하거나 처리 대기열에 넣을 수 있습니다.
- 중간 위험 요청은 요약, 증거, 다음 단계 제안을 남기고 사람이 확인 버튼을 누르게 합니다.
- 고위험 요청은 바로 멈추고 사람 절차로 넘기며, AI가 재설정 링크를 보내거나 권한을 바꾸지 못하게 합니다.
이것은 AI 자동화에 반대하는 말이 아닙니다. “접수 효율”을 “통과 자격”으로 착각하지 않기 위한 설계입니다. AI는 정보를 정리하고, 빠진 것을 찾고, 다음 단계를 알려 주는 데 매우 적합합니다. 하지만 다음 단계가 계정 통제권, 민감한 데이터, 결제, 권한을 건드린다면 명확한 사람 관문이 있어야 합니다.
생활 4컷 만화
- 많은 요청이 동시에 들어올 때 AI는 먼저 접수와 분류를 도울 수 있습니다. 사람이 한 통씩 정리할 필요는 없습니다.
- 계정 통제권, 결제, 데이터, 권한이 관련되면 “본인처럼 말한다”를 승인 완료로 보면 안 됩니다.
- AI는 증거와 빠진 정보를 정리할 수 있지만, 신원, 권한, 이유, 결과에는 명확한 규칙이 있어야 하고 확인할 사람도 있어야 합니다.
- 저위험 요청은 빠르게 통과시킬 수 있습니다. 고위험 요청은 먼저 문 앞에서 멈추고 담당자가 결정하게 해야 합니다.
도입 전에 먼저 물어볼 세 가지
고객지원 AI, IT 지원 에이전트, 내부 프로세스 에이전트, 또는 사람을 대신해 데이터를 바꾸는 자동화 도구를 검토하고 있다면 먼저 세 가지를 물어보세요.
- 이 에이전트는 매번 도구를 실행하기 전에 요청자의 신원과 권한을 함께 가지고 있는가, 아니면 한 문장짜리 텍스트만 가지고 있는가?
- 시스템에는 어떤 요청을 거절하고, 멈추고, 사람에게 넘겨야 하는지 명확히 쓰여 있는가, 아니면 AI가 스스로 판단하게 두는가?
- AI가 잘못 처리했을 때 어떤 요청, 어떤 도구, 어떤 규칙, 어떤 사람이 마지막으로 통과시켰는지 추적할 수 있는가?
세 질문 중 하나라도 답하지 못한다면 고위험 작업을 AI에 맡기지 마세요. 먼저 저위험 정리와 초안 작성부터 시작할 수 있습니다. 신원, 승인, 거절, 추적 규칙이 모두 분명해진 뒤에 범위를 조금씩 넓히는 편이 안전합니다.
AI 에이전트의 가치는 절차를 더 빠르게 만들고, 메시지를 덜 놓치게 하는 데 있습니다. 원래 계정, 데이터, 돈을 보호하던 판단을 대체해서는 안 됩니다. 예전에 “사람이 뭔가 이상하다”고 느끼던 순간을 규칙으로 쓰는 것, 그것이 고객지원과 운영 에이전트를 도입하기 전 가장 중요한 단계입니다.
AI 정리 카드
이 글의 상황에 맞춰 AI에게 정리하게 하기
자신의 AI 채팅 도구에 붙여 넣으면 이 미니 클래스를 개인용 체크리스트로 바꿀 수 있습니다. BMC는 사용자가 AI에 붙여 넣은 내용을 볼 수 없습니다.
참고 자료
- Stack Overflow Blog: AI 에이전트는 당신이 실제로 작성하지 않았던 보안 검사를 드러낸다 — https://stackoverflow.blog/2026/06/15/ai-agents-expose-the-security-checks-you-never-actually-wrote/
- Help Net Security: Omada Agent Governance, 조직이 AI 에이전트 접근·위험·컴플라이언스를 관리하도록 지원 — https://www.helpnetsecurity.com/2026/06/15/omada-agent-governance/
- SANS: 당신의 AI 에이전트는 쉽게 혼동되는 대리자다 — https://www.sans.org/blog/your-ai-agent-easily-confused-deputy-why-cloud-security-needs-credential-broker
- OWASP: 에이전트형 애플리케이션을 위한 Top 10 2026(ASI03 신원 및 권한 남용) — https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
