레슨 1: 하나의 루프로는 부족할 때

학습 목표:

• 단일 루프 에이전트를 무너뜨리는 실제 작업을 써서, '더 큰 윈도를 쓰면 된다'가 형태의 문제를 풀지 못하는 이유 보이기
• 워크플로와 에이전트의 아키텍처적 구분을 진술하고, '누가 계획을 쥐고 있는가'로 임의의 시스템을 그 축 위에 놓기
• 위로 올라갈 트리거와 그대로 머물 조건을 열거하되, 레이턴시와 토큰 비용을 먼저 테이블에 올리기

전제: 이 시리즈의 앞선 11개 코스를 마쳤고, stop_reason이 모는 하네스 루프를 손으로 쓸 수 있어야 합니다(코스 7 '에이전트 하네스 기초: 루프와 통제') | 다음: 레슨 2 >>

모듈 30에 이르면, 뭔가 잘못됩니다

백엔드 리포지토리를 사내 RPC 프레임워크 v1에서 v2로 마이그레이션해야 합니다. 착수하기 전에 인벤토리가 필요합니다. 리포지토리에는 모듈이 40개 있고, 모듈마다 마이그레이션 평가가 있어야 합니다 — 위험 지점을 열거하고, 변경 범위를 추산하고, 의존성 매니페스트를 붙이는 일입니다. 어려운 작업은 아닙니다, 그저 수가 많을 뿐입니다. 손에는 이 시리즈의 코스 7에서 만든 그 하네스가 있습니다:

(하네스란 모델 호출을 감싸는 호스트 쪽 코드입니다. 요청을 보내고, 모델이 쓰고 싶어 한 도구를 실행하고, 결과를 다시 밀어 넣고, 계속할지 말지를 결정합니다.)

40개 모듈 목록을 한꺼번에 건네주고, '하나씩 평가하고, 모듈마다 보고서 하나씩'이라고 써 놓은 뒤, 커피를 내리러 갑니다.

처음 다섯 모듈은 훌륭합니다. 호출 지점을 grep으로 훑고, 설정을 읽고, 테스트 파일을 확인하고, 보고서는 기대했던 것보다 상세합니다.

모듈 15쯤에서 돌아와 로그를 확인합니다. messages 배열은 이미 장관입니다. 앞선 14개 모듈의 grep 출력, 통째로 읽어 들인 설정 파일 덩어리, 파일 쓰기 성공 영수증, 갔다가 버린 경로의 흔적 — 이 모든 것이 아직도 그 하나의 타임라인 위에 얹혀 있습니다. 이 내용 중에 틀린 것은 없었습니다. 각각은 그 시점에 필요했습니다. 그러나 지금의 기능은 하나로 줄어들었습니다. 자리를 차지하는 것.

모듈 30에 이르면 품질이 무너집니다. 이름이 비슷하다는 이유로 모듈 27의 결론을 모듈 30에 복사해 붙이고, 그전까지 매번 하던 '커스텀 인터셉터 확인' 단계를 조용히 건너뛰고, 모듈 34쯤에서는 출력 형식마저 흔들리기 시작합니다.

첫 반응은 아마 이럴 것입니다. 더 큰 컨텍스트 윈도를 가진 모델로 갈아타기.

그 반응은 절반까지만 데려다줍니다. 윈도를 두 배로 키우면 붕괴 지점은 아마 모듈 30에서 55로 옮겨 갑니다. 다음 리포지토리는 모듈이 120개입니다. 문제를 푼 것이 아니라 집행유예를 산 것입니다.

실제로 바닥난 것은 윈도가 아니라 '하나의 루프'라는 형태입니다. 독립적인 40개 항목이 하나의 타임라인, 하나의 주의 예산을 억지로 나눠 쓰고 있습니다. 모듈 30의 평가 품질이 앞선 29개 모듈이 남긴 잔여물의 양에 좌우됩니다 — 이 둘은 서로 아무 상관이 없는데도 말입니다.

