GitHub가 2026년 5월 14일 GitHub Copilot app technical preview를 공개했습니다.

이번 앱은 기존 IDE 플러그인이나 CLI만의 연장이 아닙니다.
GitHub 이슈, PR, prompt, 이전 session에서 작업을 시작하고, 에이전트가 만든 변경사항을 검토·검증·PR까지 이어가도록 만든 GitHub-native 데스크톱 환경입니다.

AI 코딩 도구가 “코드 에디터 안의 보조 채팅”에서 “작업 단위의 실행 환경”으로 이동하는 흐름을 보여주는 발표입니다.

무엇이 공개됐나

GitHub 설명 기준으로 Copilot app은 agentic development를 위한 데스크톱 경험입니다.

핵심은 세 가지입니다.

  1. GitHub context에서 시작한다.
  2. 작업을 session 단위로 분리한다.
  3. 변경사항을 검증하고 PR로 연결한다.

사용자는 이슈, PR, prompt, 이전 session에서 새 작업을 시작할 수 있습니다.
각 session은 branch, files, conversation, task state를 분리해서 갖고, 여러 작업을 동시에 진행할 때 섞이지 않도록 설계됐습니다.

또 앱 안에서 terminal과 browser를 열어 명령을 실행하고 preview를 확인할 수 있습니다.

바로 보기

왜 VS Code Copilot과 다르게 봐야 하나

VS Code의 Copilot Chat은 편집기 안에서 질문하고 수정하기 좋습니다.
Copilot CLI는 터미널에서 저장소를 읽고 명령을 실행하는 흐름에 강합니다.

Copilot app은 시작점이 다릅니다.

GitHub에 이미 있는 업무 단위, 즉 이슈·PR·리뷰·체크 상태를 앱의 작업 흐름으로 끌어오는 쪽입니다.

예를 들어 이런 흐름입니다.

  1. Inbox에서 이슈를 고른다.
  2. 해당 이슈 context로 session을 시작한다.
  3. Copilot이 계획을 만든다.
  4. 변경사항과 diff를 검토한다.
  5. 앱 안에서 테스트나 preview를 확인한다.
  6. PR을 열고 리뷰·체크를 이어간다.

즉 “AI에게 코드 좀 고쳐달라”보다 GitHub 작업 항목 하나를 에이전트 session으로 처리한다에 가깝습니다.

세션 격리가 중요하다

에이전트형 도구에서 가장 자주 생기는 문제는 작업이 섞이는 것입니다.

한쪽에서는 버그를 고치고, 다른 쪽에서는 의존성을 올리고, 또 다른 쪽에서는 문서를 바꾸다 보면 diff가 커지고 리뷰가 어려워집니다.

GitHub는 Copilot app의 각 session이 자체 공간을 가진다고 설명합니다.
branch, file 상태, conversation, task state가 나뉘면 여러 작업을 병렬로 진행하더라도 PR 단위로 정리하기 쉬워집니다.

이건 개인보다 팀에서 더 중요합니다.

팀이 에이전트 작업을 운영하려면 “누가 어떤 지시를 했는가”보다 “어떤 이슈에서 어떤 변경이 생겼고, 어떤 테스트를 통과했는가”가 더 중요합니다. Copilot app은 그 흐름을 GitHub 쪽으로 되돌려놓으려는 제품입니다.

Agent Merge는 조심해서 봐야 한다

GitHub 발표에는 Agent Merge도 언급됩니다.

의미는 리뷰 코멘트 대응, 실패한 check 수정, 조건을 만족했을 때 merge까지 이어가는 follow-through 기능입니다.

편리하지만, 이 부분은 팀 정책과 충돌하기 쉽습니다.

아래 조건을 먼저 정하지 않으면 위험합니다.

  • 어떤 branch에서 agent merge를 허용할 것인가
  • CODEOWNERS나 required reviews를 어떻게 유지할 것인가
  • failing check 자동 수정 범위를 어디까지 둘 것인가
  • 보안·배포 설정 변경도 agent가 처리할 수 있는가
  • merge 전에 사람이 보는 최종 단계가 남아 있는가

작은 문서 수정이나 테스트 보정에는 유용할 수 있습니다.
반대로 인증, 결제, 배포, 데이터 마이그레이션처럼 위험한 영역은 자동 merge보다 수동 확인이 먼저입니다.

누가 먼저 쓸 수 있나

GitHub Changelog 기준으로 Copilot Pro와 Pro+ 사용자는 preview 확대에 맞춰 early access를 신청할 수 있습니다.

Copilot Business와 Enterprise 사용자는 rollout이 진행되면 조직 또는 enterprise에서 시작할 수 있습니다. 다만 관리자 조건이 있습니다.

GitHub는 Business나 Enterprise plan에서 technical preview를 쓰려면 organization 또는 enterprise admin이 preview 기능과 Copilot CLI를 정책에서 켜야 한다고 안내했습니다.

GitHub Docs도 같은 방향입니다.

  • Business/Enterprise: 조직이 preview features와 Copilot CLI를 켠 경우 사용
  • Pro/Pro+: waitlist를 통해 접근
  • 앱은 technical preview이며 변경될 수 있음
  • macOS, Windows, Linux 앱 설치가 전제

개인 사용자는 waitlist 여부를 보면 되고, 회사 사용자는 정책이 먼저입니다.

먼저 시험해볼 만한 작업

technical preview는 처음부터 중요한 운영 코드에 붙이는 것보다 낮은 위험의 반복 작업으로 보는 편이 좋습니다.

예시는 이렇습니다.

  • README 최신화
  • 테스트 실패 원인 조사
  • 작은 UI 문구 수정
  • deprecated API 사용 지점 탐색
  • release note 초안 작성
  • issue triage와 label 정리
  • 작은 버그의 재현 테스트 추가

반대로 아래 작업은 preview 단계에서 바로 맡기기 어렵습니다.

  • 인증·권한 변경
  • 결제 로직 변경
  • 배포 파이프라인 변경
  • 데이터 삭제나 마이그레이션
  • 대규모 리팩터링과 자동 merge

에이전트 앱은 생산성을 올릴 수 있지만, preview 기능은 먼저 운영 경계부터 정해야 합니다.

한 줄 결론

GitHub Copilot app technical preview는 Copilot을 이슈·PR·세션·검증 중심의 데스크톱 에이전트 환경으로 확장하는 발표입니다.
개인은 waitlist와 사용 가능 여부를 보고, 팀은 preview 정책, Copilot CLI 허용, Agent Merge 기준을 먼저 정해야 합니다.

같이 보면 좋은 글

출처