1장. 에이전트 아키텍처

학습 목표

• 워크플로와 에이전트의 차이를 설명하고, 한 시스템 안에서 두 방식이 섞이는 지점을 찾는다.
• 프롬프트 체이닝·라우팅·병렬화·오케스트레이터-워커·평가자-최적화의 적용 조건과 실패 양상을 구분한다.
• 다중 에이전트 구조가 비용을 늘리는 원인을 설명하고, 성공한 작업당 비용으로 도입을 판단한다.
• handoff와 agent-as-tool, LLM 오케스트레이션과 코드 오케스트레이션 가운데 알맞은 연결 방식을 고른다.
• 가장 단순한 구조에서 출발해 근거가 생길 때만 복잡도를 올리는 결정 절차를 적용한다.

들어가며

어느 팀이 고객 문의 처리를 "에이전트로" 다시 만들었습니다. 모델이 알아서 도구를 고르고, 필요하면 다른 에이전트에게 일을 넘기는 구조였습니다. 데모는 훌륭했습니다. 그런데 운영 한 달 만에 세 가지 불만이 올라왔습니다. 같은 질문에도 처리 경로가 매번 달라 재현이 안 되고, 응답이 느려졌고, 청구서가 예상의 세 배였습니다. 로그를 열어 보니 문의의 대부분은 처리 순서가 늘 같은 정형 요청이었습니다. 정해진 노선을 달리면 될 일을 매번 택시를 불러 길을 묻고 있었던 셈입니다.

이 장은 이런 실수를 피하는 법을 다룹니다. 워크플로와 에이전트를 구분하고, 에이전트가 필요한 업무를 가려낸 뒤, 다섯 가지 워크플로 패턴과 자율·다중 에이전트의 비용을 해부합니다. 이어서 에이전트를 잇는 방식과 가장 단순한 구조에서 출발하는 결정 절차를 정리하고, 깊이 읽기에서 혼합 설계와 상관된 오류를 살펴봅니다.

핵심 개념

워크플로와 에이전트

Anthropic의 "Building effective agents"는 둘을 이렇게 나눕니다. 워크플로는 LLM과 도구가 미리 정해진 코드 경로로 조율되는 시스템이고, 에이전트는 LLM이 자신의 진행 과정과 도구 사용을 동적으로 결정하는 시스템입니다. 같은 글은 워크플로가 잘 정의된 작업에 예측 가능성과 일관성을 주고, 에이전트는 규모 있는 유연성과 모델 주도 판단이 필요할 때 더 낫다고 정리합니다.

워크플로가 정해진 노선의 버스라면 에이전트는 목적지만 듣고 길을 고르는 택시입니다. 노선이 정해진 일에 택시를 부르면 비용만 늘고 경로도 예측하기 어렵습니다. 반대로 골목마다 길이 다른 일에 버스를 고집하면 승객이 내릴 곳에 닿지 못합니다.

이 구분은 시스템 전체에 붙는 딱지가 아닙니다. 한 시스템 안에서도 단계마다 다음 행동을 정하는 주체가 다를 수 있습니다. 문의 분류와 권한 검사는 코드가 정하고, 분류된 문의 중 일부의 조사만 모델이 스스로 이끄는 식입니다. 설계 문서에는 "이 시스템은 에이전트다"가 아니라 "이 단계의 다음 행동은 누가 정하는가"를 적어야 합니다.

에이전트가 필요한 업무

에이전트는 지연과 비용을 대가로 더 나은 작업 성능을 사는 선택입니다. Anthropic은 가장 단순한 해법을 먼저 찾고 필요할 때만 복잡도를 올리라고 권하며, 많은 애플리케이션에서는 검색과 예시를 붙인 단일 LLM 호출을 최적화하는 것으로 대개 충분하다고 말합니다.

OpenAI의 "A practical guide to building agents"는 에이전트를 검토할 업무의 기준 세 가지를 듭니다.

