Copilot CLI 예약 명령 GA, 터미널 에이전트가 스스로 반복 실행

AI 요약

• 무슨 일: GitHub이 2026년 6월 2일 Copilot CLI에 /every, /after, Rubber Duck, 음성 입력을 GA로 추가했습니다.
  • 새 terminal UI는 /experimental에서 시험하며, issue, PR, gist tab을 CLI 안에서 전환합니다.
• 개발자 영향: 테스트 실행, PR 확인, usage 점검 같은 반복 작업을 열린 CLI session 안에 예약할 수 있습니다.
  • GitHub Docs 기준 schedule은 생성된 session이 실행 중일 때만 trigger됩니다.
• 주의점: Rubber Duck은 파일을 직접 고치지 않는 critic agent이고, 반복 실행은 비용, 권한, 승인 정책과 함께 설계해야 합니다.

GitHub이 2026년 6월 2일 Microsoft Build 2026 발표 묶음에서 Copilot CLI refresh를 공개했습니다. 공식 changelog는 Rubber Duck, prompt scheduling, voice input이 generally available 상태가 됐다고 밝혔습니다. 같은 공지는 tabs가 들어간 새 terminal experience를 /experimental로 시험할 수 있다고 설명했습니다. 전날인 6월 1일 Copilot usage-based billing 전환이 적용됐고, 같은 날 Copilot app canvas 확대도 발표됐습니다. 이번 CLI 업데이트는 그 흐름을 데스크톱 앱이 아니라 터미널 세션 안으로 가져온 사건입니다.

이번 발표에서 개발자가 바로 만질 기능은 네 가지입니다. 첫째, /every와 /after로 현재 Copilot CLI session에 반복 또는 1회 지연 프롬프트를 등록합니다. 둘째, Rubber Duck agent가 계획, 설계, 구현, 테스트에 대한 두 번째 의견을 줍니다. 셋째, 음성 입력은 space bar hold 또는 Ctrl+X, V 조합으로 프롬프트를 받아 적습니다. 넷째, 실험적 terminal UI는 repository 안에서 Tab으로 Session, Issues, Pull requests, Gists를 전환합니다. 기능 목록은 짧지만, 공통점은 agent가 터미널에서 더 오래 머무는 방향입니다.

/every와 /after는 이 발표의 운영상 변화입니다. GitHub는 changelog에서 /every 30m run the frontend tests와 /every 1h how many tokens have I used during the past hour를 예시로 들었습니다. 1회 지연 실행 예시는 /after 2h /example-skills:docx create a new file summarizing recent changes to this repo였습니다. 여기서 프롬프트는 단발 질문이 아니라 session에 걸어두는 timer가 됩니다. 테스트, PR 확인, token usage 점검처럼 사람이 기억해야 했던 반복 확인이 agent session의 scheduling surface로 이동합니다.

GitHub Docs의 scheduling 문서는 이 기능의 경계를 분명히 적습니다. /every는 fixed interval마다 prompt를 submit하고, /after는 지정한 delay 뒤 한 번 submit한 뒤 schedule list에서 제거됩니다. 단위 suffix는 s, m, h, d이고, bare number는 minute로 해석됩니다. 문서 기준 최소 interval은 10초, 최대 interval은 1일입니다. /every나 /after를 인수 없이 입력하면 현재 session의 schedule manager가 열리고, 사용자는 활성 schedule을 보고 삭제할 수 있습니다.

자동화라고 부르기 전에 봐야 할 제약도 있습니다. 같은 문서는 schedule이 생성된 interactive CLI session이 실행 중일 때만 trigger된다고 설명합니다. session을 닫으면 반복 실행도 멈춥니다. --continue나 --resume으로 session을 다시 열면 schedule은 재시작되고, interval은 reopen 시점부터 다시 계산됩니다. /after schedule이 닫기 전에 실행되지 않았다면 reopened session에서 delay 뒤 실행됩니다. 즉 이 기능은 cloud cron이 아니라 "살아 있는 agent session 안의 예약 프롬프트"입니다.

이 차이는 팀 운영에서 큽니다. "매일 오전 9시에 issue triage"처럼 컴퓨터가 꺼져도 돌아야 하는 업무라면, interactive schedule보다 외부 scheduler나 Copilot app workflow가 맞습니다. GitHub의 programmatic CLI 문서는 copilot -p "YOUR PROMPT" 실행 방식을 설명합니다. 이 명령은 cron, Windows Task Scheduler, CI/CD pipeline에서 쓸 수 있습니다. 반대로 "현재 작업하는 동안 30분마다 frontend test를 돌려 새 failure를 알려줘" 같은 업무라면 session-scoped /every가 더 직접적입니다.

Rubber Duck은 반복 실행과 다른 종류의 자동화입니다. GitHub Changelog는 이 기능을 built-in CLI agent이자 constructive critic으로 설명했습니다. main CLI agent가 현재 plan, design, implementation, tests를 Rubber Duck에게 넘기면, Rubber Duck은 blind spot, design flaw, substantive issue를 찾고 concrete feedback을 돌려줍니다. 이후 Copilot이 그 critique를 고려해 계속 진행합니다. 사용자는 /rubber-duck으로 수동 호출할 수도 있습니다.