이 코스가 하는 일은 그 형태를 갈아 끼우는 것입니다.

공식 용어부터 정리합니다

에이전트는 정교한 작업을 다룰 수 있지만, 그 구현은 대개 단순합니다. 전형적으로는 환경 피드백에 기반해 루프 안에서 도구를 쓰는 LLM일 뿐입니다¹. 이 시리즈의 코스 7에서 쓴 그 while이 바로 그것입니다, 한 줄도 다르지 않습니다. 그러니 자기 위치를 확인해 두세요. 여러분은 이미 에이전트를 만들었고, 이 코스는 0에서 시작하지 않습니다.

한 층 위로. Anthropic은 이 모든 변형을 에이전트 시스템(agentic systems, 평범하게 말하면 모델과 도구와 어떤 형태의 제어 흐름으로 조립되어 스스로 여러 단계를 걸어갈 수 있는 시스템)으로 분류하지만, 이 넓은 범주 안에서 중요한 아키텍처적 구분을 하나 긋습니다¹:

• 워크플로란 LLM과 도구가 미리 정의된 코드 경로를 통해 오케스트레이션되는 시스템입니다¹. '미리 정의된 코드 경로'가 핵심 어구입니다 — 다음에 무슨 일이 일어날지가 코드에 적혀 있습니다.
• 반면 에이전트란 LLM이 자기 프로세스와 도구 사용을 동적으로 방향 지으며, 작업을 어떻게 완수할지에 대한 통제를 계속 쥐고 있는 시스템입니다¹. 다음에 무슨 일이 일어날지는 모델이 그 자리에서 정합니다.

앞으로 몇 레슨에 걸쳐 반복해서 쓸 기초 용어가 하나 더 있습니다. 컴퓨팅에서 결정론적 시스템은 동일한 입력이 주어지면 매번 동일한 출력을 내지만, 비결정론적 시스템은 — 에이전트처럼 — 같은 시작 조건에서도 다양한 응답을 생성할 수 있습니다².

이 정의를 여러분의 while에 대 보면 두 가지가 꿰매어져 있는 것이 보입니다. 요청을 어떻게 보낼지, 도구 호출을 어떻게 실행할지, 언제 멈출지 — 이것들은 결정론적이고, 여러분이 코드로 썼습니다. 한편 '다음에 무엇을 grep할지, 이 보고서를 다 썼는지' — 이것들은 비결정론적이고, 모델이 그 자리에서 정합니다. 앞으로 할 수술은 이 두 절반 사이에서 결정권을 옮기는 일입니다.

'누가 계획을 쥐고 있는가'라는 축

Claude Code의 문서는 이것을 더 직접적으로 묻습니다. 서브에이전트, 스킬, 에이전트 팀, 워크플로는 모두 여러 단계짜리 작업을 실행할 수 있습니다. 차이는 누가 계획을 쥐고 있는가입니다³.

('서브에이전트' = 자기만의 컨텍스트 윈도 안에서 독립적으로 일하고 요약만 돌려주는 어시스턴트. '팬아웃' = 여러 서브에이전트를 동시에 일하게 내보내는 것. 두 용어 모두 이 시리즈의 코스 6에서 다뤘습니다.)

이 한 문장이 비슷해 보이는 여러 접근을 갈라냅니다. '40개 모듈 평가를 실행한다'로 보겠습니다:

• 모델이 하나의 대화 안에서 40개를 전부 진행하게 둡니다 — 계획은 모델의 손에 있고, 게다가 암묵적이며, 대화 이력 속에 숨어 있습니다. 그 의도한 경로를 짐작하려면 로그를 파헤쳐야 합니다.
• 모델을 오케스트레이터로 세우고, 어느 모듈에 어느 서브에이전트를 파견할지 매 턴 모델이 정하게 합니다 — 계획은 여전히 모델의 손에 있고, 다만 조금 더 명시적입니다.
• 스크립트를 하나 씁니다. 그 스크립트가 40개 모듈을 for로 직접 돕니다 — 계획은 코드 안에 있습니다. 파일을 열어 끝까지 읽을 수 있고, 내일 그대로 다시 돌릴 수 있습니다.

