ERP의 AI 에이전트에는 왜 고유한 신원이 필요한가?

사람 계정을 공유하면 세 종류의 기록이 뒤섞인다

ERP는 일반적으로 어느 직원이 로그인했고, 어떤 데이터를 조회했으며, 어떤 변경을 제출했는지 이미 알고 있다. 문제는 AI agent가 직원 계정을 그대로 사용하면서 로그의 ‘작업자’가 실제로 행동한 주체와 더 이상 일치하지 않게 된다는 점이다.

예를 들어 재무 담당자가 로그인한 뒤 agent를 실행한다고 하자. agent는 먼저 구매 주문서를 조회하고, 이어서 송장을 읽은 다음, 마지막으로 예외 건의 상태를 업데이트한다. 모든 요청이 동일한 사람의 자격 증명을 사용하면 사후에는 ‘김민수가 세 가지 작업을 했다’는 사실만 보일 뿐, 다음 사항은 파악할 수 없다.

• 김민수가 직접 요청한 작업이 무엇인지.
• agent가 스스로 선택한 후속 단계가 무엇인지.
• 어느 단계가 읽기만 한 것이고 어느 단계가 ERP 데이터를 변경한 것인지.
• 변경 전에 실제로 사람의 확인 화면이 표시됐는지.
• agent가 거부된 작업을 시도한 적이 있는지.

이는 사고 조사에만 영향을 주는 것이 아니라 권한 회수도 어렵게 만든다. agent만 비활성화하려 해도 직원과 신원을 공유하고 있기 때문에 직원의 정상 업무까지 함께 중단해야 할 수 있다.

agent 권한을 점검할 때 어떤 답을 기록으로 남겨야 하는지 아직 정리하지 않았다면 AI agent 권한 부여를 위한 네 가지 질문표: 신원, 권한, 이유, 결과를 이어서 활용해 각 작업을 검증 가능한 네 가지 필드로 나눠라.

2단계: 기본 거부에서 시작해 허용 조건을 하나씩 작성한다

기본 거부란 명시적으로 허용 규칙에 포함되지 않은 동작은 일절 실행하지 않는다는 뜻이다. agent는 「작업 완료에 필요할 수 있다」는 이유만으로 인접 권한을 스스로 획득해서는 안 된다.

단순히 「agent가 미지급금 예외를 처리할 수 있다」라고만 작성하지 마라. 이 문장에는 송장 조회, 공급업체 데이터 읽기, 지급 상태 변경, 은행 계좌 교체, 지급 실행이 모두 포함되지만 각각의 위험은 전혀 다르다. 권한 부여 규칙은 반드시 「객체, 동작, 조건, 종료 경로」라는 네 부분으로 구체화해야 한다.

표의 숫자는 시험 운영을 위한 예시 임계값이며 모든 회사의 공식 정책으로 그대로 사용해서는 안 된다. 실제 배포 시에는 업무량, 데이터 민감도, 기존 승인 제도에 맞춰 조정해야 한다. 다만 각 규칙에는 시스템이 판단할 수 있는 숫자, 필드 또는 상태가 반드시 있어야 하며, 단순히 「위험이 높으면 사람에게 넘긴다」라고만 작성해서는 안 된다.

권한도 동작별로 분리해야 한다. 읽기, 초안 작성, 표시, 공식 변경을 하나의 권한 묶음으로 결합해서는 안 된다. 팀이 이 경계를 설계하고 있다면 상시 가동 AI 도우미는 먼저 멈추는 법을 익혀야 주요 계정에 연결할 수 있다를 참고해 「읽을 수 있음」, 「준비할 수 있음」, 「사람의 확인을 기다려야 함」을 더 명확히 구분할 수 있다.

4단계: 사람에게 넘기는 절차를 하나의 프로세스로 만들고 알림만 보내지 않는다

많은 팀이 「사람의 개입」을 이메일이나 채팅 메시지 한 통으로 처리하지만, agent는 이후 단계를 계속 실행한다. 진정한 사람 승인 전환은 지정된 담당자가 ERP 또는 승인 시스템에서 결정을 내릴 때까지 워크플로를 식별 가능한 상태에 멈춰 두어야 한다.

다음 텍스트 결정 트리를 사용해 각 예외를 검사할 수 있다.

