# NuGet 레지스트리 작업 dotnet 명령줄 인터페이스(CLI)를 구성하여 NuGet 패키지를 GitHub Packages에 게시하고, GitHub Packages에 저장된 패키지를 .NET 프로젝트의 종속성으로 사용할 수 있습니다. ## 인증 진행 중 GitHub Packages > \[!NOTE] > GitHub Packages 은 .를 사용하는 personal access token (classic)인증만 지원합니다. 자세한 내용은 [개인용 액세스 토큰 관리](/ko/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens)을(를) 참조하세요. 프라이빗, 내부, 퍼블릭 패키지를 게시, 설치, 삭제하려면 액세스 토큰이 필요합니다. personal access token (classic)을 사용하여 GitHub Packages 또는 GitHub API에 인증할 수 있습니다. personal access token (classic)을(를) 만들 때 필요에 따라 토큰의 범위를 다르게 할당할 수 있습니다. personal access token (classic)의 패키지 관련 범위에 대한 자세한 내용은 [GitHub 패키지에 대한 사용 권한 정보](/ko/packages/learn-github-packages/about-permissions-for-github-packages#about-scopes-and-permissions-for-package-registries)를 참조하세요. GitHub Packages 워크플로 내에서 GitHub Actions 레지스트리에 인증하려면 다음을 사용할 수 있습니다. * 워크플로 리포지토리와 연결된 패키지를 게시하려면 `GITHUB_TOKEN`을 사용합니다. * 다른 프라이빗 리포지토리와 연결된 패키지를 설치하기 위한 최소한 `read:packages` 범위가 있는 personal access token (classic)(리포지토리에 패키지에 대한 읽기 액세스 권한이 부여된 경우 `GITHUB_TOKEN`을 사용할 수 있습니다. [패키지의 액세스 제어 및 표시 여부 구성](/ko/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility)을(를) 참조하세요). ### GitHub Actions 워크플로에서 인증하기 이 레지스트리는 세분화된 권한을 지원합니다. 세분화된 권한을 지원하는 레지스트리의 경우, 레지스트리에 인증하기 위해 GitHub Actions를 사용하는 personal access token 워크플로가 있다면 워크플로를 업데이트하여 `GITHUB_TOKEN`를 사용하도록 강력히 권장합니다. 레지스트리를 사용하여 인증하는 워크플로를 업데이트하는 방법에 대한 지침은 personal access token을 [](/ko/packages/managing-github-packages-using-github-actions-workflows/publishing-and-installing-a-package-with-github-actions#upgrading-a-workflow-that-accesses-a-registry-using-a-personal-access-token)참조하세요. > \[!NOTE] > GitHub Actions 워크플로에서 REST API를 사용하여 패키지를 삭제하고 복원하는 기능은 현재 공개 미리 보기 버전이며 변경될 수 있습니다. 토큰에 패키지에 대한 `GITHUB_TOKEN` 권한이 있는 경우, GitHub Actions 워크플로에서 `admin`를 사용해 REST API로 패키지를 삭제하거나 복원할 수 있습니다. 워크플로를 사용하여 패키지를 게시하는 리포지토리와 패키지에 명시적으로 연결한 리포지토리에는 리포지토리의 패키지에 대한 `admin` 권한이 자동으로 부여됩니다. `GITHUB_TOKEN`에 대한 자세한 내용은 [워크플로에서 인증에 GITHUB\_TOKEN 사용](/ko/actions/tutorials/authenticate-with-github_token#using-the-github_token-in-a-workflow)을(를) 참조하세요. 작업에서 레지스트리를 사용하는 모범 사례에 대한 자세한 내용은 [손상된 러너](/ko/actions/concepts/security/compromised-runners#cross-repository-access)를 참조하세요. 다음 명령을 사용하여 리포지토리의 nuget.config 파일에 GitHub Packages를 하드코딩하는 것 대신 GitHub Actions 워크플로에서 `GITHUB_TOKEN`를 사용해 personal access token에 인증합니다. ```shell dotnet nuget add source --username USERNAME --password ${{ secrets.GITHUB_TOKEN }} --store-password-in-clear-text --name github "https://nuget.pkg.github.com/NAMESPACE/index.json" ``` `NAMESPACE`을(를) 패키지 범위가 지정된 개인 계정 또는 조직 의 이름으로 바꾸세요. 이 계정 또는 조직은 패키지가 호스팅된 리포지토리. `USERNAME`을(를) 인증된 소스에 연결할 때 사용할 사용자 이름으로 바꿉니다. 패키지에 대한 액세스 권한을 독립적으로GitHub Codespaces 부여하도록 선택할 수도 있습니다GitHub Actions. 자세한 내용은 [패키지의 액세스 제어 및 표시 여부 구성](/ko/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#ensuring-github-codespaces-access-to-your-package) 및 [패키지의 액세스 제어 및 표시 여부 구성](/ko/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#ensuring-workflow-access-to-your-package)을(를) 참조하세요. ### personal access token를 사용하여 인증하기 > \[!NOTE] > GitHub Packages 은 .를 사용하는 personal access token (classic)인증만 지원합니다. 자세한 내용은 [개인용 액세스 토큰 관리](/ko/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens)을(를) 참조하세요. 프라이빗, 내부, 퍼블릭 패키지를 게시, 설치, 삭제하려면 액세스 토큰이 필요합니다. personal access token (classic)을 사용하여 GitHub Packages 또는 GitHub API에 인증할 수 있습니다. personal access token (classic)을(를) 만들 때 필요에 따라 토큰의 범위를 다르게 할당할 수 있습니다. personal access token (classic)의 패키지 관련 범위에 대한 자세한 내용은 [GitHub 패키지에 대한 사용 권한 정보](/ko/packages/learn-github-packages/about-permissions-for-github-packages#about-scopes-and-permissions-for-package-registries)를 참조하세요. GitHub Packages 워크플로 내에서 GitHub Actions 레지스트리에 인증하려면 다음을 사용할 수 있습니다. * 워크플로 리포지토리와 연결된 패키지를 게시하려면 `GITHUB_TOKEN`을 사용합니다. * 다른 프라이빗 리포지토리와 연결된 패키지를 설치하기 위한 최소한 `read:packages` 범위가 있는 personal access token (classic)(리포지토리에 패키지에 대한 읽기 액세스 권한이 부여된 경우 `GITHUB_TOKEN`을 사용할 수 있습니다. [패키지의 액세스 제어 및 표시 여부 구성](/ko/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility)을(를) 참조하세요). 적절한 범위의personal access token (classic)으로 GitHub Packages에서 패키지를 게시하고 설치해야 합니다. 자세한 내용은 [GitHub 패키지 소개](/ko/packages/learn-github-packages/introduction-to-github-packages#authenticating-to-github-packages)을(를) 참조하세요. GitHub Packages 명령줄 인터페이스(CLI)를 사용하여 `dotnet`에 인증하려면, 프로젝트 디렉터리에 \_\_ CLI 클라이언트의 GitHub Packages 아래에 `packageSources`를 소스로 지정하는 `dotnet` 파일을 생성합니다. 다음과 같이 반드시 교체하십시오. * `USERNAME` 에 개인 계정의 이름을 입력합니다 GitHub. * `TOKEN`와 personal access token (classic). * `NAMESPACE`패키지가 속한 범위의 개인 계정 또는 조직으로, 패키지가 호스팅된 리포지토리를 소유한입니다. ```xml ``` ## 패키지 게시 > \[!NOTE] > NuGet 패키지 버전의 `nupkg` 보관 파일 크기는 2.147GB보다 작아야 합니다. GitHub Packages에 패키지를 게시하려면 *nuget.config* 파일로 인증하거나, `--api-key`GitHub와 함께 personal access token (classic) 명령줄 옵션을 사용하거나, `dotnet` 명령줄 인터페이스(CLI)를 사용해 명령줄에서 직접 실행할 수 있는 명령을 사용할 수 있습니다. `OWNER`를 사용자 이름 또는 회사 이름으로 바꾸고, `YOUR_GITHUB_PAT`를 personal access token(으)로 바꾸세요. ```shell dotnet nuget add source --username OWNER --password YOUR_GITHUB_PAT --store-password-in-clear-text --name github "https://nuget.pkg.github.com/OWNER/index.json" ``` NuGet 레지스트리는 조직 또는 개인 계정 내에 패키지를 저장하며 패키지를 리포지토리와 연결할 수 있게 합니다. 리포지토리에서 사용 권한을 상속할지 또는 리포지토리와 독립적으로 세분화된 권한을 설정할지 선택할 수 있습니다. 패키지를 처음 게시할 때 기본 표시 여부는 프라이빗입니다. 표시 유형 또는 액세스 권한을 변경하려면 [패키지의 액세스 제어 및 표시 여부 구성](/ko/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility)을(를) 참조하세요. 게시된 패키지를 리포지토리와 연결하는 방법에 대한 자세한 내용은 [리포지토리를 패키지에 연결](/ko/packages/learn-github-packages/connecting-a-repository-to-a-package)을 참조하세요. project `RepositoryURL` 파일에 \_\_ 지정하면 게시된 패키지가 지정된 리포지토리에 자동으로 연결됩니다. 자세한 내용은 [NuGet 레지스트리 작업](/ko/packages/working-with-a-github-packages-registry/working-with-the-nuget-registry#publishing-a-package-using-a-nugetconfig-file) 참조하세요. 이미 게시된 패키지를 리포지토리에 연결하는 방법에 대한 자세한 내용은 [리포지토리를 패키지에 연결](/ko/packages/learn-github-packages/connecting-a-repository-to-a-package) 참조하세요. ### GitHub personal access token 사용하여 패키지를 API 키로 게시 personal access token에서 계정에 사용할 GitHub가 아직 없는 경우 [개인용 액세스 토큰 관리](/ko/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens)을 참조하세요. 1. 새 project 만듭니다. `PROJECT_NAME`을 프로젝트에 지정하고자 하는 이름으로 바꾸십시오. ```shell dotnet new console --name PROJECT_NAME ``` 2. 프로젝트를 패키징합니다. ```shell dotnet pack --configuration Release ``` 3. personal access token를 API 키로 사용하여 패키지를 게시하세요. `PROJECT_NAME`를 프로젝트 이름으로, `1.0.0`를 패키지 버전 번호로, `YOUR_GITHUB_PAT`를 사용자의 personal access token(으)로 바꾸세요. ```shell dotnet nuget push "bin/Release/PROJECT_NAME.1.0.0.nupkg" --api-key YOUR_GITHUB_PAT --source "github" ``` 패키지를 게시한 후 GitHub에서 패키지를 볼 수 있습니다. 자세한 내용은 [패키지 보기](/ko/packages/learn-github-packages/viewing-packages)을(를) 참조하세요. ### *nuget.config* 파일을 사용하여 패키지 게시 게시할 때 패키지를 리포지 `OWNER` 토리에 연결하는 경우 *.csproj* 파일에 지정된 리포지토리가 `NAMESPACE` 인증 파일에서 사용하는 리포지토리와 일치 \_\_ 해야 합니다. *.csproj* 파일에 버전 번호를 지정하거나 증분한 다음 `dotnet pack` 명령을 사용하여 해당 버전에 맞는 *.nuspec* 파일을 만듭니다. 패키지를 만드는 방법에 대한 자세한 내용은 Microsoft 설명서의 [패키지 만들기 및 게시](https://docs.microsoft.com/nuget/quickstart/create-and-publish-a-package-using-the-dotnet-cli)를 참조하세요. > \[!NOTE] > 리포지토리에 연결된 패키지를 게시하는 경우, 패키지는 자동으로 연결된 리포지토리의 액세스 권한을 상속받고, 조직에서 액세스 권한의 자동 상속을 사용하지 않도록 설정하지 않은 한 연결된 리포지토리의 GitHub Actions 워크플로에 패키지에 대한 액세스 권한이 자동으로 부여됩니다. 자세한 내용은 [패키지의 액세스 제어 및 표시 여부 구성](/ko/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#about-inheritance-of-access-permissions)을(를) 참조하세요. 1. GitHub Packages에 인증합니다. 자세한 내용은 [GitHub Packages에 인증](#authenticating-to-github-packages)을 참조하세요. 2. 새 project 만듭니다. `PROJECT_NAME`을 프로젝트에 지정하고자 하는 이름으로 바꾸십시오. ```shell dotnet new console --name PROJECT_NAME ``` 3. 프로젝트의 특정 정보를 프로젝트 파일에 추가하는데, 파일은 \_.csproj\_로 끝납니다. 반드시 다음과 같이 교체하십시오. * `1.0.0`을 패키지의 버전 번호로 바꿉니다. * `OWNER`패키지를 연결하려는 리포지토리를 소유하는 개인 계정 또는 조직의 이름으로 패키지를 게시합니다. * `REPOSITORY` 패키지를 연결하려는 리포지토리의 이름을 사용합니다. ```xml Exe netcoreapp3.0 PROJECT_NAME 1.0.0 AUTHORS COMPANY_NAME PACKAGE_DESCRIPTION https://github.com/OWNER/REPOSITORY ``` 4. 프로젝트를 패키징합니다. ```shell dotnet pack --configuration Release ``` 5. `key`를 사용해 *nuget.config* 파일에 지정한 패키지를 게시합니다. `PROJECT_NAME` project 이름으로 바꾸고 `1.0.0` 패키지의 버전 번호로 바꿉다. ```shell dotnet nuget push "bin/Release/PROJECT_NAME.1.0.0.nupkg" --source "github" ``` 패키지를 게시한 후 GitHub에서 패키지를 볼 수 있습니다. 자세한 내용은 [패키지 보기](/ko/packages/learn-github-packages/viewing-packages)을(를) 참조하세요. ## 동일한 리포지토리에 여러 패키지 게시 여러 패키지를 동일한 리포지토리에 연결하려면 모든 GitHub 프로젝트 파일의 `RepositoryURL` 필드에 동일한 \_\_ 리포지토리 URL을 사용합니다. GitHub 는 해당 필드를 기반으로 리포지토리와 일치합니다. 다음 예시에서는 MY\_APP 및 MY\_OTHER\_APP 프로젝트를 동일한 리포지토리에 게시합니다. ```xml Exe netcoreapp3.0 MY_APP 1.0.0 Octocat GitHub This package adds a singing Octocat! https://github.com/my-org/my-repo ``` ```xml Exe netcoreapp3.0 MY_OTHER_APP 1.0.0 Octocat GitHub This package adds a dancing Octocat! https://github.com/my-org/my-repo ``` ## 패키지 설치 프로젝트에서 패키지를 GitHub 사용하는 것은 *nuget.org* 패키지를 사용하는 것과 비슷합니다. 패키지 이름 및 버전을 지정하여 *.csproj* 파일에 패키지 종속성을 추가합니다. project *.csproj* 파일을 사용하는 방법에 대한 자세한 내용은 Microsoft 설명서의 [ NuGet 패키지 작업](https://docs.microsoft.com/nuget/consume-packages/overview-and-workflow)을 참조하세요. 1. GitHub Packages에 인증합니다. 자세한 내용은 [GitHub Packages에 인증](#authenticating-to-github-packages)을 참조하세요. 2. 패키지를 사용하려면 `ItemGroup`을 추가하고, `PackageReference` 프로젝트 파일에서 \_\_ 필드를 구성합니다. `PACKAGE_NAME`의 `Include="PACKAGE_NAME"` 값을 패키지 종속성으로 바꾸고 `X.X.X`의 `Version="X.X.X"` 값을 사용하려는 패키지의 버전으로 바꿉니다. ```xml Exe netcoreapp3.0 My-app 1.0.0 Octocat GitHub This package adds an Octocat! https://github.com/OWNER/REPOSITORY ``` 3. `restore` 명령으로 패키지를 설치합니다. ```shell dotnet restore ``` ## 문제 해결 `GITHUB_TOKEN` 워크플로 내에서 GitHub Packages를 사용해 GitHub Actions 레지스트리에 인증하는 경우, 해당 토큰은 워크플로가 실행 중인 리포지토리가 아닌 다른 리포지토리의 비공개 리포지토리 기반 패키지에 액세스할 수 없습니다. 다른 리포지토리와 연결된 패키지에 액세스하려면 대신 범위를 사용하여 personal access token (classic)`read:packages` 생성하고 이 토큰을 비밀로 전달합니다. ### 공용 패키지를 복원할 때 일시적인 403 오류 GitHub Packages를 \_nuget.org\_와 함께 사용하면서 일반적인 공개 패키지(예: `Microsoft.Extensions.*`)를 복원할 때 간헐적으로 403 Forbidden 오류가 발생하는 경우, 이는 NuGet이 각 패키지에 대해 구성된 모든 패키지 원본을 쿼리하기 때문에 발생할 수 있습니다. 인증이 일시적으로 실패하면 GitHub Packages 존재하지 않는 GitHub Packages패키지에 대해서도 전체 복원을 차단할 수 있습니다. 이를 방지하려면 [NuGet 패키지 원본 매핑](https://learn.microsoft.com/nuget/consume-packages/package-source-mapping) 을 사용하여 패키지를 특정 원본으로 라우팅합니다. 교체: * `NAMESPACE` GitHub Packages NuGet 피드를 소유한 개인 계정 또는 조직의 이름으로 * `PACKAGE-ID-PREFIX`에 호스팅된 패키지에 사용하는 NuGet 패키지 ID 접두사인 GitHub Packages. 여러 접두사를 사용하는 경우 각 접두사에 대한 추가 `` 항목을 추가합니다. ```xml ``` NuGet은 [가장 구체적으로 일치하는 패턴](https://learn.microsoft.com/nuget/consume-packages/package-source-mapping#package-pattern-precedence)을 사용하므로 `PACKAGE-ID-PREFIX.*`에 일치하는 패키지는 GitHub Packages에서만 가져오고, 그 밖의 모든 패키지는 \_nuget.org\_에서 가져옵니다. 또한 프라이빗 패키지가 사용자의 GitHub Packages 피드에서만 오도록 보장하여 종속성 혼동 공격을 방지하는 데도 도움이 됩니다. ## 추가 참고 자료 * [패키지 삭제 및 복원](/ko/packages/learn-github-packages/deleting-and-restoring-a-package)