AI 자동 발주를 맡기면, 팀장이 승인한 수량과 실제 주문이 달라질 수 있습니다

🍎 바쁘다면 알짜배기만이라도 !

• AI 자동 발주에 승인 뒤 바뀐 수량을 막는 장치가 없으면, 팀장이 "A사에 부품 10개 발주"를 승인했어도 실제 주문은 100개로 나갈 수 있습니다.
• 같은 요청 4건(수량 변경, 거래처 변경, 기한이 지난 승인, 이미 한 번 쓴 승인)을 두 방식으로 각각 시험했습니다. '승인했는지'만 보는 방식은 4건 모두 통과시켰고, '승인한 내용과 실제 주문이 같은지'까지 보는 방식은 4건 모두 막았습니다.
• 승인한 뒤 바뀐 주문이 다시 승인받지 않고 확정될 수 있다면, 사람이 확인하지 않고 AI가 주문을 내보내는 무인 발주는 미뤄야 합니다.

10개를 승인했는데 100개가 나가는 경우

구매팀장이 화면에서 "A사 부품 10개 발주"를 확인하고 승인 버튼을 눌렀다고 해 봅시다. 그 뒤에 주문서를 만들어 A사에 실제로 보내는 일은 AI 자동 발주가 맡습니다. 그런데 승인과 발송 사이에 자동화가 요청을 고쳐서 수량이 100개로 바뀌었다면 어떻게 될까요?

'승인됐는가'만 확인하는 시스템은 100개 주문을 그대로 보냅니다. '누군가 승인했는가'와 '이 내용을 승인했는가'는 다른 질문입니다. 승인한 내용과 실제 주문이 같은지 맞춰 보는 절차를 '승인-실행 대조'라고 부르겠습니다.

승인 여부만 보는 방식과 내용까지 대조하는 방식의 비교 시험

2026년 9월 28일, 작은 시험 프로그램으로 두 방식에 같은 요청을 넣었습니다. 한쪽은 승인이 있는지만 보고, 다른 쪽은 승인한 거래처·품목·수량이 같은지, 기한이 지나지 않았는지, 이미 쓴 승인은 아닌지까지 봅니다. 허용되면 시험용 주문 한 건이 기록됩니다. 실제 ERP도, AI도, 고객 계정도 쓰지 않았습니다.

승인한 내용 그대로 요청하면 두 방식 모두 통과시켰고, 승인이 없으면 두 방식 모두 막았습니다. 차이는 네 경우에서 났습니다.

• 수량을 10개에서 100개로 바꾼 요청
• 거래처를 A에서 B로 바꾼 요청
• 승인 기한이 지난 뒤의 요청
• 이미 한 번 쓴 승인으로 다시 한 요청

'승인했는지'만 보는 방식은 네 경우 모두 주문을 기록했고, '내용까지 맞춰 보는' 방식은 네 경우 모두 기록하지 않았습니다.

이 시험은 일부러 구성한 조건의 비교입니다. 두 주문이 동시에 들어오는 경우나 승인 기록을 누가 고치는 경우는 검사하지 않았습니다. (macOS, Python 3.10.11)

자동화 전용 계정이 할 수 있는 일의 범위

AI 발주 자동화를 직원 계정에 연결하는 대신 자동화 전용 회사 계정을 따로 만들면 충분할까요? 비교 시험은 발주 한 건의 내용이 바뀌는 경우였고, 이번에는 계정이 발주 말고 다른 일까지 할 수 있는 경우입니다. 그 계정으로 거래처 정보 수정과 주문 취소까지 할 수 있다면, 승인 검사 밖의 일이 일어날 수 있습니다.

Deloitte의 Tech Trends 2026(2025-12-10)은 AI가 스스로 일을 이어 가는 프로그램(AI 에이전트)에 맡길 판단의 범위를 정하라고 설명합니다. 계정 이름만 바꿔서는 이 범위가 정해지지 않습니다. 보안 단체 OWASP의 LLM06:2025(과도한 권한) 원문은 문서를 읽으려고 AI에 붙인 도구가 문서 수정·삭제 권한까지 갖고 있던 경우를 사례로 들고, 허용 여부를 AI의 판단에 맡기지 말고 그 도구가 접속하는 시스템(발주라면 ERP)에서 검사하라고 밝힙니다.

'발주 외 작업은 하지 마'라는 지시문은 AI의 판단에 맡기는 방식이므로, 이것만으로는 범위를 제한했다고 볼 수 없습니다. 거래처 수정 같은 기능을 아예 주지 않거나, 연결한 계정에서 그 권한을 빼야 합니다.

승인 뒤 수량·거래처·품목이 바뀐 주문의 재승인

구매팀장이 확인한 목록에 자동화가 새 품목을 덧붙였다면, 기존 품목만 실행하거나 바뀐 목록을 다시 보여 줘야 합니다.

OWASP의 거래 승인 안내(Transaction Authorization)도 같은 방향입니다. 로그인과 거래 승인을 구분하고, 승인 여부는 화면이 아니라 주문을 받는 쪽 시스템(서버)에서 검사하고, 내용이 바뀌면 기존 승인을 무효로 하고 다시 받고, 실행 직전에 마지막으로 확인하라고 합니다.

여러 건을 묶어 승인한다면 품목·수량·적용 기한을 확정하고, 그 뒤에 들어온 요청은 그 묶음에 넣지 않아야 합니다. '오늘 발주 처리해'라는 말만 남기고 주문 목록을 계속 바꾸면, 무엇을 승인했는지 알 수 없게 됩니다.

검사를 거치지 않고 주문을 확정하는 경로

비교 시험은 모든 주문이 검사를 거친다는 전제로 진행했습니다. 실제로 AI가 같은 계정의 다른 화면이나 도구로 주문을 직접 확정할 수 있다면, 그 길에도 같은 검사가 있어야 합니다.

판단 기준은 둘입니다.

• 승인한 뒤 바뀐 주문이 다시 승인받지 않고 확정될 수 있다면, 무인 발주를 미룹니다.
• 지금 쓰는 ERP가 내용이 바뀌면 승인을 취소하고 승인되지 않은 주문을 주문 받는 쪽 시스템에서 거부한다면, 같은 기능을 새로 만들 필요가 없습니다. 그 검사가 자동화 계정에도 적용되는지만 확인하면 됩니다.

주문을 넣는 곳이 외부 사이트이고 승인 내용을 거래마다 검사하는 기능이 없다면, 우리 쪽에서 그 기능을 임의로 추가할 수 없습니다. 이때는 사람이 최종 확정을 맡고, 자동화는 조회와 입력 준비까지만 하는 안이 있습니다.

이 기준은 운영 계정이 아닌 시험 환경에서 승인 뒤 수량 변경, 이미 쓴 승인의 재요청, 검사를 거치지 않는 발주 경로를 각각 요청하고, 거부 기록이 남고 주문이 생기지 않는지 보면 알 수 있습니다.