AI 에이전트 운영에서 먼저 정해야 할 것

AI 에이전트는 단순 챗봇과 다르게 검색, 메일, 고객 정보, 결제, 배포, 데이터베이스 조회 같은 실제 도구를 호출한다. 그래서 모델 성능보다 먼저 정해야 할 것은 에이전트가 무엇을 할 수 있고, 어떤 경우에는 멈춰야 하며, 실행 후 어떤 증거를 남길지다. 좋은 답변을 만드는 것과 안전하게 일을 맡기는 것은 다른 문제다. 실무에서는 프롬프트에 “조심해서 처리하라”고 쓰는 것만으로 충분하지 않다. 권한 목록, 승인 조건, 감사 로그, 실패 처리 기준을 시스템 설계로 분리해야 운영 사고를 줄일 수 있다.

특히 사내 업무 자동화에서는 도구 호출의 범위가 넓어진다. 고객 문의 요약은 낮은 위험이지만, 환불 처리나 계정 권한 변경은 높은 위험이다. 같은 CRM API라도 읽기, 수정, 삭제의 위험도는 다르다. 따라서 에이전트 권한은 사람 계정처럼 넓게 주는 방식이 아니라 작업 목적별로 작게 나누어야 한다. 이 문서는 AI 에이전트를 실제 서비스에 붙일 때 바로 적용할 수 있는 권한 모델과 로그 설계 방법을 정리한다.

도구를 기능이 아니라 위험도로 나누기

도구 목록을 만들 때 흔한 실수는 “메일 도구”, “DB 도구”, “검색 도구”처럼 시스템 이름만 기준으로 묶는 것이다. 운영에서는 시스템 이름보다 행위의 위험도가 중요하다. 예를 들어 메일 도구 안에도 받은 편지 조회, 초안 작성, 실제 발송이 있다. DB 도구 안에도 조회, 집계, 개인정보 조회, 데이터 수정이 있다. 각 도구는 최소한 read, suggest, write, external_action 단계로 분류하는 것이 좋다.

• read: 내부 문서 검색, 상태 조회, 로그 조회처럼 데이터를 읽기만 하는 호출
• suggest: 초안 작성, SQL 제안, 응답 문안 생성처럼 실행 전 사람이 검토할 결과 생성
• write: 내부 시스템에 값을 변경하지만 외부 사용자에게 직접 노출되지는 않는 호출
• external_action: 이메일 발송, 결제, 게시, 권한 부여처럼 조직 밖으로 영향이 나가는 호출

이렇게 나누면 승인 정책을 단순하게 만들 수 있다. read는 자동 실행을 허용하되 개인정보 범위를 제한하고, suggest는 결과만 생성하게 하며, write는 업무별 제한과 재시도 한도를 둔다. external_action은 기본적으로 사람 승인 또는 별도 서비스 계정 승인을 요구한다. 이 기준은 모델 종류와 무관하게 유지되어야 한다.

정책 파일로 권한을 명시하기

권한은 코드 곳곳에 if 문으로 흩어두기보다 정책 파일로 관리하는 편이 운영에 좋다. 정책 파일은 누가 어떤 목적에서 어떤 도구를 사용할 수 있는지, 자동 실행 가능한지, 승인자가 필요한지, 로그에 어떤 필드를 남길지 명시한다. 아래는 작은 업무 에이전트에 적용할 수 있는 예시다.

policy:
  agents:
    support-agent:
      allowed_tools:
        - crm.customer.read
        - crm.ticket.read
        - crm.ticket.suggest_reply
      denied_tools:
        - crm.customer.delete
        - mail.send
      require_approval:
        - crm.ticket.close

  tools:
    crm.customer.read:
      risk: read
      pii: masked
      max_rows: 20
      log_level: full

    crm.ticket.suggest_reply:
      risk: suggest
      output_only: true
      log_level: summary

    crm.ticket.close:
      risk: write
      approval_role: support-lead
      reason_required: true
      log_level: full

핵심은 “허용되지 않은 것은 실행하지 않는다”는 기본값이다. 새 도구를 추가했을 때 자동으로 사용 가능해지면 사고가 나기 쉽다. 기본 거부 정책을 두고, 필요한 도구만 명시적으로 열어야 한다. 또한 권한은 에이전트 이름만이 아니라 작업 목적, 사용자 역할, 데이터 등급을 함께 본다. 같은 support-agent라도 일반 문의에서는 고객 이름과 주문 상태만 조회하고, 보안 문의에서는 계정 변경 기록까지 조회할 수 있도록 목적별 정책을 분리한다.

도구 호출 전 승인 게이트 만들기

모델이 도구를 호출하겠다고 결정한 직후, 실제 API를 실행하기 전에 별도의 authorize 함수를 통과시키는 구조가 필요하다. 이 단계에서는 프롬프트 신뢰가 아니라 정적 정책과 런타임 정보를 기준으로 판단한다. 예를 들어 고객 정보 조회 요청이 들어오면 요청자, 도구 이름, 리소스, 목적, 입력 크기, 개인정보 등급을 검사한다. 허용되지 않으면 모델에게 실패 사유를 알려주고 다른 안전한 경로를 선택하게 한다.

