AI 에이전트를 데모에서 실무 운영으로 전환할 때, "이 액션, 누가 수행했는가?" 라는 질문에 답하지 못하는 케이스가 빈번하게 발생합니다.

원인은 단순합니다. 에이전트에 명확한 아이덴티티(Identity, ID) 가 없으며, 위임한 사용자나 워크플로우(Workflow) 와 연결되어 있지 않기 때문입니다.

본 기사에서는 다음과 같은 관점에서 실무적인 설계 패턴을 정리합니다.

• 에이전트에 ID가 필요한 이유 (감사, 설명 책임, 신뢰 경계)
• 정적 역할(Static Role)만으로는 불충분한 이유 (컨텍스트 의존적 권한)
• 위임된 권한 (Delegated Authority)의 모델화
• 구현 패턴 (서비스 ID, 정책 엔진, 권한 레이어, 감사 로그)
• 아직 이 패턴이 적합하지 않은 케이스와 위험 신호

기존의 엔터프라이즈 아키텍처(Enterprise Architecture)에서 액터(Actor)는 "인간", "애플리케이션", "서비스 계정", "스케줄 작업" 중 하나였습니다.

Agentic AI는 여기에 **"추론하고, 도구를 선택하며, 여러 단계를 자율적으로 실행하는 디지털 액터"**라는 새로운 카테고리를 추가합니다.

이 에이전트를 단순한 백그라운드의 익명 스크립트로 취급하면, 실무에서 다음 세 가지가 불분명해집니다.

누가 액션을 실행했는가 -
**누구의 위임(Mandate)**으로 움직였는가 -
어떤 워크플로우의 맥락에서 발생했는가

예를 들어, 구매 에이전트가 ERP에 발주 요청 초안을 작성했을 때, 그 로그가 범용 서비스 계정의 것으로만 남는다면 어떨까요?

"그 사용자가 요청한 것인가", "스케줄 작업이 실행된 것인가", "누군가 권한을 악용한 것인가" —— 구분이 불가능합니다.

에이전트가 비즈니스 상태를 변경하기 시작하는 순간, 그 ID는 인간이나 애플리케이션과 동일하게 추적 가능해야 합니다.

"에이전트에 역할을 할당하면 끝이다" —— 이는 오래된 실수의 새로운 형태입니다.

에이전트의 권한에는 컨텍스트(Context) 가 필요합니다.

• 이 액션은 특정 사용자의 지시인가, 스케줄인가, 이벤트 트리거인가?
• 읽기인가, 초안 작성인가, 실행인가, 승인 지원인가?
• 데이터는 일반 정보인가, 기밀(급여, 거래처 은행, 계약, 고객 데이터)인가?

동일한 에이전트라도, "송장 데이터를 읽기", "차이점에 대한 설명을 초안 작성하기", "해결책을 권장하기" 는 허용하되, "지불 차단 해제하기" 는 허용하지 않는 —— 식의 입도가 필요합니다.

구현의 기본은 권한을 레이어(Layer)로 나누는 것입니다.

이 레이어를 정책 엔진(Policy Engine)으로 평가함으로써, "읽기는 OK, 실행은 NG"와 같은 제어가 가능해집니다.

에이전트 액션의 대부분은 에이전트 자신에게 귀속되는 것이 아닙니다.

"사용자의 지시", "승인된 워크플로우", "자율 이벤트 트리거" 라는 위임원(Source of Mandate) 이 있습니다.

이 위임원은 구별 가능해야 합니다.

• 구매 에이전트가 구매자를 위해 발주 요청 초안을 작성한다
• 재무 마감 에이전트가 스케줄에 따라 야간 체크를 실행한다
• IT 운영 에이전트가 모니터링 이벤트에 응답한다

감사 추적(Audit Trail)에는 위임원의 정보, 에이전트 ID, 유효 기간, 사용 도구, 정책 준수 여부를 기록합니다.

위임에는 경계를 설정합니다.

