메일을 정리하고, 보고서 초안을 쓰고, 거래처에 보낼 문서를 만드는 일에 AI를 붙이려는 팀이 늘고 있습니다. 이때 가장 먼저 부딪히는 질문은 어떤 모델을 쓰느냐가 아닙니다. AI에게 어디까지 손대게 할 것인가입니다. 이 글은 특정 고객사의 도입 결과를 보고하는 사례가 아니라, DMS.Labs가 다루는 업무 자동화와 AX 설계의 한 대목을 실무 가이드로 풀어 쓴 것입니다. 어떤 팀에든 적용할 수 있게 일반적인 순서만 다룹니다.
핵심 방법은 단순합니다. 권한을 한 번에 주지 않고 읽기, 초안, 실행의 세 단계로 나눠 차례로 넓힙니다. 각 단계에서 쓸 만한지 확인한 뒤에만 다음 단계로 올라갑니다.
왜 한 번에 주면 위험한가
AI가 도구를 호출할 수 있게 되면 말만 하던 프로그램이 실제로 무언가를 바꾸는 프로그램이 됩니다. 메일을 보내고, 파일을 지우고, 시스템에 값을 기록할 수 있습니다. OWASP의 LLM 위험 목록은 이를 과도한 대리 권한(Excessive Agency)이라는 항목으로 설명합니다. 예상 밖이거나 모호하거나 조작된 모델 출력에 반응해 해로운 행동이 실행되는 취약점이며, 원인이 모델의 착오든 외부에서 끼워 넣은 지시든 상관없이 생긴다고 합니다. 같은 문서는 뿌리를 세 가지로 꼽습니다. 기능이 필요 이상으로 많은 경우, 권한이 필요 이상으로 큰 경우, 그리고 자율성이 필요 이상으로 높은 경우입니다.
일상의 업무에 옮기면 이렇게 읽힙니다. 메일 요약만 시키려는데 메일 삭제와 발송까지 되는 도구를 연결했다면 기능이 과한 것입니다. 읽기만 필요한데 쓰기 권한이 있는 계정으로 연결했다면 권한이 과한 것입니다. 사람이 확인하지 않아도 되는 설정이라면 자율성이 과한 것입니다. OWASP 문서의 사례도 이와 닮았습니다. 받은 메일을 요약하는 비서에 메일 발송 기능까지 붙어 있었고, 악의적으로 짜인 메일이 AI에게 받은편지함의 민감한 정보를 외부로 보내라고 시키는 공격이 가능했다는 시나리오입니다. 읽기 기능만 가진 도구를 쓰고, 읽기 전용 권한으로 연결하고, 사람이 보내기 버튼을 직접 누르게 하면 막을 수 있다고 같은 문서는 설명합니다.
여기서 얻을 수 있는 실무 원칙은 어렵지 않습니다. AI가 틀릴 수 있다고 가정하고, 틀렸을 때 피해가 작도록 권한을 설계합니다. 모델이 똑똑해지면 이 설계가 필요 없어지는 것이 아닙니다. 설계가 되어 있을 때 똑똑한 모델의 이점을 안심하고 쓸 수 있습니다.
1단계: 읽기만 시킨다
첫 단계에서 AI는 자료를 읽고 요약하거나 분류하거나 질문에 답하는 일만 합니다. 어떤 시스템도 바꾸지 못합니다. 메일 함의 읽기, 문서 폴더의 조회, 보고서 초안의 검토가 여기에 속합니다. 이 단계의 목적은 두 가지입니다. 하나는 AI가 우리 업무 자료를 얼마나 정확히 이해하는지 보는 것이고, 다른 하나는 사람이 결과를 믿고 쓸 만한지 감각을 얻는 것입니다.
연결할 때는 읽기 전용 계정이나 읽기 전용 범위를 사용합니다. OWASP 문서는 데이터베이스에서 상품 정보를 읽어 추천하는 앱이라면 필요한 표에 대한 읽기 권한만 주고, 삽입이나 수정이나 삭제 권한을 주지 말라고 예시합니다. 이 제한은 AI에게 부탁하는 문장으로 거는 것이 아니라 연결된 계정의 권한으로 걸어야 합니다. 프롬프트에 "삭제하지 마라"고 적어 두는 것은 안전장치가 아닙니다.
이 단계에서 확인할 것은 정확도입니다. 같은 자료로 여러 번 물었을 때 답이 크게 흔들리지 않는지, 근거가 되는 문장을 제대로 가리키는지, 자료에 없는 내용을 지어내지 않는지 봅니다. 업무에서 실제로 쓰는 어려운 사례를 열 개쯤 모아 두고 매번 같은 사례로 시험하면 변화를 알아보기 쉽습니다. 정답을 아는 사람이 결과를 직접 읽고 표시해 둡니다. 읽기 단계에서 자주 틀리는 AI는 다음 단계로 올라갈 이유가 없습니다.
나무 책상 위에서 인쇄한 초안 위에 펜을 든 손과 옆에 열린 노트북.원본 전체 보기
2단계: 초안까지 만들게 한다
읽기 결과가 믿을 만하다면 AI가 산출물의 초안을 만들게 합니다. 답장 메일의 초안, 회의록 정리본, 보고서의 첫 문단, 견적서 항목 같은 것입니다. 중요한 점은 초안이 곧바로 밖으로 나가지 않는다는 것입니다. 초안은 사람이 읽고 고치고 승인하는 자리에 놓입니다.
이 단계에서 사람의 승인은 형식이 아니라 실제 검토여야 합니다. 검토자가 매번 훑어보고 승인만 누르는 상황이 되면 사실상 2단계가 3단계로 바뀐 것입니다. 이를 막으려면 검토할 항목을 구체적으로 정해 둡니다. 수신자가 맞는지, 금액과 날짜가 원본과 일치하는지, 약속하지 않은 내용이 들어가지 않았는지, 첨부 파일이 맞는지 같은 항목입니다. 초안 옆에 AI가 근거로 삼은 원본의 위치를 함께 보여 주면 검토 시간이 줄어듭니다.
OWASP 문서는 완화책의 하나로 사람이 승인하는 절차를 둘 것을 권합니다. 영향이 큰 행동은 실행 전에 사람이 승인하게 하라는 것입니다. 소셜 미디어에 글을 올리는 앱이라면 게시 기능 안에 사용자 승인 절차를 넣는 식입니다. 이 승인은 모델의 판단에 맡기지 않고, 모델 바깥의 시스템이 막아야 한다는 점도 함께 강조합니다. 모델이 허락해도 되는지 스스로 정하게 하면 안 됩니다.
나무 탁자 위 세 줄로 놓인 빈 종이 카드 중 하나를 옮기는 손.원본 전체 보기
이 단계에서 기록해 둘 것은 사람이 초안을 얼마나 고쳤는가입니다. 거의 고치지 않는 유형의 작업과 늘 크게 고치는 유형의 작업이 갈립니다. 수정이 적은 유형은 다음 단계의 후보가 되고, 수정이 많은 유형은 초안 단계에 오래 두거나 프롬프트와 입력 자료를 손봐야 한다는 신호입니다. 이 숫자는 높은 정밀도를 가질 필요가 없습니다. 작업 유형마다 손이 많이 가는지 적게 가는지만 구분해도 충분합니다.
3단계: 실행은 범위를 좁혀서 준다
실행은 AI가 직접 메일을 보내거나 기록을 바꾸거나 파일을 옮기는 단계입니다. 모든 업무가 이 단계까지 올라갈 필요는 없습니다. 올라간다면 일을 가장 좁게 잘라서 줍니다. "메일을 알아서 처리해"가 아니라 "지정한 폴더의 영수증 메일에서 금액을 읽어 지정한 시트의 한 열에 추가한다"처럼 행동과 대상을 구체적으로 고정합니다.
OWASP 문서가 권하는 방향도 같습니다. 열린 형태의 도구, 예컨대 아무 셸 명령이나 실행하거나 아무 주소나 불러오는 도구를 피하고 기능이 세분된 도구를 쓰라고 합니다. 파일에 결과를 쓰는 일이 필요하다면 셸을 열어 주지 말고 그 파일에만 쓰는 전용 기능을 만들라는 것입니다. 또 사용자를 대신하는 작업은 그 사용자의 권한 범위에서 실행하고, 최소한의 권한만 쓰라고 합니다. 모든 사용자의 파일에 접근하는 높은 권한의 공용 계정을 쓰면 한 사람의 요청이 다른 사람의 자료를 건드릴 수 있습니다.
실행 단계에서는 되돌릴 수 있는지를 먼저 묻습니다. 시트에 한 줄을 추가하는 일은 지우면 되지만, 외부로 나간 메일은 되돌릴 수 없습니다. 되돌리기 어려운 행동은 3단계에 올라가도 사람의 승인을 남겨 두는 편이 안전합니다. 삭제처럼 파괴적인 행동이나 결제, 대외 발송, 권한 변경은 기본적으로 사람이 마지막 버튼을 누르게 합니다. 이는 AI를 믿지 못해서가 아니라 사고의 비용이 비대칭이기 때문입니다.
실행 권한을 주었다면 활동 기록과 횟수 제한을 함께 둡니다. OWASP 문서는 기록과 감시, 요청 횟수 제한이 과도한 대리 권한을 막지는 못하지만 피해를 줄일 수 있다고 설명합니다. 한 시간에 보낼 수 있는 메일 수에 상한을 두면, 이상한 동작이 시작되어도 발견할 시간이 생깁니다. 기록에는 무엇을 읽었고 무엇을 실행했는지가 남아야 하며, 이상이 생겼을 때 사람이 한 번에 멈출 수 있는 정지 수단도 있어야 합니다.
단계를 올리는 기준을 미리 적는다
세 단계의 가치는 올라가는 기준을 사전에 합의해 두는 데 있습니다. 기준 없이 운영하면 편해서, 혹은 바빠서 단계가 슬그머니 올라갑니다. 작업 유형마다 한 줄씩 적어 두면 충분합니다. 예를 들어 영수증 정리는 몇 건을 연속으로 검토해 오류가 없을 때 3단계로 올린다고 적습니다. 숫자는 팀의 위험 감수 정도에 따라 다르며, 여기서는 구체적인 숫자를 권하지 않습니다. 중요한 것은 올리는 조건과 내리는 조건이 모두 있다는 점입니다. 오류가 한 번 발생하면 한 단계 낮추고 원인을 살핀다는 규칙을 포함합니다.
단계를 올릴 때는 한 번에 하나만 바꿉니다. 새 모델로 바꾸면서 동시에 실행 권한까지 올리면, 문제가 생겼을 때 원인을 가를 수 없습니다. 프롬프트를 고치거나 입력 자료를 바꾸거나 권한을 올리는 일은 각각 따로 하고 그 결과를 지켜봅니다.
NIST의 AI 위험 관리 프레임워크는 AI 시스템의 위험을 관리하기 위한 자발적 지침을 제공합니다. 이 글의 세 단계가 그 틀을 대체하지는 않지만, 규모가 커지는 조직이라면 위험을 어떻게 식별하고 측정하고 관리할지 참고할 만합니다. 작은 팀이라면 위 세 단계와 기준표만으로도 시작하기에 충분합니다.
첫 한 주를 이렇게 보낼 수 있다
처음 시작하는 팀이라면 가장 작은 반복 업무 하나를 고릅니다. 위험이 낮고 결과를 쉽게 확인할 수 있는 일이 좋습니다. 첫날에는 1단계로 AI가 자료를 읽게 하고 사람이 같은 자료를 읽은 결과와 비교합니다. 며칠 뒤에는 2단계로 초안을 만들게 하고 검토 항목 목록을 따라 승인합니다. 그동안 틀린 지점과 사람이 고친 지점을 한 장에 적습니다. 이 한 장이 쌓이면 이 업무를 3단계로 올려도 되는지, 아니면 초안에서 멈추는 것이 맞는지 근거가 생깁니다.
업무가 여러 개로 늘어나면 작업 유형별로 현재 단계를 표로 둡니다. 어떤 업무는 읽기에 머물고, 어떤 업무는 초안까지 가고, 몇몇만 실행에 이릅니다. 모든 업무를 같은 단계로 맞출 필요는 없습니다. 오히려 단계가 서로 다른 것이 정상입니다.
정리하며
AI 자동화의 성패는 모델의 성능 하나로 갈리지 않습니다. 어떤 권한을 어떤 순서로 주고, 사람이 어디에서 확인하고, 문제가 생기면 어디서 멈추는지가 함께 결정합니다. 읽기에서 초안으로, 초안에서 실행으로 올라가는 순서를 지키면 AI가 틀렸을 때의 피해를 작게 유지하면서 쓸모를 확인할 수 있습니다. 서두르는 팀일수록 이 순서가 오히려 시간을 아껴 줍니다.
이 글의 두 이미지는 책상 위의 검토 장면을 실사 필름 느낌으로 새로 생성한 것입니다. 실제 프로젝트나 고객사의 현장을 촬영한 사진이 아닙니다.
