WSL v2 가져오기·내보내기로 팀 공통 개발 환경 만들기

사진: Unsplash의 Lukas

시작하기

전통적으로 개발 환경은 회사 위키에 설치 순서를 적어 두거나, 컨테이너·VDI 템플릿 배포처럼 비교적 무거운 방법을 사용해 왔습니다. 그렇지만 문서를 읽는 사람 사이의 이해 수준 차이, 소프트웨어 업데이트로 인한 변경 사항, OS 로캘 차이, 대용량 이미지로 인한 I/O 지연 등 실제로 초기 온보딩 개발 환경을 구축하는 것은 매번 괴로운 일이 되곤 합니다.

 

WSL v2는 리눅스 커널을 경량 VM 형태로 구동하기 때문에 완전한 리눅스 커널 기능을 확보하면서도 VM 이미지 대비 1/10 수준의 용량만으로 배포할 수 있게 해줍니다. 그래서 많게는 수 십 GB에 달하는 가상 하드디스크 이미지를 복사하던 시간을 수백 MB짜리 tar 아카이브 파일로 간소화할 수 있고, 온보딩 속도 또한 분 단위로 단축됩니다.

 

이것이 가능할 수 있는 이유는 WSL v2의 --export와 --import 옵션 덕분인데, 이 옵션을 사용하여 개발팀이 겪는 환경 설정 문제를 단번에 해결할 수 있습니다.

 

이번 아티클에서는 WSL v2이미지 배포 방식을 채택해야 하는지부터, 실제 골든 이미지를 만들고 유지·보수하며, 실전에서 어떤 식으로 활용할 수 있는지까지 단계별로 설명합니다. 마지막으로 내보내기 전에 반드시 점검해야 하는 보안·개인정보 체크리스트도 제시합니다.

---

골든 이미지 만들기 — 내보내기(Export)

먼저 베이스 배포판으로 Ubuntu 22.04 LTS를 설치합니다. 그 위에 팀 표준 도구—예컨대 .NET 8 SDK, Node LTS, Git, Zsh 및 Oh‑My‑Zsh, Azure / AWS CLI—를 설치하고 프로젝트별 의존 패키지를 추가합니다. 이미지가 준비되면 다음 명령으로 내보냅니다:

$Name = "Ubuntu-22.04"
$Export = "C:\WSL\exports\dev-env-$(Get-Date -Format yyyyMMdd).tar"
wsl.exe --export $Name $Export

Windows 11 22H2 이상에서는 --vhd 옵션을 사용해 tar 대신 VHD 단일 파일로 내보낼 수도 있습니다. 이때는 압축 해제 과정이 없어서 가져오기 속도가 더욱 빨라집니다.

60초 온보딩 — 가져오기(Import)

내보낸 tar 파일을 Google Drive나 OneDrive 같은 곳에서 다운로드한 후, 개발자는 다음 두 줄만 실행하면 됩니다.

$Tar = "$home\Downloads\dev-env-202504.tar"
$Target = "C:\WSL\TeamUbuntu"
wsl.exe --import TeamUbuntu $Target $Tar --version 2

가져온 배포판의 이름은 TeamUbuntu‑202504처럼 날짜 태그를 붙이면 버전 관리가 명확해집니다. 호스트 자원을 과도하게 사용하지 않도록 %USERPROFILE%\.wslconfig에 memory=8GB, processors=4 같은 제한을 걸어 두는 것도 고려해볼 수 있습니다. 신규 노트북에 자동 스크립트를 배포해 wsl -l 결과에 해당 이름이 없으면 자동으로 가져오도록 하면 온보딩이 60초 안에 끝납니다.

유지·보수 전략

이미지 배포의 핵심은 주기적 갱신입니다. 마스터 이미지에서 주기적으로 apt update && apt upgrade를 실행해 유저 랜드 부분에 적용할 보안 패치를 반영하고, 새로운 개발 도구를 이미지에 설치한 다음, 새 태그(dev-env‑202506.tar)를 붙여 만듭니다. 필요하다면 dev, qa, prod‑support처럼 개발 흐름별로 서로 다른 이미지를 만들어 배포하는 것도 좋은 방법입니다.

 

