AI 에이전트가 멋대로 회계 데이터를 바꿔버린 날 —— 가드레일, 정책 엔진, 승인 워크플로우 설계론

AI 에이전트가 업무 시스템에 직접 액세스하는 시대, 「잘못된 조작이 실행되기 전에 막는」 메커니즘이 필수적입니다. 본 기사에서는 다음의 3가지 제어 레이어(Layer)를 시스템 설계·API·권한·감사·운용의 관점에서 해설합니다.

런타임 가드레일 (Runtime Guardrail): 입력·컨텍스트 취득·도구 호출·액션 실행·출력의 5단계에서 동작을 차단하는 메커니즘 -
정책 엔진 (Policy Engine): 액세스 가능 여부·승인 필요 여부를 동적으로 판단하는 규칙/분류기 구현 패턴 -
인간 승인 워크플로우 (Human Approval Workflow): 전수 승인이 아닌 리스크 기반으로 선택적으로 개입하는 설계

많은 팀이 처음에 빠지는 오해는 **「가드레일 = 모델의 출력을 체크하는 필터」**라는 인식입니다. 챗봇이라면 그것으로 충분할지도 모릅니다. 하지만 에이전트가 도구를 호출하고, 데이터베이스를 업데이트하며, 외부 API에 쓰기를 수행하는 시스템에서는 출력 필터만으로는 이미 늦습니다.

에이전트가 이미 「봐서는 안 될 문서를 취득했다」 「실행해서는 안 될 도구를 호출했다」 「되돌릴 수 없는 트랜잭션(Transaction)을 확정했다」 —— 그 후에 출력을 필터링해도 피해를 막을 수 없습니다.

실무에서는 다음의 5가지 제어 포인트를 설계해야 합니다.

1. 의도 확인 (Intent Verification)
사용자나 트리거 이벤트의 의도가 에이전트의 이용 범위 내에 있는지 판정합니다. 예를 들어 구매 발주 에이전트라면, 사용자가 직접 발주를 생성하려고 하는 것인지, 아니면 적절한 결재(稟議) 플로우를 거치고 있는지를 확인합니다.

2. 데이터 접근 제어 (Data Access Control)
에이전트가 참조할 수 있는 문서나 데이터를 제한합니다. 재무 에이전트는 관련 회계 기준을 취득할 수 있지만, 타 부서의 기밀 메모에는 액세스하게 하지 않습니다. 고객 지원 에이전트는 현재 고객의 티켓 이력만 취득할 수 있도록 하여, 유사도만으로 다른 고객 데이터를 가져오지 않도록 합니다.

3. 도구 사용 제한 (Tool Usage Restriction)
이용 가능한 도구를 상황에 따라 제한합니다. IT 운영 에이전트는 진단 도구나 티켓 생성은 허가하지만, 운영 환경(Production)의 변경 커맨드는 실행시키지 않습니다. 고객 운영 에이전트는 권한 확인이나 환불 초안은 작성할 수 있지만, 임계치를 초과하는 환불 실행은 차단합니다.

4. 실행 제어 (Execution Control)
비즈니스 상태를 변경하는 조작이 여기에 해당합니다. 공급업체 등록, 분개 입력, 신용 한도 변경, 지급 차단 해제, 인시던트 종료 —— 이것들은 모두 「실행」의 제어 대상입니다. 기업은 「참조」 「권장」 「초안」 「실행」을 명확히 구분하고, 실행에는 반드시 가드를 겁니다.

5. 출력 필터링 (Output Filtering)
위 4가지를 통과한 후의 최종 체크입니다. 데이터 유출 방지, 적절한 톤, 근거에 기반한 응답인지를 확인합니다. 다만, 이것은 어디까지나 최종 방어선이며 주요한 가드레일은 아닙니다.

가드레일이 제어 포인트라면, **정책 엔진 (Policy Engine)**은 각 포인트에서 「허가/거부/에스컬레이션/승인 대기」를 실시간으로 판단하는 컴포넌트입니다.

정책 엔진이 없다면 제어 로직은 프롬프트, 애플리케이션 코드, 도구 설정, 팀의 관습에 산재하게 되어 일관성과 감사성을 잃게 됩니다.

정책 엔진이 고려해야 할 요소:

• 에이전트의 역할(Role)과 위임된 권한
• 비즈니스 오브젝트(Business Object)의 종류 (공급업체, 송장, 발주, 티켓, 계약, 직원 데이터)
• 트랜잭션 금액이나 중요도
• 리스크 레벨 (취소 가능한가, 여러 시스템에 영향을 주는가)
• 규제·컴플라이언스 요건

**결정론적 규칙 (Deterministic Rules)**은 명확하고 고정적인 조건에 적합합니다.

• 금액이 임계치를 넘으면 거부
• 특정 공급업체 카테고리는 승인 필수
• 심야 시간대의 운영 환경 변경은 금지
• 기밀 데이터에 대한 액세스는 항상 거부

감사·테스트·설명이 용이하지만, 비즈니스 컨텍스트가 다양해질 경우 규칙이 폭발적으로 증가합니다.

**모델 기반 분류기 (Model-based Classifier)**는 모호한 상황 판단에 사용합니다.

• 요청의 기밀성 스코어
• 케이스의 리스크 레벨
• 부정 가능성
• 사용자 의도가 스코프(Scope) 외인지 여부

유연하지만 설명성에 과제가 있으며, 정기적인 평가와 업데이트가 필요합니다. 고리스크 액션의 유일한 제어 수단으로 삼아서는 안 됩니다.

권장 패턴은 이들의 조합입니다. 분류기로 리스크 시그널을 탐지하고, 결정론적 규칙으로 최종 판단을 내립니다. 고객 운영의 예:

