DEVOCEAN

에이전트에게 일을 맡길 때, 스스로 알아서 하게 둘 것인가 아니면 정해진 순서대로 하나씩 시킬 것인가.

이 선택이 시스템 전체의 성격을 바꿉니다. 어느 한쪽이 더 나은 것이 아니라, 각자 비싸지는 지점이 다를 뿐입니다.

1. 에이전트는 어떻게 일하나

모든 이야기의 출발점이 되는 기본 동작 구조입니다.

에이전트에게 일을 맡기는 방식은 크게 둘로 나뉩니다.

이 글에서는 A. 자율 방식과 B. 워크플로우 방식이라고 부르겠습니다. 다만 두 방식은 같은 뼈대 위에 서 있어서, 비교에 앞서 그 공통 뼈대부터 보는 편이 빠릅니다.

AI 에이전트는 질문 하나에 답 하나를 내놓는 챗봇과 다릅니다.

요청을 받으면 "다음에 뭘 할지" 판단하고 → 필요하면 도구를 쓰고 → 그 결과를 보고 다시 판단하는 과정을 여러 번 반복합니다.

그림 1. 에이전트의 기본 루프 — 핵심은 한 번의 요청 안에서 이 사이클이 여러 바퀴 돈다는 점

💡 여기서 꼭 기억할 것

가운데 "판단" 상자가 이 구조의 심장입니다. 도구를 쓸지 말지, 어떤 도구를 쓸지, 이제 끝낼지를 매 바퀴마다 여기서 결정합니다.

앞으로 살펴볼 두 방식의 차이는 결국 "이 판단을 누가, 어디까지 하느냐"의 차이입니다.

2. 계획은 이 그림 어디에 있을까

복잡한 일은 계획부터 세우게 되는데, 계획은 별도의 단계가 아닙니다.

사람도 복잡한 일을 받으면 먼저 순서를 정합니다.

에이전트도 마찬가지인데, 이 계획 세우기는 "판단" 안에서 일어나는 하나의 생각일 뿐 별도의 박스가 아닙니다.

그리고 한 번 세운 계획은 도구 결과를 볼 때마다 계속 수정됩니다.

그림 2. 계획은 첫 바퀴의 산출물일 뿐, 이후 바퀴마다 참조되고 수정됩니다

⚠️ 흔한 오해

"계획의 항목 1개 = 루프 1바퀴"가 아닙니다.

항목 하나를 처리하는 데 다섯 바퀴가 걸릴 수도 있고, 한 바퀴에 항목 세 개를 한꺼번에 끝낼 수도 있습니다.

도중에 항목을 건너뛰거나 새로 추가하기도 합니다.

계획은 지도일 뿐, 실제 걸음 수를 정해주지는 않습니다.

3. 두 가지 방식

앞에서 본 것이 사실 A방식입니다. 이제 B방식을 나란히 놓습니다.

1·2장에서 본 모습 — 에이전트가 스스로 계획을 세우고 끝까지 루프를 돌리는 모습 — 이 곧 A. 자율 방식입니다.

여기에 B. 워크플로우 방식을 대비시켜 보겠습니다. 두 방식의 부품은 똑같습니다.

다른 것은 이 루프를 누가 돌리느냐 하나뿐입니다.

💡 용어 노트 — 업계에서는 이렇게 부릅니다

이 글의 A. 자율 방식은 보통 에이전트(Agent) 또는 자율 에이전트(Autonomous Agent)라고 부르고, B. 워크플로우 방식은 워크플로우(Workflow) 또는 오케스트레이션된 워크플로우라고 부릅니다.

Anthropic은 둘을 이렇게 구분합니다 — 워크플로우는 미리 정의된 코드 경로로 LLM과 도구를 엮은 시스템, 에이전트는 LLM이 스스로 과정과 도구 사용을 지시하는 시스템.

구현 패턴 이름까지 내려가면 A는 ReAct 루프, B는 파이프라인이나 오케스트레이션이라고 부릅니다.

