GitHub가 Copilot CLI에 맞춘 커스텀 에이전트 활용법을 공개했다. 핵심은 터미널에서 매번 같은 프롬프트를 다시 쓰는 대신, 저장소 안의 Markdown 프로필로 역할·도구 권한·출력 형식을 정의해 반복 업무를 팀이 검토할 수 있는 워크플로로 바꾸는 것이다.
핵심 요약
- 무엇: GitHub Copilot CLI에서 사용할 커스텀 에이전트를 Markdown 기반 agent profile로 정의하는 방식이다.
- 어디에 두나: 대상 저장소의
.github/agents디렉터리에accessibility.agent.md처럼.agent.md파일로 둔다. - 무엇을 정하나: 에이전트의 역할, 전문 영역, 접근 가능한 도구, 지켜야 할 guardrail, 결과물 형식을 YAML frontmatter와 본문으로 명시한다.
- 왜 중요하나: 보안 점검, IaC 검토, 릴리스 노트, 장애 초동 분석처럼 반복되지만 팀 규칙이 중요한 작업을 CLI에서 일관되게 실행할 수 있다.
무엇이 달라졌나
기존의 터미널 AI 사용은 대개 “지금 이 로그를 요약해줘”, “이 명령을 만들어줘”처럼 한 번 쓰고 사라지는 프롬프트에 가까웠다. GitHub 블로그가 설명한 커스텀 에이전트는 이 흐름을 파일로 고정한다. 저장소에 agent profile을 넣어두면 에이전트가 어떤 역할을 맡고, 어떤 도구를 쓸 수 있으며, 어떤 기준으로 결과를 내야 하는지 팀이 코드처럼 관리할 수 있다.
GitHub는 Copilot CLI가 스크립트를 실행하고, API를 호출하고, 저장소와 직접 맞닿아 있다는 점을 강조한다. 그래서 커스텀 에이전트의 가치는 “대답을 잘하는 봇”보다 “정해진 작업 순서를 같은 방식으로 다시 수행하는 도구”에 가깝다. 예를 들어 릴리스 때마다 병합된 PR을 모아 CHANGELOG 초안을 만들고, 테스트·마이그레이션·롤백 메모까지 붙이는 작업을 한 사람의 기억이 아니라 저장소에 남긴 규칙으로 처리할 수 있다.
agent profile이 중요한 이유
GitHub가 제시한 예시는 접근성 전문가 에이전트다. 프로필에는 “WCAG 2.1/2.2, inclusive UX, a11y testing을 다루는 전문가”처럼 역할을 쓰고, 사용할 모델과 도구를 지정한다. 이 구조가 중요한 이유는 프롬프트가 개인 노트에 머물지 않고 저장소의 리뷰 대상이 되기 때문이다. 팀은 프로필 변경을 pull request로 검토하고, 어떤 도구 권한을 열었는지 확인하며, 출력 형식이 팀 표준과 맞는지 추적할 수 있다.
파일 위치도 실무적으로 의미가 있다. .github/agents 아래에 둔 agent profile은 저장소와 함께 버전 관리된다. 누가 어떤 guardrail을 추가했는지, 사고 이후 어떤 절차가 바뀌었는지, 특정 팀만 쓰던 프롬프트가 공통 규칙으로 승격됐는지 확인할 수 있다. AI 에이전트를 업무에 붙일 때 가장 큰 문제인 “같은 질문을 했는데 사람마다 다른 방식으로 실행한다”는 위험을 줄이는 장치다.
어떤 업무에 먼저 맞는가
| 업무 | 에이전트에 넣을 규칙 | 사람이 확인할 부분 |
|---|---|---|
| 보안 점검 | 표준 스캐너 실행, 심각도별 요약, 담당자와 후속 조치 목록 | 오탐 여부, 공개 이슈로 올려도 되는 정보 범위 |
| IaC 검토 | Terraform/manifest 변경을 조직 정책과 비교, 위험한 변경 강조 | 실제 인프라 영향, 승인권자, 되돌릴 방법 |
| 릴리스 문서 | 이전 릴리스 이후 병합된 PR 수집, CHANGELOG 초안, 배포 전 확인 항목 | 고객 영향, migration 누락, release note 톤 |
| 장애 초동 분석 | 서비스명과 시간 범위 기준으로 배포 이력, 오류율, 주요 로그 요약 | 민감 로그 노출, 원인 단정, 다음 대응 우선순위 |
이 네 가지는 GitHub가 글에서 직접 예로 든 흐름과 맞닿아 있다. 공통점은 “명령 실행과 요약”만으로 끝나지 않는다는 점이다. 보안 점검은 오탐과 심각도 판단이 필요하고, IaC 검토는 실제 배포 영향과 승인 과정이 필요하다. 릴리스 문서는 팀의 표현 방식이 중요하며, 장애 초동 분석은 로그 접근 권한과 민감 정보 처리 기준이 중요하다. 따라서 커스텀 에이전트는 자동화 자체보다 “어디까지 자동화하고 어디서 사람이 멈춰 볼지”를 파일에 적는 방식으로 접근해야 한다.
기성 에이전트와 직접 만든 에이전트의 선택 기준
GitHub는 JFrog, Dynatrace, Octopus Deploy, Arm 같은 파트너 영역의 off-the-shelf agent도 함께 언급한다. 이미 특정 도구의 권장 명령과 관행이 정리된 업무라면 기성 에이전트로 빠르게 시작하는 편이 낫다. 예를 들어 관측성 도구에서 일반적인 오류 패턴을 찾거나, 보안 도구의 기본 리포트를 정리하는 작업은 처음부터 프로필을 새로 쓰지 않아도 된다.
반대로 팀 내부 API, 사내 배포 스크립트, 고유한 코드 리뷰 규칙, 보안 승인 절차가 섞인 업무라면 직접 만든 agent profile이 더 적합하다. 이 경우 에이전트의 장점은 “더 창의적인 답변”이 아니라 “우리 팀이 이미 합의한 순서를 빠뜨리지 않는 것”이다. 특히 여러 저장소가 같은 릴리스 규칙을 공유하거나, 신규 팀원이 같은 품질 기준으로 첫 PR을 준비해야 하는 상황에서 효과가 크다.
실무에서 먼저 확인할 리스크
- 도구 권한: 에이전트가 파일 수정, 명령 실행, 외부 API 호출, 변경사항 작성 중 어디까지 할 수 있는지 분리해야 한다. 처음부터 쓰기 권한을 넓게 주면 잘못된 명령이나 과도한 수정이 리뷰 전에 발생할 수 있다.
- 데이터 처리: 로그, 고객 식별자, 보안 스캔 결과가 프롬프트나 출력에 포함될 수 있다. 저장소 밖으로 나가면 안 되는 정보는 agent profile과 실행 스크립트에서 마스킹 기준을 명확히 해야 한다.
- 재현성: 같은 입력에서 같은 절차가 실행되는지 확인해야 한다. 모델 응답만 믿기보다 실행 명령, 사용한 파일, 생성한 요약을 PR이나 이슈에 남겨야 나중에 원인을 추적할 수 있다.
- 자동 수정 한계: 릴리스 문서나 보안 요약은 초안 생성까지는 유용하지만, 실제 코드 변경·정책 변경·배포 승인까지 자동으로 넘기는 것은 별도 통제 없이는 위험하다.
- 비용과 사용량: 반복 업무를 에이전트로 묶으면 호출 횟수가 늘어날 수 있다. 팀 단위로 쓰기 전에는 대표 워크플로 하나의 실행 시간, 토큰 사용량, 실패 후 재시도 비용을 기록해야 한다.
팀에서 검증하는 순서
- 반복 빈도가 높은 작업 하나만 고른다. 릴리스 노트 작성, 장애 초동 요약, 보안 스캔 정리처럼 매주 반복되고 결과 형식이 비교적 분명한 작업이 좋다.
- 읽기 전용 또는 초안 생성 권한으로 시작한다. 처음부터 파일을 수정하거나 배포 명령을 실행하게 하기보다, 에이전트가 어떤 명령을 제안하고 어떤 요약을 내는지 먼저 본다.
- agent profile을 PR로 리뷰한다. 역할 설명, 접근 도구, guardrail, 출력 형식을 팀원이 확인해야 한다. 특히 “실패했을 때 멈추는 조건”과 “사람 승인 없이 하면 안 되는 작업”을 명시한다.
- 기존 수작업 결과와 나란히 비교한다. 누락된 로그, 과장된 원인 추정, 불필요한 명령, 오탐을 기록한다. 에이전트가 줄인 시간보다 검토 부담이 더 큰지도 함께 본다.
- 되돌릴 방법을 남긴다. 프로필 변경 이력, 생성된 PR, 실행 로그, 실패 사례를 저장해 다음 업데이트 때 같은 실수를 반복하지 않게 한다.
결론
GitHub Copilot CLI 커스텀 에이전트는 개발자의 터미널을 더 화려하게 만드는 기능이라기보다, 반복되는 팀 업무를 저장소 안의 규칙으로 끌어오는 기능에 가깝다. 가치가 분명한 영역은 보안, 인프라, 릴리스, 장애 대응처럼 “실행은 빠르지만 기준은 엄격해야 하는” 작업이다. 개인 개발자에게도 유용하지만, 진짜 차이는 팀이 같은 프로필을 리뷰하고 버전 관리할 때 나온다.
다만 에이전트를 붙였다고 해서 검토 책임이 사라지지는 않는다. 권한 범위, 민감 데이터, 자동 수정 한계, 실패 시 롤백 기준을 먼저 정해야 한다. 이 네 가지가 정리되지 않았다면 Copilot CLI의 커스텀 에이전트는 생산성 도구가 아니라 또 다른 자동화 위험이 될 수 있다.