실전 AI 에이전트 — 파트 5: 워크플로우(Workflow), 에이전트(Agent), 또는 단일 LLM 호출(Single LLM Call)

8부작 중 5부 — 실전 AI 에이전트 (AI Agents in Practice) 시리즈.

이전 글 — 다섯 가지 에이전트 패턴과 안전성을 보장하는 제어 표면 (파트 4)

실수: 작업의 형태(Task Shape) 대신 에이전트로 시작하는 것

TechNova가

단일 LLM 호출 (Single LLM call). 한 번의 모델 호출, 한 번의 응답. 에이전트 루프(Agent loop)도, 동적인 도구 선택(Dynamic tool choice)도 없습니다. 모델은 입력을 받고 출력을 반환하며, 시스템은 그 출력을 사용하거나 사용하지 않습니다. 주변 코드가 검증(Validation), 재시도(Retries), 또는 포맷팅(Formatting)을 추가할 수는 있지만, 모델 자체는 한 번의 턴(Turn)에서 하나의 작업만 수행합니다. 이것은 가능한 가장 단순한 형태이며, 대부분의 엔지니어가 생각하는 것보다 더 많은 프로덕션(Production) 문제를 해결합니다 — 이 사례를 요약하거나, 이 티켓을 분류하거나, 첫 번째 답장 초안을 작성하는 것과 같은 작업들 말입니다.

사전 정의된 워크플로우 (Predefined workflow). 개발자가 설계한 일련의 단계(Steps)입니다. 단계에는 LLM 호출, 코드, 도구 호출(Tool calls), API 요청, 데이터베이스 조회(Database lookups), 재시도, 검증 게이트(Validation gates), 병렬 분기(Parallel branches), 그리고 조건부 라우팅(Conditional routing)이 포함될 수 있습니다. 가능한 경로의 그래프(Graph)는 설계 시점에 고정됩니다. 모델이 단계 내부에서 결정을 내릴 수는 있지만, 그래프의 구조는 개발자의 몫입니다. 파트 3에서 다룬 상태 전이(State transitions)를 에이전트 방식의 다음 단계 선택(Agentic next-step choice) 없이 생각해보세요. 흐름은 동일하지만, 모든 엣지(Edge)가 개발자에 의해 그려진 형태입니다.

하나의 에이전트적 단계가 포함된 하이브리드 워크플로우 (Hybrid workflow with one agentic step). 사전 정의된 워크플로우 내에, 모델이 사전 정의된 옵션들 사이에서 동적으로 선택할 수 있도록 허용된 하나의 제한된 결정 지점(Bounded decision point)이 있는 형태입니다. 워크플로우는 예측 가능한 부분들 — 인증(Authentication), 데이터 가져오기(Data fetching), 검증, 그리고 입력값과 상관없이 순서대로 반드시 일어나야 하는 단계들을 처리합니다. 에이전트는 결정론적 규칙(Deterministic rule)이 없는 중간의 단 하나의 결정을 처리합니다. 그 후 다시 워크플로우가 제어권을 넘겨받습니다.

단일 에이전트 (Single agent). 모델이 지금까지 관찰한 내용을 바탕으로 런타임(Runtime)에 다음 단계를 결정하는 루프(Loop)입니다. 개발자는 사용 가능한 도구(Tools), 중단 조건(Stopping condition), 예산(Budget), 그리고 경계(Boundaries)를 정의합니다. 모델이 시퀀스(Sequence)를 결정합니다. 매 턴마다 상태를 관찰하고 행동(Action)을 선택합니다. 경로는 모델과 환경(Environment) 사이의 상호작용을 통해 나타납니다.

멀티 에이전트 시스템 (Multi-agent system). 각각 고유한 범위를 가진 여러 에이전트가 협력하여, 단일 에이전트가 혼자서는 깔끔하게 해결할 수 없는 작업을 수행합니다. 전문화(Specialization)는 비용을 정당화하는 속성입니다. 즉, 서로 다른 도메인, 서로 다른 도구, 서로 다른 메모리, 서로 다른 검토 책임을 갖습니다. 조정 계층(Coordination layer) 그 자체도 설계 문제이며, 결코 공짜로 얻어지는 것이 아닙니다.

D1 — 아키텍처 사다리 (The Architecture Ladder)

이 사다리를 처음 보는 독자는 가능한 한 높이 올라가는 것이 목표라고 생각할 수도 있습니다. 하지만 실제로는 그 반대에 가깝습니다. 토큰(Tokens), 지연 시간(Latency), 디버깅 가능성(Debuggability), 신뢰성(Reliability), 감사 난이도(Audit difficulty), 그리고 시스템을 건강하게 유지하는 데 필요한 엔지니어의 시간(Engineer-hours) 측면에서 각 단계(Rung)를 운영하는 비용은 사다리를 올라갈수록 증가합니다. 표현력(Expressive power) 또한 증가하지만, 작업 요구 사항을 초과하는 표현력은 그저 비용만 많이 들 뿐입니다.

