개발 머신으로 손색없는 윈도우, 설정이 관건

마이크로소프트 윈도우는 지난 몇 년 동안 개발 환경 측면에서 큰 발전을 이뤘다. 윈도우 리눅스 서브시스템(WSL)을 사용하면 VM의 거추장스러움과 오버헤드 없이 윈도우에서 매끄럽게 리눅스를 다룰 수 있다. 일반적인 워크플로우에 포함되는 모든 주요 소프트웨어 개발 툴에는 네이티브 윈도우 에디션이 존재한다. 또한 아직 정당한 평가를 받지 못하고 있지만 마이크로소프트는 윈도우에 다양한 개발자 편의 기능도 도입했다. 다만 이러한 기능이 자동으로 구현되는 것은 아니다. 윈도우를 개발 시스템으로 최대한 활용하기 위해서는 약간의 수고가 필요하다. 개발자의 일반적인 작업 환경 설정 방식과 큰 차이는 없지만 구체적인 단계에 주의가 필요하며, 그중 몇 가지는 모호한 면이 있다. 이 기사에서는 소프트웨어 개발 작업용으로 윈도우 시스템을 설정하기 위한 가장 중요한 5단계를 안내한다. 참고로 많은 작업에서 관리자 권한이 필요하다. 1단계 : 윈도우 리눅스 서브시스템 설치 WSL은 VM보다 낮은 오버헤드로 명령줄에서 전체 리눅스 시스템을 제공한다. 전 세계 소프트웨어 개발 작업에서 리눅스, 또는 맥OS와 같은 유닉스계열 시스템이 차지하는 비중이 가장 큰 만큼 터미널 세션에서 실제 리눅스 시스템을 사용할 수 있다는 점은 매우 큰 장점이다. WSL을 설치하려면 관리자 권한으로 콘솔을 열고 다음을 입력한다. wsl --install WSL 핵심 파일과 실행할 리눅스 배포판을 모두 다운로드해야 하므로 설치에 어느정도 시간이 걸릴 수 있다. WSL의 기본 리눅스 배포판은 우분투 26.04 LTS다. 기본값인 우분투도 개발자가 리눅스 배포판에 기대하는 요건을 대부분 충족하지만 다른 배포판도 사용할 수 있고, 계속 추가되고 있다. WSL용 맞춤형 리눅스 배포판을 사용자가 직접 빌드하는 것도 가능하다. WSL이 설치되면 wsl --list --online을 입력해 사용 가능한 모든 배포판을 확인할 수 있다. wsl --install (왼쪽 열의 이름 사용)을 입력해 원하는 배포판을 설치한다. 각자의 기호 또는 구체적인 필요에 맞게 선택하면 된다. 예를 들어 데비안 리눅스에 가장 익숙하거나 현재 데비안을 기반으로 상정하는 프로젝트를 개발하고 있다면 데비안이 적합할 수 있다. 그러나 대부분의 사용 사례에서는 우분투가 무난할 것이다. WSL 배포판은 기본적으로 사용자 AppData 디렉터리의 AppData\Local\Packages에 저장된다. 다른 디렉터리나 볼륨으로 옮기려면 wsl --manage --move 명령을 사용하면 된다. 마이크로소프트는 최근 윈도우에서 네이티브로 리눅스 컨테이너를 실행할 수 있게 해주는 중요한 새로운 기능인 WSL 컨테이너를 도입했다. WSL 컨테이너는 현재 공개 프리뷰 단계다. 2단계 : 프로젝트를 위한 데브 드라이브(Dev Drive) 볼륨 구성 대부분의 윈도우 사용자는 프로젝트를 저장할 때 사용자 프로필 내부든 다른 경로든 NTFS 볼륨의 디렉터리를 기본으로 사용한다. 기본값으로 나쁘지는 않지만 그보다 더 좋은 방법이 있고, 그중 하나가 데브 드라이브다. 데브 드라이브는 윈도우에서 제공되는 새로운 볼륨 유형으로 NTFS 대신 ReFS(“Resilient File System”의 약어)라는 더 새로운 파일 시스템을 사용한다. 원래 윈도우 서버용으로 개발된 ReFS는 소프트웨어 개발에서 발생하는 워크로드에 유용한 다음과 같은 기능을 제공한다. 쓰기 시 복사(Copy-on-write). 프로젝트 디렉터리에는 경우에 따라 수천 개의 파일과 수십 개의 디렉터리가 존재한다. ReFS를 사용하면 이러한 프로젝트의 복사본을 훨씬 더 빠르게 처리할 수 있다. 파일이 변경될 때만 복사본을 만들기 때문이다. 변경되지 않은 복사본은 원본을 가리키는 디스크 상의 링크다. 안티바이러스 동작에 대한 더 강력한 제어. 데브 드라이브는 기본적으로 윈도우 네이티브 안티바이러스 툴에 의한 간섭을 최소화한다. 개발 디렉터리를 수동으로 검사에서 제외하는 것도 가능하지만 데브 드라이브를 설정하기만 하면 드라이브의 내용물에 대한 검사가 자동으로 관리된다. VHD 또는 파티션. 데브 드라이브는 가상 하드 디스크 파일로 설정할 수도 있고 포맷된 파티션에서 직접 사용할 수도 있다. 유연성은 전자가 더 높고(예를 들어 크기 조절이 더 쉬움), 성능은 후자가 대체로 약간 더 유리하다. 데브 드라이브에 대해서는 다음과 같은 두 가지를 유의해야 한다. 데브 드라이브는 툴이 아닌 프로젝트용이다. 데브 드라이브에는 프로젝트 리포지토리, 빌드 아티팩트, 캐시된 파일 등을 저장하고, 언어 런타임이나 컴파일러, 기타 툴체인 유틸리티는 데브 드라이브가 아닌 일반 NTFS 볼륨에 설치해야 한다. 로우레벨 파일 시스템 툴은 데브 드라이브 볼륨에서 생각대로 작동하지 않을 수 있다. 파일 테이블 정보를 직접 읽는 방식으로 작동하는 전문가 수준의 파일 시스템 유틸리티는 데브 드라이브(그리고 일반적인 ReFS 볼륨)에서 의도한 대로 작동하지 않을 수 있다. 예를 들어 더 높은 성능을 위해 NTFS 볼륨 데이터를 직접 읽는 디스크 공간 관리 툴인 위즈트리(WizTree)는 ReFS 볼륨에서 사용할 경우 속도가 매우 느려진다. 3단계 : 패키지 관리에 윈겟(WinGet) 사용 얼마 전까지도 윈도우에는 공식적인 패키지 관리 시스템이나 중앙 패키지 관리자가 마땅히 없었다. 마이크로소프트 스토어는 해결책이 아니었다. 마이크로소프트 스토어는 유니버설 윈도우 플랫폼 패키징 시스템에 부합하는 앱만 설치했고 마이크로소프트 스토어를 통해 전달되는 앱만 제공했으며, 명령줄 인터페이스도 없었다. 최근 마이크로소프트는 윈도우를 위한 제대로 된 패키지 관리 시스템인 윈겟을 도입했다. 윈겟은 모든 유형의 윈도우 앱을 설치하며 상호작용과 자동화를 위한 완전한 명령줄 인터페이스를 제공한다. 또한 윈도우 소프트웨어 생태계에서 광범위하게 지원된다. 거의 대부분의 윈도우 프로그램에 윈겟 패키지가 있다고 해도 과언이 아니다. 즉, 윈겟은 개발 시스템에 필요한 모든 툴을 확보하기 위한 이상적인 방법이다(기사 후반에 추가로 다룸). 윈겟 리포지토리에서 패키지를 검색하려면 다음을 입력한다. winget search "Thing to search for" 찾는 패키지의 이름에 공백이 있는 경우(예: 어도비 아크로뱃 리더) 따옴표를 사용해야 한다. WinGet search output for the term “Acrobat”. The Id column shows the name to use with the winget install command. Foundry “Acrobat”에 대한 윈겟 검색 결과. Id 열에는 winget install 명령에 사용할 이름이 표시된다. 윈겟 패키지 설치는 다음과 같이 아주 간단하다. winget install 여기서 는 설치할 패키지의 Id다(이름이 아님!). 위에서 언급한 어도비 아크로뱃 리더의 경우 다음과 같이 입력한다. winget install Adobe.Acrobat.Reader.64-bit 패키지 관리 워크플로우를 위한 보기 좋은 GUI를 원한다면 유니겟UI(UniGetUI)가 있다. 유니겟UI는 윈겟, 스쿱(Scoop), 초콜레티(Chocolatey), npm, pip, 카고(Cargo) 등 다양한 패키지 관리 소스의 패키지를 관리한다. 4단계 : 스크립트를 허용하기 위한 파워셸 설정 다른 여러 작업을 진행하기 전에 미리 해두고 넘어가면 좋은 일회성 작업으로, 바로 로컬 스크립트 실행을 허용하는 파워셸 주문이다. 파워쉘을 관리자 권한으로 실행하고 다음을 입력한다. set-executionpolicy remotesigned 이 작업은 시스템 수명 동안 한 번만 하면 된다. 윈도우는 인터넷에서 다운로드한 파워셸 스크립트에 대해서는 여전히 서명을 요구하지만 이는 본질적으로 예외 사례이고, 로컬에서 생성하는 모든 스크립트는 그대로 작동한다. 5단계 : 필수 개발 툴 설치 윈겟을 사용하면 개발용 윈도우 시스템에서 개발자들이 가장 보편적으로 원하는 모든 툴에 빠르게 접근할 수 있다. 개발자라면 각자 선호하는 툴이 이미 있겠지만, 윈도우 개발에 유용한 대표적인 툴은 다음과 같다. 손쉬운 설치를 위해 윈겟 Id도 첨부한다. 깃(Git.Git): 모든 개발자가 가장 즐겨 사용하는 버전 제어 시스템. 윈도우 버전도 본질적으로 다른 플랫폼과 동일하다. 비주얼 스튜디오 빌드툴(BuildTools) 2022(Microsoft.VisualStudio.2022.BuildTools): 마이크로소프트 비주얼 스튜디오의 C/C++ 컴파일 시스템을 사용하는 데 필요한 최소한의 명령줄 툴. C메이크(CMake)(Kitware.Cmake): C/C++를 위한 크로스 플랫폼 빌드 솔루션. C/C++ 언어를 사용하는 크고 복잡한 프로젝트에 필요한 경우가 많다. 참고로, 기본 빌드툴 설치본에는 일반적으로 최소한의 C/C++ 빌드 작업을 수행하기 위한 툴이 없다. 다음 명령을 실행하면 필요한 요소를 받을 수 있다. winget install -e --id Microsoft.VisualStudio.2022.BuildTools --force --override "--passive --wait --add Microsoft.VisualStudio.Workload.VCTools;includeRecommended" 다음과 같은 인기 있는 편집기도 모두 네이티브 윈도우 앱으로 제공된다. 마이크로소프트 비주얼 스튜디오 코드(Microsoft.VisualStudioCode) GNU 이맥스(Emacs)(GNU.Emacs) 네오빔(Neovim)(Neovim.Neovim) 선택 사항이지만 유용한 기타 윈도우 개발용 툴은 다음과 같다. 윈도우용 코어유틸(CoreUtils for Windows)(Microsoft.Coreutils): 마이크로소프트가 유지 관리하는 오픈소스 프로젝트로, cp, grep, find, ls를 비롯한 수십 가지 리눅스 명령줄 유틸리티를 윈도우에서 사용할 수 있게 해준다. MSYS2(MSYS2.MSYS2): GCC 컴파일러를 사용해 윈도우 바이너리를 빌드하기 위한 툴 모음. 기본적으로 시그윈(Cygwin) 환경을 기반으로 한 비주얼 스튜디오 빌드 스택의 대안이다. LLVM(LLVM.LLVM): 클랭, 러스트, 스위프트 및 기타 많은 프로젝트를 뒷받침하는 컴파일러 프레임워크. 참고로 LLVM을 종속 항목으로 사용하는 경우 프로젝트에 필요한 특정 LLVM 버전을 설치해야 한다. 도커 데스크톱(XP8CBJ40XLBWKX): 도커 데스크톱 애플리케이션의 윈도우 네이티브 버전. 마이크로소프트 파워토이(Microsoft.PowerToys): 윈도우를 쉽게 조정할 수 있게 해주는 30여 개의 유틸리티로 구성된 모음으로, 호스트 파일 편집기, 파일 잠금 해제 툴(특정 파일을 잠그고 있는 프로세스를 찾는 데 유용), 창 고정 툴, 텍스트 추출 툴(화면에서 커서로 하이라이트할 수 없는 부분을 포함해 어디서나 텍스트를 읽는 데 유용) 등이 포함돼 있다. 한 단계로 완성하는 윈도우 개발 시스템 대부분의 개발자는 개발 시스템의 설치와 구성을 자신이 온전히 통제하는 편을 선호하지만 곧바로 사용할 수 있는, 지향점이 뚜렷한 스타터 키트를 원하는 경우도 있다. 마이크로소프트는 지름길을 원하는 사람들을 위해 윈도우 디벨로퍼 컨피그(Windows Developer Config)를 제공한다. 윈도우 디벨로퍼 컨피그는 시스템을 개발 환경으로 설정하는 파워셸 스크립트 모음이다. 완전한 개발 워크스테이션 설정, 명령줄 툴에 중점을 둔 “WSL 컴포트(WSL Comfort)” 설정, 또는 컴파일러/인터프리터, 추가 툴 및 VS 코드 확장을 제공하는 언어별 워크로드 설정 중에서 선택할 수 있다. dl-itworldkorea@foundryco.com