▲

윈도우 네이티브 개발 환경을 고쳤어요

 (marler8997.github.io)
3P by GN⁺ 22시간전 | ★ favorite | 댓글 4개
  • 윈도우 네이티브 개발은 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 은 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
▲
geekbini 13시간전  [-]

wsl2 에 우분투로 윈도우도 많이 개발하기에 좋아지긴했죠. 그런데 vscode가 아닌 비쥬얼스튜디오 환경이라면 이게 도움이 그나마 될 듯 해보이네요. 근데 choco나 winget같은 패키지매니져로 원도우에서 안되나보네요.

답변달기
▲
click 12시간전  [-]

패키지 매니저들은 sdk보다는 최종 결과물에 초점을 맞추는 듯 하긴 해요
vcredist 같은 건 대부분의 개발자들이 패키지 매니저 스크립트 내에서 설치하도록 설정하긴 하던데
빌드 환경은 좀 이야기가 다르긴 합니다

답변달기
▲
GN⁺ 22시간전  [-]
Hacker News 의견들

  • 내가 하는 일보다 이건 더 복잡해 보임
    그냥 LTSC Visual Studio Build Tools을 설치하고, cl yourprogram.c /link user32.lib advapi32.lib ... 같은 명령을 cmd 파일에 넣으면 됨
    나는 vim으로 편집하고 이런 식으로 여러 유틸리티를 빌드해왔음
    Visual Studio 툴체인에는 LTSC와 안정 버전이 존재하지만, 대부분은 잘 모름
    협업 환경이라면 공식 릴리스 히스토리 문서에 있는 고정 버전을 쓰는 게 좋음
    예전처럼 회사 전체가 동일한 툴체인 버전을 고정해서 쓰던 시절처럼 말임

    • 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 기사를 보면 마지막으로 호환성을 깬 시점이 나와 있음
      문제는 사람들이 glibc 버전을 잘못 고정(pinning)하는 경우임
      glibc는 버전 고정을 하면 안 됨
      GCC는 몇 번 호환성을 깬 적 있지만 대부분 C++ 표준 변경 때문이었음
    • 최근 .NET은 완전히 달라졌음
      .NET Framework는 이미 레거시이고, .NET 5 이후로는 이런 문제 없음
      다만 여전히 구버전에 의존하는 앱들이 많음
    • 예전엔 C/C++ 개발에서 시스템 패키지 매니저만으로도 충분했지만, 최신 버전 문제로 언어별 패키지 매니저가 생김
      문제를 해결했지만 동시에 새로운 복잡성을 만들어냄
      가끔은 그냥 시스템 패키지 매니저 시절로 돌아가고 싶음
    • C/C++의 빌드 UX 마찰은 메모리 안전성과 별개로 짜증나는 부분임
      임베디드 환경에서는 rust + probe-rs 쪽이 훨씬 쾌적함

  • Visual Studio 설치기는 명령줄 매개변수로 무인 설치가 가능함
    공식 문서에 설명되어 있음
    2018년에 인터넷이 느린 위성망 환경에서 일할 때, 오프라인 설치 패키지를 만들어야 해서 이 방법을 썼음

    • 시도해봤는데 불필요한 다운로드가 너무 많았고, 설치에는 여전히 관리자 권한이 필요했음
    • (고지연 연결이라니… “high-latency” 표현이 더 맞을 듯함)

  • 스크립트를 보니
    curl -L -o msvcup.zip https://github.com/marler8997/msvcup/releases/...
    이런 식으로 되어 있음
    하지만 출처 불명 GitHub 계정의 실행 파일을 해시 검증도 없이 설치하는 건 꺼려짐
    Windows 상황이 블로그에서 말한 만큼 나쁘진 않지만, 이건 해결책이라기보다 또 다른 위험한 설치 스크립트 같음

    • 굳이 실행 파일을 설치할 필요 없음
      그냥 스크립트를 직접 읽고 검토하면 됨
      curl|sh 방식도 결국 소스코드를 내려받는 것일 뿐, 실행 파일을 바로 설치하는 것보다 위험하지 않음
    • Jonathan Marler는 Zig 관련 발표와 win32 API 바인딩 작업으로 유명함
      그의 프로젝트 zigwin32는 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 설치 방식도 있음

  • 그냥 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은 커널 개발자들이 즐겨 쓰는 라이브러리로, 코드 안전성과 편의성을 크게 높여줌
    • 외부에서 빌드된 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, 광고 같은 건 비판받을 만하지만, 대부분 비활성화 가능함
답변달기
▲
click 12시간전  [-]

저도 Ubuntu 24.04에서 빌드하고 cents 6인가 7에서 실행하려니 glibc 의존성 문제가 발생하더라고요
기본값으로 빌드 환경의 glibc 버전을 가져가는 게 문제로 보이긴 합니다.

답변달기