Agent 설계 패턴

Workflow vs Agent: 먼저 무엇이 필요한지 파악하기

직관에 반하는 통찰: 가장 성공적인 AI 구현은 대개 가장 복잡한 것이 아닙니다. Agent 프레임워크를 구축하기 전에, 진정으로 무엇이 필요한지 먼저 파악하세요.

핵심 통찰

"The most successful implementations weren't using complex frameworks or specialized libraries. Instead, they were building with simple, composable patterns."

모든 AI 프로덕트 매니저가 외워둘 만한 말입니다. 업계는 Agent 프레임워크(LangChain, AutoGen, CrewAI...)로 넘쳐나지만, 프로덕션 환경에서 반복적으로 검증된 법칙은 이렇습니다: 실제로 잘 작동하는 시스템은 가장 단순한 조합 패턴을 사용합니다.

두 가지 핵심 개념

Workflow

LLM과 도구가 미리 정의된 코드 경로를 통해 조율됩니다. 개발자가 코드 작성 시 실행 순서를 결정합니다: A를 먼저 하고, B를 하고, 마지막으로 C를 합니다.

키워드: 결정론적 실행, 예측 가능성, 개발자 제어 흐름

Agent

LLM이 동적으로 결정합니다. 모델은 매 단계에서 다음에 무엇을 할지, 도구를 호출할지, 언제 종료할지를 자율적으로 판단합니다.

키워드: 자율성, 동적 의사결정, 모델 제어 흐름

흐름 비교

Workflow: 코드가 흐름을 결정

입력

단계 A

단계 B

출력

Agent: 모델이 흐름을 결정

입력

LLM 의사결정

도구 / 사고 / 재결정

출력

비교 분석

항목	Workflow	Agent
제어권	개발자 (코드 경로 고정)	모델 (매 단계 동적으로 결정)
예측 가능성	높음 — 입력이 동일하면 실행 경로도 동일	낮음 — 같은 입력도 다른 경로로 실행될 수 있음
적합한 상황	작업 분해가 명확하고 단계가 고정된 경우	개방형 작업, 유연한 의사결정이 필요한 경우
비용	예측 가능 (호출 횟수 고정)	불확실 (루프 횟수 미정)
디버그 난이도	낮음 (경로가 결정적, 재현 용이)	높음 (비결정적 동작, 재현 어려움)
대표 사례	카피라이팅 파이프라인, 데이터 정제 파이프라인	Cursor, Claude Code, Devin

Agent를 사용하지 말아야 할 때

대부분의 경우 Agent는 필요하지 않습니다

실제 경험에 따르면, 대부분의 애플리케이션 시나리오에서는 단일 LLM 호출을 최적화하고 RAG(검색 증강 생성)를 추가하는 것만으로 충분합니다. 더 단순한 방법으로는 요구사항을 충족할 수 없다는 것이 명확할 때만 Workflow나 Agent의 복잡성 도입을 고려해야 합니다.

흔한 과도한 설계의 사례: 본질적으로 하나의 Prompt와 한 번의 검색으로 해결할 수 있는 문제에 Agent 프레임워크를 도입하는 것입니다. 프레임워크가 가져오는 지연, 비용, 불확실성이 그 이점을 훨씬 능가합니다.

핵심 원칙: 복잡성 사다리

가장 단순한 방법부터 시작하고, 효과가 명확히 개선될 때만 복잡성을 추가하세요

1 먼저 단일 LLM 호출을 시도합니다: Prompt 최적화, Few-shot 예제 추가, Temperature 조정
2 부족하다면? RAG(검색 증강 생성)을 추가합니다: LLM이 외부 지식에 접근할 수 있도록
3 그래도 부족하다면? Workflow를 사용합니다: 작업을 여러 단계로 분해하고 코드로 흐름을 제어
4 정말로 유연한 의사결정이 필요한가요? 그때서야 Agent를 도입합니다: 모델이 자율적으로 계획하고 실행

모든 문제에 Agent가 필요한 것은 아닙니다. 많은 경우 Workflow로 충분하고, 심지어 잘 조정된 Prompt 하나로도 충분합니다. 복잡성은 비용이지 기능이 아닙니다. 명확한 이득이 있을 때만 복잡성을 추가하세요.