GitHub Copilot CLI는 5월 릴리스에서 /autopilot, /fork, MCP 관련 개선, OpenTelemetry 정렬, prompt/headless 모드 안정화 같은 변화를 이어가고 있습니다. 이 기능들은 “터미널에서 Copilot을 쓴다” 수준을 넘어, 코딩 에이전트를 반복 가능한 개발 워크플로우에 넣기 위한 재료입니다. 문제는 기능을 켜는 것보다 운영 기준을 세우는 쪽이 더 어렵다는 점입니다.
실무에서 Copilot CLI autopilot을 쓸 때 목표는 에이전트에게 무작정 많은 권한을 주는 것이 아닙니다. 사람이 하던 반복 작업 중 위험도가 낮고 검증 가능한 부분을 맡기고, 위험도가 높은 변경은 계획과 리뷰 단계에서 멈추게 만드는 것입니다.
/autopilot은 인터랙티브 모드와 자동 진행 모드 사이를 오가게 해줍니다. 이름 때문에 “큰 작업을 알아서 끝내는 버튼”처럼 보일 수 있지만, 처음부터 대규모 리팩터링에 쓰면 실패 비용이 큽니다. autopilot에 적합한 첫 작업은 작고, 검증 가능하고, 되돌리기 쉬운 일입니다.
좋은 후보는 다음과 같습니다.
반대로 DB migration, 결제 로직, 인증/권한, 인프라 변경은 처음부터 autopilot에 맡기면 안 됩니다. 이런 작업은 plan mode 또는 조사 모드로 시작하고, 사람이 승인한 작은 단위만 실행해야 합니다.
Copilot CLI의 /fork는 현재 세션을 독립 세션으로 분기해 다른 방향을 시험할 때 유용합니다. 예를 들어 버그 원인을 두 가지 가설로 나눠 확인하거나, UI 수정안을 두 방식으로 비교할 수 있습니다. 하지만 같은 파일을 여러 fork가 동시에 고치면 병합 비용이 커집니다.
/fork를 쓸 때는 목적을 명확히 해야 합니다.
fork A: 원인 가설 1 검증. 파일 수정 금지, 로그와 테스트 결과만 보고.
fork B: 원인 가설 2 검증. 파일 수정 금지, 관련 코드 경로만 정리.
메인 세션: 두 결과 비교 후 하나만 구현.
이 구조에서는 fork가 조사 역할을 하고, 실제 변경은 메인 세션에서 합니다. 반대로 fork마다 구현을 시키면 나중에 사람이 diff를 비교하고 충돌을 풀어야 합니다. AI가 시간을 아껴준 만큼 리뷰 시간이 늘어나는 전형적인 실패 패턴입니다.
최근 Copilot CLI 릴리스에는 MCP registry 검색, 외부 도구 deferred loading, workspace MCP source 자동 로딩 같은 변화가 포함됐습니다. MCP는 에이전트가 외부 시스템을 다룰 수 있게 해주지만, 연결되는 순간 신뢰 경계가 넓어집니다.
MCP 서버를 붙이기 전에 다음 질문에 답해야 합니다.
특히 prompt mode나 headless mode에서 MCP 설정이 자동으로 로딩되는 경우, CI나 자동화 환경에서 예상보다 많은 도구가 열릴 수 있습니다. --plugin-dir나 추가 MCP config를 쓴다면 deterministic set, 즉 어떤 플러그인과 도구가 로딩되는지 고정하는 방식이 필요합니다.
Copilot CLI는 MCP tool call span과 gen_ai.client.operation.duration 같은 GenAI semantic convention에 맞춘 관측성 개선을 포함했습니다. 이건 개발팀이 반드시 활용해야 할 지점입니다. 에이전트 작업은 실패했을 때 원인 파악이 어렵습니다. 모델이 잘못 판단했는지, 도구 호출이 느렸는지, MCP 서버가 실패했는지, 권한 프롬프트 때문에 멈췄는지 분리해야 합니다.
관측성에서 최소로 봐야 할 지표는 다음입니다.
이 지표가 있어야 “autopilot이 느리다” 같은 감상을 “특정 MCP 서버 응답이 평균 12초라 전체 세션을 지연시킨다”로 바꿀 수 있습니다.
릴리스에는 memory permission prompt가 저장 범위를 더 명확히 보여주는 개선도 포함됐습니다. user scope인지 repository scope인지, repository collaborator와 공유되는지 표시하는 방식입니다. 코딩 에이전트 메모리는 편리하지만, 팀 환경에서는 민감한 설계 결정, 고객 정보, 내부 URL이 저장될 수 있습니다.
정책은 단순해야 합니다.
메모리를 잘 쓰면 반복 지시가 줄지만, 잘못 쓰면 오래된 규칙이나 민감정보가 자동으로 주입됩니다.
실무에서는 autopilot을 켤 때 다음 템플릿을 권장합니다.
목표: [작고 검증 가능한 작업]
범위: [허용 파일/디렉터리]
금지: [DB 변경, 의존성 추가, 공개 API 변경 등]
도구: [허용 MCP/CLI]
진행: 먼저 계획 5줄, 그 다음 변경
검증: [실행할 테스트/린트]
중단: 테스트 실패 2회, 권한 필요, 범위 밖 파일 수정 필요 시 중단
출력: 변경 파일, 테스트 결과, 남은 리스크
이 템플릿은 에이전트를 느리게 만들기 위한 것이 아닙니다. 자동화가 멈춰야 할 지점을 미리 정해서, 사람이 개입해야 할 때를 명확히 만드는 장치입니다.
Copilot CLI의 새 기능은 “자동으로 더 많이 하게 하는 기능”이 아니라 “자동화를 더 안전하게 운영하기 위한 기능”으로 봐야 합니다. 이 관점이 없으면 autopilot은 생산성 도구가 아니라 리뷰 부채 생성기가 됩니다.