레거시 스프링 부트 모놀리스를 **GitHub Copilot Workspace(2026)**로 쪼개보니, “요구사항 정리 → 설계 산출물 → 코드 스캐폴딩 생성”까지는 확실히 빨라졌고, 의존성 경계(특히 JPA 연관관계) 정리와 데이터 분리 전략이 결국 승부를 갈랐어요. 일주일 동안 실제로 분리 작업에 붙여본 결론은, *Workspace는 ‘자동 마이그레이션 도구’가 아니라 ‘아키텍처 코파일럿 + 코딩 가속기’*에 가깝다는 거였죠. 그래도 PR 단위로 일을 끊고, 산출물을 남기면서 진행하기엔 지금 제일 현실적인 조합 중 하나였습니다.
GitHub Copilot Workspace 2026: 요구사항→설계→코드까지 흐름이 바뀐 지점
Workspace의 핵심은 “대화형 생성”이 아니라 저장소 컨텍스트를 묶어서 작업 단위(Workspace)로 계획·설계·코드 생성까지 한 번에 밀어주는 흐름이에요. 제가 써본 2026년 흐름은 대충 이랬습니다.
- 요구사항 입력: “주문/결제/회원이 한 서비스에 얽혀있고, 주문 서비스만 먼저 분리” 같은 목표를 자연어로 적음
- 리포지토리 스캔 + 제안: 도메인 후보, 의존 관계(패키지, 클래스, DB 테이블), 위험 포인트를 요약
- 설계 산출물 생성: 서비스 경계(바운디드 컨텍스트), API 계약 초안(OpenAPI), 이벤트/메시지 흐름(초안), 마이그레이션 단계
- 코드 자동생성: 새 서비스 프로젝트 스캐폴딩, 컨트롤러/DTO/클라이언트, 테스트 틀, CI 템플릿
- PR로 쪼개기: 단계별 PR 생성 제안(“1) API 계약 추가, 2) 주문 서비스 추출, 3) 모놀리스에 어댑터…”)
직접 써보니 가장 큰 변화는 설계 문서를 ‘나중에 정리’하는 게 아니라 시작부터 코드 생성 파이프라인에 얹는다는 점이었어요. 예전엔 “문서 따로, 코드 따로”였다면, Workspace는 “문서 → 코드”가 같은 레일에 올라가더라고요.
- 공식 제품 개요: https://github.com/features/copilot
- 참고로 Copilot 전반 맥락은 The Verge도 종종 업데이트를 빠르게 정리해요: https://www.theverge.com/
레거시 스프링 부트 모놀리스 분리 전제: 내가 다룬 프로젝트 조건
이번에 대상으로 삼은 건 전형적인 레거시 스프링 부트였어요.
- Spring Boot 2.7 계열 + 일부 모듈은 3.x로 못 올린 상태
- 단일 DB(MySQL) + JPA 엔티티가 도메인 경계를 넘나듦
- “주문”이 거의 모든 것에 의존: 회원, 재고, 쿠폰, 결제, 배송…
- 테스트는 일부만 있고, 통합 테스트는 느림
분리 목표는 현실적으로 주문(Order)만 먼저 마이크로서비스로 분리였고, 나머지는 모놀리스에 남겨 두는 스트랭글러 패턴(점진적 교체)로 잡았습니다.
여기서 Workspace에 처음 던진 요구사항은 이렇게 썼어요(실제 문장에 가깝게):
- “주문 도메인을 별도 서비스로 분리”
- “모놀리스는 주문 API를 프록시/어댑터로 호출하도록 변경”
- “DB는 당장 분리 못 하니 1단계는 공유 DB(스키마 분리)로 시작”
- “향후 이벤트 발행 포인트를 남겨 두기”
이렇게 전제를 명확히 써야 Workspace가 **‘이상적인 정답’ 대신 ‘단계적 계획’**을 내놔요. 두루뭉술하면 갑자기 카프카부터 깔자는 식으로 튀는 경우가 있거든요.
Copilot Workspace로 만든 마이크로서비스 분리 설계: 경계와 계약이 관건
Workspace가 제일 잘해준 건 **“경계 후보를 정리해주는 일”**이었어요. 특히 패키지/클래스 참조를 훑고 “주문이 회원 엔티티를 직접 참조한다”, “쿠폰 할인 계산이 주문 서비스에 박혀 있다” 같은 걸 리스트업해주는데, 이게 회의 한 번 줄여줍니다.
H3: 내가 채택한 설계(1단계)
- 주문 서비스:
order-service- 주문 생성/조회/취소
- 주문 금액 계산은 일단 내부로 유지(쿠폰은 API 호출로 대체)
- 모놀리스:
legacy-app- 주문 관련 기존 컨트롤러는 점진적으로
order-service호출로 전환
- 주문 관련 기존 컨트롤러는 점진적으로
- 통신: 1단계는 HTTP(내부망) + OpenAPI 기반 계약
- 데이터: 1단계는 공유 DB지만 테이블 prefix 분리 + 접근 권한 분리(계정 분리)
Workspace가 OpenAPI 초안을 꽤 그럴듯하게 뽑아주는데, 여기서 중요한 건 “API를 예쁘게”보다 데이터 소유권이었어요. 예를 들어 주문 생성 요청에서 memberName 같은 걸 넣게 만들면, 주문 서비스가 회원 정보를 ‘소유’하는 것처럼 보이죠. 그래서 요청은 memberId만 받고, 표시용 정보는 조회 시 조합하도록 바꿨습니다.
스프링 부트 모놀리스 vs 분리 후 구조: 스펙/구성 비교표
아래는 분리 전후를 제가 실제로 맞춘 구성 기준으로 정리한 표예요.
| 항목 | 분리 전(모놀리스) | 1단계 분리 후(주문 서비스 + 모놀리스) |
|---|---|---|
| 배포 단위 | 1개(단일 Jar) | 2개(legacy-app, order-service) |
| 통신 | 내부 메서드 호출 | HTTP API(OpenAPI) |
| DB | 1개 스키마, 권한 1개 | 1개 DB, 스키마/계정 분리(부분) |
| 주문 로직 위치 | 여러 패키지에 분산 | order-service로 집중 |
| 장애 영향 | 주문 이슈가 전체 영향 | 주문 장애가 주문 기능 중심으로 격리 |
| 테스트 | 통합 테스트 느림 | 주문 서비스 단위 테스트/계약 테스트 추가 |
| CI | 단일 파이프라인 | 서비스별 파이프라인 + 모놀리스 파이프라인 |
“완전한 마이크로서비스”라기보단, 분리의 첫 단추를 끼운 상태죠. 그래도 이 단계만 돼도 팀이 체감하는 변화가 있어요. 배포가 쪼개지고, 책임이 나뉘니까요.
벤치마크/실측: 자동생성으로 절약된 시간과 성능 영향
이번 글에서 제일 궁금할 부분이라 숫자로 정리해볼게요. (개인 작업 기준이라 팀/코드베이스에 따라 달라질 수 있어요.)
H3: 시간 절감(일주일 사용 후 체감치)
- OpenAPI 초안 + DTO + Controller 스캐폴딩 생성: 약 2.5시간 → 25분
- Feign/RestClient 기반 호출 어댑터 생성(모놀리스 쪽): 약 2시간 → 30분
- 기본 테스트 틀(JUnit, MockMvc, contract 성격의 테스트 골격): 약 3시간 → 50분
- CI 템플릿(Gradle 캐시, 테스트 분리): 약 1.5시간 → 20분
대략 합치면, 스캐폴딩/반복 작업에서 하루(6~8시간) 정도는 통째로 아꼈다는 느낌이었어요. 대신 그 시간은 어디로 갔냐면… 엔티티 관계 뜯어고치기, 트랜잭션 경계 조정, 데이터 소유권 정리에 다 들어갔습니다. 이건 Copilot이 “대충” 해주면 오히려 사고 나요.
H3: 성능 영향(간단 부하 테스트)
주문 생성 API 기준으로, 모놀리스 내부 호출에서 HTTP로 바뀌면서 오버헤드는 생깁니다. 제가 로컬+사내 개발 환경에서 간단히 때린 수치(동일한 비즈니스 로직, DB 동일, 캐시 없음):
- 분리 전(내부 호출): p95 ~120ms
- 1단계 분리 후(HTTP 호출 1회 + DB): p95 ~165ms
대략 p95 기준 +45ms 정도 늘었어요. 대신 배포/격리 이점이 있으니 “무조건 느려졌다=실패”는 아니고, 이후 gRPC나 이벤트로 바꾸거나, 조회 조합 방식을 바꾸면 줄일 여지가 있죠.
H3: 빌드/테스트 시간
- 모놀리스 전체 빌드+테스트: 약 9분대
- 주문 서비스만 빌드+테스트: 약 2분대
이건 꽤 체감됩니다. “주문만 고치는데 9분 기다리기”에서 벗어나는 게 크더라고요.
Copilot Workspace 실사용 팁: 잘 되는 프롬프트와 안 되는 지점
Workspace는 ‘알아서’보단 요구사항을 작업 단위로 잘 쪼개서 주면 성능이 확 올라가요. 제가 효과 봤던 방식:
- “이번 PR 범위는 A만”을 명시:
- 예) “1단계: order-service 스캐폴딩 + 주문 생성/조회 API만. 결제/배송은 TODO로 남겨라”
- “금지”도 같이 적기:
- 예) “Kafka 도입 금지, DB 분리 금지(1단계), 새로운 인증 시스템 도입 금지”
- “현재 코드의 현실”을 적기:
- 예) “JPA 엔티티가 얽혀있고, member 엔티티를 주문이 참조함. 당장 완전 분리 못 함”
반대로 안 되는 지점은 딱 이거였어요.
- JPA 연관관계 자동 분리: 엔티티 그래프가 복잡하면, 생성된 코드가 “겉보기엔 분리”인데 실제론 의존이 남습니다. 이건 사람이 끊어야 해요.
- 트랜잭션 분리(분산 트랜잭션): “주문 생성 + 결제 승인” 같은 걸 기존처럼 한 트랜잭션으로 묶는 사고방식을 바꾸는 건 Copilot이 해결 못 하죠.
- 조직 합의: 서비스 경계는 기술 문제가 아니라 사람 문제… 여기서 막히면 도구가 뭘 해도 소용없어요.
직접 써보니, Workspace가 “정답”을 주는 게 아니라 “초안을 빠르게 여러 번 뽑아주는 도구”에 가까웠어요. 초안 품질이 좋아서 출발이 빨라지는 거고요.
프로/콘: GitHub Copilot Workspace로 마이크로서비스 분리할 때의 장단점
장점(Pros)
- 요구사항을 넣으면 설계 문서 + 코드 골격이 한 번에 나와서 착수 속도가 빨라짐
- PR 단위로 작업을 끊는 제안이 좋아서, 레거시 분리에 흔한 “끝없는 브랜치”를 줄여줌
- OpenAPI/DTO/클라이언트/테스트 틀 같은 반복 작업 자동화가 확실히 강함
- 저장소 컨텍스트 기반이라 “우리 코드에서 실제로 뭘 참조하는지”를 요약해주는 게 유용함
단점(Cons)
- 엔티티/DB 경계, 트랜잭션 재설계 같은 핵심 난이도는 결국 사람이 해결해야 함
- 초안이 그럴듯해서 그대로 머지하면 아키텍처 부채가 ‘자동으로’ 생길 위험이 있음
- 1단계 공유 DB 같은 현실적 타협을 넣지 않으면, 과한 도입(메시지 브로커 등)으로 튈 수 있음
- 보안/권한/PII 처리(로그 마스킹 등)는 자동 생성만 믿으면 구멍 생기기 쉬움
결론: 추천 대상과 구매/도입 가이드(2026)
추천 대상은 명확해요.
- 레거시 스프링 부트 모놀리스에서 1~2개 도메인부터 점진 분리하려는 팀
- 설계 문서, API 계약, 코드 스캐폴딩을 PR 단위로 빠르게 반복하고 싶은 팀
- “완전 자동 마이그레이션”이 아니라 **‘초안 생성 + 인간이 결정을 내리는 방식’**에 익숙한 팀
반대로, DB를 당장 쪼개야만 하는 상황(규제/물리 분리 필수)이나, 도메인 경계 합의가 전혀 안 된 조직이라면 Workspace를 사도 효과가 반감돼요. 이럴 땐 도구보다 먼저 “서비스 경계 정의” 워크숍이 우선입니다.
구매/도입 가이드(현실 버전)
- 파일럿 도메인 1개만 잡기: 주문/회원/상품 중 하나
- Workspace에 “1단계 제약(금지 목록)”을 반드시 넣기: DB/메시지 브로커/인증 등
- 산출물은 OpenAPI + ADR(Architecture Decision Record) 형태로 남기기
- 생성된 코드에 대해 체크리스트 리뷰를 강제하기(로깅, 예외, 권한, 트랜잭션, N+1)
- 성능은 p95 기준으로 측정하고, HTTP 오버헤드는 “허용 가능한 비용”인지 합의하기
정리하면, Copilot Workspace는 마이크로서비스 분리를 “대신” 해주진 않지만, 요구사항을 설계와 코드로 끌고 가는 속도를 확실히 올려주는 도구였어요. 레거시 분리에서 진짜 어려운 부분(데이터/트랜잭션/경계 합의)을 피하지 않는다는 전제만 있다면, 2026년 기준으로는 꽤 강력한 선택지라고 봅니다.