파트 6 · 하나의 에이전트, 다섯 개의 플랫폼
"루프 내 인간(Human in the loop)"은 종종 체크박스처럼 취급됩니다. 흐름의 어딘가에서 사람이 승인 버튼을 클릭하는 식입니다. 이것은 디자인이 아닙니다. 진정한 디자인은 에이전트가 정확히 어디서 멈추는지, 사람이 무엇을 보게 되는지, 그 승인이 무엇을 허용하는지, 그리고 아무도 답변하지 않을 경우 무슨 일이 일어나는지를 명확하게 정의합니다.
본 파트는 플랫폼에 어떤 것이 개입되기 전에 송장 예외 처리 에이전트의 이러한 결정들을 확정합니다. Part 11부터 작성되는 모든 빌드는 이 방식대로 구현해야 합니다.
Where the invoice agent stops and asks
세 가지 게이트 지점
[Part 2]의 흐름을 따라가면, "사람이 결정해야 하는가?"라는 질문에 답하는 세 곳이 있습니다.
게이트 1: 설계상 게이트 없음 (허용 오차 범위 내)
합의된 허용 오차 범위 내에서 구매 주문서(PO)와 영수증이 일치하는 송장은 규칙에 따라 자동으로 마감됩니다. 에이전트도, 조정 작업도, 사람의 개입도 필요 없습니다.
이는 공백이 아니라 의도적인 결정입니다. 수천 건의 올바른 송장에 사람이 개입하게 하면, 그들은 읽지 않고 승인 버튼을 누르는 습관을 들이게 되어 중요한 게이트가 약해집니다. 허용 오차 범위 자체는 재무 부서(finance)가 설정하고 소유하며, 변경하는 것은 에이전트가 건드릴 수 있는 것이 아니라 통제된 변화입니다.
게이트 2: ERP에 쓰기 전
post_invoice_adjustment를 통해 가격, 수량 또는 전기(posting)를 변경하기 전에, 권한을 가진 사람이 특정 제안을 승인해야 합니다. 이것이 돈을 보호하는 게이트입니다.
에이전트는 모든 것을 준비합니다: 예외 유형, 증거 자료(PO 라인, 영수증, 공급업체 이력, 가격 합의) 및 제안하는 정확한 조정 내역입니다. 사람은 그 하나의 제안을 승인하거나 거부합니다.
게이트 3: 공급업체와 접촉하기 전
notify_supplier가 무언가를 보내기 전에 사람이 메시지를 승인합니다. 공급업체 관계는 오래 지속되며, 잘못되거나 표현이 서툰 문의는 지연된 결제보다 더 큰 피해를 줄 수 있습니다. 에이전트는 초안을 작성하고; 사람은 전송합니다.
읽기 및 조사에는 전혀 게이트가 필요하지 않습니다. 에이전트는 필요한 만큼 송장(invoices), 구매 주문서(POs), 영수증(receipts) 및 공급업체 이력을 조회할 수 있는데, 읽기는 아무것도 변경하지 않기 때문입니다. 이것이 [Part 2]에서 읽기 전용 도구(read-only tools)를 기본값으로 설정한 이유입니다.
게이트가 프로세스 계층에 존재하는 이유
승인 확인은 프롬프트(prompt)가 아니라 프로세스 API에 있습니다. [참조 아키텍처 (reference architecture)]에서 이는 레이어 4입니다.
차이점은 간단합니다. "게시하기 전에 항상 문의하라"와 같은 프롬프트의 지침은 요청입니다. 모델은 보통 이를 따르지만, 이상한 송장, 긴 대화, 또는 혼란스러운 도구 결과는 모델을 잘못된 방향으로 이끌 수 있습니다. 프로세스 API에서의 확인은 규칙(rule)입니다. post_invoice_adjustment는 유효한 approval_id가 없는 모든 호출을 거부하고, 에이전트가 믿었던 내용과 관계없이 APPROVAL_MISSING을 반환합니다.
Series 1은 SAP 변경 승인에 대해 [휴먼 인 더 루프 게시물 (human-in-the-loop post)]에서도 같은 점을 지적했습니다. 이는 여기와 모든 다섯 개 플랫폼에서 변함없이 적용됩니다.
유효한 승인이 의미하는 것
approval_id는 늘릴 수 없다면만 유용합니다. 네 가지 규칙이 이를 엄격하게 만듭니다:
- 하나의 제안에 바인딩됨(Bound to one proposal). 승인은 하나의 송장, 하나의 액션, 그리고 하나의 금액을 다룹니다. 만약 에이전트가 승인 후 제안(예: 다른 가격)을 변경하면, 승인이 더 이상 일치하지 않아 게시물은 거부됩니다.
- 단일 사용(Single use). 한 번 사용되면 다른 송장에 재사용할 수 없습니다.
- 만료됨(Expires). 며칠 동안 사용되지 않은 승인은 오래된(stale) 것이기 때문에, 송장, PO(구매 주문서), 또는 기간이 변경되었을 수 있습니다. 만료된 승인은 거부되며, 에이전트는 다시 요청해야 합니다.
- 직무 분리(Separation of duties). 에이전트는 승인을 요청할 수는 있지만, 절대 직접 부여할 수는 없습니다. 승인자는 사람이 되어야 하며, 요청한 것과 동일한 신원이어서는 안 됩니다.
이러한 규칙들은 플랫폼에 관계없이 작동합니다. 이는 워크플로우가 생성하는 승인 기록을 대상으로 프로세스 API에서 수행하는 검사입니다.
누가 무엇을 승인하는가 (Who approves what)
승인 단계(Approval tiers)는 Part 2의 위험 사분면을 따릅니다:
- 낮은 위험(Low risk), 예를 들어 영수증 누락 또는 거의 중복되는 경우: AP 팀의 빠른 승인이 필요합니다.
- 높은 위험(High risk), 예를 들어 허용 오차를 초과하는 가격 또는 수량 변동의 경우: 해당 금액에 대한 재무 권한을 가진 승인자가 필요합니다.
- 세금 불일치(Tax mismatches): 에이전트가 증거만 제공하고, 세금 팀이 담당합니다.
- 마감된 구매 주문서(Closed purchase orders): 조달 부서(procurement)가 결정하며, 에이전트는 요약합니다.
request_approval은 예외 유형과 금액에 따라 적절한 그룹으로 작업을 라우팅합니다. 이 라우팅은 규칙이며, 에이전트의 결정이 아닙니다.
아무도 응답하지 않을 때 (When nobody answers)
승인은 누군가의 받은 편지함에 머무릅니다. 설계는 다음에 무슨 일이 일어날지 명시해야 합니다:
- 알림(Reminder): 설정된 시간이 지난 후 알림이 전송됩니다.
- 에스컬레이션(Escalation): 여전히 응답이 없다면 부서장 또는 다음 단계로 에스컬레이션됩니다.
- 안전 기본값(Safe default): 송장은 보류 상태를 유지합니다. 타이머가 만료되었기 때문에 아무것도 게시되지 않고 아무것도 전송되지 않습니다.
시간 초과는 절대 승인으로 이어져서는 안 됩니다. “응답 없음”은 “승인되지 않음”을 의미합니다.
승인자가 보는 것 (What the approver sees)
승인은 그 뒤에 있는 화면만큼만 신뢰할 수 있습니다. 최소한 승인자는 예외 유형, 제안된 조치 및 금액, 에이전트가 사용한 증거, 그리고 원본 문서로 연결되는 링크를 확인할 수 있어야 합니다. 한 번의 클릭으로 승인하거나 거부할 수 있으며, 선택적인 코멘트는 감사 추적(audit trail)에 기록됩니다. 파트 34에서는 각 플랫폼이 이를 어떻게 제시하는지 비교합니다.
이것이 구축(builds)을 형성하는 방식
각 구축마다 플랫폼이 다음을 수행할 수 있는지 확인할 것입니다:
- 제안과 증거가 첨부된 승인 작업을 생성하는 것.
- 에이전트의 작업을 일시 중지하고 결정이 도착했을 때 재개하는 것.
- 프로세스 API(process API)가 검증할 수 있는
approval_id를 반환하는 것.
- 누가 무엇을 언제 승인했는지에 대한 감사 추적(audit trail)을 유지하는 것.
이러한 기능들은 [scorecard]의 인간 개입 루프(human-in-the-loop) 기준과 직접적으로 연결됩니다.
게이트를 어디에 둘까요?
본 시리즈는 가상의 회사에 대한 참고 구축(reference build)을 설명합니다. 제품 기능은 2026년 10월 기준의 공급업체 문서를 기반으로 하므로, 구축하기 전에 최신 문서를 확인하십시오.
