

Amazon CodeCatalyst는 더 이상 신규 고객에게 공개되지 않습니다. 기존 고객은 정상적으로 서비스를 계속 이용할 수 있습니다. 자세한 내용은 [CodeCatalyst에서 마이그레이션하는 방법](migration.md) 단원을 참조하십시오.

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# CodeCatalyst에서 소프트웨어 패키지 게시 및 공유
<a name="packages"></a>

Amazon CodeCatalyst는 완전관리형 패키지 리포지토리 서비스를 포함하며, 이 서비스를 사용하면 개발 팀은 애플리케이션 개발에 사용되는 소프트웨어 패키지를 안전하게 저장하고 공유할 수 있습니다. 이러한 패키지는 패키지 리포지토리에 저장되며, 이 리포지토리는 CodeCatalyst의 프로젝트 내에서 생성되고 구성됩니다.

단일 패키지 리포지토리는 지원되는 모든 패키지 유형의 패키지를 저장할 수 있습니다. CodeCatalyst는 다음 패키지 형식을 지원합니다.
+ npm
+ Maven
+ NuGet
+ Python

패키지 리포지토리의 패키지는 리포지토리가 포함된 프로젝트 멤버 간에 검색하고 공유할 수 있습니다.

리포지토리에서 패키지를 게시하고 사용하려면 리포지토리 엔드포인트(URL)를 사용하도록 패키지 관리자를 구성합니다. 그런 다음 패키지 관리자를 사용하여 패키지를 리포지토리에 게시할 수 있습니다. Maven, Gradle, npm, yarn, nuget, dotnet, pip, twine와 같은 패키지 관리자를 사용할 수 있습니다.

CodeCatalyst 패키지 리포지토리를 사용하도록 CodeCatalyst 워크플로를 구성할 수도 있습니다. 워크플로에서 패키지를 사용하는 방법에 대한 자세한 내용은 [워크플로에 패키지 리포지토리 연결](workflows-packages.md) 섹션을 참조하세요.

업스트림 리포지토리로 추가하여 한 패키지 리포지토리의 패키지를 동일한 프로젝트의 다른 리포지토리에서 사용할 수 있도록 할 수 있습니다. 업스트림 리포지토리에서 사용할 수 있는 모든 패키지 버전을 다운스트림 리포지토리에서도 사용할 수 있습니다. 자세한 내용은 [업스트림 리포지토리 구성 및 사용](packages-upstream-repositories.md) 단원을 참조하십시오.

**게이트웨이**라는 특수 유형의 리포지토리를 생성하여 CodeCatalyst 리포지토리에서 오픈 소스 패키지를 사용할 수 있도록 할 수 있습니다. 게이트웨이 리포지토리로 업스트리밍하면 npmjs.com 및 pypi.org 같이 널리 사용되는 퍼블릭 리포지토리의 패키지를 사용하고 CodeCatalyst 리포지토리에 해당 패키지를 자동으로 캐싱할 수 있습니다. 자세한 내용은 [퍼블릭 외부 리포지토리에 연결](packages-connect-external.md) 단원을 참조하십시오.

**Topics**
+ [패키지 개념](packages-concepts.md)
+ [패키지 리포지토리 구성 및 사용](packages-repositories.md)
+ [업스트림 리포지토리 구성 및 사용](packages-upstream-repositories.md)
+ [퍼블릭 외부 리포지토리에 연결](packages-connect-external.md)
+ [패키지 게시 및 수정](working-with-packages.md)
+ [npm 사용](packages-npm.md)
+ [Maven 사용](packages-maven.md)
+ [NuGet 사용](packages-nuget.md)
+ [Python 사용](packages-python.md)
+ [패키지 할당량](packages-quotas.md)

# 패키지 개념
<a name="packages-concepts"></a>

다음은 CodeCatalyst에서 패키지를 관리, 게시 또는 사용할 때 알아야 할 몇 가지 개념 및 용어입니다.

## Packages
<a name="packages-concepts-packages"></a>

*패키지*는 소프트웨어와 모든 종속성을 해결하고 소프트웨어를 설치하는 데 필요한 메타데이터를 포함한 번들입니다. CodeCatalyst는 npm 패키지 형식을 지원합니다.

