From Your Laptop to the Pipeline: Scaling Custom Agents with GitHub Copilot

한 줄 핵심

GitHub Copilot으로 로컬에서 시작한 맞춤형 에이전트를 CLI·마켓플레이스·CI 파이프라인으로 확장해, 조직 단위로 재사용·자동화·비용 통제까지 연결하는 방법을 보여주는 영상이다.

시간별 요약

1. 0:00
   소개 GitHub에서 보안과 AI 고객 도입을 담당해 온 배경을 바탕으로, 플랫폼 위에서 에이전트를 어떻게 만들고 확장할지 다룬다.
2. 0:52
   로컬 에이전트와 자율 에이전트 에이전트는 로컬에서 사용하는 작업 보조형과 파이프라인에서 자동으로 돌아가는 자율형으로 나뉘며, 둘의 설계와 확장 방식이 다르다.
3. 1:32
   Copilot의 내부 동작 방식 IDE, GitHub CLI, SDK 같은 진입점이 모두 Cappy 또는 Copilot API service라는 하네스로 연결되고, 여기서 입력 분할, 인증, 로깅, 모델 전달, 결과 필터링이 처리된다.
4. 3:32
   CLI에 내장된 에이전트 CLI에는 코드베이스 탐색용 explorer agent나 계획 검토용 rubber duck처럼 목적에 맞는 내장 에이전트가 있으며, 각 에이전트는 모델과 지침을 명시적으로 바꿔 쓸 수 있다.
5. 5:32
   맞춤형 에이전트 만들기 agent 명령으로 프로젝트 수준 또는 사용자 수준의 에이전트를 생성하고, Copilot이 설명·front matter·성공 기준·방법론을 자동으로 채워 반복 작업용 에이전트를 빠르게 구성한다.
6. 7:37
   마켓플레이스로 에이전트 공유하기 마켓플레이스는 저장소에 약간의 JSON을 더한 형태로 에이전트를 버전 관리·동기화·배포하는 장치이며, 조직 내부의 공통 에이전트를 중앙에서 배포해 재사용성을 높인다.
7. 10:52
   여러 저장소에서 에이전트 사용하기 orchestrate는 여러 GitHub issue를 목표로 삼아 저장소별 서브에이전트를 띄우는 기능으로, 마이크로서비스처럼 여러 저장소를 가로지르는 작업을 병렬로 진행하게 해준다.
8. 12:41
   에이전트형 워크플로: CI에서의 에이전트 Copilot CLI를 headless mode로 실행해 GitHub Actions나 다른 CI에서 돌리면, 릴리스·주기적 점검·유지보수 같은 이벤트 기반 작업을 파이프라인 안에서 자동화할 수 있다.
9. 14:21
   이슈에서 에이전트 실행하기 issue 댓글의 slash command로 다음 단계를 열고, 기획 에이전트와 구현 에이전트, 검수 단계가 이어지는 흐름을 만들어 사람은 승인 지점에서만 개입하게 할 수 있다.
10. 14:56
    파이프라인 에이전트가 확장되는 이유 로컬 세션과 달리 플랫폼에서 돌아가는 에이전트는 장치·네트워크 의존성이 낮고, 전 과정이 관측 가능해져 최적화와 운영 통제가 쉬워진다.
11. 15:36
    하나의 저장소에 200개의 에이전트 GitHub AW 프로젝트처럼 수백 개의 에이전트가 각자 일일 보고·중복 제거·리뷰 등을 맡는 구조가 가능하며, Agentics 같은 예시 저장소에서 바로 가져다 쓸 수도 있다.
12. 18:16
    스스로 비용을 감시하는 에이전트 에이전트가 기대 비용의 P90을 넘으면 원인을 조사하게 하거나, 실패하는 도구 호출에 대해 front matter와 모델을 A/B 테스트해 더 저렴하고 안정적인 구성을 찾을 수 있다.
13. 18:56
    마무리 로컬 에이전트 생성, 플랫폼 공유, CI 파이프라인 이관이라는 세 단계를 통해 에이전트를 조직 규모로 확장하는 흐름을 정리한다.

실무 인사이트

• 에이전트를 조직에 확산하려면 먼저 반복 가능한 작업을 표준화한 뒤, 마켓플레이스로 배포 가능한 형태로 묶는 것이 효과적이다.
• 비용과 품질을 관리하려면 로컬 실행보다 CI 기반 실행으로 옮겨 관측 가능성을 확보하고, 토큰 사용량과 실패 지점을 함께 봐야 한다.
• 여러 저장소를 다루는 작업은 단일 에이전트보다 orchestrate 같은 오케스트레이션 계층으로 분리해야 권한과 책임 범위를 유지하기 쉽다.