GitHub Docs의 Rubber Duck 문서는 더 구체적인 제약을 적습니다. Rubber Duck은 proposed change를 review하도록 설계됐고, 파일 변경을 직접 만들지 않습니다. feedback을 반영할지 결정하는 쪽은 main agent입니다. 또 현재 main agent가 Claude 또는 GPT large language model을 사용할 때만 이용할 수 있습니다. 문서는 Rubber Duck이 session을 driving하는 모델과 다른 AI model을 사용해 second opinion을 준다고 설명합니다. 제품 구조상 "같은 모델에게 한 번 더 물어보기"가 아니라 critic role을 분리한 설계입니다.

이 기능은 agentic coding에서 작은 품질 게이트가 제품 기능이 된 사례입니다. 사람 개발자는 중요한 변경 전 동료에게 plan을 설명하거나, PR 전에 테스트 설계를 확인받습니다. Rubber Duck은 그 관행을 CLI agent의 내부 단계로 넣습니다. 물론 이것이 human review를 대체하지는 않습니다. 보안 권한, data migration, billing logic, auth flow 같은 변경에서는 사람이 diff와 test result를 봐야 합니다. Rubber Duck의 실용적 위치는 "PR을 열기 전에 agent가 자기 계획과 테스트를 한 번 더 검토하게 하는 장치"에 가깝습니다.

새 terminal UI는 GitHub workflow와 연결됩니다. Changelog는 /experimental mode에서 theme-aware semantic colors, narrow terminal에서도 읽을 수 있는 responsive components, screen reader 감지 시 자동 활성화되는 accessibility support를 설명했습니다. repository 안에서는 Tab으로 Session view, Issues, Pull requests, Gists tab을 오갈 수 있습니다. 터미널 안에서 issue와 PR을 보는 일이 가능해지면, Copilot CLI는 단순한 local code assistant보다 GitHub 작업 큐를 처리하는 console에 가까워집니다.

GitHub의 public repository인 github/copilot-cli는 이 방향을 README에서 확인시켜 줍니다. README는 Copilot CLI가 GitHub의 Copilot coding agent와 같은 agentic harness로 동작하며, GitHub workflow에 깊게 통합된다고 설명합니다. 설치 방식은 install script, Homebrew, WinGet, npm을 지원합니다. 2026년 6월 2일 기준 repository에는 1.0.59 최신 release가 표시됐고, README는 기본 모델이 Claude Sonnet 4.5이며 /model 명령으로 Claude Sonnet 4와 GPT-5 등 다른 모델을 고를 수 있다고 적었습니다.

음성 입력은 접근성 기능이면서 privacy 문구가 붙은 기능입니다. GitHub Changelog는 Copilot CLI가 hands-free dictation을 포함하며, 첫 사용 때 runtime과 speech-to-text model 다운로드를 안내한다고 밝혔습니다. 더 민감한 부분은 음성 입력이 local에서 실행되고 녹음한 audio가 machine을 떠나지 않는다는 설명입니다. regulated environment에서는 이 문구가 도입 검토의 시작점입니다. 실제 rollout에서는 어떤 runtime과 speech-to-text model을 내려받는지, 조직의 endpoint allowlist와 device policy에 맞는지 확인해야 합니다.

이 발표는 전날 Copilot 과금 전환과 분리해서 읽기 어렵습니다. GitHub은 2026년 6월 1일부터 모든 Copilot plan의 usage-based billing이 live 상태가 됐다고 공지했습니다. Copilot code review는 AI Credits와 GitHub Actions minutes를 함께 소비합니다. /every가 곧바로 대규모 청구를 만든다는 뜻은 아닙니다. 다만 반복 schedule이 열리면 "사람이 매번 눌렀던 prompt"가 "session이 살아 있는 동안 자동으로 반복되는 prompt"로 바뀝니다. 조직은 반복 주기, model, tool permission, repository scope를 같은 표에서 봐야 합니다.

보안 질문도 같은 이유로 다시 올라옵니다. HN에는 과거 Copilot CLI가 악성 명령을 실행했다는 주장과 그 반박을 둘러싼 토론이 있었습니다. 토론의 핵심은 folder trust, explicit approval, indirect prompt injection 해석이었습니다. 이번 /every 기능은 새로운 취약점 공지가 아니지만, 운영 형태는 달라집니다. 사용자가 한 번 만든 schedule이 30분마다 repository를 읽고 test를 실행한다면, 승인 prompt, trusted folder, MCP server, shell command policy가 반복 실행의 일부가 됩니다.

GitHub은 CLI가 "full control"을 제공하고 action preview 없이는 아무 일도 일어나지 않는다고 README에서 설명합니다. 이 원칙은 interactive work에서는 이해하기 쉽습니다. 반복 schedule에서는 팀 규칙이 더 필요합니다. 예를 들어 /every 30m run the test suite는 비교적 안전하지만, /every 30m fix any failing test and commit은 다릅니다. 후자는 file write, shell execution, git operation, possibly network access를 묶습니다. schedule syntax보다 prompt boundary가 더 중요한 이유입니다.

