에이전트를 만들려다 workflow로 시작한 이유: 에이전트 설계의 세 가지 단순함

운영진으로 참여하고 있는 IT 동아리에서 운영 관련 질문에 답해 주는 도우미를 만들고 있습니다. 처음 계획은 당연히 "에이전트"였습니다. 요즘 LLM으로 뭔가를 만든다고 하면 다들 에이전트를 이야기하니까요.

그런데 Anthropic의 「Building effective agents」를 읽고 나서 방향을 바꿨습니다. 이 글은 에이전트를 잘 만드는 법보다 에이전트를 언제 만들지 말아야 하는지를 먼저 이야기합니다.

이 글은 원문의 앞부분(정의, 사용 시점, 프레임워크)을 읽으며 정리한 내용을 바탕으로, 원문이 말하는 원칙을 세 가지 단순함으로 묶고 제 프로젝트에 대어 본 기록입니다.

출발점 — 성공한 팀들은 단순했다

Anthropic은 지난 1년간 여러 산업에서 LLM 에이전트를 만드는 수십 개 팀과 협업했습니다. 그 결과 가장 성공한 팀들은 복잡한 프레임워크나 에이전트 전용 라이브러리를 쓰지 않았다고 합니다. 대신 단순하고 조합 가능한 패턴(simple, composable patterns)으로 시스템을 만들었습니다.

처음에는 이 "단순함"을 각 에이전트나 도구를 작게 만들라는, SRP 같은 이야기로 읽었습니다. 하지만 글을 따라가 보면 SRP보다는 KISS나 YAGNI에 가깝습니다. 처음부터 복잡하게 만들지 말고, 효과가 증명될 때만 복잡도를 더하라는 것입니다.

용어부터 — agentic system, workflow, agent

"에이전트"는 사람마다 다르게 쓰는 말입니다. 오랜 시간 혼자 동작하며 여러 도구로 복잡한 작업을 해내는 완전 자율 시스템을 떠올리는 사람도 있고, 정해진 절차를 따르는 구현을 에이전트라고 부르는 사람도 있습니다.

Anthropic은 이 모두를 agentic system이라는 하나의 범주로 묶고, 그 안에서 둘을 구조적으로 구분합니다.

Workflow

LLM과 도구가 미리 정해진 코드 경로를 따라 움직이는 시스템입니다. 흐름은 개발자가 짠 코드가 정합니다.

Agent

LLM이 작업 과정과 도구 사용을 스스로 결정하고, 작업을 어떻게 끝낼지에 대한 통제권을 가진 시스템입니다.

	Workflow	Agent
흐름을 정하는 주체	개발자가 짠 코드	LLM
강점	예측 가능성, 일관성	유연성, 모델 주도의 판단
맞는 작업	명확하게 정의된 작업	단계를 미리 정할 수 없는 열린 문제

여기서 헷갈리기 쉬운 점이 있습니다. LLM을 여러 번 호출한다고 에이전트가 되는 것도 아니고, 도구를 쓴다고 에이전트가 되는 것도 아닙니다. workflow도 LLM 호출을 여러 번 조합하고 도구도 씁니다. 둘을 가르는 기준은 흐름의 통제권을 누가 갖느냐 하나입니다.

그리고 LLM을 쓰는 앱이 모두 agentic system인 것도 아닙니다. 포함 관계로 그리면 이렇습니다.

LLM 애플리케이션 ⊃ agentic system ⊃ { workflow, agent }

에이전트 설계의 세 가지 단순함

원문의 앞부분은 결국 세 가지 질문에 대한 답으로 정리됩니다. 무엇을 만들지, 언제 복잡도를 높일지, 어떻게 만들지입니다.

1. 무엇을 만들까 — 가장 단순한 구조부터

원문은 가장 단순한 해법부터 찾고, 필요할 때만 복잡도를 높이라고 권합니다. 그리고 그것이 agentic system을 아예 만들지 않는 것일 수도 있다고 말합니다. 많은 애플리케이션은 검색(retrieval)과 프롬프트 속 예시(in-context examples)로 LLM 단일 호출을 다듬는 것만으로 충분하다는 것입니다.

복잡도가 낮은 순서로 늘어놓으면 이렇습니다.

Level 1 · LLM 단일 호출 검색과 프롬프트 속 예시로 한 번의 호출을 다듬는다

↓

Level 2 · Workflow 여러 LLM 호출과 도구를 코드가 정한 경로로 연결한다

↓

Level 3 · Agent LLM이 다음 단계와 도구 사용을 스스로 결정한다

중요한 것은 이 "단순하게"가 agent에만 적용되는 말이 아니라는 점입니다. agentic system에는 workflow도 포함됩니다. workflow조차 없이 단일 호출로 해결된다면 그것이 최선입니다.