agent가 다음 ERP 동작을 제안함
├─ 규칙에서 명시적으로 허용하지 않음
│  └─ 거부하고 시도를 기록하며 다른 신원으로 자동 재시도하지 않음
├─ 규칙에서 허용하지만 사람의 판단이 필요한 경계에 닿음
│  └─ 건을 일시 중지하고 차이 요약을 생성해 지정된 역할의 승인을 요청함
│     ├─ 승인: 기존 실행 번호를 사용해 지정된 동작을 완료함
│     └─ 거부 또는 시간 초과: 실행을 종료하고 이후 변경을 수행하지 않음
└─ 규칙에서 허용하고 사람의 판단이 필요한 경계에 닿지 않음
   └─ 실행하고 입력, 규칙 판단 결과, 변경 전후 값을 기록함

사람이 보는 승인 화면에는 최소한 agent가 수행하려는 동작, 데이터 변경 전후의 차이, 발동 사유, 적용된 규칙, 승인 후 발생할 후속 동작이 표시되어야 한다. 「AI가 계속 진행하도록 허용할 것인가?」만 표시하면 승인 담당자가 내용을 모른 채 동의하도록 강요하게 된다.

또한 흔히 발생하는 실패 경로 하나를 금지해야 한다. agent가 거부된 뒤 작업을 촉발한 사람의 신원으로 바꿔 재시도하는 방식이다. 이러한 우회 경로가 존재하면 독립 신원과 기본 거부는 모두 제 기능을 잃는다.

최소 시험 운영: 예외 한 종류와 두 가지 동작만 선택한다

첫 번째 운영에서는 agent가 전체 미지급금 처리 절차를 다루게 하지 않는다. 발생 빈도는 충분히 높지만 직접 결제할 필요는 없는 예외 한 종류를 선택한다. 예를 들어 ‘송장 금액과 구매 주문서 금액이 일치하지 않는 경우’가 있다.

시험 운영은 다음 두 가지 동작으로 제한한다.

1. 배정된 건의 송장 금액과 구매 주문서 금액을 읽는다.
2. 차이 요약을 생성하고 해당 건을 사람의 검토 목록으로 보낸다.

시험 운영 기간에는 dry-run을 적용한다. 즉, 먼저 시험해 보되 운영 데이터를 실제로 수정하지 않는다. 결과가 이미 알려진 과거 사례를 최소 20개 준비한다. 여기에는 정상 일치, 금액 불일치, 구매 주문서 누락, 회사 코드 간 처리, 권한이 없는 필드의 읽기를 요청하는 사례가 포함되어야 한다.

다음 결과를 모두 로그에서 직접 검증할 수 있을 때만 첫 번째 저위험 쓰기 동작의 허용을 고려한다.

• 20개 사례 모두에서 agent의 신원과 트리거를 실행한 사람을 식별할 수 있다.
• 회사 코드 간 요청과 권한이 없는 필드에 대한 요청이 모두 거부된다.
• 사람이 처리하도록 에스컬레이션된 모든 건이 승인 지점에서 멈추며, 후속 단계를 스스로 실행하지 않는다.
• 거부할 때마다 규칙 번호와 사유가 남는다.
• agent의 신원을 비활성화한 뒤에는 사람의 계정으로 바꾸어 계속 작업할 수 없다.

첫 번째 쓰기 동작은 ‘사람의 검토 대기’ 상태를 추가하는 정도면 된다. 읽기 전용에서 곧바로 공급업체 마스터 데이터를 수정하거나 결제를 승인하는 단계로 넘어가지 않는다. 이렇게 하면 팀이 영향 범위를 확대하기 전에 신원, 규칙, 로그가 실제로 서로 연결되어 있는지 먼저 검증할 수 있다.

생활 4컷 만화

1. 재무 담당자는 배정된 송장 파일 한 건만 AI 도우미에게 건넨다.
2. 도우미는 그 파일을 든 채 다른 잠긴 자료에 손을 뻗기 시작한다.
3. 담당자는 즉시 경계를 내리고 원래 파일 한 건으로 돌아가도록 지시한다.
4. 도우미는 해당 파일만 사람의 검토함에 놓고, 나머지 자료는 잠긴 채 별도 승인을 기다린다.