둘 사이의 절충 형태에도 이름이 붙어 있는데 plan-and-execute, orchestrator-workers가 대표적입니다(8장에서 다룹니다).

참고로 엄격한 정의에서는 B를 "에이전트"라 부르지 않고, 둘을 묶어 에이전틱 시스템(agentic system)이라고 합니다.

차이는 자율성의 정도입니다.

A. 자율 방식 (Agent) — 한 번 맡기면 끝까지 알아서

요청 하나를 통째로 맡기고, 끝날 때까지 관여하지 않는 방식입니다.

계획도 에이전트가 세우고, 몇 바퀴를 돌지도, 언제 멈출지도 에이전트가 정합니다.

그림 3. 계획 수립부터 마무리까지 전부 에이전트 안에서 일어납니다

B. 워크플로우 방식 (Workflow) — 관리자가 한 단계씩 시킨다

절차를 미리 단계로 쪼개 놓고, 관리 시스템이 그 단계를 하나씩 에이전트에게 건네주는 방식입니다.

에이전트는 받은 한 단계만 처리하고 곧바로 제어권을 돌려줍니다. "다음은 무엇인가"는 바깥에서 정합니다.

그림 4. 계획은 바깥에 있고, 에이전트는 매번 한 단계짜리 작은 루프만 돌립니다

⚠️ B방식에서도 에이전트는 여전히 루프를 돕니다

다만 그 루프의 범위가 "주어진 한 단계 안"으로 줄어들 뿐입니다.

"다음 단계로 넘어갈까?"라는 판단은 에이전트가 아니라 관리 시스템이 합니다.

같은 일을 두 방식으로 — 나란히 보기

아래 두 그림은 위에서 아래로 시간이 흐릅니다.

맨 위 상자가 등장인물이고, 그 아래로 내려온 세로 점선은 각자의 시간 흐름입니다.

가로 화살표는 누가 누구에게 요청하는지를, 점선 화살표는 되돌아오는 응답을 뜻합니다.

그림 5-A. 사용자는 처음과 끝에만 등장합니다

그림 5-B. 단계마다 관리 시스템을 거치며, 그 사이에 검토·승인을 끼워 넣을 수 있습니다

4. 무엇이 다른가

부품은 같고 통제권만 다른데, 결과적으로 성격이 꽤 갈립니다.

A. 자율 방식 — 판단을 에이전트가 한다

무엇을 언제 할지, 이제 끝낼지를 에이전트가 스스로 정합니다.

B. 워크플로우 방식 — 판단을 바깥에서 한다

무엇을 언제 할지, 다음 단계로 넘어갈지를 관리 시스템이 정합니다.

⚠️ B방식의 제약은 부작용이 아니라 목적입니다

표만 보면 B는 느리고 무겁게만 보입니다.

하지만 "단계가 고정돼 유연성이 낮다"는 것은 결함이 아니라 일부러 만든 성질입니다.

매번 다르게 처리되면 곤란한 업무에서는 실행 경로를 묶어두는 것 자체가 B를 쓰는 이유입니다.

유연성을 잃은 것이 아니라 예측 가능성과 맞바꾼 것입니다.

그래서 "어느 쪽이 더 낫다"가 아니라 **"어느 쪽이 이 업무에서 덜 비싼가"**로 봐야 합니다. 두 방식은 서로 다른 상황에서 비싸집니다.

5. 서로가 비싸지는 순간

한쪽이 일방적으로 낫지 않습니다. 각자 손해를 보는 지점이 다릅니다.

계획이 도중에 바뀔 때 — B가 비싸집니다

B방식도 계획을 바꿀 수 있습니다. 다만 바꾸는 데 드는 품이 다릅니다.

A방식은 머릿속에서 생각을 고치는 것에 가깝고, B방식은 결재를 올려 일정표를 다시 받는 것에 가깝습니다.

그림 6. 계획이 자주 바뀌는 일일수록 A방식이, 거의 안 바뀌는 일일수록 B방식이 유리합니다

⚠️ 왜 B방식은 수정이 비쌀까

