.NET에서 NuGet 패키지 사용 마스터하기
Source: Dev.to
NuGet란 실제로 무엇인가?
.NET의 Amazon 또는 Mercado Libre라고 생각하면 됩니다. 가구의 나사를 직접 만들지 않고, 가게에 주문하는 것과 같습니다.
- 패키지 (Package): 구매하는 제품 (Newtonsoft.Json, EntityFramework).
- 소스 (Source / Feed): 패키지가 저장되는 창고 또는 가게.
내 패키지는 어디에 저장되나요?
많은 개발자는 dotnet restore를 실행하면 DLL이 마법처럼 프로젝트에 나타난다고 생각합니다. 실제 흐름을 이해하는 것이 무엇이 배경에서 일어나고 있는지 파악하는 데 중요합니다:
Request: 프로젝트(.csproj)가 Newtonsoft.Json v13.0.1을 요청합니다.
Restore: NuGet이 설정된 Sources에서 검색합니다.
Global Packages Folder: NuGet이 패키지를 다운로드하고 압축을 푼 후, 사용자 계정의 전역 폴더에 저장합니다 (Windows에서는 일반적으로 %userprofile%\.nuget\packages, Linux/Mac에서는 ~/.nuget/packages). 프로젝트 내부에 저장되지 않습니다.
Build: 빌드 시 .NET이 전역 폴더의 DLL을 읽어 bin/Debug 또는 bin/Release 폴더로 복사합니다.
왜 중요한가? 디스크 공간을 절약할 수 있기 때문입니다. 동일한 라이브러리를 사용하는 10개의 프로젝트가 있더라도 한 번만 다운로드됩니다.
설정 계층 구조
설정을 한 줄이라도 작성하기 전에 NuGet이 어떻게 생각하는지 이해해야 합니다. restore를 실행하면 프로젝트만 보는 것이 아니라, NuGet은 계층적인 설정을 결합합니다:
- 머신 수준: 이 파일은 물리적으로 존재하지 않거나 비어 있는 경우가 많으며, 관리자에 의해 별도로 배치된 경우에만 존재합니다.
- 사용자 수준: 가장 흔히 사용되는 파일 (
%appdata%\NuGet\NuGet.Config)이며, 시간이 지나면서 많은 *“디지털 쓰레기”*가 쌓일 수 있습니다. - 디렉터리 수준 (재귀): 솔루션 폴더에서 시작해 설정을 찾지만, 없으면 상위 폴더로 올라가고, 다시 그 위 폴더로, 최종적으로 디스크 루트까지 탐색합니다.
“내 컴퓨터에서는 동작한다”는 말의 출처 🤷♂️
여기서 유명한 밈이 탄생합니다. 당신은 사용자 수준에 사설 피드를 설정해 두고 여러 프로젝트를 작업하고 있습니다. 새 프로젝트를 만들면 정상적으로 컴파일됩니다. 하지만 동료가 레포지토리를 클론하고 빌드하려고 하면… 오류가 발생합니다.
왜일까? 프로젝트가 보이지 않는 사용자 전용 설정에 의존하고 있기 때문입니다. 동료의 환경에는 그 피드가 존재하지 않습니다.
현재 활성화된 설정 확인하기
솔루션 폴더에서 다음 명령을 실행합니다:
dotnet nuget list source이 명령은 해당 폴더에서 NuGet이 실제로 사용하고 있는 모든 소스의 최종 결합 목록을 보여줍니다. 인식하지 못하는 경로나 중단된 서버가 보인다면, 상속된 설정이 원인입니다.
NuGet.config
솔루션 루트에 명시적인 NuGet.config 파일을 만들면, 유해한 상속 체인을 차단하고 모든 사람이 동일하게 프로젝트를 빌드할 수 있게 됩니다.
elimina toda la "basura" heredada del usuario o máquina -->
이 설정의 장점
- 🛡 격리: “ 로 전역(사용자·머신) 설정으로부터 프로젝트를 보호합니다.
- 🛠 독립성: 새 개발자는
git clone후dotnet restore만 하면 됩니다. - 🔄 CI/CD 친화적: 파이프라인이 정확히 어디서 패키지를 찾아야 할지 알기 때문에 별도 조치가 필요 없습니다.
우선순위 혼란
nuget.org와 GitHubFeed를 모두 설정했는데, 두 소스에 Newtonsoft.Json 패키지가 존재한다면 어느 것이 다운로드될까요?
NuGet은 **“먼저 응답한 것”**을 선택합니다. 이는 두 가지 위험을 내포합니다:
- 성능: 사설 패키지를 찾기 전에 공개 저장소를 먼저 검색하게 됩니다.
- 보안: 공격자가
nuget.org에 내부 패키지와 동일한 이름(예:MiBanco.Core)의 악성 패키지를 업로드할 경우, 프로젝트가 이를 무심코 다운로드할 수 있습니다. 🚨
