💳 02. 승인과 권한은 어떻게 설계되나

에이전트 결제에서 가장 먼저 설계해야 할 것은 결제수단이 아니라 권한 구조다. 같은 모델이라도 누가 승인권을 갖고, 어느 금액까지 자동 실행되며, 로그가 어떻게 남는지에 따라 위험 수준이 완전히 달라진다.

쉽게 말해 에이전트를 “직원”처럼 다루면 된다. 모든 결정을 혼자 하게 두지 않고, 역할과 한도를 나눠서 맡기는 식이다.

flowchart TD
A[요청 감지] --> B{정책 체크}
B -->|소액·반복| C[자동 실행]
B -->|중간 금액| D[담당자 승인]
B -->|고위험·예외| E[관리자 승인]
C --> F[로그 저장]
D --> F
E --> F

무엇을 먼저 나눠야 하나

첫 번째는 금액 한도다. 월 한도와 1회 한도를 따로 두면 작은 반복 지출과 큰 단발 지출을 구분하기 쉬워진다. 두 번째는 공급사 범위다. 이미 승인된 벤더만 허용할지, 신규 벤더도 탐색할지 정책이 달라져야 한다. 세 번째는 목적 제한이다. 광고비, API 비용, 소프트웨어 구독처럼 카테고리를 분리해야 사고가 줄어든다.

칠판 치트시트

Note

• 권한 설계의 핵심은 금액, 대상, 목적, 시간 네 축이다.
• 자동 실행보다 로그 보존이 더 중요하다.
• 예외 상황은 반드시 사람 단계로 되돌아와야 한다.
• 승인 없는 자율보다 승인 있는 반자동이 먼저 보편화된다.

현장형 미니 사례

한 운영팀은 월간 API 충전은 자동으로 돌리되, 신규 공급사 결제는 항상 담당자 승인으로 묶을 수 있다. 이렇게 하면 반복 지출은 빠르게 처리하면서도 사기나 오결제 위험은 낮출 수 있다.

또 다른 예는 마케팅 조직이다. 기존 광고 플랫폼 안에서 예산 재분배는 에이전트가 실행하되, 예산 총액 증액은 팀장 승인으로 넘기는 방식이 자연스럽다. 같은 광고비여도 권한 단위가 다르기 때문이다.

실제 글에서 풀 핵심 질문

• 소액 자동 승인 기준은 어디까지가 적절한가
• 신규 공급사는 왜 별도 승인 라인에 묶어야 하나
• 감사 로그는 어떤 필드를 남겨야 하나
• 사람이 마지막에 개입해야 하는 예외는 무엇인가

다음 글

• 💳 03. 어떤 결제레일이 남을까

이 글은 AI를 활용해 초안을 정리했으며, 후속 보강 때는 실제 Spend Management·Procurement 사례와 공식 문서를 추가 확인해 업데이트한다.