프로젝트와 패키지

프로그램이 커지면 코드를 여러 프로젝트로 나누고, 다른 사람이 만든 라이브러리를 가져다 쓰게 됩니다. .NET에서는 이 일을 어셈블리, 프로젝트, 솔루션, NuGet 패키지라는 네 가지 단위로 다룹니다. 이 장에서는 각 단위의 관계를 정리하고, 프로젝트 참조와 패키지 추가, 그리고 배포용 결과물을 만드는 방법을 살펴봅니다.

어셈블리 · 프로젝트 · 솔루션

네임스페이스와 어셈블리는 별개의 개념입니다. 네임스페이스는 이름을 정리하는 논리적 단위이고, 어셈블리는 배포되는 물리적 단위입니다. 한 어셈블리에 여러 네임스페이스가 들어갈 수도 있고, 같은 네임스페이스가 여러 어셈블리에 걸칠 수도 있습니다.

솔루션과 여러 프로젝트 만들기

흔한 구조는 실행 프로젝트, 핵심 로직을 담은 클래스 라이브러리, 테스트 프로젝트를 한 솔루션에 두는 것입니다. 다음 명령으로 그 뼈대를 만들 수 있습니다.

mkdir Shop && cd Shop
dotnet new sln -n Shop
dotnet new classlib -o src/Shop.Core
dotnet new console -o src/Shop.Cli
dotnet sln add src/Shop.Core src/Shop.Cli

# Shop.Cli 가 Shop.Core 를 쓰도록 프로젝트 참조 추가
dotnet add src/Shop.Cli reference src/Shop.Core

dotnet build   # 솔루션 폴더에서 실행하면 모든 프로젝트를 빌드합니다

프로젝트 참조를 추가하면 Shop.Cli.csproj에 다음 항목이 생깁니다. 빌드할 때 참조된 프로젝트가 먼저 빌드되고, 그 어셈블리가 출력 폴더로 복사됩니다.

<ItemGroup>
  <ProjectReference Include="..\Shop.Core\Shop.Core.csproj" />
</ItemGroup>

접근 한정자와 어셈블리 경계

다른 프로젝트에서 쓸 수 있는 것은 public으로 선언한 타입과 멤버뿐입니다. internal은 같은 어셈블리 안에서만 보이므로, 라이브러리의 내부 구현을 감추는 데 씁니다. 최상위 타입에 접근 한정자를 생략하면 internal이 됩니다.

// src/Shop.Core/PriceCalculator.cs
namespace Shop.Core;

public static class PriceCalculator
{
    public static decimal WithTax(decimal price) => Round(price * (1 + TaxRate));

    internal const decimal TaxRate = 0.1m;          // 이 어셈블리 안에서만 보입니다

    private static decimal Round(decimal value) => Math.Round(value, 0);
}

// src/Shop.Cli/Program.cs
using Shop.Core;

Console.WriteLine(PriceCalculator.WithTax(10_000m)); // 11000
// PriceCalculator.TaxRate 는 internal 이라 여기서 쓸 수 없습니다

테스트 프로젝트에서 internal 멤버를 시험해야 한다면 라이브러리 쪽에 InternalsVisibleTo 특성을 지정해 특정 어셈블리에만 공개할 수 있습니다.

NuGet 패키지 사용

NuGet은 .NET의 패키지 관리자입니다. dotnet add package로 패키지를 추가하면 프로젝트 파일에 PackageReference가 기록되고, 빌드할 때 패키지가 자동으로 복원됩니다.

cd src/Shop.Cli
dotnet add package Humanizer           # 최신 안정 버전 추가
dotnet add package Humanizer --version <버전>  # 특정 버전 지정
dotnet list package                    # 참조 중인 패키지 보기
dotnet list package --outdated         # 새 버전이 있는 패키지 보기
dotnet remove package Humanizer        # 제거
dotnet restore                         # 패키지 복원만 따로 실행

using Humanizer;

Console.WriteLine("order_created_at".Humanize()); // Order created at
Console.WriteLine(TimeSpan.FromMinutes(95).Humanize(2)); // 1 hour, 35 minutes

패키지를 고를 때는 nuget.org에서 내려받기 수, 최근 업데이트, 라이선스, 대상 프레임워크를 확인합니다. 여러 프로젝트가 같은 패키지 버전을 써야 한다면 솔루션 루트의 Directory.Packages.props에서 버전을 한곳에 관리하는 중앙 패키지 관리를 쓸 수 있고, 공통 빌드 설정은 Directory.Build.props에 모아 둘 수 있습니다.

게시(publish)

dotnet build의 결과는 개발용입니다. 다른 컴퓨터에 배포할 결과물은 dotnet publish로 만듭니다.

# 프레임워크 종속: 대상 컴퓨터에 .NET 런타임이 있어야 합니다(결과물이 작음)
dotnet publish src/Shop.Cli -c Release -o out

# 자체 포함: 런타임까지 함께 담습니다(설치 없이 실행)
dotnet publish src/Shop.Cli -c Release -r linux-x64 --self-contained -o out-linux

# 단일 파일로 묶기
dotnet publish src/Shop.Cli -c Release -r win-x64 --self-contained -p:PublishSingleFile=true

-r은 대상 플랫폼을 뜻하는 런타임 식별자(RID)로, win-x64, linux-x64, osx-arm64 등이 있습니다. 시작 속도와 메모리가 중요하다면 프로젝트에 <PublishAot>true</PublishAot>를 넣어 네이티브 AOT로 컴파일할 수 있지만, 리플렉션을 많이 쓰는 라이브러리와는 맞지 않을 수 있습니다. 라이브러리를 NuGet 패키지로 만들어 공유하려면 dotnet pack -c Release를 실행합니다.

정리

• 프로젝트 하나가 어셈블리 하나를 만들고, 솔루션은 여러 프로젝트를 묶습니다.
• dotnet sln add로 솔루션에 프로젝트를 넣고, dotnet add reference로 프로젝트끼리 연결합니다.
• 다른 어셈블리에 공개할 것은 public, 내부 구현은 internal로 선언합니다.
• dotnet add package로 NuGet 패키지를 추가하면 PackageReference가 기록되고 빌드할 때 복원됩니다.
• 배포용 결과물은 dotnet publish로 만들며, 프레임워크 종속 · 자체 포함 · 단일 파일 · 네이티브 AOT 중에서 고릅니다.