블로그 / 왜 AI Agent는 Workflow 없이는 안 될까? 현대 AI 애플리케이션의 밑바닥 설계 이해하기

왜 AI Agent는 Workflow (워크플로) 없이는 안 될까? 본문은 Prompt (프롬프트), Workflow (워크플로)에서 Agent (에이전트)로의 진화 과정을 Prompt, LangGraph, n8n 등 주요 솔루션과 결합하여 설명하며, 현대적인 AI 워크플로 설계 사고방식을 명확히 전달하고 코드 예제를 통해 Agent의 작동 메커니즘을 이해하도록 돕습니다.

읽는 시간 약 12분 ｜ AI Agent, Workflow, LangGraph를 체계적으로 이해하고자 하는 개발자에게 적합합니다.

1. Prompt와 Workflow의 근본적인 차이

AI에게 기사를 요약해 달라고 하면 결과가 괜찮습니다. 그러다 문득 '웹페이지를 먼저 긁어오고, 요약하고, 번역한 뒤, 이메일을 보내면 어떨까?'라는 생각이 듭니다. 모든 요구사항을 하나의 prompt (프롬프트)에 몰아넣고 한 번에 처리하게 합니다. 결과는 번역을 잊어버리거나 이메일 형식이 틀리는 식입니다. 당신은 이것이 프롬프트를 잘 쓰지 못해서라고 생각하겠지만, 사실은 구조적인 문제입니다. 당신에게 필요한 것은 프롬프트가 아니라 workflow (워크플로)입니다. 이 글에서는 프롬프트와 워크플로의 차이점, 그리고 실제로 작동하는 AI Agent 워크플로를 설계하는 방법을 명확히 설명합니다.

Prompt (프롬프트)는 일회성 대화입니다. 당신이 한 마디 하면, AI가 한 마디 답합니다.

Workflow (워크플로)는 다회성 대화의 조합입니다. 복잡한 작업을 여러 단계로 나누고, 각 단계마다 하나의 프롬프트를 사용하며, 이전 단계의 출력을 다음 단계의 입력으로 사용하여 하나의 파이프라인을 구축합니다.

가장 간단한 예를 들어보겠습니다: 영어 기사를 중국어로 번역하는 것이라면 프롬프트 하나로 한 번에 해결할 수 있습니다. 하지만 매일 10개의 영어 기술 블로그 신규 기사를 긁어와서, 중국어로 번역하고, 키워드를 추출하고, 주제별로 분류하고, 요약을 생성하여 Feishu (페이슈) 그룹에 전송해야 한다면 어떨까요? 이것은 프롬프트 한 문장으로 해결할 수 있는 문제가 아닙니다. 다음과 같은 과정이 필요합니다:

1. 기사 긁어오기 (스크립트) 2. 번역 (AI) 3. 키워드 추출 (AI) 4. 분류 (AI) 5. 요약 생성 (AI) 6. Feishu 전송 (스크립트)

각 단계는 고유한 입출력을 가진 독립적인 작업입니다. 이것이 바로 workflow (워크플로)입니다.

판단 기준은 매우 간단합니다:

• 작업이 한 단계로 완료됨 → Prompt (프롬프트)
• 작업이 여러 단계가 필요하며, 각 단계마다 명확한 입출력이 있음 → Workflow (워크플로)
• 작업이 이전 단계의 결과에 따라 다음 행동을 결정해야 함 → Workflow (워크플로, 조건부 분기 포함)

2. Workflow의 4가지 핵심 구성 요소

어떤 도구(LangChain, Dify, n8n, Coze, 직접 작성한 코드)를 사용하든, workflow (워크플로)는 다음 네 가지 구성 요소로 이루어집니다:

1. 노드 (Node)

하나의 노드는 한 가지 일을 수행합니다. AI를 호출할 수도 있고, 스크립트를 실행하거나, 데이터베이스를 조회하거나, 요청을 보낼 수도 있습니다.

각 노드는 세 가지 요소를 가집니다: - 입력 (Input): 어디서 데이터를 가져오는가 - 처리 (Process): 어떤 일을 하는가 - 출력 (Output): 다음 노드에 무엇을 주는가

2. 엣지 (Edge)

노드 사이의 데이터 흐름입니다. A의 출력이 B의 입력으로 연결됩니다.

3. 조건 (Condition)