세 번째 접근에는 정확한 서술이 있습니다. 워크플로는 계획을 코드로 옮깁니다. 워크플로 스크립트가 루프와 분기와 중간 결과를 직접 쥐고 있으므로, Claude의 컨텍스트에는 최종 답만 남습니다³. 그리고 중간 결과는 Claude의 컨텍스트에 착지하는 대신 스크립트 변수 안에 머뭅니다³. 모듈 27의 grep 출력은 JavaScript 배열 안에 머무르므로, 모듈 30의 평가는 자연히 그것을 볼 수 없습니다 — 모델이 무시하는 법을 배워서가 아니라, 애초에 볼 기회 자체가 없었기 때문입니다.

이 축의 양 끝에 대해, 공식 안내는 각각 적합성에 관한 한 문장씩을 줍니다. 복잡성이 정당화될 때, 워크플로는 잘 정의된 작업에 예측 가능성과 일관성을 제공하는 반면, 유연성과 모델 주도의 의사결정이 규모 있게 필요할 때는 에이전트가 더 나은 선택입니다¹.

한 가지 분명히 해 둘 것: 이 코스는 이 축을 '결정성 스펙트럼'이라 부르고, 레슨 5의 조합 패턴을 '그래프', '노드', '엣지'라고 부릅니다. 이 이름표들은 이 코스가 만든 엔지니어링 은유이며 1차 자료에는 결코 등장하지 않습니다 — 1차 자료가 주는 것은 두 끝점의 정의(미리 정의된 코드 경로 대 모델 주도의 결정)¹와 '누가 계획을 쥐고 있는가'라는 틀³뿐입니다. 스펙트럼과 그래프라는 은유를 빌려 오는 이유는 실제로 존재하는 패턴들을 배열하기에 편해서입니다. 어느 공식 문서에서도 이 용어들을 읽을 수 없으니, 공식 개념인 것처럼 제시하지 마세요.

위로 올라가야 할 때

'하나의 루프로는 부족하다'는 직감처럼 들리지만, 말로 옮길 수 있는 트리거가 있습니다.

트리거 1: 작업에 하나의 대화가 조율할 수 있는 것보다 많은 에이전트가 필요하거나, 오케스트레이션을 읽고 다시 돌릴 수 있는 스크립트로 성문화하고 싶을 때³. 앞 절반은 능력의 문제이고 뒤 절반은 엔지니어링의 문제입니다 — 하나의 대화가 겨우 조율할 수 있다 해도 '내일 똑같이 다시 돌릴 수 있는가'는 그 자체로 이유가 됩니다.

트리거 2: 작업이 하나의 에이전트가 컨텍스트에 담을 수 있는 것보다 클 때, 또는 같은 단계를 많은 항목에 걸쳐 돌려야 할 때³. 이 두 문장을 합치면 첫머리의 40개 모듈 시나리오가 정확히 그려집니다. 두 번째 문장에 주목하세요. 항목 수 자체가 이유이며, 각 항목이 어려운지 아닌지는 상관없습니다.

트리거 3: 곁가지 작업이 메인 대화를 범람시킬 때. 서브에이전트 문서의 상황 서술은 이렇습니다. 곁가지 작업이 다시 참조하지 않을 검색 결과나 로그나 파일 내용으로 메인 대화를 범람시킬 상황이라면 서브에이전트를 파견하세요 — 그 일을 자기 컨텍스트 안에서 하고 요약만 돌려줍니다⁴. 탐색과 구현을 메인 대화 바깥에 둠으로써 컨텍스트를 보존하는 것입니다⁴. 이 트리거가 처방하는 것이 '서브에이전트를 파견하라'라는 데 주목하세요 — 계획은 여전히 모델의 손에 머무르며, 그것과 '계획을 코드로 옮기기'는 서로 다른 두 가지입니다. 레벨 2 연습의 B열과 C열이 이 구분을 펼쳐 보일 것입니다.

