GitHub Copilot 앱 발표를 처음 봤을 때 제일 먼저 든 생각은 “이제 IDE 안 채팅창만으로는 부족해졌구나”였다. Copilot은 원래 코드 자동완성에서 시작했고, 그다음은 에디터 안 대화와 PR 보조로 넓어졌다. 그런데 이번에는 아예 데스크톱 앱을 따로 꺼냈다. 그냥 새 UI를 붙인 정도가 아니라, 코딩 에이전트가 일하는 장소를 IDE 밖으로 빼내는 움직임에 가깝다.
GitHub 공식 글은 이 앱을 “agent-native desktop experience”라고 부른다. 기술 프리뷰 공지를 보면, 하나의 앱에서 이슈, PR, 프롬프트, 이전 세션을 출발점으로 삼고, 여러 저장소의 작업을 My work 화면에서 모아 보고, 병렬 에이전트 세션을 각각 별도 git worktree와 브랜치에서 실행하는 흐름을 내세운다. 말은 화려하지만 핵심은 단순하다. 코딩 에이전트를 “에디터 기능”이 아니라 “작업 큐”로 다루겠다는 뜻이다.
이전에 AI 코딩 에이전트에 하네스가 먼저 필요하다는 글을 쓰면서도 비슷한 얘기를 했다. 에이전트가 진짜 일을 하기 시작하면 모델보다 작업장 설계가 더 중요해진다. 이번 Copilot 앱은 그 작업장을 GitHub가 직접 가져가려는 신호로 보인다.
GitHub Copilot 앱은 IDE 기능이 아니라 작업대다
자동완성에서 세션 관리로 중심이 옮겨간다
Copilot을 아직도 “코드 몇 줄 추천해주는 도구”로 보면 이번 발표가 잘 안 보인다. 자동완성은 개발자가 지금 열어둔 파일을 기준으로 작동한다. 반면 코딩 에이전트는 이슈를 읽고, 저장소를 훑고, 브랜치를 만들고, 테스트를 돌리고, PR에 연결되는 긴 흐름을 가진다. 이건 에디터 사이드바 하나에 넣기에는 너무 크다.
GitHub가 데스크톱 앱에서 강조한 것도 바로 이 부분이다. 에이전트 세션은 각자 별도 worktree와 브랜치를 갖고, 파일 변경, 대화, 도구 로그가 분리된다. 개발자는 한 세션이 테스트를 돌리는 동안 다른 세션을 열 수 있다. 실패한 작업은 버리고, 괜찮은 작업만 이어서 리뷰할 수 있다. 이 구조는 사람 개발자의 멀티태스킹이라기보다, 작은 작업자 여러 명을 같은 책상 위에 올려놓는 방식에 가깝다.
여기서 IDE는 여전히 중요하다. 최종 리뷰와 깊은 수정은 에디터에서 해야 한다. 하지만 모든 작업이 IDE에서 시작하고 끝날 필요는 줄어든다. 이슈에서 바로 세션을 만들고, PR에서 후속 수정 세션을 열고, 이전 세션을 다시 이어가는 흐름이 자연스러워지면 IDE는 실행 화면 중 하나가 된다. 중심은 저장소와 작업 상태로 이동한다.
병렬 세션은 생산성보다 통제 문제다
병렬 에이전트 세션은 듣기에는 굉장히 생산적이다. 버그 하나, 리팩터링 하나, 문서 업데이트 하나를 동시에 맡길 수 있다. 그런데 실제 팀에서는 이게 바로 위험 지점이 된다. 세션이 늘어나면 diff도 늘어나고, 테스트 비용도 늘어나고, 누가 무엇을 승인해야 하는지도 흐려진다.
그래서 나는 이번 앱의 핵심을 “많이 돌릴 수 있다”보다 “분리해서 볼 수 있다”로 읽는다. 별도 worktree와 브랜치를 기본값으로 잡는 건 꽤 현실적인 선택이다. 에이전트가 실패해도 main 작업 폴더를 망치지 않고, 각 세션의 변경을 독립적으로 검토할 수 있다. 이건 멋진 AI 기능이라기보다 운영 안전장치다.
작은 팀에서도 이 차이는 크다. 한 명이 여러 고객사 작업을 동시에 보고 있을 때, 에이전트 세션이 로컬 작업 폴더를 섞어버리면 바로 지옥이 열린다. 반대로 세션별로 작업장이 분리되어 있고, 어떤 세션이 어떤 이슈에서 출발했는지 남아 있으면 검토 부담이 줄어든다. 결국 생산성은 에이전트가 코드를 빨리 쓰는 데서 끝나지 않는다. 사람이 나중에 믿고 합칠 수 있어야 생산성이다.
Copilot CLI 변화까지 같이 봐야 한다
데스크톱 앱만 따로 나온 게 아니다
이번 흐름이 더 흥미로운 이유는 Copilot 앱만 발표된 게 아니라는 점이다. GitHub는 같은 시기에 Copilot CLI의 커스텀 에이전트, 프롬프트 스케줄링과 음성 입력, rubber duck 리뷰, Copilot CLI와 클라우드 에이전트, Copilot 앱에서 Gemini 모델 지원도 같이 밀었다. 한쪽은 데스크톱 화면이고, 다른 한쪽은 터미널과 모델 선택, 검토 루프다.
이 조합이 말하는 건 분명하다. GitHub는 Copilot을 에디터 플러그인 하나로 끝낼 생각이 없다. 데스크톱 앱, CLI, 클라우드 에이전트, IDE 확장, PR, Actions까지 한 줄로 묶으려 한다. 개발자는 “Copilot을 어디에서 켤까”가 아니라 “이 작업은 어느 표면에서 시작하는 게 제일 안전한가”를 고민하게 된다.
개인적으로는 커스텀 에이전트 쪽이 더 실무 냄새가 난다. 팀마다 빌드 방식, 테스트 명령, 릴리즈 규칙, 금지 파일이 다르다. 범용 에이전트에게 매번 같은 설명을 반복하는 건 피곤하다. CLI에서 팀 워크플로우를 이해하는 커스텀 에이전트를 만들 수 있다면, 반복 작업의 품질이 조금씩 안정될 수 있다.
rubber duck은 장난감처럼 보이지만 꽤 중요하다
Copilot CLI의 rubber duck 기능은 이름만 보면 귀엽다. 그런데 실제로는 에이전트 루프 안에 비판자 역할을 넣는 구조다. 메인 에이전트가 계획, 설계, 구현, 테스트를 진행하다가 rubber duck에게 검토를 넘기고, blind spot이나 설계 결함을 되돌려 받는 식이다.
이건 내가 계속 필요하다고 느끼던 방향이다. 코딩 에이전트는 목표를 주면 너무 성실하게 앞으로 간다. 그래서 중간에 “잠깐, 이 설계 이상하지 않아?”라고 묻는 루프가 필요하다. 사람이 매번 그 역할을 하면 피곤하다. 그렇다고 아무 검토 없이 자동 머지로 가면 더 위험하다. rubber duck은 완벽한 리뷰어는 아니겠지만, 에이전트 작업의 첫 번째 마찰 장치로는 의미가 있다.
물론 이걸 믿고 사람 리뷰를 빼면 안 된다. 특히 권한, 결제, 배포, 데이터 마이그레이션이 걸린 작업은 여전히 사람이 잡아야 한다. 다만 작은 리팩터링이나 테스트 보강처럼 반복적인 작업에서는 자동 비판 루프가 diff 품질을 조금 올려줄 수 있다. 에이전트 시대의 리뷰는 사람이 한 번 보는 구조보다, 자동 검토와 사람 검토가 층을 나눠 갖는 쪽으로 갈 가능성이 크다.
개발팀 입장에서 바뀌는 질문
이제 도입 여부보다 운영 방식이 중요하다
Microsoft Build 2026 공식 글도 Copilot 앱을 언급하면서, 아이디어나 기존 이슈, PR에서 시작해 여러 에이전트 세션을 병렬로 오케스트레이션하고 리뷰, CI, 머지까지 이어가는 흐름을 설명했다. 여기서 중요한 단어는 “오케스트레이션”이다. 코딩 에이전트는 이제 한 번 켜보고 신기해하는 도구가 아니라, 팀 작업 흐름 안에 들어오는 실행 단위가 되고 있다.
그러면 질문도 바뀐다. “Copilot을 쓸까 말까”보다 “어떤 작업을 맡길까”, “어디까지 자동화할까”, “누가 마지막 승인을 할까”, “실패한 세션은 어떻게 폐기할까”가 더 중요해진다. 특히 병렬 세션이 가능해질수록 작업을 작게 자르는 능력이 중요해진다. 큰 기능 하나를 통째로 던지는 팀보다, 재현 가능한 작은 작업으로 쪼개고 검증 명령까지 명확히 주는 팀이 더 이득을 볼 것이다.
이건 운영자 관점에서도 꽤 큰 변화다. 지금까지 AI 코딩 도구 도입은 개인 생산성 이야기로 많이 소비됐다. 그런데 데스크톱 앱과 CLI, 클라우드 에이전트가 연결되면 팀 정책의 문제가 된다. 저장소별 허용 권한, 외부 네트워크 접근, 비밀 값 접근, 브랜치 이름 규칙, PR 템플릿, 테스트 필수 조건까지 같이 봐야 한다.
IDE 밖으로 나온다는 건 책임도 밖으로 나온다는 뜻이다
IDE 안에서 AI가 제안한 코드 한 줄을 개발자가 받아들이는 구조에서는 책임 경계가 비교적 단순했다. 개발자가 수락했다. 개발자가 커밋했다. 개발자가 리뷰했다. 그런데 에이전트가 별도 세션에서 브랜치를 만들고 테스트를 돌리고 PR까지 이어가면 책임 흐름이 더 길어진다.
이때 로그가 중요해진다. 어떤 프롬프트에서 시작했는지, 어떤 파일을 읽었는지, 어떤 명령을 실행했는지, 어떤 테스트가 실패했고 어떻게 고쳤는지 남아야 한다. GitHub가 세션과 도구 로그를 화면 안에 끌어오는 이유도 여기에 있다. 에이전트 작업은 결과 diff만 봐서는 부족하다. 과정이 너무 길고, 그 안에 위험한 판단이 숨어 있을 수 있다.
내가 팀이라면 처음부터 전면 도입하지는 않을 것 같다. 문서 업데이트, 테스트 보강, 작은 버그 재현, 타입 정리처럼 되돌리기 쉬운 작업부터 넣겠다. 그리고 세션마다 반드시 검증 명령과 종료 조건을 붙이겠다. 에이전트가 알아서 잘하겠지 하고 던지는 순간, 생산성 도구가 아니라 사고 가속기가 될 수 있다.
지금 봐야 할 포인트
GitHub는 개발자 표면을 다시 묶고 있다
이번 발표는 Copilot 앱 하나만 보면 조금 작아 보일 수 있다. 하지만 Copilot CLI, Gemini 모델 지원, JetBrains IDE의 agentic 기능, GitHub Actions와 PR 흐름까지 같이 놓으면 그림이 커진다. GitHub는 코드가 작성되는 곳, 리뷰되는 곳, 테스트되는 곳, 머지되는 곳을 이미 쥐고 있다. 여기에 에이전트 세션 관리까지 붙이면 개발자의 하루가 더 GitHub 중심으로 묶인다.
좋게 보면 편하다. 이슈에서 시작한 작업이 세션으로 이어지고, 세션이 브랜치와 PR로 이어지고, CI와 리뷰가 같은 흐름에 붙는다. 나쁘게 보면 잠금 효과가 커진다. 팀의 AI 작업 로그, 커스텀 에이전트 설정, 병렬 세션 습관이 특정 플랫폼에 쌓이면 나중에 빼기가 어렵다.
그래서 지금 필요한 태도는 흥분도 냉소도 아니다. 실험은 하되, 작업 단위를 작게 두고, 로그와 권한을 먼저 보는 쪽이 맞다. Copilot 앱이 성공하면 코딩 에이전트는 IDE 안 기능에서 데스크톱 작업대로 이동할 가능성이 크다. 그때 경쟁력은 “누가 더 많이 자동화했나”가 아니라 “누가 더 안전하게 자동화했나”에서 갈릴 것 같다.