• 왕복이 생긴다 — 실행하던 곳에서 관리 시스템으로 돌아갔다가 다시 내려와야 함

• 상황을 다시 설명해야 한다 — 에이전트가 알게 된 내용을 관리 시스템에 전달하는 과정에서 정보가 새거나 왜곡될 수 있음

• 승인 절차가 낀다 — 안전을 위해 만든 검토 지점이 속도 면에서는 비용이 됨

• 진행 상태를 맞춰야 한다 — 어디까지 했는지 양쪽이 같은 상태를 유지해야 함

같은 절차를 반복할 때 — A가 비싸집니다

반대 상황도 있습니다. 이미 확정된 절차를 A방식으로 돌리면, 에이전트는 매번 순서를 처음부터 다시 생각합니다.

답이 이미 나와 있는 문제를 실행할 때마다 새로 푸는 셈입니다.

그림 7. 같은 업무를 반복하면 A는 매번 경로가 달라지고, B는 항상 같은 경로로 갑니다

💡 왜 A방식은 반복 업무에서 비쌀까

• 같은 일인데 결과가 매번 조금씩 다르다 — 순서와 단계 수가 실행할 때마다 달라져 "항상 이렇게 처리된다"는 보장이 없음

• 검증을 매번 다시 해야 한다 — 사람이 한 번 확인해 확정한 절차인데도, 이번에도 그대로 갔는지 매번 다시 확인해야 함

• 계획을 다시 짜는 비용이 계속 든다 — 이미 정해진 순서를 매번 새로 생각하는 데 시간과 비용이 그대로 나감

• 문제가 생겨도 원인을 나누기 어렵다 — 절차 자체의 결함인지, 이번에 순서를 잘못 짠 것인지 구분되지 않음

• 빠뜨리거나 덧붙일 수 있다 — 꼭 필요한 단계를 건너뛰거나, 필요 없는 단계를 끼워 넣는 실수가 섞일 수 있음

6. 도입하면 무엇이 달라지나

각 방식을 실제로 채택했을 때 얻는 것과, 대신 감수해야 하는 것.

A. 자율 방식을 택하면

얻는 것

• 절차를 미리 설계하지 않아도 되니 바로 시작할 수 있다

• 예상 밖 상황에서 스스로 길을 찾는다

• 만들 것이 적다 — 관리 시스템도, 상태 저장도 필요 없다

• 단계마다 오가는 왕복이 없어 처리가 빠르다

• 업무가 바뀌어도 지시만 바꾸면 되니 변경에 강하다

감수하는 것

• 같은 일도 실행할 때마다 경로와 소요가 달라진다

• 진행 중 무슨 판단을 했는지 들여다보기 어렵다

• 일이 길어질수록 앞의 맥락이 쌓여 품질이 흔들릴 수 있다

• 되돌릴 수 없는 행동을 막아 세울 지점이 마땅치 않다

B. 워크플로우 방식을 택하면

얻는 것

• 항상 같은 순서로 처리돼 결과를 예측할 수 있다

• 단계마다 기록이 남아 나중에 설명하고 감사할 수 있다

• 위험한 단계 앞에 사람 승인을 걸 수 있다

• 문제가 생기면 그 단계만 골라 다시 돌릴 수 있다

• 단계를 병렬로 돌리거나 다른 업무에 재사용할 수 있다

• 단계별로 필요한 만큼만 성능을 붙여 비용을 조절할 수 있다

감수하는 것

• 절차를 먼저 설계해야 해서 시작이 무겁다

• 관리 시스템을 따로 만들고 유지해야 한다

• 예상 밖 상황이 오면 사람이 절차를 고쳐야 한다

• 단계마다 왕복이 생겨 전체 소요가 늘 수 있다

✅ 한 줄로 줄이면

A는 시작이 가볍고 운영이 불투명합니다. B는 시작이 무겁고 운영이 투명합니다. 그래서 한 번 하고 마는 일에는 A가, 계속 돌려야 하는 일에는 B가 유리합니다.

7. 그래서 언제 무엇을 쓰나

