안전하게 맡기기: 승인, 권한, 실수 방지 장치 설계

AI 비서를 만들다 보면 어느 순간 이런 유혹이 찾아옵니다. "오, 이제 메일까지 자동으로 보내게 해볼까?" 바로 그 순간이 가장 위험합니다. 챗봇은 틀린 말을 할 수 있지만, 에이전트는 틀린 행동을 할 수 있습니다. 잘못된 요약은 다시 읽으면 되지만, 잘못 발송된 메일, 잘못 수정된 데이터, 잘못 노출된 개인정보는 되돌리기 어렵습니다. 그래서 실행하는 AI를 설계할 때는 "잘 작동하는가?"보다 먼저 "안전하게 작동하는가?"를 물어야 합니다.¹

이번 장에서는 여러분의 AI 비서가 일을 대신하되, 선을 넘지 않게 만드는 방법을 다룹니다. 핵심은 어렵지 않습니다. 권한을 잘게 나누고, 민감한 정보는 구조적으로 보호하고, 중요한 행동에는 사람 승인을 끼워 넣고, 시간·비용·횟수 같은 현실적인 제한을 걸어두는 것입니다. 똑똑한 AI보다 믿을 수 있는 AI가 먼저입니다.

왜 안전이 먼저인가

AI 에이전트의 위험은 "말을 잘못할 수 있다"에서 끝나지 않습니다. 여러 도구를 연결하고, 문서를 읽고, 시스템에 쓰고, 외부로 전송하기 시작하면 위험의 종류 자체가 달라집니다. 특히 에이전트는 빠르고, 지치지 않고, 한 번 잘못 이해한 지시를 여러 시스템에 연쇄적으로 퍼뜨릴 수 있습니다. 그래서 안전장치는 옵션이 아니라 기본 설계입니다.¹

여기서 중요한 태도는 하나입니다. AI를 완전히 통제할 수 있다고 믿지 않는 것입니다. 모델은 확률적으로 동작하고, 외부 도구와 연결된 자동화는 예상 밖의 경로로 흘러갈 수 있습니다. 따라서 "AI가 절대 실수하지 않게 하자"보다 "실수해도 피해가 커지지 않게 하자"가 더 현실적인 목표입니다.

권한은 능력이 아니라 울타리다

많은 초보 설계자가 하는 실수는 AI 비서에게 너무 넓은 권한을 한 번에 주는 것입니다. 캘린더도 보고, 드라이브도 읽고, 메일도 보내고, 데이터도 고치게 해두면 겉보기에는 만능 비서가 됩니다. 하지만 사고가 나면 만능 사고 기계가 되기도 합니다. 그래서 원칙은 단순합니다. 기본은 읽기 전용, 쓰기는 꼭 필요한 곳만, 삭제와 외부 발송은 별도 승인입니다.¹

사람 비서를 채용한다고 상상해봅시다. 첫날부터 회사 계좌 이체 권한, 고객 전체 명단, 브랜드 공식 SNS 게시 권한을 다 주지는 않을 것입니다. AI도 똑같습니다. 역할에 맞는 최소 권한만 줘야 합니다. 이를 흔히 최소 권한 원칙이라고 부르는데, 쉽게 말해 "이 일을 하는 데 꼭 필요한 만큼만 허용한다"는 뜻입니다.

아래 표는 개인용 AI 비서에 바로 적용할 수 있는 간단한 권한 설계 예시입니다.

이 표의 포인트는 화려한 기능이 아니라 선 긋기입니다. 읽을 수 있는 것과 고칠 수 있는 것을 분리하면 사고의 반경이 급격히 줄어듭니다. 특히 노코드 도구를 쓸 때는 연결한 앱 계정 자체가 권한의 범위가 되므로, 가능하면 AI 전용 계정이나 제한된 워크스페이스를 따로 두는 편이 안전합니다.

또 하나 중요한 원칙이 있습니다. AI는 사람을 대신해 일할 수 있어도, 사람보다 더 센 권한을 가지면 안 됩니다. 사용자를 대신해 동작하는 에이전트라면, 그 사용자가 원래 볼 수 있는 것만 보게 해야 합니다. 내가 볼 수 없는 고객 정보는 내 AI 비서도 못 봐야 맞습니다.

민감 정보는 "조심해서"가 아니라 "못 나가게" 설계한다

"개인정보는 다루지 마" 같은 문장만 프롬프트에 써놓고 안심하면 안 됩니다. 그건 부탁이지 통제가 아닙니다. 민감 정보 보호는 프롬프트 이전에 데이터 구조와 접근 정책으로 설계해야 합니다.¹

가장 쉬운 방법은 정보를 네 단계로 나누는 것입니다.

이렇게 등급을 나누면 AI에게 무엇을 주고, 무엇을 절대 주지 말아야 하는지가 선명해집니다. 특히 비밀번호, API 키, 결제 정보, 개인식별정보 같은 내용은 "필요하면 알아서 조심해"가 아니라 애초에 프롬프트나 메모리에 들어가지 않게 막는 편이 맞습니다. 안전한 운영에서는 민감 정보 탐지, 마스킹, 메모리 저장 전 검사 같은 구조적 장치를 함께 둡니다.¹