같은 기능도 구조에 따라 이 중 어느 단계에든 놓일 수 있습니다. 사내 문서를 검색해서 답하는 RAG(Retrieval-Augmented Generation, LLM이 답하기 전에 관련 문서를 찾아 프롬프트에 넣어 주는 방식)를 예로 들면 이렇습니다.

구조	단계
질문 → (코드가) 문서 검색 → LLM이 1번 답변	단일 호출 + 검색
LLM이 검색어 다듬기 → 검색 → LLM 답변 → LLM 검증	Workflow (순서를 코드가 정함)
LLM이 검색할지, 무엇을 몇 번 검색할지 스스로 판단	Agent (흔히 agentic RAG라고 부름)

검색 자체는 LLM 호출이 아니라 코드가 하는 전처리입니다. 그래서 "RAG를 쓰니까 workflow다"라고 말할 수는 없습니다. RAG는 패턴이라기보다, 어느 단계에서든 LLM에 붙여 쓸 수 있는 검색 기능에 가깝습니다.

2. 언제 복잡도를 높일까 — 비용과 성능의 거래

원문은 agentic system이 보통 지연 시간과 비용을 내주고 더 나은 성능을 얻는다고 말합니다. 처음 읽을 때는 "비용이 드니까 조심하라"는 말로 읽었습니다. 다시 읽어 보니 원문이 따지라는 것은 비용 자체가 아니라 이 거래(tradeoff)입니다. 시간과 비용을 더 쓰는 만큼 성능이 좋아지는지를 저울에 올려 봐야 합니다.

그리고 그 판단은 감이 아니라 측정으로 합니다. 원문 결론부도 복잡도는 결과가 개선된다는 것이 증명될 때만 더하라고 말합니다.

Step 1 · Build 가장 단순한 구조로 만든다

↓

Step 2 · Evaluate 평가해서 성능이 부족한지 확인한다

↓

Step 3 · Step up 부족하면 한 단계 복잡도를 높인다. 흐름을 미리 정할 수 있으면 workflow, 정할 수 없으면 agent

↓

Step 4 · Re-evaluate 늘어난 지연 시간과 비용만큼 좋아졌는지 다시 확인한다

3. 어떻게 만들까 — 프레임워크와 거리 두기

agentic system을 쉽게 만들게 해 주는 프레임워크는 많습니다. 원문은 Claude Agent SDK, AWS의 Strands Agents SDK 같은 SDK와 Rivet, Vellum 같은 GUI 도구를 예로 듭니다. 이런 도구는 LLM 호출, 도구 정의와 파싱, 호출 연결 같은 저수준 작업을 대신해 줘서 시작을 쉽게 만듭니다.

문제는 두 가지입니다. 첫째, 추상화 계층이 실제로 오가는 프롬프트와 응답을 가려서 디버깅을 어렵게 만듭니다. 둘째, 단순한 구성으로 충분한데도 복잡도를 더하고 싶게 만듭니다. "가장 단순한 구조부터"라는 첫 번째 단순함을 거스르게 되는 셈입니다.

프레임워크부터

시작은 쉽지만 실제 프롬프트와 응답이 가려집니다. 내부 동작을 잘못 가정하기 쉽고, 필요 없는 복잡도를 얹고 싶어집니다.

API 직접 호출부터

많은 패턴은 코드 몇 줄이면 됩니다. 오가는 프롬프트와 응답이 그대로 보이고, 필요할 때 한 단계씩 쌓을 수 있습니다.

그래서 원문은 LLM API를 직접 쓰는 것부터 시작하라고 권합니다. 프레임워크를 쓴다면 그 아래에서 돌아가는 코드를 반드시 이해해야 합니다. 내부 동작을 잘못 가정하는 것이 흔한 실수의 원인이라고 합니다.

세 가지 단순함을 표로 정리하면 다음과 같습니다.

단순함	질문	원문의 답
무엇을	어떤 구조로 만들까?	단일 호출부터. agentic system을 안 만드는 것도 답
언제	복잡도를 올릴까?	비용과 성능의 거래가 타당하다고 측정됐을 때
어떻게	무엇으로 만들까?	API 직접 호출부터. 프레임워크는 내부를 이해하고

동아리 운영 도우미에 대어 보면

이 표를 동아리 운영 도우미에 대어 보니, 제가 만들고 있던 것이 무엇인지 선명해졌습니다.

처음에는 에이전트로 설계하려고 했습니다. 그런데 단순한 LLM 앱(단일 호출 + 검색)으로는 부족해 보였습니다. 질문이 FAQ로 바로 답할 수 있는 것인지, 운영 가이드나 1:1 가이드, 개인정보 처리방침 중 어느 문서를 봐야 하는 것인지 먼저 가려야 했기 때문입니다. 그래서 지금은 이런 흐름으로 구현하고 있습니다.

운영 도우미 흐름 Graph

START → check_faq ─(FAQ에 있음)──────────────────────────→ generate_answer → END
                  └(없음)→ get_document_name → retrieve_document ↗