형태를 갈아 끼운 뒤가 어떤 모습인지 감을 잡으려면 이 코드를 보세요:

루프는 여전히 그 루프입니다 — runHarnessLoop 안에는 이 시리즈의 코스 7에서 쓴 그 while이 있습니다. 바뀐 것은 하나뿐입니다. 누가 40까지 세는가. 전에는 모델이 셌습니다. 이제는 for가 셉니다.

그대로 머물러야 할 때

트리거 신호 뒤에는 그 반대편의 똑같이 긴 점검 목록이 있고, 이쪽이 건너뛰기 더 쉽습니다.

가능한 한 가장 단순한 해법을 찾고, 필요할 때에만 복잡성을 늘리세요. 이는 에이전트 시스템을 아예 만들지 않는 것을 뜻할 수도 있습니다¹. 다만 많은 애플리케이션에서는 검색과 인컨텍스트 예시로 단일 LLM 호출을 최적화하는 것으로 대개 충분합니다¹. 함수 하나를 12군데에서 이름 바꾸는 그 일에는 하네스도, 오케스트레이션도 필요 없습니다 — 호출 한 번에 grep 한 번이면 끝납니다.

오늘날 일부 도메인은 멀티 에이전트 시스템에 잘 맞지 않습니다. 모든 에이전트가 같은 컨텍스트를 공유해야 하는 도메인, 또는 에이전트 사이의 의존이 많은 도메인입니다. 본문은 예를 하나 들어 놓았습니다 — 대부분의 코딩 작업은 조사보다 진짜로 병렬화 가능한 작업이 적고, LLM 에이전트는 다른 에이전트를 실시간으로 조율하고 위임하는 데 아직 능숙하지 않습니다⁵. 강하게 결합된 주문 모듈을 리팩터링하고 있고 변경이 호출자 사슬을 따라 번져 나간다면, 이것을 서브에이전트 다섯으로 팬아웃하는 것은 더 느리고 더 지저분해지기만 합니다. 모두가 같은 것을 봐야 하는데, 먼저 움직인 쪽이 나머지 모두의 정보를 무효화해 버리기 때문입니다.

거꾸로, 잘 맞는 조건도 그만큼 담백하게 진술되어 있습니다. 그들은 멀티 에이전트 시스템이 무거운 병렬화, 단일 컨텍스트 윈도를 넘어서는 정보, 수많은 복잡한 도구와의 접속을 수반하는 작업에서 뛰어나며⁵, 작업의 가치가 향상된 성능에 값을 치를 만큼 충분히 높은 작업에서 그렇다는 것을 발견했습니다⁵. 이 세 조건에 많이 해당할수록 위로 올라갈 값어치가 커집니다.

자율 루프에 그대로 두어야 하는 작업 부류도 있습니다. 오케스트레이션으로 억지로 밀어 넣을 것이 아닙니다. 필요한 단계 수를 예측하기 어렵거나 불가능하고, 고정 경로를 하드코딩할 수 없는 열린 문제 — 이런 것들은 에이전트에게 줄 수 있고, 에이전트는 잠재적으로 여러 턴 동안 작동할 것이며, 여러분은 그 의사결정을 어느 정도 신뢰해야 합니다¹. Anthropic 자신의 리서치 시스템이 이 유형입니다. 리서치 작업은 필요한 단계를 미리 예측하기가 매우 어려운 열린 문제를 수반합니다. 복잡한 주제를 탐색하는 고정 경로는 하드코딩할 수 없는데, 그 과정이 본질적으로 동적이고 경로 의존적이기 때문입니다⁵.

