워크플로와 에이전트의 경계 — 경로를 누가 정하는가

"에이전트를 도입합시다"라는 말이 회의에서 나오면 대개 두 사람이 서로 다른 것을 떠올린다. 한쪽은 웹 검색을 붙인 챗봇을 생각하고, 다른 쪽은 목표만 주면 알아서 여러 단계를 밟는 무언가를 생각한다. 둘 다 최근 몇 년 사이 "에이전트"라고 불린 적이 있어서 어느 쪽도 틀렸다고 말하기 어렵다.

이 글은 그 단어의 뜻이 실제로 한 번 이동했다는 사실에서 출발한다. 판정 기준이 "도구를 쓰느냐"에서 "경로와 종료 시점을 누가 정하느냐"로 옮겨 갔고, 그 이동을 인정하는 순간 워크플로와 에이전트 사이에 아키텍처적 경계선이 생긴다. 경계선을 그은 다음에는 반대 방향의 질문이 따라온다 — 에이전트를 쓰지 말아야 할 때는 언제인가. 이 글의 절반은 그쪽에 쓰인다. 다음 편에서는 이 경계를 넘어간 쪽, 즉 자율성을 실제로 구현하는 패턴 카탈로그로 넘어간다.

이 글은 2025년 2월과 4월의 자료를 정리한 것이다. 두 시점에 같은 주제를 다시 다룬 자료가 있고, 두 판을 겹쳐 읽으면 회의론에서 표준화로 이동하는 흐름이 보인다. 등장하는 수치·제품·벤치마크는 모두 그 시점의 것이며 이후 갱신되지 않았다.

용어 정리

출발점 — LLM 단독이 부딪힌 네 개의 벽

2025년 4월 자료는 에이전트를 곧바로 정의하지 않고, 2023년에 기업이 ChatGPT를 도입하며 부딪힌 벽부터 센다. 에이전트를 "새로 나온 것"이 아니라 누적된 대응의 마지막 층으로 놓는 서사다.

네 벽 중 셋이 RAG로 상당 부분 해결된다. 남는 것은 "검색해서 → 메일 보내고 → 일정 잡아줘" 같은 요청이다.

RAG의 한계와 그 위에 얹히는 검증 루프는 Agentic RAG 편에 별도로 정리돼 있다. 여기서 중요한 것은 위 도식의 마지막 상자뿐이다 — 한 번의 검색으로 끝나지 않는 요청이 존재한다는 사실이 에이전트의 존재 이유다.

정의 — 그리고 정의가 한 번 이동했다

AI Agent는 목표를 달성하기 위하여 주변 환경을 관찰(observation)하고, 보유한 도구(tools)를 활용하여 행동(action)하는 자율적인 애플리케이션이다.

이 에이전트는 명시적인 인간의 지시 없이도 스스로 목표를 판단하고, 해당 목표를 달성하기 위한 최적의 행동을 계획할 수 있다.

— Google, Agents Whitepaper

이 정의를 네 속성으로 분해하면 다음과 같다.

네 속성 중 실무에서 판정 기준으로 쓸 수 있는 것은 첫 번째와 세 번째뿐이다. 도구 사용과 환경 피드백은 워크플로도 한다.

LLM 단독과 에이전트의 여덟 축

2월판(5축)과 4월판(6축)을 합치면 여덟 축이 된다. 겹치는 항목은 4월판 표현을 기준으로 했다.

여덟 축 중 마지막 두 개가 대가를 말한다. 앞의 여섯은 에이전트가 더 낫다고 읽히지만, 응답 시간이 유동적이라는 것은 p95 지연을 약속할 수 없다는 뜻이고 그것은 제품 요구사항이 될 수 있다.

사고실험 — ChatGPT는 LLM인가 에이전트인가

두 행의 차이는 모델이 아니라 도구 하나다. 그래서 결론이 "둘 중 하나"가 아니라 **"도구 활성 여부에 따라 성격이 달라지는 시스템"**이 된다. 검색을 상시 결합해 자율적으로 정보를 모으는 제품은 Agentic RAG 쪽에 더 가깝고, 그 계열을 화면에서 역추론한 기록은 Perplexity를 리버스 엔지니어링한 편에 있다.