이 사다리는 기능의 목록이 아닙니다. RAG, 도구(Tools), 데이터베이스(Databases), 큐(Queues), API 등은 이 단계들 중 여러 곳에 나타날 수 있습니다. 동일한 검색(Retrieval) 단계라도 단일 호출 전의 컨텍스트 가져오기(Context fetch), 사전 정의된 워크플로우(Workflow) 내의 노드(Node), 또는 에이전트가 루프(Loop) 내에서 호출하는 도구(Tool)로 나타날 수 있습니다. 사다리는 시스템이 무엇을 _포함하는가_에 관한 것이 아니라, 누가 다음 단계를 제어하는가와 시스템이 실행 시점에 어느 정도의 자유도(Runtime freedom)를 갖는가에 관한 것입니다.

목표는 정당화할 수 있는 가장 에이전트적인(Agentic) 형태를 사용하는 것이 아닙니다. 작업을 정직하게 처리할 수 있는 가장 낮은 단계의 사다리를 사용하는 것입니다. 하이브리드(Hybrid) 방식은 상당수의 사례에서 유효한 안정 상태(Steady-state)의 형태이며, 단일 에이전트(Single agent)가 적절한 경우는 그보다 적고, 멀티 에이전트(Multi-agent)가 적절한 경우는 훨씬 더 적습니다. 만약 분포에 대한 당신의 감각이 이와 반대라면, 이 글의 마지막에 있는 경고 징후(Warning-signs) 섹션이 당신을 위한 것입니다.

진짜 질문: 누가 다음 단계를 결정하는가?

결정적인 요인은 복잡성이 아닙니다. 바로 누가 다음 단계를 결정하느냐입니다.

TechNova에 다음과 같은 규칙이 있다고 가정해 봅시다: 환불 금액이 500달러를 초과하면 사람의 승인 단계로 라우팅(route)한다. 모델은 사례를 요약하거나, 사유를 분류하거나, 답변 초안을 작성할 수는 있지만, 다음 단계는 시스템이 실행되기도 전에 코드로 이미 결정된 것입니다. 그 지점은 워크플로우 (Workflow)입니다. 이제 주문 데이터, 고객의 메시지, 보증 문구, 배송 상태가 모두 상충하여, 시스템이 사진을 요청할지, 재고를 확인할지, 보증 부서로 에스컬레이션(escalate)할지, 아니면 교체 제안 초안을 작성할지 등 올바른 다음 단계가 무엇인지 미리 알 수 없다고 가정해 봅시다. 만약 모델이 방금 확인한 내용을 바탕으로 런타임 (Runtime)에 그 다음 단계를 선택한다면, 그 지점은 에이전트적 (Agentic)입니다.

이것이 전체적인 차이점이며, 여러분이 어떤 복잡한 상황을 제시하더라도 이 원칙은 유지됩니다. 세 번의 LLM 호출, 병렬 분기, 재시도(retry), 조건부 라우터(conditional router)를 갖춘 시스템이라 할지라도, 개발자가 그래프를 그렸고 모델이 단지 미리 정의된 경로 중에서만 선택한다면 그것은 여전히 워크플로우입니다. 단 한 번의 LLM 호출과 하나의 도구(tool)를 가진 시스템이라 할지라도, 모델이 도구를 호출할지, 무엇을 전달할지, 그리고 그 결과로 무엇을 할지를 결정한다면 그것은 여전히 에이전트입니다. 도구 사용 여부가 이를 결정짓지 않습니다. 의사결정을 하는지 여부도, 모델을 여러 번 호출하는지도 결정 요인이 아닙니다. 오직 하나의 질문만이 이를 결정합니다: 다음 단계가 불분명할 때, 누가 선택하는가 — 설계 시점(design time)의 개발자인가, 아니면 런타임(runtime)의 모델인가?

파트 2의 언어를 빌리자면, 우리는 그 지점에서 관찰(observe) → 결정(decide) → 실행(act) 루프를 누가 소유하고 있는지를 묻고 있는 것입니다 — 코드인가, 아니면 모델인가.

만약 개발자가 설계 시점에 선택하고 그 선택을 코드에 작성했다면, 그 지점에서 시스템은 워크플로우입니다. 그 선택은 조건부일 수도 있고 ("티켓이 24시간 후에도 해결되지 않으면 에스컬레이션한다"), 분기형일 수도 있으며 ("세 가지 카테고리 중 하나로 분류한다"), 심지어 확률적일 수도 있습니다 ("최대 3번까지 재시도한다"). 그것은 여전히 개발자의 선택이며 — 한 번 인코딩(encoded)되어 매번 실행될 뿐입니다.

만약 모델이 방금 관찰한 내용을 바탕으로 런타임(runtime)에 선택을 내린다면, 그 시점에서 시스템은 에이전트적(agentic)입니다. 그 선택은 사전에 열거될 수 없는데, 왜냐하면 선택에 정보를 제공할 입력값들이 시스템이 실행되기 전까지는 존재하지 않기 때문입니다. 모델은 상태(state)를 살펴보고, 옵션들을 저울질하며, 하나를 선택하고, 행동을 취하고, 결과를 관찰한 뒤, 다시 결정합니다.

