들어가며
솔직히 처음에 “AI 에이전트”라는 말 들었을 때, 그냥 ChatGPT 좀 더 잘 쓰는 거 아닌가 싶었다. 근데 직접 만들어보니까 얘기가 완전 달라진다. 어떻게 연결하고, 어떻게 역할을 나누느냐에 따라 결과물 품질이 하늘과 땅 차이다.
나도 요즘 Claude 기반으로 AI 에이전트 구조를 설계하면서 Anthropic 공식 문서를 꽤 뒤졌는데, 공식적으로 권장하는 패턴이 딱 5가지로 정리돼 있더라. 이걸 알고 나서 “아, 내가 그냥 감으로 짜고 있었구나” 싶었다. 오늘은 그 5가지를 개발자 입장에서 가능한 쉽게 풀어볼게.
그리고 이번엔 실제 비용도 같이 따져본다. 패턴마다 API 호출 구조가 다르다 보니, 어떤 패턴이 얼마나 비싼지 알고 선택하는 게 중요하다.
비용 계산 기준
Claude API는 입력 토큰 + 출력 토큰 기준으로 과금된다. 2025년 기준 주요 모델 요금은 아래와 같다.
| 모델 | 입력 (1M 토큰) | 출력 (1M 토큰) |
|---|---|---|
| Claude Haiku 3.5 | $0.80 | $4.00 |
| Claude Sonnet 4 | $3.00 | $15.00 |
| Claude Opus 4 | $15.00 | $75.00 |
이 글에서는 Sonnet 4 기준, 1회 호출당 입력 1,000 토큰 + 출력 500 토큰 조건으로 계산한다. 이 기준으로 단일 호출 비용은 약 $0.011 (약 15원). 이걸 1배로 놓고 패턴별로 비교해보자.
1. Prompt Chaining — 가장 기본, 그래서 가장 안전한
구조는 단순하다. 설계 → 구현 → 검증, 순서대로 넘긴다.
앞 단계의 출력이 다음 단계의 입력이 되는 방식이다. 마치 공장 컨베이어벨트처럼. 복잡한 마법은 없고, 그래서 오히려 디버깅이 쉽다.
예를 들면 이런 식이다:
- 1단계: “이 기획서를 분석해서 핵심 요구사항 뽑아줘”
- 2단계: “위 요구사항 기반으로 코드 짜줘”
- 3단계: “이 코드에서 버그나 개선점 찾아줘”
Anthropic이 가장 먼저 권장하는 이유가 있다. 단순하고 예측 가능하다. 처음 에이전트 시스템 만드는 거라면 무조건 여기서 시작하는 게 맞다.
💰 비용 수준: 낮음 — 단일 호출의 N배 호출 횟수 = 단계 수. 3단계 체인이면 단일 대비 3배. 각 단계가 독립적이라 컨텍스트 누적이 적어서 토큰이 크게 불어나지 않는다. 3단계 기준 약 $0.03 (약 45원)
2. Routing — 작업 난이도에 따라 모델을 나눈다
모든 요청에 Opus를 붙이면 비용이 폭발한다. Routing 패턴은 이 문제를 해결한다.
복잡한 작업 → 고성능 모델 (예: Opus) 단순한 작업 → 경량 모델 (예: Haiku)
분류기가 먼저 요청을 판단하고, 적절한 모델로 라우팅한다. 실제로 서비스 운영할 때 API 비용 최적화에 꽤 효과적이다. 사용자 입장에서는 차이를 못 느끼는데, 인프라 비용은 확실히 줄어든다.
개발자라면 이런 생각 해봤을 거다. “이 요청은 굳이 GPT-4o 써야 하나?” Routing이 그 고민에 대한 공식 답변이다.
💰 비용 수준: 가장 낮음 — 유일한 절감 패턴 분류 콜(Haiku) 1회 + 실제 처리 콜 1회. 요청의 70%가 Haiku로 처리된다고 가정하면 Sonnet 단독 대비 비용 60~70% 절감 가능. 트래픽이 많을수록 효과가 극적으로 커진다. 단일 호출 대비 0.2~1배 (상황에 따라 더 저렴)
3. Parallelization(Voting) — 같은 문제를 여러 에이전트가 동시에 푼다
이게 좀 재밌다. 동일한 문제를 에이전트 A, B, C가 각각 독립적으로 풀고, 결과를 종합해서 최선을 고른다.
일종의 다수결 투표 방식이다. 한 에이전트가 틀려도 나머지가 커버할 수 있어서 신뢰도가 높아진다. 특히 정답이 하나로 수렴하기 어려운 창의적 작업이나 판단이 필요한 작업에 강하다.
단점은 당연히 비용. 같은 작업을 3번 돌리니까. 그래서 정확도가 중요한 핵심 기능에만 선택적으로 쓰는 게 현실적이다.
💰 비용 수준: 중간~높음 — 에이전트 수에 정직하게 비례 에이전트 3개 + 결과 종합(Aggregator) 콜 1회 = 총 4회 호출. 약 $0.04~0.05 (약 60~70원) “신뢰도를 돈으로 사는” 패턴이다. 어디에 정확도가 필요한지 선별해서 써야 한다.
4. Orchestrator-Workers — 가장 강력한 구조
구조도 복잡하고 설계도 어렵지만, 제대로 만들면 가장 강력하다.
오케스트레이터가 큰 작업을 받아서 동적으로 분해한다. 그리고 각각을 워커 에이전트에게 위임한다. 워커들이 각자 처리한 결과를 오케스트레이터가 종합한다.
예를 들어 “이 앱 전체 리팩토링해줘”라는 요청이 들어오면:
- 오케스트레이터: 작업을 분析하고 “파일 구조 정리 / 컴포넌트 분리 / API 통합”으로 나눔
- 워커 A: 파일 구조 담당
- 워커 B: 컴포넌트 분리 담당
- 워커 C: API 통합 담당
- 오케스트레이터: 결과 종합 후 최종 출력
현실적으로 LLM 기반 오케스트레이터가 항상 최선의 분해를 하지는 않는다. Anthropic도 이 점을 솔직하게 경고한다. 오케스트레이터가 워커보다 나은 판단을 항상 하는 건 아니라고.
💰 비용 수준: 높음 — 5가지 중 가장 비싸다 오케스트레이터는 보통 Opus급 모델을 쓴다. Opus 4 기준 호출 1회만 해도 $0.09 (약 130원). 여기에 워커 3개(Sonnet) 호출까지 더하면 1회 파이프라인에 $0.12~0.20 (약 180~300원). 단순 Sonnet 단일 호출 대비 10~18배 비싸다. 비용이 정당화되는 작업인지 반드시 먼저 따져봐야 한다.
5. Evaluator-Optimizer — 품질을 반복으로 끌어올린다
생성 에이전트와 평가 에이전트가 루프를 돈다.
- 생성 에이전트가 결과물을 만든다
- 평가 에이전트가 기준에 맞는지 검토한다
- 기준 미충족 → 다시 생성
- 기준 충족 → 종료
코드 리뷰, 글쓰기 퀄리티 체크, 번역 품질 검증 같은 데 쓰기 좋다. 반복 횟수 제한을 걸어두지 않으면 무한루프에 빠질 수 있으니 max iteration 설정은 필수다.
💰 비용 수준: 가변적 — 가장 예측이 어려운 패턴 루프 1회 = 생성 콜 + 평가 콜 = 약 $0.02. 평균 3회 반복이면 $0.06 (약 90원). 기준을 너무 높게 잡으면 루프가 10회를 넘기도 한다. 그러면 비용이 순식간에 $0.20을 넘어선다. max iteration은 반드시 5 이하로 고정할 것.
패턴별 비용 한눈에 보기
| 패턴 | 예시 호출 수 | 1회 비용 (Sonnet 기준) | 단일 대비 | 비용 예측 가능성 |
|---|---|---|---|---|
| Prompt Chaining (3단계) | 3회 | ~$0.03 (약 45원) | 3배 | ✅ 예측 쉬움 |
| Routing | 2회 | ~$0.002~0.011 (3~15원) | 0.2~1배 | ✅ 예측 쉬움 |
| Parallelization (3 에이전트) | 4회 | ~$0.04 (약 60원) | 4배 | ✅ 예측 쉬움 |
| Orchestrator-Workers | 5회+ | ~$0.15~0.20 (180~300원) | 10~18배 | ⚠️ 작업에 따라 변동 |
| Evaluator-Optimizer (3루프) | 6회 | ~$0.06 (약 90원) | 6배 | ⚠️ 루프 수에 따라 변동 |
실전에서 쓰는 조합 — Voting + Evaluator-Optimizer
토론 구조처럼 여러 관점을 비교해야 하는 작업이라면 이 두 패턴의 조합이 정답에 가깝다.
(사진 = claude)
예를 들어 “이 기능을 어떻게 구현할까” 같은 설계 결정에서, A는 REST API 방식으로, B는 GraphQL 방식으로 각각 설계안을 제시하고, 평가자가 요구사항 대비 적합도를 판단하는 식이다.
단, 이 조합은 비용이 꽤 나온다. Parallelization + Evaluator-Optimizer 루프 비용이 합산되니까. 정말 중요한 결정에만 써야 한다.
마무리
Anthropic이 남긴 핵심 조언이 하나 있다.
“LLM이 실제로 필요한지 먼저 확인하라.”
에이전트 시스템은 복잡할수록 비용도 올라가고 디버깅도 어려워진다. 단순한 Prompt Chaining으로 해결되는 문제에 Orchestrator-Workers를 붙이는 건 오버엔지니어링이다. 비용 측면에서도 마찬가지다.
5가지 패턴을 외우는 것보다 중요한 건, 내 문제에 어느 패턴이 맞는지, 그 비용을 감당할 수 있는지 같이 판단하는 눈이다. 그 눈은 결국 직접 만들어보면서 생긴다. 나도 여전히 만들면서 배우는 중이다.