규칙 기반 자동화의 한계: AI 워크플로우는 어디까지 룰로 묶고, 어디서 에이전트가 필요할까

1. 개요: 많은 AI 자동화는 아직 에이전트가 아니라 워크플로우입니다

이번 주 x-inbox-router에서 잡힌 X 신호는 흥미로웠습니다. 한 포스트는 워크플로우 설계도 중요하지만, 카테고리를 분류한 뒤 정해진 일만 하는 규칙 기반 제어에는 한계가 있고, 에이전트에도 오토파일럿이 필요하다고 주장했습니다. 이 말은 반은 맞고 반은 위험합니다.

맞는 부분은 분명합니다. 고객 문의를 배송, 환불, 견적, 불만으로 나눈 뒤 정해진 템플릿만 붙이는 구조는 곧 막힙니다. 고객은 항상 예외를 가져오고, 데이터는 빠져 있고, 업무 목표는 중간에 바뀝니다. 정해진 분기표가 현실을 다 담기 어렵습니다.

하지만 위험한 부분도 있습니다. 룰 기반이 막힌다고 바로 완전 자율 에이전트로 뛰면 운영 리스크가 커집니다. 문제는 룰이냐 에이전트냐가 아니라, 어느 단계는 고정하고 어느 단계는 동적으로 열어둘지 정하는 것입니다.

2. 워크플로우가 잘하는 일: 길이 보이는 업무는 룰로 묶습니다

Anthropic은 agentic system 안에서도 workflow와 agent를 구분합니다. workflow는 LLM과 도구가 미리 정해진 코드 경로를 따라 움직이는 시스템이고, agent는 LLM이 자신의 절차와 도구 사용을 더 동적으로 지휘하는 시스템입니다.

이 구분은 실무에서 매우 유용합니다. 업무 경로가 이미 보이고, 입력 유형이 반복되고, 실패했을 때 되돌릴 수 있고, 평가 기준이 명확하면 먼저 워크플로우로 묶는 편이 낫습니다. 작은 회사가 처음부터 만능 agent를 만들 필요는 없습니다.

예를 들어 고객 문의 자동화에서 처음 필요한 것은 자율 에이전트가 아닙니다. 문의 분류, 누락 정보 체크, 과거 주문 조회, 답변 초안, 위험 신호 표시, 사람 승인 대기열이 먼저입니다. 이것만으로도 업무량은 줄고, 사람은 더 나은 판단에 집중할 수 있습니다.

• 입력이 명확합니다: 주문번호, 문의 유형, 날짜, 금액처럼 필요한 필드가 정해져 있습니다.
• 경로가 짧습니다: 분류한 뒤 정해진 템플릿, 담당자, 체크리스트로 이어집니다.
• 실패 비용이 낮습니다: 자동 실행이 아니라 초안이나 내부 메모로 끝납니다.
• 평가가 쉽습니다: 맞는 분류인지, 누락된 필드가 잡혔는지, 초안이 기준을 지켰는지 확인할 수 있습니다.
• 개선 루프가 보입니다: 사람이 고친 내용을 다음 규칙과 지식베이스에 반영할 수 있습니다.

3. 룰 기반 자동화가 막히는 지점: 예외, 맥락, 목표 변화

규칙 기반 자동화는 반복 업무의 첫 번째 답입니다. 그러나 회사 운영에는 항상 규칙표 바깥의 일이 생깁니다. 고객이 정책상 환불 대상은 아니지만 장기 VIP일 수 있고, 같은 불만이 여러 채널에서 동시에 쌓이고 있을 수 있고, 원래는 배송 문의였지만 실제 문제는 상품 설명 오류일 수 있습니다.

Reddit의 agent 논의에서도 비슷한 혼란이 반복됩니다. 어떤 사람은 현재의 AI agent가 사실상 잘 짜인 workflow에 LLM wrapper를 붙인 것 아니냐고 묻고, 다른 사람은 진짜 agent라면 고정된 단계보다 목표, 도구, 상태를 보고 다음 행동을 선택해야 한다고 봅니다. 이 논쟁은 용어 싸움처럼 보이지만, 실무에서는 중요한 설계 질문입니다.

룰 기반 구조가 막히는 대표 신호는 세 가지입니다. 첫째, 예외가 늘어 규칙이 폭발합니다. 둘째, 한 번의 분류로 끝나지 않고 중간 결과를 보고 다음 행동을 바꿔야 합니다. 셋째, 업무 목표가 "정답 출력"이 아니라 "상황을 이해하고 다음 조치를 찾는 것"으로 바뀝니다.

• 분류 카테고리가 계속 늘어나고 서로 겹칩니다.
• 한 단계가 끝나기 전에는 다음 단계가 무엇인지 알 수 없습니다.
• AI가 여러 도구를 써서 확인, 비교, 재계획을 해야 합니다.
• 사람이 매번 "이 경우는 예외"라고 설명하고 있습니다.
• 업무 결과보다 중간 판단의 품질이 더 중요해집니다.

4. 에이전트가 필요한 일: 정해진 길이 아니라 목표가 있는 일

에이전트가 필요한 일은 길이 아니라 목표가 먼저 주어지는 일입니다. "이 고객의 문제를 해결해라", "이번 주 문의 패턴에서 가격 정책 문제를 찾아라", "경쟁사 5곳의 온보딩 흐름을 비교해 개선안을 만들어라"처럼 필요한 단계 수와 도구 선택을 미리 다 쓰기 어려운 업무입니다.

OpenAI의 agent 가이드도 agent를 모델, 도구, instructions와 guardrails의 조합으로 설명합니다. 중요한 점은 도구를 준다고 끝이 아니라는 것입니다. 데이터 조회 도구, action 도구, 다른 agent로 handoff하는 orchestration 도구가 있고, 각 도구는 표준화되고 테스트되어야 합니다.

