# 윈도우 네이티브 개발 환경을 고쳤어요 > Clean Markdown view of GeekNews topic #26722. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26722](https://news.hada.io/topic?id=26722) - GeekNews Markdown: [https://news.hada.io/topic/26722.md](https://news.hada.io/topic/26722.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-02-16T09:47:07+09:00 - Updated: 2026-02-16T09:47:07+09:00 - Original source: [marler8997.github.io](https://marler8997.github.io/blog/fixed-windows/) - Points: 8 - Comments: 5 ## Summary 윈도우 네이티브 개발의 복잡한 **Visual Studio 설치 의존성**을 제거하기 위해, 오픈소스 CLI 도구 **`msvcup`** 이 등장했습니다. 이 도구는 MSVC 툴체인과 Windows SDK를 버전별로 **격리·자동 설치**하며, JSON 매니페스트 파싱과 락 파일을 통해 재현 가능한 빌드 환경을 제공합니다. Visual Studio Installer 없이도 완전한 스크립트 기반 빌드 체계를 구축할 수 있어, 윈도우에서도 리눅스 수준의 간결한 개발 환경 구성이 가능해집니다. ## Topic Body - 윈도우 네이티브 개발은 **Visual Studio 설치 의존성**으로 인해 복잡하고 비효율적 - **수십 GB 설치 용량**, **불투명한 구성 요소 관리**, **버전 불일치 문제** 등으로 개발자 생산성을 저하시킴 - 이를 해결하기 위해 **경량 CLI 도구 ‘msvcup’** 을 개발, MSVC 툴체인과 Windows SDK를 **버전별·격리된 형태로 자동 설치** 가능 - `msvcup`은 **JSON 매니페스트 파싱**, **자동 환경 설정(autoenv)** , **락 파일 지원** 등을 통해 재현 가능한 빌드 환경을 제공 - 이 접근은 Visual Studio Installer에 의존하지 않고 **스크립트 기반의 완전한 자동화 빌드 체계**를 가능하게 함 --- ### 윈도우 네이티브 개발의 문제점 - Visual Studio를 설치해야 하는 기존 방식은 **복잡한 설치 과정과 불안정한 의존성 관리**로 인해 개발자에게 부담을 줌 - “Desktop development with C++” 워크로드, 특정 SDK 버전 등 세부 선택이 필요하며, 잘못 선택 시 빌드 실패 발생 - 설치 용량이 50GB에 달하고, 제거 후에도 **레지스트리 잔여 항목과 백그라운드 서비스**가 남음 - **Linux**에서는 패키지 매니저 명령 한 줄로 툴체인을 설치할 수 있지만, Windows에서는 수천 개의 구성 요소를 수동으로 선택해야 함 - Visual Studio는 **에디터, 컴파일러, SDK가 얽힌 단일 구조**로, 버전 관리와 환경 재현이 어려움 - 결과적으로 “내 PC에서는 된다”는 식의 불일치가 빈번하며, 이는 **네이티브 개발의 진입 장벽**으로 작용 ### msvcup: 새로운 접근 - **[msvcup](https://github.com/marler8997/msvcup)** 은 Visual Studio 설치 없이 **MSVC 툴체인과 Windows SDK를 직접 다운로드·설치**하는 오픈소스 CLI 도구 - 각 버전은 `C:\msvcup\` 하위의 **격리된 디렉터리**에 설치되어, 버전 간 충돌 없이 병행 사용 가능 - 설치는 **수 분 내 완료**되며, ARM 크로스 컴파일 도구도 자동 포함 - `msvcup install` 명령은 필요한 패키지를 설치하고, `autoenv` 명령은 **자동 환경 디렉터리**를 생성 - 이 디렉터리에는 환경 변수를 자동 설정하는 **래퍼 실행 파일**과 `toolchain.cmake` 파일이 포함되어, CMake 프로젝트도 별도 설정 없이 빌드 가능 - `build.bat` 스크립트 예시에서는 `msvcup`을 통해 “Hello, World” 프로그램을 **Visual Studio 없이** 빌드 가능 - Windows 10 이상 환경에서 `curl`과 `tar`만 있으면 동작 ### 내부 동작 원리 - Microsoft가 배포하는 **Visual Studio 구성 요소 JSON 매니페스트**를 파싱하여 필요한 패키지만 식별 - 컴파일러, 링커, 헤더, 라이브러리 등 핵심 요소만 Microsoft CDN에서 직접 다운로드 - 설치된 구성 요소는 **락 파일(lock file)** 로 관리되어, 동일한 버전의 패키지를 팀 전체가 공유 가능 - `install` 및 `autoenv` 명령은 **멱등성(idempotent)** 을 가지며, 이미 설치된 경우 수 밀리초 내에 완료 ### 실제 적용 사례 - **Tuple**(페어 프로그래밍 앱)은 `msvcup`을 CI 빌드 시스템에 통합하여 Visual Studio 사전 설치 요구를 제거 - WebRTC를 포함한 수백 개의 C/C++ 프로젝트를 동일한 툴체인/SDK로 빌드 가능 - x86_64와 ARM 빌드를 모두 지원 - **장점** - 버전별 디렉터리 설치로 **병행 버전 관리 및 손쉬운 재설치** 가능 - **크로스 컴파일 자동 지원**, 별도 구성 불필요 - **락 파일 기반 재현성 보장**, Microsoft 측 변경 시 즉시 인지 가능 - **빠른 실행 속도**, 불필요한 재설치 없음 ### 한계와 확장 - `msvcup`은 **컴파일 툴체인 중심**으로 설계되어, Visual Studio IDE 자체가 필요한 경우에는 공식 설치가 여전히 필요 - 그러나 대부분의 네이티브 개발 워크플로에서는 **IDE 없이도 완전한 빌드 환경**을 제공 - 예시로 제시된 **raylib 빌드 스크립트**는 Visual Studio 없이도 SDK와 툴체인을 자동 설치하고 프로젝트를 빌드함 - GUI 없이 명령줄만으로 **완전 자동화된 빌드 과정** 수행 ### 결론 - `msvcup`은 Visual Studio Installer의 복잡성을 제거하고, **버전 관리 가능한 경량 네이티브 빌드 환경**을 제공 - 이 방식은 Windows 네이티브 개발을 **재현 가능하고 자동화된 형태**로 전환시키며, 개발자들이 IDE 의존성에서 벗어나도록 함 - Repo : https://github.com/marler8997/msvcup ## Comments ### Comment 51233 - Author: neo - Created: 2026-02-16T09:47:07+09:00 - Points: 2 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47022891) - 내가 하는 일보다 이건 더 복잡해 보임 그냥 [LTSC Visual Studio Build Tools](https://download.visualstudio.microsoft.com/download/pr/5d23a358-8ed7-4560-81e7-fb52d6a3ae02/2b25d9b457dfaf84fcb2af5b21264322b029b6efafd3178b1a4a8a7b79a18105/vs_BuildTools.exe)을 설치하고, `cl yourprogram.c /link user32.lib advapi32.lib ...` 같은 명령을 cmd 파일에 넣으면 됨 나는 vim으로 편집하고 이런 식으로 여러 유틸리티를 빌드해왔음 Visual Studio 툴체인에는 **LTSC와 안정 버전**이 존재하지만, 대부분은 잘 모름 협업 환경이라면 [공식 릴리스 히스토리 문서](https://learn.microsoft.com/en-gb/visualstudio/releases/2022/release-history#fixed-version-bootstrappers)에 있는 고정 버전을 쓰는 게 좋음 예전처럼 회사 전체가 동일한 툴체인 버전을 고정해서 쓰던 시절처럼 말임 - LTSC 채널은 **Visual Studio Professional 이상 라이선스**가 있어야 접근 가능함 그래서 학생이나 취미 개발자들은 잘 모르는 경우가 많음 반면 회사에서 VS를 쓰는 사람들은 대부분 알고 있음 - Visual Studio 2026에는 아직 LTSC 릴리스가 없음 언제 나올지 아는 사람 있음? - 리눅스의 툴체인도 **의존성 지옥**에서 자유롭지 않음 npm 패키지 설치하다가 cmake가 필요하다거나, glibc 버전 충돌이 생기거나, 최신 boost를 요구하는 C++ 프로젝트 등… heartbleed 때 openSSL 패치하던 기억도 남음 Visual Studio도 불편하지만, 진짜 지옥은 **.NET Framework 버전 혼란**임 윈도우 버전마다 설치된 .NET 버전이 다르고, 앱이 어떤 런타임에서 실행될지도 불명확함 그래서 대규모 배포에서는 C++로 **.NET 버전 확인용 shim**을 만들어서 올바른 런타임으로 실행되게 해야 함 - glibc 자체에서 의존성 문제가 생긴다면 정말 듣고 싶을 정도로 드묾 glibc 팀은 **하위·상위 호환성**에 매우 엄격함 [LWN 기사](https://lwn.net/Articles/605607/)를 보면 마지막으로 호환성을 깬 시점이 나와 있음 문제는 사람들이 glibc 버전을 잘못 고정(pinning)하는 경우임 glibc는 버전 고정을 하면 안 됨 GCC는 몇 번 호환성을 깬 적 있지만 대부분 C++ 표준 변경 때문이었음 - 최근 .NET은 완전히 달라졌음 .NET Framework는 이미 **레거시**이고, .NET 5 이후로는 이런 문제 없음 다만 여전히 구버전에 의존하는 앱들이 많음 - 예전엔 C/C++ 개발에서 시스템 패키지 매니저만으로도 충분했지만, 최신 버전 문제로 언어별 패키지 매니저가 생김 문제를 해결했지만 동시에 **새로운 복잡성**을 만들어냄 가끔은 그냥 시스템 패키지 매니저 시절로 돌아가고 싶음 - C/C++의 **빌드 UX 마찰**은 메모리 안전성과 별개로 짜증나는 부분임 임베디드 환경에서는 rust + probe-rs 쪽이 훨씬 쾌적함 - Visual Studio 설치기는 **명령줄 매개변수**로 무인 설치가 가능함 [공식 문서](https://learn.microsoft.com/en-us/visualstudio/install/use-command-line-parameters-to-install-visual-studio?view=visualstudio)에 설명되어 있음 2018년에 인터넷이 느린 위성망 환경에서 일할 때, 오프라인 설치 패키지를 만들어야 해서 이 방법을 썼음 - 시도해봤는데 **불필요한 다운로드**가 너무 많았고, 설치에는 여전히 관리자 권한이 필요했음 - (고지연 연결이라니… “high-latency” 표현이 더 맞을 듯함) - 스크립트를 보니 `curl -L -o msvcup.zip https://github.com/marler8997/msvcup/releases/...` 이런 식으로 되어 있음 하지만 **출처 불명 GitHub 계정의 실행 파일**을 해시 검증도 없이 설치하는 건 꺼려짐 Windows 상황이 블로그에서 말한 만큼 나쁘진 않지만, 이건 해결책이라기보다 또 다른 위험한 설치 스크립트 같음 - 굳이 실행 파일을 설치할 필요 없음 그냥 스크립트를 **직접 읽고 검토**하면 됨 curl|sh 방식도 결국 소스코드를 내려받는 것일 뿐, 실행 파일을 바로 설치하는 것보다 위험하지 않음 - Jonathan Marler는 Zig 관련 발표와 **win32 API 바인딩 작업**으로 유명함 그의 프로젝트 [zigwin32](https://github.com/marlersoft/zigwin32)는 Microsoft의 [win32metadata](https://github.com/microsoft/win32metadata)에서도 링크되어 있음 즉 신뢰할 만한 인물임 - 이 글, **AI가 쓴 것처럼** 느껴짐 “it’s not just X, but Y” 같은 문장 구조나 강조 리스트가 전형적인 LLM 스타일임 프로젝트가 얼마나 인간이 만든 건지 궁금함 - 네 닉네임이 “its_notjack”인 게 좀 웃김 - 나도 처음엔 의심했음 리스트 구조가 어색하고 일관성이 부족했음 하지만 만약 LLM이 썼다면, **요즘 LLM의 품질이 꽤 올라왔다는 증거**일 수도 있음 Grammarly 같은 도구의 영향일 수도 있음 - 어쩌면 사람들이 LLM 스타일을 **모방**하고 있는 걸지도 모름 그게 독자에게 읽기 편하니까 - “The key insight is…” 같은 표현은 **Claude**가 자주 쓰는 문체라서 그런 느낌이 남 그냥 솔직히 AI 사용 여부를 밝혔으면 좋겠음 - Visual Studio DX를 개선하려는 시도로 **msvcup**은 정말 신선함 예전에 대학 시절 이런 게 있었으면 좋았을 텐데 대안으로는 [컨테이너에 Build Tools 설치](https://learn.microsoft.com/en-us/visualstudio/install/build-tools-container?view=vs-2022) 방식도 있음 - 그냥 **winget**으로 설치하면 됨 `winget install --id Microsoft.VisualStudio.2022.BuildTools` WinRT 기능이 필요하면 `winget install --id Microsoft.WindowsSDK.10.0.18362` `winget install --id Microsoft.WindowsAppRuntime.1.8` 추가 가능 - 예전에 이 패키지들을 지원했었는데, 단순하지 않음 어떤 **workload**를 설치할지도 지정해야 하고, 프로젝트를 모르면 시행착오가 많음 `.vsconfig`가 좀 도와주긴 하지만 완벽하진 않음 - 오픈소스 프로젝트들이 **MinGW 지원**을 막지 않았으면 좋겠음 추가 DLL 없이도 잘 동작하는 좋은 컴파일러임 오픈소스가 왜 굳이 독점 컴파일러를 강제하는지 이해가 안 됨 - MinGW는 일부 **Windows 전용 라이브러리(WIL)** 와 호환되지 않음 [WIL](https://github.com/microsoft/wil)은 커널 개발자들이 즐겨 쓰는 라이브러리로, 코드 안전성과 편의성을 크게 높여줌 - 외부에서 빌드된 **MSVC 라이브러리**를 링크해야 할 때는 MinGW가 옵션이 아님 예를 들어 Steamworks SDK는 MinGW로 빌드되지만 런타임에서 크래시함 - 나도 MinGW 지원이 더 많아졌으면 좋겠음 이 블로그 글에서도 언급조차 없어서 아쉬움 - MinGW는 싫음 그냥 **Clang + MSVC STL + WinSDK** 조합이 훨씬 깔끔함 - 또는 이렇게 간단히 할 수도 있음 `"winget install Microsoft.VisualStudio.BuildTools"` `"winget install Microsoft.WindowsSDK.10.0.26100"` - 나도 항상 이렇게 함 **노력 대비 안정성**이 좋아서 선호함 - 하지만 이런 설치는 시스템 전역이라, 프로젝트별로 다른 버전이 필요할 땐 곤란함 모든 언어에 **Python uv 같은 버전 격리 도구**가 있었으면 좋겠음 - Windows 비판 중 상당수는 **20년 전 이야기**임 Bing, Copilot, 광고 같은 건 비판받을 만하지만, 대부분 **비활성화 가능**함 ### Comment 51256 - Author: click - Created: 2026-02-16T20:05:08+09:00 - Points: 1 - Parent comment: 51233 - Depth: 1 저도 Ubuntu 24.04에서 빌드하고 cents 6인가 7에서 실행하려니 glibc 의존성 문제가 발생하더라고요 기본값으로 빌드 환경의 glibc 버전을 가져가는 게 문제로 보이긴 합니다. ### Comment 51299 - Author: penza1 - Created: 2026-02-18T00:41:05+09:00 - Points: 1 - Parent comment: 51256 - Depth: 2 glibc 는 의존할수밖에요.. python/jv/.net/js 같은 스크립트 언어가 아닌 glibc 의존은 있을수밖에 없습니다 각 배포판별 라이브러리를 배포 하는 이유기도 하지요 최소 glibc 에서 빌드한건 별다른 의존성없다면 다른 상위 버전 배포판에서도 충분히 실행 가능 합니다 ### Comment 51253 - Author: geekbini - Created: 2026-02-16T19:21:05+09:00 - Points: 1 wsl2 에 우분투로 윈도우도 많이 개발하기에 좋아지긴했죠. 그런데 vscode가 아닌 비쥬얼스튜디오 환경이라면 이게 도움이 그나마 될 듯 해보이네요. 근데 choco나 winget같은 패키지매니져로 원도우에서 안되나보네요. ### Comment 51255 - Author: click - Created: 2026-02-16T20:03:07+09:00 - Points: 1 - Parent comment: 51253 - Depth: 1 패키지 매니저들은 sdk보다는 최종 결과물에 초점을 맞추는 듯 하긴 해요 vcredist 같은 건 대부분의 개발자들이 패키지 매니저 스크립트 내에서 설치하도록 설정하긴 하던데 빌드 환경은 좀 이야기가 다르긴 합니다