Gemini CLI 서브에이전트 운영법: 긴 작업을 병렬로 나누고 품질까지 지키는 방법

Gemini CLI 서브에이전트는 긴 작업을 한 번에 밀어붙이는 대신, 병렬로 분해하고 검증 가능한 단위로 다시 묶는 운영 방식에 가깝습니다. Google Developers Blog의 공식 글 https://developers.googleblog.com/en/subagents-have-arrived-in-gemini-cli/ 를 보면 핵심은 단순한 멀티태스킹이 아닙니다. 큰 작업을 더 빨리 처리하는 것보다, 문맥 손실과 작업 충돌을 줄이고 결과 품질을 안정화하는 데 초점이 있습니다. 이 관점으로 보면 서브에이전트는 “속도 옵션”이 아니라 “긴 작업을 망치지 않게 만드는 구조”입니다.

왜 단일 에이전트 방식이 긴 작업에서 자주 무너지는가

한 에이전트에게 리서치, 구현, 테스트, 문서화, 리뷰까지 모두 맡기면 처음에는 편해 보입니다. 하지만 실제로는 세 가지 문제가 반복됩니다. 첫째, 맥락이 길어질수록 초반 제약을 잊어버립니다. 둘째, 서로 다른 역할의 판단 기준이 섞입니다. 예를 들어 구현 모드와 리뷰 모드가 충돌합니다. 셋째, 작업이 길어질수록 “얼추 끝난 것처럼 보이는 조기 종료”가 늘어납니다.

서브에이전트 구조는 이 문제를 분리로 해결합니다. 리서치 담당, 구현 담당, 테스트 담당처럼 하위 작업을 역할별로 나누면 각 에이전트는 짧은 문맥에서 더 명확한 목표를 갖고 움직일 수 있습니다. 결국 성능 향상의 상당 부분은 모델 지능보다 작업 설계에서 나옵니다.

어떤 작업을 서브에이전트로 쪼개야 하나

모든 일을 나누면 오히려 느려집니다. 아래 조건에 맞을 때 효과가 큽니다.

1) 독립적으로 진행 가능한 하위 작업이 있는가

예를 들어 “신규 API 연동”은 공식 문서 조사, 샘플 코드 작성, 에러 케이스 정리, 테스트 시나리오 작성으로 나눌 수 있습니다. 서로 산출물이 다르기 때문에 병렬화 가치가 있습니다.

2) 결과를 비교하거나 교차 검증할 수 있는가

한 명은 구현하고 다른 한 명은 리뷰만 하게 만들면 품질이 좋아집니다. 특히 보안 체크, 비용 계산, 회귀 테스트처럼 실패 비용이 큰 작업에서 유용합니다.

3) 공통 문맥을 최소화할 수 있는가

서브에이전트가 모두 같은 거대한 코드베이스 전체를 읽어야 한다면 이득이 줄어듭니다. 대신 범위를 파일 단위, 기능 단위, 문서 묶음 단위로 잘라야 합니다.

실전 운영 패턴 3가지

패턴 1) 리서치-실행 분리

첫 번째 에이전트는 공식 문서, 변경 이력, 제한사항만 정리합니다. 두 번째 에이전트는 그 결과를 받아 실제 구현을 합니다. 이렇게 하면 구현 에이전트가 검색에 시간을 쓰지 않고 결정된 사실만 기반으로 움직일 수 있습니다.

패턴 2) 구현-검증 이중화

한 에이전트가 코드를 만들고, 다른 에이전트가 테스트 시나리오와 실패 가능성을 찾습니다. 이 구조는 “잘 되는 데모”와 “운영 가능한 결과물”의 차이를 크게 줄여줍니다.

패턴 3) 대안 비교형 실행

같은 문제를 두 에이전트가 서로 다른 전략으로 풀게 한 뒤 비교합니다. 예를 들어 하나는 최소 수정, 다른 하나는 구조 개선 중심으로 구현합니다. 사람이 마지막에 선택하면 의사결정 속도가 빨라집니다.

