오늘 끝나면
멀티 에이전트
- ✓멀티 에이전트의 핵심 문제를 한 문장으로 설명한다
- ✓오른쪽 실습에서 멀티이 어떻게 움직이는지 관찰한다
- ✓다음 강의와 이어지는 한계를 말할 수 있다
실습 미션
작업을 쪼개 서브에이전트로 팬아웃 이 문장이 실제로 무슨 뜻인지 실습에서 한 번 손으로 확인한다.
성공 조건
- □실습의 기본값을 먼저 관찰
- □입력값이나 모드를 한 번 이상 바꿔 결과 비교
- □왜 결과가 바뀌었는지 한 문장으로 설명
바이브코딩 · 08
멀티
에이전트
큰 작업은 한 에이전트가 혼자 다 짊어지면 느림.
쪼개서 여러 서브에이전트에 팬아웃하고 병렬로 굴림.
각자 좁은 책임만 지고, 오케스트레이터가 합침.
한 에이전트의 한계
에이전트 하나는 결국 LLM + 도구 루프임. 한 번에 들고 갈 수 있는 컨텍스트가 정해져 있음.
파일 40개를 한꺼번에 고치라 시키면 한 루프 안에서 다 머금어야 함.
컨텍스트가 차오를수록 앞 내용을 잊고, 길어질수록 흐트러짐.
그래서 큰 작업은 통째로 던지지 않음.
작은 단위로 쪼개 각각을 다른 에이전트에 맡기는 게 멀티 에이전트의 출발점임.
핵심은 분할 — 한 에이전트가 보는 범위를 일부러 좁힘.
파일이 많을수록 한 창에 안 들어감.
그래서 쪼개서 나눠 맡김.
작업을 쪼갠다
멀티 에이전트의 절반은 잘 쪼개는 데 있음. 막 나누는 게 아니라 책임선으로 가름.
“전체 테스트 통과시켜”를 그대로 던지지 않음.
모듈 A 고치기 · 모듈 B 고치기 · 문서 갱신 — 겹치지 않는 조각으로 나눔.
좋은 분할은 조각끼리 서로 안 건드림.
각 조각이 좁은 책임 하나만 지면, 그 안의 컨텍스트도 작아져서 에이전트가 또렷하게 일함.
조각이 서로 얽히면 병렬로 못 돌리고 충돌만 남음.
조각끼리 안 겹쳐야 병렬로 돌아감
팬아웃과 병렬
쪼갠 조각을 여러 서브에이전트에 한꺼번에 뿌리는 걸 팬아웃이라 함. 오른쪽에서 직접 돌려봄.
서브에이전트 수를 늘리면 작업이 더 잘게 갈라짐.
각자 자기 조각만 동시에 처리함 — 직렬로 한 줄 세우는 게 아니라 병렬임.
그래서 전체 걸리는 시간은 조각들의 합이 아니라 가장 느린 조각임.
에이전트를 늘릴수록 율속이 짧아지지만, 끝에 합치는 비용이 붙음.
무한히 빨라지진 않고 가장 무거운 조각에서 멈춤.
청크 분배 8·8·8 → 율속은 8t, 합치기 2t.
오케스트레이션
서브에이전트들을 누가 부리나? 오케스트레이터라는 상위 에이전트가 조율함.
오케스트레이터는 직접 코드를 짜기보다 지시·취합을 맡음.
작업을 쪼개 뿌리고(팬아웃) · 각 결과를 기다리고 · 하나로 합침(머지).
서브에이전트는 자기 조각의 결과만 위로 올림 — 중간 과정을 다 올리지 않음.
그래서 오케스트레이터의 컨텍스트는 깨끗하게 유지됨.
이 구조 덕에 좁은 책임을 여럿 두고도 전체 그림이 한 곳에서 모임.
범위와 속도를 넓힌다
멀티 에이전트를 쓰는 이유는 둘임. 속도 · 범위.
속도 — 병렬이라 같은 일을 더 빨리 끝냄.
범위 — 한 컨텍스트엔 안 들어갈 큰 작업을 조각으로 나눠 통째로 다룸.
단, 공짜가 아님. 쪼개는 설계 · 합치는 비용 · 조각 간 충돌 관리가 따라옴.
그래서 작고 독립적인 작업일수록 멀티 에이전트가 잘 먹힘.
다음 강(9강)에선 이렇게 나온 결과를 어떻게 검증하고 디버깅하는지 다룸.
Q. 멀티 에이전트의 핵심 이점은? (느린 직렬 처리 · 좁은 책임으로 병렬 확장 · 컨텍스트 무제한 · 도구 없이 동작)
정답은 좁은 책임으로 병렬 확장임.큰 작업을 좁은 책임의 조각으로 쪼개 여러 서브에이전트에 팬아웃하고 병렬로 굴림.
그래서 범위와 속도가 동시에 커짐.
컨텍스트가 무제한이 되는 게 아니라, 조각마다 작게 나눠 다루는 게 핵심임.
| 단일 | 멀티 | |
|---|---|---|
| 처리 방식 | 직렬 1개 | 병렬 N개 |
| 속도 | 느림 | 빠름 |
| 범위 | 한 컨텍스트 | 조각 합산 |
| 비용 | 없음 | 쪼갬·머지 |
작고 독립적인 작업일수록 멀티가 잘 먹힘