그 외의 모든 것들 — 복잡성(complexity), 비용(cost), 도구 사용(tool use), 분기(branching), 지연 시간(latency) — 은 바로 그 선택으로부터 파생됩니다.

많은 시스템이 혼합된 영역(mixed territory)에 위치합니다. 워크플로우(workflow)가 대부분을 결정하고, 모델이 단 한 가지를 결정하는 식입니다. 이것이 하이브리드(hybrid) 사례입니다. 하이브리드는 바로 그 분리를 명명한 것뿐입니다. 워크플로우는 예측 가능한 경계(edges)를 소유하고, 모델은 경계를 깔끔하게 그릴 수 없는 하나의 제한된 결정(bounded decision)을 소유합니다. 사다리의 맨 위와 맨 아래에 있는 깔끔한 형태들은 더 단순합니다. 중간 부분이 실제로 대부분의 배포된 시스템이 존재하는 곳입니다.

이 결정에는 복잡한 프레임워크가 필요하지 않습니다. 다음 단계의 선택권을 누가 갖느냐 — 코드인가, 아니면 모델인가 — 를 묻는 것부터 시작하십시오. 아래의 다이어그램은 그 질문의 실무적인 버전이며, 이어지는 다섯 가지 결정 요인들은 그 질문을 더욱 날카롭게 만들어 줄 뿐입니다.

D2 — 누가 다음 단계를 결정하는가?

요약하자면:

• 런타임 이전에 코드가 다음 단계를 선택한다면, 그 지점은 워크플로우(workflow)입니다.
• 모델이 방금 관찰한 내용을 바탕으로 런타임에 다음 단계를 선택한다면, 그 지점은 에이전트적(agentic)입니다.
• 대부분의 실제 시스템은 하이브리드(hybrid)입니다: 코드가 예측 가능한 경계를 소유하고, 모델이 하나의 제한된 결정을 소유합니다.

워크플로우는 단순한 파이프라인이 아니라 그래프입니다

흔한 오해로 인해 워크플로우 옵션이 실제보다 약해 보이곤 합니다. 많은 엔지니어들이 워크플로우를 1단계, 2단계, 3단계로 이어지는 선형 파이프라인(linear pipeline)으로 생각합니다. 실제 프로덕션 워크플로우는 선형이 아닙니다. 그것들은 그래프(graphs)입니다.

워크플로우(workflow)는 분기(branch)할 수 있습니다. 워크플로우는 병렬(parallel)로 실행될 수 있습니다. 워크플로우는 라우팅(route)할 수 있습니다. 워크플로우는 재시도(retries), 검증 게이트(validation gates), 에러 처리 경로(error-handling paths), 인간 검토 단계(human review steps), 중간 결과에 기반한 조건부 로직(conditional logic), 그리고 팬아웃/팬인(fan-out / fan-in) 패턴을 포함할 수 있습니다. 워크플로우는 한 노드에서는 분류(classification)를 위해, 다른 노드에서는 요약(summarization)을 위해 LLM을 호출할 수 있으며, LLM의 출력을 사용하여 어떤 분기를 따를지 결정할 수 있습니다.

워크플로우가 잘 수행할 수 없는 것은 시스템에 설계되지 않은 새로운 경로를 결정하는 것입니다.

그 마지막 문장이 경계선입니다. 워크플로우는 개발자가 그린 그래프(graph) 내에서 작동합니다. 그 그래프는 조밀하고, 분기되며, 풍부할 수 있습니다. 하지만 그래프의 모든 엣지(edge)는 시스템이 실행되기 전에 이미 존재했습니다. 워크플로우가 처리 방법을 모르는 입력을 만나면, 기본 경로로 라우팅하거나, 인간에게 에스컬레이션(escalate)하거나, 에러와 함께 실패하거나, 불완전하게 패턴 매칭(pattern-match)을 할 수는 있지만, 이미 존재하지 않는 경로를 선택할 수는 없습니다.

에이전트(agent)는 — 당신이 부여한 도구와 경계 내에서 — 그것이 가능합니다. 개발자는 도구 세트(tool set), 예산(budget), 중단 조건(stopping condition), 그리고 환경의 규칙을 정의합니다. 이러한 제약 조건 내에서, 에이전트는 사전에 그려지지 않은 행동 시퀀스(action sequence)를 선택할 수 있습니다. 그것이 에이전트만의 독특한 움직임입니다.

언급할 만한 미묘한 차이가 하나 있습니다. 문제는 시스템이 워크플로우 엔진(workflow engine), 그래프 프레임워크(graph framework), 또는 커스텀 루프(custom loop)로 구현되었는지 여부가 아닙니다. 워크플로우 엔진이 에이전트를 호스팅할 수 있고, 커스텀 루프가 워크플로우를 호스팅할 수 있습니다. 구현은 하위 단계(downstream)의 문제입니다. 핵심 질문은 다음 단계의 결정권을 누가 갖느냐 — 코드인가, 아니면 모델인가 하는 점입니다. 워크플로우 엔진이 에이전트를 구현할 수 있지만, 그렇다고 해서 모든 워크플로우가 에이전트라는 의미는 아닙니다.