모든 AI 작업에 에이전트가 필요하지는 않다. Static LLM과 Agent 사이의 선택 기준을 비용·속도·신뢰성 세 축으로 명확히 구분한다.
이하는 실제 운영 환경에서 반복적으로 관찰되는 패턴을 바탕으로 구성한 가상 시나리오다.
한 보험사의 고객 문의 처리 팀이 있었다. 6개월 동안 Agent를 구축했다. 고객이 접수한 문의를 읽고, 사내 DB에서 정책을 검색하고, 상황에 맞는 답변을 초안으로 만들어 상담사에게 전달하는 구조였다. PoC에서는 인상적이었다. 그런데 실제 운영에 올리자 두 가지 문제가 동시에 터졌다. 응답 시간이 10초를 넘어서 콜센터 상담사들이 결과를 기다리다가 직접 답변했다. 비용은 예상의 8배였다.
이 팀이 나중에 파악한 원인은 기술적 실수가 아니었다. 아키텍처 선택의 문제였다. 처리하던 업무 중 85%는 "고객 문의 → DB 검색(RAG) → 답변 초안"의 흐름이 미리 정해져 있었다. Agent가 필요 없는 업무였다.
Anthropic은 "Building Effective Agents" 공식 문서에서 이 문제를 정면으로 지적한다. "agentic systems often trade latency and cost for better task performance. Your task may not need that trade-off." 단순히 복잡해 보인다고 해서 Agent가 필요한 것은 아니라는 것이다.[1]
Agent가 필요 없는 업무에 Agent를 붙이면 비용, 속도, 신뢰성에서 동시에 손해를 본다.
손실 1: 비용
단일 LLM 호출 한 건의 비용은 $0.001~$0.02 선이다. 반면 Agent 워크플로우 한 건은 $0.10~$5.00 — 웹 검색 2~3회 수준의 평균적인 B2B 태스크는 $0.10~$0.50이지만, 코딩 디버깅 Agent처럼 tool call과 reflection loop가 누적되는 태스크는 최대 $5~8에 달한다.[2][7] 시장 조사 자동화 태스크에서 orchestrated LLM 워크플로우 대비 완전 자율 Agent의 토큰 소비는 12배 더 많았다 (3×185회 실험 기준).[3] 월 10만 건 처리 시, 아키텍처 선택 하나가 비용을 수십 배로 만들 수 있다.
손실 2: 속도
단일 LLM 호출은 0.8~2초다 (스트리밍 시작 기준). Agent가 Orchestrator-Worker 구조로 tool call을 반복하면 10~30초가 된다.[2] 콜센터·실시간 고객 응대처럼 응답 시간 SLA가 3초 이하인 업무에서 이 차이는 서비스 불가 수준이다. 배치 처리나 백오피스 업무처럼 수십 초를 허용하는 환경은 다른 판단이 필요하다.
손실 3: 신뢰성
Agent의 신뢰성 문제는 단순한 확률 계산이 아니다. 핵심은 비결정론(Non-determinism)에 있다. 동일한 입력이 들어와도 Agent는 매번 다른 경로로 실행된다. 어떤 도구를 몇 번 쓸지, 어떤 순서로 처리할지 실행 전에 알 수 없다. 이로 인해 품질 보증(QA)이 극도로 어렵다. Static LLM 파이프라인은 골든 데이터셋으로 회귀 테스트가 가능하지만, Agent는 매번 경로가 달라져 같은 테스트를 반복해도 결과가 달라진다.
여기에 운영 장애가 더해진다. Agent가 외부 도구 호출에 실패했을 때, 같은 도구를 의미 없이 반복 호출하며 토큰을 소모하는 현상(Token Exhaustion)이 발생한다. 예를 들어 검색어를 미세하게 바꿔가며 DB 조회를 10번 연속 시도하다가 token budget을 초과하는 상황이 실제 운영에서 가장 흔히 보이는 Agent 장애 유형이다. 단일 LLM 호출의 실패 포인트는 API 하나뿐이지만, Agent는 tool call, 네트워크, planning 오류, 무한 루프까지 실패 지점이 분산된다.
그리고 이 모든 비용에도 불구하고, 동일한 업무에서 Agent가 LLM 파이프라인보다 정확도가 낮은 경우도 존재한다. ChangeMyView 설득형 답변 생성 태스크에서 one-shot GPT-4o-mini는 75% 정확도를 6초 만에 달성했다. 여기에 Agent 구조(계획 + 검색 도구)를 추가했더니 정확도는 거의 개선되지 않고 레이턴시만 수십 초로 급증했다.[4]
"복잡하다"는 기준 대신, 두 회사가 공식 문서에서 제시한 기준은 명확하다. 실행 중 판단 분기를 미리 코드로 정의할 수 있는가 없는가.
Anthropic은 이를 이렇게 정의한다: "Agents can be used for open-ended problems where it's difficult or impossible to predict the required number of steps, and where you can't hardcode a fixed path."[1] 반대로, 실행 흐름을 미리 정할 수 있다면 LLM 파이프라인이 더 적합하다.
OpenAI 공식 가이드는 Agent를 정당화하는 세 가지 조건을 명시한다: ① 규칙으로 포착하기 어려운 복잡한 판단(nuanced judgment), ② 관리 불가능해진 규칙 집합(unwieldy rulesets), ③ 비정형 데이터에 대한 깊은 이해가 필요한 경우.[5] 반대로, 이 세 가지 중 해당하는 것이 없다면 "a deterministic solution may suffice"라고 명시했다.
단계 수 예측 가능성
실행 중 판단 분기
외부 Tool 호출
규칙 집합 상태
응답 시간 SLA
대표 업무
실무 체크리스트 — 모두 해당하면 LLM 파이프라인으로 시작하라:
하나라도 해당하면 Agent 검토가 필요하다:
경계 케이스: 두 방식 사이에 중간 지점이 있다
예외 케이스가 일부 있지만 Agent를 쓰기에는 비용이 부담스럽다면, Routing LLM이 현실적인 선택이다. 들어오는 요청을 유형별로 분류하여(예: 단순 조회 / 정책 확인 / 예외 처리) 각각 최적화된 Static LLM 파이프라인으로 보내는 구조다. 불확실도가 높은 요청만 Agent로 라우팅하고, 나머지 80~90%는 정적 파이프라인이 처리한다. Agent의 유연성 없이도 다양한 입력을 처리할 수 있고, 비용과 속도 모두 통제 범위 안에 둘 수 있다.
Agent가 적합한 업무가 있는 것은 사실이다. 그러나 그 선택에는 측정 가능한 대가가 따른다.
정확도를 얻으면 속도와 비용을 잃는다. Event-QA 벤치마크에서 Agent 구조는 정확도를 47.5%→67.5%로 끌어올렸다. 대신 응답 시간은 8초→317초, 40배 느려졌다.[4] 소프트웨어 엔지니어링 디버깅 Agent는 tool call과 reflection loop가 누적되면서 태스크당 $5~8의 비용이 발생했다. 10-cycle reflection loop를 허용하면 단일 패스 대비 토큰 소비가 50배로 늘어난다.[7]
테스트와 품질 관리가 어려워진다. Static LLM 파이프라인은 골든 데이터셋으로 회귀 테스트가 가능하다. Agent는 실행 경로가 매번 달라진다. 동일한 입력에도 다른 도구를 다른 순서로 부를 수 있고, 그 결과를 사전에 정의된 기준으로 검증하기 어렵다. 운영 안정성을 담보하기 위한 QA 비용이 별도로 필요하다.
Agent는 "더 강력한 것"이 아니라 "다른 트레이드오프를 갖는 것"이다. 그 트레이드오프가 업무에 맞는지 확인하지 않은 채 도입하면, 앞서 말한 보험사 팀처럼 6개월을 되돌아오는 데 쓰게 된다.
Static LLM과 Agent의 경계는 이론상 명확하지만, 실제 엔터프라이즈 환경에서는 업무 특성, 기존 인프라, SLA 요구사항이 복합적으로 얽혀 판단이 어렵다. "복잡해 보이니까 Agent"라는 직관은 비용·속도·신뢰성 문제로 돌아온다. 아키텍처 선택은 운영 단계에서 되돌리기 어렵다.
우리 업무 구조에 맞는 아키텍처를 함께 검토하고 싶다면 →
