.NET 빌드와 배포 방식의 재창조 (다시)

1 week ago 6

.NET Unified Build 프로젝트는 기존 분산형 저장소 기반 빌드 구조의 복잡성과 비효율을 줄이기 위해, 제품 전체를 ‘가상 단일 저장소(Virtual Monolithic Repository, VMR)’ 형태로 통합한 새로운 빌드 체계
기존의 분산형 제품 구성 방식은 독립성과 유연성은 높지만, 의존성 관리·빌드 일관성·속도 측면에서 큰 부담을 초래
Unified Build는 Linux 배포판용 Source Build의 원리를 확장해, 단일 소스 레이아웃과 ‘수직 빌드(Vertical Build)’ 구조를 도입하여 빌드 시간을 단축하고 예측 가능성을 확보
양방향 코드 흐름(two-way code flow) , 시나리오 테스트, 자동 검증 및 서명 인프라 개선 등을 통해 개발자 효율성과 제품 품질을 동시에 향상
.NET 10에서 정식 도입된 이 체계는 빌드 시간 단축(24시간→7시간 이하) , 유지보수 비용 절감, 배포 신뢰성 향상 등 실질적 성과를 달성

.NET 빌드 구조의 변화 배경

.NET은 2015~2016년 오픈소스화 과정에서 CoreCLR, CoreFX, ASP.NET Core, SDK 등 다수의 저장소로 분리되어 개발
각 저장소가 독립적으로 빌드·배포되며, 전체 제품은 의존성 그래프를 통해 조합되는 구조
이 방식은 OSS 생태계와 유사하지만, 보안 패치나 긴급 수정 시 여러 팀의 동시 조율이 필요해 시간 예측 불가 문제가 발생
분산형 개발의 장점(레이어링, 커뮤니티 분화, 비동기 개발 등)에도 불구하고, 제품 일관성(coherency) 확보에는 비효율적

복잡성(Complexity) : 변경이 고객에게 전달되기까지 필요한 단계 수로 정의
- 저장소·의존성 노드가 많을수록 일관성 확보에 더 많은 시간과 인적 조율 필요
오버헤드(Overhead) : 고객에게 전달 가능한 산출물을 직접 생산하지 않는 시간
- 예: PR 생성·승인 대기, 큐잉, 환경 설정 등
.NET 8 런타임 빌드 분석 결과, 전체 빌드 시간의 약 38.5%가 오버헤드로 확인
복잡성과 오버헤드가 결합되면 빌드 효율이 급격히 저하되고, 전체 릴리스 주기가 길어짐

Source Build는 Linux 배포판이 .NET을 단일 소스에서 오프라인 빌드할 수 있도록 설계된 시스템
- 단일 구현, 단일 플랫폼, 단일 빌드 환경 원칙
- 빌드 오케스트레이터가 각 구성요소의 의존성과 빌드 순서를 관리
Source Build는 낮은 복잡도·낮은 오버헤드로 50분 내 빌드 가능
Microsoft 내부 빌드에도 이 개념을 적용하려 했으나, 폐쇄 소스·레거시 의존성·플랫폼 간 조인(join) 등으로 어려움 존재
이를 해결하기 위해 참조 전용 패키지(source-build-reference-packages) , 단일 구현 원칙, 조인 제거 등의 접근 도입

단일 커밋으로 전체 .NET 제품 빌드 가능
모든 플랫폼별 배포판을 단일 환경에서 생성
Microsoft 외부에서도 독립적 빌드·검증 가능
양방향 코드 흐름을 통해 VMR과 개별 저장소 간 변경 자동 동기화
시나리오 테스트를 통해 전체 제품 수준의 기능 검증 수행
수직 빌드(Vertical Build) 구조로 플랫폼별 빌드를 병렬화
- 약 35~40개의 빌드 수직선(short/tall stack)으로 구성