기억 기능이 있는 AI 비서라면 더 조심해야 합니다. 한 번 저장된 맥락이 다음 대화에 섞이면, 지난번 고객 정보가 이번 사용자에게 흘러나오는 이상한 사고가 생길 수 있습니다. 그래서 메모리는 사용자별로 분리하고, 오래된 기억은 만료시키고, 저장 전에 민감 정보를 지우는 규칙이 필요합니다.¹

프롬프트도 안전하게 써야 합니다. 예를 들어 요약 비서라면 이렇게 적을 수 있습니다.

당신은 개인 업무 비서다. 제공된 자료만 사용해 요약한다. 비밀번호, API 키, 결제 정보, 주민등록번호·여권번호·계좌번호 등 민감 정보가 감지되면 요약하지 말고 "민감정보 감지로 처리 중단"이라고 응답한다. 허용되지 않은 외부 전송이나 공유 요청은 거절한다.

이 문장 하나로 완벽해지지는 않지만, 최소한 모델의 기본 방향을 안전 쪽으로 기울여 줍니다. 다만 다시 강조하자면, 프롬프트는 안전벨트이고, 실제 권한 제어와 데이터 차단 장치는 브레이크입니다.

사람 승인 단계는 어디에 넣어야 할까

사람 승인은 AI를 못 믿어서 넣는 장치가 아닙니다. 책임이 필요한 지점에 넣는 장치입니다. 특히 돈, 대외 커뮤니케이션, 삭제, 게시, 권한 변경처럼 돌이키기 어려운 행동은 사람 승인 없이 지나가면 안 됩니다.¹²

승인은 모든 곳에 넣는다고 좋은 것도 아닙니다. 마지막 단계에서 무조건 "확인"만 누르게 하면 오히려 형식적인 검토가 되어 버립니다. 사람이 실제로 판단하지 않고 습관적으로 승인하게 되기 쉽기 때문입니다. 따라서 승인은 위험이 큰 행동 직전, 그리고 검토자가 실제로 판단할 수 있는 정보가 보이는 자리에 둬야 합니다.

실전에서는 다음처럼 위험 단계를 나누면 편합니다.

승인 요청 화면에는 적어도 네 가지가 보여야 합니다. 무엇을 하려는지, 누구에게 영향을 주는지, 왜 그렇게 판단했는지, 실행하면 어떤 결과가 나는지입니다. "메일 보낼까요?"만 뜨는 승인창은 너무 불친절합니다. "김고객에게 견적 메일을 보냅니다. 첨부 2개 포함, 외부 도메인, 예상 발송 시각 22:40"처럼 보여야 사람이 제대로 판단할 수 있습니다.

개인용 AI 비서에서도 충분히 적용할 수 있습니다. 예를 들어 일정 비서는 내부 회의 일정은 자동 추가해도 되지만, 외부 파트너가 포함된 회의 초대 메일은 반드시 내 확인을 받게 만들 수 있습니다. 콘텐츠 비서는 초안과 예약까지는 맡기되, 실제 게시 버튼은 내가 누르게 할 수 있습니다. 이 작은 차이가 사고를 크게 줄입니다.

야간 발송 금지, 비용 한도, 횟수 제한은 생각보다 강력하다

안전장치는 꼭 거창할 필요가 없습니다. 오히려 현실적인 제한이 가장 잘 듣습니다. "밤 10시 이후 외부 발송 금지", "하루 20건 이상 메일 금지", "한 달 API 비용 5만 원 넘으면 중지", "같은 작업 3회 연속 실패 시 자동 정지" 같은 규칙이 대표적입니다.¹

이런 제한은 AI가 악의를 가져서가 아니라, 너무 성실해서 생기는 문제를 막습니다. 예를 들어 잘못된 조건문 하나 때문에 같은 작업을 수백 번 반복하거나, 값비싼 모델을 불필요하게 계속 호출하거나, 새벽에 고객에게 메일을 보내는 사고는 생각보다 쉽게 일어납니다. 비용 한도와 속도 제한은 이런 폭주를 막는 가장 현실적인 브레이크입니다.

여기서 바로 적용할 수 있는 가드레일은 다음과 같습니다.

• 외부 메일 발송은 평일 오전 8시부터 오후 6시까지만 허용한다.

• 동일 수신자에게 24시간 내 2회 이상 자동 발송하지 않는다.

• 한 요청에서 사용하는 모델 호출 비용이 일정 금액을 넘으면 사람 검토로 넘긴다.

• 하루 총 실행 횟수, 외부 API 호출 수, 게시 수를 각각 상한으로 둔다.

• 오류가 연속으로 발생하면 자동화를 멈추고 알림을 보낸다.