이전 단계의 결과에 따라 어떤 경로로 갈지 결정합니다. 예: "만약 요약 길이가 200자보다 길면 요약 분기(branch)로 가고, 그렇지 않으면 원문 분기로 간다."

4. 루프 (Loop)

일련의 데이터에 대해 동일한 프로세스를 반복 실행합니다. 예: "10개의 기사에 대해 번역+요약 과정을 개별적으로 실행한다."

이 네 가지를 기억하세요. 모든 워크플로 도구는 이들의 변형일 뿐입니다.

3. 완전한 Workflow 예시

요구사항: 매일 아침 8시, 3개의 기술 블로그 최신 기사를 긁어와서 중국어로 번역하고, 요약을 생성한 뒤, 품질 점수(1-5점)를 매깁니다. 3점보다 높으면 Feishu로 보내고, 낮으면 아카이브합니다.

텍스트로 그려보기:

[정기 트리거]
    ↓
[기사 긁어오기] ← 스크립트 노드, AI 아님
...

만약 하나의 프롬프트로 처리한다면 어떤 문제가 생길까요?

• 신뢰할 수 없음. AI에게 한 번에 5가지 일을 시키면 종종 한두 가지를 누락합니다. - 재사용 불가. '채점 기준'을 바꾸려면 프롬프트 전체를 다시 써야 합니다. 단계를 나누면 채점 노드만 수정하면 됩니다. - 디버깅 불가. 오류가 발생했을 때 번역이 틀린 것인지 채점이 틀린 것인지 알 수 없습니다. 단계를 나누면 각 단계를 개별적으로 테스트할 수 있습니다. - 병렬 처리 불가. 3개의 기사를 3개의 병렬 파이프라인으로 나누면 속도가 3배 빨라지지만, 하나의 프롬프트에 넣으면 순차적으로 처리할 수밖에 없습니다.

이것이 workflow (워크플로)의 핵심 가치입니다: 신뢰할 수 없는 '전능한 프롬프트'를 신뢰할 수 있는 '전용 노드'로 분해하는 것입니다.

4. Workflow 설계를 위한 5가지 원칙

원칙 1: AI를 쓸 수 있다면 쓰지 마라

모든 노드가 AI를 호출할 필요는 없습니다. 웹페이지 긁어오기, 메시지 보내기, 데이터베이스 조회, 수학 계산 등은 스크립트를 사용하는 것이 더 빠르고 정확하며 저렴합니다.

초보자들이 가장 자주 하는 실수는 모든 것을 AI에게 맡기는 것입니다. AI에게 주문 총액을 계산하게 하고, AI에게 SQL을 조합하게 하고, AI에게 날짜 형식을 맞추게 합니다. 이러한 결정론적인(deterministic) 작업은 스크립트 한 줄이면 해결되며, 오히려 AI는 실수하기 쉽습니다.

판단 기준: 만약 해당 작업의 출력에 유일한 정답이 있다면, AI를 사용하지 마세요. AI는 '모호하고, 이해가 필요하며, 창의적인' 작업에 적합합니다.

원칙 2: 각 AI 노드는 한 가지 일만 수행한다

하나의 노드 = 하나의 책임입니다.

나쁜 설계:

[AI 노드: 번역 + 요약 + 점수 매기기 + 분류]

좋은 설계:

[AI 노드: 번역] → [AI 노드: 요약] → [AI 노드: 점수 매기기] → [AI 노드: 분류]

분리했을 때의 장점: - 각 노드의 프롬프트 (Prompt)가 더 짧고 정확해짐 - 개별 테스트가 더 쉬움 - 오류 발생 시 구체적인 노드를 특정할 수 있음 - 병렬 실행 가능 (번역과 점수 매기기를 동시에 실행 가능)

원칙 3: 노드 간에는 구조화된 데이터로 전달한다

노드 사이의 데이터 형식은 명확해야 합니다. JSON 사용을 권장합니다.

나쁜 설계: AI가 자연어 (Natural Language) 한 단락을 출력하게 하고, 다음 AI 노드가 그 말을 다시 "이해"하도록 만드는 것.

좋은 설계:

