서브에이전트란 무엇인가: 큰 작업을 병렬로 맡기는 실전 기준

서브에이전트는 “작은 담당자”를 따로 세우는 방식

서브에이전트는 메인 대화가 모든 일을 직접 처리하지 않고, 독립적인 하위 작업을 별도 에이전트에게 맡기는 방식입니다. 1인 개발자로 비유하면, 내가 제품 오너이자 리드 개발자이고 서브에이전트는 특정 범위만 조사하거나 수정안을 준비하는 임시 담당자에 가깝습니다.

핵심은 “병렬”입니다. 예를 들어 큰 리팩터링을 앞두고 한 에이전트는 인증 흐름을 읽고, 다른 에이전트는 결제 코드를 확인하고, 또 다른 에이전트는 테스트 실패 원인을 조사하게 할 수 있습니다. 메인 대화는 결과를 모아 판단하고 최종 결정을 내립니다.

다만 서브에이전트가 많다고 항상 더 좋아지는 것은 아닙니다. 작업 사이 의존성이 크거나, 하나의 맥락을 계속 유지해야 하는 문제라면 오히려 조율 비용이 커질 수 있습니다.

메인 대화와 무엇이 다른가

메인 대화는 제품 목표, 제약, 우선순위, 사용자의 최신 의도를 가장 잘 알고 있는 중심 세션입니다. 반면 서브에이전트는 보통 제한된 범위와 지시를 받아 독립적으로 탐색합니다. 그래서 긴 맥락을 모두 공유하기보다 “이 폴더에서 이 문제만 확인해줘”처럼 좁고 명확한 임무에 잘 맞습니다.

차이는 다음처럼 정리할 수 있습니다.

구분	메인 대화	서브에이전트
역할	방향 결정, 통합 판단	특정 범위 조사·초안·검증
맥락	전체 목표와 대화 흐름 유지	필요한 정보만 제한적으로 사용
장점	일관성, 책임 있는 결정	병렬 탐색, 컨텍스트 절약
약점	큰 탐색에서 느려질 수 있음	결과 통합과 검증이 필요

1인 빌더에게 중요한 점은 “누가 최종 판단을 하는가”입니다. 서브에이전트는 실행력을 보태는 도구이지, 제품 방향을 대신 정하는 존재로 두면 위험합니다.

언제 작업을 쪼개면 좋은가

서브에이전트가 잘 맞는 작업은 서로 독립적이고, 결과를 합쳐도 충돌이 적은 일입니다. 특히 코드베이스가 커졌거나, 변경 전에 넓은 조사가 필요한 경우 유용합니다.

좋은 후보는 다음과 같습니다.

서로 다른 폴더나 모듈을 조사하는 작업
API, UI, 데이터베이스처럼 경계가 분명한 영역별 점검
테스트 실패 원인을 여러 가능성으로 나누어 확인하는 일
경쟁 제품, 문서, 라이브러리 사용법처럼 병렬 리서치가 가능한 일
큰 문서를 요약하되 섹션별로 나누어 읽는 일

예를 들어 “알림 기능을 고쳐줘”는 아직 너무 큽니다. 대신 “알림 생성 API”, “알림 목록 UI”, “읽음 처리 상태”, “테스트 커버리지”로 나누면 각 서브에이전트가 독립적으로 볼 수 있습니다. 메인 대화는 각 결과를 비교해 실제 수정 범위를 정하면 됩니다.

한 세션에서 처리하는 편이 나은 경우

반대로 작업이 강하게 이어져 있으면 한 세션에서 밀고 가는 편이 낫습니다. 예를 들어 한 파일 안에서 상태 관리 구조를 바꾸고, 그에 맞춰 UI 분기까지 조정해야 한다면 중간 판단이 계속 필요합니다. 이런 작업을 너무 잘게 나누면 서로 다른 가정이 섞일 수 있습니다.

다음에 해당하면 서브에이전트 사용을 줄이는 편이 보통 낫습니다.

변경 범위가 작고 파일 몇 개 안에서 끝나는 경우
사용자 의도나 제품 정책 판단이 계속 필요한 경우
여러 작업이 같은 코드 줄을 수정할 가능성이 높은 경우
데이터 마이그레이션처럼 순서와 검증이 중요한 경우
“왜 이렇게 해야 하는지”를 계속 토론해야 하는 설계 작업

서브에이전트는 속도를 올리지만, 일관성을 자동으로 보장하지는 않습니다. 그래서 결과물을 바로 믿기보다 “근거, 파일 위치, 남은 불확실성”까지 함께 받아야 합니다.

실전 프롬프트 구조

서브에이전트에게 일을 맡길 때는 넓은 부탁보다 좁은 산출물이 좋습니다. 다음 구조를 쓰면 결과가 다루기 쉬워집니다.

목표: 결제 실패 원인을 찾는다.
범위: app/api/billing, lib/stripe 관련 파일만 본다.
하지 말 것: 코드 수정은 하지 말고 조사만 한다.
산출물: 의심 지점 3개 이하, 파일 경로, 확인 근거, 다음 액션.

특히 “하지 말 것”이 중요합니다. 조사만 필요한데 수정까지 해버리면 메인 흐름에서 충돌이 생길 수 있습니다. 반대로 명확한 작은 버그라면 “테스트 추가 후 수정안 제시”까지 맡길 수 있습니다.

1인 빌더를 위한 판단 기준

서브에이전트를 쓸지 말지는 작업 크기보다 “분리 가능성”으로 판단하는 편이 좋습니다.

체크리스트는 간단합니다.

하위 작업끼리 같은 파일을 많이 건드리지 않는가?
각 작업의 성공 기준을 한 문장으로 말할 수 있는가?
결과를 표나 목록으로 합쳐 비교할 수 있는가?
틀려도 메인 대화에서 검증할 시간이 있는가?
속도 이득이 조율 비용보다 큰가?

대체로 0→1 단계에서는 “구현을 여러 명에게 동시에 맡기기”보다 “조사와 검증을 병렬화하기”가 더 안정적입니다. 제품 방향은 좁고 빠르게 유지하되, 막히는 지점에서만 서브에이전트를 꺼내 쓰는 식입니다.

마무리: 병렬화보다 중요한 것은 분해 능력

서브에이전트의 가치는 에이전트 수가 아니라 작업을 잘 나누는 능력에서 나옵니다. 좋은 분해는 각 담당자가 독립적으로 움직일 수 있게 만들고, 나쁜 분해는 결과를 다시 해석하느라 시간을 잃게 만듭니다.

처음에는 “조사 2개 + 메인 통합 1개” 정도로 작게 시작해보세요. 예를 들어 버그 하나를 두고 프론트 흐름과 서버 로그를 따로 보게 한 뒤, 메인 대화에서 공통 원인을 판단하는 방식입니다. 익숙해지면 기능 단위 감사, 릴리즈 전 점검, 리팩터링 사전 조사처럼 더 큰 작업에도 적용할 수 있습니다.

이 글의 목차