Copilot CLI autopilot 운영법: /fork·MCP·OpenTelemetry를 실무에 붙이는 방법

GitHub Copilot CLI는 5월 릴리스에서 /autopilot, /fork, MCP 관련 개선, OpenTelemetry 정렬, prompt/headless 모드 안정화 같은 변화를 이어가고 있습니다. 이 기능들은 “터미널에서 Copilot을 쓴다” 수준을 넘어, 코딩 에이전트를 반복 가능한 개발 워크플로우에 넣기 위한 재료입니다. 문제는 기능을 켜는 것보다 운영 기준을 세우는 쪽이 더 어렵다는 점입니다.

실무에서 Copilot CLI autopilot을 쓸 때 목표는 에이전트에게 무작정 많은 권한을 주는 것이 아닙니다. 사람이 하던 반복 작업 중 위험도가 낮고 검증 가능한 부분을 맡기고, 위험도가 높은 변경은 계획과 리뷰 단계에서 멈추게 만드는 것입니다.

autopilot은 작은 작업 자동화부터 시작해야 한다

/autopilot은 인터랙티브 모드와 자동 진행 모드 사이를 오가게 해줍니다. 이름 때문에 “큰 작업을 알아서 끝내는 버튼”처럼 보일 수 있지만, 처음부터 대규모 리팩터링에 쓰면 실패 비용이 큽니다. autopilot에 적합한 첫 작업은 작고, 검증 가능하고, 되돌리기 쉬운 일입니다.

좋은 후보는 다음과 같습니다.

• lint 오류 일괄 수정
• deprecated API 사용처 목록화
• 테스트 이름 정리
• README와 실제 CLI 옵션 차이 점검
• 타입 오류 중 단순 누락 import 수정
• 실패 테스트의 원인 후보 정리

반대로 DB migration, 결제 로직, 인증/권한, 인프라 변경은 처음부터 autopilot에 맡기면 안 됩니다. 이런 작업은 plan mode 또는 조사 모드로 시작하고, 사람이 승인한 작은 단위만 실행해야 합니다.

/fork는 비교 실험에 쓰고, 병렬 구현 남발에는 쓰지 않는다

Copilot CLI의 /fork는 현재 세션을 독립 세션으로 분기해 다른 방향을 시험할 때 유용합니다. 예를 들어 버그 원인을 두 가지 가설로 나눠 확인하거나, UI 수정안을 두 방식으로 비교할 수 있습니다. 하지만 같은 파일을 여러 fork가 동시에 고치면 병합 비용이 커집니다.

/fork를 쓸 때는 목적을 명확히 해야 합니다.

fork A: 원인 가설 1 검증. 파일 수정 금지, 로그와 테스트 결과만 보고.
fork B: 원인 가설 2 검증. 파일 수정 금지, 관련 코드 경로만 정리.
메인 세션: 두 결과 비교 후 하나만 구현.

이 구조에서는 fork가 조사 역할을 하고, 실제 변경은 메인 세션에서 합니다. 반대로 fork마다 구현을 시키면 나중에 사람이 diff를 비교하고 충돌을 풀어야 합니다. AI가 시간을 아껴준 만큼 리뷰 시간이 늘어나는 전형적인 실패 패턴입니다.

MCP는 도구 수보다 신뢰 경계가 먼저다

최근 Copilot CLI 릴리스에는 MCP registry 검색, 외부 도구 deferred loading, workspace MCP source 자동 로딩 같은 변화가 포함됐습니다. MCP는 에이전트가 외부 시스템을 다룰 수 있게 해주지만, 연결되는 순간 신뢰 경계가 넓어집니다.

MCP 서버를 붙이기 전에 다음 질문에 답해야 합니다.

• 이 도구는 읽기 전용인가, 쓰기도 가능한가?
• 어떤 저장소, 이슈, 문서, DB에 접근하는가?
• 토큰이나 비밀값이 프롬프트에 노출될 가능성은 없는가?
• 실패했을 때 side effect가 남는가?
• 로그에 민감정보가 남지 않는가?
• headless 모드에서도 같은 권한으로 동작하는가?

