Copilot 앱 프리뷰 확대, 채팅 밖으로 나온 에이전트 캔버스

AI 요약

• 무슨 일: GitHub가 2026년 6월 2일 Copilot app technical preview를 기존 유료 Copilot 사용자에게 확대했습니다.
  • 대상은 Copilot Pro, Pro+, Business, Enterprise이며 Free 사용자와 미가입자는 waitlist에 남습니다.
• 새 표면: canvases는 계획, PR, 브라우저, 터미널, 배포 상태를 사람과 에이전트가 함께 고치는 작업 화면입니다.
• 실무 영향: Copilot의 경쟁축이 코드 제안에서 세션 격리, 검토, 자동화, 감사 로그로 이동합니다.
  • GitHub Docs는 cloud agent에 human review, firewall, hidden character filtering, signed commit, session log를 mitigation으로 둡니다.

GitHub가 2026년 6월 2일 Microsoft Build 2026 발표에서 GitHub Copilot app technical preview를 확대했습니다. 이제 기존 Copilot Pro, Pro+, Business, Enterprise 사용자는 Windows, macOS, Linux용 Copilot 앱을 받을 수 있습니다. Copilot Free 사용자와 아직 Copilot을 쓰지 않는 사용자는 waitlist 대상입니다. 발표의 표면은 데스크톱 앱이지만, 실제 변화는 coding agent의 작업 단위를 채팅창 밖으로 꺼내는 쪽에 있습니다.

GitHub Blog는 Copilot 앱을 "agent-native desktop experience"로 설명했습니다. 앱은 issue, pull request, prompt, prior session에서 작업을 시작하고, connected repositories의 active session, issue, pull request, background automation을 My work에서 보여줍니다. 각 session은 별도 git worktree와 branch에서 돌아가고, 사용자는 plan과 diff를 읽은 뒤 integrated terminal과 browser에서 결과를 검증하고 pull request로 넘길 수 있습니다. Copilot이 코드를 제안하는 도구에서 여러 에이전트 작업을 관리하는 화면으로 넓어지는 셈입니다.

최근 GitHub Copilot 뉴스는 많았습니다. 6월 1일에는 usage-based billing과 Copilot code review의 Actions minutes 소비가 시작됐고, 6월 2일에는 Copilot SDK GA와 Copilot CLI refresh가 나왔습니다. 6월 3일에는 VS Code Copilot May releases가 Agents Window, remote agents, BYOK, terminal risk assessment를 묶어 공개했습니다. 이번 글은 그중에서도 Copilot 앱과 캔버스에 집중합니다. 같은 Copilot 이름이지만, 여기서 쟁점은 모델 성능이 아니라 작업 상태를 어디에 남기고 어떻게 검토할지입니다.

Copilot 앱은 에이전트 작업의 조종석을 노립니다

GitHub Docs는 Copilot 앱을 "agent-driven development"용 데스크톱 애플리케이션으로 정의합니다. 문서 기준 앱은 parallel workstreams, GitHub integration, PR lifecycle management를 한곳에 묶습니다. 개발자는 issue를 고르거나 빈 workspace에서 시작하고, Interactive, Plan, Autopilot 같은 session mode를 선택하며, 모델과 reasoning effort도 session 단위로 고릅니다. 작업이 끝나면 앱 안에서 pull request를 만들고, 리뷰를 남기고, CI 통과 여부를 확인하고, merge까지 이어갈 수 있습니다.

이 설명에서 중요한 명사는 session입니다. Copilot 앱은 에이전트가 한 번 답하고 끝나는 채팅이 아니라, branch와 worktree와 검증 기록을 가진 작업 단위를 전제로 합니다. GitHub Blog는 한 개발자가 production bug 조사, backlog issue 구현, review feedback 처리 같은 세 가지 일을 동시에 진행하는 장면을 예로 듭니다. 한 agent가 실패 로그를 보고 있고, 다른 agent가 새 기능을 만들고, 또 다른 agent가 PR feedback을 반영한다면 사람에게 필요한 것은 더 긴 transcript가 아니라 어느 session이 어떤 상태인지 보는 화면입니다.