가이드는 이 기준을 분명히 만족하는지 먼저 확인하고, 그렇지 않으면 결정적(deterministic) 해법으로 충분할 수 있다고 덧붙입니다. 결정적이라는 말은 같은 입력에 늘 같은 경로와 결과를 낸다는 뜻입니다. 정해진 서식의 파일을 검증해 올리는 일처럼 규칙이 단순하고 안정적이면, 에이전트보다 평범한 코드가 더 싸고 정확합니다.

증강된 LLM과 에이전트 루프

모든 구조의 기본 부품은 같습니다. Anthropic은 이를 증강된 LLM, 즉 검색·도구·메모리 같은 확장을 붙인 LLM이라고 부릅니다. OpenAI 가이드도 에이전트를 모델, 도구, 지침 세 요소로 설명합니다. 도구는 다시 세 종류로 나뉩니다. 맥락과 정보를 가져오는 데이터 도구, 외부 시스템에 작용하는 행동 도구, 다른 에이전트를 도구처럼 부르는 오케스트레이션 도구입니다.

에이전트는 이 부품을 루프로 돌립니다. 모델이 다음 행동을 고르고, 도구를 실행하고, 그 결과를 다시 모델에 넣습니다. Anthropic은 에이전트가 매 단계 환경에서 실제 결과(Anthropic의 표현으로 "ground truth"), 예컨대 도구 결과나 코드 실행 결과를 얻어 진행을 판단해야 하며, 체크포인트나 막히는 지점에서 사람의 피드백을 받으려고 멈출 수 있다고 설명합니다. 루프가 이런 실제 결과 대신 모델의 추측으로만 돌면 오류가 쌓입니다.

프롬프트 체이닝과 게이트

프롬프트 체이닝은 작업을 고정된 하위 단계로 나누고, 앞 호출의 출력을 다음 호출의 입력으로 넘깁니다. 단계 사이에는 코드로 된 검사, 즉 게이트를 둘 수 있습니다. Anthropic의 예는 마케팅 문구를 쓰고 번역하기, 개요를 쓰고 기준에 맞는지 확인한 뒤 본문 쓰기입니다. 작업을 깔끔하게 고정 단계로 나눌 수 있을 때 씁니다.

체이닝을 설계할 때는 단계 사이의 데이터 계약을 먼저 정합니다. 앞 단계가 무엇을 어떤 형식으로 넘기는지, 다음 단계가 무엇을 전제하는지를 스키마로 고정하는 것입니다.

1. 단계마다 출력 스키마를 정한다(필드, 단위, 허용 범위).
2. 게이트에서 스키마와 업무 규칙을 코드로 검사한다.
3. 검사에 실패하면 그 단계만 다시 실행하거나 사람에게 넘긴다.
4. 단계별 지연을 합산해 전체 지연 예산 안에 드는지 확인한다.

체이닝의 대표 실패는 오류 전파입니다. 첫 단계가 단위를 잘못 읽으면 뒤 단계는 그 숫자로 그럴듯한 글을 씁니다. 게이트는 바로 이 전파를 끊는 장치입니다. 또 단계가 늘수록 지연이 더해지므로, 단계를 쪼개는 이득(호출당 집중도)이 지연 비용보다 큰지 따져야 합니다.

라우팅

라우팅은 입력을 분류해 전문화된 후속 처리로 보냅니다. 따로 다루는 편이 나은 뚜렷한 범주가 있을 때 씁니다. Anthropic은 고객 문의를 유형별로 나누는 경우와, 쉬운 질문은 작고 빠른 모델로, 어려운 질문은 더 강한 모델로 보내는 경우를 예로 듭니다.

라우터 설계에서 정확도만큼 중요한 것이 오분류 비용입니다. 환불 문의를 일반 안내로 잘못 보내는 것과 일반 안내를 환불 처리로 보내는 것은 피해가 다릅니다. 그래서 라우터에는 다음을 함께 설계합니다.

분류 자체는 규칙, 작은 모델, 구조화된 출력을 내는 LLM 호출 중 무엇으로 해도 됩니다. 범주가 안정적이면 코드나 작은 모델이 싸고, 범주의 경계가 자연어 뉘앙스에 달렸으면 LLM 분류가 낫습니다.