특히 prompt mode나 headless mode에서 MCP 설정이 자동으로 로딩되는 경우, CI나 자동화 환경에서 예상보다 많은 도구가 열릴 수 있습니다. --plugin-dir나 추가 MCP config를 쓴다면 deterministic set, 즉 어떤 플러그인과 도구가 로딩되는지 고정하는 방식이 필요합니다.

OpenTelemetry는 “AI가 뭘 했는지”를 운영 데이터로 만든다

Copilot CLI는 MCP tool call span과 gen_ai.client.operation.duration 같은 GenAI semantic convention에 맞춘 관측성 개선을 포함했습니다. 이건 개발팀이 반드시 활용해야 할 지점입니다. 에이전트 작업은 실패했을 때 원인 파악이 어렵습니다. 모델이 잘못 판단했는지, 도구 호출이 느렸는지, MCP 서버가 실패했는지, 권한 프롬프트 때문에 멈췄는지 분리해야 합니다.

관측성에서 최소로 봐야 할 지표는 다음입니다.

• 세션별 총 실행 시간
• 모델별 호출 횟수
• MCP tool call 횟수와 실패율
• 가장 오래 걸린 tool call
• 권한 프롬프트 발생 횟수
• autopilot 중단 사유
• 생성 diff 크기
• 테스트 실행 결과

이 지표가 있어야 “autopilot이 느리다” 같은 감상을 “특정 MCP 서버 응답이 평균 12초라 전체 세션을 지연시킨다”로 바꿀 수 있습니다.

메모리 권한 프롬프트는 팀 정책과 연결해야 한다

릴리스에는 memory permission prompt가 저장 범위를 더 명확히 보여주는 개선도 포함됐습니다. user scope인지 repository scope인지, repository collaborator와 공유되는지 표시하는 방식입니다. 코딩 에이전트 메모리는 편리하지만, 팀 환경에서는 민감한 설계 결정, 고객 정보, 내부 URL이 저장될 수 있습니다.

정책은 단순해야 합니다.

• 개인 취향은 user memory에 저장 가능
• 프로젝트 규칙은 repository memory에 저장 가능
• 고객명, 토큰, 장애 상세, 보안 취약점은 memory 저장 금지
• memory 변경은 PR 또는 로그로 추적
• 퇴사자나 권한 변경 시 repository memory 접근 범위 점검

메모리를 잘 쓰면 반복 지시가 줄지만, 잘못 쓰면 오래된 규칙이나 민감정보가 자동으로 주입됩니다.

autopilot 프롬프트 템플릿

실무에서는 autopilot을 켤 때 다음 템플릿을 권장합니다.

목표: [작고 검증 가능한 작업]
범위: [허용 파일/디렉터리]
금지: [DB 변경, 의존성 추가, 공개 API 변경 등]
도구: [허용 MCP/CLI]
진행: 먼저 계획 5줄, 그 다음 변경
검증: [실행할 테스트/린트]
중단: 테스트 실패 2회, 권한 필요, 범위 밖 파일 수정 필요 시 중단
출력: 변경 파일, 테스트 결과, 남은 리스크

이 템플릿은 에이전트를 느리게 만들기 위한 것이 아닙니다. 자동화가 멈춰야 할 지점을 미리 정해서, 사람이 개입해야 할 때를 명확히 만드는 장치입니다.

오늘 적용할 체크리스트

• autopilot 첫 적용 대상은 작고 되돌리기 쉬운 작업으로 제한한다.
• /fork는 병렬 구현보다 원인 가설 비교에 먼저 사용한다.
• MCP 서버는 읽기/쓰기 권한, 접근 범위, side effect를 표로 정리한다.
• headless 모드에서 로딩되는 플러그인과 MCP config를 고정한다.
• OpenTelemetry로 tool call 지연, 실패율, 권한 프롬프트 횟수를 수집한다.
• memory 저장 범위를 user와 repository로 나누고 금지 정보를 문서화한다.
• autopilot에는 중단 조건과 검증 명령을 반드시 포함한다.

Copilot CLI의 새 기능은 “자동으로 더 많이 하게 하는 기능”이 아니라 “자동화를 더 안전하게 운영하기 위한 기능”으로 봐야 합니다. 이 관점이 없으면 autopilot은 생산성 도구가 아니라 리뷰 부채 생성기가 됩니다.