AI 에이전트가 정말 필요한가요?

LLM을 다루든 그렇지 않든, 여러분은 이미 '에이전트(agent)'와 '에이전틱 AI(agentic AI)'라는 말을 수천 번 들었을 것입니다. 프로젝트를 몇 달 동안 구축하고 (취미용이든 상업용이든), 엄청난 양의 콘텐츠를 소비하며, LangGraph나 Google Vertex AI 같은 에이전틱 프레임워크로 매일 작업하면서 몇 가지 생각을 하게 되었습니다.

제목에 대한 간단한 답변은 이렇습니다: 대부분의 경우 그렇지 않습니다. 에이전트로 구축되는 것들 중 대부분은 고정된 워크플로우(fixed workflow)로 구현하는 것이 더 저렴하고, 빠르며, 신뢰하기 쉽습니다. 에이전트는 측정 가능한 결과로 자신의 자리를 증명해야 합니다.

간략한 버전

에이전트는 작업에 적응성이 필요할 때 탁월합니다: 정리되지 않은 입력(messy inputs), 예측할 수 없는 많은 단계, 대규모 자동화가 필요한 경우입니다. 하지만 에이전트도 과도하게 사용되는 경향이 있습니다. 간단하고 예측 가능한 업무의 경우, 워크플로우나 심지어 단일 LLM 호출만으로도 더 효율적이고 신뢰성이 높습니다. 그러니 지루한 솔루션부터 시작하여 측정해보고, 추가적인 복잡성이 확실히 그만한 가치를 제공할 때에만 에이전트를 도입하세요.

왜 모두가 에이전트에 그렇게 열광하는 걸까요?

LLM은 구식 알고리즘으로는 다룰 수 없었던 자동화를 가능하게 했습니다. LLM은 문제에 대해 즉석에서 추론할 수 있기 때문에, 모든 개발자와 모든 회사가 문서 업데이트나 PR 검토 같은 반복적인 작업을 자동화하는 데 이를 원합니다. 코딩조차 이제 반자동화되었고, 이는 OpenAI, Anthropic, Google이 LLM이 사소한 일들을 처리할 것이라고 말해온 것을 뒷받침합니다.

에이전틱 AI는 이 모든 것을 한 단계 더 나아가 전체 프로세스를 자동화하려고 합니다. 소프트웨어 엔지니어로서 저는 그 충동을 느낍니다. 하지만 이러한 과대광고(hype)는 많은 FOMO를 불러왔고, 이제 에이전트가 훨씬 간단한 솔루션으로 처리할 수 있는 문제들에 투입되고 있습니다. 마치 나방 한 마리를 잡기 위해 바주카포를 사용하는 것과 같습니다.

워크플로우 대 에이전트: 차이점은 무엇인가요?

저는 Building effective agents에서 Anthropic이 제시하는 구분을 사용합니다: 워크플로우에서는 코드가 경로를 결정합니다. 반면, 에이전트에서는 모델이 결정합니다.

워크플로우

워크플로우(workflow)는 미리 정의된 순서입니다. LLM은 사용자가 작성한 코드 경로를 따르므로 예측 가능하고 구조적입니다. 모든 단계에는 명확한 목표가 있습니다.

예를 들어, 사용자가 메시지를 보낸다고 가정해 봅시다. 워크플로우는 이 메시지를 '질문(query)', '불만(complaint)', '피드백(feedback)', 또는 '정보(information)'로 분류한 다음, 일치하는 미리 정의된 응답을 보내줄 수 있습니다. 유연성보다 일관성이 더 중요한 경우에 완벽합니다.

ai workflow

에이전트(Agents)

에이전트는 더 자유롭습니다. 정해진 경로를 따르지 않습니다. 정보를 찾고 사용하는 방법을 단계별로 스스로 결정합니다. 이 때문에 비결정적(non-deterministic)입니다. 상황과 자신이 가진 도구에 맞춰 적응하기 때문입니다.

워크플로우가 단순히 메시지를 분류하는 데 그친다면, 에이전트는 여러 데이터 소스를 뒤져보고, 찾은 정보를 조합하여 맞춤형 답변을 작성할 수 있습니다. 복잡한 작업에는 강력하지만, 예측하고 제어하기도 훨씬 어렵습니다.