그러나 이런 작업을 자동화하기 위해서는 적절한 자동화 수단을 택해야 합니다. 이 때 쉽게 사용할 수 있는 수단으로 cloud-init을 추천하며, WSL에 cloud-init을 직접 적용하는 방법은 별도의 블로그 포스트로 한 번 더 준비해서 공유하겠습니다.

---

활용 사례

그렇다면 이렇게 만들어진 이미지를 어떤 상황에서 적절하게 활용할 수 있을까요? 몇 가지 예시를 들어볼 수 있을 것입니다.

 

첫째, 신입·외주 온보딩입니다. 새로 입사한 개발자는 노트북을 수령한 뒤 스크립트 한 번 실행만으로 IDE와 CLI 설정을 모두 끝낼 수 있습니다.

둘째, 해커톤·워크숍처럼 단기간 집중 개발이 필요한 행사에서는 데이터셋과 라이브러리를 포함한 동일 이미지를 배포해 환경 이슈를 최소화할 수 있습니다.

셋째, glibc 버전이 고정된 레거시 프로젝트 유지보수에도 유용합니다. 마지막으로 CI 동일화 측면에서, self‑hosted GitHub Actions 러너에 같은 tar를 불러오면 "로컬 = CI" 환경을 보장할 수 있습니다.

넷째, 다른 사람을 위한 배포판 공유는 물론, 내 배포판을 백업하고 재사용하기 위한 용도로도 사용 가능합니다. 이렇게 만들어진 이미지는 스냅샷 역할도 겸합니다.

 

위의 상황들 모두 기존에는 환경을 구축하려는 사용자들에게 문서를 제공하여 스스로 환경을 구축할 것을 요청해야 했던 작업인 경우가 많은데, 이런 부분들을 완전히 자동화할 수 있으므로 그 어느때보다 많은 이점을 가져다주는 구성이라고 할 수 있겠습니다.

주의할 점

이렇게 편리한 배포판 내보내기/가져오기 기능이지만, 다른 한 편으로 주의할 부분이 있습니다. 이미지를 내보내기 전에 반드시 민감 정보가 포함되지 않았는지 확인해야 합니다.

• ~/.ssh 폴더의 개인 키(id_rsa, id_ed25519 등)
• 클라우드 자격 증명 파일(~/.aws/credentials, Azure azureProfile.json 등)
• npm Token, GitHub PAT, Docker Config 안의 로그인 정보
• 사내 라이선스 파일, 상용 폰트, Oracle JDK 같이 재배포 라이선스가 불명확한 바이너리

그래서 골든 이미지를 만들 때에는 한창 사용 중인 이미지를 내보내려는 것은 적절하지 않으며, 초기 상태의 WSL 이미지를 사용하는 것이 적절하다는 점을 기억해두어야 겠습니다.

 

아울러, 기술적으로는 다음의 두 가지 주의 사항을 점검해야 합니다.

• CPU 아키텍처 확인: Intel, AMD 프로세서를 사용하는 Windows PC에서 Qualcomm, Apple Silicon 프로세서를 사용하는 Windows PC로, 혹은 그 반대로 이미지를 교환하는 것은 불가합니다.
• WSL 버전 확인: WSL v1용 이미지를 WSL v2에서 가져와서 사용하는 것은 큰 문제가 없지만, WSL v2용 이미지를 WSL v1으로 내보내면 일부 고급 기능 (X11, SquashFS, Machine Learning 등)이 제대로 작동하지 않을 수 있습니다. 환경 차이를 줄이기 위해 Windows 11 이상의 OS로 통일하고, Microsoft Store를 통해 배포되는 WSL을 기본으로 사용하는 것을 추천합니다.

마무리

WSL v2 이미지 배포 전략을 도입하면 "내 PC에서는 잘 되는데?"라는 말을 팀에서 사라지게 만들 수 있습니다. 채용·프로젝트·교육 등 모든 개발 사이클에서 절약된 시간을 곧바로 ROI로 전환할 수 있기 때문입니다.

 

지금 한 번 wsl --export 명령어를 사용하고 있는 WSL 배포판에 적용해보고 다른 곳으로 가져가보세요. 팀 전체가 같은 출발선에서 코드를 달리는 것이 얼마나 큰 생산성 향상을 가져오는지 즉시 체감하게 될 것입니다.