3 개의 포스트
Dalia는 GitHub의 Copilot Agent Control Plane 팀에서 소프트웨어 엔지니어로 일하고 있습니다. 주요 업무는 Copilot 고객을 위한 서브에이전트 거버넌스 계층을 구축하는 것입니다. ### 소속과 역할 - GitHub의 **Copilot Agent Control Plane 팀**에서 근무합니다. - 소프트웨어 엔지니어로서 Copilot 관련 인프라와 기능을 개발합니다. ### 담당 분야 - Copilot 고객이 사용하는 **서브에이전트(subagent)** 를 관리하고 통제하는 거버넌스 계층을 구축합니다. - 제공된 내용만으로는 해당 시스템의 구체적인 설계, 기능, 운영 방식은 확인할 수 없습니다.
GitHub는 Copilot CLI가 단순한 작업까지 불필요하게 서브에이전트에 위임해 발생하던 검색 반복, 도구 실패, 대기 시간을 줄이기 위해 위임 정책을 개선했다. 핵심은 좁고 명확한 작업은 메인 에이전트가 직접 처리하고, 독립적인 탐색·복잡한 조사·병렬 실행이 필요한 경우에만 서브에이전트를 활용하는 것이다. 그 결과 도구 실패가 23% 감소하고 P95 사용자 대기 시간이 5% 줄었으며, 품질 저하 없이 Copilot CLI 전체 트래픽에 적용됐다. ### 서브에이전트 위임은 항상 효율적이지 않다 - 서브에이전트는 복잡한 작업을 분해하고 여러 조사를 병렬로 수행하는 데 유용하다. - 하지만 단순한 파일 수정까지 위임하면 오히려 다음과 같은 비용이 발생한다. - 불필요한 에이전트 간 인계와 조정 - 동일하거나 겹치는 저장소 검색 - 메인 에이전트가 결과를 기다리는 시간 - 오래된 파일 경로, 잘못된 상대 경로, 워크스페이스 불일치에 따른 도구 실패 - 특히 메인 에이전트가 이미 충분한 맥락을 알고 있는데도 탐색 서브에이전트를 실행하면, 서브에이전트가 저장소를 다시 검색하면서 작업이 지연된다. ### 데이터 분석으로 불필요한 위임 패턴 식별 - GitHub는 에이전트의 전체 실행 궤적을 LLM으로 분석해 위임이 실제로 도움이 되는지 확인했다. - 분석 결과, 다음과 같은 작업에 서브에이전트가 과도하게 사용되고 있었다. - 범위가 좁고 명확한 작업 - 필요한 정보가 이미 핸드오프에 포함된 작업 - 파일을 찾고 읽은 뒤 한 곳을 수정하는 작업 - 이를 바탕으로 “간단한 탐색과 수정은 메인 에이전트가 직접 처리한다”는 방향을 개선 목표로 삼았다. ### 좁은 작업은 직접 처리하고 복잡할 때만 위임 - Copilot CLI의 새로운 정책은 가장 간단한 실행 경로에서 시작한다. - 파일 찾기 - 파일 읽기 - 특정 부분 수정 - 변경 사항 검증 - 다음과 같은 경우에는 서브에이전트 위임이 효과적이다. - 익숙하지 않은 대규모 저장소 탐색 - 서로 독립적인 코드 영역 조사 - 장시간 실행되는 명령 수행 - 여러 작업을 동시에 진행할 수 있는 경우 - 작업이 복잡하거나 불확실할 때 위임하고, 다시 작업 범위가 좁아지면 메인 에이전트가 직접 처리하도록 한다. - 서브에이전트는 메인 에이전트를 멈추게 하는 “일시정지 버튼”이 아니라, 독립 작업을 병렬화하는 도구로 사용해야 한다. ### 구체적인 핸드오프와 병렬 실행 - 서브에이전트를 실행할 때는 핸드오프에 다음 내용을 명확히 포함해야 한다. - 사용자가 요청한 전체 목표 - 메인 에이전트가 이미 파악한 정보 - 서브에이전트가 담당할 범위 - 반환해야 하는 결과의 형태 - 메인 에이전트는 서브에이전트의 결과를 기다리기만 하지 않고, 그동안 독립적으로 수행할 수 있는 작업을 계속 진행해야 한다. - 이 방식은 중복 검색과 순차적 대기를 줄이고, 실제로 병렬 처리가 가능한 작업에서 위임의 이점을 높인다. ### 오프라인 평가와 운영 환경 A/B 테스트 - GitHub는 자동 생성 회귀 테스트와 기존 벤치마크를 이용해 정책 변경을 먼저 오프라인에서 검증했다. - 이후 내부 사용자와 공개 사용자를 대상으로 A/B 테스트를 진행했다. - 평가 항목은 다음과 같았다. - 도구 안정성 - 사용자 응답성과 대기 시간 - 서브에이전트 사용량 - 최종 결과 품질 - 성능 향상은 개별 LLM 호출 자체를 빠르게 만든 결과가 아니라, 불필요한 서브에이전트 실행을 줄여 오케스트레이션 비용을 낮춘 결과였다. ### 측정된 개선 효과 - 세션당 도구 실패가 **23% 감소** - 검색 도구 실패: **27% 감소** - 편집 도구 실패: **18% 감소** - 사용자 대기 시간 개선 - P95: **5% 감소** - P75: **3% 감소** - 품질 저하는 관찰되지 않았다. - 개선된 위임 기능은 Copilot CLI 운영 트래픽의 100%에 배포됐다. - 사용자는 `/update` 명령으로 Copilot CLI **1.0.42 이상**으로 업데이트하면 적용된 기능을 사용할 수 있다. 간단한 작업에는 직접 실행을 우선하고, 서브에이전트는 독립성·복잡성·병렬성 때문에 실제 이득이 있을 때만 사용하는 것이 효율적이다. 이를 위해 위임 여부뿐 아니라 핸드오프의 구체성, 메인 에이전트의 병렬 진행 여부까지 함께 설계해야 한다.
Copilot CLI의 `/fleet`는 하나의 작업을 여러 독립적인 하위 작업으로 나누고, 여러 에이전트를 병렬 실행하는 기능이다. 오케스트레이터가 작업의 의존성을 분석해 실행 순서를 정하고, 결과를 검증·통합하므로 여러 파일이나 모듈을 동시에 처리할 수 있다. 다만 에이전트들이 동일한 파일을 수정하면 잠금이나 자동 병합 없이 마지막 변경이 덮어쓰므로, 작업 범위와 파일 경계를 명확히 지정해야 한다. ## `/fleet`의 작동 방식 - 사용자가 `/fleet <작업 목표>` 형식으로 목표를 전달한다. - 오케스트레이터가 목표를 독립적인 작업 단위로 분해한다. - 작업 간 의존성을 분석해 병렬 실행 가능한 항목과 순차 실행해야 하는 항목을 구분한다. - 독립적인 작업은 백그라운드 하위 에이전트에 동시에 배정한다. - 작업 완료를 확인한 뒤 다음 의존 작업을 실행한다. - 각 결과를 검증하고 최종 산출물로 통합한다. - 하위 에이전트는 각자의 컨텍스트 창을 사용하지만 동일한 파일 시스템을 공유하며, 서로 직접 대화하지 않고 오케스트레이터를 통해 조정된다. ## 시작 방법 - 대화형 CLI에서는 다음과 같이 실행한다. ```text /fleet Refactor the auth module, update tests, and fix the related docs in the folder docs/auth/ ``` - 터미널에서 비대화형으로 실행할 수도 있다. ```bash copilot -p "/fleet <YOUR TASK>" --no-ask-user ``` - `--no-ask-user`는 사용자가 추가 질문에 응답할 수 없는 비대화형 환경에서 필요하다. ## 병렬화에 적합한 프롬프트 작성 - 작업마다 구체적인 산출물을 지정해야 한다. - 파일 - 테스트 스위트 - 문서 페이지 - 특정 모듈 - “문서를 작성하라”처럼 모호한 요청은 독립 작업을 식별하기 어려워 순차 실행될 가능성이 높다. - 예를 들어 인증, 엔드포인트, 오류 문서를 각각 별도 파일로 지정하면 세 작업은 병렬 처리할 수 있다. - 여러 문서를 연결하는 `docs/index.md`처럼 다른 결과물에 의존하는 작업은 후속 단계로 명시해야 한다. ## 파일 범위와 제약 조건 지정 프롬프트에는 각 에이전트가 담당할 범위를 명확히 적어야 한다. - 담당 디렉터리나 파일을 지정한다. - 수정해서는 안 되는 영역을 명시한다. - 테스트 변경 금지 - 의존성 업그레이드 금지 - 지정 디렉터리 외 수정 금지 - 완료 조건을 제시한다. - 린트 통과 - 타입 검사 통과 - 특정 테스트 통과 - API, UI, 설정처럼 서로 다른 영역을 별도 트랙으로 나누면 병렬 실행 효과가 커진다. ## 작업 의존성 선언 - 한 작업이 다른 작업의 결과를 필요로 하면 프롬프트에 `depends on` 관계를 명시한다. - 예를 들어 다음과 같이 데이터베이스 마이그레이션, ORM 모델, API 핸들러, 통합 테스트의 순서를 지정할 수 있다. - ORM 모델이 완성된 뒤 API 핸들러와 통합 테스트를 동시에 실행하도록 구성할 수 있다. - 의존성을 명시하지 않으면 에이전트가 충돌하거나 불완전한 결과를 바탕으로 작업할 수 있다. ## 사용자 지정 에이전트 활용 - `.github/agents/`에 전문 에이전트 설정 파일을 만들 수 있다. - 에이전트마다 다음을 지정할 수 있다. - 모델 - 사용 가능한 도구 - 역할과 작업 지침 - 문서 작성에는 `technical-writer` 같은 전문 에이전트를 사용하고, 코드 변경에는 기본 에이전트를 사용하는 식으로 역할을 나눌 수 있다. - 모델을 별도로 지정하지 않으면 현재 기본 모델이 사용된다. ## 병렬 실행 여부 확인 - 오케스트레이터가 작업을 여러 트랙으로 분해했는지 계획을 먼저 확인한다. - `/tasks` 명령으로 백그라운드 작업 목록과 진행 상태를 볼 수 있다. - 여러 트랙에서 동시에 진행 상황이 보고되는지 확인한다. - 병렬화되지 않는다면 다음처럼 먼저 분해하도록 요청할 수 있다. ```text Decompose this into independent tracks first, then execute tracks in parallel. Report each track separately with status and blockers. ``` ## 주요 주의점 - 하위 에이전트는 파일 잠금 기능 없이 동일한 파일 시스템을 공유한다. - 두 에이전트가 같은 파일을 수정하면 오류나 자동 병합 없이 마지막 완료 결과가 앞선 변경을 덮어쓸 수 있다. - 따라서 각 에이전트에 서로 다른 파일을 배정해야 한다. - 하나의 파일에 여러 에이전트가 기여해야 한다면: - 각자 임시 파일에 작성한 뒤 오케스트레이터가 병합하게 하거나 - 에이전트 실행 순서를 명시해야 한다. - 하위 에이전트는 오케스트레이터와의 이전 대화 기록을 볼 수 없으므로, 전달되는 프롬프트만으로 작업할 수 있도록 지침과 제약 조건을 self-contained하게 작성해야 한다. 실제로 `/fleet`를 사용할 때는 먼저 작업을 파일·모듈 단위로 분리하고, 의존성과 검증 조건을 프롬프트에 명시하는 것이 좋다. 특히 공유 파일을 여러 에이전트가 수정하지 않도록 범위를 엄격히 나누면 병렬 처리의 속도 이점과 결과 안정성을 함께 얻을 수 있다.