ai agent

에이전트를 사용해야 할 때?

작은 시간 절약이 쌓일 때입니다. 경비 보고서를 예로 들어보겠습니다. 에이전트는 영수증을 스캔하고, 지출 항목을 분류하며, 보고서를 작성할 수 있습니다. 사람 한 명이 영수증 하나에 몇 분씩 쓰는 시간을 생각해보세요. 이것을 수백 개의 보고서에 곱하면 수동 작업은 거의 사라집니다.

또한 유연성과 미리 스크립트화 할 수 없는 많은 결정이 필요할 때 에이전트가 빛을 발합니다. 다만, 거래의 본질을 알아야 합니다. 더 나은 결과를 얻기 위해 비용(cost)과 지연 시간(latency)으로 지불한다는 것입니다. 그 가치가 있을 때만 이 '거래'를 하세요.

에이전트를 사용하지 말아야 할 때는?

입력(inputs)이 너무 모호해서 출력을 검증할 수 없는 경우를 생각해 보세요. 언어의 뉘앙스와 의도가 인간 전문가가 필요한 자동 법률 계약 검토(automated legal contract review) 같은 상황이나, 주관적 판단 자체가 핵심인 개인 맞춤형 투자 전략 생성 같은 경우입니다. 이런 사례에서는 사소한 오독이 값비싼 실수로 이어질 수 있습니다.

만약 작업에 엄격한 신뢰성이 필요하다면, 예측 가능성과 일관성을 제공하는 워크플로우(workflow)가 더 나은 선택지일 수 있습니다. 그리고 많은 앱의 경우, 검색 증강 생성 (Retrieval-augmented generation)과 몇 가지 인컨텍스트 예시(in-context examples)를 활용한 잘 조정된 LLM 호출만으로도 추가적인 장치 없이 작업을 완료할 수 있습니다.

이 게시물에서 신뢰를 멈춰야 할 부분

저는 이 글을 2025년 3월에 작성했으며, 모델들은 이후로 발전했습니다. 예전에는 세심하게 스크립트된 워크플로우가 필요했던 것들이 이제는 단일하고 유능한 모델 호출만으로 가능해졌고, 에이전트(agent)의 실패율도 이전보다 낮아졌습니다. '워크플로우'와 '에이전트' 사이의 경계는 모든 모델 생성과 함께 변화합니다. 제 예시는 시대적임을 감안하시고 방법론을 참고하시는 것이 좋습니다.

에이전트를 우선시하는 가장 좋은 경우는 워크플로우가 오늘날 사용자가 작업을 이해하는 방식을 인코딩하며, 작업이 바뀔 때마다 재작성하는 데 비용을 지불해야 한다는 점입니다. 코딩이나 연구와 같은 개방형(open-ended) 작업으로, 사전에 단계를 나열할 수 없는 경우 에이전트로 시작하는 것이 정직한 설계 방식입니다. Anthropic의 가이드도 이와 같은 예외를 제시합니다.

저는 여기에 어떤 숫자도 넣지 않았습니다. 비용과 지연 시간(latency) 간의 트레이드오프는 언급만 되었을 뿐 측정되지는 않았습니다. 공정한 버전의 게시물이라면 한 작업을 두 가지 방식으로 실행하여 토큰 수, 초 단위 시간, 오류율을 보고해야 할 것입니다.

핵심 요약

제가 이 글을 작성했을 때의 예측은 다음과 같습니다: 2025년은 우리가 '에이전트적(agentic)' 시스템에서 여러 전문 에이전트가 복잡한 워크플로우를 함께 처리하는 '멀티-에이전트(multi-agent)' 시스템으로 전환되는 해가 될 것이라는 것입니다. 흥미로운 발전입니다. 하지만 각 단계마다 측정하지 않는다면, 복잡성과 비용을 쌓아 올리는 좋은 방법이기도 합니다.

저의 규칙은 이렇습니다. 먼저 작업을 단일 프롬프트로 작성하세요. 그런 다음 고정된 워크플로우(fixed workflow)로 만드세요. 에이전트는 오직 고정 경로가 실패하는 정확한 단계와, 그 에이전트가 더 낫다는 것을 보여주는 평가 결과(eval)를 제시할 수 있을 때만 사용해야 합니다.