왜 AI 에이전트가 필요한가
지금까지의 자동화는 대체로 순서가 정해져 있었다. 파일을 읽고, 데이터를 정리하고, 데이터베이스에 저장하고, 알림을 보냈다. LLM을 붙인 뒤에도 고객 문의를 분류하거나 회의록을 요약하는 식으로 하나의 작업을 맡기는 경우가 많았다.
하지만 실제 업무에는 한 번의 호출로 끝나지 않는 일이 많다. 영업 리드를 조사하려면 회사 정보를 찾고, 기존 CRM 고객인지 확인하고, 최근 뉴스와 채용 공고를 살피고, 담당 영업팀에 전달할 요약을 만들어야 한다. 고객 응대도 마찬가지다. 문의 내용을 읽고, 사내 정책을 검색하고, 주문 상태를 조회하고, 답변 초안을 쓴 뒤, 민감한 내용이면 사람이 승인해야 한다.
이처럼 여러 단계를 이어 가며 상황에 따라 다음 행동을 선택하는 자동화에 AI 에이전트를 사용할 수 있다. 여기서 에이전트란 사람처럼 모든 권한을 가진 존재가 아니다. 업무 목표를 해석하고, 허용된 도구를 선택해 호출하고, 결과를 바탕으로 다음 단계를 제안하는 실행 관리자에 가깝다.
핵심은 자율성이 아니라 통제된 실행이다. 복잡한 업무일수록 AI가 혼자 처리하는 구조보다, 파이썬 도구와 업무 규칙, 사람 승인 절차를 함께 연결한 구조가 안정적이다.
AI 생성 이미지
에이전트의 기본 구조
업무용 AI 에이전트는 보통 다음 구성 요소로 나눌 수 있다.
목표 입력: "이 리드가 영업 대상인지 조사하라", "이 고객 문의에 대한 답변 초안을 작성하라"처럼 사람이 요청한 업무 목표다.
LLM 또는 판단 모듈: 목표를 읽고 필요한 단계를 계획한다.
도구 목록: CRM API, 주문 조회 API, 데이터베이스 조회, RAG 검색, 문서 생성, Slack 알림 같은 실제 실행 기능이다.
정책과 권한 제한: 어떤 도구를 사용할 수 있는지, 어떤 조건에서 사람 승인이 필요한지 정한다.
실행 로그: 에이전트가 무엇을 조회했고, 어떤 판단을 했고, 어떤 도구를 호출했는지 남긴다.
사람 승인 단계: 고위험 작업이나 불확실한 판단에서 자동화를 멈추고 담당자에게 넘긴다.
이 구조에서 LLM은 직접 데이터베이스를 수정하거나 고객에게 메일을 보내지 않는다. LLM은 "무엇을 해야 하는지"를 제안하고, 실제 실행은 파이썬 코드가 허용된 범위 안에서 수행한다.
간단한 형태의 도구 목록은 다음처럼 정의할 수 있다.
TOOLS = {
"search_internal_policy": {
"description": "사내 정책 문서에서 관련 내용을 검색한다.",
"risk": "low",
},
"get_customer_order": {
"description": "고객 주문 상태를 조회한다.",
"risk": "low",
},
"create_reply_draft": {
"description": "고객 답변 초안을 생성한다.",
"risk": "medium",
},
"send_email": {
"description": "고객에게 이메일을 발송한다.",
"risk": "high",
"requires_approval": True,
},
"update_crm_status": {
"description": "CRM 리드 상태를 변경한다.",
"risk": "high",
"requires_approval": True,
},
}중요한 점은 도구를 함수처럼 등록하되, 위험도와 승인 필요 여부를 함께 관리하는 것이다. 에이전트가 send_email을 선택했다고 해서 바로 발송하면 안 된다. 발송 대상, 본문, 근거, 예상 영향 범위를 검토할 수 있는 승인 단계가 먼저 있어야 한다.
다단계 업무 자동화 예시
영업 리드 조사
영업팀은 매주 새로운 잠재 고객 목록을 받는다. 사람이 직접 조사하면 시간이 많이 든다. 에이전트를 사용하면 다음 흐름을 자동화할 수 있다.
엑셀 또는 CRM에서 신규 리드 목록을 읽는다.
회사명과 도메인으로 기존 고객 여부를 조회한다.
공개 웹 정보나 승인된 외부 데이터 API에서 업종, 규모, 최근 뉴스 키워드를 확인한다.
사내 영업 기준에 따라 우선순위를 분류한다.
담당자에게 리드 요약과 추천 접근 방식을 보낸다.
CRM 상태 변경은 담당자가 승인한 뒤 실행한다.
이때 "리드 요약 작성"은 AI가 잘할 수 있다. 하지만 "전략 고객으로 확정", "담당자 배정 변경", "자동 이메일 발송"은 업무 영향이 있으므로 승인 대상으로 두는 편이 안전하다.
경쟁사 모니터링
경쟁사 모니터링은 반복적이지만 완전히 규칙화하기 어렵다. 에이전트는 정해진 사이트, 보도자료, 채용 공고, 가격 페이지를 확인하고 변화가 있는지 요약할 수 있다.
자동화 흐름은 다음과 같다.
매일 아침 지정된 경쟁사 목록을 기준으로 자료를 수집한다.
이전 스냅샷과 비교해 새 문장, 가격 변경, 신규 기능 언급을 찾는다.
중요도가 낮은 변경은 기록만 남긴다.
가격 변경, 주요 제품 출시, 대규모 채용 같은 항목은 담당자에게 검토 요청을 보낸다.
사람이 "중요"로 표시한 항목은 주간 보고서에 포함한다.
여기서 에이전트는 정보 수집과 초안 작성에 강하다. 그러나 경쟁사의 의도를 단정하거나 우리 회사의 가격 정책을 자동으로 바꾸는 역할을 맡기면 위험하다. AI가 만든 요약에는 원문 링크와 수집 시각을 반드시 포함해야 한다.
고객 응대 초안 작성
고객 응대 자동화는 에이전트가 가장 유용하면서도 주의가 필요한 영역이다. 단순 문의는 자동 초안으로 충분하지만, 환불, 법적 책임, 개인정보, 강한 불만이 포함된 문의는 사람이 검토해야 한다.
예를 들어 고객 문의가 들어오면 에이전트는 다음 순서로 움직인다.
문의 유형을 분류한다.
주문 번호가 있으면 주문 API로 상태를 조회한다.
관련 정책을 RAG로 검색한다.
답변 초안을 작성한다.
위험도를 계산한다.
낮은 위험은 상담원이 빠르게 확인 후 발송한다.
높은 위험은 팀장 승인 대상으로 넘긴다.
이 구조에서는 AI가 "답변을 보냈다"가 아니라 "근거가 포함된 답변 초안을 만들었다"가 기본값이어야 한다.
사람 참여형 자동화 설계
사람 참여형 자동화는 단순히 "마지막에 사람이 확인한다"는 뜻이 아니다. 자동화 흐름 안에 사람이 개입해야 하는 지점을 명확히 박아 넣는 설계다. 에이전트가 위험하거나 불확실한 상황을 만나면 멈추고, 필요한 정보를 정리해 담당자에게 넘기고, 승인 결과에 따라 다음 단계로 진행한다. 고위험·불확실·민감한 상황에서 에이전트가 멈추고 사람에게 검토를 요청하는 방식은 여러 기업용 AI 설계에서도 핵심 통제 패턴으로 다뤄진다1.
승인 요청에는 최소한 다음 정보가 포함되어야 한다.
요청한 업무 목표
에이전트가 사용한 데이터 출처
AI가 만든 판단 또는 초안
실행하려는 도구와 실제 변경 내용
위험도와 승인 필요 사유
예상 영향 범위
되돌리기 방법
승인, 반려, 수정 요청 버튼
예를 들어 CRM 상태를 변경하는 승인 요청은 이렇게 기록할 수 있다.
approval_request = {
"request_id": "APR-20260527-001",
"action": "update_crm_status",
"target": {"lead_id": "L-10291", "new_status": "high_priority"},
"reason": "최근 투자 유치 뉴스와 채용 증가가 확인됨",
"sources": [
"crm://leads/L-10291",
"news://approved-provider/company-abc",
],
"risk_level": "high",
"rollback_plan": "CRM 상태를 previous_status 값으로 복원",
"status": "pending_approval",
}승인자는 단순히 "좋아 보인다"로 판단하면 안 된다. 자신이 승인 권한을 가진 사람인지, 근거가 충분한지, 실행 범위가 정책 안에 있는지, 문제가 생겼을 때 되돌릴 수 있는지 확인해야 한다. 의미 있는 사람 승인을 위해서는 적절한 자격, 충분한 맥락, 개입 권한, 승인 사유 기록이 필요하다2.
실행 전 정책으로 막기
에이전트의 위험은 "똑똑하지 않아서"만 생기지 않는다. 오히려 애매한 목표를 넓게 해석해 너무 많은 행동을 하려 할 때 문제가 생긴다. 따라서 실행 전 정책 검사가 필요하다.
def evaluate_action(action_name, payload):
tool = TOOLS[action_name]
if tool.get("requires_approval"):
return "needs_approval"
if payload.get("contains_personal_data"):
return "needs_approval"
if payload.get("estimated_cost_usd", 0) > 5:
return "needs_approval"
return "allowed"
def run_agent_action(action_name, payload):
decision = evaluate_action(action_name, payload)
if decision == "allowed":
return execute_tool(action_name, payload)
if decision == "needs_approval":
request_id = create_approval_request(action_name, payload)
return {"status": "pending_approval", "request_id": request_id}
return {"status": "blocked", "reason": "policy_denied"}이런 정책은 LLM 프롬프트에만 적어 두면 부족하다. 프롬프트는 지시문이고, 정책 검사는 코드로 강제되어야 한다. 특히 결제, 계약, 고객 통지, 권한 변경, 개인정보 처리, 외부 발송은 승인 없이 실행되지 않도록 막아야 한다.
업무별로 자율 실행 범위를 나누는 것도 중요하다. 낮은 위험의 조회와 요약은 자동으로 처리할 수 있다. 중간 위험의 초안 작성은 사람이 빠르게 검토한다. 높은 위험의 상태 변경, 발송, 삭제, 결제, 계약 관련 작업은 반드시 승인 후 실행한다. 기업 환경에서는 에이전트에도 역할과 권한을 부여하고, 접근 가능한 데이터와 연결 도구를 제한하며, 운영 환경별로 통제 수준을 달리하는 방식이 필요하다3.
로그, 비용, 롤백을 함께 설계하기
에이전트 자동화는 실행 경로가 매번 조금씩 달라질 수 있다. 그래서 로그가 더 중요하다. 단순히 "성공" 또는 "실패"만 남기면 나중에 원인을 찾기 어렵다.
운영 로그에는 다음 항목을 남긴다.
사용자 요청
선택한 도구
도구 입력값과 결과 요약
사용한 문서 또는 데이터 출처
AI 응답 버전과 프롬프트 버전
승인자, 승인 시각, 승인 사유
실제 실행 결과
토큰 사용량과 API 비용
오류와 재시도 여부
에이전트 운영에서는 품질뿐 아니라 비용, 지연 시간, 도구 호출 성공률, 사용자 피드백 같은 지표도 함께 봐야 한다. 다단계 에이전트는 한 번의 업무에서 여러 번 모델과 API를 호출하므로, 모니터링이 없으면 비용과 실패가 조용히 커질 수 있다4.
롤백도 설계 단계에서 정해야 한다. 모든 작업을 쉽게 되돌릴 수 있는 것은 아니다. 이메일 발송은 되돌릴 수 없다. 외부 고객에게 보낸 안내도 회수하기 어렵다. 반면 CRM 상태 변경이나 내부 태그 변경은 이전 값을 저장해 두면 복구할 수 있다.
따라서 실행 전 작업을 세 가지로 나누면 좋다.
되돌릴 수 있는 작업: 내부 상태 변경, 태그 수정, 임시 데이터 생성
부분적으로만 되돌릴 수 있는 작업: 보고서 공유, 내부 알림, 작업 할당
되돌릴 수 없는 작업: 외부 메일 발송, 결제 실행, 계약 전송, 데이터 삭제
되돌릴 수 없는 작업은 원칙적으로 자동 실행 대상에서 제외하거나, 강한 승인 절차를 거쳐야 한다.
작은 에이전트부터 시작하기
처음부터 "모든 업무를 알아서 처리하는 에이전트"를 만들려고 하면 실패하기 쉽다. 실무에서는 작은 에이전트를 여러 개 두는 편이 낫다.
예를 들어 다음처럼 나눌 수 있다.
리드 조사 에이전트: 리드 정보 수집과 요약만 담당
고객 응대 에이전트: 정책 검색과 답변 초안만 담당
경쟁사 모니터링 에이전트: 변경 탐지와 요약만 담당
승인 관리 에이전트: 승인 요청 생성과 상태 추적만 담당
각 에이전트는 사용할 수 있는 도구가 제한되어야 한다. 리드 조사 에이전트가 결제 API를 호출할 이유는 없다. 고객 응대 에이전트가 데이터베이스 전체를 조회할 필요도 없다. 필요한 데이터에만 접근하게 만드는 것이 가장 기본적인 보안이다.
마지막으로, 에이전트를 평가할 때는 "얼마나 사람처럼 말하는가"보다 "업무를 안전하게 전진시키는가"를 봐야 한다. 좋은 에이전트는 모르는 것을 모른다고 말하고, 위험한 작업 앞에서 멈추며, 사람이 판단할 수 있도록 근거를 정리한다. 자동화의 목적은 사람을 과정에서 없애는 것이 아니라, 사람이 꼭 판단해야 하는 지점에 더 좋은 정보를 제공하는 것이다.
참고
1Oracle Human in the Loop for Agentic AI
2Strata Human-in-the-Loop Guide
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.