많이 하는 실수와 방지 방법

실수 1) 역할이 아니라 작업량만 나눈다

“너는 앞부분, 너는 뒷부분” 식 분할은 충돌을 부릅니다. 역할과 산출물이 명확해야 합니다. 예를 들어 “공식 문서 기반 제약 정리”, “API 래퍼 구현”, “회귀 테스트 설계”처럼 쪼개야 합니다.

실수 2) 부모 에이전트가 중간 기준 없이 위임한다

서브에이전트에게 일을 던질 때는 완료 조건이 있어야 합니다. 어떤 파일을 수정할지, 무엇을 증명해야 하는지, 어떤 형식으로 결과를 돌려줄지 정해줘야 병렬화가 이득이 됩니다.

실수 3) 병렬화만 하고 병합 규칙이 없다

여러 결과가 돌아왔을 때 누가 최종 판단을 하는지 없으면 다시 혼란이 생깁니다. 부모 에이전트나 사람이 병합 기준을 가져야 합니다. 일반적으로는 정확성, 수정 범위, 테스트 통과 여부, 유지보수성을 기준으로 삼으면 됩니다.

실수 4) 긴급한 외부 액션까지 자동 위임한다

배포, 고객 메시지 발송, 권한 변경 같은 액션은 서브에이전트가 제안하더라도 승인 단계를 둬야 합니다. 병렬화가 빨라질수록 사고도 빨라질 수 있습니다.

실제로 생산성이 오르는 업무 예시

Gemini CLI 서브에이전트 방식은 아래 같은 작업에서 특히 강합니다.

• 기능 개발 전에 공식 문서·변경 이력·제약 조건을 빠르게 정리해야 하는 경우
• 대규모 리팩터링 전 영향 범위를 병렬로 조사해야 하는 경우
• 테스트, 문서화, 코드 리뷰를 구현과 동시에 진행하고 싶은 경우
• 여러 후보안을 동시에 만들어 비교하고 싶은 경우
• 긴 리서치 작업과 짧은 구현 작업이 섞여 있는 경우

반대로 아주 작은 수정, 단일 파일 변경, 선택지가 거의 없는 단순 작업은 서브에이전트 오버헤드가 더 큽니다.

실무 적용 순서

처음부터 복잡하게 갈 필요는 없습니다. 가장 쉬운 시작은 한 작업을 세 갈래로 나누는 겁니다. 예를 들어 1) 사실 조사, 2) 구현, 3) 검증입니다. 각 에이전트에 동일한 긴 배경 설명을 주지 말고, 자기 역할에 필요한 최소 문맥만 줍니다. 그리고 결과는 반드시 표준 형식으로 받으세요. 예를 들면 “핵심 결론 3개, 근거, 위험, 다음 액션” 형태가 좋습니다.

이렇게 하면 병렬화의 장점이 생깁니다. 각 에이전트가 짧은 문맥에서 더 정확하게 움직이고, 부모 에이전트는 전체 조정과 의사결정에 집중할 수 있습니다. 결국 서브에이전트 운영의 본질은 더 많은 AI를 동시에 돌리는 것이 아니라, 긴 작업을 관리 가능한 시스템으로 바꾸는 데 있습니다.

실행 체크리스트

• 현재 작업이 리서치·구현·검증처럼 독립 하위 작업으로 나뉘는가
• 각 서브에이전트에 역할, 입력, 완료 조건, 출력 형식을 명확히 줬는가
• 동일한 큰 문맥을 모두에게 복사하지 않고 최소 문맥만 전달했는가
• 결과 병합 기준을 정확성, 수정 범위, 테스트 통과 여부로 정했는가
• 배포·권한 변경·외부 발신 같은 고위험 액션에 승인 단계를 남겼는가
• 작은 작업까지 무조건 병렬화하지 않고 오버헤드를 비교했는가