GitHub Copilot cloud agent 사용법: 59분 제한 안에서 PR 작업 쪼개기

GitHub Copilot cloud agent는 IDE 안에서 채팅하는 기능과 다르다. GitHub 문서 기준으로 cloud agent는 GitHub Actions 기반의 임시 개발 환경에서 저장소를 조사하고, 구현 계획을 만들고, 브랜치에 변경을 만들고, 필요하면 PR까지 열 수 있다. 이 기능을 제대로 쓰려면 ‘AI에게 큰 작업을 맡긴다’가 아니라 ‘59분 안에 끝나는 검증 가능한 PR 단위로 쪼갠다’가 핵심이다.

검색 의도는 실무적이다. Copilot cloud agent를 어떤 이슈에 배정해야 하는지, 어디까지 자동화해야 하는지, 59분 제한과 GitHub Actions 비용을 어떻게 고려해야 하는지다. 문서에는 cloud agent session의 최대 실행 시간이 59분이며, GitHub Actions minutes와 AI credits를 사용한다고 적혀 있다. 이 두 조건이 운영 설계를 결정한다.

cloud agent와 IDE agent mode를 구분한다

Copilot cloud agent는 GitHub에서 비동기적으로 일한다. 이슈나 Copilot Chat에서 시작해 저장소를 조사하고 브랜치를 만들고 변경을 커밋한다. 반면 IDE agent mode는 로컬 개발 환경에서 직접 파일을 수정한다. 둘 다 ‘agent’라는 말을 쓰지만 운영 경계가 다르다.

Cloud agent의 장점은 투명성이다. 작업 결과가 브랜치, commit, PR, log로 남는다. 팀원이 같은 GitHub 공간에서 진행 상황을 보고, 리뷰하고, 이어받을 수 있다. 로컬 IDE 세션은 빠르지만 대화 중 결정이 사라지기 쉽고, 브랜치 생성과 PR 작성 같은 뒷정리를 사람이 해야 한다.

따라서 cloud agent는 ‘협업 가능한 백그라운드 작업자’로 보는 편이 맞다. 혼자 빠르게 고치는 작업은 IDE가 낫고, 이슈에서 출발해 PR로 남길 작업은 cloud agent가 맞다.

59분 제한은 작업 설계 기준이다

GitHub 문서에는 Copilot cloud agent session이 최대 59분까지 실행된다고 명시돼 있다. 복잡한 리팩터링, 여러 패키지 업그레이드, 대형 migration을 한 번에 맡기면 제한에 걸리기 쉽다. 제한 시간이 끝나면 작업은 멈추고, 사람은 중간 상태를 해석해야 한다.

좋은 이슈는 59분 안에 조사, 수정, 테스트, 요약이 가능한 단위다. 예를 들어 ‘settings page의 broken link를 수정하고 테스트를 추가하라’, ‘이 API deprecation warning을 제거하라’, ‘문서 예제와 실제 prop 이름을 맞춰라’ 같은 작업은 적합하다. 반대로 ‘인증 구조를 전부 개선하라’, ‘성능을 최적화하라’, ‘디자인 시스템을 새로 만들라’는 너무 크다.

큰 작업은 discovery issue와 implementation issue로 나눈다. 첫 번째 세션은 repository 조사와 계획만 맡기고, 두 번째부터 작은 PR 단위로 구현한다. 이렇게 하면 실패해도 비용이 제한되고, 사람이 계획을 검토한 뒤 진행할 수 있다.

custom instructions가 품질을 좌우한다

GitHub 문서는 Copilot cloud agent의 저장소 이해도를 높이는 방법으로 custom instructions와 Copilot Memory를 언급한다. 특히 custom instructions는 팀 규칙을 안정적으로 전달하는 기본 장치다. 테스트 명령, package manager, 코딩 스타일, 금지 경로, PR 작성 규칙을 저장소에 남겨야 한다.

좋은 instruction은 길지 않다. 예를 들어 pnpm test --filter web을 써야 하는지, DB migration은 자동 작성하지 말아야 하는지, UI copy 변경은 i18n 파일도 함께 수정해야 하는지 같은 구체 규칙이 좋다. ‘깔끔하게 작성하라’는 쓸모가 적다.

또한 cloud agent는 저장소 하나만 변경할 수 있다는 제한이 있다. monorepo가 아닌 여러 repo가 얽힌 작업이라면 이슈에 경계를 명확히 써야 한다. ‘이 저장소에서는 API client 타입만 수정하고, 서버 변경은 별도 이슈로 남겨라’처럼 적어야 한다.

MCP와 hooks는 권한 설계가 먼저다

Copilot cloud agent는 repository MCP settings, hooks, skills, custom agents로 확장할 수 있다. GitHub MCP server와 Playwright MCP server가 기본으로 제공되는 문맥도 있다. 이 확장은 강력하지만, 곧 공격 표면이기도 하다.

MCP 서버를 붙이면 agent가 외부 데이터와 도구에 접근한다. Jira, Slack, production log, feature flag, analytics를 붙이는 순간 agent는 단순 코딩 도구가 아니라 업무 시스템 조작자가 된다. read-only와 write 권한을 나누고, 민감 도구는 승인 없이 실행하지 못하게 해야 한다.

Hooks도 마찬가지다. lifecycle 중 shell command를 실행해 validation, logging, security scanning을 할 수 있지만, 잘못 만들면 agent가 예측하지 못한 side effect를 만든다. 처음에는 test, lint, typecheck처럼 검증용 hook부터 시작하는 편이 안전하다. 배포나 외부 메시지 발송 hook은 나중에 별도 승인과 함께 붙여야 한다.

비용은 Actions minutes와 AI credits로 나눠 본다

Cloud agent는 GitHub Actions powered ephemeral environment에서 실행된다. 따라서 비용은 모델 사용량만이 아니다. private repository라면 Actions minutes도 고려해야 하고, Copilot code review 역시 private repository에서 Actions minutes를 소비할 수 있다고 문서에 적혀 있다.

팀 운영에서는 issue label별 평균 비용을 보는 것이 좋다. docs, test, bug-small, refactor-medium, security 같은 label에 대해 평균 실행 시간, 생성 PR 수, merge rate, 재작업 시간을 기록한다. 단순히 PR 개수만 늘면 좋은 것이 아니다. merge되지 않는 PR을 많이 만들면 Actions와 reviewer 시간이 같이 낭비된다.

Copilot usage metrics API는 cloud agent가 만든 PR의 총수, merge된 수, median time to merge 같은 지표를 제공한다. 이 지표를 사람이 만든 PR과 비교하면 어떤 작업을 agent에 맡겨야 할지 보인다.

실행 체크리스트

• cloud agent와 IDE agent mode의 사용 기준을 문서화한다.
• 이슈는 59분 안에 조사·수정·테스트 가능한 범위로 쪼갠다.
• 큰 작업은 discovery issue와 implementation issue로 나눈다.
• 저장소 custom instructions에 테스트 명령, package manager, 금지 경로를 적는다.
• MCP와 hooks는 read-only 검증부터 시작하고 write 작업은 승인 요구로 둔다.
• GitHub Actions minutes와 AI credits를 label별로 추적한다.
• cloud agent PR의 merge rate와 time to merge를 usage metrics로 확인한다.

출처: GitHub Docs, About GitHub Copilot cloud agent