판정 기준이 옮겨 갔다

판정 기준은 "도구를 쓰느냐"가 아니라 "경로와 종료 시점을 누가 정하느냐"다.

이 이동이 실무에서 값을 하는 이유는 판정 대상이 바뀌기 때문이다. 기존 기준으로는 기능 목록을 보고 판정했지만 — 검색이 되나, 코드를 돌리나 — 새 기준으로는 코드를 열어 조건부 엣지가 어디에 있는지를 봐야 한다. "도구를 다섯 개 붙였으니 에이전트"라는 문장은 새 기준에서 아무것도 말하지 않는다.

아키텍처적 구분 — 화살표가 미리 그려져 있는가

워크플로우와 에이전트 사이에는 중요한 아키텍처적 구분이 있다.

워크플로우는 정해진 규칙대로 순차적으로 수행하며, 이 과정에서 도구 호출이 사용될 수 있다. 에이전트는 변하는 환경과 주어진 도구를 활용하여 최적의 상황을 판단하며 수행하는 동적 프로세스다.

두 도식의 차이는 노드 수가 아니라 화살표의 성격이다. 위쪽은 화살표가 전부 미리 그려져 있고 Gate가 그중 하나를 고른다. 아래쪽에는 Action–Feedback 루프 하나뿐이고, 몇 바퀴 돌지·언제 Stop할지가 어디에도 그려져 있지 않다.

축을 늘리면 무엇이 보이나

원 자료가 제시한 네 축은 이렇다.

여기에 자료 전반에 흩어져 있던 운영 축을 더하면 여섯 줄이 붙는다.

도식은 둘인데 표는 두 개에 열 행이다. 도식이 말하는 것은 구조 하나 — 화살표가 미리 그려져 있는가 — 뿐이고, 표 열 행은 전부 그 하나에서 파생된 운영상의 귀결이다. 도식만 보면 "그래서 뭐가 문제인가"에 답할 수 없고, 표만 보면 열 가지가 서로 독립된 항목처럼 보인다.

"유연함"과 "비결정성"은 같은 것을 두 각도에서 부르는 이름이다.

세 번째 행이 그 사실을 드러낸다. 원 자료는 에이전트를 "유연하며, 같은 상황에서도 다른 판단이 작용할 가능성이 있음"이라고 적었는데, 앞의 절반은 세일즈 문구이고 뒤의 절반은 장애 리포트다. 같은 문장에 둘이 들어 있다. 도입을 검토할 때 앞의 절반만 인용되는 것이 이 단어가 위험한 이유다.

언제 에이전트를 쓰지 않아야 하는가

현재 에이전트라는 용어에 대한 흥미가 높지만, 많은 사람들이 실제로 그 의미를 잘 이해하지 못하고 있다. 그래서 이로 인해 불필요한 문제에 에이전트를 적용하려는 경향이 보인다. "소 잡는 칼로 닭을 잡을 필요는 없다."

에이전트를 사용할 적정 영역은 가치가 있으며 복잡한 작업으로, 오류 비용이 상대적으로 낮은 작업이다.

판단은 두 축의 교차로 정리된다.

네 칸 중 셋이 "에이전트를 쓰지 말거나 제한하라"고 말한다. 자율성이 온전히 허용되는 것은 왼쪽 위 한 칸뿐이다.

원 자료가 던진 검증 질문이 이 표를 한 문장으로 압축한다.

에이전트에게 값비싼 비행기 티켓 예매와 호텔 예약을 맡길 수 있는가?

이 질문이 좋은 이유는 복잡도를 묻지 않기 때문이다. 티켓 예매는 단계가 많지도 않고 경로가 애매하지도 않다. 그런데도 대부분 "아니오"라고 답한다면, 판단을 가른 것은 복잡도가 아니라 틀렸을 때의 대가다.

반대로 에이전트를 써야 하는 조건은 다섯 가지로 정리돼 있다.

