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

AI 요약

• 무슨 일: GitHub이 2026년 6월 2일 Copilot app technical preview를 paid Copilot 사용자로 넓혔습니다.
  • 최신 Changelog 기준 대상은 기존 Copilot Pro, Pro+, Business, Enterprise 고객입니다.
  • headline addition은 사람과 agent가 같은 작업 객체를 편집하는 canvases입니다.
• 개발자 영향: agent session이 chat transcript가 아니라 issue, PR, worktree, browser, terminal 검증 루프로 이동합니다.
  • app은 parallel session, Agent Merge, MCP, skills, cloud sessions, scheduled automations를 한 표면에 묶습니다.
• 주의점: preview 기능이고, 6월 1일 usage-based billing 전환 직후라 반복 agent 작업의 비용 경계가 같이 따라옵니다.

GitHub은 2026년 6월 2일 Microsoft Build 2026 발표 묶음에서 Copilot app technical preview 확대를 공지했습니다. 최신 Changelog 문구 기준으로 기존 Copilot Pro, Pro+, Business, Enterprise 고객은 Windows, macOS, Linux용 Copilot app을 받을 수 있습니다. Copilot Free 사용자와 아직 Copilot을 쓰지 않는 사용자는 waitlist 대상입니다. 같은 공지에서 GitHub은 이번 release의 중심을 canvases라고 불렀습니다.

이 발표는 또 하나의 코딩 assistant UI가 나온 사건으로 보기 어렵습니다. GitHub이 설명한 Copilot app은 issue, pull request, prompt, prior session에서 agent session을 시작하는 데스크톱 표면입니다. session마다 git worktree와 branch를 분리하고, plan과 diff를 검토한 뒤 integrated terminal과 browser에서 검증합니다. GitHub 제품 블로그는 월간 commit이 14억 건을 넘었다고 적었습니다. 같은 글은 GitHub Actions 사용이 주당 20억 분을 넘는다고 밝히며, agentic workflow 증가를 app의 배경으로 제시했습니다.

캔버스는 이 구조에서 chat의 반대편에 놓입니다. GitHub은 canvas를 사람과 agent가 함께 쓰는 bidirectional work surface라고 설명합니다. agent가 작업하면서 canvas를 업데이트하고, 개발자는 같은 surface에서 edit, reorder, approve, redirect를 합니다. canvas가 덮을 수 있는 객체는 plan, pull request, browser session, terminal, release checklist, migration board, incident, spreadsheet, dashboard, cloud console, workflow state입니다. 채팅창에 묻힌 로그를 읽는 대신, 작업 객체 자체가 agent와 사람 사이의 shared state가 되는 설계입니다.

GitHub이 캔버스를 "agent experience, AX"의 시작이라고 부른 대목도 기사에서 빼기 어렵습니다. AX는 사람이 쓰는 UI만 설계하는 것이 아니라, 사람과 agent가 같은 화면에서 조작할 권한과 상태를 나누는 문제입니다. agent는 canvas state를 읽고 structured action을 취하며 결과를 다시 surface에 남깁니다. app은 canvas를 실제 artifact나 runtime에 연결하고, 어떤 action이 허용되는지 제한합니다. 이 구조에서는 prompt 품질보다 "어떤 객체를 agent에게 조작시킬 것인가"가 제품 설계의 단위가 됩니다.

2026년 5월 14일 첫 technical preview 발표와 비교하면 6월 2일 발표의 변화가 분명합니다. 5월 공지는 GitHub-native desktop experience, issue/PR 기반 시작, session별 branch와 file state, plan/diff review, terminal/browser validation, Agent Merge를 설명했습니다. 6월 2일 공지는 여기서 availability를 넓히고, canvas, voice conversations, cloud sessions, cloud automations, CLI session 통합, agentic browsing, /chronicle을 얹었습니다. app은 "agent를 한 번 호출하는 도구"에서 "여러 agent 작업을 관리하는 데스크톱 control center"로 이동했습니다.

GitHub Docs의 caveat도 같이 봐야 합니다. GitHub Docs는 Copilot app이 technical preview이며 변경될 수 있다고 적습니다. 같은 문서의 접근 안내는 Business와 Enterprise plan, 그리고 Pro/Pro+ waitlist를 설명합니다. 6월 2일 Changelog는 기존 Pro, Pro+, Business, Enterprise 고객에게 preview가 제공된다고 업데이트했습니다. 문서와 Changelog가 같은 날 완전히 정렬되지 않을 수 있으므로, 실제 팀 rollout에서는 조직의 preview feature 설정과 Copilot CLI policy를 확인해야 합니다.