패키지는 다음으로 구성됩니다.
+ 이름(예: `webpack`는 널리 사용되는 npm 패키지의 이름)
+ 선택적 [네임스페이스](#packages-concepts-package-namespaces)(예: `@types/node`의 `@types`)
+ [버전](#packages-concepts-package-versions) 세트(예: `1.0.0`, `1.0.1`, `1.0.2`)
+ 패키지 수준 메타데이터(예: npm dist 태그)

## 패키지 네임스페이스
<a name="packages-concepts-package-namespaces"></a>

일부 패키지 형식은 계층적 패키지 이름을 지원하여 패키지를 논리적 그룹으로 구성할 수 있고 이름 충돌을 방지하는 데 도움이 됩니다. 이름이 같은 패키지는 다른 네임스페이스에 저장할 수 있습니다. 예를 들어 npm은 범위를 지원하며 npm 패키지 `@types/node`는 `@types`의 범위 및 `node`의 이름을 지닙니다. `@types` 범위에는 다른 패키지 이름이 많습니다. CodeCatalyst에서 범위('유형')는 패키지 네임스페이스라고 하고 이름('노드')은 패키지 이름이라고 합니다. Maven 패키지의 경우 패키지 네임스페이스는 Maven groupID에 해당합니다. `org.apache.logging.log4j:log4j` Maven 패키지에는 `org.apache.logging.log4j` groupID(패키지 네임스페이스)와 `log4j` artifactID(패키지 이름)가 있습니다. Python와 같은 일부 패키지 형식은 npm 범위 또는 Maven groupID와 유사한 개념의 계층적 이름을 지원하지 않습니다. 패키지 이름을 그룹화하는 방법이 없으면 이름 충돌을 피하기가 더 어려울 수 있습니다.

## 패키지 버전
<a name="packages-concepts-package-versions"></a>

**패키지 버전은 패키지의 특정 버전(예: `@types/node@12.6.9`)을 식별합니다. 버전 번호 형식과 의미 체계는 패키지 형식에 따라 다릅니다. 예를 들어, npm 패키지 버전은 [의미 체계 버전 관리 사양](https://semver.org/)을 준수해야 합니다. CodeCatalyst 패키지 버전은 버전 식별자, 패키지 버전 수준 메타데이터 및 자산 세트로 구성됩니다.

## 자산
<a name="packages-concepts-assets"></a>

*자산*은 패키지 버전(예: npm `.tgz` 파일, Maven POM 및 JAR 파일)과 관련된 CodeCatalyst에 저장된 개별 파일입니다.

## 패키지 리포지토리
<a name="packages-concepts-repository"></a>

CodeCatalyst *패키지 리포지토리*에는 [패키지](#packages-concepts-packages) 세트가 포함되어 있으며, 이 세트에 포함된 각 [패키지 버전](#packages-concepts-package-versions)은 [자산](#packages-concepts-assets) 세트에 매핑됩니다. 패키지 리포지토리는 다국어 개체이며, 따라서 지원되는 모든 유형의 패키지가 단일 리포지토리에 포함될 수 있습니다. 각 패키지 리포지토리는 NuGet CLIs(`nuget`, `dotnet`), `npm` CLI, Maven CLI(`mvn`) 및 Python CLI(`pip` 및 `twine`)와 같은 도구를 사용하여 패키지를 가져오고 게시하기 위한 엔드포인트를 노출합니다. 각 스페이스에서 생성할 수 있는 패키지 리포지토리 수를 포함하여 CodeCatalyst 패키지 할당량에 대한 자세한 내용은 [패키지 할당량](packages-quotas.md) 섹션을 참조하세요.

패키지 리포지토리를 업스트림으로 설정하여 다른 패키지 리포지토리에 연결할 수 있습니다. 리포지토리가 업스트림으로 설정된 경우 업스트림의 모든 패키지와 체인의 추가 업스트림 리포지토리를 사용할 수 있습니다. 자세한 내용은 [업스트림 리포지토리](#packages-concepts-upstream-repositories) 단원을 참조하십시오.

게이트웨이 리포지토리는 공식 외부 패키지 권한에서 패키지를 가져와 저장하는 특별한 유형의 패키지 리포지토리입니다. 자세한 내용은 [게이트웨이 리포지토리](#packages-concepts-gateway-repositories) 단원을 참조하십시오.

## 업스트림 리포지토리
<a name="packages-concepts-upstream-repositories"></a>

CodeCatalyst를 사용하여 두 패키지 리포지토리 간에 업스트림 관계를 만들 수 있습니다. 다운스트림 리포지토리의 패키지 리포지토리 엔드포인트에서 패키지 리포지토리의 패키지 버전에 액세스할 수 있는 경우 해당 패키지 리포지토리는 다른 패키지 리포지토리의 *업스트림*입니다. 업스트림 관계를 사용하면 두 패키지 리포지토리의 내용이 클라이언트의 관점에서 효과적으로 병합됩니다.

예를 들어 패키지 관리자가 리포지토리에 없는 패키지 버전을 요청하는 경우 CodeCatalyst는 패키지 버전에 대해 구성된 업스트림 리포지토리를 검색합니다. 업스트림 리포지토리는 구성된 순서대로 검색되며 패키지가 발견되면 CodeCatalyst가 검색을 중지합니다.

## 게이트웨이 리포지토리
<a name="packages-concepts-gateway-repositories"></a>

*게이트웨이 리포지토리*는 지원되는 외부 공식 패키지 권한에 연결되는 특수한 유형의 패키지 리포지토리입니다. 게이트웨이 리포지토리를 [업스트림 리포지토리](#packages-concepts-upstream-repositories)로 추가할 때 해당 공식 패키지 권한의 패키지를 사용할 수 있습니다. 다운스트림 리포지토리는 퍼블릭 리포지토리와 통신하지 않으며, 대신 모든 것이 게이트웨이 리포지토리가 중재합니다. 이러한 방식으로 사용되는 패키지는 게이트웨이 리포지토리와 원래 요청을 받은 다운스트림 리포지토리 모두에 저장됩니다.

게이트웨이 리포지토리는 사전 정의되어 있지만 사용할 각 프로젝트에서 생성해야 합니다. 다음 목록에는 CodeCatalyst에서 생성할 수 있는 모든 게이트웨이 리포지토리와 게이트웨이 리포지토리가 연결된 패키지 권한이 포함되어 있습니다.
+ **npm-public-registry-gateway**는 npmjs.com에서 npm 패키지를 제공합니다.
+ **maven-central-gateway**는 Maven Central 리포지토리에서 Maven 패키지를 제공합니다.
+ **google-android-gateway**는 Google Android에서 Maven 패키지를 제공합니다.
+ **commonsware-gateway**는 CommonsWare에서 Maven 패키지를 제공합니다.
+ **gradle-plugins-gateway**는 Gradle Plugins에서 Maven 패키지를 제공합니다.
+ **nuget-gallery-gateway**는 NuGet Gallery에서 NuGet 패키지를 제공합니다.
+ **pypi-gateway**는 Python Package Index에서 Python 패키지를 제공합니다.

# 패키지 리포지토리 구성 및 사용
<a name="packages-repositories"></a>

CodeCatalyst에서 패키지는 패키지 리포지토리 내에 저장되고 관리됩니다. 패키지를 CodeCatalyst에 게시하거나 CodeCatalyst(또는 지원되는 모든 퍼블릭 패키지 리포지토리)의 패키지를 사용하려면 패키지 리포지토리를 생성하고 패키지 관리자를 연결해야 합니다.

**Topics**
+ [패키지 리포지토리 생성](packages-repositories-create.md)
+ [패키지 리포지토리에 연결](packages-repositories-connect.md)
+ [패키지 리포지토리 삭제](packages-repositories-delete.md)

# 패키지 리포지토리 생성
<a name="packages-repositories-create"></a>

CodeCatalyst에서 패키지 리포지토리를 생성하려면 다음 단계를 수행합니다.

**패키지 리포지토리를 생성하려면**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.

1. 패키지 리포지토리를 생성하려는 프로젝트로 이동합니다.

1. 탐색 창에서 **패키지**를 선택합니다.

1. **패키지 리포지토리** 페이지에서 **패키지 리포지토리 생성**을 선택합니다.

1. **패키지 리포지토리 세부 정보** 섹션에서 다음을 추가합니다.

   1. **리포지토리 이름**. 프로젝트 또는 팀 이름 또는 리포지토리 사용 방식과 같은 세부 정보와 함께 설명 이름을 사용하는 것이 좋습니다.

   1. (선택 사항) **설명**. 리포지토리 설명은 프로젝트의 여러 팀에 여러 리포지토리가 있는 경우 특히 유용합니다.

1. **업스트림 리포지토리** 섹션에서 **업스트림 리포지토리 선택**을 선택하여 CodeCatalyst 패키지 리포지토리를 통해 액세스하려는 패키지 리포지토리를 추가합니다. **게이트웨이 리포지토리**를 추가하여 외부 패키지 리포지토리 또는 기타 **CodeCatalyst 리포지토리**에 연결할 수 있습니다.

   1. 패키지 리포지토리에서 패키지를 요청하면 업스트림 리포지토리가 이 목록에 표시된 순서대로 검색됩니다. 패키지가 발견되면 CodeCatalyst는 검색을 중지합니다. 업스트림 리포지토리의 순서를 변경하려면 목록에서 리포지토리를 끌어다 놓을 수 있습니다.

1. **생성**을 선택하여 패키지 리포지토리를 생성합니다.

# 패키지 리포지토리에 연결
<a name="packages-repositories-connect"></a>

CodeCatalyst에서 패키지를 게시하거나 사용하려면 패키지 리포지토리 엔드포인트 정보 및 CodeCatalyst 자격 증명 정보로 패키지 관리자를 구성해야 합니다. 리포지토리를 생성하지 않은 경우 [패키지 리포지토리 생성](packages-repositories-create.md)의 지침에 따라 리포지토리를 생성할 수 있습니다.

패키지 관리자를 CodeCatalyst 패키지 리포지토리에 연결하는 방법에 대한 지침은 다음 설명서를 참조하세요.
+ [Gradle Groovy 구성 및 사용](packages-maven-gradle.md)
+ [mvn 구성 및 사용](packages-maven-mvn.md)
+ [nuget 또는 dotnet CLI 구성 및 사용](packages-nuget-cli.md)
+ [npm 구성 및 사용](packages-npm-use.md)
+ [pip 구성 및 Python 패키지 설치](packages-python-pip.md)
+ [Twine 구성 및 Python 패키지 게시](packages-python-twine.md)

# 패키지 리포지토리 삭제
<a name="packages-repositories-delete"></a>

CodeCatalyst에서 패키지 리포지토리를 삭제하려면 다음 단계를 수행합니다.

**패키지 리포지토리를 삭제하려면**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.

1. 삭제하려는 패키지 리포지토리가 포함된 프로젝트로 이동합니다.

1. 탐색 창에서 **패키지**를 선택합니다.

1. **패키지 리포지토리** 페이지에서 삭제할 리포지토리를 선택합니다.

1. **삭제**를 선택합니다.

1. 패키지 리포지토리 삭제의 영향에 대해 제공된 정보를 검토합니다.

1. 입력 필드에 `delete`를 입력한 다음 **삭제**를 선택합니다.

# 업스트림 리포지토리 구성 및 사용
<a name="packages-upstream-repositories"></a>

게이트웨이 리포지토리와 기타 CodeCatalyst 패키지 리포지토리를 모두 패키지 리포지토리의 업스트림으로 연결할 수 있습니다. 이를 통해 패키지 관리자 클라이언트는 단일 패키지 리포지토리 엔드포인트를 사용하여 둘 이상의 패키지 리포지토리에 포함된 패키지에 액세스할 수 있습니다. 다음은 업스트림 리포지토리 사용의 주요 이점입니다.
+ 여러 소스에서 가져오고자 한다면 패키지 관리자를 단일 리포지토리 엔드포인트로 구성하기만 하면 됩니다.
+ 업스트림 리포지토리에서 사용되는 패키지는 다운스트림 리포지토리에 저장되므로 업스트림 리포지토리에서 예기치 않은 중단이 발생하거나 패키지가 삭제되더라도 패키지를 사용할 수 있습니다.

패키지 리포지토리를 생성할 때 업스트림 리포지토리를 추가할 수 있습니다. CodeCatalyst 콘솔의 기존 패키지 리포지토리에서 업스트림 리포지토리를 추가하거나 제거할 수도 있습니다.

게이트웨이 리포지토리를 업스트림 리포지토리로 추가하면, 패키지 리포지토리가 게이트웨이 리포지토리의 해당 퍼블릭 패키지 리포지토리에 연결됩니다. 지원되는 퍼블릭 패키지 리포지토리 목록은 [지원되는 외부 패키지 리포지토리 및 해당 리포지토리의 게이트웨이 리포지토리](packages-connect-external.md#packages-upstream-repositories-supported-external)를 참조하세요.

여러 리포지토리를 업스트림 리포지토리로 함께 연결할 수 있습니다. 예를 들어 팀이 `project-repo`라는 리포지토리를 생성하는데, 퍼블릭 npm 리포지토리인 `npmjs.com`에 연결되어 업스트림 리포지토리로 추가된 **npm-public-registry-gateway**가 있는 `team-repo`라는 다른 리포지토리를 이미 사용하고 있다고 가정해 보겠습니다. `team-repo`을 업스트림 리포지토리로 `project-repo`에 추가할 수 있습니다. 이 경우 `project-repo`, `team-repo`, `npm-public-registry-gateway` 및 `npmjs.com`에서 패키지를 가져오는데 `project-repo`를 사용하도록 패키지 관리자만 구성하면 됩니다.

**Topics**
+ [업스트림 리포지토리 추가](packages-upstream-repositories-add.md)
+ [업스트림 리포지토리의 검색 순서 편집](packages-upstream-repositories-search-order.md)
+ [업스트림 리포지토리가 포함된 패키지 버전 요청](packages-upstream-repositories-request.md)
+ [업스트림 리포지토리 제거](packages-upstream-repositories-remove.md)

# 업스트림 리포지토리 추가
<a name="packages-upstream-repositories-add"></a>

퍼블릭 패키지 리포지토리 또는 다른 CodeCatalyst 패키지 리포지토리를 다운스트림 리포지토리에 업스트림 리포지토리로 추가하면, 다운스트림 리포지토리에 연결된 패키지 관리자가 업스트림 리포지토리의 모든 패키지를 사용할 수 있습니다.

**업스트림 리포지토리를 추가하려면**

1. 탐색 창에서 **패키지**를 선택합니다.

1. **패키지 리포지토리** 페이지에서 업스트림 리포지토리를 추가할 패키지 리포지토리를 선택합니다.

1. 패키지 리포지토리 이름에서 **업스트림**을 선택하고 **업스트림 리포지토리 선택**을 선택합니다.

1. **업스트림 유형 선택**에서 다음 중 하나를 선택합니다.
   + **게이트웨이 리포지토리**

     사용 가능한 게이트웨이 리포지토리 목록에서 선택할 수 있습니다.
**참고**  
CodeCatalyst는 Maven Central, npmjs.com 또는 Nuget Gallery와 같은 퍼블릭 외부 패키지 권한에 연결하기 위해 게이트웨이 리포지토리를 외부 리포지토리에서 가져온 패키지를 검색하고 저장하는 중개 리포지토리로 사용합니다. 이렇게 하면 프로젝트의 모든 패키지 리포지토리가 게이트웨이 중개 리포지토리의 패키지를 사용하므로 시간과 데이터 전송이 절약됩니다. 자세한 내용은 [퍼블릭 외부 리포지토리에 연결](packages-connect-external.md) 단원을 참조하십시오.
   + **CodeCatalyst 리포지토리**

     프로젝트의 사용 가능한 CodeCatalyst 패키지 리포지토리 목록에서 선택할 수 있습니다.

1. 업스트림 리포지토리로 추가하려는 모든 리포지토리를 선택한 후 **선택**을 선택한 다음 **저장**을 선택합니다.

   업스트림 리포지토리의 검색 순서 변경에 대한 자세한 내용은 [업스트림 리포지토리의 검색 순서 편집](packages-upstream-repositories-search-order.md) 섹션을 참조하세요.

업스트림 리포지토리를 추가한 경우 로컬 리포지토리에 연결된 패키지 관리자를 사용하여 업스트림 리포지토리에서 패키지를 가져올 수 있습니다. 패키지 관리자 구성을 업데이트할 필요는 없습니다. 업스트림 리포지토리에서 패키지 버전을 요청하는 방법에 대한 자세한 내용은 [업스트림 리포지토리가 포함된 패키지 버전 요청](packages-upstream-repositories-request.md) 섹션을 참조하세요.

# 업스트림 리포지토리의 검색 순서 편집
<a name="packages-upstream-repositories-search-order"></a>

CodeCatalyst는 구성된 검색 순서로 업스트림 리포지토리를 검색합니다. 패키지가 발견되면 CodeCatalyst는 검색을 중지합니다. 패키지를 찾기 위해 업스트림 리포지토리를 검색하는 순서는 변경할 수 있습니다.

**업스트림 리포지토리의 검색 순서를 편집하려면**

1. 탐색 창에서 **패키지**를 선택합니다.

1. **패키지 리포지토리** 페이지에서 업스트림 리포지토리 검색 순서를 편집할 패키지 리포지토리를 선택합니다.

1. 패키지 리포지토리 이름에서 **업스트림**을 선택합니다.

1. **업스트림 리포지토리** 섹션에서 업스트림 리포지토리와 해당 검색 순서를 볼 수 있습니다. 검색 순서를 변경하려면 목록에 리포지토리를 끌어다 놓습니다.

1. 업스트림 리포지토리의 검색 순서 편집이 완료되면 **저장**을 선택합니다.

# 업스트림 리포지토리가 포함된 패키지 버전 요청
<a name="packages-upstream-repositories-request"></a>

다음 예시는 패키지 관리자가 업스트림 리포지토리가 있는 CodeCatalyst 패키지 리포지토리에서 패키지를 요청하는 경우 발생할 수 있는 시나리오를 보여줍니다.

이 예시에서는 `npm`과 같은 패키지 관리자가 여러 업스트림 리포지토리가 있는 `downstream`이라는 패키지 리포지토리에서 패키지 버전을 요청합니다. 패키지를 요청하면 다음이 발생할 수 있습니다.
+  요청된 패키지 버전이 `downstream`에 포함되어 있는 경우 클라이언트에 반환됩니다.
+  요청된 패키지 버전이 `downstream`에 포함되어 있지 않은 경우 CodeCatalyst는 `downstream` 업스트림 리포지토리에서 구성된 검색 순서에 따라 해당 버전을 찾습니다. 패키지 버전을 찾으면 해당 패키지에 대한 참조가 `downstream`에 복사되고 패키지 버전이 클라이언트에 반환됩니다.
+  `downstream` 및 해당 업스트림 리포지토리 모두에 패키지 버전이 포함되어 있지 않은 경우 HTTP 404 `Not Found` 응답이 클라이언트에 반환됩니다.

 하나의 리포지토리에 허용되는 최대 직접 업스트림 리포지토리 수는 10개입니다. 패키지 버전이 요청될 때 CodeCatalyst가 확인하는 최대 리포지토리 수는 25개입니다.

## 업스트림 리포지토리의 패키지 보존
<a name="package-retention-upstream-repos"></a>

요청된 패키지 버전이 업스트림 리포지토리에서 발견되면 해당 버전에 대한 참조가 유지되며 해당 버전의 요청을 받은 리포지토리에서 항상 사용할 수 있습니다. 이렇게 하면 업스트림 리포지토리가 예기치 않게 중단되는 경우에 패키지에 액세스할 수 있습니다. 유지되는 패키지 버전은 다음 사항에 영향을 받지 않습니다.
+  업스트림 리포지토리 삭제 
+  업스트림 리포지토리와 다운스트림 리포지토리 간 연결 해제 
+  업스트림 리포지토리에서 패키지 버전 삭제 
+  업스트림 리포지토리의 패키지 버전 편집(예: 새 자산 추가) 

## 업스트림 관계를 통해 패키지 가져오기
<a name="fetching-packages-through-an-upstream-relationship"></a>

CodeCatalyst는 업스트림 리포지토리라는 연결된 여러 리포지토리를 통해 패키지를 가져올 수 있습니다. CodeCatalyst 패키지 리포지토리에 게이트웨이 리포지토리에 대한 업스트림 연결이 있는 다른 CodeCatalyst 패키지 리포지토리에 대한 업스트림 연결이 있는 경우, 업스트림 리포지토리에 없는 패키지에 대한 요청은 외부 리포지토리에서 복사됩니다. 예를 들어, 다음과 같은 구성을 살펴보겠습니다. `repo-A`라는 리포지토리는 `npm-public-registry-gateway`라는 게이트웨이 리포지토리에 대한 업스트림 연결이 있습니다. `npm-public-registry-gateway`는 퍼블릭 패키지 리포지토리인 [https://npmjs.com](https://npmjs.com) 대한 업스트림 연결이 있습니다.

![\[세 개의 리포지토리가 서로 연결되어 있는 모습을 보여주는 간단한 업스트림 리포지토리 다이어그램\]](http://docs.aws.amazon.com/ko_kr/codecatalyst/latest/userguide/images/packages/upstream-with-external.png)


`npm`이 `repo-A` 리포지토리를 사용하도록 구성된 경우 `npm install`을 실행하면 [https://npmjs.com](https://npmjs.com)에서 `npm-public-registry-gateway`로 패키지 복사가 시작됩니다. 설치된 버전도 함께 `repo-A`로 가져옵니다. 다음 예시에서는 `lodash`를 설치합니다.

```
$ npm config get registry
https://packages.region.codecatalyst.aws/npm/space-name/proj-name/repo-name/
$ npm install lodash
+ lodash@4.17.20
added 1 package from 2 contributors in 6.933s
```

`npm install`을 실행한 후에는 `repo-A`에는 최신 버전(`lodash 4.17.20`)만 포함됩니다. 해당 버전이 `repo-A`에서 `npm`를 통해 가져온 버전이기 때문입니다.

 `npm-public-registry-gateway`에 [https://npmjs.com](https://npmjs.com)에 대한 외부 업스트림 연결이 있기 때문에 [https://npmjs.com](https://npmjs.com)에서 가져온 모든 패키지 버전이 `npm-public-registry-gateway`에 저장됩니다. 이러한 패키지 버전은 `npm-public-registry-gateway`로 업스트림 연결이 있는 모든 다운스트림 리포지토리에서 가져올 수 있었을 것입니다.

`npm-public-registry-gateway`의 내용은 시간이 지남에 따라 [https://npmjs.com](https://npmjs.com)에서 가져온 모든 패키지 및 패키지 버전을 볼 수 있는 방법을 제공합니다.

## 중간 리포지토리에 패키지 보존
<a name="package-retention-intermediate-repositories"></a>

 CodeCatalyst를 사용하면 업스트림 리포지토리를 연결할 수 있습니다. 예를 들어 `repo-B`는 `repo-A`의 업스트림 리포지토리가 되고 `repo-C`는 `repo-B`의 업스트림 리포지토리가 됩니다. 이 구성을 통해 `repo-A`에서 `repo-B` 및 `repo-C` 패키지 버전을 사용할 수 있습니다.

![\[세 개의 리포지토리가 서로 연결되어 있는 모습을 보여주는 간단한 업스트림 리포지토리 다이어그램\]](http://docs.aws.amazon.com/ko_kr/codecatalyst/latest/userguide/images/packages/upstream-chaining.png)


 패키지 관리자가 `repo-A` 리포지토리에 연결하고 `repo-C` 리포지토리에서 패키지 버전을 가져오면 해당 패키지 버전은 `repo-B` 리포지토리에 유지되지 않습니다. 이 예시에서는 패키지 버전은 최종 `repo-A` 다운스트림 리포지토리에만 유지됩니다. 중간 리포지토리에는 유지되지 않습니다. 더 긴 체인의 경우에도 마찬가지입니다. 예를 들어, 네 개의 리포지토리 `repo-A`, `repo-B`, `repo-C`, `repo-D` 및 패키지 관리자가 `repo-A`에 연결되어 있고 `repo-D`에서 패키지 버전을 가져온 경우, 해당 패키지 버전은 `repo-A`에는 유지되지만 `repo-B` 또는 `repo-C`에는 유지되지 않습니다.

패키지 보존 동작은 퍼블릭 패키지 리포지토리에서 패키지 버전을 가져올 때와 비슷합니다. 단, 패키지 버전이 퍼블릭 리포지토리에 대한 직접 업스트림 연결이 연결된 게이트웨이 리포지토리에 항상 유지된다는 점이 다릅니다. 예를 들어 `repo-B`는 `repo-A`의 업스트림 리포지토리로 사용됩니다. `npm-public-registry-gateway`는 `repo-B`의 업스트림 리포지토리로, 퍼블릭 리포지토리 **npmjs.com**에 대한 업스트림 연결이 연결됩니다. 아래 다이어그램을 참조하세요.

![\[npmjs.com에 대한 외부 업스트림 연결과 함께 연결된 세 개의 리포지토리를 보여주는 업스트림 리포지토리 다이어그램\]](http://docs.aws.amazon.com/ko_kr/codecatalyst/latest/userguide/images/packages/upstream-chaining-external.png)


 `repo-A`에 연결된 패키지 관리자가 특정 패키지 버전(예: *lodash 4.17.20*)을 요청했으나 해당 패키지 버전이 세 리포지토리 중 어디에도 없는 경우 **npmjs.com**에서 해당 패키지 버전을 가져옵니다. *lodash 4.17.20*을 가져오면 이는 최종 다운스트림 리포지토리인 `repo-A`와 퍼블릭 외부 리포지토리인 **npmjs.com**에 대한 업스트림 연결이 되어 있는 `npm-public-registry-gateway`에 유지됩니다. *lodash 4.17.20*은 중간 저장소인 `repo-B`에는 유지되지 않습니다.

# 업스트림 리포지토리 제거
<a name="packages-upstream-repositories-remove"></a>

업스트림 리포지토리 내의 패키지에 더 이상 액세스하지 않으려면 패키지 리포지토리에서 업스트림 리포지토리를 제거할 수 있습니다.

**주의**  
업스트림 리포지토리를 제거하면 업스트림 관계 체인이 중단되어 프로젝트 또는 빌드가 중단될 수 있습니다.

**업스트림 리포지토리를 제거하려면**

1. 탐색 창에서 **패키지**를 선택합니다.

1. **패키지 리포지토리** 페이지에서 업스트림 리포지토리를 제거할 패키지 리포지토리를 선택합니다.

1. 패키지 리포지토리 이름에서 **업스트림**을 선택합니다.

1. **업스트림 리포지토리 편집** 섹션에서 제거하려는 업스트림 리포지토리를 찾은 다음 ![\[Remove\]](http://docs.aws.amazon.com/ko_kr/codecatalyst/latest/userguide/images/packages/remove.png)를 선택합니다.

1. 업스트림 리포지토리 제거가 완료되면 **저장**을 선택합니다.

# 퍼블릭 외부 리포지토리에 연결
<a name="packages-connect-external"></a>

해당 게이트웨이 리포지토리를 업스트림 리포지토리로 추가하여, CodeCatalyst 패키지 리포지토리를 지원되는 퍼블릭 외부 리포지토리에 연결할 수 있습니다. 게이트웨이 리포지토리는 외부 리포지토리에서 가져온 패키지를 검색하고 저장하는 중간 리포지토리 역할을 합니다. 이렇게 하면 프로젝트의 모든 패키지 리포지토리가 게이트웨이 리포지토리의 저장된 패키지를 사용할 수 있으므로 시간과 데이터 전송이 절약됩니다.

**게이트웨이 리포지토리를 사용하여 퍼블릭 리포지토리에 연결하려면**

1. 탐색 창에서 **패키지**를 선택합니다.

1. **패키지**에서 **게이트웨이 리포지토리** 페이지를 선택합니다. 지원되는 게이트웨이 리포지토리 목록과 그 설명을 볼 수 있습니다.

1. 게이트웨이 리포지토리를 사용하려면 먼저 게이트웨이 리포지토리를 생성해야 합니다. 게이트웨이 리포지토리가 생성된 경우 생성된 날짜와 시간이 표시됩니다. 그렇지 않은 경우 **생성**을 선택하여 생성합니다.

1. 게이트웨이 리포지토리의 패키지를 사용하려면 CodeCatalyst 리포지토리에서 게이트웨이 리포지토리에 업스트림 연결을 설정해야 합니다. **패키지 리포지토리**를 선택하고 연결할 패키지 리포지토리를 선택합니다.

1. 퍼블릭 리포지토리에 연결하려면 **업스트림**을 선택하고 **업스트림 리포지토리 선택**을 선택합니다.

1. **게이트웨이 리포지토리**를 선택하고, 업스트림 리포지토리로 연결할 퍼블릭 리포지토리에 해당하는 게이트웨이 리포지토리를 선택합니다.

1. 업스트림 리포지토리로 추가하려는 게이트웨이 리포지토리를 모두 선택한 경우 **선택**을 선택합니다.

1. 업스트림 리포지토리 정렬이 완료되면 **저장**을 선택합니다.

업스트림 리포지토리에 대한 자세한 내용은 [업스트림 리포지토리 구성 및 사용](packages-upstream-repositories.md) 섹션을 참조하세요.

게이트웨이 리포지토리를 업스트림 리포지토리로 추가한 경우, 로컬 리포지토리에 연결된 패키지 관리자를 사용하여 해당 리포지토리에 해당하는 퍼블릭 외부 패키지 리포지토리에서 패키지를 가져올 수 있습니다. 패키지 관리자 구성을 업데이트할 필요는 없습니다. 이러한 방식으로 사용되는 패키지는 게이트웨이 리포지토리와 로컬 패키지 리포지토리 모두에 저장됩니다. 업스트림 리포지토리에서 패키지 버전을 요청하는 방법에 대한 자세한 내용은 [업스트림 리포지토리가 포함된 패키지 버전 요청](packages-upstream-repositories-request.md) 섹션을 참조하세요.

## 지원되는 외부 패키지 리포지토리 및 해당 리포지토리의 게이트웨이 리포지토리
<a name="packages-upstream-repositories-supported-external"></a>

CodeCatalyst는 게이트웨이 리포지토리가 있는 다음 공식 패키지 권한에 업스트림 연결을 추가하도록 지원합니다.


| 리포지토리 패키지 유형 | 설명 | 게이트웨이 리포지토리 이름 | 
| --- | --- | --- | 
| npm | npm 공용 레지스트리 | npm-public-registry-gateway | 
| Python | Python Package Index | pypi-gateway | 
| Maven | Maven Central | maven-central-gateway | 
| Maven | Google Android Repository | google-android-gateway | 
| Maven | CommonsWare | commonsware-gateway | 
| Maven | Gradle 플러그인 저장소 | gradle-plugins-gateway | 
| NuGet | NuGet Gallery | nuget-gallery-gateway | 

# 패키지 게시 및 수정
<a name="working-with-packages"></a>

CodeCatalyst의 *패키지*는 종속성을 해결하고 소프트웨어를 설치하는 데 필요한 소프트웨어 및 메타데이터 번들입니다. CodeCatalyst에서 지원되는 패키지 형식 목록은 [CodeCatalyst에서 소프트웨어 패키지 게시 및 공유](packages.md) 섹션을 참조하세요. 이 섹션에서는 패키지 게시, 보기, 삭제, 패키지 버전 상태 업데이트에 대한 정보를 제공합니다.

**Topics**
+ [CodeCatalyst 패키지 리포지토리에 패키지 게시](package-publishing.md)
+ [패키지 버전 세부 정보 보기](working-with-packages-view.md)
+ [패키지 버전 삭제](working-with-packages-delete.md)
+ [패키지 버전의 상태 업데이트](working-with-packages-update-version-status.md)
+ [패키지 원본 제어 편집](package-origin-controls.md)

# CodeCatalyst 패키지 리포지토리에 패키지 게시
<a name="package-publishing"></a>

 패키지 관리자 도구를 사용하여 지원되는 패키지 유형의 버전을 CodeCatalyst 패키지 리포지토리에 게시할 수 있습니다. 패키지 버전을 게시하는 단계는 다음과 같습니다.

**패키지 버전을 CodeCatalyst 패키지 리포지토리에 게시하려면**

1. 생성하지 않은 경우 [패키지 리포지토리를 생성합니다](packages-repositories-create.md).

1. 패키지 관리자를 패키지 리포지토리에 연결합니다. npm 패키지 관리자를 CodeCatalyst 패키지 리포지토리에 연결하는 방법에 대한 지침은 [npm 구성 및 사용](packages-npm-use.md) 섹션을 참조하세요.

1. 연결된 패키지 관리자를 사용하여 패키지 버전을 게시합니다.

**Contents**
+ [리포지토리 게시 및 업스트림](#package-publishing-upstreams)
+ [프라이빗 패키지 및 퍼블릭 리포지토리](#package-publishing-upstreams-direct)
+ [패키지 자산 덮어쓰기](#package-publishing-overwrite-assets)

## 리포지토리 게시 및 업스트림
<a name="package-publishing-upstreams"></a>

CodeCatalyst에서는 연결 가능한 업스트림 리포지토리 또는 퍼블릭 리포지토리에 있는 패키지 버전을 게시할 수 없습니다. 예를 들어 npm 패키지 `lodash@1.0`을 패키지 리포지토리 `myrepo`에 게시하고 `myrepo`가 업스트림 리포지토리로 구성된 게이트웨이 리포지토리를 통해 npmjs.com에 연결되어 있다고 가정해 보겠습니다. `lodash@1.0`이 업스트림 리포지토리 또는 npmjs.com에 있다면, CodeCatalyst는 `myrepo`에서 이에 게시하려는 모든 시도를 거부하며 409 충돌 오류가 발생합니다. 이렇게 하면 업스트림 리포지토리의 패키지와 이름 및 버전이 동일한 패키지를 실수로 게시하지 못하게 되어 예기치 않은 동작이 발생할 수 있습니다.

업스트림 리포지토리에 있는 패키지 이름의 다른 버전을 게시할 수 있습니다. 예를 들어 `lodash@1.0`이 업스트림 리포지토리에 있지만 `lodash@1.1`이 아닌 경우 `lodash@1.1`을 다운스트림 리포지토리에 게시할 수 있습니다.

## 프라이빗 패키지 및 퍼블릭 리포지토리
<a name="package-publishing-upstreams-direct"></a>

 CodeCatalyst는 CodeCatalyst 리포지토리에 저장된 패키지를 npmjs.com 또는 Maven Central 같은 퍼블릭 리포지토리에 게시하지 않습니다. CodeCatalyst는 퍼블릭 리포지토리에서 CodeCatalyst 리포지토리로 패키지를 가져오지만, 반대 방향으로 패키지를 이동시키지는 않습니다. CodeCatalyst 리포지토리에 게시하는 패키지는 비공개로 유지되며 리포지토리가 속한 CodeCatalyst 프로젝트에서만 사용할 수 있습니다.

## 패키지 자산 덮어쓰기
<a name="package-publishing-overwrite-assets"></a>

 이미 존재하며 콘텐츠가 다른 패키지 자산은 다시 게시할 수 없습니다. 예를 들어 Maven 패키지를 JAR 자산 `mypackage-1.0.jar`과 함께 이미 게시했다고 가정해 보겠습니다. 이 자산은 이전 자산과 새 자산의 체크섬이 동일한 경우에만 다시 게시할 수 있습니다. 새로운 내용이 있는 동일한 자산을 다시 게시하려면 먼저 해당 패키지 버전을 삭제하세요. 콘텐츠가 다른 동일한 자산 이름을 다시 게시하려고 하면 HTTP 409 충돌 오류가 발생합니다.

여러 자산을 지원하는 패키지 형식(Python 및 Maven)의 경우, 필요한 권한이 있다면 언제든지 기존 패키지 버전에 이름이 다른 새 자산을 추가할 수 있습니다. npm와 NuGet은 패키지 버전당 자산 하나만 지원하므로, 게시된 패키지 버전을 수정하려면 먼저 패키지 버전을 삭제해야 합니다.

 이미 존재하는 자산(예:`mypackage-1.0.jar`)을 다시 게시하려고 할 때 게시된 자산과 새 자산의 내용이 동일하면, 작업은 멱등성이기 때문에 성공하게 됩니다.

# 패키지 버전 세부 정보 보기
<a name="working-with-packages-view"></a>

CodeCatalyst 콘솔을 사용하여 특정 패키지 버전에 대한 세부 정보를 볼 수 있습니다.

**패키지 버전 세부 정보 보기**

1. 탐색 창에서 **패키지**를 선택합니다.

1. **패키지 리포지토리** 페이지에서 세부 정보를 보려는 패키지 버전이 포함된 리포지토리를 선택합니다.

1. **패키지** 테이블에서 패키지 버전을 검색합니다. 검색 창을 사용하여 패키지 이름과 형식 지정에 따라 패키지를 필터링할 수 있습니다. 목록에서 패키지를 선택합니다.

1. **패키지 세부 정보** 페이지에서 **버전** 을 선택한 다음 보려는 버전을 선택합니다.

# 패키지 버전 삭제
<a name="working-with-packages-delete"></a>

CodeCatalyst 콘솔의 **패키지 버전 세부 정보** 페이지에서 패키지 버전을 삭제할 수 있습니다.

**패키지 버전 삭제**

1. 탐색 창에서 **패키지**를 선택합니다.

1. **패키지 리포지토리** 페이지에서 삭제하려는 패키지 버전이 포함된 리포지토리를 선택합니다.

1. 테이블에서 패키지를 검색하고 선택합니다.

1. **패키지 세부 정보** 페이지에서 **버전**을 선택하고 삭제할 버전을 선택합니다.

1. **패키지 버전 세부 정보** 페이지에서 **버전 작업**을 선택하고 **삭제**를 선택합니다.

1. 텍스트 필드에 *delete*를 입력하고 **삭제**를 선택합니다.

# 패키지 버전의 상태 업데이트
<a name="working-with-packages-update-version-status"></a>

CodeCatalyst의 각 패키지 버전에는 패키지 버전의 현재 상태 및 가용성을 설명하는 상태가 적용됩니다. CodeCatalyst 콘솔을 사용하여 패키지 버전 상태를 변경할 수 있습니다. 패키지 버전의 가능한 상태 값과 그 의미에 대한 자세한 내용은 [패키지 버전 상태](#package-version-status) 섹션을 참조하세요.

**패키지 버전의 상태 업데이트**

1. 탐색 창에서 **패키지**를 선택합니다.

1. **패키지 리포지토리** 페이지에서 상태를 업데이트하려는 패키지 버전이 포함된 리포지토리를 선택합니다.

1. 테이블에서 패키지를 검색하고 선택합니다.

1. **패키지 세부 정보** 페이지에서 **버전** 을 선택한 다음 보려는 버전을 선택합니다.

1. **패키지 버전 세부 정보** 페이지에서 **작업**을 선택한 다음 **나열 취소,** **아카이브** 또는 **폐기**를 선택합니다. 각 패키지 버전 상태에 대한 자세한 내용은 [패키지 버전 상태](#package-version-status) 섹션을 참조하세요.

1. 텍스트 필드에 확인 텍스트를 입력한 다음 업데이트 중인 상태에 따라 **나열 취소**, **아카이브** 또는 **폐기**를 선택합니다.

## 패키지 버전 상태
<a name="package-version-status"></a>

다음은 패키지 버전 상태에 적용되는 값입니다. 콘솔을 사용하여 패키지 버전 상태를 변경할 수 있습니다. 자세한 내용은 [패키지 버전의 상태 업데이트](#working-with-packages-update-version-status) 섹션을 참조하세요.
+  **게시됨**: 패키지 버전이 성공적으로 게시되었으며 패키지 관리자를 이용해 요청할 수 있습니다. 패키지 버전은 패키지 관리자에 반환되는 패키지 버전 목록(예: `npm view <package-name> versions` 출력)에 포함됩니다. 패키지 버전의 모든 자산은 리포지토리에서 사용할 수 있습니다.
+  **완료되지 않음**: 마지막 게시 시도가 완료되지 않았습니다. 현재 Maven 패키지 버전만 **완료되지 않음** 상태를 가질 수 있습니다. 클라이언트가 패키지 버전용 자산을 하나 이상 업로드하지만 해당 버전이 포함된 패키지의 `maven-metadata.xml` 파일을 게시하지 않으면 이 문제가 발생할 수 있습니다.
+  **미등록** - 패키지 버전의 자산을 리포지토리에서 다운로드할 수 있지만, 패키지 버전이 패키지 관리자에게 반환되는 버전 목록에 포함되지 않습니다. 예를 들어 npm 패키지의 경우 `npm view <package-name> versions` 출력에 패키지 버전이 포함되지 않습니다. 즉, 사용 가능한 버전 목록에 버전이 표시되지 않기 때문에 npm의 종속성 확인 로직은 패키지 버전을 선택하지 않습니다. 하지만 **미등록** 패키지 버전이 이미 `npm package-lock.json` 파일에서 참조된 경우, 예를 들어 `npm ci`를 실행 중일 때 해당 버전을 다운로드하여 설치할 수 있습니다.
+  **아카이브됨** - 패키지 버전 자산을 다운로드할 수 없습니다. 패키지 버전은 패키지 관리자에 반환되는 버전 목록에 포함됩니다. 자산을 사용할 수 없으므로 클라이언트의 패키지 버전 사용이 차단됩니다. 애플리케이션 빌드가 **아카이브됨**으로 업데이트된 버전을 사용하는 경우, 패키지 버전이 로컬에 캐시되지 않으면 빌드가 실패합니다. **아카이브됨** 패키지 버전은 리포지토리에 여전히 존재하므로 패키지 관리자나 빌드 도구를 사용하여 다시 게시할 수 없습니다. 하지만 콘솔에서 패키지 버전 상태를 **미등록** 또는 **게시됨**으로 변경할 수 있습니다.
+  **폐기됨**: 패키지 버전이 목록에 표시되지 않으며 리포지토리에서 자산을 다운로드할 수 없습니다. **폐기됨**과 **보관됨**의 주된 차이점은 **폐기됨** 상태인 경우 CodeCatalyst가 패키지 버전의 자산을 영구적으로 삭제한다는 것입니다. 따라서 패키지 버전을 **폐기됨**에서 **보관됨**, **미등록** 또는 **게시됨**으로 전환할 수 없습니다. 자산이 삭제되었으므로 패키지 버전을 사용할 수 없습니다. 패키지 버전이 **폐기됨**으로 표시되면 패키지 자산의 스토리지 비용이 청구되지 않습니다.

 위 목록의 상태 외에도 패키지 버전을 삭제할 수도 있습니다. 삭제된 패키지 버전은 리포지토리에 없으며 패키지 관리자 또는 빌드 도구를 사용하여 해당 패키지 버전을 자유롭게 다시 게시할 수 있습니다.

## 패키지 이름, 패키지 버전 및 자산 이름 표준화
<a name="package-name-normalization"></a>

CodeCatalyst는 패키지 이름, 패키지 버전과 자산 이름을 저장하기 전에 먼저 표준화합니다. 즉, CodeCatalyst의 이름 또는 버전은 패키지가 게시될 때 제공된 것과 다를 수 있습니다. CodeCatalyst에서 각 패키지 유형의 이름 및 버전을 표준화하는 방법에 대한 자세한 내용은 다음 설명서를 참조하세요.
+ [Python 패키지 이름 정규화](python-name-normalization.md)
+ [NuGet 패키지 이름, 버전 및 자산 이름 표준화](nuget-name-normalization.md)

CodeCatalyst는 다른 패키지 형식에서는 표준화를 수행하지 않습니다.

# 패키지 원본 제어 편집
<a name="package-origin-controls"></a>

Amazon CodeCatalyst에서는 패키지 버전을 직접 게시하거나, 업스트림 리포지토리에서 가져오거나, 게이트웨이를 통해 외부 퍼블릭 리포지토리에서 수집하여, 패키지 버전을 리포지토리에 추가할 수 있습니다. 직접 게시와 퍼블릭 리포지토리에서 수집하는 방법 모두를 통해 패키지의 버전을 추가하면, 종속성 대체 공격에 취약해집니다. 자세한 내용은 [종속성 대체 공격](#dependency-substitution-attacks) 단원을 참조하십시오. 종속성 대체 공격을 방어하려면 리포지토리의 패키지에서 패키지 원본 제어를 구성하여 해당 패키지 버전을 리포지토리에 추가하는 방법을 제한합니다.

직접 게시 같은 내부 소스와 퍼블릭 리포지토리 같은 외부 소스 모두에서 서로 다른 패키지의 새 버전을 가져오려면 패키지 원본 제어 구성을 고려해야 합니다. 기본적으로 패키지 원본 제어는 패키지의 첫 번째 버전이 리포지토리에 추가되는 방식을 기반으로 구성됩니다.

## 패키지 원본 제어 설정
<a name="package-origin-control-settings"></a>

패키지 원본 제어를 사용하여 패키지 버전을 리포지토리에 추가하는 방법을 구성할 수 있습니다. 다음 목록에는 사용 가능한 패키지 원본 제어 설정 및 값이 포함되어 있습니다.

**게시**

이 설정은 패키지 관리자 또는 이와 유사한 도구를 사용하여 패키지 버전을 리포지토리에 직접 게시할 수 있는지를 구성합니다.
+ **허용**: 패키지 버전을 직접 게시할 수 있습니다.
+ **차단**: 패키지 버전을 직접 게시할 수 없습니다.

**업스트림**

이 설정은 패키지 관리자가 요청하는 경우 패키지 버전을 외부 또는 퍼블릭 리포지토리에서 수집하거나 업스트림 리포지토리에서 유지할 수 있는지를 구성합니다.
+ **허용**: 모든 패키지 버전은 업스트림 리포지토리로 구성된 다른 CodeCatalyst 리포지토리에서 유지하거나 외부 연결을 통해 공개 소스에서 수집할 수 있습니다.
+ **차단**: 패키지 버전은 업스트림 리포지토리로 구성된 다른 CodeCatalyst 리포지토리에서 유지하거나 외부 연결을 통해 공개 소스에서 수집할 수 없습니다.

### 기본 패키지 원본 제어 설정
<a name="default-package-origin-control-settings"></a>

패키지의 기본 패키지 원본 제어는 해당 패키지의 첫 번째 버전이 패키지 리포지토리에 추가되는 방식을 기반으로 합니다.
+ 패키지 관리자가 첫 번째 패키지 버전을 직접 게시하는 경우 설정은 **게시: 허용** 및 **업스트림: 차단**이 됩니다.
+ 첫 번째 패키지 버전을 공개 소스에서 수집하는 경우 설정은 **게시: 차단** 및 **업스트림: 허용**이 됩니다.

## 일반적인 패키지 액세스 제어 시나리오
<a name="package-origin-control-scenarios"></a>

이 섹션에는 CodeCatalyst 리포지토리에 패키지 버전이 추가되는 일반적인 시나리오를 설명합니다. 새 패키지에 대한 패키지 원본 제어 설정은 첫 번째 패키지 버전이 추가되는 방식에 따라 설정됩니다.

다음 시나리오에서 *내부 패키지*는 패키지 관리자가 리포지토리에 직접 게시하는 패키지(예: 사용자가 유지 관리하는 패키지)입니다. *외부 패키지*는 게이트웨이 리포지토리 업스트림을 통해 리포지토리에 수집될 수 있는 퍼블릭 리포지토리에 있는 패키지입니다.

**외부 패키지 버전은 기존 내부 패키지를 대상으로 게시됩니다.**

이 시나리오에서는 내부 패키지인 *packageA*를 가정합니다. 팀은 *packageA*의 첫 번째 패키지 버전을 CodeCatalyst 패키지 리포지토리에 게시합니다. 이 패키지의 첫 번째 패키지 버전이므로, 패키지 원본 제어 설정은 **게시: 허용** 및 **업스트림: 차단**으로 자동 설정됩니다. 패키지가 리포지토리에 게시되면, CodeCatalyst 패키지 리포지토리에 연결된 퍼블릭 리포지토리에 같은 이름의 패키지가 게시됩니다. 이는 내부 패키지에 대한 종속성 대체 공격 시도일 수도 있고 우연의 일치일 수도 있습니다. 하지만 패키지 원본 제어는 새로운 외부 버전의 수집을 차단하여 잠재적 공격을 방어하도록 구성되어 있습니다.

다음 이미지에서 *repoA*는 `npm-public-registry-gateway` 리포지토리에 대한 업스트림 연결이 있는 CodeCatalyst 패키지 리포지토리입니다. 리포지토리에 *packageA* 버전 1.1 및 2.1이 있지만 버전 3.0은 퍼블릭 리포지토리에 게시됩니다. 일반적으로 *repoA*는 패키지 관리자가 패키지를 요청한 후 버전 3.0을 수집합니다. 패키지 수집이 **차단**으로 설정되어 있기 때문에 버전 3.0은 CodeCatalyst 패키지 리포지토리에 수집되지 않으며 이 리포지토리에 연결된 패키지 관리자가 사용할 수 없습니다.

![\[퍼블릭 리포지토리에서 차단된 새 외부 패키지 버전을 보여주는 간단한 그래픽입니다.\]](http://docs.aws.amazon.com/ko_kr/codecatalyst/latest/userguide/images/packages/package-origin-controls-one.png)


**내부 패키지 버전은 기존 외부 패키지를 대상으로 게시됩니다.**

이 시나리오에서는 패키지인 *packageB*가 리포지토리에 연결된 퍼블릭 리포지토리의 외부에 존재합니다. 리포지토리에 연결된 패키지 관리자가 *packageB*를 요청하면 해당 패키지 버전이 퍼블릭 리포지토리에서 사용자의 리포지토리로 수집됩니다. 이것은 리포지토리에 추가된 *packageB*의 첫 번째 패키지 버전이므로, 패키지 원본 설정은 **게시: 차단** 및 **업스트림: 허용**으로 구성됩니다. 나중에 패키지 이름이 동일한 버전을 리포지토리에 게시합니다. 퍼블릭 패키지를 모르는 상태에서 관련 없는 패키지를 같은 이름으로 게시하려고 하거나, 패치가 적용된 버전을 게시하려고 하거나, 이미 외부에 있는 패키지 버전을 직접 게시하게 될 수 있습니다. CodeCatalyst는 사용자가 게시하려는 버전을 거부하지만, 사용자가 거부를 명시적으로 무시하고 필요한 경우에만 버전을 게시할 수 있습니다.

다음 이미지에서 *repoA*는 `npm-public-registry-gateway` 리포지토리에 대한 업스트림 연결이 있는 CodeCatalyst 패키지 리포지토리입니다. 패키지 리포지토리에는 퍼블릭 리포지토리에서 수집된 버전 3.0이 포함되어 있습니다. 버전 1.2를 리포지토리에 게시하려 합니다. 일반적으로 버전 1.2를 *repoA*에 게시할 수 있지만 게시가 **차단**으로 설정되어 있기 때문에 버전 1.2는 게시할 수 없습니다.

![\[패키지 게시가 차단되었음을 보여주는 간단한 그래픽입니다.\]](http://docs.aws.amazon.com/ko_kr/codecatalyst/latest/userguide/images/packages/package-origin-controls-two.png)


**기존 외부 패키지의 패치가 적용된 패키지 버전 게시**

이 시나리오에서는 패키지인 *packageB*가 패키지 리포지토리에 연결된 퍼블릭 리포지토리의 외부에 존재합니다. 리포지토리에 연결된 패키지 관리자가 *packageB*를 요청하면 해당 패키지 버전이 퍼블릭 리포지토리에서 사용자의 리포지토리로 수집됩니다. 이것은 사용자의 리포지토리에 추가된 *packageB*의 첫 번째 패키지 버전이므로, 패키지 원본 설정은 **게시: 차단** 및 **업스트림: 허용**으로 구성됩니다. 팀에서 이 패키지의 패치가 적용된 패키지 버전을 리포지토리에 게시하기로 합니다. 패키지 버전을 직접 게시하기 위해 팀은 패키지 원본 제어 설정을 **게시: 허용** 및 **업스트림: 차단**으로 변경합니다. 이제 이 패키지의 버전을 리포지토리에 직접 게시하고 퍼블릭 리포지토리에서 수집할 수 있습니다. 팀에서 패치된 패키지 버전을 게시하면 패키지 원본 설정을 **게시: 차단** 및 **업스트림: 허용**으로 되돌립니다.

## 패키지 원본 제어 편집
<a name="edit-package-origin-controls"></a>

패키지 원본 제어는 패키지 첫 번째 패키지 버전이 리포지토리에 추가되는 방식에 따라 자동으로 구성됩니다. 자세한 내용은 [기본 패키지 원본 제어 설정](#default-package-origin-control-settings) 단원을 참조하십시오. CodeCatalyst 패키지 리포지토리에서 패키지의 패키지 원본 제어를 추가하거나 편집하려면 다음 절차의 단계를 수행하세요.

**패키지 원본 제어 추가 또는 편집하려면**

1. 탐색 창에서 **패키지**를 선택합니다.

1. 편집하려는 패키지가 포함된 패키지 리포지토리를 선택합니다.

1. **패키지** 표에서 편집할 패키지를 검색하여 선택합니다.

1. 패키지 요약 페이지의 **원본 제어**를 선택합니다.

1. **원본 제어**에서 이 패키지에 설정할 패키지 원본 제어를 선택합니다. 패키지 원본 제어 설정인 **게시**와 **업스트림**을 동시에 설정해야 합니다.
   + 패키지 버전을 직접 게시할 수 있도록 허용하려면 **게시**에서 **허용**을 선택합니다. 패키지 버전 게시를 차단하려면 **차단**을 선택합니다.
   + 외부 리포지토리에서 패키지를 수집하고 업스트림 리포지토리에서 패키지를 가져오도록 허용하려면 **업스트림 소스**에서 **허용**을 선택합니다. 외부 및 업스트림 리포지토리에서의 패키지 버전 수집과 가져오기를 모두 차단하려면 **차단**을 선택합니다.

1. **저장**을 선택합니다.

## 리포지토리 게시 및 업스트림
<a name="package-publishing-upstreams"></a>

CodeCatalyst에서는 연결 가능한 업스트림 리포지토리 또는 퍼블릭 리포지토리에 있는 패키지 버전을 게시할 수 없습니다. 예를 들어 npm 패키지 `lodash@1.0`을 리포지토리 `myrepo`에 게시하려고 하는데 `myrepo`에 npmjs.com과의 외부 연결이 있는 업스트림 리포지토리가 있다고 가정해 보겠습니다. 다음 시나리오를 고려해 보세요.

1. `lodash`에서의 패키지 원본 제어 설정은 **게시: 허용**과 **업스트림: 허용**입니다. `lodash@1.0`이 업스트림 리포지토리 또는 npmjs.com에 있다면, CodeCatalyst는 `myrepo`에서 이에 게시하려는 모든 시도를 거부하며 409 충돌 오류가 발생합니다. `lodash@1.1` 같은 다른 버전은 게시할 수 있습니다.

1. `lodash`에서의 패키지 원본 제어 설정은 **게시: 허용**과 **업스트림: 차단**입니다. `lodash`의 모든 버전은 아직 존재하지 않는 리포지토리에 게시할 수 있습니다. 패키지 버전에 연결할 수 없기 때문입니다.

1. `lodash`에서의 패키지 원본 제어 설정은 **게시: 차단**과 **업스트림: 하용**입니다. 패키지 버전은 리포지토리에 직접 게시할 수 없습니다.

## 종속성 대체 공격
<a name="dependency-substitution-attacks"></a>

패키지 관리자는 재사용 가능한 코드를 패키징하고 공유하는 프로세스를 단순화합니다. 이러한 패키지는 애플리케이션에서 사용하기 위해 조직에서 개발한 프라이빗 패키지일 수도 있고, 조직 외부에서 개발되어 퍼블릭 패키지 리포지토리에서 배포하는 퍼블릭(대부분의 경우 오픈 소스) 패키지일 수도 있습니다. 패키지를 요청할 때 개발자는 패키지 관리자를 이용해 종속 항목의 새 버전을 가져옵니다. 종속성 혼동 공격이라고도 하는 종속성 대체 공격은 대부분의 패키지 관리자가 패키지의 합법적인 버전과 악성 버전을 구분할 방법이 없다는 사실을 악용합니다.

종속성 대체 공격은 소프트웨어 공급망 공격이라 알려진 공격의 하위 집합에 속합니다. 소프트웨어 공급망 공격은 소프트웨어 공급망에 존재하는 취약성을 악용하는 공격입니다.

종속성 대체 공격은 내부적으로 개발된 패키지와 퍼블릭 리포지토리에서 가져온 패키지를 모두 사용하는 사용자라면 누구나 노릴 수 있습니다. 공격자는 내부 패키지 이름을 식별한 다음 같은 이름의 악성 코드를 전략적으로 퍼블릭 패키지 리포지토리에 배치합니다. 일반적으로 악성 코드는 버전 번호가 높은 패키지에 게시됩니다. 패키지 관리자는 악성 패키지가 패키지 최신 버전이라고 생각하기 때문에 이러한 퍼블릭 피드에서 악성 코드를 가져옵니다. 결과적으로 원하는 패키지와 악성 패키지 간에 ‘혼동’ 또는 ‘대체’가 발생하여 코드가 손상될 수 있습니다.

종속성 대체 공격을 방지하기 위해 Amazon CodeCatalyst는 패키지 원본 제어 기능을 제공합니다. 패키지 원본 제어는 패키지를 리포지토리에 추가하는 방법을 제어하는 설정입니다. 제어는 새 패키지의 첫 번째 패키지 버전이 CodeCatalyst 리포지토리에 추가될 때 자동으로 구성됩니다. 제어를 사용하면 패키지 버전을 리포지토리에 직접 게시하거나 퍼블릭 소스에서 수집할 수 없게 하여 종속성 대체 공격을 방어할 수 있습니다. 패키지 원본 제어 및 이를 변경하는 방법에 대한 자세한 내용은 [패키지 원본 제어 편집](#package-origin-controls) 섹션을 참조하세요.

# npm 사용
<a name="packages-npm"></a>

이 항목에서는 Node.js 패키지 관리자인 `npm`을 CodeCatalyst와 함께 사용하는 방법을 설명합니다.

**참고**  
CodeCatalyst는 `node v4.9.1` 이상 `npm v5.0.0` 및 이상을 지원합니다.

**Topics**
+ [npm 구성 및 사용](packages-npm-use.md)
+ [npm 태그 처리](packages-npm-tags.md)

# npm 구성 및 사용
<a name="packages-npm-use"></a>

`npm`를 CodeCatalyst와 함께 사용하려면 패키지 리포지토리에 `npm`를 연결하고 인증을 위한 개인 액세스 토큰(PAT)을 제공해야 합니다. CodeCatalyst 콘솔에서 패키지 리포지토리에 `npm`을 연결하기 위한 지침을 볼 수 있습니다.

**Contents**
+ [CodeCatalyst를 사용하여 npm 구성](#npm-configure)
+ [CodeCatalyst 패키지 리포지토리에서 npm 패키지 설치](#npm-install)
+ [CodeCatalyst를 통해 npmjs에서 npm 패키지 설치](#npm-install-npmjs)
+ [CodeCatalyst 패키지 리포지토리에 npm 패키지 게시](#npm-publish)
+ [npm 명령 지원](#npm-commands)
  + [리포지토리와 상호 작용하는 지원되는 명령](#supported-commands-that-interact-with-a-repository)
  + [지원되는 클라이언트 측 명령](#supported-client-side-commands)
  + [지원되지 않는 명령](#unsupported-commands)

## CodeCatalyst를 사용하여 npm 구성
<a name="npm-configure"></a>

다음 지침은 CodeCatalyst 패키지 리포지토리를 인증하고 `npm`에 연결하는 방법을 설명합니다. npm에 대한 자세한 내용은 [공식 npm 설명서](https://docs.npmjs.com/)를 참조하세요.

**CodeCatalyst 패키지 리포지토리`npm`에 연결하려면**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.

1. 프로젝트로 이동합니다.

1. 탐색 창에서 **패키지**를 선택합니다.

1. 목록에서 패키지 리포지토리를 선택합니다.

1. **리포지토리에 연결**을 선택합니다.

1. **구성 세부 정보**의 **패키지 관리자 클라이언트**에서 **npm 클라이언트**를 선택합니다.

1. 해당하는 구성 단계를 보기 위해 사용 중인 운영 체제를 선택합니다.

1. CodeCatalyst를 사용하여 npm을 인증하려면 개인 액세스 토큰(PAT)이 필요합니다. 토큰이 이미 있으면 해당 토큰을 사용할 수 있습니다. 토큰이 없다면, 다음 단계를 통해 생성할 수 있습니다.

   1. **(선택 사항):** **PAT 이름** 및 **만료 날짜**를 업데이트합니다.

   1. **토큰 생성**을 선택합니다.

   1. PAT를 복사하여 안전한 위치에 저장합니다.
**주의**  
대화 상자를 닫으면 PAT를 다시 보거나 복사할 수 없습니다. 자격 증명은 공격자가 자격 증명을 유용한 후 사용할 수 있는 기간을 최소화하도록 수명이 짧아야 합니다.

1. 프로젝트의 루트 디렉터리에서 다음 명령을 실행하여 패키지 리포지토리로 npm을 구성합니다. 명령은 다음을 수행합니다.
   + 프로젝트에 아무 파일도 없는 경우 프로젝트 수준의 `.npmrc` 파일을 생성합니다.
   + 패키지 리포지토리 엔드포인트 정보를 프로젝트 수준의 `.npmrc` 파일에 추가합니다.
   + 사용자 수준의 `.npmrc` 파일에 자격 증명(PAT)을 추가합니다.

   다음 값을 교체합니다.
**참고**  
콘솔 지침에서 복사하는 경우 다음 명령의 값이 업데이트되므로 변경할 필요가 없습니다.
   + *username*을 CodeCatalyst 사용자 이름으로 바꿉니다.
   + *PAT*를 CodeCatalyst PAT로 바꿉니다.
   + *space\$1name*을 CodeCatalyst 스페이스 이름으로 바꿉니다.
   + *proj\$1name*을 CodeCatalyst 프로젝트 이름으로 바꿉니다.
   + *my\$1repo*를 CodeCatalyst 패키지 리포지토리 이름으로 바꿉니다.

   ```
   npm set registry=https://packages.region.codecatalyst.aws/npm/space-name/proj-name/repo-name/ --location project
   npm set //packages.region.codecatalyst.aws/npm/space-name/proj-name/repo-name/:_authToken=username:PAT
   ```

   **npm 6 이하의 경우:** `GET` 요청이 있을 경우에도 npm이 항상 CodeCatalyst에 인증 토큰을 전달하도록 하려면 항시 인증 구성 변수를 `npm config set`로 다음과 같이 설정합니다.

   ```
   npm set //packages.region.codecatalyst.aws/npm/space-name/proj-name/repo-name/:always-auth=true --location project
   ```

## CodeCatalyst 패키지 리포지토리에서 npm 패키지 설치
<a name="npm-install"></a>

[CodeCatalyst를 사용하여 npm 구성](#npm-configure) 섹션의 단계에 따라 npm을 리포지토리에 연결한 후 리포지토리에서 `npm` 명령을 실행할 수 있습니다.

`npm install` 명령을 사용하여 CodeCatalyst 패키지 리포지토리 또는 업스트림 리포지토리 중 하나에 있는 npm 패키지를 설치할 수 있습니다.

```
npm install lodash
```

## CodeCatalyst를 통해 npmjs에서 npm 패키지 설치
<a name="npm-install-npmjs"></a>

npmjs.com, **npm-public-registry-gateway**에 연결된 게이트웨이 리포지토리에 대한 업스트림 연결로 리포지토리를 구성하여 CodeCatalyst 리포지토리를 통해 [npmjs.com](https://www.npmjs.com/)에서 npm 패키지를 설치할 수 있습니다. npmjs에서 설치된 패키지는 수집되어 게이트웨이 리포지토리와 가장 먼 다운스트림 패키지 리포지토리에 저장됩니다.

**npmjs에서 패키지를 설치하려면**

1. 아직 구성하지 않은 경우 [CodeCatalyst를 사용하여 npm 구성](#npm-configure)의 단계에 따라 CodeCatalyst 패키지 리포지토리로 `npm`을 구성합니다.

1. 리포지토리가 게이트웨이 리포지토리 **npm-public-registry-gateway**를 업스트림 연결로 추가했는지 확인합니다. [업스트림 리포지토리 추가](packages-upstream-repositories-add.md)의 지침에 따라 **npm-public-registry-gateway** 리포지토리를 선택하여, 어떤 업스트림 소스가 추가되었는지 확인하거나 **npm-public-registry-gateway**를 업스트림 소스로 추가할 수 있습니다.

1. `npm install` 명령을 사용하여 패키지를 설치합니다.

   ```
   npm install package_name
   ```

업스트림 리포지토리에서 패키지를 요청하는 방법에 대한 자세한 내용은 [업스트림 리포지토리가 포함된 패키지 버전 요청](packages-upstream-repositories-request.md) 섹션을 참조하세요.

## CodeCatalyst 패키지 리포지토리에 npm 패키지 게시
<a name="npm-publish"></a>

[CodeCatalyst를 사용하여 npm 구성](#npm-configure)를 완료한 후 `npm` 명령을 실행할 수 있습니다.

`npm publish` 명령을 사용하여 CodeCatalyst 패키지 리포지토리에 npm 패키지를 게시할 수 있습니다.

```
npm publish
```

npm 패키지를 만드는 방법에 관한 자세한 내용은 *npm Docs*에서 [Node.js 모듈 생성](https://docs.npmjs.com/getting-started/creating-node-modules) 섹션을 참조하세요.

## npm 명령 지원
<a name="npm-commands"></a>

다음 섹션에는 지원되지 않는 특정 명령 외에도 CodeCatalyst 리포지토리에서 지원하는 `npm` 명령이 요약되어 있습니다.

**Topics**
+ [리포지토리와 상호 작용하는 지원되는 명령](#supported-commands-that-interact-with-a-repository)
+ [지원되는 클라이언트 측 명령](#supported-client-side-commands)
+ [지원되지 않는 명령](#unsupported-commands)

### 리포지토리와 상호 작용하는 지원되는 명령
<a name="supported-commands-that-interact-with-a-repository"></a>

이 섹션에는 `npm` 클라이언트가 구성될 때 사용된 레지스트리(예: `npm config set registry` 포함)에 하나 이상의 요청을 보내는 `npm` 명령이 나열되어 있습니다. CodeCatalyst 패키지 리포지토리에 대해 이러한 명령을 간접적으로 호출했을 때 제대로 작동하는 것으로 확인되었습니다.


****  

| 명령 | 설명 | 
| --- | --- | 
|   [bugs](https://docs.npmjs.com/cli/bugs)   |  패키지의 버그 추적기 URL 위치를 추측한 후 URL 열기를 시도합니다.  | 
|   [ci](https://docs.npmjs.com/cli/ci)   |  프로젝트를 새로 다시 설치합니다.  | 
|   [deprecate](https://docs.npmjs.com/cli/deprecate)   |  패키지 버전을 더 이상 사용하지 않습니다.  | 
|   [dist-tag](https://docs.npmjs.com/cli/dist-tag)   |  패키지 배포 태그를 수정합니다.  | 
|   [docs](https://docs.npmjs.com/cli/docs)   |  패키지 설명서 URL의 위치를 추측한 다음 `--browser` config 파라미터를 사용하여 URL 열기를 시도합니다.  | 
|   [doctor](https://docs.npmjs.com/cli/doctor)   |  일련의 검사를 실행하여 npm 설치가 JavaScript 패키지를 관리할 수 있는지 검증합니다.  | 
|   [install](https://docs.npmjs.com/cli/install)   |  패키지를 설치합니다.  | 
|   [install-ci-test](https://docs.npmjs.com/cli/install-ci-test)   |  프로젝트를 새로 다시 설치하고 테스트를 실행합니다. 별칭: `npm cit`. 이 명령은 `npm ci`를 실행한 후 즉시 `npm test`를 실행합니다.  | 
|   [install-test](https://docs.npmjs.com/cli/install-test)   |  패키지를 설치하고 테스트를 실행합니다. `npm install`을 실행한 후 즉시 `npm test`를 실행합니다.  | 
|   [outdated](https://docs.npmjs.com/cli/outdated)   |  구성된 레지스트리를 검사하여 설치된 패키지가 만료되었는지 확인합니다.  | 
|   [ping](https://docs.npmjs.com/cli/ping)   |  구성되거나 지정된 npm 레지스트리를 ping하고 인증을 확인합니다.  | 
|   [publish](https://docs.npmjs.com/cli/publish)   |  패키지 버전을 레지스트리에 게시합니다.  | 
|   [update](https://docs.npmjs.com/cli/update)   |  패키지의 리포지토리 URL 위치를 추측한 다음, `--browser` config 파라미터를 사용하여 URL 열기를 시도합니다.  | 
|   [view](https://docs.npmjs.com/cli/view)   |  패키지 메타데이터를 표시합니다. 또한 메타데이터 속성을 인쇄하는 데 사용할 수 있습니다.  | 

### 지원되는 클라이언트 측 명령
<a name="supported-client-side-commands"></a>

이러한 명령은 리포지토리와 직접 상호 작용할 필요가 없으므로 CodeCatalyst는 명령을 지원하기 위해 아무 것도 할 필요가 없습니다.


****  

| 명령 | 설명 | 
| --- | --- | 
|   [bin(legacy)](https://docs.npmjs.com/cli/v8/commands/npm-bin)   |  npm `bin` 디렉터리를 표시합니다.  | 
|   [build](https://docs.npmjs.com/cli/v6/commands/npm-build)   |  패키지를 빌드합니다.  | 
|   [cache](https://docs.npmjs.com/cli/cache)   |  패키지 캐시를 조작합니다.  | 
|   [completion](https://docs.npmjs.com/cli/completion)   |  모든 npm 명령에서 탭 완성을 활성화합니다.  | 
|   [config](https://docs.npmjs.com/cli/config)   |  사용자 및 글로벌 `npmrc` 파일의 내용을 업데이트합니다.  | 
|   [dedupe](https://docs.npmjs.com/cli/dedupe)   |  로컬 패키지 트리를 검색하고 종속성을 트리 위로 이동하여 구조를 단순화하려고 합니다. 여기서 종속성을 여러 종속 패키지에서 더 효과적으로 공유할 수 있습니다.  | 
|   [edit](https://docs.npmjs.com/cli/edit)   |  설치된 패키지를 편집합니다. 현재 작업 디렉터리에서 종속성을 선택하고 기본 편집기에서 패키지 폴더를 엽니다.  | 
|   [explore](https://docs.npmjs.com/cli/explore)   |  설치된 패키지를 찾아봅니다. 설치된 특정 패키지의 디렉터리에 서브셸을 생성합니다. 명령이 지정되면 해당 명령은 서브셸에서 실행된 후 즉시 종료됩니다.  | 
|   [help](https://docs.npmjs.com/cli/help)   |  npm에 관한 도움말을 가져옵니다.  | 
|   [help-search](https://docs.npmjs.com/cli/help-search)   |  npm 도움말 설명서를 검색합니다.  | 
|   [init](https://docs.npmjs.com/cli/init)   |  `package.json` 파일을 생성합니다.  | 
|   [link](https://docs.npmjs.com/cli/link)   |  패키지 디렉터리에 심볼릭 링크를 생성합니다.  | 
|   [ls](https://docs.npmjs.com/cli/ls)   |  설치된 패키지를 나열합니다.  | 
|   [pack](https://docs.npmjs.com/cli/pack)   |  패키지에서 tarball을 생성합니다.  | 
|   [prefix](https://docs.npmjs.com/cli/prefix)   |  접두사를 표시합니다. `-g`도 지정되지 않는 한, 이 디렉터리는 `package.json` 파일을 포함하는 가장 가까운 상위 디렉터리입니다.  | 
|   [prune](https://docs.npmjs.com/cli/prune)   |  상위 패키지의 종속성 목록에 나열되지 않은 패키지를 제거합니다.  | 
|   [rebuild](https://docs.npmjs.com/cli/rebuild)   |  일치하는 폴더에서 `npm build` 명령을 실행합니다.  | 
|   [restart](https://docs.npmjs.com/cli/restart)   |  패키지의 중지, 재시작, 시작 스크립트와 관련 사전/사후 스크립트를 실행합니다.  | 
|   [root](https://docs.npmjs.com/cli/root)   |  유효 `node_modules` 폴더를 표준 출력으로 출력합니다.  | 
|   [run-script](https://docs.npmjs.com/cli/run-script)   |  임의의 패키지 스크립트를 실행합니다.  | 
|   [shrinkwrap](https://docs.npmjs.com/cli/shrinkwrap)   |  게시할 종속 버전을 잠급니다.  | 
|   [uninstall](https://docs.npmjs.com/cli/uninstall)   |  패키지를 제거합니다.  | 

### 지원되지 않는 명령
<a name="unsupported-commands"></a>

아래 `npm` 명령은 CodeCatalyst 패키지 리포지토리에서 지원하지 않습니다.


****  

| 명령 | 설명 | 참고 | 
| --- | --- | --- | 
|   [access](https://docs.npmjs.com/cli/access)   |  게시된 패키지에서 액세스 수준을 설정합니다.  |  CodeCatalyst는 퍼블릭 npmjs 리포지토리와는 다른 권한 모델을 사용합니다.  | 
|   [adduser](https://docs.npmjs.com/cli/adduser)   |  레지스트리 사용자 계정을 추가합니다.  |  CodeCatalyst는 퍼블릭 npmjs 리포지토리와는 다른 사용자 모델을 사용합니다.  | 
|   [audit](https://docs.npmjs.com/cli/audit)   |  보안 감사를 실행합니다.  |  CodeCatalyst는 현재 보안 취약성 데이터를 제공하지 않습니다.  | 
|   [hook](https://docs.npmjs.com/cli/v9/commands/npm-hook)   |  추가, 제거, 나열 및 업데이트를 포함하여 npm 후크를 관리합니다.  |  CodeCatalyst는 현재 어떠한 변경 알림 메커니즘도 지원하지 않습니다.  | 
|   [login](https://docs.npmjs.com/cli-commands/adduser.html)   |  사용자를 인증합니다. `npm adduser`에 대한 별칭입니다.  |  CodeCatalyst는 퍼블릭 npmjs 리포지토리와는 다른 인증 모델을 사용합니다. 자세한 내용은 [CodeCatalyst를 사용하여 npm 구성](#npm-configure) 단원을 참조하세요.  | 
|   [logout](https://docs.npmjs.com/cli/logout)   |  레지스트리에서 로그아웃합니다.  |  CodeCatalyst는 퍼블릭 npmjs 리포지토리와는 다른 인증 모델을 사용합니다. CodeCatalyst 리포지토리에서 로그아웃할 수 있는 방법은 없지만, 인증 토큰은 구성 가능한 만료 시간이 지나면 만료됩니다. 기본 토큰 지속 시간은 12시간입니다.  | 
|   [owner](https://docs.npmjs.com/cli/owner)   |  패키지 소유자를 관리합니다.  |  CodeCatalyst는 퍼블릭 npmjs 리포지토리와는 다른 권한 모델을 사용합니다.  | 
|   [profile](https://docs.npmjs.com/cli/profile)   |  레지스트리 프로파일의 설정을 변경합니다.  |  CodeCatalyst는 퍼블릭 npmjs 리포지토리와는 다른 사용자 모델을 사용합니다.  | 
|   [search](https://docs.npmjs.com/cli/search)   |  레지스트리에서 검색어와 일치하는 패키지를 검색합니다.  |  CodeCatalyst는 `search` 명령을 지원하지 않습니다.  | 
|   [star](https://docs.npmjs.com/cli/star)   |  좋아하는 패키지를 표시합니다.  |  CodeCatalyst는 현재 즐겨찾기 메커니즘을 지원하지 않습니다.  | 
|   [stars](https://docs.npmjs.com/cli/stars)   |  즐겨찾기로 표시된 패키지를 조회합니다.  |  CodeCatalyst는 현재 즐겨찾기 메커니즘을 지원하지 않습니다.  | 
|   [team](https://docs.npmjs.com/cli/team)   |  팀 및 팀 멤버십을 관리합니다.  |  CodeCatalyst는 퍼블릭 npmjs 리포지토리와는 다른 사용자 및 그룹 멤버 모델을 사용합니다.  | 
|   [token](https://docs.npmjs.com/cli/token)   |  인증 토큰을 관리합니다.  |  CodeCatalyst는 인증 토큰을 가져오기 위해 다른 모델을 사용합니다. 자세한 내용은 [CodeCatalyst를 사용하여 npm 구성](#npm-configure) 단원을 참조하세요.  | 
|   [unpublish](https://docs.npmjs.com/cli/unpublish)   |  레지스트리에서 패키지를 제거합니다.  |  CodeCatalyst는 npm 클라이언트를 사용하여 리포지토리에서 패키지 버전을 제거하는 것을 지원하지 않습니다. 콘솔을 사용하여 에서 패키지를 삭제할 수 있습니다.  | 
|   [whoami](https://docs.npmjs.com/cli/whoami)   |  npm 사용자 이름을 표시합니다.  |  CodeCatalyst는 퍼블릭 npmjs 리포지토리와는 다른 사용자 모델을 사용합니다.  | 

# npm 태그 처리
<a name="packages-npm-tags"></a>

npm 레지스트리는 패키지 버전의 문자열 별칭인 *태그*를 지원합니다. 태그를 사용하여 버전 번호를 사용하는 대신 별칭을 제공할 수 있습니다. 예를 들어, 여러 개발 스트림이 있는 프로젝트에서 각 스트림마다 다른 태그(예: `stable`, `beta`, `dev`, `canary`)를 사용할 수 있습니다. 자세한 내용은 *npm Docs*에서 [dist-tag](https://docs.npmjs.com/cli/dist-tag)를 참조하세요.

기본적으로 npm은 `latest` 태그를 사용하여 패키지의 현재 버전을 식별합니다. `npm install pkg`(`@version` 또는 `@tag` 지정자가 없는)는 최신 태그를 설치합니다. 일반적으로 프로젝트는 안정적인 릴리스 버전에만 최신 태그를 사용합니다. 그 밖의 태그는 불안정한 버전이나 프리릴리스 버전에 사용됩니다.

## npm 클라이언트로 태그를 편집
<a name="editing-tags-with-the-npm-client"></a>

 CodeCatalyst 패키지 리포지토리에서는 세 개의 `npm dist-tag` 명령(`add`, `rm` 및 `ls`)이 [기본 npm 레지스트리](https://registry.npmjs.com/)에서와 동일하게 작동합니다.

## npm 태그와 업스트림 리포지토리
<a name="packages-tags-and-upstreams"></a>

`npm`이 패키지에 대한 태그를 요청하고 해당 패키지의 버전이 업스트림 리포지토리에도 있을 때 CodeCatalyst는 태그를 병합한 후 클라이언트에 반환합니다. 예를 들어 리포지토리 `R`에는 업스트림 리포지토리 `U`가 있습니다. 다음 표에는 두 리포지토리에 모두 있는 `web-helper`라는 패키지의 태그가 나와 있습니다.


****  

| 리포지토리 | 패키지 이름 | 패키지 태그 | 
| --- | --- | --- | 
|  R  |  `web-helper`  |   *latest*(버전 1.0.0의 별칭)  | 
|  U  |  `web-helper`  |   *alpha*(버전 1.0.1의 별칭)  | 

이 경우, npm 클라이언트가 리포지토리 `R`에서 `web-helper` 패키지의 태그를 가져오면 *latest* 태그와 *alpha* 태그를 모두 받습니다. 태그가 가리키는 버전은 변경되지 않습니다.

업스트림 및 로컬 리포지토리의 동일한 패키지에 동일한 태그가 있는 경우 CodeCatalyst는 *마지막으로 업데이트된* 태그를 사용합니다. 예를 들어, *webhelper*의 태그가 다음과 같이 수정되었다고 가정해 보겠습니다.


****  

| 리포지토리 | 패키지 이름 | 패키지 태그 | 최종 업데이트 날짜 | 
| --- | --- | --- | --- | 
|  R  |  `web-helper`  |   *latest*(버전 1.0.0의 별칭)  |  2023년 1월 1일  | 
|  U  |  `web-helper`  |   *latest*(버전 1.0.1의 별칭)  |  2023년 6월 1일  | 

이 경우, npm 클라이언트가 리포지토리 `R`에서 패키지 *web-helper*의 태그를 가져오면, *최신* 태그는 버전 *1.0.1*에 별칭을 지정합니다. 이는 가장 최근에 업데이트되었기 때문입니다. 이렇게 하면 `npm update`를 실행하여 로컬 리포지토리에 아직 없는 업스트림 리포지토리의 새 패키지 버전을 쉽게 사용할 수 있습니다.

# Maven 사용
<a name="packages-maven"></a>

Maven 리포지토리 형식은 Java, Kotlin, Scala, Clojure를 비롯한 다양한 언어에서 사용됩니다. Maven, Gradle, Scala SBT, Apache Ivy, Leiningen을 비롯한 다양한 빌드 도구에서 지원됩니다.

CodeCatalyst와 다음 버전과의 호환성을 테스트하고 확인했습니다.
+ 최신 **Maven** 버전: 3.6.3.
+ 최신 **Gradle** 버전: 6.4.1. 버전 5.5.1도 테스트되었습니다.

**Topics**
+ [Gradle Groovy 구성 및 사용](packages-maven-gradle.md)
+ [mvn 구성 및 사용](packages-maven-mvn.md)
+ [curl을 사용하여 패키지 게시](packages-maven-curl.md)
+ [Maven 체크섬 및 스냅샷 사용](packages-maven-checksums-snapshots.md)

# Gradle Groovy 구성 및 사용
<a name="packages-maven-gradle"></a>

CodeCatalyst 에서 Gradle Groovy를 사용하려면 Gradle Groovy를 패키지 리포지토리에 연결하고 인증을 위한 개인 액세스 토큰(PAT)을 제공해야 합니다. CodeCatalyst 콘솔에서 Gradle Groovy를 패키지 리포지토리에 연결하기 위한 지침을 볼 수 있습니다.

**Contents**
+ [CodeCatalyst에서 종속성 가져오기](#gradle-fetch-dependencies)
+ [CodeCatalyst에서 플러그인 가져오기](#gradle-fetch-plugins)
+ [CodeCatalyst를 통해 외부 패키지 리포지토리에서 패키지 가져오기](#gradle-install-public)
+ [CodeCatalyst에 패키지 게시](#gradle-publish-packages)
+ [IntelliJ IDEA에서 Gradle 빌드 실행](#gradle-intellij)
  + [방법 1: PAT를 `gradle.properties`에 넣기](#gradle-intellij-gradle-properties)
  + [방법 2: PAT를 별도의 파일에 넣기](#gradle-intellij-file)

## CodeCatalyst에서 종속성 가져오기
<a name="gradle-fetch-dependencies"></a>

다음 지침에서는 CodeCatalyst 패키지 리포지토리의 종속성을 가져오도록 Gradle Groovy를 구성하는 방법을 설명합니다.

**Gradle Groovy를 사용하여 CodeCatalyst 패키지 리포지토리에서 종속성을 가져오려면**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.

1. 프로젝트로 이동합니다.

1. 탐색 창에서 **패키지**를 선택합니다.

1. 패키지 리포지토리 목록에서 패키지 리포지토리를 선택합니다.

1. **리포지토리에 연결**을 선택합니다.

1. **리포지토리에 연결** 대화 상자의 패키지 관리자 클라이언트 목록에서 **Gradle Groovy**를 선택합니다.

1. CodeCatalyst로 Gradle Groovy를 인증하려면 개인 액세스 토큰(PAT)이 필요합니다. 이미 토큰이 있으면 그 토큰을 사용하면 됩니다. 없는 경우에는 여기에서 만들 수 있습니다.

   1. **토큰 생성**을 선택합니다.

   1. PAT를 복사하려면 **복사**를 선택합니다.
**주의**  
대화 상자를 닫으면 PAT를 다시 보거나 복사할 수 없습니다.

1. gradle 속성 파일을 액세스 자격 증명으로 업데이트합니다. *username*을 CodeCatalyst 사용자 이름으로 바꾸고 *PAT*를 자신의 CodeCatalyst 개인 액세스 토큰으로 바꿉니다. 다음 단계에서 동일한 값을 사용하는 한 *spaceUsername* 및 *spacePassword*에는 어떤 값이든 사용할 수 있습니다.

   ```
   spaceUsername=username
   spacePassword=PAT
   ```

1. Gradle 빌드의 CodeCatalyst에서 종속성을 가져오려면 `maven` 코드 조각을 복사하여 프로젝트 `build.gradle` 파일의 `repositories` 섹션에 추가합니다. 다음 값을 교체합니다. 다음 단계에서 동일한 값을 사용하는 한 *spaceName*에는 어떤 값이든 사용할 수 있습니다.
**참고**  
콘솔 지침에서 복사하는 경우 다음 값을 업데이트해야 하며 변경해서는 안 됩니다.
   + *space\$1name*을 CodeCatalyst 스페이스 이름으로 바꿉니다.
   + *proj\$1name*을 CodeCatalyst 프로젝트 이름으로 바꿉니다.
   + *my\$1repo*를 CodeCatalyst 패키지 리포지토리 이름으로 바꿉니다.

   ```
   maven {
     name = 'spaceName'
     url = uri('https://packages.region.codecatalyst.aws/maven/space_name/proj_name/repo_name/')
     credentials(PasswordCredentials)
   }
   ```

1. (선택 사항) - CodeCatalyst 패키지 리포지토리를 프로젝트 종속성의 유일한 소스로 사용하려면 `build.gradle` 파일에서 리포지토리의 다른 섹션을 모두 제거합니다. 리포지토리가 두 개 이상인 경우, Gradle은 나열된 순서대로 각 리포지토리에서 종속성을 검색합니다.

## CodeCatalyst에서 플러그인 가져오기
<a name="gradle-fetch-plugins"></a>

기본적으로 Gradle은 퍼블릭 [Gradle 플러그인 포털](https://plugins.gradle.org/)에서 플러그인을 확인합니다. 다음 단계에서는 CodeCatalyst 패키지 리포지토리의 플러그인을 확인하도록 Gradle 프로젝트를 구성합니다.

**Gradle을 사용하여 CodeCatalyst 패키지 리포지토리에서 플러그인을 가져오려면**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.

1. 프로젝트로 이동합니다.

1. 탐색 창에서 **패키지**를 선택합니다.

1. 패키지 리포지토리 목록에서 패키지 리포지토리를 선택합니다.

1. **리포지토리에 연결**을 선택합니다.

1. **리포지토리에 연결** 대화 상자의 패키지 관리자 클라이언트 목록에서 **Gradle**을 선택합니다.

1. CodeCatalyst로 Gradle을 인증하려면 개인 액세스 토큰(PAT)이 필요합니다. 이미 토큰이 있으면 그 토큰을 사용하면 됩니다. 없는 경우에는 여기에서 만들 수 있습니다.

   1. **토큰 생성**을 선택합니다.

   1. PAT를 복사하려면 **복사**를 선택합니다.
**주의**  
대화 상자를 닫으면 PAT를 다시 보거나 복사할 수 없습니다.

1. gradle 속성 파일을 액세스 자격 증명으로 업데이트합니다. *username*을 CodeCatalyst 사용자 이름으로 바꾸고 *PAT*를 자신의 CodeCatalyst 개인 액세스 토큰으로 바꿉니다. 다음 단계에서 동일한 값을 사용하는 한 *spaceUsername* 및 *spacePassword*에는 어떤 값이든 사용할 수 있습니다.

   ```
   spaceUsername=username
   spacePassword=PAT
   ```

1. `settings.gradle` 파일에 `pluginManagement` 블록을 추가합니다. `pluginManagement` 블록은 `settings.gradle`에서 명령문 중에 가장 앞에 나타나야 합니다. 다음 값을 교체합니다.
**참고**  
콘솔 지침에서 복사하는 경우 다음 값을 업데이트해야 하며 변경해서는 안 됩니다.
   + *spaceName*을 이전 단계에서 사용한 이름 값으로 바꿉니다.
   + *space\$1name*을 CodeCatalyst 스페이스 이름으로 바꿉니다.
   + *proj\$1name*을 CodeCatalyst 프로젝트 이름으로 바꿉니다.
   + *my\$1repo*를 CodeCatalyst 패키지 리포지토리 이름으로 바꿉니다.

   ```
   pluginManagement {
       repositories {
           maven {
               name = 'spaceName'
               url = uri('https://packages.region.codecatalyst.aws/maven/space_name/proj_name/repo_name/')
               credentials(PasswordCredentials)
           }
       }
   }
   ```

   이렇게 하면 Gradle이 지정된 리포지토리의 플러그인을 확인할 수 있습니다. 일반적으로 필요한 Gradle 플러그인을 빌드에서 사용할 수 있도록 이 리포지토리에는 Gradle 플러그인 포털(`gradle-plugins-store`)에 대해 구성된 업스트림 연결이 있어야 합니다. 자세한 내용은 [Gradle 설명서](https://docs.gradle.org/current/userguide/plugins.html#sec:custom_plugin_repositories)를 참조하세요.

## CodeCatalyst를 통해 외부 패키지 리포지토리에서 패키지 가져오기
<a name="gradle-install-public"></a>

게이트웨이 리포지토리를 나타내는 게이트웨이에 대한 업스트림 연결로 구성하여 CodeCatalyst 리포지토리를 통해 퍼블릭 리포지토리에서 Maven 패키지를 설치할 수 있습니다. 게이트웨이 리포지토리에서 설치된 패키지는 수집되어 CodeCatalyst 리포지토리에 저장됩니다.

CodeCatalyst는 다음과 같은 퍼블릭 Maven 패키지 리포지토리를 지원합니다.
+ maven-central-gateway
+ google-android-gateway
+ gradle-plugins-gateway
+ commonsware-gateway

**퍼블릭 Maven 패키지 리포지토리에서 패키지를 설치하려면**

1. 아직 구성하지 않은 경우, [CodeCatalyst에서 종속성 가져오기](#gradle-fetch-dependencies) 또는[CodeCatalyst에서 플러그인 가져오기](#gradle-fetch-plugins)의 단계를 따라 CodeCatalyst 패키지 리포지토리로 Gradle을 구성합니다.

1. 리포지토리에 설치하려는 게이트웨이 리포지토리가 업스트림 연결로 추가되었는지 확인합니다. [업스트림 리포지토리 추가](packages-upstream-repositories-add.md)의 지침을 따라 업스트림으로 추가하려는 퍼블릭 패키지 리포지토리를 선택하여 이 작업을 수행할 수 있습니다.

업스트림 리포지토리에서 패키지를 요청하는 방법에 대한 자세한 내용은 [업스트림 리포지토리가 포함된 패키지 버전 요청](packages-upstream-repositories-request.md) 섹션을 참조하세요.

## CodeCatalyst에 패키지 게시
<a name="gradle-publish-packages"></a>

이 섹션에서는 Gradle Groovy로 빌드한 Java 라이브러리를 CodeCatalyst 리포지토리에 게시하는 방법을 설명합니다.

**Gradle Groovy를 사용하여 패키지를 CodeCatalyst 패키지 리포지토리에 게시하려면**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.

1. 프로젝트의 개요 페이지에서 **패키지**를 선택합니다.

1. 패키지 리포지토리 목록에서 패키지 리포지토리를 선택합니다.

1. **리포지토리에 연결**을 선택합니다.

1. **리포지토리에 연결** 대화 상자의 패키지 관리자 클라이언트 목록에서 **Gradle Groovy**를 선택합니다.

1. CodeCatalyst로 Gradle을 인증하려면 개인 액세스 토큰(PAT)이 필요합니다. 이미 토큰이 있으면 그 토큰을 사용하면 됩니다. 없는 경우에는 여기에서 만들 수 있습니다.

   1. **토큰 생성**을 선택합니다.

   1. PAT를 복사하려면 **복사**를 선택합니다.
**주의**  
대화 상자를 닫으면 PAT를 다시 보거나 복사할 수 없습니다.

1. gradle 속성 파일을 액세스 자격 증명으로 업데이트합니다. *username*을 CodeCatalyst 사용자 이름으로 바꾸고 *PAT*를 자신의 CodeCatalyst 개인 액세스 토큰으로 바꿉니다. 다음 단계에서 동일한 값을 사용하는 한 *spaceUsername* 및 *spacePassword*에는 어떤 값이든 사용할 수 있습니다.

   ```
   spaceUsername=username
   spacePassword=PAT
   ```

1. 프로젝트의 `build.gradle` 파일 중 `plugins` 섹션에 `maven-publish` 플러그인을 추가합니다.

   ```
   plugins {
       id 'java-library'
       id 'maven-publish'
   }
   ```

1. 다음으로 프로젝트 `build.gradle` 파일에 `publishing` 섹션을 추가합니다. 다음 값을 교체합니다.
**참고**  
콘솔 지침에서 복사하는 경우 다음 값을 업데이트해야 하며 변경해서는 안 됩니다.
   + *space\$1name*을 CodeCatalyst 스페이스 이름으로 바꿉니다.
   + *proj\$1name*을 CodeCatalyst 프로젝트 이름으로 바꿉니다.
   + *my\$1repo*를 CodeCatalyst 패키지 리포지토리 이름으로 바꿉니다.

   ```
   publishing {
       publications {
           mavenJava(MavenPublication) {
               groupId = 'group-id'
               artifactId = 'artifact-id'
               version = 'version'
               from components.java
           }
       }
       repositories {
           maven {
               name = 'spaceName'
               url = uri('https://packages.region.codecatalyst.aws/maven/space_name/proj_name/repo_name/')
               credentials(PasswordCredentials)
           }
       }
   }
   ```

   `maven-publish` 플러그인은 `publishing` 섹션에 지정된 `groupId`, `artifactId`, `version`을 기반으로 POM 파일을 생성합니다.

1. `build.gradle`에 대한 이러한 변경이 완료되면 다음 명령을 실행하여 프로젝트를 빌드하여 리포지토리에 업로드합니다.

   ```
   ./gradlew publish
   ```

1. CodeCatalyst 콘솔에서 패키지 리포지토리로 이동하여 패키지가 성공적으로 게시되었는지 확인합니다. 패키지 리포지토리의 **패키지** 목록에 패키지가 표시되어야 합니다.

자세한 내용은 Gradle 웹 사이트에서 이 주제를 참조하세요.
+  [Java 라이브러리 빌드](https://guides.gradle.org/building-java-libraries/) 
+  [프로젝트를 모듈로 게시](https://docs.gradle.org/current/userguide/publishing_setup.html) 

## IntelliJ IDEA에서 Gradle 빌드 실행
<a name="gradle-intellij"></a>

CodeCatalyst에서 종속성을 가져오는 IntelliJ IDEA에서 Gradle 빌드를 실행할 수 있습니다. CodeCatalyst로 Gradle을 인증하려면 개인 액세스 토큰(PAT)을 사용해야 합니다. `gradle.properties` 또는 선택한 별도의 파일에 CodeCatalyst PAT를 저장할 수 있습니다.

### 방법 1: PAT를 `gradle.properties`에 넣기
<a name="gradle-intellij-gradle-properties"></a>

`gradle.properties` 파일을 사용하지 않고 PAT로 내용을 덮어쓸 수 있는 경우 이 방법을 사용합니다. `gradle.properties`를 사용하는 경우 파일의 내용을 덮어쓰는 대신 이 방법을 수정하여 PAT를 추가할 수 있습니다.

**참고**  
예시는 `GRADLE_USER_HOME`에 있는 `gradle.properties` 파일을 보여줍니다.

먼저 PAT가 없는 경우 PAT를 생성합니다.

**개인용 액세스 토큰(PAT)을 만들려면**

1. 상단 메뉴 바에서 프로파일 배지를 선택한 다음 **내 설정**을 선택합니다.
**작은 정보**  
프로젝트 또는 스페이스의 멤버 페이지로 이동하고 멤버 목록에서 이름을 선택하여 자신의 사용자 프로파일을 찾을 수도 있습니다.

1. **PAT 이름**에 PAT를 설명하는 이름을 입력합니다.

1. **만료 날짜**에 기본 날짜를 유지하거나 달력 아이콘을 선택하여 사용자 지정 날짜를 선택합니다. 만료 날짜는 기본적으로 현재 날짜로부터 1년 후입니다.

1. **생성**을 선택합니다.

   소스 리포지토리의 **복제 리포지토리**를 선택할 때도 이 토큰을 생성할 수 있습니다.

1. PAT 보안 암호를 안전한 위치에 저장합니다.
**중요**  
PAT 보안 암호는 한 번만 표시됩니다. 창을 닫은 후에는 검색할 수 없습니다.

다음 코드 조각을 사용하여 `build.gradle` 파일을 업데이트합니다.

```
repositories {
    maven {
        name = 'spaceName'
        url = uri('https://packages.region.codecatalyst.aws/maven/space_name/proj_name/repo_name/')
        credentials(PasswordCredentials)
    }
}
```

### 방법 2: PAT를 별도의 파일에 넣기
<a name="gradle-intellij-file"></a>

`gradle.properties` 파일을 수정하지 않으려면 이 방법을 사용하세요.

먼저 PAT가 없는 경우 PAT를 생성합니다.

**개인용 액세스 토큰(PAT)을 만들려면**

1. 상단 메뉴 바에서 프로파일 배지를 선택한 다음 **내 설정**을 선택합니다.
**작은 정보**  
프로젝트 또는 스페이스의 멤버 페이지로 이동하고 멤버 목록에서 이름을 선택하여 자신의 사용자 프로파일을 찾을 수도 있습니다.

1. **PAT 이름**에 PAT를 설명하는 이름을 입력합니다.

1. **만료 날짜**에 기본 날짜를 유지하거나 달력 아이콘을 선택하여 사용자 지정 날짜를 선택합니다. 만료 날짜는 기본적으로 현재 날짜로부터 1년 후입니다.

1. **생성**을 선택합니다.

   소스 리포지토리의 **복제 리포지토리**를 선택할 때도 이 토큰을 생성할 수 있습니다.

1. PAT 보안 암호를 안전한 위치에 저장합니다.
**중요**  
PAT 보안 암호는 한 번만 표시됩니다. 창을 닫은 후에는 검색할 수 없습니다.

**PAT를 별도의 파일에 배치하려면**

1. 다음 코드 조각을 사용하여 `build.gradle` 파일을 업데이트합니다. *space\$1name*, *proj\$1name*, *repo\$1name*을 자신의 CodeCatalyst 사용자 이름, 스페이스 이름, 프로젝트 이름, 패키지 리포지토리 이름으로 바꿉니다.

   ```
   def props = new Properties()
   file("fileName").withInputStream { props.load(it) }
                     
   repositories {
           maven {
               name = 'spaceName'
               url = uri('https://packages.region.codecatalyst.aws/maven/space_name/proj_name/repo_name/')
               credentials(PasswordCredentials)
           }
       }
   }
   ```

1. `build.gradle` 파일에 지정된 파일에 PAT를 작성합니다.

   ```
   echo "codecatalystArtifactsToken=PAT" > fileName
   ```

# mvn 구성 및 사용
<a name="packages-maven-mvn"></a>

`mvn` 명령을 사용하여 Maven 빌드를 실행합니다. 패키지 리포지토리를 사용하고 인증을 위한 개인 액세스 토큰(PAT)을 제공하도록 `mvn`을 구성해야 합니다.

**Contents**
+ [CodeCatalyst에서 종속성 가져오기](#mvn-fetch-dependencies)
+ [CodeCatalyst를 통해 외부 패키지 리포지토리에서 패키지 가져오기](#mvn-install-public)
+ [CodeCatalyst에 패키지 게시](#mvn-publish-packages)
+ [타사 패키지 게시](#publishing-third-party-packages)

## CodeCatalyst에서 종속성 가져오기
<a name="mvn-fetch-dependencies"></a>

CodeCatalyst 리포지토리에서 종속성을 가져오도록 `mvn`을 구성하려면 Maven 구성 파일, `settings.xml` 및 프로젝트 객체 모델(POM) 파일을 편집해야 합니다. POM 파일에는 종속성, 빌드 디렉터리, 소스 디렉터리, 테스트 소스 디렉터리, 플러그인 및 목표와 같이 Maven이 프로젝트를 빌드하기 위한 프로젝트 및 구성 정보에 대한 정보가 포함되어 있습니다.

**`mvn`을 사용하여 CodeCatalyst 패키지 리포지토리에서 종속성을 가져오는 방법**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.

1. 프로젝트의 개요 페이지에서 **패키지**를 선택합니다.

1. 패키지 리포지토리 목록에서 패키지 리포지토리를 선택합니다.

1. **리포지토리에 연결**을 선택합니다.

1. **리포지토리에 연결** 대화 상자의 패키지 관리자 클라이언트 목록에서 **mvn**을 선택합니다.

1. `mvn`을 CodeCatalyst 로 인증하려면 개인 액세스 토큰(PAT)이 필요합니다. 이미 토큰이 있으면 그 토큰을 사용하면 됩니다. 없는 경우에는 여기에서 만들 수 있습니다.

   1. **토큰 생성**을 선택합니다.

   1. PAT를 복사하려면 **복사**를 선택합니다.
**주의**  
대화 상자를 닫으면 PAT를 다시 보거나 복사할 수 없습니다.

1. 리포지토리가 포함된 프로파일을 `settings.xml` 파일에 추가합니다. 다음 값을 교체합니다.
**참고**  
콘솔 지침에서 복사하는 경우 다음 값을 업데이트해야 하며 변경해서는 안 됩니다.
   + *space\$1name*을 CodeCatalyst 스페이스 이름으로 바꿉니다.
   + *proj\$1name*을 CodeCatalyst 프로젝트 이름으로 바꿉니다.
   + *my\$1repo*를 CodeCatalyst 패키지 리포지토리 이름으로 바꿉니다.

   ```
   <profiles>
     <profile>
       <id>repo_name</id>
       <activation>
           <activeByDefault>true</activeByDefault>
       </activation>
       <repositories>
           <repository>
             <id>repo_name</id>
             <url>https://packages.region.codecatalyst.aws/maven/space_name/proj_name/repo_name/</url>
           </repository>
       </repositories>
     </profile>
   </profiles>
   ```

1. `settings.xml` 파일의 서버 목록에 서버를 추가합니다. 다음 값을 교체합니다.
**참고**  
콘솔 지침에서 복사하는 경우 다음 값을 업데이트해야 하며 변경해서는 안 됩니다.
   + *my\$1repo*를 CodeCatalyst 패키지 리포지토리 이름으로 바꿉니다.
   + *username*을 CodeCatalyst 사용자 이름으로 바꿉니다.
   + *PAT*를 CodeCatalyst PAT로 바꿉니다.

   ```
   <servers>
     <server>
       <id>repo_name</id>
       <username>username</username>
       <password>PAT</password>
     </server>
   </servers>
   ```

1. (선택 사항) 모든 연결을 캡처하여 게이트웨이 리포지토리 대신 리포지토리로 라우팅하는 미러를 `settings.xml` 파일에 설정합니다.
**참고**  
콘솔 지침에서 복사하는 경우 다음 값을 업데이트해야 하며 변경해서는 안 됩니다.
   + *space\$1name*을 CodeCatalyst 스페이스 이름으로 바꿉니다.
   + *proj\$1name*을 CodeCatalyst 프로젝트 이름으로 바꿉니다.
   + *my\$1repo*를 CodeCatalyst 패키지 리포지토리 이름으로 바꿉니다.

   ```
   <mirrors>
     <mirror>
       <id>repo_name</id>
       <name>repo_name</name>
       <url>https://packages.region.codecatalyst.aws/maven/space_name/proj_name/repo_name/</url>
       <mirrorOf>*</mirrorOf>
     </mirror>
   </mirrors>
   ```

**중요**  
`<id>` 요소에서 어떤 값이든 사용할 수 있지만 그 값은 `<server>` 및 `<repository>` 요소에서 모두 동일해야 합니다. 이렇게 하면 지정된 자격 증명을 CodeCatalyst에 대한 요청에 포함할 수 있습니다.

이러한 구성을 변경한 후 프로젝트를 빌드할 수 있습니다.

```
mvn compile
```

## CodeCatalyst를 통해 외부 패키지 리포지토리에서 패키지 가져오기
<a name="mvn-install-public"></a>

게이트웨이 리포지토리를 나타내는 게이트웨이에 대한 업스트림 연결로 구성하여 CodeCatalyst 리포지토리를 통해 퍼블릭 리포지토리에서 Maven 패키지를 설치할 수 있습니다. 게이트웨이 리포지토리에서 설치된 패키지는 수집되어 CodeCatalyst 리포지토리에 저장됩니다.

현재 CodeCatalyst는 다음과 같은 퍼블릭 Maven 패키지 리포지토리를 지원합니다.
+ maven-central-gateway
+ google-android-gateway
+ gradle-plugins-gateway
+ commonsware-gateway

**퍼블릭 Maven 패키지 리포지토리에서 패키지를 설치하려면**

1. 아직 `mvn`을 구성하지 않았다면 [CodeCatalyst에서 종속성 가져오기](#mvn-fetch-dependencies)의 단계에 따라 CodeCatalyst 패키지 리포지토리로 구성합니다.

1. 리포지토리가 설치하려는 게이트웨이 리포지토리를 업스트림 연결로 추가했는지 확인합니다. 추가되는 업스트림 소스를 확인하거나 게이트웨이 리포지토리를 업스트림 소스로 추가하려면 [업스트림 리포지토리 추가](packages-upstream-repositories-add.md)의 지침을 따르세요.

업스트림 리포지토리에서 패키지를 요청하는 방법에 대한 자세한 내용은 [업스트림 리포지토리가 포함된 패키지 버전 요청](packages-upstream-repositories-request.md) 섹션을 참조하세요.

## CodeCatalyst에 패키지 게시
<a name="mvn-publish-packages"></a>

`mvn`과 함께 Maven 패키지를 CodeCatalyst 리포지토리에 게시하려면 `~/.m2/settings.xml` 및 프로젝트 POM도 편집해야 합니다.

**`mvn`을 사용하여 CodeCatalyst 패키지 리포지토리에 패키지를 게시하려면**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.

1. 프로젝트의 개요 페이지에서 **패키지**를 선택합니다.

1. 패키지 리포지토리 목록에서 패키지 리포지토리를 선택합니다.

1. **리포지토리에 연결**을 선택합니다.

1. **리포지토리에 연결** 대화 상자의 패키지 관리자 클라이언트 목록에서 **mvn**을 선택합니다.

1. `mvn`을 CodeCatalyst 로 인증하려면 개인 액세스 토큰(PAT)이 필요합니다. 이미 토큰이 있으면 그 토큰을 사용하면 됩니다. 없는 경우에는 여기에서 만들 수 있습니다.

   1. **토큰 생성**을 선택합니다.

   1. PAT를 복사하려면 **복사**를 선택합니다.
**주의**  
대화 상자를 닫으면 PAT를 다시 보거나 복사할 수 없습니다.

1. PAT를 사용하여 로컬 시스템에서 환경 변수를 구성합니다. `setting.xml` 파일에서 이 환경 변수를 사용합니다.

   ```
   export CODECATALYST_ARTIFACTS_TOKEN=your_PAT
   ```

1. Maven이 HTTP 요청에서 토큰을 전달하도록 `<servers>` 섹션을 `CodeCatalyst_ARTIFACTS_TOKEN` 환경 변수에 대한 참조가 있는 `settings.xml`에 추가합니다.

   ```
   <settings>
   ...
       <servers>
           <server>
               <id>repo-name</id>
               <username>username</username>
               <password>${env.CodeCatalyst_ARTIFACTS_TOKEN}</password>
           </server>
       </servers>
   ...
   </settings>
   ```

1. 프로젝트의 `pom.xml`에 `<distributionManagement>` 섹션을 추가합니다.

   ```
   <project>
   ...
        <distributionManagement>
            <repository>
                <id>repo_name</id>
                <name>repo_name</name>
                <url>https://packages.region.codecatalyst.aws/maven/space_name/proj_name/repo_name/</url>
            </repository>
        </distributionManagement>
   ...
   </project>
   ```

이러한 구성을 변경한 후 프로젝트를 빌드하여 지정된 리포지토리에 게시할 수 있습니다.

```
mvn deploy
```

CodeCatalyst 콘솔에서 패키지 리포지토리로 이동하여 패키지가 성공적으로 게시되었는지 확인할 수 있습니다.

## 타사 패키지 게시
<a name="publishing-third-party-packages"></a>

`mvn deploy:deploy-file`을 사용하여 타사 Maven 패키지를 CodeCatalyst 리포지토리에 게시할 수 있습니다. 이는 JAR 파일만 가지고 있고 패키지 소스 코드나 POM 파일에는 액세스할 수 없는 사용자가 패키지를 게시하려고 할 때 도움이 될 수 있습니다.

이 `mvn deploy:deploy-file` 명령을 실행하면 명령줄에 전달된 정보를 기반으로 POM 파일이 생성됩니다.

먼저 PAT가 없는 경우 PAT를 생성합니다.

**개인용 액세스 토큰(PAT)을 만들려면**

1. 상단 메뉴 바에서 프로파일 배지를 선택한 다음 **내 설정**을 선택합니다.
**작은 정보**  
프로젝트 또는 스페이스의 멤버 페이지로 이동하고 멤버 목록에서 이름을 선택하여 자신의 사용자 프로파일을 찾을 수도 있습니다.

1. **PAT 이름**에 PAT를 설명하는 이름을 입력합니다.

1. **만료 날짜**에 기본 날짜를 유지하거나 달력 아이콘을 선택하여 사용자 지정 날짜를 선택합니다. 만료 날짜는 기본적으로 현재 날짜로부터 1년 후입니다.

1. **생성**을 선택합니다.

   소스 리포지토리의 **복제 리포지토리**를 선택할 때도 이 토큰을 생성할 수 있습니다.

1. PAT 보안 암호를 안전한 위치에 저장합니다.
**중요**  
PAT 보안 암호는 한 번만 표시됩니다. 창을 닫은 후에는 검색할 수 없습니다.

**타사 Maven 패키지를 게시하려면**

1. 다음 콘텐츠가 포함된 `~/.m2/settings.xml` 파일을 생성합니다.

   ```
   <settings>
       <servers>
           <server>
               <id>repo_name</id>
               <username>username</username>
               <password>PAT}</password>
           </server>
       </servers>
   </settings>
   ```

1. `mvn deploy:deploy-file` 명령을 실행합니다.

   ```
   mvn deploy:deploy-file -DgroupId=commons-cli          \
   -DartifactId=commons-cli       \
   -Dversion=1.4                  \
   -Dfile=./commons-cli-1.4.jar   \
   -Dpackaging=jar                \
   -DrepositoryId=repo-name      \
   -Durl=https://packages.region.codecatalyst.aws/maven/space-name/proj-name/repo-name/
   ```
**참고**  
앞의 예에서는 `commons-cli 1.4`를 게시합니다. groupId, artifactID, 버전 및 파일 인수를 수정하여 다른 JAR을 게시합니다.

이 지침은 **Apache Maven 설명서의 [타사 JAR을 원격 리포지토리에 배포하기 위한 가이드](https://maven.apache.org/guides/mini/guide-3rd-party-jars-remote.html)의 예시를 기반으로 합니다.

 자세한 내용은 Apache Maven Project 웹 사이트에서 다음 주제를 참조하세요.
+  [여러 리포지토리 설정](https://maven.apache.org/guides/mini/guide-multiple-repositories.html) 
+  [설정 참조](https://maven.apache.org/settings.html) 
+  [배포 관리](https://maven.apache.org/pom.html#Distribution_Management) 
+  [프로파일](https://maven.apache.org/pom.html#Profiles) 

# curl을 사용하여 패키지 게시
<a name="packages-maven-curl"></a>

이 섹션에서는 HTTP 클라이언트 `curl`을 사용하여 CodeCatalyst 패키지 리포지토리에 Maven 패키지를 게시하는 방법을 보여줍니다. 환경에 Maven 클라이언트가 없거나 이 클라이언트를 설치하려는 경우, `curl`을 사용하여 패키지를 게시하는 것이 도움이 될 수 있습니다.

**`curl`을 사용하여 Maven 패키지를 게시하려면**

1. CodeCatalyst로 `curl`을 인증하려면 환경 변수에 개인 액세스 토큰(PAT)을 저장해야 합니다. 이미 토큰이 있으면 그 토큰을 사용하면 됩니다. 그렇지 않은 경우 토큰을 생성하고 환경 변수를 구성할 수 있습니다.

   1. [개인 액세스 토큰을 사용하여 사용자 리포지토리 액세스 권한 부여](ipa-tokens-keys.md)의 단계에 따라 PAT를 생성합니다. PAT를 복사하여 환경 변수에 저장합니다.

   1. 로컬 시스템의 명령줄에서 PAT로 환경 변수를 구성합니다.

      ```
      export CodeCatalyst_ARTIFACTS_TOKEN=your_PAT
      ```

1. 다음 `curl` 명령을 사용하여 JAR을 CodeCatalyst 리포지토리에 게시합니다. *username*, *space\$1name*, *proj\$1name*, *repo\$1name*을 CodeCatalyst 사용자 이름, 스페이스 이름, 프로젝트 이름, 패키지 리포지토리 이름으로 바꿉니다.

   ```
   curl --request PUT https://packages.region.codecatalyst.aws/maven/space-name/proj-name/repo-name/com/mycompany/app/my-app/1.0/my-app-1.0.jar \
        --user "username:CodeCatalyst_ARTIFACTS_TOKEN" --header "Content-Type: application/octet-stream" \
        --data-binary @target/path/to/my-app-1.0.jar
   ```

1. 다음 `curl` 명령을 사용하여 POM을 CodeCatalyst 리포지토리에 게시합니다. *username*, *space\$1name*, *proj\$1name*, *repo\$1name*을 CodeCatalyst 사용자 이름, 스페이스 이름, 프로젝트 이름, 패키지 리포지토리 이름으로 바꿉니다.

   ```
   curl --request PUT https://packages.region.codecatalyst.aws/maven/space-name/proj-name/repo-name/com/mycompany/app/my-app/1.0/my-app-1.0.pom \
        --user "username:CodeCatalyst_ARTIFACTS_TOKEN" --header "Content-Type: application/octet-stream" \
        --data-binary @target/my-app-1.0.pom
   ```

1. 이때 Maven 패키지는 상태가 `Unfinished`인 CodeCatalyst 리포지토리에 저장됩니다. 패키지를 사용하려면 패키지가 `Published` 상태에 있어야 합니다. 패키지에 `maven-metadata.xml` 파일을 업로드하거나 CodeCatalyst 콘솔에서 상태를 변경하여 패키지를 `Unfinished`에서 `Published`로 이동할 수 있습니다.

   1.  옵션 1: 다음 `curl` 명령을 사용하여 패키지에 `maven-metadata.xml` 파일을 추가합니다. *username*, *space\$1name*, *proj\$1name*, *repo\$1name*을 CodeCatalyst 사용자 이름, 스페이스 이름, 프로젝트 이름, 패키지 리포지토리 이름으로 바꿉니다.

      ```
      curl --request PUT https://packages.region.codecatalyst.aws/maven/space-name/proj-name/repo-name/com/mycompany/app/my-app/maven-metadata.xml \
           --user "username:CodeCatalyst_ARTIFACTS_TOKEN" --header "Content-Type: application/octet-stream" \
           --data-binary @target/maven-metadata.xml
      ```

      다음은 `maven-metadata.xml` 파일의 내용을 보여주는 예입니다.

      ```
      <metadata modelVersion="1.1.0">
          <groupId>com.mycompany.app</groupId>
          <artifactId>my-app</artifactId>
          <versioning>
              <latest>1.0</latest>
              <release>1.0</release>
              <versions>
                  <version>1.0</version>
              </versions>
              <lastUpdated>20200731090423</lastUpdated>
          </versioning>
      </metadata>
      ```

   1.  옵션 2: CodeCatalyst 콘솔에서 패키지 상태를 `Published`로 업데이트합니다. 패키지 버전의 상태를 업데이트하는 방법에 대한 자세한 내용은 [패키지 버전의 상태 업데이트](working-with-packages-update-version-status.md) 섹션을 참조하세요.

패키지의 JAR 파일만 있는 경우, `mvn`을 사용하여 CodeCatalyst 리포지토리에 사용 가능한 패키지 버전을 게시할 수 있습니다. 이는 패키지의 소스 코드나 POM에 액세스할 수 없는 경우에 도움이 될 수 있습니다. 세부 정보는 [타사 패키지 게시](packages-maven-mvn.md#publishing-third-party-packages) 섹션을 참조하세요.

# Maven 체크섬 및 스냅샷 사용
<a name="packages-maven-checksums-snapshots"></a>

다음 섹션에서는 CodeCatalyst에서 Maven 체크섬 및 Maven 스냅샷을 사용하는 방법을 설명합니다.

## Maven 체크섬 사용
<a name="maven-checksums"></a>

 Maven 패키지가 CodeCatalyst 패키지 리포지토리에 게시되면 패키지의 각 자산 또는 파일과 관련된 체크섬을 사용하여 업로드를 검증합니다. 자산의 예로는 **jar, **pom, **war 파일 등이 있습니다. 각 자산의 경우, `md5` 또는 `sha1` 같은 추가 확장자가 있는 자산 이름을 사용하는 여러 개의 체크섬 파일이 Maven 패키지에 포함되어 있습니다. 예를 들어, `my-maven-package.jar`라는 이름이 지정된 파일의 체크섬 파일은 `my-maven-package.jar.md5` 및 `my-maven-package.jar.sha1`일 수 있습니다.

 모든 Maven 패키지에는 `maven-metadata.xml` 파일도 포함되어 있습니다. 게시가 성공하려면 이 파일을 업로드해야 합니다. 패키지 파일을 업로드하는 동안 체크섬 불일치가 감지되면 게시가 중지됩니다. 이렇게 하면 `maven-metadata.xml`이 업로드되지 않을 수 있습니다. 이 경우 Maven 패키지의 상태가 `Unfinished`로 설정됩니다. 이 상태의 패키지 일부인 자산은 다운로드할 수 없습니다.

Maven 패키지를 게시할 때 체크섬 불일치가 발생하는 경우 다음 사항에 유의하세요.
+  `maven-metadata.xml`이 업로드되기 전에 체크섬 불일치가 발생하면 패키지의 상태가 `Unfinished`로 설정되지 않습니다. 패키지가 표시되지 않으며 해당 자산을 사용할 수 없습니다. 이 경우 다음 중 하나를 시도한 다음 자산을 다시 다운로드해 보세요.
  + Maven 패키지를 다시 게시하는 명령을 실행합니다. 다운로드를 하는 동안 네트워크 문제로 인해 체크섬 파일이 손상된 경우, 이러한 명령 실행이 효과적일 수 있습니다. 다시 시도하여 네트워크 문제가 해결되면 체크섬이 일치하여 다운로드가 완료됩니다.
  +  Maven 패키지를 다시 게시할 수 없는 경우 해당 패키지를 삭제한 다음 다시 게시합니다.
+  `maven-metadata.xml`이 업로드된 후 체크섬 불일치가 발생하면 패키지 상태가 `Published`로 설정됩니다. 체크섬 불일치가 있는 자산을 포함하여 패키지의 모든 자산을 사용할 수 있습니다. 자산을 다운로드하면 CodeCatalyst에서 생성한 체크섬이 함께 다운로드됩니다. 다운로드한 파일이 체크섬 불일치와 연결된 경우 다운로드한 체크섬 파일이 패키지가 게시될 때 업로드된 체크섬과 일치하지 않을 수 있습니다.

## Maven 스냅샷 사용
<a name="maven-snapshots"></a>

 Maven **스냅샷은 최신 프로덕션 브랜치 코드를 참조하는 Maven 패키지의 특수 버전입니다. 이 스냅샷은 최종 릴리스 버전보다 앞서는 개발 버전입니다. 패키지 버전에 추가된 접미사 `SNAPSHOT`으로 Maven 패키지의 스냅샷 버전을 식별할 수 있습니다. 예를 들어, 버전 `1.1`의 스냅샷은 `1.1-SNAPSHOT`입니다. 자세한 내용은 Apache Maven 프로젝트 웹사이트에서 [SNAPSHOT 버전이란 무엇입니까?](https://maven.apache.org/guides/getting-started/index.html#What_is_a_SNAPSHOT_version)를 참조하세요.

 CodeCatalyst는 Maven 스냅샷 게시 및 사용을 지원합니다. Maven 스냅샷을 CodeCatalyst 리포지토리에 게시하거나, 직접 연결된 경우 업스트림 리포지토리에 게시할 수 있습니다. 그러나 업스트림 리포지토리 중 하나와 패키지 리포지토리에서 모두 스냅샷 버전은 지원되지는 않습니다. 예를 들어, 버전이 `1.2-SNAPSHOT`인 Maven 패키지를 패키지 리포지토리에 업로드하는 경우, CodeCatalyst는 동일한 스냅샷 버전이 있는 Maven 패키지를 업스트림 리포지토리 중 하나에 업로드하는 것을 지원하지 않습니다. 이 시나리오는 예측할 수 없는 결과를 반환할 수 있습니다.

 Maven 스냅샷이 게시되면 이전 버전이 *빌드*라는 새 버전에 보존됩니다. Maven 스냅샷이 게시될 때마다 새 빌드 버전이 생성됩니다. 스냅샷의 모든 이전 버전은 빌드 버전에서 유지 관리됩니다. Maven 스냅샷이 게시되면 상태가 `Published`로 설정되고 이전 버전이 포함된 빌드의 상태가 `Unlisted`로 설정됩니다.

 스냅샷을 요청하면 상태 `Published`의 버전이 반환됩니다. 이 버전은 항상 Maven 스냅샷의 최신 버전입니다. 스냅샷의 특정 빌드를 요청할 수도 있습니다.

Maven 스냅샷의 모든 빌드 버전을 삭제하려면 CodeCatalyst 콘솔을 사용합니다.

# NuGet 사용
<a name="packages-nuget"></a>

이 항목에서는 CodeCatalyst를 사용하여 `NuGet` 패키지를 사용하고 게시하는 방법을 설명합니다.

**참고**  
CodeCatalyst는 [NuGet 버전 4.8](https://docs.microsoft.com/en-us/nuget/release-notes/nuget-4.8-rtm) 이상을 지원합니다.

**Topics**
+ [Visual Studio에서 CodeCatalyst 사용](packages-nuget-visual-studio.md)
+ [nuget 또는 dotnet CLI 구성 및 사용](packages-nuget-cli.md)
+ [NuGet 패키지 이름, 버전 및 자산 이름 표준화](nuget-name-normalization.md)
+ [NuGet 호환성](packages-nuget-compatibility.md)

# Visual Studio에서 CodeCatalyst 사용
<a name="packages-nuget-visual-studio"></a>

 Visual Studio에서 직접 CodeCatalyst의 패키지를 사용할 수 있습니다.

NuGet을 `dotnet` 또는 `nuget`과 같은 CLI 도구와 함께 구성하고 사용하려면 [nuget 또는 dotnet CLI 구성 및 사용](packages-nuget-cli.md) 섹션을 참조하세요.

**Contents**
+ [CodeCatalyst로 Visual Studio 구성](#packages-nuget-vs-configure)
  + [Windows](#packages-nuget-vs-configure-windows)
  + [macOS](#packages-nuget-vs-configure-mac)

## CodeCatalyst로 Visual Studio 구성
<a name="packages-nuget-vs-configure"></a>

### Windows
<a name="packages-nuget-vs-configure-windows"></a>

**CodeCatalyst로 Visual Studio를 구성하려면**

1. CodeCatalyst로 인증하려면 개인 액세스 토큰(PAT)이 필요합니다. 이미 토큰이 있으면 그 토큰을 사용하면 됩니다. 토큰이 없다면 [개인 액세스 토큰을 사용하여 사용자 리포지토리 액세스 권한 부여](ipa-tokens-keys.md)의 지침에 따라 토큰을 생성합니다.

1. `nuget` 또는 `dotnet`를 사용하여 패키지 리포지토리 및 자격 증명을 구성합니다.

------
#### [ dotnet ]

   **Linux 및 macOS 사용자:** Windows 이외의 플랫폼에서는 암호화를 지원하지 않으므로 다음 명령에 `--store-password-in-clear-text` 플래그를 추가해야 합니다. 단, 이렇게 하면 비밀번호가 구성 파일에 일반 텍스트로 저장됩니다.

   ```
   dotnet nuget add source https://packages.region.codecatalyst.aws/nuget/space-name/proj-name/repo-name/v3/index.json --name repo_name --password PAT --username user_name
   ```

------
#### [ nuget ]

   ```
   nuget sources add -name repo_name -Source https://packages.region.codecatalyst.aws/nuget/space-name/proj-name/repo-name/v3/index.json -password PAT --username user_name
   ```

------

   출력 예시:

   ```
   Package source with Name: repo_name added successfully.
   ```

1. 새 패키지 소스를 사용하도록 Visual Studio를 구성합니다. Visual Studio에서 **도구**를 선택한 다음 **옵션**을 선택합니다.

1. **옵션** 메뉴에서 **NuGet 패키지 관리자** 섹션을 확장하고 **패키지 소스**를 선택합니다.

1. **사용 가능한 패키지 소스** 목록에서 *repo\$1name* 소스가 활성화되어 있는지 확인합니다. NuGet Gallery에 대한 업스트림 연결로 패키지 리포지토리를 구성한 경우 **nuget.org** 소스를 비활성화합니다.

### macOS
<a name="packages-nuget-vs-configure-mac"></a>

**CodeCatalyst로 Visual Studio를 구성하려면**

1. CodeCatalyst로 인증하려면 개인 액세스 토큰(PAT)이 필요합니다. 이미 토큰이 있으면 그 토큰을 사용하면 됩니다. 토큰이 없다면 [개인 액세스 토큰을 사용하여 사용자 리포지토리 액세스 권한 부여](ipa-tokens-keys.md)의 지침에 따라 토큰을 생성합니다.

1. 메뉴 모음에서 **기본 설정**을 선택합니다.

1. **NuGet** 섹션에서 **소스**를 선택합니다.

1. **추가**를 선택하여 리포지토리 정보를 추가합니다.

   1. **이름**에 CodeCatalyst 패키지 리포지토리 이름을 입력합니다.

   1. **위치**에 CodeCatalyst 패키지 리포지토리 엔드포인트를 입력합니다. 다음 코드 조각은 엔드포인트의 예시를 보여줍니다. *space-name*, *proj-name*, *repo-name*을 CodeCatalyst 스페이스 이름, 프로젝트 이름, 리포지토리 이름으로 바꿉니다.

      ```
      https://packages.region.codecatalyst.aws/nuget/space-name/proj-name/repo-name/
      ```

   1. **사용자 이름**에 유효한 값을 입력합니다.

   1. **암호**에 PAT를 입력합니다.

1. **소스 추가**를 선택합니다.

1. NuGet Gallery에 대한 업스트림 연결로 패키지 리포지토리를 구성한 경우 **nuget.org** 소스를 비활성화합니다.

구성 후 Visual Studio는 CodeCatalyst 리포지토리, 모든 업스트림 리포지토리 또는 업스트림 소스로 구성한 경우 [NuGet.org](https://www.nuget.org/)의 패키지를 사용할 수 있습니다. Visual Studio에서 NuGet 패키지를 검색하고 설치하는 방법에 대한 자세한 내용은 *NuGet 설명서*의 [NuGet 패키지 관리자를 사용한 Visual Studio의 패키지 설치 및 관리](https://docs.microsoft.com/en-us/nuget/consume-packages/install-use-packages-visual-studio)를 참조하세요.

# nuget 또는 dotnet CLI 구성 및 사용
<a name="packages-nuget-cli"></a>

`NuGet` 및 `dotnet`와 같은 CLI 도구를 사용하여 CodeCatalyst에서 패키지를 게시하고 사용할 수 있습니다. 이 문서에서는 CLI 도구를 구성하고 이를 사용하여 패키지를 게시하거나 사용하는 방법에 관한 정보를 제공합니다.

**Contents**
+ [CodeCatalyst를 사용하여 NuGet 구성](#nuget-configure-cli)
+ [CodeCatalyst 리포지토리에서 NuGet 패키지 사용](#nuget-consume-cli)
+ [CodeCatalyst를 통해 NuGet.org에서 NuGet 패키지 사용](#nuget-consume-nuget-gallery)
+ [CodeCatalyst에 NuGet 패키지 게시](#nuget-publish-cli)

## CodeCatalyst를 사용하여 NuGet 구성
<a name="nuget-configure-cli"></a>

CodeCatalyst로 NuGet을 구성하려면 NuGet 구성 파일에 리포지토리 엔드포인트와 개인 액세스 토큰을 추가하여 CodeCatalyst 패키지 리포지토리에 `nuget` 또는 `dotnet`을 연결할 수 있도록 합니다.

**CodeCatalyst 패키지 리포지토리로 NuGet을 구성하려면**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.

1. 프로젝트의 개요 페이지에서 **패키지**를 선택합니다.

1. 패키지 리포지토리 목록에서 패키지 리포지토리를 선택합니다.

1. **리포지토리에 연결**을 선택합니다.

1. **리포지토리에 연결** 대화 상자의 패키지 관리자 클라이언트 목록에서 **NuGet** 또는 **dotnet**을 선택합니다.

1. CodeCatalyst로 NuGet을 인증하려면 개인 액세스 토큰(PAT)이 필요합니다. 이미 토큰이 있으면 그 토큰을 사용하면 됩니다. 없는 경우에는 여기에서 만들 수 있습니다.

   1. **토큰 생성**을 선택합니다.

   1. PAT를 복사하려면 **복사**를 선택합니다.
**주의**  
대화 상자를 닫으면 PAT를 다시 보거나 복사할 수 없습니다.

1. 리포지토리의 NuGet 엔드포인트 및 CodeCatalyst PAT를 사용하도록 `nuget` 또는 `dotnet`을 구성합니다. 다음 값을 교체합니다.
**참고**  
콘솔 지침에서 복사하는 경우 다음 값을 업데이트해야 하며 변경해서는 안 됩니다.
   + *username*을 CodeCatalyst 사용자 이름으로 바꿉니다.
   + *PAT*를 CodeCatalyst PAT로 바꿉니다.
   + *space\$1name*을 CodeCatalyst 스페이스 이름으로 바꿉니다.
   + *proj\$1name*을 CodeCatalyst 프로젝트 이름으로 바꿉니다.
   + *my\$1repo*를 CodeCatalyst 패키지 리포지토리 이름으로 바꿉니다.

   1. `nuget`에서 `nuget sources add` 명령을 사용합니다.

      ```
      nuget sources add -name "repo_name" -Source "https://packages.region.codecatalyst.aws/nuget/space_name/proj_name/repo_name/v3/index.json" -username "username" -password "PAT"
      ```

   1. `dotnet`에서 `dotnet nuget add source` 명령을 사용합니다.

      **Linux 및 macOS 사용자:** Windows 이외의 플랫폼에서는 암호화를 지원하지 않으므로 다음 명령에 `--store-password-in-clear-text` 플래그를 추가해야 합니다. 단, 이렇게 하면 비밀번호가 구성 파일에 일반 텍스트로 저장됩니다.

      ```
      dotnet nuget add source "https://packages.region.codecatalyst.aws/nuget/space_name/proj_name/repo_name/v3/index.json" -n "proj_name/repo_name" -u "username" -p "PAT" --store-password-in-clear-text
      ```

CodeCatalyst로 NuGet을 구성한 후에는 CodeCatalyst 리포지토리 또는 업스트림 리포지토리 중 하나에 저장된 [NuGet 패키지를 사용](#nuget-consume-cli)할 수 있고 CodeCatalyst 리포지토리로 [NuGet 패키지를 게시](#nuget-publish-cli)할 수 있습니다.

## CodeCatalyst 리포지토리에서 NuGet 패키지 사용
<a name="nuget-consume-cli"></a>

[CodeCatalyst로 NuGet을 구성](#nuget-configure-cli)한 후에는 CodeCatalyst 리포지토리 또는 업스트림 리포지토리 중 하나에 저장된 NuGet 패키지를 사용할 수 있습니다.

CodeCatalyst 리포지토리 또는 nuget 또는 dotnet이 있는 업스트림 리포지토리 중 하나에서 패키지 버전을 사용하려면 다음 명령을 실행합니다. *packageName*을 사용하려는 패키지 이름으로 바꾸고 *packageSourceName*을 NuGet 구성 파일의 CodeCatalyst 패키지 리포지토리 소스 이름으로 바꿉니다. 이 이름은 리포지토리 이름이어야 합니다.

**`dotnet`을 사용하여 패키지를 설치하려면**

```
dotnet add packageName --source packageSourceName
```

**`nuget`을 사용하여 패키지를 설치하려면**

```
nuget install packageName --source packageSourceName
```

자세한 내용은 *Microsoft 설명서*의 [nuget.exe CLI를 사용하여 패키지 관리](https://docs.microsoft.com/en-us/nuget/consume-packages/install-use-packages-nuget-cli) 또는 [dotnet CLI를 사용하여 패키지 설치 및 관리](https://docs.microsoft.com/en-us/nuget/consume-packages/install-use-packages-dotnet-cli)를 참조하세요.

## CodeCatalyst를 통해 NuGet.org에서 NuGet 패키지 사용
<a name="nuget-consume-nuget-gallery"></a>

**NuGet.org**에 대한 업스트림 연결을 통해 리포지토리를 구성하여 CodeCatalyst 리포지토리를 통해 [NuGet.org](https://www.nuget.org/)의 NuGet 패키지를 사용할 수 있습니다. **Nuget.org**에서 사용하는 패키지는 CodeCatalyst 리포지토리로 수집하여 저장됩니다.

**Nuget.org의 패키지를 사용하려면**

1. 아직 구성하지 않았다면 [CodeCatalyst를 사용하여 NuGet 구성](#nuget-configure-cli)의 단계에 따라 CodeCatalyst 패키지 리포지토리로 NuGet 패키지 관리자를 구성합니다.

1. 리포지토리가 **NuGet.org**를 업스트림 연결로 추가했는지 확인합니다. [업스트림 리포지토리 추가](packages-upstream-repositories-add.md)의 지침에 따르고 **NuGet 스토어** 리포지토리를 선택하여, 어떤 업스트림 소스가 추가되었는지 확인하거나 **Nuget.org**를 업스트림 소스로 추가할 수 있습니다.

## CodeCatalyst에 NuGet 패키지 게시
<a name="nuget-publish-cli"></a>

[CodeCatalyst로 NuGet을 구성](#nuget-configure-cli)한 후에는 `nuget` 또는 `dotnet`을 사용하여 CodeCatalyst 리포지토리에 패키지 버전을 게시할 수 있습니다.

패키지 버전을 CodeCatalyst 리포지토리로 불러오려면 NuGet 구성 파일에 `.nupkg` 파일의 전체 경로와 CodeCatalyst 리포지토리의 소스 이름을 포함하여 다음 명령을 실행합니다.

**`dotnet`를 사용하여 패키지를 게시하려면**

```
dotnet nuget push path/to/nupkg/SamplePackage.1.0.0.nupkg --source packageSourceName
```

**`nuget`를 사용하여 패키지를 게시하려면**

```
nuget push path/to/nupkg/SamplePackage.1.0.0.nupkg --source packageSourceName
```

# NuGet 패키지 이름, 버전 및 자산 이름 표준화
<a name="nuget-name-normalization"></a>

CodeCatalyst는 패키지 및 자산 이름과 패키지 버전을 저장하기 전에 표준화합니다. 즉, CodeCatalyst의 이름 또는 버전은 패키지 또는 자산이 게시될 때 제공된 것과 다를 수 있습니다.

**패키지 이름 표준화:** CodeCatalyst는 모든 문자를 소문자로 변환하여 NuGet 패키지 이름을 표준화합니다.

**패키지 버전 표준화:** CodeCatalyst는 NuGet과 동일한 패턴을 사용하여 NuGet 패키지 버전을 표준화합니다. 다음 정보는 NuGet 설명서의 [표준화된 버전 번호](https://docs.microsoft.com/en-us/nuget/concepts/package-versioning#normalized-version-numbers)에서 가져왔습니다.
+ 버전 번호에서 앞에 오는 0은 제거되었습니다.
  + `1.00`은 `1.0`으로 간주합니다.
  + `1.01.1`은 `1.1.1`으로 간주합니다.
  + `1.00.0.1`은 `1.0.0.1`으로 간주합니다.
+ 버전 번호의 네 번째 부분에 있는 0은 생략합니다.
  + `1.0.0.0`은 `1.0.0`으로 간주합니다.
  + `1.0.01.0`은 `1.0.1`으로 간주합니다.
+ SemVer 2.0.0 빌드 메타데이터가 제거되었습니다.
  + `1.0.7+r3456`은 `1.0.7`으로 간주합니다.

**패키지 에셋 이름 표준화:** CodeCatalyst는 표준화된 패키지 이름과 패키지 버전을 기반으로 NuGet 패키지 에셋 이름을 생성합니다.

# NuGet 호환성
<a name="packages-nuget-compatibility"></a>

 이 안내서에는 CodeCatalyst의 다양한 NuGet 도구 및 버전과의 호환성에 관한 정보가 포함되어 있습니다.

**Topics**
+ [일반 NuGet 호환성](#nuget-version-support)
+ [NuGet 명령줄 지원](#nuget-command-line-support)

## 일반 NuGet 호환성
<a name="nuget-version-support"></a>

CodeCatalyst는 NuGet 4.8 이상을 지원합니다.

CodeCatalyst는 NuGet HTTP 프로토콜의 V3만 지원합니다. 즉, 프로토콜의 V2를 사용하는 일부 CLI 명령은 지원하지 않습니다. 자세한 내용은 다음 [nuget 명령 지원](#nuget-command-support) 섹션을 참조하세요.

CodeCatalyst는 PowerShellGet 2.x를 지원하지 않습니다.

## NuGet 명령줄 지원
<a name="nuget-command-line-support"></a>

CodeCatalyst는 NuGet(`nuget`) 및 .NET Core(`dotnet`) CLI 도구를 지원합니다.

### nuget 명령 지원
<a name="nuget-command-support"></a>

CodeCatalyst는 NuGet HTTP 프로토콜 V3만 지원하므로 CodeCatalyst 리소스에 대해 다음 명령을 사용해도 작동하지 않습니다.
+ `list`: 이 `nuget list` 명령은 지정된 소스의 패키지 목록을 표시합니다. CodeCatalyst 패키지 리포지토리의 패키지 목록을 가져오려면 CodeCatalyst 콘솔에서 리포지토리로 이동합니다.

# Python 사용
<a name="packages-python"></a>

이 항목에서는 CodeCatalyst와 함께 Python 패키지 관리자인 `pip`, Python 패키지 게시 유틸리티인 `twine`을 사용하는 방법에 대해 설명합니다.

**Topics**
+ [pip 구성 및 Python 패키지 설치](packages-python-pip.md)
+ [Twine 구성 및 Python 패키지 게시](packages-python-twine.md)
+ [Python 패키지 이름 정규화](python-name-normalization.md)
+ [Python 호환성](packages-python-compatibility.md)

# pip 구성 및 Python 패키지 설치
<a name="packages-python-pip"></a>

`pip`을 CodeCatalyst와 함께 사용하려면 패키지 리포지토리에 `pip`를 연결하고 인증을 위한 개인 액세스 토큰을 제공해야 합니다. CodeCatalyst 콘솔에서 패키지 리포지토리에 `pip`을 연결하기 위한 지침을 볼 수 있습니다. `pip`을 CodeCatalyst에 인증하고 연결한 후 `pip` 명령을 실행할 수 있습니다.

**Contents**
+ [pip를 사용하여 CodeCatalyst에서 Python 패키지 설치](#pip-install)
+ [CodeCatalyst를 통해 PyPI에서 패키지 사용](#pip-install-pypi)
+ [pip 명령 지원](#pip-command-support)
  + [리포지토리와 상호 작용하는 지원되는 명령](#supported-pip-commands-that-interact-with-a-repository)
  + [지원되는 클라이언트 측 명령](#supported-pip-client-side-commands)

## pip를 사용하여 CodeCatalyst에서 Python 패키지 설치
<a name="pip-install"></a>

다음 지침은 CodeCatalyst 패키지 리포지토리 또는 업스트림 리포지토리 중 하나에서 Python 패키지를 설치하도록 `pip`를 구성하는 방법을 설명합니다.

**CodeCatalyst 패키지 리포지토리에서 Python 패키지를 설치하기 위해 `pip`를 구성하고 사용하려면**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.

1. 프로젝트의 개요 페이지에서 **패키지**를 선택합니다.

1. 패키지 리포지토리 목록에서 패키지 리포지토리를 선택합니다.

1. **리포지토리에 연결**을 선택합니다.

1. **리포지토리에 연결** 대화 상자의 패키지 관리자 클라이언트 목록에서 **pip**를 선택합니다.

1. CodeCatalyst로 pip를 인증하려면 개인 액세스 토큰(PAT)이 필요합니다. 이미 토큰이 있으면 그 토큰을 사용하면 됩니다. 없는 경우에는 여기에서 만들 수 있습니다.

   1. **토큰 생성**을 선택합니다.

   1. PAT를 복사하려면 **복사**를 선택합니다.
**주의**  
대화 상자를 닫으면 PAT를 다시 보거나 복사할 수 없습니다.

1. `pip config` 명령 사용하여 CodeCatalyst 레지스트리 URL 및 자격 증명을 설정합니다. 다음 값을 교체합니다.
**참고**  
콘솔 지침에서 복사하는 경우 다음 값을 업데이트해야 하며 변경해서는 안 됩니다.
   + *username*을 CodeCatalyst 사용자 이름으로 바꿉니다.
   + *PAT*를 CodeCatalyst PAT로 바꿉니다.
   + *space\$1name*을 CodeCatalyst 스페이스 이름으로 바꿉니다.
   + *proj\$1name*을 CodeCatalyst 프로젝트 이름으로 바꿉니다.
   + *my\$1repo*를 CodeCatalyst 패키지 리포지토리 이름으로 바꿉니다.

   ```
   pip config set global.index-url https://username:PAT@https://packages.region.codecatalyst.aws/pypi/space_name/proj_name/repo_name/simple/
   ```

1. 패키지가 리포지토리 또는 업스트림 리포지토리 중 하나에 있다고 할 경우, `pip install`을 사용하여 패키지를 설치할 수 있습니다. 예를 들어 다음 명령을 사용하여 `requests` 패키지를 설치할 수 있습니다.

   ```
   pip install requests
   ```

   `-i` 옵션을 사용하여 CodeCatalyst 리포지토리 대신 [https://pypi.org](https://pypi.org)에서 패키지를 설치하는 것으로 일시적으로 되돌릴 수 있습니다.

   ```
   pip install -i https://pypi.org/simple requests
   ```

## CodeCatalyst를 통해 PyPI에서 패키지 사용
<a name="pip-install-pypi"></a>

**PyPI**에 대한 업스트림 연결이 있는 리포지토리를 구성하여 CodeCatalyst 리포지토리를 통해 [Python 패키지 인덱스(PyPI)](https://www.pypi.org/)에서 Python 패키지를 사용할 수 있습니다. **PyPI**에서 사용하는 패키지는 CodeCatalyst 리포지토리로 수집하여 저장됩니다.

**PyPI에서 패키지를 사용하려면**

1. 아직 구성하지 않은 경우 [pip를 사용하여 CodeCatalyst에서 Python 패키지 설치](#pip-install)의 단계에 따라 CodeCatalyst 패키지 리포지토리로 pip를 구성합니다.

1. 리포지토리가 **PyPI**를 업스트림 소스로 추가했는지 확인합니다. [업스트림 리포지토리 추가](packages-upstream-repositories-add.md)의 지침에 따르고 **PyPI 스토어** 리포지토리를 선택하여, 어떤 업스트림 소스가 추가되었는지 확인하거나 **PyPI**를 업스트림 소스로 추가할 수 있습니다.

업스트림 리포지토리에서 패키지를 요청하는 방법에 대한 자세한 내용은 [업스트림 리포지토리가 포함된 패키지 버전 요청](packages-upstream-repositories-request.md) 섹션을 참조하세요.

## pip 명령 지원
<a name="pip-command-support"></a>

다음 섹션에는 지원되지 않는 특정 명령 외에도 CodeCatalyst 리포지토리에서 지원하는 pip 명령이 요약되어 있습니다.

**Topics**
+ [리포지토리와 상호 작용하는 지원되는 명령](#supported-pip-commands-that-interact-with-a-repository)
+ [지원되는 클라이언트 측 명령](#supported-pip-client-side-commands)

### 리포지토리와 상호 작용하는 지원되는 명령
<a name="supported-pip-commands-that-interact-with-a-repository"></a>

이 섹션에는 `pip` 클라이언트가 구성된 레지스트리에 하나 이상의 요청을 보내는 `pip` 명령이 나열되어 있습니다. CodeCatalyst 패키지 리포지토리에 대해 이러한 명령을 간접적으로 호출했을 때 제대로 작동하는 것으로 확인되었습니다.


****  

| 명령 | 설명 | 
| --- | --- | 
|   [install](https://pip.pypa.io/en/stable/reference/pip_install/)   |  패키지를 설치합니다.  | 
|   [download](https://pip.pypa.io/en/stable/reference/pip_download/)   |  패키지를 다운로드합니다.  | 

CodeCatalyst는 `pip search`를 구현하지 않습니다. `pip`를 CodeCatalyst 패키지 리포지토리로 구성한 경우 `pip search`를 실행하면 [PyPI](https://pypi.org/)에서 패키지를 검색하고 표시합니다.

### 지원되는 클라이언트 측 명령
<a name="supported-pip-client-side-commands"></a>

이러한 명령은 리포지토리와 직접 상호 작용할 필요가 없으므로 CodeCatalyst는 명령을 지원하기 위해 아무 것도 할 필요가 없습니다.


****  

| 명령 | 설명 | 
| --- | --- | 
|   [uninstall](https://pip.pypa.io/en/stable/reference/pip_uninstall/)   |  패키지를 제거합니다.  | 
|   [freeze](https://pip.pypa.io/en/stable/reference/pip_freeze/)   |  설치된 패키지를 요구 사항 형식으로 출력합니다.  | 
|   [list](https://pip.pypa.io/en/stable/reference/pip_list/)   |  설치된 패키지를 나열합니다.  | 
|   [show](https://pip.pypa.io/en/stable/reference/pip_show/)   |  설치된 패키지에 대한 정보를 표시합니다.  | 
|   [check](https://pip.pypa.io/en/stable/reference/pip_check/)   |  설치된 패키지에 호환되는 종속성이 있는지 확인합니다.  | 
|   [config](https://pip.pypa.io/en/stable/reference/pip_config/)   |  로컬 및 글로벌 구성을 관리합니다.  | 
|   [wheel](https://pip.pypa.io/en/stable/reference/pip_wheel/)   |  요구 사항에 맞게 휠을 빌드합니다.  | 
|   [hash](https://pip.pypa.io/en/stable/reference/pip_hash/)   |  패키지 아카이브의 해시를 계산합니다.  | 
|   [completion](https://pip.pypa.io/en/stable/user_guide/#command-completion)   |  명령 완성을 돕습니다.  | 
|   [debug](https://pip.pypa.io/en/stable/reference/pip_debug/)   |  디버깅에 유용한 정보를 표시합니다.  | 
|  help  |  명령에 대한 도움말을 표시합니다.  | 

# Twine 구성 및 Python 패키지 게시
<a name="packages-python-twine"></a>

`twine`을 CodeCatalyst와 함께 사용하려면 패키지 리포지토리에 `twine`를 연결하고 인증을 위한 개인 액세스 토큰을 제공해야 합니다. CodeCatalyst 콘솔에서 패키지 리포지토리에 `twine`을 연결하기 위한 지침을 볼 수 있습니다. `twine`을 CodeCatalyst에 인증하고 연결한 후 `twine` 명령을 실행할 수 있습니다.

## Twine을 사용하여 CodeCatalyst에 패키지 게시
<a name="packages-twine-publish"></a>

다음 지침은 CodeCatalyst 패키지 리포지토리를 인증하고 `twine`에 연결하는 방법을 설명합니다.

**`twine`을 구성하고 사용하여 CodeCatalyst 패키지 리포지토리에 패키지를 게시하려면**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.

1. 프로젝트의 개요 페이지에서 **패키지**를 선택합니다.

1. 패키지 리포지토리 목록에서 패키지 리포지토리를 선택합니다.

1. **리포지토리에 연결**을 선택합니다.

1. **리포지토리에 연결** 대화 상자의 패키지 관리자 클라이언트 목록에서 **Twine**을 선택합니다.

1. CodeCatalyst 를 사용하여 twine을 인증하려면 개인 액세스 토큰(PAT)이 필요합니다. 이미 토큰이 있으면 그 토큰을 사용하면 됩니다. 없는 경우에는 여기에서 만들 수 있습니다.

   1. **토큰 생성**을 선택합니다.

   1. PAT를 복사하려면 **복사**를 선택합니다.
**주의**  
대화 상자를 닫으면 PAT를 다시 보거나 복사할 수 없습니다.

1. `.pypirc` 파일을 사용하거나 환경 변수를 사용하여 twine를 구성할 수 있습니다.

   1. **`.pypirc` 파일로 구성하려면**

      원하는 편집기에서 `~/.pypirc` 파일을 엽니다.

      이전 단계에서 생성 및 복사한 PAT, 사용자 이름 및 리포지토리를 포함하여 CodeCatalyst용 인덱스 서버를 추가합니다. 다음 값을 교체합니다.
**참고**  
콘솔 지침에서 복사하는 경우 다음 값을 업데이트해야 하며 변경해서는 안 됩니다.
      + *username*을 CodeCatalyst 사용자 이름으로 바꿉니다.
      + *PAT*를 CodeCatalyst PAT로 바꿉니다.
      + *space\$1name*을 CodeCatalyst 스페이스 이름으로 바꿉니다.
      + *proj\$1name*을 CodeCatalyst 프로젝트 이름으로 바꿉니다.
      + *my\$1repo*를 CodeCatalyst 패키지 리포지토리 이름으로 바꿉니다.

      ```
      [distutils]
      index-servers = proj-name/repo-name
      
      [proj-name/repo-name]
      repository = https://packages.region.codecatalyst.aws/pypi/space_name/proj_name/repo_name/
      password = PAT
      username = username
      ```

   1. **환경 변수를 구성하려면**

      다음 환경 변수를 설정합니다. `TWINE_REPOSITORY_URL` 값에서 *space\$1name*, *proj\$1name*, *repo\$1name*을 CodeCatalyst 스페이스, 프로젝트, 패키지 리포지토리 이름으로 업데이트합니다.

      ```
      export TWINE_USERNAME=username
      ```

      ```
      export TWINE_PASSWORD=PAT
      ```

      ```
      export TWINE_REPOSITORY_URL="https://packages.region.codecatalyst.aws/pypi/space_name/proj_name/repo_name/"
      ```

1. `twine upload` 명령을 사용하여 Python 배포를 게시합니다.

# Python 패키지 이름 정규화
<a name="python-name-normalization"></a>

CodeCatalyst는 패키지 이름을 저장하기 전에 정규화합니다. 즉, CodeCatalyst의 패키지 이름은 패키지가 게시될 때 제공된 이름과 다를 수 있습니다.

Python 패키지의 경우, 정규화를 수행할 때 패키지 이름은 소문자와 `.`, `-` 및 `_` 문자의 모든 인스턴스가 단일 `-` 문자로 대체됩니다. 따라서 `pigeon_cli` 및 `pigeon.cli` 패키지 이름은 `pigeon-cli`과 같이 정규화되어 저장됩니다. 정규화되지 않은 이름은 pip 및 twine에서 사용할 수 있습니다. Python 패키지 이름 정규화에 관한 자세한 내용은 Python 설명서에서 [PEP 503](https://www.python.org/dev/peps/pep-0503/#normalized-names)을 참조하세요.

# Python 호환성
<a name="packages-python-compatibility"></a>

 CodeCatalyst는 `/simple/` API 지원하지 않지만 `Legacy` API 작업을 지원합니다. CodeCatalyst는 PyPI의 `XML-RPC` 또는 `JSON` API 작업을 지원하지 않습니다.

자세한 내용은 Python Packaging Authority의 GitHub 리포지토리에서 다음 섹션을 참조하세요.
+ [Legacy API](https://warehouse.pypa.io/api-reference/legacy.html)
+ [XML-RPC API](https://github.com/pypi/warehouse/blob/main/docs/dev/api-reference/xml-rpc.rst)
+ [JSON API](https://docs.pypi.org/api/json/)

# 패키지 할당량
<a name="packages-quotas"></a>

다음 표에서는 Amazon CodeCatalyst의 패키지 할당량 및 제한에 대해 설명합니다. Amazon CodeCatalyst의 할당량에 대한 자세한 내용은 [CodeCatalyst 할당량](quotas.md) 섹션을 참조하세요.


| Resource | 기본 할당량 | 
| --- | --- | 
| 패키지 리포지토리 | 스페이스당 최대 1,000개 | 
| 직접 업스트림 리포지토리 |  패키지 리포지토리당 최대 10개  | 
| 검색된 업스트림 패키지 리포지토리 |  요청된 패키지 버전당 최대 25개의 업스트림 리포지토리 검색  | 
| 패키지 자산 파일 크기 |  패키지 자산당 최대 5GB  | 
|  패키지 자산  |  패키지 버전당 최대 150개  | 