function authorize(input) {
  const policy = loadPolicy(input.actor);
  const toolPolicy = policy.tools[input.tool];

  if (!toolPolicy) return { allow: false, reason: 'tool_not_registered' };
  if (!policy.allowed_tools.includes(input.tool)) {
    return { allow: false, reason: 'tool_not_allowed' };
  }
  if (toolPolicy.max_rows && input.params.limit > toolPolicy.max_rows) {
    return { allow: false, reason: 'row_limit_exceeded' };
  }
  if (toolPolicy.risk === 'external_action' && !input.approvalId) {
    return { allow: false, reason: 'approval_required' };
  }

  return { allow: true, logLevel: toolPolicy.log_level };
}

이 코드는 단순하지만 중요한 원칙을 담고 있다. 모델이 생성한 파라미터를 그대로 믿지 않고, 실행 직전에 한 번 더 제한한다. limit 값, 파일 경로, 고객 ID, 대상 채널, 금액, 날짜 범위처럼 피해 범위를 키울 수 있는 값은 반드시 검증해야 한다. 또한 거절 사유를 남겨야 나중에 권한이 과도하게 좁은지, 모델이 잘못된 도구를 자주 고르는지 분석할 수 있다.

감사 로그는 재현 가능해야 한다

감사 로그는 단순히 “도구를 호출했다”는 기록이 아니다. 운영 중 문제가 생겼을 때 누가, 어떤 입력으로, 어떤 정책 판정을 거쳐, 어떤 결과를 받았는지 재현할 수 있어야 한다. 다만 개인정보와 비밀값을 그대로 남기면 로그가 또 다른 위험이 된다. 그래서 원문 전체를 저장하기보다 마스킹, 해시, 요약, 참조 ID를 조합한다.

• request_id: 사용자 요청부터 도구 호출까지 묶는 추적 ID
• actor: 에이전트 또는 서비스 계정 이름
• tool: 호출한 도구의 정규화된 이름
• purpose: 사용자가 요청한 업무 목적
• policy_result: allow, deny, approval_required 같은 판정
• params_summary: 민감값을 제거한 주요 파라미터 요약
• result_summary: 성공, 실패, 변경된 레코드 수, 외부 발송 여부

로그에는 입력 프롬프트 전체를 무조건 저장하지 않는 편이 안전하다. 대신 필요한 경우 원문은 짧은 보관 기간을 가진 별도 저장소에 암호화하고, 일반 감사 로그에는 참조 ID만 남긴다. 고객명, 전화번호, 이메일, 토큰, 쿠키, API 키는 저장 전에 마스킹해야 한다. 운영팀이 자주 보는 대시보드에는 요약 로그만 노출하고, 상세 로그는 권한 있는 담당자만 볼 수 있게 분리한다.

실패와 재시도 정책도 권한의 일부다

AI 에이전트는 실패했을 때 다시 시도하거나 다른 도구를 고르려는 경향이 있다. 이 동작이 업무 자동화에서는 편리하지만, 쓰기 작업에서는 중복 처리 사고로 이어질 수 있다. 예를 들어 환불 API가 네트워크 오류처럼 보였지만 실제로는 처리된 상태라면 재시도가 이중 환불을 만들 수 있다. 따라서 write와 external_action 도구에는 멱등성 키, 재시도 횟수, 확인 조회 절차를 반드시 둔다.

읽기 작업은 짧은 지연 후 1~2회 재시도해도 큰 문제가 없지만, 쓰기 작업은 서버가 제공하는 idempotency key를 사용하거나, 실행 후 상태 조회로 결과를 확인해야 한다. 모델에게 “다시 해볼게요”를 맡기는 것이 아니라, 도구 래퍼가 재시도 가능 여부를 판단해야 한다. 이 기준을 정해두면 장애 상황에서도 에이전트가 예측 가능한 방식으로 멈춘다.

운영 적용 체크리스트

• 모든 도구를 read, suggest, write, external_action 위험도로 분류한다.
• 새 도구의 기본값은 거부로 두고, 정책 파일에서만 허용한다.
• 실제 API 실행 전 authorize 게이트를 반드시 통과시킨다.
• 개인정보, 토큰, 쿠키, 원문 프롬프트는 로그에 그대로 저장하지 않는다.
• 쓰기 작업은 승인, 멱등성 키, 재시도 제한, 결과 확인 절차를 갖춘다.
• 거절된 호출도 기록해 정책 개선과 모델 평가에 활용한다.

AI 에이전트의 품질은 답변 정확도만으로 결정되지 않는다. 운영 환경에서는 권한이 작게 나뉘어 있고, 실행 전 검사가 있으며, 실행 후 기록이 남는 구조가 더 중요하다. 먼저 작은 도구 세트에서 정책과 로그를 안정화한 뒤, 위험도가 낮은 업무부터 자동 실행 범위를 넓히는 것이 현실적인 도입 순서다.