AI 코딩, 언제 여러 에이전트로 쪼갤까

한 개의 AI에게 "이거 다 해줘" 하고 기다리던 시절은 지나가고 있습니다. 2026년의 바이브코딩은 여러 에이전트를 동시에 부리는 방식으로 무게중심이 옮겨왔어요. 한 에이전트가 감독을 맡고, 여러 하위 에이전트가 각자 다른 화면에서 병렬로 코드를 짠 뒤, 결과를 하나로 합칩니다.

그런데 여기서 초보자가 가장 많이 하는 착각이 있습니다. "쪼개면 무조건 빠르다"는 것. 아닙니다. 잘못 쪼개면 오히려 느려지고 결과가 어긋납니다. 그래서 진짜 실력은 도구를 아는 게 아니라 '언제 쪼갤지'를 아는 데서 갈립니다.

서브에이전트, 왜 지금 뜨나

핵심 개념은 '쪼개서 던지고 합치기(split-and-merge)'입니다. 하나의 큰 작업을 서로 독립적인 하위 작업으로 나눠, 각자 자기만의 컨텍스트 창을 가진 에이전트들에게 병렬로 맡기고, 끝나면 결과를 다시 하나로 병합합니다. 한 터미널 세션 안에서 최대 열 개 안팎의 하위 에이전트로 펼칠 수 있죠. Claude Code의 서브에이전트 문서처럼, 이제는 별도 인프라 없이 개인 개발 환경에서 바로 시작할 수 있게 됐습니다.

왜 이 방식이 힘을 얻었을까요. 모델이 똑똑해질수록 한 번에 다루는 맥락도 커졌지만, 그래도 한 컨텍스트에 모든 걸 욱여넣으면 품질이 떨어집니다. 사람이 열 가지를 동시에 신경 쓰면 실수하듯, AI도 마찬가지예요. 그래서 '하나의 거대한 두뇌'보다 '역할이 나뉜 여러 작은 두뇌'가 더 정확한 결과를 내는 구간이 생깁니다.

언제 쪼개고, 언제 순차로 갈까

판단의 뼈대는 딱 하나입니다. 작업들이 서로 독립적인가, 아니면 앞의 결과에 뒤가 매달려 있는가.

서브에이전트는 서로의 컨텍스트를 보지 못합니다. 그래서 결합된 작업을 억지로 쪼개면, 각자 다른 가정 위에서 코드를 짜다가 병합 단계에서 충돌합니다. "빠르게 하려다 병합 지옥"이 초보자의 흔한 함정이에요.

실제로 해보니: 12편 교재의 경험

우리도 이 원칙을 콘텐츠 작업에 그대로 적용해 봤습니다. FastAPI 입문 12편짜리 교재 시리즈를 만들 때, 각 챕터는 주제가 뚜렷이 나뉘어 독립적이었습니다. 그래서 챕터별로 서브에이전트에 병렬 위임했더니, 하나씩 순차로 쓸 때보다 훨씬 빨리 초안이 쌓였죠.

하지만 전부를 병렬로 두지는 않았습니다. 챕터 사이의 용어 통일·난이도 상승 곡선·앞 챕터 참조는 명백히 '연속성'이 필요한 작업이라, 이 부분만은 메인에서 순차로 다듬었습니다. 결론은 교과서 그대로였어요. 독립적인 몸통은 병렬로, 연결되는 흐름은 순차로. 이 경계를 지켰을 때만 병렬화가 실제로 이득이었습니다.

초보자를 위한 판단 체크리스트

새 작업 앞에서 이 세 질문만 던지면 됩니다. 첫째, 이 일을 서로 모르는 사람 셋에게 나눠 줘도 각자 끝낼 수 있는가. 둘째, 각 조각이 한 사람(한 컨텍스트)이 감당하기엔 너무 큰가. 셋째, 마지막에 합칠 때 서로 어긋날 위험이 적은가. 세 개 다 '예'면 쪼개세요. 하나라도 '아니오'면 순차가 안전합니다.

여러 에이전트를 부리는 능력은 분명 강력합니다. 하지만 그 힘은 '많이 벌리는' 데서 나오지 않고 '제대로 나누는' 데서 나옵니다. 오늘 작업을 시작하기 전에, 코드를 짜기보다 먼저 종이에 작업을 나눠 보세요. 잘 그은 경계선 하나가, 열 개의 에이전트보다 낫습니다.