Agent와 Workflow, 뭐가 다른가 — 결정권이 어디 있는가
← 전체 목차 · 다음: Agent란 무엇인가
"Workflow는 고정적이고 Agent는 똑똑하다"는 정답처럼 들리지만 사실 아무것도 설명하지 못하는 문장이다. 둘 다 대형모델을 호출하고, 둘 다 도구를 부를 수 있다. 진짜 분기점은 지능의 총량이 아니라 다음 스텝을 누가 정하는가에 있다.
결정이 코드에 있는가, 모델에 있는가
| Workflow | Agent |
|---|
| 분기 로직의 출처 | 개발자가 미리 써놓은 조건문 | 모델이 그때그때 판단 |
| 모델의 역할 | 정해진 자리에서 호출되는 실행 도구 | 다음 행동을 고르는 결정 중추 |
| 새 시나리오 대응 | 코드를 고쳐야 대응 가능 | 코드 변경 없이 그대로 대응 시도 |
| 판단 소재 | 모든 로직이 인간의 머릿속에서 나와 코드로 굳음 | 모델이 상황을 보고 그 자리에서 추론 |
핵심 함정: 모델을 호출한다고 해서 Agent가 되는 것이 아니다. 호출 순서와 호출 조건을 사람이 하드코딩해놓고 모델은 그 자리를 채우기만 한다면, 겉보기엔 지능적이어도 본질은 Workflow다. 반대로 판단·트리거·다음 행동 선택을 모델에게 넘기는 순간부터가 Agent다.
네 가지 실무 차이
| 차원 | Workflow | Agent |
|---|
| 이상 대응 | 예상 밖 입력·데이터 누락 시 그 자리에서 멈추고 에러 반환 | 재시도·파라미터 보정·경로 변경으로 스스로 복구 시도 |
| 비용·속도 | 다회 추론 불필요 → 빠르고 저렴하고 환각 없음 | 매 스텝 추론 필요 → 느리고 비싸고 환각 리스크 존재 |
| 변경 대응 | 요구사항 바뀌면 코드 수정 → 재배포 → 재테스트 | 요구사항 바뀌면 프롬프트·예시 조정만으로 대응 가능한 경우가 많음 |
| 감사 가능성 | 경로가 유일해서 문제 발생 즉시 위치 특정 | 매번 경로가 달라질 수 있어 재현·추적 비용이 별도로 필요 |
이 네 줄은 사실 하나의 원인에서 파생된다. 결정권을 코드가 쥐면 예측 가능성이 올라가고, 모델이 쥐면 적응력이 올라간다. 둘 다 가질 수 없고, 어느 쪽으로 기울일지는 업무가 정한다.
선택 기준: 스텝을 미리 못 박을 수 있는가
업무의 절차가 고정 · 입력 형태가 안정 · 예외가 드묾
→ Workflow로 충분하다. Agent를 쓰면 과설계다.
요구가 모호 · 분기 경우의 수가 사전에 다 안 그려짐 · 처리 중 판단이 필요
→ 이 지점부터 Agent의 자율 판단이 비용을 상쇄한다.
전형적인 오판 두 가지는 대칭적으로 일어난다.
- 표준화된 업무(정형 폼 승인, 정기 배치, 고정 리포트)에 Agent를 얹으면 — 응답이 느려지고 비용이 튀고 안정성도 오히려 떨어진다. 똑똑함이 필요 없는 곳에 산 지능 비용을 지불하는 것.
- 절차가 자주 바뀌고 예외가 일상인 업무(이상 진단, 다중 시스템 협업, 자유도 높은 상담)를 Workflow로 하드코딩하면 — 분기 조건이 기하급수로 늘어나며 한 곳을 고치면 전체가 흔들리는 **"노드 폭발"**이 온다.
프로덕션 정답은 이분법이 아니라 혼합 구조다
고정 구간 (표준화·저변동) 동적 구간 (비표준·고변동)
폼 승인 요구 이해
데이터 동기화 ──▶ 이상 판단 ──▶ 업무 결과
정기 리포트 도구 선택
배치 작업 결과 검증
Workflow가 담당 Agent가 담당
분업 원칙은 간단하다. 핵심 표준 스텝은 Workflow로 안정성과 비용을 지키고, 판단이 필요한 스텝만 Agent에게 넘긴다. 실제 상용 시스템 대부분이 이 형태이며, "전부 Agent" 또는 "전부 Workflow"는 둘 다 아키텍처 미성숙의 신호다.
핵심 통찰
- "똑똑함"은 판별 기준이 아니다 — Workflow도 매 스텝 대형모델을 부를 수 있고 Agent처럼 보이게 꾸밀 수 있다. 유일하게 새는 곳 없는 기준은 "다음 행동을 누가 골랐는가"이며, 이건 로그를 열어 분기 조건이 코드에 있는지 모델 출력에 있는지 보면 바로 드러난다.
- 분기점은 정상 경로가 아니라 이상 경로에서 드러난다 — 정상 흐름에서는 둘 다 순서대로 도구를 부르는 것처럼 보여 구분이 안 된다. 파라미터가 이상하거나 데이터가 없을 때 하나는 멈추고 하나는 스스로 고치려 든다. 시스템의 지능 수준을 재려면 happy path가 아니라 예외 분기를 테스트해야 한다.
- 자율성은 공짜가 아니라 토큰과 불확실성으로 산 것이다 — Workflow의 "저비용·고안정·무환각"과 Agent의 "고비용·환각 리스크·응답 지연"은 같은 동전의 양면이다. 적응력이 필요 없는 업무에 이 비용을 치르는 것은 설계 실패다.
- 선택 변수는 "업무의 중요도"가 아니라 "요구의 확정성"이다 — 핵심 업무라도 절차가 고정돼 있으면 Workflow가 맞고, 지엽적 업무라도 매번 판단이 달라지면 Agent가 필요할 수 있다. 중요도로 아키텍처를 고르는 것은 흔한 오판이다.
- 반복 비용이 아키텍처의 수명을 정한다 — 같은 요구 변경이 Workflow에서는 "코드 수정 → 재배포 → 재테스트"를, Agent에서는 "프롬프트·예시 조정"을 요구한다. 요구가 자주 바뀌는 영역일수록 이 격차가 초기 개발 비용보다 빠르게 승부를 가른다.
- 과설계와 설계 부족은 대칭적인 실패다 — 고정 업무에 Agent를 얹는 것과 가변 업무를 Workflow로 하드코딩하는 것은 서로 반대 방향의 같은 오류이며, 하나는 "비용 폭발"로, 다른 하나는 "노드 폭발"로 터진다.
- 혼합 구조는 타협이 아니라 책임 분리다 — "전부 Agent"나 "전부 Workflow"는 둘 다 극단이다. 고정 구간과 판단 구간의 경계선을 어디에 긋는가가 아키텍처 설계자의 실제 작업이며, 이 경계선이 명시적이지 않은 시스템은 결국 모델과 하드코딩 로직이 서로 침식한다.
엔지니어링 실전 Tips
- 판정은 로그로 할 것. "이 시스템은 Agent인가"라는 질문에는 코드를 읽지 말고 실행 로그에서 분기 조건이 어디서 나왔는지(코드 상수 vs 모델 출력)를 확인하는 것이 가장 빠르다.
- 이상 주입 테스트를 설계 검증 수단으로 쓸 것. 파라미터 누락·데이터 없음·시나리오 변경을 의도적으로 주입해, 시스템이 멈추는지 스스로 복구를 시도하는지로 실제 지능 수준을 가른다.
- 요구 변경 시 "코드를 고쳤는가 프롬프트를 고쳤는가"를 추적할 것. 이 비율이 아키텍처가 업무의 변화율과 맞는지 보여주는 선행 지표다.
- 혼합 구조를 설계할 때 경계선을 문서로 명시할 것. 어떤 스텝이 Workflow 구간이고 어떤 스텝이 Agent 구간인지, 그리고 Agent 구간이 실패했을 때 Workflow 구간으로 어떻게 되돌아오는지를 그림 한 장으로 남겨야 한다.
- 표준화 업무에 Agent를 붙이기 전에 "판단이 실제로 필요한가"를 먼저 검증할 것. 판단 포인트가 없다면 다단계 추론·반성 루프를 켜봐야 비용만 늘고 안정성은 떨어진다.
- 가변 업무를 Workflow로 시작했다면 분기 수를 지표로 관리할 것. 조건 분기가 계속 늘고 서로 얽히기 시작하면, 그 지점이 바로 판단 로직을 모델에게 넘겨야 할 신호다.