병렬화: 구간 나누기와 투표

병렬화에는 두 변형이 있습니다. 구간 나누기(sectioning)는 서로 독립인 하위 작업을 동시에 돌리고, 투표(voting)는 같은 작업을 여러 번 돌려 여러 출력을 모읍니다. Anthropic은 구간 나누기의 예로 한 모델이 답을 만드는 동안 다른 모델이 부적절한 요청인지 걸러 내는 가드레일 구성을, 투표의 예로 여러 프롬프트가 각각 코드 취약점을 찾게 하거나 서로 다른 임계값으로 콘텐츠 적합성을 판정하게 하는 구성을 듭니다. 속도를 얻거나, 여러 관점과 시도로 더 믿을 만한 결과를 얻을 때 씁니다.

병렬화의 이득을 계산할 때는 임계 경로를 봅니다. 전체 시간은 가장 오래 걸리는 경로와 결과를 합치는 시간으로 정해집니다. 워커 열 개를 동시에 띄워도 전체 시간은 가장 느린 워커 하나와 결과를 정리하는 단계의 합보다 짧아지지 않습니다. 또 동시 실행 수는 외부 API 한도에 막힐 수 있고, 워커 하나가 실패했을 때 부분 결과를 쓸지 전체를 다시 돌릴지도 미리 정해야 합니다.

투표는 호출 수만큼 비용이 늘어납니다. 판단이 애매하고 한 번의 오류 비용이 큰 곳에 한정하세요.

오케스트레이터-워커

오케스트레이터-워커는 중앙 LLM이 작업을 동적으로 나눠 워커 LLM에 맡기고 결과를 종합합니다. 병렬화와 겉모습은 비슷하지만 결정적인 차이가 있습니다. 병렬화는 하위 작업이 설계 시점에 정해져 있고, 오케스트레이터-워커는 입력을 보기 전에는 하위 작업을 예측할 수 없습니다. Anthropic의 예는 여러 파일을 고쳐야 하는 코딩 도구와 여러 출처를 뒤지는 검색 작업입니다.

이 패턴은 위임 계약에서 성패가 갈립니다. Anthropic의 리서치 시스템 글은 하위 에이전트마다 목표, 출력 형식, 쓸 도구와 출처에 대한 지침, 분명한 작업 경계가 필요하다고 적습니다. 지시가 모호하자 하위 에이전트 셋 중 둘이 같은 공급망 주제를 중복 조사한 사례도 소개합니다. 위임 지시에는 다음 네 가지를 빠짐없이 넣으세요.

목표: 2024~2026년 국내 전기차 충전 요금 정책 변화만 조사한다.
출력 형식: 연도·정책명·변경 내용·출처 URL 열을 가진 표, 20행 이내.
도구와 출처: 정부·공공기관 사이트 우선, 블로그 요약은 쓰지 않는다.
경계: 해외 정책과 충전기 보급 통계는 다른 워커가 맡는다.

여기에 재위임 깊이(워커가 다시 워커를 만들 수 있는가)와 전체 워커 수의 상한을 코드로 걸어 두어야 합니다.

평가자-최적화

평가자-최적화는 한 호출이 생성하고 다른 호출이 평가와 피드백을 주는 루프입니다. Anthropic은 평가 기준이 분명하고 반복 개선의 가치가 측정될 때 쓰라고 합니다. 기준은 두 가지로 확인합니다. 사람이 피드백을 주면 결과가 실제로 나아지는가, 그리고 모델이 그런 피드백을 스스로 만들어 낼 수 있는가입니다. 예로는 번역가의 비평처럼 미묘한 차이를 잡아야 하는 문학 번역, 평가자가 더 찾아볼지를 판단하는 여러 차례의 검색이 있습니다.

루프에는 끝이 있어야 합니다. 평가자가 영원히 "조금 더"를 외칠 수 있기 때문입니다. 최대 반복 횟수, 점수가 더 오르지 않으면 멈추는 조건, 반복 사이 개선 폭의 하한을 코드에 둡니다. 루프가 수렴하지 않고 끝나면 마지막 결과와 평가 기록을 함께 남겨 사람이 판단하게 합니다.