// 번역 노드의 출력
{
  "original_title": "GPT-5 Released",
...

다음 노드는 "이해"할 필요 없이 JSON 필드를 직접 읽으면 됩니다.

Function Calling 또는 JSON Mode와 함께 사용할 때 효과가 가장 좋습니다. AI가 자연어 속에 JSON을 끼워 넣는 것이 아니라, 강제로 JSON을 출력하도록 만드세요.

원칙 4: 각 노드에는 반드시 "실패 처리"가 있어야 한다

AI는 실패할 수 있습니다. 타임아웃 (Timeout), 속도 제한 (Rate Limit), 출력 형식 오류, 콘텐츠 차단 등이 발생할 수 있습니다. 당신의 워크플로 (Workflow)는 반드시 이러한 상황을 처리할 수 있어야 합니다.

가장 간단한 방법: 각 AI 노드에 재시도 (Retry) + 폴백 (Fallback)을 구성합니다.

[AI 노드] 
  ├── 성공 → 계속 진행
  ├── 실패 → 3회 재시도
...

실패 처리를 설계하지 않은 워크플로는 두 번만 돌려도 무너집니다.

원칙 5: 병렬로 할 수 있다면 병렬로 한다

직렬 (Serial)은 느리고, 병렬 (Parallel)은 빠릅니다. 동시에 실행할 수 있는 노드는 줄을 세우지 마세요.

# 직렬 (느림)
[번역] → [요약] → [점수 매기기] → [분류]   총 소요 시간 12초

...

번역이 완료된 후, 요약, 점수 매기기, 분류 세 노드는 서로 의존성이 없으므로 동시에 실행할 수 있습니다.

모든 노드가 병렬로 가능한 것은 아닙니다. 의존 관계가 있는 노드는 반드시 직렬로 처리해야 합니다. 하지만 의존성이 없다면 무조건 병렬로 처리하세요.

5. 워크플로 도구 선택 방법

사용 진입 장벽이 낮은 순서부터 높은 순서대로 나열하면 다음과 같습니다.

1. 시각화 도구 (Dify, Coze, FastGPT)

노드를 드래그 앤 드롭하여 연결하며, 코드를 작성할 필요가 없습니다. 비기술자나 아이디어를 빠르게 검증하고 싶은 사람에게 적합합니다. 단점은 복잡한 로직을 표현하기 어렵고, 도구의 기능에 제약을 받는다는 점입니다.

2. 자동화 도구 (n8n, Make, Zapier)

"다양한 서비스를 연결"하는 데 더 특화되어 있습니다. AI는 그중 하나의 노드 유형일 뿐입니다. "AI + 기존 시스템"의 통합 시나리오에 적합합니다.

3. 코드 프레임워크 (LangChain, LangGraph, LlamaIndex)

코드를 작성하여 매 단계를 제어합니다. 가장 유연하지만 진입 장벽이 가장 높습니다. 정밀한 제어와 장기적인 유지보수가 필요한 프로젝트에 적합합니다.

4. 직접 코드 작성

API를 직접 호출하고 흐름 제어를 직접 작성합니다. 가장 단순하고 직관적이며, 간단한 워크플로에 적합합니다. 프레임워크에 의존하지 않으므로 학습 비용이 없습니다.

나의 제안: 직접 코드를 작성하는 것부터 시작하세요. 충분히 고민한 후에 프레임워크를 도입하세요. 프레임워크가 당신 대신 생각하게 만들지 마세요.

6. 실행 가능한 최소한의 코드 예시

Python + OpenAI SDK를 사용하여 앞서 언급한 "번역 + 요약 + 점수 매기기" 워크플로를 작성하면 50줄도 채 되지 않습니다.

from openai import OpenAI
import json

...

각 단계는 독립적인 함수이며, 입출력이 명확하고 개별적으로 테스트 가능합니다. "점수 매기기 기준"을 바꾸고 싶다면 score 함수만 수정하면 되며, 다른 부분은 영향을 받지 않습니다.

이것이 바로 워크플로의 본질입니다: 큰 작업을 작은 함수로 나누고, 각 함수가 한 가지 일만 수행하게 한 뒤, 이를 하나로 엮는 것입니다.

본문 예시는 Token Supply Station (https://addtoken.top)을 사용하여 테스트되었습니다. 이 플랫폼은 OpenAI 및 Anthropic과 호환되는 API를 제공하며 공식 프로토콜과 일치합니다. 이 워크플로를 실행할 때 언제든지 기반 모델을 전환할 수 있어, 각 노드에서 GPT, Claude, DeepSeek의 성능 차이를 비교하기 편리합니다.

7. 워크플로의 흔한 실수 (Pitfalls)

실수 1: 워크플로를 프롬프트처럼 작성하는 것

모든 로직을 하나의 매우 긴 프롬프트에 집어넣고 AI가 스스로 어느 단계를 밟을지 "결정"하게 만드는 것입니다. 결과는 예측 불가능하고 디버깅이 어렵습니다. 기억하세요: 워크플로의 핵심은 "당신이 흐름을 제어하는 것"이지, "AI가 제어하게 두는 것"이 아닙니다.

실수 2: 노드 간에 구조화된 데이터를 전달하지 않는 것

A 노드가 한 단락의 말을 출력하면, B 노드가 그 말을 다시 이해해야 합니다. 매 단계마다 정보 손실이 발생합니다. JSON을 사용하여 구조화된 데이터를 전달하세요.

실수 3: 실패 처리가 없는 것

AI를 여러 번 호출하다 보면 반드시 실패하는 상황이 발생합니다. 재시도와 폴백을 추가하지 않으면 워크플로는 배포 직후 곧 무너질 것입니다.

실수 4: 노드가 너무 잘게 쪼개진 경우

너무 잘게 쪼개는 것도 좋지 않습니다. 하나의 워크플로 (Workflow)에 노드가 30개나 있다면, 디버깅 (Debugging)이 코드를 짜는 것보다 더 어려워집니다. 원칙: 하나의 노드는 당신이 한 문장으로 설명할 수 있는 하나의 책임 (Responsibility)에 대응해야 합니다.

실수 5: 중간 결과를 기록하지 않는 경우

워크플로가 완료된 후 최종 출력값만 확인하고 중간 노드의 결과들을 버리는 경우가 있습니다. 이렇게 되면 문제가 발생했을 때 추적 (Traceback)할 방법이 없습니다. 각 노드의 입력 (Input)과 출력 (Output)을 모두 로그 (Log)에 남기는 것을 권장합니다.

8. Workflow vs Agent: 개념 재정립

많은 사람들이 이 두 용어를 혼용하지만, 사실 차이가 있습니다.

워크플로 (Workflow): 프로세스는 당신이 미리 설계한 것이며, 노드와 연결 관계가 모두 고정되어 있습니다. AI는 각 노드 안에서 작업만 수행할 뿐, 어떤 경로로 갈지는 결정하지 않습니다.

에이전트 (Agent): 프로세스는 AI가 스스로 결정합니다. 당신이 목표를 주면, AI가 스스로 작업을 분해하고, 도구 (Tool)를 호출하며, 다음 단계에 무엇을 할지 결정합니다.

예시:

• Workflow: 당신이 "번역 → 요약 → 점수 매기기 → 배포"라는 라인을 설계했다면, AI는 각 단계의 콘텐츠 생성만을 담당합니다.
• Agent: 당신이 "이 기사를 처리해서 보내줘"라고 말하면, AI는 먼저 번역하고, 요약하고, 점수를 매긴 뒤 배포할지 스스로 결정합니다. 이 전체 과정은 당신이 생각한 것과 다를 수 있습니다.

실제 프로젝트에서는 두 가지를 자주 혼용합니다. 메인 줄기는 제어 가능성을 보장하기 위해 워크플로를 사용하고, 부분적으로는 불확실한 하위 작업 (Sub-task)을 처리하기 위해 에이전트를 사용합니다.

초보자에게는 워크플로부터 시작할 것을 권장합니다. 에이전트는 멋져 보이지만, 제어하기 어렵고, 디버깅이 불가능하며, 재현 (Reproduce)이 어렵습니다. 워크플로에 익숙해진 후에 특정 노드에 에이전트 능력을 도입하세요.

결론

프롬프트 (Prompt)는 "한 문장으로 AI가 일하게 만드는 것"으로 간단한 작업에 적합합니다. 워크플로는 "AI가 각 작업대에서 일할 수 있도록 파이프라인 (Pipeline)을 설계하는 것"으로 복잡한 작업에 적합합니다.

프롬프트를 아무리 조정해도 결과가 불안정하다면, 잠시 멈추고 스스로에게 물어보세요: 이 작업은 워크플로로 분해해야 하는 것 아닐까?

작업을 분해하여 각 단계를 단순하고 신뢰할 수 있게 만들고, 이를 연결하여 안정적이고 제어 가능하게 만드는 것 — 이것이 바로 워크플로 설계의 정수입니다.