개발팀이 바로 체감할 변화는 parallel session입니다. GitHub은 Copilot app에서 여러 agent session을 동시에 실행하고, 각 session을 자체 git worktree와 branch에 둔다고 설명합니다. 기존 CLI agent 사용자는 같은 저장소에서 여러 작업을 병렬로 돌릴 때 branch 충돌, uncommitted diff, terminal state를 직접 관리해야 했습니다. Copilot app은 이 작업을 UI와 session model로 흡수합니다. 이 말은 편의 기능이 늘었다는 뜻이면서, 동시에 session lifecycle이 GitHub 제품 안의 관리 객체가 된다는 뜻입니다.

Agent Merge는 이 lifecycle의 마지막 단계입니다. GitHub 제품 블로그는 Agent Merge가 review comments를 처리하고, failing checks를 고치고, merge condition이 만족될 때까지 기다릴 수 있다고 설명합니다. 개발자가 자동화를 어디까지 허용할지는 별도 선택입니다. "CI를 green으로 되돌리기", "피드백 반영", "조건 충족 시 merge"는 서로 다른 위험 수준입니다. security-sensitive code, payment flow, auth logic, data migration에서는 agent가 작성한 diff를 conventional PR review와 별도 test gate로 묶어야 합니다.

이번 release에서 agentic browsing이 들어간 점도 Copilot app의 성격을 바꿉니다. Changelog는 agent가 integrated browser를 drive해 click, type, screenshot을 수행하고 UI 변경을 end-to-end로 검증할 수 있다고 적었습니다. 이 기능은 frontend 개발에서 "코드를 바꿨다"와 "사용자 화면에서 동작한다" 사이의 간격을 줄입니다. 다만 browser driving은 외부 사이트, staging credential, test data에 접근할 수 있으므로, session마다 허용된 URL과 account scope를 분리해야 합니다.

Voice conversations는 편의 기능처럼 보이지만 enterprise policy와 연결됩니다. GitHub은 app release note에서 voice conversations가 on-device speech-to-text를 사용해 audio가 machine을 떠나지 않는다고 밝혔습니다. 같은 날 Copilot CLI refresh도 voice input을 설명하며 최초 사용 때 runtime과 speech-to-text model을 내려받는 절차를 언급했습니다. regulated environment에서 음성 입력을 켤지 결정하려면, 오디오가 외부로 전송되지 않는다는 설명과 로컬 모델 다운로드 경로를 내부 정책에 맞춰 검토해야 합니다.

/chronicle은 또 다른 운영 신호입니다. GitHub은 이 명령이 Copilot agent session data를 조회하며, 사용자가 지금 보고 있지 않은 session도 포함한다고 설명합니다. agent 작업이 늘어나면 필요한 것은 더 긴 chat history가 아니라 "어떤 session에서 어떤 file을 만졌고 어떤 PR을 언급했는가"를 찾는 검색입니다. /chronicle은 agent session이 개인 대화 기록에서 팀 운영 데이터로 이동하고 있음을 보여주는 기능입니다.

이 발표는 6월 1일 Copilot usage-based billing 전환 직후에 나왔습니다. GitHub은 6월 1일 모든 Copilot plan이 GitHub AI Credits 기반 사용량 과금으로 이동했고, Copilot code review는 private repository에서 GitHub Actions minutes도 소비한다고 공지했습니다. 6월 2일 app 발표는 cloud sessions와 cloud automations를 함께 내놓았습니다. 반복 agent 작업은 prompt를 사람이 매번 누르지 않아도 token usage를 만들 수 있습니다. 따라서 app 도입 논의는 기능 평가와 비용 budget을 분리해서 진행하기 어렵습니다.

Reddit의 r/GithubCopilot 반응도 이 비용 질문을 비켜가지 않았습니다. 6월 2일 전후 게시글들은 Copilot을 계속 쓸 이유, usage-based billing 이후 대안, AI Credits 소진 가능성을 묻고 있었습니다. 한 사용자는 GitHub platform 자체와 무료 혜택 외에 Copilot agent, CLI, SDK를 유지할 이유가 있는지 물었습니다. 댓글에서는 VS Code native integration, GitHub Actions와 Cloud Agents 통합, targeted context input, 여러 model provider 선택이 장점으로 언급됐습니다. 대표성 있는 설문은 아니지만, 새 app 발표가 곧바로 platform value와 비용 논쟁으로 이어진다는 점은 분명합니다.

