업무 자동화에서 무엇을 쓸지는 질문 하나로 갈립니다. 흐름을 사람이 미리 정해둘 수 있는가. 흐름과 갈림길을 미리 다 그려둘 수 있다면 규칙 기반이나 고정 워크플로우로 충분하고, LLM이 실행 과정을 그때그때 정해야 한다면 그제야 에이전트가 필요합니다.
흔히 "LLM을 쓴다"와 "AI 에이전트를 쓴다"를 같은 말로 여기지만, 둘은 다릅니다. LLM(대규모 언어 모델)은 엄청난 양의 글을 학습해 사람 말을 알아듣고 새 문장을 만들어내는 AI입니다. 문의를 요약하거나 초안을 잡는 일은 이 LLM을 한 번, 또는 정해진 순서대로 부르는 '고정 워크플로우'만으로 됩니다. 반면 '에이전트'는 스스로 계획을 세우고 도구를 골라 여러 단계를 밟습니다. 그래서 경로를 미리 그려둘 수 없는 업무에만 필요합니다. 비정형 업무라고 무조건 에이전트여야 하는 것은 아닙니다(워크플로우와 에이전트의 구분, Anthropic).
먼저 큰 그림부터 그려봅시다.
컨베이어벨트를 떠올리면 규칙 기반 자동화의 본질이 보입니다. 벨트 위 부품은 정해진 자리에서 정해진 작업만 받습니다. 나사 조이는 자리에선 늘 나사를 조이고, 어제도 오늘도 똑같은 순서로 똑같은 결과가 나옵니다. 부품 모양이 갑자기 달라지면 벨트는 처리하지 못하고 라인이 멈춥니다.
일 잘하는 비서를 떠올리면 에이전트가 보입니다. "다음 주 워크숍 장소 좀 알아봐줘"라고만 해도, 비서는 인원·예산·지난번 평판까지 스스로 고려해 후보를 추려 옵니다. 세세히 지시하지 않아도 알아서 판단합니다. 대신 같은 지시를 다른 날 내리면 조금 다른 후보가 올 수도 있어, 비서가 가져온 결과엔 "이대로 예약해도 되는지" 한 번 확인하는 절차가 자연스럽게 붙습니다.
그 사이에 고정 LLM 워크플로우가 있습니다. 차례표는 컨베이어벨트처럼 고정돼 있지만, 각 자리에서 하는 일(요약·분류)은 비서의 판단을 조금 빌립니다. 이제 셋을 하나씩 뜯어봅니다.
Zapier, Make, n8n 같은 노코드 도구(코드를 직접 쓰지 않고 화면에서 블록을 이어 붙여 만드는 도구)가 답하는 질문은 "이 일이 생기면 저 일을 어떻게 자동으로 처리할까"입니다.
작동 방식은 트리거(trigger, 어떤 일이 벌어지는 신호)와 액션(action, 그 신호에 따라 실행할 동작)의 조합입니다. 예를 들어 "구글폼에 새 응답이 들어오면 → 스프레드시트에 행을 추가하고 → 슬랙에 알림을 보낸다"처럼 흘러갑니다. 조건과 결과가 사람이 미리 정해둔 대로 결정적으로, 즉 같은 입력이면 항상 같은 결과로 이어집니다.
장점은 분명합니다. 예측 가능하고, 어느 단계에서 무엇이 실행됐는지 로그로 한눈에 보입니다. 문제가 생기면 그 단계만 콕 집어 고칠 수 있고(이렇게 문제 지점을 찾아 고치는 일을 디버깅이라고 합니다), 실행 비용도 대체로 쌉니다.
한계도 같은 이유에서 나옵니다. 미리 정의한 경로 밖의 상황은 처리하지 못합니다. 새로운 경우가 생기면 분기(branch, 조건에 따라 길을 나누는 갈래)를 하나 더 붙여야 하고, 그걸 빠뜨리면 그 경우는 조용히 처리되지 않습니다. 분기가 늘수록 흐름은 얽히고, 나중엔 만든 사람도 전체를 못 따라가는 '분기 폭발' 상태가 됩니다.
요즘은 노코드 플랫폼이 에이전트 기능을 얹기도 합니다 — Zapier Agents, Make AI Agents. 그러니 진짜 기준은 '노코드냐 코드냐'가 아니라 '경로를 규칙으로 미리 고정하느냐, 시스템이 그때그때 정하느냐'입니다.
중간 단계가 있습니다. 글을 이해해야 하지만 처리 흐름은 늘 똑같은 업무입니다.
문서를 세 줄로 요약하거나, 문의를 정해진 카테고리로 분류하거나, 메일 초안을 잡는 일이 여기 속합니다. 더 엮을 수도 있습니다. 예를 들어 "문의 내용을 분석해 감성 점수를 매긴다 → 점수가 낮으면 사과 톤, 높으면 감사 톤으로 초안을 쓴다 → 담당자에게 넘긴다"처럼 LLM을 여러 번 부르되 그 순서는 늘 같습니다. 글을 이해하는 일이라 규칙만으로는 안 되지만, 거치는 단계와 갈림길은 미리 다 정해져 있습니다. 이럴 땐 정해진 자리에서 LLM을 부르면 됩니다. 스스로 계획을 세우는 에이전트까지는 필요 없습니다.
에이전트는 자연어 목표를 받아 스스로 계획을 세우고, 필요하면 검색이나 문서 조회 같은 도구를 호출하고, 중간 결과를 보며 다음 행동을 정합니다. 정해진 순서도가 없다는 점이 핵심입니다.
이 유연성 덕분에 사람이 모든 경우를 미리 정의하지 못한 모호한 요청도 다룹니다. "이번 분기 매출 보고 이상 징후 있으면 짚어줘" 같은 요청은 규칙으로 적어두기 어렵지만, 에이전트는 데이터를 훑고 스스로 판단 기준을 세워 결과를 냅니다.
대가도 있습니다. 가장 큰 특징은 비결정성입니다. 같은 입력을 줘도 실행할 때마다 결과가 조금씩 달라질 수 있다는 뜻입니다. 그래서 산출물은 사람의 검증이 필요하고, 사실이 아닌 내용을 그럴듯하게 지어내는 환각(hallucination, 예: 존재하지 않는 기능이나 정책을 사실인 양 언급하는 경우) 위험이 있으며, 매 실행마다 연산 비용이 듭니다.
| 구분 | 규칙 기반 (노코드) | 고정 LLM 워크플로우 | LLM 에이전트 |
|---|---|---|---|
| 입력 | 트리거 + 사전 정의 조건 | 자연어, 단 처리 흐름은 고정 | 자연어 목표·맥락 |
| 실행 경로 | 사람이 미리 그린 고정 경로 | 사람이 정한 흐름대로 LLM 호출(분기 포함) | 에이전트가 그때그때 계획 |
| 재현성 | 결정적 — 같은 입력이면 같은 결과 | 대체로 비슷, 표현은 조금 다를 수 있음 | 비결정적 — 매번 달라질 수 있음 |
| 강점 | 예측 가능·투명·저비용 | 흐름이 고정된, 글을 이해하는 작업 | 모호한 요청, 경로를 못 짜는 업무 |
| 한계 | 정의 밖 상황 불가, 분기 폭발 | 고정 흐름이라 예외 상황서 못 벗어남 | 검증 필요, 환각, 실행 비용 |
| 사람 개입 | 설계 시점(만들 때) | 실행 후 검증 | 실행 후 검증 |
업무를 아래 세 질문에 차례로 통과시킵니다. 앞 단계에서 걸리면 거기서 멈추고, 통과하면 다음 질문으로 넘어갑니다. 하나의 업무로 따라가 보겠습니다. 들어온 고객 문의를 처리하는 일입니다.
1단계 — 규칙만으로 처리할 수 있나? "제목에 '환불'이 있으면 환불팀 채널로 넘긴다." 조건과 결과가 딱 떨어지는 이런 부분은 규칙으로 고정합니다. 노코드의 자리입니다. 여기서 끝나는 일이라면 더 복잡한 도구를 꺼낼 이유가 없습니다.
2단계 — 정해진 흐름의 LLM 호출로 충분한가? "문의마다 핵심을 세 줄로 요약하고, 정해진 카테고리로 분류해 담당자에게 넘긴다." 요약과 분류는 글을 이해해야 하니 규칙만으론 안 됩니다. 하지만 '받는다 → 요약·분류한다 → 넘긴다'는 흐름은 매번 같습니다. 분류 결과에 따라 보내는 곳이 갈리더라도 — 환불 문의면 결제 기록 조회, 사용법 문의면 안내 문서 조회 — 그 갈림길을 사람이 미리 다 정해둘 수 있다면 이 역시 고정 워크플로우(라우팅)입니다. 이럴 땐 LLM을 정해진 자리에서 부르는 것으로 충분합니다. 아직 에이전트는 필요 없습니다.
3단계 — 흐름과 도구 사용을 LLM이 실행 중에 스스로 정해야 하나? 갈리는 기준은 '길이 갈라지느냐'가 아닙니다. 길이 갈라져도 그 갈림길을 사람이 미리 다 적어둘 수 있으면 2단계의 고정 워크플로우로 족합니다. 진짜 3단계는 흐름 자체를 미리 적어둘 수 없을 때입니다. "'제품이 생각과 다르다'처럼 두루뭉술한 문의"는 무엇부터 확인할지, 몇 단계를 밟을지, 어떤 도구를 쓸지가 미리 정해지지 않습니다. 과거 문의를 뒤져 나온 내용에 따라 다음에 결제 기록을 볼지, 배송 이력을 볼지, 안내 문서를 볼지를 그때그때 판단해야 하고, 그 조합을 사람이 사전에 다 열거하기 어렵습니다. 실행 과정과 도구 선택을 LLM이 스스로 꾸려야 하는 이 지점이 에이전트의 자리입니다.
세 질문을 순서대로 던지면 "비정형이니까 무조건 에이전트"라는 과잉 선택을 피할 수 있습니다. 실제로 많은 업무가 1단계나 2단계에서 끝납니다.
실무의 답은 셋 중 하나만 고르는 게 아니라 섞는 것입니다. 앞의 고객 문의로 돌아가 보죠. 두루뭉술한 문의를 읽고 무엇을 확인할지 정해 답변 초안을 만드는 경로 탐색 부분은 에이전트가 맡고, 그렇게 나온 답변을 고객 관리 시스템(CRM, 고객 정보를 모아 관리하는 시스템)에 기록하고 담당자에게 알리는 정형 부분은 규칙으로 넘깁니다. 하나의 도구로 억지로 통일하지 않고, 각자 잘하는 영역을 맡기는 것입니다.
이 구조에서 빠지면 안 되는 것이 사람의 확인 게이트입니다. 에이전트가 만든 초안을 그대로 내보내면, 비결정성 때문에 가끔 나오는 애매한 결과가 검증 없이 나가버립니다. 그래서 "에이전트가 초안을 만든다 → 사람이 확인한다 → 확인된 것만 다음 단계로 넘어간다"를 기본값으로 둡니다.
이 '섞어 쓰기'와 '사람의 확인 게이트' 원칙을 서비스에 그대로 담은 사례가 온틀입니다.
온틀에 이렇게 적어 보냅니다. "이번 주 밀린 고객 문의, 핵심만 추려서 답변 초안까지 잡아줘."
파견된 AI 에이전트는 미리 짜인 버튼을 고르는 방식이 아닙니다. 문의 하나하나를 읽고, '제품이 생각과 다르다'처럼 두루뭉술한 건은 과거 비슷한 문의부터 찾아봅니다. 거기서 환불로 이어진 사례가 많으면 주문·결제 기록까지 확인하고, 단순 사용법 문제였다면 안내 문서를 끌어와 톤을 맞춥니다. 무엇을 몇 단계에 걸쳐 더 볼지를 미리 짜둘 수 없어, 에이전트가 실행 과정을 그때그때 꾸립니다 — 이 부분이 에이전트의 자리입니다.
그렇게 만들어진 초안을 당신이 열어 봅니다. 톤이 센 한 건을 부드럽게 고치고, 사실이 틀린 한 줄을 바로잡습니다. 사람이 확인한 답변만 다음 단계로 넘어갑니다 — 위에서 말한 '확인 게이트'가 구조에 내장돼 있는 셈입니다. 고정된 규칙만으로는 담기 어려운 유연성을 가져가면서도, 에이전트 단독 사용의 가장 큰 위험인 "검증 없는 실행"을 피합니다.
물론 온틀이 모든 자동화를 대체하진 않습니다. 완전히 정형화된 고빈도 반복 업무라면 노코드 자동화가 비용과 예측 가능성에서 여전히 유리합니다. 온틀이 강점을 갖는 곳은 확인할 것이 매번 달라져 규칙으로 정의하기 어려웠던, 사람이 매번 직접 붙어야 했던 비정형 업무입니다.
아니요. 지금 워크플로우가 예측 가능한 결과를 잘 내고 있다면 바꿀 이유가 없습니다. 에이전트는 노코드로는 다루기 어려웠던 '흐름을 미리 짜둘 수 없는 업무'를 더해주는 도구이지, 기존 자동화를 걷어내는 도구가 아닙니다.
있습니다. 사람이 하는 일이 "처음부터 끝까지 직접 작성"에서 "만들어진 초안을 검토"로 바뀌기 때문입니다. 검토에 드는 시간은 처음부터 만드는 것보다 훨씬 짧습니다. 완전 무인은 아니지만, 사람의 작업량 자체가 크게 줄어듭니다.
결정적 결과가 반드시 필요한 업무입니다. 회계 처리나 재고 이동처럼 같은 입력이면 반드시 같은 결과가 나와야 하는 일은, 조금의 편차도 위험합니다. 이런 업무는 1단계, 즉 규칙 기반 자동화에 맡기는 것이 맞습니다.
반복 업무는 규칙으로, 흐름을 미리 짜둘 수 없는 업무는 대화로 맡기고 싶다면 온틀에서 시작해보세요. 대화형 AI 에이전트가 요청을 해석해 산출물을 만들고, 사람이 확인하는 구조로 설계되어 있습니다.
https://ontle.kr
저자: 박도현