자율 에이전트와 멈춤 조건

필요한 단계 수를 예측하기 어렵거나 미리 코드로 박을 수 없는 열린 문제에는 자율 에이전트를 씁니다. Anthropic은 이때 모델의 판단을 어느 정도 신뢰할 수 있어야 하고, 비용이 높고 오류가 누적될 수 있으니 샌드박스 환경에서 충분히 시험하고 적절한 가드레일을 두라고 권합니다. 통제를 유지하려면 최대 반복 횟수 같은 멈춤 조건을 넣습니다. 멈춤 조건의 구체적 설계는 5장에서 다룹니다.

같은 글은 에이전트 설계의 세 원칙을 꼽습니다. 설계를 단순하게 유지할 것, 에이전트의 계획 단계를 명시적으로 드러낼 것, 철저한 도구 문서화와 시험으로 에이전트-컴퓨터 인터페이스(ACI)를 다듬을 것입니다. 세 번째 원칙은 2장의 주제입니다.

다중 에이전트의 비용

Anthropic의 리서치 시스템 사례에서 에이전트는 채팅보다 약 4배, 다중 에이전트 시스템은 약 15배의 토큰을 썼습니다. BrowseComp 평가 분석에서는 세 요인이 성능 분산(차이)의 95%를 설명했고, 토큰 사용량 하나가 약 80%를 설명했습니다. 나머지 둘은 도구 호출 횟수와 모델 선택이었습니다. 다중 에이전트의 이득은 상당 부분 "여러 창에 걸쳐 더 많은 토큰을 쓸 수 있다"는 데서 옵니다.

그래서 그 글은 다중 에이전트가 병렬화 여지가 크고 정보가 한 창에 담기지 않는 가치 높은 작업에 맞고, 모든 에이전트가 같은 맥락을 공유해야 하거나 에이전트 사이 의존성이 강한 작업에는 맞지 않는다고 정리합니다. 대부분의 코딩 작업은 연구보다 진짜로 병렬화할 부분이 적어 덜 맞는다고도 적습니다.

비용은 토큰만이 아닙니다.

비교 지표는 총비용이 아니라 성공한 작업당 비용이어야 합니다. 총비용이 두 배여도 성공률이 세 배가 되면 이득이고, 비용이 같아도 성공률이 그대로면 손해입니다.

오케스트레이션: LLM이 정할까, 코드가 정할까

OpenAI Agents SDK 문서는 두 방식을 구분합니다. LLM 오케스트레이션은 모델이 계획하고 다음 단계를 골라 열린 작업에 맞습니다. 코드 오케스트레이션은 흐름을 코드로 정해 속도·비용·성능 면에서 더 결정적이고 예측 가능합니다. 문서가 드는 코드 오케스트레이션 기법은 구조화된 출력으로 작업을 분류해 다음 에이전트를 고르기, 한 에이전트의 출력을 다음 에이전트의 입력으로 잇기, 평가 에이전트가 통과를 선언할 때까지 while 루프 돌리기, asyncio.gather 같은 기본 도구로 독립 에이전트를 병렬 실행하기입니다.

에이전트를 잇는 방법도 둘입니다.

handoff는 한 번의 실행(턴) 안에서 일어나며, 다음 턴을 어느 에이전트로 시작할지는 애플리케이션이 실행을 호출할 때 정합니다. OpenAI 가이드는 같은 구분을 관리자 패턴(에이전트를 도구로 호출)과 분산 패턴(동료끼리 handoff)으로 부르며, 다중 에이전트를 그래프로 보면 관리자 패턴의 간선은 도구 호출이고 분산 패턴의 간선은 실행을 넘기는 handoff라고 설명합니다. 가이드의 일반 권고는 단일 에이전트의 능력을 먼저 최대한 끌어올리라는 것입니다. 나눌 신호는 두 가지입니다. 프롬프트에 if-then-else 분기가 너무 많아 템플릿을 키우기 어려울 때, 그리고 도구가 많아서라기보다 서로 비슷하거나 겹쳐서 엉뚱한 도구를 고를 때입니다. 가이드는 잘 구분된 도구 15개 이상을 다루는 구현도 있고, 겹치는 도구 10개 미만에서 헤매는 구현도 있다고 적습니다.