다섯 조건 중 마지막 둘은 조건이 아니라 청구서다. 앞의 셋을 만족해서 에이전트를 쓰기로 했다면, 그 결정에 비용 증가와 샌드박스 구축이 자동으로 딸려 온다. 실행 권한이 붙는 순간 샌드박스가 무엇을 뜻하는지는 격리 등급을 4단계로 나눈 편에 정리돼 있다.

추천된 도메인은 상담원과 코딩 에이전트 둘이었고, 예시 제품으로는 OpenAI Operator, Anthropic Computer Use, AI 상담원이 제시됐다. 대표 프롬프트는 *"여행 계획을 세우고, 비행기 티켓을 구매하고, 호텔과 레스토랑을 예약해줘"*다. 바로 위에서 "맡길 수 있는가"라고 물었던 그 작업이 예시로 다시 나온다는 점이 이 자료의 긴장 지점이다.

워크플로가 적합한 경우

두 예시 모두 LLM 호출이 두 번 이상이고, 두 번째가 첫 번째 결과에 의존한다. 그런데도 워크플로인 이유는 호출 순서가 요구사항에 이미 적혀 있기 때문이다.

워크플로우란 LLM과 도구가 미리 정의된 코드 경로를 통해 오케스트레이션되는 시스템이며, 복잡한 파이프라인을 그래프 형태로 구성함으로써 흐름 관리가 용이하다.

복잡성이 요구되는 경우에도 워크플로우는 잘 정의된 작업에 대해 예측 가능성과 일관성을 제공한다. 여기서 읽어야 할 것은 "복잡성이 요구되는 경우에도"라는 단서다. 복잡하다는 이유만으로는 에이전트로 넘어갈 근거가 되지 않는다 — 복잡한 것과 경로를 그릴 수 없는 것은 다른 문제다.

결정 프레임 두 장

먼저 요구사항에서 시작하는 흐름이다.

이 도식은 분기가 셋인데 앞의 2×2 표는 칸이 넷이다. 도식이 표에 없는 축을 하나 더 갖고 있어서다 — "신뢰할 수 있는 환경인가"라는 세 번째 질문은 표의 어느 칸에도 없다. 반대로 표는 오류 비용이 높으면서 복잡도가 낮은 칸(결제·계약)을 명시하지만 도식은 그 경로를 D로 합쳐 버린다. 둘을 함께 봐야 네 칸과 세 질문이 다 남는다.

그리고 모든 경로가 M(측정 지표 설계)으로 수렴한다는 점이 이 도식의 진짜 주장이다. 워크플로를 골랐든 에이전트를 골랐든 측정은 면제되지 않는다.

두 번째 프레임은 작업 단위에서 시작하며, 첫 질문이 다르다.

가역성이 복잡도보다 먼저다.

앞 도식은 "분해 가능한가"를 먼저 묻고 오류 비용을 두 번째로 물었다. 이 도식은 순서를 뒤집는다. 되돌릴 수 없는 작업이라면 경로를 그릴 수 있든 없든 자율 대상이 아니기 때문에, 복잡도 질문을 먼저 하면 판정을 두 번 해야 한다. 실무에서는 이쪽 순서가 짧다 — 첫 질문에서 잘려 나가는 작업이 생각보다 많다.

가역성이 자율성의 상한을 정한다는 원칙은 코딩 에이전트의 권한 등급에서 읽기 → 로컬 실행 → 쓰기 → 배포의 4단 게이트로 구체화된다. 원칙과 구현이 같은 축 위에 있다.

여기까지가 "에이전트를 쓸 것인가"의 판단이다. 쓰기로 했다면 다음 질문은 무엇을 어떻게 조립할 것인가이고, 여기서 선택지가 갑자기 열한 개로 늘어난다.

프롬프트 체이닝부터 컴퓨터 유즈까지, 자율성 수준이 "없음"에서 "매우 높음"까지 걸쳐 있는 패턴들이 전부 "에이전트 아키텍처"라는 한 이름으로 불린다. 다음 편에서 에이전트를 구성 요소로 먼저 분해한 뒤, 그 열한 개를 자율성 축과 대표 실패 모드로 나란히 세운다.