재무 부서가 AI agent를 만들었다. 여러 단계의 작업을 스스로 이어서 하는 AI 도우미다. 구매, 송장, 지급을 관리하는 핵심 시스템인 ERP의 송장과 발주서를 읽고, 금액이나 거래처 정보가 맞지 않는 항목을 찾아, 예외를 재무 담당자에게 넘긴다. 시험할 때 수고를 덜려고 어느 재무 담당자의 계정을 그대로 쓰게 했다. 조회도 되고 수정도 됐다. 그런데 누군가 물었다. “이 거래처 계좌 정보는 직원 본인이 바꾼 건가, AI가 바꾼 건가?” 로그에는 같은 직원 계정만 남아 있어 답할 수 없었다.
2026년 7월, AWS는 AI agent로 SAP 같은 ERP의 예외를 처리하는 방식을 공개했다. 설계의 핵심은 모델이 아니라 신원이다. agent가 스스로 일할 때는 자기 서비스 계정으로 로그인하고, 사람이 끼어들면 시스템이 그 사람의 확인된 신원으로 바뀐다. 모든 동작은 기본적으로 거부되고, 명시적으로 허용한 것만 통과한다. 금액이 기준을 넘거나 AI의 확신이 부족하면 담당자에게 메일을 보내고, 사건을 사람의 답을 기다리는 상태로 두고 멈춘다. 모든 단계는 추가만 되고 수정이나 삭제는 안 되는 로그에 기록된다.
이 방식은 어떤 시스템에도 가져갈 수 있다. AI가 재무 데이터에 손댈 수 있게 되는 순간 자기 신원이 있어야 한다. 그래야 로그에서 어떤 것은 AI가 했고 어떤 것은 사람이 승인했는지 가릴 수 있다.
직원 계정을 그대로 쓰면 로그로는 누가 했는지 알 수 없다
직원 계정을 빌려 쓰면 로그의 “작업자"가 실제로 손댄 쪽과 달라진다. 직원이 agent를 시작하고, agent가 발주서를 조회하고, 송장을 읽고, 사건 상태를 바꾼다. 나중에 보이는 것은 “아무개가 동작 세 개를 했다"뿐이다. 어느 것을 직원이 직접 요청했는지, 어떤 후속 단계를 agent가 스스로 골랐는지, 데이터를 바꾸기 전에 사람의 확인 화면이 떴는지, agent가 거부된 동작을 시도했는지는 알 수 없다.
권한을 회수하기도 어려워진다. agent만 멈추고 싶어도, 직원과 신원을 함께 쓰고 있어서 직원의 평소 업무까지 같이 멈출 수밖에 없다.
자기 신원, 기본 거부, 기준을 넘으면 사람에게
자기 신원: 시스템이 이 신원을 따로 승인하고, 멈추고, 조회할 수 있어야 한다. 표시 이름 뒤에 “Bot"을 붙이는 것만으로는 부족하다. 신원은 한 가지 용도에 묶는다. 예를 들어 “매입 채무 송장 예외 처리"처럼 하고, 재무 부서 전체가 함께 쓰는 AI 계정으로 만들지 않는다. 권한을 승인하고, 경고를 처리하고, 신원을 멈출 수 있는 담당자를 한 명 정한다. 교체하고 회수할 수 있는 기계용 인증 정보를 쓰고, 직원의 비밀번호를 agent에게 주지 않는다.
기본 거부: 먼저 모든 것을 막고, 필요한 동작을 하나씩 연다. AWS의 예는 모든 발주서 조회는 허용하되, 분개 전기는 5만 달러 미만만 허용하는 것이다. AWS 공식 문서에 따르면 그 권한 규칙은 어떤 허용 규칙에도 맞지 않는 요청은 모두 거부하고, 명시적인 금지는 언제나 허용보다 우선한다.
기준을 넘으면 사람에게: agent가 반드시 멈추고 사람에게 넘겨야 하는 경우를 분명히 적는다. 예를 들어 금액이 중요성 기준을 넘을 때, 거래처 계좌 정보를 바꿀 때, AI가 스스로 확신이 부족하다고 판단할 때. 사람에게 넘길 때는 “확인해 주세요"만 던지지 말고 근거와 제안을 함께 붙인다.
신원을 대화로 주장하게 하지 말고 시스템이 확인해야 하는 이유는 AI 고객지원이 계정을 바꾸기 전에, 본인 확인은 대화가 아니라 시스템이 해야 한다를 참고하자. 여러 시스템을 오갈 때 들르는 곳마다 권한을 어떻게 바꿀지는 AI agent가 여러 시스템을 오가며 일한다면, 들르는 곳마다 새 열쇠로 바꿔야 한다를 참고하자.
먼저 적은 수의 예외로 읽기 전용 시험을 한다
처음부터 agent에게 실제 데이터를 고치게 하지 않는다. 이미 처리한 예외를 조금 골라, agent가 자기 신원으로 읽기 전용으로 한 번 돌게 하고, 그 판단이 재무 담당자가 실제로 처리한 것과 맞는지 비교한다. 그다음 로그가 agent의 동작과 사람의 동작을 나누고 있는지, 거부된 시도가 기록에 남는지 확인한다. 이 모든 것이 보이게 된 뒤에 수정 권한을 하나씩 연다.
신원을 나눈다고 판단이 맞아지는 것은 아니다
자기 신원이 있으면 책임은 추적할 수 있지만, agent의 판단이 옳다는 보장은 없다. 기준을 너무 높이면 위험이 빠져나가고, 너무 낮추면 모든 사건이 사람에게 넘어가 자동화의 의미가 사라진다. 기준은 재무 책임자가 회사의 중요성 기준에 따라 정하고, 사람에게 넘어간 사건의 비율을 주기적으로 돌아본다.
또 이 글이 다루는 것은 방식이지 특정 제품의 추천이 아니다. ERP와 신원 시스템에 따라 구현 방식은 다르다. 중요한 것은 “누가 했는지 가릴 수 있다"와 “허용하지 않은 것은 할 수 없다"는 두 원칙이다.
AI 정리 카드
AI agent에게 ERP 안의 예외(송장 불일치, 지급 예외 등)를 처리하게 하려고 한다. 먼저 그 신원과 권한을 설계해 두고 싶다.
판단 방법은 이 글에서 가져왔다: https://boosterminiclass.com/ko/posts/erp-agent-separate-identity-deny-by-default/
글의 관점은 이렇다. AI agent가 직원 계정을 빌려 쓰면 안 된다. 그러면 로그에서 사람이 했는지 AI가 했는지 가릴 수 없고, AI만 멈출 수도 없다. agent에게 자기 신원을 주고, 모든 동작을 기본적으로 거부한 뒤 하나씩 열고, 금액이 기준을 넘거나 확신이 부족하면 멈추고 사람에게 넘기게 한다.
먼저 나에게 물어 달라. agent가 어떤 종류의 예외를 처리할지, 어떤 데이터를 읽을지, 어떤 데이터를 바꿀 수 있는지, 지금 어떤 계정으로 시험하고 있는지.
그다음:
1. agent의 신원 설계를 적을 것. 용도 이름, 서비스 범위, 담당자, 인증 정보 종류와 교체 방식;
2. 기본 거부 권한 목록을 쓸 것. 명시적으로 허용하는 읽기와 수정 동작, 각각의 조건(금액 상한 등), 명시적으로 금지하는 동작(거래처 계좌 정보 변경 등);
3. 반드시 멈추고 사람에게 넘길 상황과, 넘길 때 붙일 정보를 적을 것;
4. 읽기 전용 시험을 설계할 것. 이미 처리한 어떤 사건들을 쓰고, 무엇을 비교하고, 로그에서 무엇이 보여야 하는지.
기준 금액은 "재무 책임자가 정함"으로 표시하고, 직접 숫자를 정하지 말 것.
참고 자료
- AWS for SAP Blog (official): AWS Agentic Standard Operating Procedures (SOPs) for ERP Automation — https://aws.amazon.com/blogs/awsforsap/aws-agentic-standard-operating-procedures-sops-for-erp-automation/ (2026-07-08)
- Help Net Security: AWS gives its ERP agent deny-by-default rules and a separate identity — https://www.helpnetsecurity.com/2026/07/10/aws-agentic-ai-erp-automation/ (2026-07-10)
- AWS official documentation: Writing policies in natural language - Amazon Bedrock AgentCore — https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy-natural-language.html [accessed: 2026-10-11]