그러므로 '오케스트레이션으로 옮겨야 하는가'는 한 방향짜리 진행 바가 아닙니다. 40개 모듈 평가는 단계가 고정되어 있고 수만 많으므로 오케스트레이션 쪽으로 옮겨야 하고, '메시지 큐를 A에서 B로 바꿔야 하는가'는 글을 몇 편이나 읽어야 할지조차 모르므로 옮기지 말아야 합니다.

비용을 먼저 테이블에 올립니다

다섯 패턴을 배우기 전에 장부를 펴세요.

에이전트 시스템은 더 나은 작업 성능을 위해 레이턴시와 비용을 맞바꾸는 일이 잦으며, 여러분은 이 맞바꿈이 언제 말이 되는지 따져 봐야 합니다¹. 여기 수사(修辭)는 한 단어도 없습니다. 이것은 교환을 서술하고 있습니다.

얼마나 비쌀까요? Anthropic은 자기 데이터에서 나온 관측 한 벌을 제공합니다. 에이전트는 전형적으로 채팅 상호작용보다 약 4배 많은 토큰을 쓰고, 멀티 에이전트 시스템은 채팅보다 약 15배 많은 토큰을 씁니다⁵. 그래서 그들의 결론은 이렇습니다 — 경제적으로 성립하려면, 멀티 에이전트 시스템은 작업의 가치가 향상된 성능에 값을 치를 만큼 충분히 높은 작업을 필요로 합니다⁵.

이 숫자의 맥락에 주목하세요. 자기 데이터에서 나온 것이지 보편 벤치마크가 아니며, '모든 오케스트레이션 방식이 15배 더 든다'도 아닙니다. 다만 방향은 분명합니다. '에이전트를 더, 병렬을 더' 쪽으로 한 걸음 갈 때마다 청구서는 한 단 올라섭니다. 경계를 재빨리 그어 두면, 이 배수는 멀티 에이전트 시스템을 채팅에 견준 것이지 '계획을 코드로 옮기기' 자체의 가격표가 아닙니다 — 1차 자료는 오케스트레이션 스크립트의 독립적인 비용 수치를 준 적이 없습니다. 40개 모듈은 위로 올라갈 값어치가 있는데 12번의 이름 바꾸기는 그렇지 않은 이유도 이것입니다. 하나가 '복잡'하고 다른 하나가 '단순'해서가 아니라, 재작업 2주를 아껴 주는 마이그레이션 평가는 이 비용을 감당할 수 있기 때문입니다.

앞으로의 다섯 레슨

이 코스의 나머지는 가장 가벼운 형태에서 시작해 조합으로 쌓아 올립니다:

• 레슨 2: 체이닝과 라우팅: 작업을 고정된 단계로 쪼개고 단계 사이마다 프로그램적 관문을 두기, 분류한 뒤 전문화된 프롬프트로 넘기기. '계획을 코드로'의 가장 가벼운 형태입니다.
• 레슨 3: 병렬화: 섹셔닝(독립적인 하위 작업으로 쪼개 병렬로 실행)과 투표(같은 작업을 여러 번 돌려 다양한 출력 얻기), 그리고 결과를 코드로 집계하는 법.
• 레슨 4: 오케스트레이터-워커: 중앙 LLM이 작업을 동적으로 분해하고, 워커 LLM에게 위임하고, 그 결과를 종합합니다. 핵심 차이는 하위 작업이 미리 정의되지 않는다는 것입니다.
• 레슨 5: 평가 루프, 그리고 패턴을 그래프로 조합하기: 통과하거나 더 이상 진전이 없을 때까지 점검-수정-재점검하고, 그다음 앞선 패턴들을 이어 붙입니다. 그 레슨에서 다시 밝힙니다. '그래프'는 이 코스가 만든 시각화입니다.
• 레슨 6: 실습: 이 시리즈의 코스 7에서 만든 그 단일 루프 하네스를 결정론적 오케스트레이션 스크립트로 끌어올립니다.