Microsoft Research의 LegoMem 연구도 같은 방향을 보여줍니다. 반복 workflow를 절차 기억으로 쌓고 재사용하게 만들면 multi-agent system이 단발성 실행을 넘어 누적되는 운영 능력을 갖게 됩니다. 이것이 단순 분류기와 에이전트의 차이입니다. 에이전트는 한 번의 답변보다, 다음 실행을 더 잘하게 만드는 절차와 기억이 필요합니다.

• 조사형 업무: 자료를 찾고, 비교하고, 모순을 정리하고, 결론을 업데이트합니다.
• 운영 분석: 여러 채널의 문의, 환불, 리뷰, 매출 데이터를 연결해 병목을 찾습니다.
• 고객 이슈 처리: 누락 정보를 묻고, 정책을 확인하고, 보상 후보를 만들고, 사람에게 올립니다.
• 개선안 설계: 현재 SOP, 예외, 비용, 리스크를 보고 다음 워크플로우를 제안합니다.
• 장기 작업: 중간 실패를 보고 계획을 수정하며 여러 번의 도구 사용을 이어갑니다.

5. 그러나 E2E는 무제한 자율이 아닙니다

E2E 에이전트라는 말은 매력적입니다. 하지만 회사 업무에서 E2E는 "처음부터 끝까지 알아서 실행"이 아니라 "목표를 이해하고 필요한 절차를 이어가되, 권한과 검증은 계층적으로 제한된다"에 가까워야 합니다.

OpenAI의 agent guide는 guardrail을 layered defense로 보고, 도구별 위험도를 read-only, reversibility, account permission, financial impact 같은 기준으로 나누라고 설명합니다. 또 실패 횟수 초과나 고위험 행동은 사람에게 넘겨야 합니다. 이 원칙은 어제 글의 사람 승인 경계와 그대로 연결됩니다.

NIST AI RMF 관점에서도 AI risk는 모델 성능만이 아니라 조직이 AI를 설계, 배포, 운영하는 방식에서 관리되어야 합니다. 즉 agent를 더 똑똑하게 만드는 것만큼 중요한 것은 로그, 추적, 권한, 롤백, 평가 기준을 같이 세우는 것입니다.

• 읽기 전용 도구와 쓰기 도구를 분리합니다.
• 환불, 결제, 계약, 대량 발송, 개인정보 처리에는 사람 승인을 둡니다.
• agent가 쓴 도구, 본 데이터, 바꾼 값, 실패한 시도를 모두 남깁니다.
• 실패 횟수와 시간 제한을 정해 무한 루프를 막습니다.
• 규칙 기반 guardrail과 LLM 기반 판단을 함께 씁니다.

6. 도입 순서: 워크플로우에서 시작해 에이전트 포켓을 만듭니다

작은 회사나 초기 도입팀에게 가장 현실적인 순서는 워크플로우를 버리고 agent로 뛰는 것이 아닙니다. 먼저 반복 업무를 workflow로 고정하고, 그 안에서 예외가 많이 생기는 구간만 agent pocket으로 떼어내는 것입니다.

예를 들어 문의 자동화라면 처음에는 분류와 초안 작성만 합니다. 그다음 "분류가 애매한 문의", "정책 문서를 여러 개 확인해야 하는 문의", "고객 맥락을 보고 보상 후보를 만들어야 하는 문의"만 agent에게 맡깁니다. 이때도 최종 발송이나 환불 실행은 사람이 승인합니다.

이 방식의 장점은 학습입니다. 사람의 수정, 보류, 승인, 거절이 쌓이면 어떤 일은 룰로 내려보낼 수 있고, 어떤 일은 계속 agent가 다뤄야 하며, 어떤 일은 아예 자동화하면 안 된다는 지도가 생깁니다.

• 1단계: 반복 업무를 분류하고 초안, 누락 체크, 위험 신호 표시부터 만듭니다.
• 2단계: 예외가 자주 생기는 구간을 기록합니다.
• 3단계: 그 예외 구간에만 agent가 도구를 쓰고 다음 행동을 고르게 합니다.
• 4단계: 사람 승인, 로그, 롤백, 평가 기준을 붙입니다.
• 5단계: 충분히 안정된 일부만 자동 실행으로 내립니다.

7. 실행 체크리스트: 이 질문에 답하면 경계가 보입니다

AI 자동화 설계 회의에서 "agent를 만들까요?"라고 묻기 전에 아래 질문부터 답해야 합니다. 답이 대부분 명확하면 workflow가 맞습니다. 답이 계속 바뀌고, 필요한 단계가 매번 다르고, 중간 결과에 따라 다음 행동이 달라지면 agent가 필요합니다.

Guildex가 보는 좋은 AI 도입은 이 경계를 먼저 그리는 일입니다. 어떤 업무를 룰로 고정하고, 어떤 업무를 agent에게 열어주고, 어떤 업무는 사람 승인 없이는 절대 실행하지 않을지 정리해야 자동화가 실제 운영 개선으로 이어집니다.

• 이 업무의 입력 유형과 출력 기준을 한 장으로 설명할 수 있는가
• 중간 결과를 보기 전에도 다음 단계가 정해져 있는가
• 예외가 늘어날 때 규칙표가 감당 가능한가
• 도구 사용 결과에 따라 agent가 계획을 바꿔야 하는가
• 실패했을 때 피해가 작고 되돌릴 수 있는가
• 사람 승인, 로그, 롤백, 권한 제한이 준비되어 있는가
• 사람이 고친 결과가 다음 규칙 또는 절차 기억으로 저장되는가