GitHub가 공개한 플랫폼 수치도 이 방향을 뒷받침합니다. 발표문은 GitHub commits가 전년 대비 거의 두 배 늘어 월 14억 건을 넘었고, GitHub Actions 사용량은 주 20억 분 이상이라고 적었습니다. 이 수치는 Copilot 앱의 품질을 증명하지는 않습니다. 다만 GitHub가 agentic workflow를 repository, pull request, Actions, API usage 증가와 같은 플랫폼 부하 문제로 보고 있다는 점은 드러냅니다. 에이전트가 더 많은 branch와 PR을 만들수록 검토와 CI와 감사 기록은 제품의 중심 기능이 됩니다.

캔버스는 채팅 옆의 공유 작업 표면입니다

이번 발표의 새 단어는 canvases입니다. GitHub changelog는 캔버스를 사람과 에이전트가 함께 쓰는 bidirectional work surface라고 설명합니다. 에이전트는 작업 중 캔버스를 업데이트하고, 사용자는 같은 표면에서 수정, 재정렬, 승인, 방향 전환을 할 수 있습니다. 대상 work object는 plan, pull request, browser session, terminal, release checklist, migration board처럼 넓게 잡혀 있습니다. Incident, spreadsheet, dashboard, cloud console, workflow state도 같은 목록에 들어갑니다.

GitHub Docs의 canvas extension 문서는 이 개념을 더 구체적으로 만듭니다. 캔버스 확장은 plan, triage board, browser session, release checklist, dashboard, incident, spreadsheet 같은 artifact를 위한 shared interactive surface입니다. 예를 들어 agentic kanban canvas를 만들면 사람은 UI control로 카드를 만들거나 옮기고, 에이전트는 get_board, add_card, move_card 같은 agent-callable capability를 호출할 수 있습니다. 같은 board state가 사람의 버튼 조작과 에이전트의 tool call 사이를 오갑니다.

구현 위치도 문서에 나옵니다. 팀 공유 캔버스는 repository의 .github/extensions 아래에 둘 수 있고, 개인 캔버스는 ~/.copilot/extensions 아래에 둘 수 있습니다. 일반적인 확장은 metadata와 dependency를 위한 package.json, 캔버스 동작과 capability를 정의하는 extension.mjs, 필요하면 persisted state를 위한 JSON artifact를 포함합니다. 이 구조는 캔버스가 단순한 화면 장식이 아니라 repository 안에 남길 수 있는 개발 워크플로 확장이라는 뜻입니다.

캔버스가 해결하려는 문제는 "에이전트가 무슨 생각을 했는지"보다 "현재 작업 객체가 어떤 상태인지"에 가깝습니다. 긴 채팅 transcript에는 계획, 로그, 실패, 수정 요청, 승인, 결과 요약이 시간순으로 섞입니다. 캔버스는 그중 plan, PR, checklist, browser session 같은 특정 객체를 따로 꺼냅니다. 사용자는 prompt로 설명하지 않고 UI에서 항목을 옮기거나 승인할 수 있고, 에이전트는 그 변경된 state를 근거로 다음 행동을 합니다.

클라우드 세션과 자동화가 붙으면 검토선이 먼저 보입니다

Copilot 앱 발표는 캔버스만 따로 떨어져 있지 않습니다. 같은 GitHub Blog 글은 local/cloud sandboxes, Agent Merge, cloud automations, Memory++와 /chronicle, partner-built agent apps를 한 묶음으로 소개합니다. Local sandbox는 사용자의 machine에서 filesystem, network, system capability 접근을 제한하는 방식이고, cloud sandbox는 GitHub가 호스팅하는 fully isolated ephemeral Linux environment입니다. GitHub는 조직이 정책을 정하고, 사용자는 cloud session을 다른 장치에서도 이어받을 수 있다고 설명합니다.