이 패턴 분류법은 2024년의 유물이 아닙니다. 현행 Claude 플랫폼의 멀티 에이전트 오케스트레이션 문서는 여전히 **병렬화(독립적인 하위 작업을 동시에 팬아웃하고, 코디네이터가 결과를 종합), 전문화(도메인에 집중한 시스템 프롬프트와 도구를 가진 에이전트로 라우팅), 에스컬레이션(복잡한 하위 작업의 일부에 대해 더 유능한 에이전트나 모델에 자문)**을 독립적으로 이름 지어 부릅니다⁶. 껍데기가 바뀌었을 뿐, 골격은 같습니다.

이 코스가 앞선 두 코스와 어떻게 갈라지는지에 대해 한 가지 더. 이 시리즈의 코스 2는 워크플로의 개념을 가르쳤습니다 — 단계, 상태, 분기, 도식 수준의 이해. 이 시리즈의 코스 6은 멀티 에이전트 협업의 분업과 소통을 가르쳤습니다 — 팬아웃, 위임 프롬프트가 자기완결적이어야 한다는 것, 프로듀서-리뷰어. 이 코스는 둘 중 어느 것도 다시 가르치지 않습니다. 다루는 것은 제어 흐름 그 자체입니다. 누가 세는가, 누가 분기하는가, 중간 결과는 어디로 가는가, 무너지면 무슨 일이 일어나는가. 용어를 재빨리 이어 주자면, 이 시리즈의 코스 6이 '프로듀서-리뷰어'라 부른 것을 1차 자료는 이밸류에이터-옵티마이저라 부르고¹, Claude Code의 워크플로 문서는 독립적인 에이전트들이 서로의 발견을 적대적으로 리뷰하게 하는 것이라 부릅니다³.

비례성: 모든 것은 '측정 가능한 개선'을 통과해야 합니다

이 코스는 다섯 패턴과 여러 조합 방법을 가르칩니다. 그것들은 모두 하나의 자인(自認)을 공유하고, 원문은 모호하지 않습니다. 이 구성 요소들은 규범이 아닙니다. 개발자가 서로 다른 사용 사례에 맞게 다듬고 조합할 수 있는 흔한 패턴입니다. 성공의 열쇠는 다른 어떤 LLM 기능과도 마찬가지로 성능을 측정하고 구현을 반복하는 것입니다. 다시 말하지만, 복잡성을 더하는 것은 그것이 결과를 명백히 개선할 때에만 고려해야 합니다¹.

'결과를 명백히 개선한다'에는 구체적인 뒷받침이 필요하고, 그것은 이 시리즈 코스 10의 평가와 코스 11의 관측 가능성에서 옵니다. 평가 세트가 없으면 '라우팅을 더해서 정말 나아졌는가'를 분명히 말할 수 없습니다. 그 규범적 텍스트의 결말은 이 순서를 따릅니다. 단순한 프롬프트에서 시작하고, 포괄적인 평가로 그것을 최적화하고, 더 단순한 해법이 부족할 때에만 여러 단계의 에이전트 시스템을 더하세요¹.

그러니 패턴을 하나씩 배운 뒤에는 스스로 물어보세요. 이것을 더한 뒤에 결과가 좋아졌음을 보이는 숫자를 내놓을 수 있는가? 못 내놓겠다면, 아직 더하지 마세요.

💻 연습

정리