취소 가능: 인시던트 발생 시 즉시 권한을 박탈할 수 있음 -
시간 제한: 특정 시간대에만 유효함 -
스코프 제한: 특정 데이터 소스나 도구로만 한정 -
금액 제한: 표준 발주는 임계치까지, 그 이상은 인간의 승인이 필요

심플하게 요약하면, 다음 네 가지를 정비하면 대부분의 케이스를 커버할 수 있습니다.

범용 서비스 계정을 공유하지 않는다.

에이전트마다 다음 속성을 관리합니다.

• 에이전트 ID (고유)
• 비즈니스 오너 (Business Owner)
• 테크니컬 오너 (Technical Owner)
• 프로세스 도메인 (구매, 재무, 고객 지원 등)
• 허용 도구 리스트
• 리스크 티어 (Risk Tier: 저/중/고)
• 라이프사이클 상태 (개발/테스트/운영/중지)

런타임의 액세스 평가는 세션 시작 시뿐만 아니라, 도구 호출 시마다 수행합니다.

# 의사 코드(Pseudo-code): 정책 평가의 이미지
def call_tool(agent_id, tool_name, input_data, mandate_source):
policy_result = policy_engine.evaluate(
...

앞서 언급한 Read / Recommend / Draft / Execute / Approve를 API나 도구별로 매핑합니다.

• 재무 에이전트: Read(분개장), Recommend(처리 방법), Draft(코멘트) → OK
• 재무 에이전트: Execute(지불 차단 해제) → NG (인간에게 에스컬레이션)
• 구매 에이전트: Read(계약서), Draft(발주 의뢰) → OK
• 구매 에이전트: Approve(발주 승인) → NG

최종적인 API 호출뿐만 아니라, 다음 정보를 연결하여 기록합니다.

• 위임원 (사용자 ID / 워크플로 ID / 이벤트 ID)
• 에이전트 ID
• 정책 평가 결과 (허가/거부, 이유)
• 도구 호출 (입력, 출력)
• 승인 프로세스 (필요한 경우)
• 최종적인 상태 변경

이것을 재구성할 수 없다면, 해당 에이전트는 프로덕션 스케일(Production Scale)을 견딜 수 없습니다.

다음과 같은 위험 신호가 여러 개 있다면, 에이전트를 스케일링할 때 리스크가 가치를 상회하게 됩니다.

• 범용 서비스 계정(Service Account)을 공유하고 있다
• "일단 작동시키기 위해" 권한을 넓게 부여하고 있다
• Read / Draft / Execute의 구분이 없다
• 위임원을 명시적으로 기록하지 않는다
• 도구 호출이 정책 엔진(Policy Engine)을 경유하지 않는다
• 감사 로그(Audit Log)가 최종 출력만 기록한다
• 인시던트 발생 시 에이전트의 권한을 즉시 박탈할 수 없다
• 비즈니스 오너가 에이전트가 사용하는 도구와 데이터를 정확히 파악하지 못하고 있다

또한, 다음과 같은 영역에서는 에이전트에게 실행 권한 (Execute) 을 부여하는 것이 아직 시기상조입니다.

• 롤백(Rollback)이 어려운 중요 트랜잭션
• 정책 정의가 런타임 규칙(Runtime Rule)으로 구현되지 않았다
• 데이터가 불안정하다 (스키마 변경이 잦거나 품질이 낮음)
• 프로세스 오너십(Process Ownership)이 불명확하다

이런 경우에는 Read / Recommend / Draft로 한정하고, ID 관리와 정책 기반을 먼저 공고히 하는 것이 더 안전합니다.

내일 감사 부서나 리스크 위원회로부터 다음과 같은 질문이 왔을 때, 당신의 팀은 증거를 가지고 답할 수 있습니까?

**이 액션을 실행한 것은 누구인가?****그 액션은 누구의 위임에 근거하는가?**왜 시스템은 그것을 허가했는가?

답변이 아직 명확하지 않다면, 다음에 우선순위를 두어야 할 것은 "더 똑똑한 모델"이 아닙니다.

아이덴티티, 권한 위임, 정책 평가, 감사——AI 에이전트를 신뢰할 수 있는 디지털 액터(Digital Actor)로 만들기 위한 기반입니다.