단계	쓰는 모델	하는 일
check_faq	임베딩 + LLM	FAQ를 검색하고, 그 결과로 답할 수 있는지 LLM이 Yes/No로 판단
get_document_name	작은 LLM	질문을 세 문서 중 하나로 분류. 목록에 없는 값이 나오면 운영 가이드로
retrieve_document	임베딩만	고른 문서로 필터를 걸어 벡터 검색
generate_answer	LLM	질문과 검색 결과로 최종 답변 생성

글을 읽고 나서 보니 이것은 에이전트가 아니라 workflow입니다. 갈림길에서 어느 쪽으로 갈지는 LLM이 판단하지만, 갈 수 있는 길 자체는 제가 코드로 미리 그려 뒀습니다. 그리고 이 구조가 지금 문제에는 더 잘 맞습니다.

• 비용과 지연 시간이 예측됩니다. FAQ로 답하면 LLM 호출 2번, 아니면 3번입니다. 에이전트였다면 질문마다 호출 횟수가 달라졌을 것입니다.
• 값싼 판단은 값싼 모델에 맡깁니다. 문서 분류처럼 단순한 판단은 작은 모델로 처리하고, 무거운 모델은 최종 답변에만 씁니다.
• 실패해도 흐름이 무너지지 않습니다. 분류 결과가 이상하면 기본 문서로 보냅니다. 에이전트가 엉뚱한 판단을 이어 가며 오류를 쌓을 여지가 없습니다.

참여자와 운영자를 구분하는 기능도 고민하고 있는데, 이것도 같은 관점으로 보게 됐습니다. 누가 운영자인지는 LLM이 대화를 보고 추측할 일이 아니라, 코드가 권한 정보로 확인하고 분기할 일입니다. 권한처럼 틀리면 안 되는 판단일수록 흐름의 통제권을 코드에 두는 workflow가 맞습니다.

LLM이 분기를 고르는데도 workflow일까

다만 경계가 생각보다 미묘하다는 점도 짚고 싶습니다. check_faq에서는 LLM이 Yes/No를 판단하고, 그 결과에 따라 흐름이 갈립니다. 그러면 LLM이 흐름을 정하는 것 아닌가 싶었습니다.

정리해 보면 차이는 이렇습니다. workflow의 LLM은 코드가 준비한 갈림길 중 하나를 고르고, agent의 LLM은 다음에 무엇을 할지 자체를 만들어 냅니다. 선택지가 코드로 닫혀 있느냐, 열려 있느냐의 차이입니다.

Workflow의 LLM

"FAQ로 답할 수 있는가? Yes/No"처럼, 코드가 미리 준비한 선택지 중 하나를 고릅니다. 갈 수 있는 길은 닫혀 있습니다.

Agent의 LLM

"다음에 무엇을 검색하고, 어떤 도구를 몇 번 쓸까?"를 스스로 만들어 냅니다. 갈 수 있는 길이 열려 있습니다.

그렇다고 언젠가 에이전트로 가지 않겠다는 것은 아닙니다. 여러 문서를 오가며 확인해야 하는 질문이 많아져서 정해진 흐름으로 답하지 못하는 경우가 늘어난다면, 그때가 복잡도를 높일 때입니다. 그 판단도 감이 아니라 실제 질문으로 평가해서 내리려고 합니다.

정리하며

「Building effective agents」는 에이전트를 만드는 법보다 먼저, 에이전트가 필요한지 묻는 법을 알려 주는 글이었습니다. 단일 호출로 충분한지, 복잡도를 올릴 만큼 성능이 좋아지는지, 프레임워크가 가리는 것은 없는지를 차례로 따져 보니 제 도우미에게 맞는 답은 에이전트가 아니라 workflow였습니다.

제가 이해한 이 글의 한 줄 요약은 이렇습니다.

복잡도는 기본값이 아니라, 효과가 증명됐을 때 지불하는 비용이다.

에이전트는 가장 강력한 선택지이지만, 가장 먼저 꺼낼 선택지는 아닙니다.

레퍼런스: Anthropic - Building effective agents

Key Points

• Workflow와 Agent를 가르는 기준은 흐름의 통제권입니다. LLM 호출 횟수나 도구 사용 여부가 아닙니다.
• 무엇을: 단일 호출 → workflow → agent 순서로, 가장 단순한 구조부터 시작합니다.
• 언제: 지연 시간과 비용을 더 쓰는 만큼 성능이 좋아진다고 측정됐을 때만 복잡도를 높입니다.
• 어떻게: LLM API 직접 호출부터 시작하고, 프레임워크를 쓴다면 내부 동작을 이해해야 합니다.
• LLM이 분기를 골라도 workflow일 수 있습니다. 선택지가 코드로 닫혀 있다면 흐름의 통제권은 여전히 코드에 있습니다.