• 이 시리즈의 코스 7에서 쓴 그 while이 에이전트다. 에이전트는 정교한 작업을 다룰 수 있지만 그 구현은 대개 단순하고, 전형적으로는 환경 피드백에 기반해 루프 안에서 도구를 쓰는 LLM일 뿐이다¹
• 이 변형들을 통틀어 에이전트 시스템이라 부르며, 그 안에서 아키텍처적 구분이 하나 그어진다. 워크플로는 LLM과 도구가 미리 정의된 코드 경로를 통해 오케스트레이션되는 시스템이고, 에이전트는 LLM이 자기 프로세스와 도구 사용을 동적으로 방향 지으며 작업을 어떻게 완수할지에 대한 통제를 쥐고 있는 시스템이다¹
• 둘을 가르는 축은 '누가 계획을 쥐고 있는가'다. 워크플로는 계획을 코드로 옮기고, 스크립트 자신이 루프와 분기와 중간 결과를 쥐고 있으므로 Claude의 컨텍스트에는 최종 답만 남는다³. 이 코스는 이 축을 '결정성 스펙트럼'이라 부르고 레슨 5의 조합 시각화를 '그래프'라 부르는데, 두 용어 모두 이 코스의 은유이며 1차 자료에는 나오지 않는다
• 위로 올라갈 트리거: 작업에 하나의 대화가 조율할 수 있는 것보다 많은 에이전트가 필요하거나 오케스트레이션을 읽고 다시 돌릴 수 있는 스크립트로 성문화하고 싶을 때³, 작업이 하나의 에이전트가 컨텍스트에 담을 수 있는 것보다 클 때 또는 같은 단계를 많은 항목에 걸쳐 돌려야 할 때³, 곁가지 작업이 다시 참조하지 않을 내용으로 메인 대화를 범람시킬 때⁴
• 그대로 머물 조건: 가능한 한 가장 단순한 해법을 찾고 필요할 때에만 복잡성을 더하며, 이는 에이전트 시스템을 아예 만들지 않는 것을 뜻할 수도 있다¹. 많은 애플리케이션에서는 검색과 인컨텍스트 예시로 단일 LLM 호출을 최적화하는 것으로 대개 충분하다¹. 공유 컨텍스트를 요구하거나 에이전트 간 의존이 많은 도메인은 오늘날 멀티 에이전트에 잘 맞지 않으며, 대부분의 코딩 작업은 조사보다 진짜로 병렬화 가능한 작업이 적다⁵
• 자율 루프에 그대로 둘 것: 열린 문제, 단계 수를 예측하기 어려움, 고정 경로를 하드코딩할 수 없음¹ — 조사류 작업이 전형적이고, 그 과정은 본질적으로 동적이고 경로 의존적이다⁵
• 청구서를 먼저 받아 볼 것: 에이전트 시스템은 더 나은 작업 성능을 위해 레이턴시와 비용을 맞바꾸는 일이 잦다¹. 그들 자신의 데이터에서 에이전트는 채팅보다 약 4배, 멀티 에이전트는 약 15배의 토큰을 쓰며, 경제적으로 성립하려면 작업의 가치가 그 향상을 감당해야 한다⁵
• 이 코스가 가르치는 모든 것은 같은 관문을 통과해야 한다. 복잡성은 결과를 명백히 개선할 때에만 더한다¹. 단순한 프롬프트에서 시작하고, 포괄적인 평가로 최적화하고, 더 단순한 해법이 부족할 때에만 여러 단계의 에이전트 시스템을 더한다¹

>> 레슨 2: 이어 붙이고, 갈라 보내기: 체이닝과 라우팅

Footnotes

1. Building Effective AI Agents — Anthropic Engineering — https://www.anthropic.com/engineering/building-effective-agents ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶ ↩¹⁷ ↩¹⁸ ↩¹⁹ ↩²⁰ ↩²¹

2. Writing effective tools for agents — with agents — Anthropic Engineering — https://www.anthropic.com/engineering/writing-tools-for-agents ↩

3. Orchestrate subagents at scale with dynamic workflows — Claude Code official documentation — https://code.claude.com/docs/en/workflows ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰

4. Create custom subagents — Claude Code official documentation — https://code.claude.com/docs/en/sub-agents ↩ ↩² ↩³

5. How we built our multi-agent research system — Anthropic Engineering — https://www.anthropic.com/engineering/multi-agent-research-system ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹

6. Multiagent orchestration — Claude API documentation (Managed Agents) — https://platform.claude.com/docs/en/managed-agents/multiagent-orchestration ↩