AI에게 권한을 얼마나 줘도 될까요?

팀원마다 AI에게 준 권한이 제각각입니다. 어떤 사람은 읽기만, 어떤 사람은 자료 작성까지, 어떤 사람은 이메일 발송까지 허용돼 있습니다. 딱히 기준이 있어서가 아니라, 그때그때 필요하다고 해서 하나씩 열어준 결과입니다. 팀장은 생각합니다. “이거 관리하기 너무 번거로운데. 그냥 다 같은 권한을 주면 편하지 않을까?”

같은 권한인데, 한 사람은 “공개된 제품자료를 요약”하고 다른 사람은 같은 권한으로 “고객에게 이메일을 자동 발송”하고 있었습니다. 잘못됐을 때의 결과는 전혀 다릅니다.

“이 사람한테는 권한을 얼마나 줘야 할까?”가 아니라, 더 정확하게 물어야 합니다. 이 업무가 잘못됐을 때, 영향이 어디까지 갑니까? 되돌릴 수 있습니까? 권한은 사람이 아니라 업무를 기준으로 정합니다.

이 원칙이 최소 권한 원칙(Least Privilege)입니다. 보안 분야에서 오래 써온 원칙이지만, AI 에이전트로 오면 조금 다르게 적용됩니다. 사람에게는 역할 기준으로 한번 정하면 계속 유지되는 권한을 주지만, AI 에이전트는 업무 하나하나가 짧고 반복적입니다. 그래서 상시로 권한을 열어두는 대신, 작업을 실행하는 동안에만 필요한 최소한의 범위를 그때그때 내주고 끝나면 거둬들이는 방식이 표준으로 자리 잡고 있습니다.

팀원들의 업무를 영향도로 나눠보니, 잘못돼도 되돌리기 쉬운 업무(자료 요약, 초안 작성)와 잘못되면 외부에 영향을 주는 업무(이메일 자동 발송, 주문·결제 실행)가 같은 권한 기준으로 묶여 있었습니다. 위험한 업무를 전부 막거나 전부 열어두는 이분법이 아니라, 영향도에 따라 통제 수준 자체를 다르게 가져가야 합니다.

팀에 실수 한 번 없는 직원이 있습니다. “이 사람한테는 그냥 다 열어줘도 되지 않을까?”

여기서 빠진 게 있습니다. 그 직원이 실수를 안 하는 것과, 그 직원의 계정이나 AI 세션이 안전한 것은 별개의 문제입니다. 계정 탈취, 프롬프트 오조작, AI의 예상치 못한 동작 — 사람의 신뢰도와 무관하게 발생할 수 있는 위험들입니다. 신뢰는 권한의 근거가 될 수 없습니다.

넓은 권한을 여는 것은 효율을 높이는 것이 아니라, 문제가 생겼을 때의 위험 범위를 함께 키우는 것입니다. Gartner도 같은 지점을 짚었습니다 — 다만 “권한을 아예 안 주거나, 다 주거나”가 아니라 자율성 단계를 구분해서 관리하는 문제로 봤습니다.

AI가 업무를 처리하는 흐름은 읽기 → 작성 → 수정 → 전송 → 실행입니다. 모든 단계마다 사람이 확인하면 AI를 쓰는 의미가 없고, 아무 데도 확인하지 않으면 Human Oversight가 사라집니다. 정확한 질문은 “모든 단계를 볼 것인가”가 아니라 “되돌릴 수 없는 지점이 어디인가”입니다.

승인은 영향이 큰 행동, 되돌릴 수 없어지는 지점 직전에 둡니다. 전송·실행 앞에 게이트를 두고, 그 앞 단계는 AI가 그대로 진행합니다.

게이트를 정한 것만으로는 부족합니다. “사람이 확인한다”고 했을 때 그 사람이 누구인지가 빠져 있으면 게이트는 이름뿐인 절차가 됩니다. 팀장은 세 가지를 함께 정합니다 — 누가 승인하는가, 문제가 생겼을 때 누가 멈출 수 있는가, 1차 보고 대상은 누구인가.

승인 게이트를 아무리 잘 설계해도 문제는 생길 수 있습니다. 예방만으로는 부족합니다. 중단시킬 버튼이 실제로 있는가, 누를 수 있는 사람이 명확한가, 중단 후 무엇부터 복구하는가 — 이 세 가지가 중단·복구 절차입니다.