AI 에이전트와 워크플로우, 무엇이 다를까: 다섯 가지 기본 패턴
요즘 업무 자동화 이야기가 나오면 'AI 에이전트'라는 말이 빠지지 않습니다. 스스로 계획을 세우고, 도구를 쓰고, 일을 끝까지 해내는 AI라는 설명이 붙곤 하죠. 그런데 막상 업무에 AI를 붙여 보려고 하면 질문이 생깁니다. 내가 만들려는 것이 에이전트일까요, 아니면 정해진 순서대로 돌아가는 자동화일까요? 그리고 정말 에이전트까지 필요할까요? 이 질문에 꽤 분명한 기준을 내놓은 글이 있습니다. 앤트로픽(Anthropic)이 2024년 12월 엔지니어링 블로그에 올린 '효과적인 에이전트 만들기(Building effective agents)'입니다. 글쓴이들은 지난 1년 동안 여러 산업에서 언어 모델 에이전트를 만드는 수십 개 팀과 일해 보니, 가장 잘된 사례들은 복잡한 프레임워크나 특수한 라이브러리를 쓰지 않았다고 말합니다. 대신 단순하고 서로 조합할 수 있는 패턴으로 만들었다는 것이죠. 이 글에서는 그 글이 말하는 워크플로우와 에이전트의 차이, 다섯 가지 기본 패턴, 그리고 '에이전트가 필요 없을 때'를 하나씩 살펴보겠습니다.
워크플로우와 에이전트는 무엇이 다를까요?
'에이전트'라는 말은 쓰는 사람마다 뜻이 조금씩 다릅니다. 어떤 곳은 오랜 시간 혼자서 여러 도구를 써 가며 복잡한 일을 해내는 완전 자율 시스템을 에이전트라고 부르고, 어떤 곳은 미리 정해 둔 절차를 따라가는 비교적 단순한 구현도 에이전트라고 부릅니다. 원문은 이 둘을 모두 묶어 '에이전틱 시스템(agentic systems)'이라고 부르되, 그 안에서 구조적으로 중요한 선을 하나 긋습니다.
워크플로우는 언어 모델과 도구가 미리 정해진 코드 경로에 따라 움직이는 시스템입니다. 어떤 단계를 어떤 순서로 밟을지는 사람이 먼저 설계해 두고, AI는 각 단계에서 맡은 일을 처리합니다. 반면 에이전트는 언어 모델이 자기 작업 과정과 도구 사용을 스스로 그때그때 정하는 시스템입니다. 일을 어떻게 끝낼지에 대한 주도권을 AI가 쥐고 있는 것이죠.
비유하자면 워크플로우는 순서가 정해진 조리법에 가깝고, 에이전트는 냉장고를 열어 보고 그날 무엇을 만들지 정하는 요리사에 가깝습니다. 조리법은 누가 따라 해도 결과가 비슷하게 나오지만 정해진 요리밖에 못 만듭니다. 요리사는 상황에 맞게 대처할 수 있지만 그만큼 결과를 미리 알기 어렵습니다. 그래서 둘 중 무엇이 더 낫다기보다는, 어떤 일에 어떤 쪽이 맞는지를 따져 봐야 합니다. 흔히 AI로 하는 자동화를 통틀어 에이전트라고 부르기도 하지만, 이 구분을 알아 두면 내가 무엇을 만들고 있는지가 훨씬 또렷해집니다.
가장 먼저 물어야 할 질문: 정말 필요한가요?
원문이 가장 먼저 강조하는 것은 패턴이 아니라 태도입니다. 언어 모델로 무언가를 만들 때는 가능한 한 가장 단순한 해법을 찾고, 정말 필요할 때만 복잡도를 높이라는 것이죠. 이 말에는 에이전틱 시스템을 아예 만들지 않는 선택도 포함됩니다.
이유는 비용에 있습니다. 에이전틱 시스템은 대개 더 나은 결과를 얻는 대가로 시간과 돈을 더 씁니다. 여러 번 모델을 부르고, 중간 결과를 다시 넘기고, 확인하는 과정이 붙기 때문입니다. 원문은 이 맞바꿈이 말이 되는 경우인지 먼저 따져 보라고 말합니다. 그리고 많은 경우에는 모델을 한 번 부르되, 필요한 자료를 찾아 붙여 주고 좋은 예시를 함께 넣어 주는 것만으로도 충분하다고 덧붙입니다.
복잡도가 정말 필요하다면 그다음 선택지가 나뉩니다. 할 일이 분명하게 정해진 작업이라면 예측 가능하고 일관된 워크플로우가 낫고, 유연함과 모델 스스로의 판단이 대규모로 필요한 작업이라면 에이전트가 낫습니다. 즉 '단순한 한 번의 호출 → 워크플로우 → 에이전트'의 순서로, 앞 단계로 안 될 때만 한 칸씩 올라가라는 것이 이 글의 뼈대입니다.
프레임워크에 대해서도 같은 이야기를 합니다. 에이전틱 시스템을 쉽게 만들어 주는 도구는 많지만, 그런 도구는 추상화 층을 하나 더 얹기 때문에 실제로 모델에 무엇이 들어가고 무엇이 나오는지를 가려 버리기 쉽습니다. 그러면 문제가 생겼을 때 원인을 찾기가 어려워지고, 더 단순하게 해도 될 일에 괜히 복잡함을 더하고 싶어지기도 합니다. 그래서 원문은 처음에는 모델을 직접 부르는 것부터 시작해 보라고 권합니다. 많은 패턴이 코드 몇 줄이면 구현된다는 것이죠. 프레임워크를 쓰더라도 그 밑에서 무슨 일이 일어나는지는 이해하고 써야 한다고 강조합니다. 내부 동작을 잘못 짐작하는 것이 흔한 실수의 원인이기 때문입니다. 다만 원문 첫머리에도 적혀 있듯, 글에 나온 도구 환경은 2024년 12월 이후 많이 바뀌었습니다. 그래서 이 글에서는 특정 도구 이름보다 패턴과 원칙에 집중하겠습니다.
기본 재료: 검색·도구·기억을 갖춘 언어 모델
모든 패턴의 출발점은 '강화된 언어 모델(augmented LLM)'입니다. 언어 모델에 검색, 도구, 기억 같은 능력을 덧붙인 것을 말합니다. 요즘 모델은 이런 능력을 수동적으로 받기만 하는 것이 아니라, 스스로 검색어를 만들고, 알맞은 도구를 고르고, 무엇을 기억해 둘지 정할 수 있습니다.
원문은 이 재료를 만들 때 두 가지를 챙기라고 합니다. 하나는 이 능력들을 내 업무에 맞게 다듬는 것이고, 다른 하나는 모델이 쓰기 쉽고 설명이 잘 되어 있는 연결 방식을 마련해 주는 것입니다. 아래에 나오는 다섯 가지 워크플로우는 모두 이 강화된 언어 모델을 여러 개 이어 붙이거나, 나누거나, 반복시키는 방식이라고 보시면 됩니다.
(1) 프롬프트 체이닝: 한 단계씩 넘겨주기
프롬프트 체이닝(prompt chaining)은 일을 여러 단계로 쪼개고, 앞 단계의 결과를 다음 단계가 받아서 처리하는 방식입니다. 공장의 조립 라인처럼 한 사람이 한 가지씩 맡는 셈이죠. 중간에 '관문(gate)'을 두어 프로그램이 결과를 점검하게 할 수도 있습니다. 기준에 맞지 않으면 다음 단계로 넘어가지 못하게 막는 것입니다.
이 방식은 일을 고정된 하위 작업으로 깔끔하게 나눌 수 있을 때 잘 맞습니다. 단계가 늘어나니 시간은 더 걸리지만, 각 단계가 쉬워지는 만큼 정확도가 올라갑니다. 원문이 드는 예는 마케팅 문구를 먼저 쓰고 그것을 다른 언어로 번역하는 일, 그리고 문서의 개요를 먼저 쓰고, 그 개요가 기준에 맞는지 확인한 뒤, 개요를 바탕으로 본문을 쓰는 일입니다.
(2) 라우팅: 들어온 일을 알맞은 곳으로 보내기
라우팅(routing)은 들어온 입력을 먼저 분류한 뒤, 그 종류에 맞는 후속 작업으로 보내는 방식입니다. 병원 접수처가 증상을 듣고 알맞은 진료과로 안내하는 것과 비슷합니다. 이렇게 하면 종류마다 전용 지시문을 따로 만들 수 있습니다. 반대로 라우팅 없이 하나의 지시문으로 모든 입력을 처리하려 하면, 한 종류에 맞춰 다듬을수록 다른 종류의 성능이 떨어질 수 있습니다.
라우팅은 따로 다루는 편이 나은 뚜렷한 범주가 있고, 그 분류를 정확하게 할 수 있을 때 잘 맞습니다. 분류는 언어 모델이 해도 되고, 전통적인 분류 모델이나 알고리즘이 해도 됩니다. 원문은 고객 문의를 일반 질문, 환불 요청, 기술 지원으로 나눠 각각 다른 처리 과정과 도구로 보내는 예를 듭니다. 또 쉽고 흔한 질문은 작고 저렴한 모델로, 어렵고 드문 질문은 더 강한 모델로 보내 비용과 성능을 함께 챙기는 방법도 소개합니다.
(3) 병렬화: 나눠서 동시에, 또는 여러 번 묻기
병렬화(parallelization)는 여러 모델 호출이 동시에 일하고, 그 결과를 프로그램이 모아 정리하는 방식입니다. 원문은 이를 두 갈래로 나눕니다. 하나는 '나누기(sectioning)'로, 서로 독립적인 하위 작업으로 쪼개 동시에 돌리는 것입니다. 다른 하나는 '투표(voting)'로, 같은 일을 여러 번 시켜 다양한 답을 얻는 것입니다.
나누기의 예로 원문은 안전장치를 듭니다. 한 모델이 사용자 질문에 답하는 동안, 다른 모델은 그 질문에 부적절한 내용이 있는지 따로 걸러내는 식입니다. 한 번의 호출에 답변과 검열을 동시에 맡기는 것보다 이렇게 나누는 편이 대체로 더 잘 된다고 합니다. 모델 성능을 평가할 때 각 호출이 서로 다른 측면을 하나씩 맡아 채점하는 것도 같은 원리입니다. 투표의 예로는 코드에 보안 취약점이 있는지 여러 지시문이 각각 검토해 문제를 짚게 하는 것, 어떤 콘텐츠가 부적절한지 여러 번 판단하게 하고 몇 표 이상이면 걸러낼지 기준을 달리 정하는 것이 있습니다. 원문의 설명대로, 고려할 점이 많은 복잡한 일은 한 번에 다 맡기기보다 고려할 점 하나에 호출 하나씩 붙여 주는 편이 각 부분에 집중하게 만들어 결과가 좋아지는 경향이 있습니다.
(4) 오케스트레이터-워커: 팀장이 일을 나눠 맡기기
오케스트레이터-워커(orchestrator-workers)는 가운데에 있는 언어 모델 하나가 일을 그때그때 쪼개서 여러 작업자 모델에게 맡기고, 돌아온 결과를 모아 종합하는 방식입니다. 팀장이 프로젝트를 받아 보고 누구에게 무엇을 맡길지 정하는 모습과 비슷합니다.
겉모습은 병렬화와 닮았지만 결정적인 차이가 있습니다. 병렬화는 어떤 하위 작업으로 나눌지 사람이 미리 정해 둡니다. 오케스트레이터-워커는 들어온 일을 보고 팀장 역할의 모델이 직접 정합니다. 그래서 필요한 하위 작업을 미리 예측할 수 없는 복잡한 일에 잘 맞습니다. 원문은 코딩을 예로 듭니다. 고쳐야 할 파일이 몇 개인지, 파일마다 무엇을 고쳐야 하는지는 일을 받아 봐야 알 수 있기 때문이죠. 여러 출처에서 관련 정보를 모으고 분석해야 하는 검색 작업도 여기에 해당합니다.
(5) 평가자-최적화: 쓰고, 고치고, 다시 쓰기
평가자-최적화(evaluator-optimizer)는 한 모델이 답을 만들고, 다른 모델이 그 답을 평가해 의견을 주는 과정을 반복하는 방식입니다. 글쓴이가 초고를 쓰고 편집자의 의견을 받아 고쳐 쓰는 과정과 같습니다.
원문은 이 방식이 잘 맞는 신호를 두 가지로 정리합니다. 첫째, 사람이 구체적으로 의견을 말해 주면 모델의 답이 눈에 띄게 나아지는 일이어야 합니다. 둘째, 그런 의견을 모델 스스로도 줄 수 있어야 합니다. 평가 기준이 분명하고, 다시 고칠수록 나아지는 정도를 확인할 수 있을 때 효과가 큽니다. 예로는 번역 모델이 처음에 놓친 미묘한 뉘앙스를 평가 모델이 짚어 주는 문학 번역, 그리고 여러 차례 검색과 분석을 반복하며 평가 모델이 검색을 더 할지 말지 정하는 복잡한 검색 작업이 있습니다.
에이전트는 언제 쓰나요?
다섯 가지 워크플로우를 지나면 비로소 에이전트가 나옵니다. 에이전트는 사람의 지시나 대화로 일을 시작합니다. 해야 할 일이 분명해지면 스스로 계획을 세우고 움직이며, 필요하면 사람에게 돌아와 추가 정보나 판단을 구합니다. 중요한 점은 매 단계마다 실제 환경에서 '정답에 해당하는 사실'을 확인한다는 것입니다. 도구를 써서 나온 결과나 코드를 실행한 결과 같은 것을 보고, 지금 제대로 가고 있는지를 판단하는 것이죠. 확인 지점에서 멈춰 사람의 의견을 듣거나, 막히는 곳에서 멈출 수도 있습니다. 일이 끝나면 멈추지만, 통제를 위해 '최대 몇 번까지만 반복' 같은 중단 조건을 함께 두는 경우도 흔합니다.
이렇게 들으면 대단히 복잡해 보이지만, 원문은 구현 자체는 대개 단순하다고 말합니다. 결국 환경에서 돌아온 결과를 보며 도구를 쓰는 일을 반복하는 언어 모델이라는 것이죠. 그래서 오히려 도구 묶음과 그 설명서를 얼마나 명확하고 세심하게 만들었는지가 성패를 가릅니다.
에이전트가 맞는 일은 몇 단계가 필요할지 미리 알기 어렵거나 불가능하고, 정해진 경로를 코드로 박아 둘 수 없는 열린 문제입니다. 모델이 여러 차례 스스로 판단하며 움직이니, 그 판단을 어느 정도 믿을 수 있어야 합니다. 그 대가도 분명합니다. 자율적인 만큼 비용이 더 들고, 한 번의 실수가 다음 단계로 이어지며 쌓일 수 있습니다. 원문이 격리된 시험 환경에서 충분히 테스트하고, 알맞은 안전장치를 함께 두라고 권하는 이유입니다.
원문은 에이전트가 특히 가치를 보인 두 분야로 고객 지원과 코딩을 꼽습니다. 고객 지원은 대화 흐름을 따라가면서 고객 정보나 주문 내역을 찾아보고, 환불 처리나 문의 기록 갱신 같은 행동까지 해야 하며, 문제가 해결됐는지로 성과를 분명히 잴 수 있습니다. 코딩은 자동화된 테스트로 결과를 검증할 수 있고, 테스트 결과를 보고 다시 고칠 수 있으며, 문제 범위가 잘 정해져 있습니다. 두 분야의 공통점은 대화와 행동이 함께 필요하고, 성공 기준이 분명하며, 결과를 보고 다시 고치는 고리가 있고, 사람이 의미 있게 감독할 수 있다는 것입니다. 다만 원문은 코딩에서도 자동 테스트가 기능을 확인해 줄 뿐, 해법이 전체 시스템의 요구에 맞는지는 여전히 사람이 검토해야 한다고 덧붙입니다.
도구 설명서도 지시문만큼 공들여야 합니다
에이전트가 도구를 잘 쓰려면 도구 자체가 쓰기 쉬워야 합니다. 원문은 사람이 쓰는 화면을 설계할 때 공을 들이는 만큼, AI가 쓰는 도구의 연결 방식(agent-computer interface, ACI)에도 똑같이 공을 들이라고 말합니다. 모델 입장이 되어 도구 설명과 입력 항목만 보고 쓰는 법이 바로 보이는지 확인하고, 팀에 새로 들어온 동료에게 건넬 설명서를 쓰듯 이름과 설명을 다듬고, 여러 예시 입력으로 모델이 어떤 실수를 하는지 직접 돌려 보며 고치라는 것이죠. 아예 실수하기 어렵게 입력 방식을 바꾸는 것도 방법입니다.
원문에는 이를 보여 주는 일화가 하나 있습니다. 코딩 에이전트를 만들 때 실제로는 전체 지시문보다 도구를 다듬는 데 더 많은 시간을 썼다고 합니다. 에이전트가 처음 위치에서 다른 폴더로 옮겨 간 뒤에 상대 경로로 파일을 가리키는 도구를 쓰면 실수가 났는데, 도구가 항상 절대 경로를 받도록 바꾸자 모델이 이 방식을 실수 없이 썼다는 것입니다. 모델을 더 똑똑하게 만든 것이 아니라 도구를 실수하기 어렵게 바꾼 것이 문제를 풀었다는 점이 눈여겨볼 만합니다.
맺음말: 가장 정교한 시스템이 아니라 알맞은 시스템
원문은 이 패턴들이 반드시 따라야 하는 규칙이 아니라, 상황에 맞게 다듬고 조합할 수 있는 흔한 모양새라고 말합니다. 성공의 열쇠는 성능을 재고, 결과를 보며 고쳐 나가는 데 있습니다. 그리고 한 번 더 강조합니다. 복잡함은 그것이 결과를 확실히 낫게 만들 때만 더하라고요.
정리하면, 언어 모델 분야에서의 성공은 가장 정교한 시스템을 만드는 데 있지 않고 내 필요에 맞는 시스템을 만드는 데 있습니다. 단순한 지시문으로 시작하고, 꼼꼼한 평가로 다듬고, 더 단순한 해법으로 부족할 때만 여러 단계의 에이전틱 시스템을 더하라는 것이죠. 에이전트를 만들 때는 세 가지 원칙을 지키라고 권합니다.
- 에이전트의 설계를 단순하게 유지할 것
- 에이전트가 세운 계획 단계를 겉으로 드러내 투명하게 보여 줄 것
- 도구 설명서와 테스트를 통해 AI가 쓰는 도구의 연결 방식을 세심하게 만들 것
AI로 업무를 자동화하고 싶을 때, 처음부터 '에이전트를 만들자'고 출발하면 필요 이상으로 복잡하고 비싸며 고치기 어려운 시스템이 되기 쉽습니다. 그보다는 먼저 이렇게 물어보는 편이 좋겠습니다. 이 일은 한 번의 질문으로 끝나는가? 단계가 늘 같은가? 종류별로 나눠야 하는가? 동시에 여러 갈래로 돌릴 수 있는가? 몇 단계가 필요할지 미리 알 수 없는가? 이 질문들에 차례로 답하다 보면, 내 일에 필요한 것이 한 번의 호출인지, 다섯 가지 워크플로우 중 하나인지, 아니면 정말 에이전트인지가 자연스럽게 드러날 것입니다.