Google ADK의 순차·반복·병렬 워크플로 에이전트도 코드 오케스트레이션의 예입니다. 미리 정한 논리로 실행되며 오케스트레이션에 모델을 쓰지 않아 결정적입니다. 다만 Python과 Go의 ADK 2.0부터는 이 템플릿형 워크플로가 그래프 기반·동적 워크플로로 대체되었으니, 쓰는 언어와 버전의 문서를 확인하세요.

가장 단순한 구조부터 고르기

구조 선택은 사다리를 한 칸씩 오르는 일입니다. 아래 칸에서 실패가 측정될 때만 위 칸으로 갑니다.

결정은 아키텍처 결정 기록(ADR)으로 남깁니다. ADR은 무엇을 왜 골랐는지 적은 짧은 문서입니다. 비교한 대안(최소한 한 칸 아래 구조), 같은 과제 세트로 잰 품질·지연·비용, 기각한 대안과 이유, 이 결정을 다시 검토할 조건을 적습니다. 반년 뒤 누군가 "왜 이렇게 복잡하지?"라고 물을 때 답이 되는 문서이고, 거꾸로 "이제 더 단순하게 가도 된다"는 근거도 여기서 나옵니다.

깊이 읽기

코드는 골격을, 모델은 판단을

실무에서 가장 흔하고 튼튼한 구조는 워크플로와 에이전트의 혼합입니다. 상태 전이와 업무 규칙, 권한, 예산은 코드가 쥐고, 해석·계획·문장 생성처럼 규칙으로 쓰기 어려운 판단만 모델에 맡깁니다. 비유하자면 철도는 코드가 깔고, 각 역에서 승객에게 무엇을 안내할지는 모델이 정하는 구조입니다.

이 구조의 핵심 규칙은 제안과 실행의 분리입니다. 모델은 "다음에 환불 도구를 이 인자로 부르자"를 제안하고, 코드는 그 제안이 현재 상태에서 허용되는지, 예산 안인지, 승인이 필요한지를 검사한 뒤 실행합니다. 모델이 실수하거나 속더라도 코드의 검사가 피해를 막습니다. 반대로 모든 분기를 코드로 박으면 업무 규칙이 바뀔 때마다 코드를 고쳐야 하므로, 판단 구간은 넓게 열어 두되 그 출구에만 검문소를 둡니다.

동의는 검증이 아니다

다중 에이전트나 투표 구성에서 "세 에이전트가 모두 같은 답을 냈다"는 사실은 생각보다 약한 증거입니다. 같은 모델, 같은 프롬프트 계열, 같은 검색 결과를 쓰는 에이전트들은 같은 방식으로 틀립니다. 이를 상관된 오류라고 합니다. 같은 오보를 읽은 세 사람이 입을 모아도 오보가 사실이 되지 않는 것과 같습니다.

검증의 힘은 독립성에서 나옵니다. 역할보다 근거를 나눠야 합니다. 서로 다른 출처를 보게 하거나, 생성과 다른 방식(코드 검사, 원문 대조)으로 확인하거나, 한 에이전트에게 반대 근거만 찾게 하는 식입니다. 그리고 투표 결과를 쓰기 전에 평가 세트로 "투표가 단일 호출보다 실제로 오류를 줄였는가"를 측정합니다.

프레임워크를 쓸 때

에이전트 프레임워크는 시작을 쉽게 해 줍니다. 그러나 Anthropic은 프레임워크가 그 밑의 프롬프트와 응답을 가리는 추상화 층을 만들어 디버깅을 어렵게 하고, 단순한 구성으로 충분할 때도 복잡도를 더하고 싶게 만든다고 지적하며, LLM API를 직접 쓰는 것에서 시작하고 프레임워크를 쓴다면 그 밑의 코드를 이해하라고 권합니다.