다른 Reddit 글은 Copilot이 "성공의 희생자"가 됐는지 물었습니다. 글쓴이는 2026년의 한 prompt가 repository scan, documentation retrieval, knowledge base search, tool invocation, workflow coordination, large context reasoning을 포함할 수 있다고 썼습니다. 이 관찰은 GitHub의 제품 방향과 맞물립니다. Copilot app의 canvas, browser, terminal, automation은 모두 한 prompt의 작업량을 키우는 기능입니다. 같은 "질문 1회"라도 2024년의 autocomplete와 2026년의 agent session은 비용 구조가 다릅니다.

경쟁 구도에서는 OpenAI Codex desktop app, Claude Code, Cursor, Google Antigravity, JetBrains AI가 모두 다른 방식으로 같은 문제를 풀고 있습니다. Codex와 Claude Code는 local workspace와 terminal 중심으로 강한 agent loop를 제공합니다. Cursor는 editor 안에서 diff와 chat을 결합합니다. Antigravity는 Google 계정과 Gemini 생태계를 앞세웁니다. GitHub Copilot app의 차별점은 repository object입니다. issue, PR, branch, check, Actions, review rule이 이미 GitHub에 있는 팀에게는 agent session을 별도 업무 도구로 옮기지 않아도 됩니다.

그 장점은 lock-in 질문과 붙어 있습니다. Copilot app이 편해질수록 agent 작업의 source of truth는 GitHub 안으로 더 깊게 들어갑니다. session data, canvas state, Agent Merge, automation owner, AI Credits usage가 GitHub control plane에 쌓입니다. GitHub을 이미 개발 운영의 중심으로 쓰는 팀에는 자연스러운 선택입니다. 여러 forge, self-hosted Git, 별도 CI, 사내 approval system을 쓰는 조직에는 "app이 편한가"보다 "우리 운영 기록을 어디에 남길 것인가"가 먼저입니다.

캔버스는 특히 human review의 형태를 바꿀 수 있습니다. 지금까지 agent review는 chat transcript, generated diff, test log를 따로 읽는 일이었습니다. canvas가 plan, PR, browser session, terminal을 하나의 조작 가능한 객체로 보여주면 reviewer는 더 빨리 판단할 수 있습니다. 하지만 canvas가 보여주는 요약이 review 자체를 대체하지는 않습니다. reviewer는 여전히 diff, test result, permission change, dependency update, data migration을 확인해야 합니다. canvas의 가치는 판단을 대신하는 데 있지 않고, 판단할 evidence를 한곳에 모으는 데 있습니다.

보안 경계는 cloud/local sandbox 발표와 함께 읽어야 합니다. GitHub 제품 블로그는 agent가 코드를 실행하고 결과를 검사하며 반복하려면 production을 건드리지 않는 bounded place가 필요하다고 설명합니다. local sandbox는 파일시스템, 네트워크, system capability 접근을 제한하는 isolated environment입니다. cloud sandbox는 GitHub이 hosted하는 isolated ephemeral Linux environment입니다. Copilot app에서 agentic browsing과 terminal validation이 늘어날수록, sandbox policy는 선택적 hardening이 아니라 기본 운영 조건이 됩니다.

조직별 rollout checklist는 다섯 가지로 줄일 수 있습니다. 첫째, preview access입니다. Changelog와 Docs의 접근 안내를 모두 확인하고, Business/Enterprise에서는 preview features와 Copilot CLI policy를 켭니다. 둘째, session policy입니다. 어떤 repository에서 parallel session을 허용하고, worktree cleanup을 누가 확인할지 정합니다. 셋째, canvas review rule입니다. canvas에서 approve할 수 있는 항목과 PR review가 반드시 필요한 항목을 분리합니다. 넷째, browser/terminal permission입니다. agent가 방문할 수 있는 host와 실행할 수 있는 command를 제한합니다. 다섯째, cost budget입니다. cloud session과 automation의 trigger 빈도, model 선택, owner를 기록합니다.

GitHub Copilot app의 6월 2일 발표는 "데스크톱 앱 출시"보다 "agent 작업을 검토 가능한 작업면으로 바꾸려는 시도"에 가깝습니다. 개발자는 더 이상 agent가 남긴 긴 채팅 기록을 끝까지 읽는 방식만으로 품질을 관리하기 어렵습니다. GitHub의 답은 issue, PR, worktree, terminal, browser, automation을 canvas와 session으로 묶는 것입니다. 이 구조가 성공하려면 팀은 prompt 작성법보다 먼저 권한, 비용, 검증, 감사 기록을 제품 사용 규칙으로 만들어야 합니다.