판단 기준은 하나입니다 — 무엇을 할지 미리 알 수 있는가.

그림 8. 선택 기준 — 핵심 질문은 "무엇을 할지 미리 알 수 있는가"

A방식이 맞는 일 — 해봐야 아는 일

코드를 열어보기 전에는 몇 개 파일을 고쳐야 할지 알 수 없습니다.

자료를 찾아봐야 다음에 뭘 검색할지 정해집니다.

이런 일은 절차를 미리 못 박는 것 자체가 불가능합니다.

B방식이 맞는 일 — 이미 답이 정해진 일

이미 검증된 절차가 있는데 매번 에이전트에게 순서를 새로 고민하게 하면, 시간과 비용만 들고 실행 경로가 들쭉날쭉해집니다.

검증된 절차는 고정해서 재사용하는 편이 낫습니다.

업무별로 보면

8. 실제로는 섞어 씁니다

둘 중 하나만 고르기 어려운 이유, 그리고 그때 나오는 형태.

근거 1 — 한 업무 안에 두 성질이 섞여 있다

5장에서 A는 반복 업무에서, B는 변화가 잦은 업무에서 비싸진다고 했습니다.

문제는 실제 업무 대부분이 두 성질을 함께 갖고 있다는 점입니다.

업무 단위로는 반복이지만, 그 안의 특정 단계만 매번 다른 경우가 흔합니다.

월 마감 정산이 그렇습니다. 전체 순서는 매달 똑같지만, "예외 원인 확인" 한 단계는 무엇이 왜 안 맞는지 열어봐야 알 수 있습니다.

그림 9. 같은 업무 안에서도 단계마다 성질이 다릅니다

이 업무를 전부 A로 돌리면 정산 순서가 매달 달라져 감사에 대응할 수 없고, 전부 B로 돌리면 예외 원인 확인 단계에서 미리 정해둔 절차가 맞지 않아 막힙니다.

어느 한쪽으로 통일할 수 없으니, 층을 나누게 됩니다.

그림 10. 바깥은 B방식으로 통제하고, 안쪽은 A방식으로 자유롭게 — 두 방식의 절충

큰 흐름은 관리 시스템이 단계로 나눠 통제하고, 각 단계 안에서는 에이전트가 자유롭게 루프를 돌게 합니다.

전체 진행은 눈에 보이고 기록에 남지만, 세부 실행은 상황에 맞게 처리됩니다.

이 절충에는 이름이 있습니다 — plan-and-execute

방금 본 구조에서 계획을 사람이 미리 짜두는 대신 모델이 실행 시점에 짜게 하면, 널리 쓰이는 패턴 하나가 됩니다.

plan-and-execute라고 부릅니다.

그림 11. 계획을 만드는 부품, 실행하는 부품, 다시 계획하는 부품이 따로 있습니다

세 부품이 돌아갑니다.

Planner가 목표를 받아 할 일 목록을 통째로 만들고, Executor가 그중 한 단계만 꺼내 자율 루프로 처리하고, Replanner가 그 결과를 보고 계속할지 · 계획을 고칠지 · 끝낼지를 정합니다.

핵심은 계획이 모델의 머릿속이 아니라 바깥의 데이터로 나와 있다는 점입니다.

그래서 실행 전에 사람이 목록을 검토할 수 있고, 진행률을 표시할 수 있고, 서로 무관한 단계는 병렬로 돌릴 수 있습니다.

큰 판단을 한 번만 하므로 매 단계 비싼 모델을 부를 필요도 없습니다.

⚠️ 대신 이런 약점이 있습니다

앞 단계 결과가 예상과 크게 다르면 뒤 단계들이 통째로 무의미해집니다.

Replanner는 바로 이 문제를 메우려고 붙은 부품이고, 그만큼 재계획 호출 비용이 추가로 듭니다.

그런데 이 패턴에도 조건이 있습니다

plan-and-execute가 주는 이득 중 계획 비용 분산과 병렬 실행은 재계획 빈도에 반비례합니다.