이 구조에서 개발자가 봐야 할 것은 편의성만이 아닙니다. GitHub Docs의 cloud agent risk 문서는 draft pull request가 사람의 review와 merge를 거쳐야 한다고 적습니다. Copilot cloud agent는 자신이 만든 PR을 ready for review로 바꾸거나 approve하거나 merge할 수 없습니다. 기본적으로 workflow run도 사람의 승인 전에는 실행되지 않습니다. 사용자가 에이전트에게 일을 맡긴 뒤에도 branch protection과 required approval을 건너뛰지 않게 만드는 장치입니다.

민감 정보와 prompt injection 경계도 문서에 들어 있습니다. GitHub는 Copilot cloud agent가 code와 민감 정보에 접근할 수 있고, 실수나 악성 입력으로 leak될 수 있다고 설명합니다. mitigation으로는 cloud agent의 internet access 제한을 들고, issue나 PR comment에 숨겨진 message가 prompt injection으로 작동할 수 있다는 점도 명시합니다. HTML comment 같은 hidden character는 agent에 넘기기 전에 filtering한다는 설명이 붙습니다.

감사 추적도 제품 기능입니다. GitHub Docs는 Copilot cloud agent commit이 Copilot authored commit으로 남고, 작업을 요청한 개발자가 co-author로 표시되며, commit은 signed 상태로 표시된다고 설명합니다. Session log와 audit log event는 administrator가 볼 수 있고, agent-authored commit message에는 session log 링크가 들어갑니다. 에이전트가 만든 결과를 "AI가 했습니다"라는 문장으로 끝내지 않고, 누가 요청했고 어떤 session에서 어떤 commit이 나왔는지 추적하는 방식입니다.

CLI와 앱이 같은 작업 기록을 공유합니다

Copilot app 확대와 같은 날 GitHub는 Copilot CLI refresh도 공개했습니다. CLI changelog에는 rubber duck과 voice input의 GA, /experimental 모드의 prompt scheduling, 새 terminal interface, issue·pull request·gist tab이 포함됐습니다. 발표문에는 Copilot CLI에서 시작한 session이 Copilot 앱의 My work에 나타나고, copilot --cloud 뒤의 cloud session 기능이 앱 UI로 들어온다는 설명도 있습니다.

이 연결은 GitHub가 Copilot을 한 가지 UI로 제한하지 않는다는 뜻입니다. 개발자는 terminal에서 시작한 작업을 앱에서 확인하고, 앱에서 cloud session을 돌린 뒤 다른 장치에서 이어 볼 수 있습니다. /chronicle은 이전 Copilot agent session 데이터를 질의하는 명령으로 소개됐습니다. 기능 이름만 보면 작아 보이지만, 긴 agent work에서는 "지난번 session이 어떤 결정을 했는가"가 실제 생산성 문제가 됩니다.

다만 Copilot CLI의 prompt scheduling은 발표 직후 표현이 수정됐습니다. GitHub changelog에는 2026년 6월 3일 editor's note가 붙어 prompt scheduling이 일반 제공이 아니라 /experimental 일부라고 바로잡았습니다. 이 세부 정정은 technical preview 제품을 다룰 때 중요합니다. Copilot 앱과 캔버스 역시 GitHub Docs가 technical preview이며 subject to change라고 명시합니다. 팀 도입 판단은 제품 방향과 현재 제약을 분리해서 봐야 합니다.

경쟁 기준은 모델 이름보다 작업 검토 단위입니다

Copilot 앱의 경쟁 상대는 단순히 다른 chat assistant가 아닙니다. Cursor, Windsurf, JetBrains AI Assistant, Google Antigravity, VS Code Agents Window처럼 개발자가 에이전트를 실행하고 검토하는 표면 전체가 비교 대상입니다. 이 영역에서 모델 이름은 한 항목일 뿐입니다. 더 직접적인 질문은 session이 독립 branch에서 안전하게 돌 수 있는지, 실패 로그와 diff가 남는지, PR 리뷰와 CI가 한 화면에서 이어지는지, 원격 실행이 끊겨도 추적 가능한지입니다.