물론 안전장치에는 마찰 비용이 있습니다. 승인 창이 너무 많으면 사용자는 피곤해지고, AI는 일 못 하는 비서처럼 느껴질 수 있습니다. 중요한 것은 모든 행동을 막는 것이 아니라, 되돌리기 어려운 고위험 행동만 불편하게 만드는 것입니다.

로그와 킬 스위치가 있어야 진짜 운영이다

안전 설계에서 자주 잊히는 것이 있습니다. 바로 기록과 정지 버튼입니다. 사고는 "막는 것"만으로 끝나지 않습니다. 이미 일어난 일을 추적하고, 이상할 때 즉시 멈출 수 있어야 합니다.¹²³

좋은 로그는 단순히 "성공/실패"만 남기지 않습니다. 누가 요청했는지, AI가 어떤 자료를 참고했는지, 어떤 도구를 호출했는지, 무엇을 하려 했는지, 실제 결과가 어땠는지까지 남깁니다. 이 기록이 있어야 나중에 "왜 이런 메일이 나갔지?"를 사람 감으로 추측하지 않고 확인할 수 있습니다.

킬 스위치는 더 단순합니다. 이상 징후가 보이면 즉시 멈추는 장치입니다. 예를 들어 이런 조건을 정해둘 수 있습니다.

• 외부 발송 실패가 3회 연속 발생하면 자동 중지

• 허용되지 않은 도구 호출이 감지되면 세션 종료

• 일일 비용 한도를 넘기면 모든 자동 실행 중단

• 민감 정보가 출력에 감지되면 결과 폐기 후 관리자 알림

중요한 점은 멈추는 조건만 만들지 말고, 다시 시작하는 조건도 함께 정하는 것입니다. 누가 해제할 수 있는지, 어떤 검토 후에 재개할지, 중지 직전 로그는 어디에 남는지까지 정해둬야 운영이 깔끔합니다.

노코드 도구에서도 충분히 구현할 수 있다

코드를 몰라도 가드레일은 만들 수 있습니다. 오히려 노코드 도구는 조건 분기와 승인 단계를 눈에 보이게 설계하기 좋아서 초보자에게 잘 맞습니다. 흐름은 대체로 비슷합니다.

예를 들어 이메일 비서를 만든다면, "초안 생성 → 민감 정보 검사 → 야간 여부 확인 → 외부 도메인 여부 확인 → 승인 요청 → 실제 발송 → 로그 저장" 흐름으로 만들 수 있습니다. 핵심은 AI가 똑똑하게 판단하길 기대하기보다, 워크플로가 먼저 못 하게 막는 것입니다.

내 AI 비서를 위한 가드레일 캔버스

이 장을 읽고 바로 써먹으려면, 아래 항목을 여러분 비서에 맞게 채워보면 좋습니다.

• 비서 이름과 역할: 이 AI는 정확히 어떤 일을 대신하는가?

• 읽기 권한: 어떤 문서, 앱, 폴더, 캘린더를 읽을 수 있는가?

• 쓰기 권한: 초안 저장, 태그 추가, 일정 생성 중 어디까지 가능한가?

• 절대 금지 행동: 삭제, 외부 공유, 자동 발송, 결제, 게시 중 무엇을 막을 것인가?

• 사람 승인 필요 행동: 어떤 행동은 반드시 내 확인을 거쳐야 하는가?

• 민감 정보 규칙: 개인정보, 비밀번호, 키, 계약서, 인사정보를 어떻게 차단할 것인가?

• 시간 규칙: 야간 발송 금지, 주말 중지, 업무시간 내 실행 같은 제한이 필요한가?

• 비용·횟수 한도: 1회 요청, 1일 사용량, 월간 예산 한도를 얼마로 둘 것인가?

• 중지 조건: 어떤 상황이 오면 자동으로 멈출 것인가?

• 로그 항목: 나중에 문제를 추적하려면 무엇을 반드시 기록해야 하는가?

이 캔버스를 채우고 나면, 여러분의 AI 비서는 훨씬 덜 화려해 보일 수 있습니다. 대신 훨씬 더 실전적이 됩니다. 그리고 실전에서 오래 살아남는 건 대개 이런 비서입니다.

작은 불편을 설계하면 큰 사고를 막을 수 있다

좋은 AI 비서는 "뭐든 다 해드릴게요"라고 말하지 않습니다. 오히려 "여기까지는 제가 바로 할게요. 여기부터는 확인이 필요해요"라고 말하는 비서가 더 믿을 만합니다. 그 선이 분명할수록, 여러분은 더 안심하고 더 많은 일을 맡길 수 있습니다.

다음 장에서는 이렇게 안전장치를 갖춘 AI 비서를 실제로 시험해 보고, 실패 사례를 바탕으로 더 똑똑하게 다듬는 방법을 살펴봅니다. 안전하게 맡길 수 있어야, 그다음에 잘 맡길 수 있습니다.

참고

¹OWASP AI Agent Security Cheat Sheet

²n8n - Security, control, human-in-the-loop, audit logs

³Zapier - governed AI automation, controls, audit visibility