실무 기준은 하나입니다. 모델에 실제로 전달되는 프롬프트, 도구 정의, 도구 결과를 언제든 원문 그대로 볼 수 있어야 합니다. 트레이싱(4장)과 요청 로그로 이 가시성을 먼저 확보하세요.

실무 장면

온길: 정형 요청에 택시를 부르지 않기

여행 플랫폼 '온길'은 일정 추천 기능을 자율 에이전트 하나로 만들었다. 에이전트는 항공·숙소·관광지 도구를 오가며 평균 23번 도구를 호출했고, 응답까지 40초가 걸렸으며 같은 요청에도 경로가 매번 달랐다.

팀은 요청 로그 2,000건을 분류했다. 87%는 '도시·기간·예산'이 주어진 정형 요청으로 처리 단계가 항공·숙소 조회 → 일정 초안 → 예산 검사로 거의 같았고, 13%만 "부모님과 갈 만한 조용한 곳" 같은 열린 요청이었다.

대안은 셋이었다. 첫째, 더 강한 모델로 바꾼다. 경로의 불안정과 비용 문제는 그대로라 기각했다. 둘째, 모든 요청을 고정 체이닝으로 바꾼다. 열린 요청의 품질이 떨어지는 것이 시범 20건에서 확인되어 기각했다. 셋째, 분류 호출 하나로 둘을 가르는 라우팅을 두고, 정형 요청은 항공·숙소를 병렬로 조회하는 고정 체이닝과 코드 예산 게이트로, 열린 요청만 최대 턴 수를 정한 에이전트로 보낸다. 팀은 셋째를 골랐고, 분류 확신이 낮은 요청은 에이전트 쪽으로 보내 품질 손실 위험을 줄였다.

정형 요청의 응답 시간은 9초로 줄었고 요청당 비용은 60% 넘게 내려갔으며, 열린 요청의 품질은 평가 세트에서 그대로였다. ADR에는 "열린 요청 비율이 30%를 넘으면 구조를 다시 검토한다"는 조건을 남겼다. 근거는 '에이전트가 나쁘다'가 아니었다. 예측 가능한 다수에 예측 불가능한 소수를 위한 구조를 쓰고 있었다는 점이었다.

솔바람에너지: 릴레이 에이전트 구조 걷어 내기

도시가스 회사 '솔바람에너지'의 고객품질팀은 매주 민원 원인 보고서를 만든다. 처음 구조는 수집·분석·작성·검토 에이전트 넷이 이어달리기하듯 차례로 일을 넘기는 형태였다. 네 에이전트는 모두 같은 주간 민원 데이터 약 4,000건을 다시 읽었고, 보고서 한 편에 드는 토큰은 단일 에이전트 시제품의 7배였다. 품질 점수는 시제품보다 조금 높았지만, 검토 에이전트가 작성 에이전트의 결론을 거의 그대로 승인한다는 사실이 트랜스크립트에서 드러났다.

팀은 같은 과제 30주 분량으로 세 구조를 비교했다. 기존 릴레이 구조, 단일 에이전트, 그리고 혼합 구조다. 혼합 구조에서는 수집과 분류를 코드와 작은 모델 라우터로 처리하고, 원인 분석만 지역별 워커로 나눠 병렬 조사하게 했으며, 작성은 평가 기준표가 분명한 평가자-최적화 루프(최대 3회)로 돌렸다.

결과는 혼합 구조가 성공한 보고서당 비용에서 릴레이 구조의 3분의 1이었고, 품질은 같거나 나았다. 검토 에이전트는 없앴다. 같은 데이터를 본 같은 모델의 '동의'가 검증 구실을 못 했기 때문이다. 대신 보고서의 수치는 코드가 원천 데이터와 대조하게 했다. 기각한 대안은 "에이전트 수는 유지하고 모델만 작은 것으로 바꾸기"였다. 비용은 줄지만 중복 읽기와 조정 비용이라는 구조적 원인이 남는다는 판단이었다.

자주 틀리는 지점