GitHub의 강점은 code host 자체를 갖고 있다는 점입니다. Issue, pull request, Actions, branch protection, audit log, signed commit, organization policy가 이미 GitHub 안에 있습니다. Copilot app과 canvases는 이 기존 객체를 에이전트 UI의 재료로 씁니다. 반대로 약점도 같습니다. GitHub workflow 밖의 Jira, Linear, Slack, cloud console, internal deployment dashboard까지 실제 팀의 작업 객체를 얼마나 자연스럽게 캔버스에 붙일 수 있는지가 다음 검증 포인트입니다.

Partner-built agent apps 목록도 이 문제의 답을 넓히려는 시도입니다. GitHub Blog는 LaunchDarkly, Bright, Amplitude, Sonar, Endor Labs, Octopus Deploy, Packfiles, PagerDuty, Miro 같은 파트너를 언급했습니다. 에이전트가 issue만 고치는 수준을 넘어 feature flag, observability, security scan, deployment, incident response로 들어가려면 각 제품의 상태와 승인 동작이 필요합니다. 캔버스는 그 상태를 사람이 볼 수 있는 표면으로 만드는 인터페이스 후보입니다.

팀이 지금 확인할 질문

첫째, Copilot app을 켤 수 있는 사용자 범위입니다. Pro, Pro+, Business, Enterprise는 technical preview를 받을 수 있지만, Business와 Enterprise는 조직 또는 enterprise가 preview features와 Copilot CLI를 켜야 하는 조건이 붙습니다. Free 사용자는 waitlist입니다. 내부 파일과 이슈를 다루는 도구이므로 개인별 설치보다 org policy가 먼저입니다.

둘째, session mode와 승인 정책입니다. Interactive, Plan, Autopilot은 같은 "Copilot 사용"으로 묶기 어렵습니다. Plan mode에서 사람 승인 후 실행하는 작업과 Autopilot에서 긴 작업을 맡기는 작업은 위험 경계가 다릅니다. 캔버스가 생기면 승인 지점이 prompt 답변이 아니라 checklist, PR state, terminal action, deployment state 같은 work object에 걸릴 수 있습니다.

셋째, cloud sandbox와 automation의 네트워크 경계입니다. GitHub는 cloud agent의 internet access 제한과 firewall customisation을 mitigation으로 설명합니다. Automation은 schedule이나 event에 의해 사람의 즉시 개입 없이 실행될 수 있고, untrusted user event가 prompt에 들어갈 가능성도 있습니다. GitHub Docs는 tool allowlist와 untrusted event 기본 무시를 mitigation으로 둡니다. 팀은 자동화가 어떤 tool을 호출할 수 있는지 먼저 적어야 합니다.

넷째, 캔버스 확장을 repository에 둘지 개인 환경에 둘지입니다. .github/extensions에 들어간 캔버스는 팀 workflow가 되고, ~/.copilot/extensions에 들어간 캔버스는 개인 작업대가 됩니다. PR triage board, release checklist, incident dashboard처럼 팀 합의가 필요한 표면은 repository scope가 자연스럽습니다. 개인 day planner나 임시 markdown canvas는 user scope가 맞습니다.

이번 발표는 Copilot이 코드 자동완성의 다음 기능을 추가했다는 이야기로 읽기에는 좁습니다. GitHub는 Copilot 앱, 캔버스, cloud/local sandbox, Agent Merge, CLI session, automation, audit log를 한 시스템으로 묶고 있습니다. 개발자에게 새로 생긴 질문은 "AI가 코드를 얼마나 잘 쓰나"에서 "에이전트가 만든 작업을 어떤 표면에서 보고, 어디서 승인하고, 어떤 로그로 남길 것인가"로 이동합니다. Copilot 캔버스는 그 질문에 대한 GitHub의 첫 번째 UI 답안입니다.