경쟁 제품과 비교하면 GitHub의 선택은 GitHub object에 가까운 terminal agent입니다. Claude Code는 /loop와 skill, subagent 패턴을 앞세우고, OpenAI Codex는 desktop app과 automation surface를 넓히고 있습니다. Cursor와 JetBrains는 editor 안의 diff와 context를 강조합니다. Copilot CLI는 issue, PR, gist, GitHub MCP, Copilot code review, Actions billing과 자연스럽게 이어집니다. GitHub을 source of truth로 쓰는 팀에는 이 통합이 장점이고, 여러 forge와 내부 CI를 섞는 팀에는 scope 관리가 먼저입니다.

GeekNews에는 Copilot CLI 공개 프리뷰 당시 "claude만큼 유용하다면 좋겠다"는 짧은 댓글이 남아 있습니다. 이 반응은 2025년 terminal agent 시장의 기준점이 Claude Code였음을 보여줍니다. 2026년 6월 update에서 GitHub은 같은 경쟁을 model 성능 하나로 풀지 않았습니다. 반복 schedule, critic agent, GitHub tab, voice input처럼 작업 환경을 구성하는 기능을 넣었습니다. 모델이 무엇을 답하느냐보다 "agent가 어느 표면에서 얼마나 오래 일하고, 누가 검토하고, 언제 다시 실행되는가"가 제품 차별점이 됐습니다.

개발팀이 바로 시험할 수 있는 사용법은 좁게 잡는 편이 좋습니다. 첫 번째 후보는 읽기 전용 반복 확인입니다. /every 30m summarize new comments on my open pull requests처럼 PR 상태를 보고 알려주는 작업은 file write가 없습니다. 두 번째 후보는 테스트 실행입니다. /every 30m run the frontend tests and summarize new failures는 shell execution이 있지만 변경을 만들지 않습니다. 세 번째 후보는 delayed review입니다. 큰 refactor를 맡긴 뒤 /after 20m /rubber-duck review the current plan and test strategy처럼 critic을 따로 넣을 수 있습니다.

반대로 처음부터 자동 수정과 commit까지 맡기는 schedule은 피해야 합니다. 반복 schedule이 failed test를 고치고 commit하는 순간, 문제는 Copilot CLI 기능이 아니라 release engineering policy가 됩니다. 어떤 branch에 쓸 수 있는지, commit author는 누구인지, CI failure가 반복될 때 어디에서 멈추는지, AI Credits나 Actions minutes를 누가 부담하는지 정해야 합니다. schedule manager가 제공됐다는 사실은 prompt를 편하게 등록하게 해주지만, 운영 책임을 대신 정해주지는 않습니다.

Rubber Duck도 과신하면 안 됩니다. critic agent는 blind spot을 찾는 데 도움이 되지만, 같은 tool context와 같은 repository snapshot에서 출발합니다. 잘못된 요구사항, 누락된 business rule, 외부 API 계약 변화, 보안 정책 예외는 사람이 제공하지 않으면 모델이 알 수 없습니다. 좋은 사용법은 "이 plan에서 migration rollback이 빠졌는지 봐줘", "이 test가 auth boundary를 충분히 덮는지 검토해줘"처럼 검토 기준을 구체화하는 것입니다. 그러면 Rubber Duck은 일반적인 찬반보다 실행 가능한 issue list를 만들 가능성이 높습니다.

Copilot CLI refresh의 신호는 명확합니다. GitHub은 agent를 editor autocomplete의 연장선에 두지 않고, terminal session 안에서 반복 실행하고, 다른 model에게 검토받고, GitHub object를 읽으며, 음성으로 prompt를 받는 작업자에 가깝게 만들고 있습니다. 개발자에게 새 질문은 "Copilot CLI를 쓸까"보다 "어떤 반복 작업을 열린 session 안에 둘 수 있고, 어떤 작업은 cloud scheduler나 CI로 보내야 하는가"입니다.

6월 2일 발표의 실무 결론은 세 가지입니다. /every와 /after는 장시간 로컬 작업 중 잊기 쉬운 확인을 줄입니다. Rubber Duck은 agent가 PR을 만들기 전 자체 검토 단계를 추가합니다. 새 terminal UI와 voice input은 CLI를 더 오래 켜두는 방향으로 설계됐습니다. 이 세 가지가 함께 들어오면 Copilot CLI는 질문 창이 아니라 세션 단위의 자동화 표면이 됩니다. 팀은 기능보다 먼저 session lifetime, prompt boundary, tool permission, budget owner를 정해야 합니다.

출처

• GitHub Changelog, Copilot CLI refresh.
• GitHub Docs, Scheduling prompts in GitHub Copilot CLI.
• GitHub Docs, About the rubber duck agent.
• GitHub, github/copilot-cli repository.
• GitHub Docs, Running GitHub Copilot CLI programmatically.
• GeekNews, GitHub Copilot CLI 공개 프리뷰 출시.