• 분류기가 케이스를 「고리스크」 또는 「분쟁 가능성 있음」으로 플래그(Flag)
• 결정론적 규칙이 「고리스크 케이스 또는 금액 ¥50,000 이상 → 승인 필수」라고 판단

모든 정책 판단은 다음 정보를 기록합니다.

• 평가한 정책
• 판단에 사용한 컨텍스트
• 결과 (허가/거부/에스컬레이션/승인 대기)
• 판단 시각

「시스템이 거부했기 때문에」라는 이유만으로는 감사를 견딜 수 없습니다. 「정책 X에 따라 금액 ¥1,200,000이 임계값 ¥1,000,000을 초과했으므로 승인 플로우(Approval Flow)로 에스컬레이션(Escalation)함」이라고 설명할 수 있어야 합니다.

「사람이 모든 것을 확인한다」는 것은 에이전트 도입의 가치를 반감시킵니다. 필요한 것은 **리스크 기반의 선택적 승인 (Risk-based Selective Approval)**입니다.

• 중요도 임계값을 초과하는 트랜잭션 (Transaction)
• 마스터 데이터 (Master Data)의 변경
• 직원의 권한에 영향을 미치는 판단
• 분쟁 리스크가 있는 고객 대응
• 고위험 실운영(Production) 변경
• 전문적 판단을 요하는 의사결정

가장 많은 실패 사례는 「에이전트가 액션 X를 권장합니다. 승인하시겠습니까?」 라는 알림만 보내는 것입니다. 리뷰어(Reviewer)는 혼란에 빠지고, 여러 시스템을 열어 확인해야 하는 상황에 처하며, 결국 피로가 쌓여 맹목적으로 승인하게 됩니다.

• 에이전트의 권장 내용
• 판단에 사용한 에비던스 (Evidence)
• 관련 정책
• 주요 리스크
• 신뢰도 또는 에스컬레이션 이유
• 대안 (있는 경우)

예: 환불 승인 요청에는 단순한 금액뿐만 아니라, 고객 이력, 환불 사유, 적용 가능한 권리, 유사 사례의 발생 빈도, 부정 시그널 (Fraud Signal), 그리고 왜 자동 실행하지 않았는지에 대한 이유를 포함합니다.

승인 케이스가 너무 많으면 다음과 같은 문제가 발생합니다.

• 사이클 타임 (Cycle Time) 악화
• 승인자가 병목 (Bottleneck)이 됨
• 사용자 신뢰도 저하
• 에이전트가 단순한 「큐 생성 머신 (Queue Generation Machine)」으로 전락

리스크 계층에 기반한 설계가 중요합니다.

리스크 레벨	제어 방식
저 (Low)	자동 실행 + 모니터링
...

우수한 에이전트는 「언제 행동할지」뿐만 아니라 「언제 멈출지」를 알고 있습니다. 다음과 같은 상황에서는 에스컬레이션이 필요합니다.

• 낮은 신뢰도
• 데이터 소스 간의 모순
• 정책의 모호함
• 툴 (Tool) 결과의 불일치
• 정의된 스코프 (Scope) 외의 요구

이때의 올바른 행동은 「여러 번 시도해서 성공시키는 것」이 아니라, 「정지하고, 이유를 설명하며, 인간 또는 별도의 워크플로우로 인계하는 것」입니다.

액션이 잘못되었을 경우를 대비한 회복 수단도 설계해 두어야 합니다.

• 롤백 (Rollback): 시스템이 직접적인 취소를 지원하는 경우 (예: 상태 변경의 되돌리기)
• 보상 액션 (Compensating Action): 직접 취소가 불가능한 경우의 대체 조작 (예: 잘못된 지급에 대한 환불 처리)
• 수동 리커버리 (Manual Recovery): 복잡한 케이스를 위한 명확한 인계 경로, 인시던트 (Incident) 기록, 정책으로의 피드백 루프

롤백 수단이 없으면 조직은 「자율성을 두려워하여 전혀 부여하지 않거나」 혹은 「안전망 없이 과신하는」 양극단에 빠지게 됩니다.

마지막으로, 유스케이스 (Use Case)별로 자율성 레벨을 정의하는 매트릭스 (Matrix)를 소개합니다.

레벨	동작	적합한 영역
Assist	컨텍스트 제공, 요약, 인사이트 제시만 수행	모호한 영역, 불안정한 데이터, 인간의 판단이 필수적인 프로세스
Draft	권장·문서·액션 안을 작성하지만, 인간이 실행	변혁 초기, 높은 컨트롤 요구, 실행 권한 없이 가속하고 싶은 영역
Execute with Approval	승인 후 액션 실행	고액 거래, 규제 대상, 공식적인 증적(Audit Trail)이 필요한 영역
Execute with Monitoring	명확한 정책 범위 내에서 자동 실행 + 감시·샘플링	고빈도·저~중 리스크·취소 가능한 액션, 정책이 성숙한 영역

이 매트릭스를 통해 **「곧바로 모든 자율성을 부여하는 것」**과 **「계속 Assist 모드에 머무는 것」**의 양극단을 피할 수 있습니다.

도입부의 시나리오로 돌아가겠습니다. 재무 에이전트가 중요한 조정 분개를 실행하려고 할 때, 당신의 시스템은 그것을 멈출 수 있습니까?

• 입력 체크를 통해 의도를 검증했는가
• 컨텍스트 획득을 적절히 제한했는가
• 툴 액세스를 상황에 따라 제어했는가
• 액션 실행 전에 정책 엔진이 판단했는가
• 필요한 경우 인간의 승인을 거쳤는가
• 잘못되었을 경우의 롤백 수단이 있는가

이 모든 질문에 「Yes」라고 답할 수 있다면, 당신의 시스템은 실운영 투입 준비가 된 것입니다.