GitHub Copilot Workspace 써봤는데, 57% 빠르다는 말은 맞고 나머지는 달랐다

GitHub Copilot Workspace를 처음 접했을 때 솔직히 반신반의했다. 이슈 하나 던져주면 AI가 계획 세우고, 코드 짜고, PR까지 올려준다는 게 너무 그럴싸하게 들렸거든. 몇 달 전부터 팀에 도입해서 써봤는데, 57% 빠르다는 말은 실제로 어느 정도 맞았다. 그런데 나머지 부분은 좀 달랐다.

코딩 에이전트 모드랑 Workspace, 같은 것처럼 보여서 처음엔 헷갈렸다

IDE에서 쓰는 Copilot 에이전트 모드랑 Copilot Workspace가 뭐가 다른지 처음엔 구분이 안 됐다. 쓰다 보니 핵심 차이가 있었다.

IDE의 에이전트 모드는 내 로컬 환경에서 직접 파일을 편집하는 방식이다. 반면 Copilot Workspace(공식 명칭으로는 'Copilot 코딩 에이전트')는 GitHub Actions로 구동되는 별도 환경에서 자율적으로 돌아간다. 내 컴퓨터 안 건드리고, GitHub 쪽 서버에서 코드 분석하고 변경하고 PR 올리는 것까지 처리한다.

흐름은 이렇다.

• GitHub 이슈에 Copilot을 assignee로 지정하거나, 채팅에서 PR 생성 요청
• Copilot이 저장소 전체 분석 → 구현 명세 작성
• 명세 기반으로 어떤 파일을 어떻게 바꿀지 계획 수립
• 코드 변경 실행 → 자동화 테스트 및 린터 실행
• PR 오픈 → 리뷰 요청

이 전 과정이 백그라운드에서 돌아가서, 작업 맡겨놓고 다른 일 하다가 PR 알림 받는 구조다. 처음 써보면 좀 신기하다.

직접 써봤을 때 진짜 된 것들 — 숫자로 보면 57%

이슈 하나 던졌더니 PR이 1.8시간 만에 올라왔다

GitHub 측 데이터에 따르면 Workspace를 사용한 PR은 이슈에서 PR 생성까지 평균 1.8시간 걸렸고, 기존 대비 57% 단축된 수치다. 직접 써본 경험에서도 비슷한 느낌을 받았다. 특히 명확한 기능 추가 이슈일수록 빨랐다.

구체적으로 잘 된 케이스들:

• API 엔드포인트 추가 — CRUD 구조가 정해진 경우는 거의 손댈 게 없는 PR이 나왔다
• 테스트 코드 생성 — 기존 로직에 대한 유닛 테스트를 한 번에 여러 파일에 걸쳐 작성해줬다
• DB 마이그레이션 스크립트 — 스키마 변경 이슈 주니까 마이그레이션 파일까지 같이 만들어줬다
• 보일러플레이트 정리 — 레거시 코드의 반복 패턴 제거 작업은 확실히 빠름

이런 작업이 전체의 50~70%라는 게 핵심이다

Workspace가 효과적인 작업이 전체 개발 업무의 50~70% 정도라는 말이 있다. 실제로 써보니 이 수치가 현실적으로 느껴졌다. CRUD API, 테스트, 마이그레이션, 리팩토링처럼 패턴이 명확한 작업들이 여기에 해당한다. 이 범위 안에서 쓰면 속도 차이가 제대로 난다.

기대했다가 막힌 것들, 세 가지

복잡한 PR일수록 리뷰 시간이 오히려 늘었다

Workspace로 생성된 복잡한 변경 PR의 경우, 리뷰어 부담이 오히려 18% 늘어났다는 데이터가 있다. 직접 경험해봐서 공감했다.

AI가 짠 코드가 틀린 건 아닌데, 읽기가 어색했다. 변수명이 지나치게 설명적이고, 파일 구조를 잡는 방식이 우리 코드베이스랑 살짝 달랐다. 합법적이지만 낯선 코드랄까. 그걸 리뷰하면서 "이게 맞는 방향인가"를 생각하는 시간이 추가로 들었다.

특히 비즈니스 로직이 복잡하거나, 여러 레이어에 걸쳐 변경이 필요한 작업에서는 이 현상이 두드러졌다. 결국 AI가 빠르게 만든 걸 내가 천천히 검증하는 구조가 됐다.

크로스 리포지토리 변경은 안 된다

마이크로서비스 구조를 쓰는 팀이라면 이게 제일 아쉬운 부분일 수 있다. Copilot 코딩 에이전트는 한 번 실행에 하나의 저장소만 수정할 수 있다. 이슈가 있는 저장소에서만 변경 가능하고, 관련 서비스 저장소를 동시에 건드리는 건 현재 지원 안 된다.

실제로 API 변경 이슈였는데 클라이언트 코드가 다른 리포에 있어서 절반만 자동화하고 나머지는 따로 작업해야 했다.

대용량 저장소에서는 분석 자체가 느려진다

저장소 크기에 제한이 있다. 너무 큰 저장소는 파일 목록 나열도 버거워진다는 게 공식 문서에도 나와 있다. 코드베이스가 수년간 쌓인 큰 팀이라면 Workspace가 제대로 분석을 못 하거나 크기 제한 오류가 뜰 수 있다.

한 번은 "Copilot Workspace may not be used to analyze this repository due to size limitations"라는 메시지를 받았다. 저장소 정리를 먼저 하거나, 적당한 크기의 독립 모듈에서 쓰는 게 현실적이다.

결국 어떤 작업에 쓸 만하고, 어디서 쓰면 아직 이른가

몇 달 써본 결론은 이렇다. Workspace는 '생각이 필요 없는 작업'에 강하다. 패턴이 정해진 코드, 테스트 작성, 레거시 정리. 이런 작업은 맡겨두면 확실히 빠르다.

반면 '처음부터 설계해야 하는 작업'은 아직 이르다. 새 아키텍처 결정, 복잡한 비즈니스 로직 구현, 성능 최적화처럼 사람이 판단해야 하는 부분은 AI가 짜준 코드를 검증하는 데 결국 시간이 들어간다.

그리고 한 가지 더 — Copilot Workspace는 GitHub Copilot Enterprise($39/월) 전용이다. Business 플랜($19)에는 없다. 기능이 좋다고 해도 사용 전에 비용 구조를 확인하고 팀 규모와 ROI를 따져봐야 한다. 루틴 작업의 60~75% 시간 절감 효과가 있다는 발표도 있지만, 팀 상황에 따라 편차가 크다.

내가 내린 결론은 "쓸 만하다, 단 어디에 쓸지 먼저 정하고 써야 한다"는 거다. 만능 도구가 아니라 특정 범위에서 빠른 도구다. 그 범위 안에선 진짜 도움이 된다. 에이전틱 AI 개발이 이렇게 쓰이는 거라면, 앞으로 리뷰어 역할이 더 중요해질 것 같다. 관련해서 AI 에이전트가 프로덕션에서 망하는 이유도 참고할 만하다.

---

📎 참고 자료

• GitHub Copilot 코딩 에이전트 — 공식 문서
• Copilot Workspace Known Issues — githubnext
• Troubleshooting Copilot cloud agent — GitHub Docs

---

📌 함께 보면 좋은 글

• RAG 파이프라인 만들다 3번 갈아엎었다, 실패 패턴이 있었다
• AI 에이전트가 프로덕션에서 망하는 이유, 모델 문제가 아니었다
• 클로드(Claude) 비용은 절반, 품질은 두 배 — 검증된 7가지 레버