1. "에이전트가 워크플로보다 항상 낫다." 데모가 인상적이면 더 똑똑한 구조처럼 보입니다. 그러나 자율성은 비용, 지연, 예측 불가능성을 동반합니다. 단계가 고정된 일에는 워크플로가 더 빠르고 싸고 재현됩니다.
2. "전문 에이전트를 많이 둘수록 품질이 오른다." 사람 조직처럼 분업하면 전문성이 생길 것 같지만, 성능 향상의 상당 부분은 토큰을 더 쓴 결과입니다. 맥락 공유와 의존성이 큰 작업에서는 조정 비용이 이득을 넘습니다.
3. "handoff로 넘기면 결과가 원래 에이전트로 돌아온다." 함수 호출처럼 보여 착각하기 쉽지만, handoff는 제어권을 넘깁니다. 결과를 받아 이어 쓰려면 agent-as-tool이 맞습니다.
4. "병렬로 돌리면 전체 시간은 워커 수로 나눈 만큼 준다." 나눗셈으로 어림하기 쉽지만, 전체 시간은 임계 경로와 종합 단계가 정합니다. 의존 관계와 외부 한도를 먼저 그립니다.
5. "여러 에이전트가 동의하면 맞는 답이다." 다수결이 믿음직해 보이지만, 같은 근거를 본 같은 모델은 같은 방식으로 틀립니다. 검증은 독립된 근거나 다른 방식으로 합니다.
6. "평가자-최적화 루프는 품질이 오를 때까지 돌리면 된다." 반복할수록 좋아질 것 같지만 끝 조건이 없으면 비용이 무한히 늘 수 있습니다. 최대 반복과 개선 폭 하한을 코드에 둡니다.
7. "도구가 많아서 헷갈리니 에이전트를 나눠야 한다." 개수가 눈에 잘 띄어 원인으로 보이지만, 문제는 유사성인 경우가 많습니다. 이름, 매개변수, 설명을 먼저 고치고 그래도 안 될 때 나눕니다.

한눈에 정리

공식 문서로 확인하기

• Anthropic: Building effective agents — 워크플로·에이전트 정의, 다섯 패턴과 쓰는 조건, 세 원칙, 프레임워크에 대한 조언
• Anthropic: How we built our multi-agent research system — 토큰 배수와 성능 요인, 위임 지시의 요소, 노력 규모 조절
• OpenAI: A practical guide to building agents — 에이전트를 검토할 업무 기준, 단일 에이전트 우선, 관리자·분산 패턴
• OpenAI Agents SDK: Agent orchestration — LLM·코드 오케스트레이션, handoff와 agents as tools
• Google ADK: Workflow agents — 결정적 워크플로 에이전트와 ADK 2.0 변경 안내

셀프 체크

1-1. 워크플로와 에이전트를 가르는 기준을 한 문장으로 쓰고, 한 시스템 안에 두 방식이 함께 들어간 예를 하나 들어라.

1-2. 병렬화의 두 변형은 각각 무엇을 얻으려는 것이며, 투표를 모든 단계의 기본값으로 두지 않는 이유는 무엇인가?

1-3. 오케스트레이터가 하위 에이전트에게 일을 맡길 때 위임 지시에 넣어야 할 네 가지 요소를 들고, 하나가 빠지면 생기는 증상을 하나 설명하라.

1-4. 평가자-최적화 루프가 비용을 무한히 쓰지 않게 하려고 루프 바깥의 코드가 가져야 할 장치 두 가지는 무엇인가?

1-5. handoff와 agent-as-tool은 대화 제어권과 최종 답을 내는 주체가 어떻게 다른가?

1-6. Anthropic의 BrowseComp 분석에서 성능 분산 대부분을 토큰 사용량이 설명했다는 관찰은, 도입 판단에서 총비용 대신 무엇을 비교하게 만드는가?

1-7. 매주 사내 공지 50건을 읽고 부서별 요약을 보내는 기능을 설계하라. 가장 단순한 구조, 그 구조가 부족해졌다는 측정 신호, 그때 올라갈 다음 구조를 차례로 적는다.

실습 과제