한 번 계획해 다섯 단계를 돌리면 비싼 판단 1회로 5단계를 처리하지만, 매 단계마다 계획을 다시 세우면 판단 5회 + 실행 5회가 됩니다.

극단으로 가면 A방식보다 나빠집니다.

단계마다 계획이 무너지는 상황이라면 사실상 자율 루프를 돌리는 것과 같은데, 거기에 Planner 호출 비용과 상태 관리 부담만 얹은 꼴이기 때문입니다.

그럴 바엔 그냥 A로 가는 편이 낫습니다.

그림 12. 세 방식은 "계획을 고치는 데 드는 품"이 다릅니다

다만 이득 하나는 살아남습니다.

계획이 자주 바뀌더라도 계획이 데이터로 밖에 나와 있다는 성질은 그대로라, 사람이 중간에 목록을 들여다보거나 승인할 수 있고 진행률도 표시됩니다.

순수 자율 루프로는 안 되는 일입니다. 비용 이득은 사라져도 통제 이득은 남습니다.

✅ 실무에서 쓰는 완화책 — 계획을 굵게 잡는다

단계를 잘게 쪼갤수록 어긋날 확률이 올라갑니다.

그래서 3~5개 수준의 큰 덩어리로만 계획하고, 그 안의 세부는 Executor의 자율 루프에 맡깁니다.

계획이 굵으면 앞 단계 결과가 달라져도 "다음은 대사, 그다음은 보고서"라는 뼈대는 대체로 유지됩니다.

💡 B와 헷갈리기 쉬운 지점

plan-and-execute는 B가 아닙니다.

계획을 누가 쓰느냐가 다릅니다.

B는 사람이 미리 확정한 절차를 코드가 집행하지만, plan-and-execute는 모델이 그 자리에서 만든 계획을 코드가 들고 관리합니다.

구조는 B를 닮았고, 계획의 저자는 A쪽입니다.

근거 2 — 위험은 전 구간에 고르게 퍼져 있지 않다

통제가 비싼 이유는 5장에서 봤습니다.

그렇다면 통제를 꼭 필요한 곳에만 걸면 비용을 줄일 수 있습니다.

실제로 한 업무에서 되돌릴 수 없는 행동 — 메일 발송, 결제, 삭제, 외부 공개 — 은 전체 단계 중 소수에 몰려 있습니다.

자료를 읽고 분석하는 대부분의 단계는 잘못돼도 다시 하면 그만입니다.

✅ 그래서 나오는 절충

에이전트는 A방식처럼 자율적으로 돌되, 되돌릴 수 없는 행동 직전에만 사람의 확인을 받습니다.

절차 전체를 고정하는 대신 사고가 날 수 있는 지점만 잠그는 것이라, B의 안전장치를 A의 속도를 크게 해치지 않으면서 얻습니다.

다만, 섞는 것도 공짜는 아닙니다

혼합 구조는 관리 시스템과 자율 루프를 둘 다 만들고 유지해야 합니다.

게다가 "어디까지를 바깥에서 정하고 어디부터 맡길 것인가"라는 경계를 직접 설계해야 하는데, 이 경계가 잘못 그어지면 두 방식의 단점만 합쳐집니다.

아래에 해당하면 굳이 섞지 않는 편이 낫습니다.

• 단계가 두세 개뿐이라 나눌 실익이 없을 때

• 업무 전체가 완전히 탐색적일 때 — 그냥 A로

• 업무 전체가 완전히 확정적일 때 — 그냥 B로

• 되돌릴 수 없는 행동이 아예 없을 때 — 승인 지점을 만들 이유가 없음

9. 한 장 요약

그림 13. 결국 하나의 맞교환 — 자율성 ↔ 통제 가능성

✅ 기억할 세 문장

• 에이전트는 **"판단 → 도구 사용 → 결과 확인"**을 여러 바퀴 돌며 일한다.

• 두 방식의 차이는 이 루프를 누가 통제하느냐, 그것 하나뿐이다.

• 우열은 없다. 각자 비싸지는 지점이 다를 뿐이다.