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

# 에서 빌드 프로젝트 설정 변경 AWS CodeBuild
<a name="change-project"></a>

 AWS CodeBuild 콘솔 AWS CLI, 또는 AWS SDKs를 사용하여 빌드 프로젝트의 설정을 변경할 수 있습니다.

빌드 프로젝트에 테스트 보고를 추가하는 경우 IAM 역할에 [테스트 보고서 권한](test-permissions.md)에서 설명하는 사용 권한이 있는지 확인합니다.

**Topics**
+ [빌드 프로젝트 설정 변경(콘솔)](#change-project-console)
+ [빌드 프로젝트 설정 변경(AWS CLI)](#change-project-cli)
+ [빌드 프로젝트의 설정 변경(AWS SDKs)](#change-project-sdks)

## 빌드 프로젝트 설정 변경(콘솔)
<a name="change-project-console"></a>

빌드 프로젝트의 설정을 변경하려면 다음 절차에 수행하세요.

1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) AWS CodeBuild 콘솔을 엽니다.

1. 탐색 창에서 **프로젝트 빌드**를 선택합니다.

1. 다음 중 하나를 수행하세요.
   + 변경하려는 빌드 프로젝트의 링크를 선택한 다음 **Edit project(프로젝트 편집)**를 선택합니다.
   + 변경하려는 빌드 프로젝트 옆에 있는 라디오 버튼을 선택하고 **세부 정보 보기**를 선택한 후 **빌드 세부 정보**를 선택합니다.

다음 섹션을 수정할 수 있습니다.

**Topics**
+ [프로젝트 구성](#change-project-console-project-config)
+ [소스](#change-project-console-source)
+ [환경](#change-project-console-environment)
+ [Buildspec](#change-project-console-buildspec)
+ [배치 구성](#change-project-console-batch-config)
+ [아티팩트](#change-project-console-artifacts)
+ [로그](#change-project-console-logs)

### 프로젝트 구성
<a name="change-project-console-project-config"></a>

**프로젝트 구성** 섹션에서 **편집**을 선택합니다. 변경이 완료되면 **구성 업데이트**를 선택하여 새 구성을 저장합니다.

다음 속성을 수정할 수 있습니다.

**설명**  
선택적으로 빌드 프로젝트에 대한 설명을 입력하여 다른 사용자가 이 프로젝트의 용도를 이해하도록 도울 수 있습니다.

**빌드 배지**  
프로젝트의 빌드 상태를 표시하고 삽입 가능하게 하려면 **Enable build badge(빌드 배치 활성화)**를 선택합니다. 자세한 내용은 [빌드 배지 샘플](sample-build-badges.md) 단원을 참조하십시오.  
소스 공급자가 Amazon S3인 경우 빌드 배지가 적용되지 않습니다.

**동시 빌드 제한 활성화**  
이 프로젝트의 동시 빌드 수를 제한하려면 다음 단계를 수행합니다.  

1. **이 프로젝트에서 시작할 수 있는 동시 빌드 수 제한**을 선택합니다.

1. **동시 빌드 제한**에 이 프로젝트에 허용되는 최대 동시 빌드 수를 입력합니다. 이 제한은 계정에 설정된 동시 빌드 제한보다 클 수 없습니다. 계정 제한보다 큰 숫자를 입력하려고 하면 오류 메시지가 표시됩니다.
현재 빌드 수가 이 한도 이하인 경우에만 새 빌드가 시작됩니다. 현재 빌드 수가 이 한도에 도달하면 새 빌드가 제한되고 실행되지 않습니다.

**퍼블릭 빌드 액세스 활성화**  <a name="change-project-console.public-builds"></a>
 AWS 계정에 액세스할 수 없는 사용자를 포함하여 프로젝트의 빌드 결과를 퍼블릭이 사용할 수 있도록 하려면 **퍼블릭 빌드 액세스 활성화**를 선택하고 빌드 결과를 퍼블릭으로 설정할지 확인합니다. 퍼블릭 빌드 프로젝트에는 다음과 같은 속성이 사용됩니다.    
**퍼블릭 빌드 서비스 역할**  
CodeBuild에서 새 서비스 역할을 생성하도록 하려면 **새 서비스 역할**을 선택하고, 기존 서비스 역할을 사용하려면 **기존 서비스 역할**을 선택합니다.  
퍼블릭 빌드 서비스 역할을 사용하면 CodeBuild가 프로젝트 빌드에 대한 CloudWatch Logs를 읽고 Amazon S3 아티팩트를 다운로드할 수 있습니다. 이 역할은 프로젝트의 빌드 로그와 아티팩트를 퍼블릭으로 지정하는 데 필요합니다.  
**서비스 역할**  
새 서비스 역할 또는 기존 서비스 역할의 이름을 입력합니다.
프로젝트의 빌드 결과를 프라이빗으로 설정하려면 **퍼블릭 빌드 액세스 활성화**를 선택 취소합니다.  
자세한 내용은 [퍼블릭 빌드 프로젝트 URL 가져오기](public-builds.md) 단원을 참조하십시오.  
프로젝트의 빌드 결과를 퍼블릭으로 유지할 때는 다음에 유의해야 합니다.  
+ 프로젝트가 프라이빗일 때 실행된 빌드를 포함하여 프로젝트의 모든 빌드 결과, 로그, 아티팩트는 누구나 이용할 수 있습니다.
+ 모든 빌드 로그와 아티팩트는 누구나 이용할 수 있습니다. 환경 변수, 소스 코드 및 기타 중요한 정보가 빌드 로그와 아티팩트에 출력되었을 수 있습니다. 빌드 로그에 출력되는 정보에 주의해야 합니다. 몇 가지 모범 사례는 다음과 같습니다.
  + 환경 변수에 민감한 값, 특히 AWS 액세스 키 IDs 및 보안 액세스 키를 저장하지 마십시오. Amazon EC2 Systems Manager 파라미터 스토어 또는를 사용하여 민감한 값을 저장하는 AWS Secrets Manager 것이 좋습니다.
  + webhook를 최대한 안전하게 보호하려면 [webhook 사용 모범 사례](webhooks.md#webhook-best-practices)에 따라 빌드를 트리거할 수 있는 엔터티를 제한하고, buildspec을 프로젝트 자체에 저장하지 마세요.
+ 악의적인 사용자는 퍼블릭 빌드를 사용하여 악성 아티팩트를 배포할 수 있습니다. 프로젝트 관리자는 모든 풀 요청을 검토하여 풀 요청이 합법적인 변경인지 확인하는 것이 좋습니다. 또한 체크섬으로 모든 아티팩트의 유효성을 검사하여 올바른 아티팩트가 다운로드되고 있는지 확인하는 것이 좋습니다.

**추가 정보**  
**태그**에 지원 AWS 서비스에서 사용할 태그의 이름과 값을 입력합니다. [**Add row**]를 사용하여 태그를 추가합니다. 최대 50개의 태그를 추가할 수 있습니다.

### 소스
<a name="change-project-console-source"></a>

**소스** 섹션에서 **편집**을 선택합니다. 변경이 완료되면 **구성 업데이트**를 선택하여 새 구성을 저장합니다.

다음 속성을 수정할 수 있습니다.

**소스 공급자**  
소스 코드 공급자 유형을 선택합니다. 다음 목록을 사용하여 소스 공급자에 알맞은 유형을 선택합니다.  
CodeBuild에서는 Bitbucket Server를 지원하지 않습니다.

------
#### [ Amazon S3 ]

 **버킷**   
소스 코드가 포함된 입력 버킷의 이름을 선택합니다.

 **S3 객체 키 또는 S3 폴더**   
소스 코드가 포함된 ZIP 파일의 이름 또는 폴더 경로를 입력합니다. S3 버킷의 모든 항목을 다운로드하려면 슬래시(/)를 입력합니다.

 **소스 버전**   
입력 파일의 빌드를 나타내는 객체의 버전 ID를 입력합니다. 자세한 내용은 [를 사용한 소스 버전 샘플 AWS CodeBuild](sample-source-version.md) 단원을 참조하십시오.

------
#### [ CodeCommit ]

 **리포지토리**   
사용할 리포지토리를 선택합니다.

**참조 유형**  
**분기**, **Git 태그** 또는 **커밋 ID**를 선택하여 소스 코드 버전을 지정합니다. 자세한 내용은 [를 사용한 소스 버전 샘플 AWS CodeBuild](sample-source-version.md) 단원을 참조하십시오.  
`811dd1ba1aba14473856cee38308caed7190c0d` 또는 `5392f7`과 같이 커밋 ID처럼 보이지 않는 Git 분기 이름을 선택하는 것이 좋습니다. 이렇게 하면 실제 커밋과 Git 체크아웃이 충돌하는 것을 방지할 수 있습니다.

 **Git clone 깊이**   
이력이 지정된 커밋 수로 잘린 부분 복제를 생성하려면 선택합니다. 전체 복제가 필요할 경우 **전체**를 선택합니다.

**Git 하위 모듈**  
리포지토리에 Git 하위 모듈을 포함하려면 **Use Git submodules(Git 하위 모듈 사용)**를 선택합니다.

------
#### [ Bitbucket ]

 **자격 증명**   
**기본 소스 자격 증명** 또는 **사용자 지정 소스 자격 증명을** 선택하고 지침에 따라 기본 소스 자격 증명을 관리하거나 소스 자격 증명을 사용자 지정합니다.

 **연결 유형**   
**CodeConnections**, **OAuth**, **앱 암호** 또는 **개인 액세스 토큰**을 선택하여 CodeBuild에 연결합니다.

 **Connection**   
Bitbucket 연결 또는 Secrets Manager 암호를 선택하여 지정된 연결 유형을 통해 연결합니다.

 **리포지토리**   
**내 Bitbucket 계정의 리포지토리** 또는 **퍼블릭 리포지토리**를 선택하고 리포지토리 URL을 입력합니다.

 **소스 버전**   
분기, 커밋 ID, 태그 또는 참조와 커밋 ID를 입력합니다. 자세한 내용은 [를 사용한 소스 버전 샘플 AWS CodeBuild](sample-source-version.md) 섹션을 참조하세요.  
`811dd1ba1aba14473856cee38308caed7190c0d` 또는 `5392f7`과 같이 커밋 ID처럼 보이지 않는 Git 분기 이름을 선택하는 것이 좋습니다. 이렇게 하면 실제 커밋과 Git 체크아웃이 충돌하는 것을 방지할 수 있습니다.

 **Git clone 깊이**   
**Git clone 깊이**를 선택하면 이력이 지정된 커밋 수로 잘린 부분 복제가 생성됩니다. 전체 복제가 필요할 경우 **전체**를 선택합니다.

**Git 하위 모듈**  
리포지토리에 Git 하위 모듈을 포함하려면 **Use Git submodules(Git 하위 모듈 사용)**를 선택합니다.

**빌드 상태**  
빌드 시작 및 완료 상태가 소스 공급자에게 보고되도록 하려면 **빌드가 시작되고 완료될 때 소스 공급자에게 빌드 상태 보고**를 선택합니다.  
소스 공급자에게 빌드 상태를 보고하려면 소스 공급자와 연결된 사용자에게 리포지토리에 대한 쓰기 권한이 있어야 합니다. 사용자에게 쓰기 권한이 없는 경우 빌드 상태를 업데이트할 수 없습니다. 자세한 내용은 [소스 공급자 액세스](access-tokens.md) 단원을 참조하십시오.  
**상태 컨텍스트**의 경우 Bitbucket 커밋 상태의 `name` 파라미터에 사용할 값을 입력합니다. 자세한 내용은 Bitbucket API 설명서의 [빌드](https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Bworkspace%7D/%7Brepo_slug%7D/commit/%7Bnode%7D/statuses/build)를 참조하세요.  
**대상 URL**에 Bitbucket 커밋 상태의 `url` 파라미터에 사용할 값을 입력합니다. 자세한 내용은 Bitbucket API 설명서의 [빌드](https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Bworkspace%7D/%7Brepo_slug%7D/commit/%7Bnode%7D/statuses/build)를 참조하세요.  
Webhook에 의해 트리거된 빌드의 상태는 항상 소스 공급자에게 보고됩니다. 콘솔 또는 API 직접 호출에서 시작된 빌드의 상태를 소스 공급자에게 보고하려면 이 설정을 선택해야 합니다.  
프로젝트 빌드가 webhook에 의해 트리거되는 경우 이 설정의 변경 사항을 적용하려면 새 커밋을 리포지토리에 푸시해야 합니다.

코드 변경 사항이 이 리포지토리에 푸시될 때마다 CodeBuild가 소스 코드를 빌드하도록 하려면 **기본 소스 webhook 이벤트**에서 **코드 변경이 이 리포지토리에 푸시될 때마다 다시 빌드**를 선택합니다. webhook 및 필터 그룹에 대한 자세한 내용은 [Bitbucket Webhook 이벤트](bitbucket-webhook.md) 섹션을 참조하세요.

------
#### [ GitHub ]

 **자격 증명**   
**기본 소스 자격 증명** 또는 **사용자 지정 소스 자격 증명을** 선택하고 지침에 따라 기본 소스 자격 증명을 관리하거나 소스 자격 증명을 사용자 지정합니다.

 **연결 유형**   
**GitHub 앱**, **OAuth** 또는 **개인 액세스 토큰**을 선택하여 CodeBuild에 연결합니다.

 **Connection**   
GitHub 연결 또는 Secrets Manager 보안 암호를 선택하여 지정된 연결 유형을 통해 연결합니다.

 **리포지토리**   
**내 GitHub 계정의 리포지토리**, **퍼블릭 리포지토리** 또는 **GitHub 범위 웹후크**를 선택하고 리포지토리 URL을 입력합니다.

 **소스 버전**   
분기, 커밋 ID, 태그 또는 참조와 커밋 ID를 입력합니다. 자세한 내용은 [를 사용한 소스 버전 샘플 AWS CodeBuild](sample-source-version.md) 섹션을 참조하세요.  
`811dd1ba1aba14473856cee38308caed7190c0d` 또는 `5392f7`과 같이 커밋 ID처럼 보이지 않는 Git 분기 이름을 선택하는 것이 좋습니다. 이렇게 하면 실제 커밋과 Git 체크아웃이 충돌하는 것을 방지할 수 있습니다.

 **Git clone 깊이**   
**Git clone 깊이**를 선택하면 이력이 지정된 커밋 수로 잘린 부분 복제가 생성됩니다. 전체 복제가 필요할 경우 **전체**를 선택합니다.

**Git 하위 모듈**  
리포지토리에 Git 하위 모듈을 포함하려면 **Use Git submodules(Git 하위 모듈 사용)**를 선택합니다.

**빌드 상태**  
빌드 시작 및 완료 상태가 소스 공급자에게 보고되도록 하려면 **빌드가 시작되고 완료될 때 소스 공급자에게 빌드 상태 보고**를 선택합니다.  
소스 공급자에게 빌드 상태를 보고하려면 소스 공급자와 연결된 사용자에게 리포지토리에 대한 쓰기 권한이 있어야 합니다. 사용자에게 쓰기 권한이 없는 경우 빌드 상태를 업데이트할 수 없습니다. 자세한 내용은 [소스 공급자 액세스](access-tokens.md) 단원을 참조하십시오.  
**상태 컨텍스트**의 경우 GitHub 커밋 상태의 `context` 파라미터에 사용할 값을 입력합니다. 자세한 내용은 GitHub 개발자 안내서의 [커밋 상태 생성](https://developer.github.com/v3/repos/statuses/#create-a-commit-status)을 참조하세요.  
**대상 URL**에 GitHub 커밋 상태의 `target_url` 파라미터에 사용할 값을 입력합니다. 자세한 내용은 GitHub 개발자 안내서의 [커밋 상태 생성](https://developer.github.com/v3/repos/statuses/#create-a-commit-status)을 참조하세요.  
Webhook에 의해 트리거된 빌드의 상태는 항상 소스 공급자에게 보고됩니다. 콘솔 또는 API 직접 호출에서 시작된 빌드의 상태를 소스 공급자에게 보고하려면 이 설정을 선택해야 합니다.  
프로젝트 빌드가 webhook에 의해 트리거되는 경우 이 설정의 변경 사항을 적용하려면 새 커밋을 리포지토리에 푸시해야 합니다.

코드 변경 사항이 이 리포지토리에 푸시될 때마다 CodeBuild가 소스 코드를 빌드하도록 하려면 **기본 소스 webhook 이벤트**에서 **코드 변경이 이 리포지토리에 푸시될 때마다 다시 빌드**를 선택합니다. webhook 및 필터 그룹에 대한 자세한 내용은 [GitHub Webhook 이벤트](github-webhook.md) 섹션을 참조하세요.

------
#### [ GitHub Enterprise Server ]

 **자격 증명**   
**기본 소스 자격 증명** 또는 **사용자 지정 소스 자격 증명을** 선택하고 지침에 따라 기본 소스 자격 증명을 관리하거나 소스 자격 증명을 사용자 지정합니다.

 **연결 유형**   
**CodeConnections** 또는 **개인 액세스 토큰**을 선택하여 CodeBuild에 연결합니다.

 **Connection**   
GitHub Enterprise 연결 또는 Secrets Manager 보안 암호를 선택하여 지정된 연결 유형을 통해 연결합니다.

 **리포지토리**   
**내 GitHub Enterprise 계정의 리포지토리** 또는 **GitHub Enterprise 범위 웹후크**를 선택하고 리포지토리 URL을 입력합니다.

**소스 버전**  
풀 요청, 분기, 커밋 ID, 태그 또는 참조와 커밋 ID를 입력합니다. 자세한 내용은 [를 사용한 소스 버전 샘플 AWS CodeBuild](sample-source-version.md) 단원을 참조하십시오.  
`811dd1ba1aba14473856cee38308caed7190c0d` 또는 `5392f7`과 같이 커밋 ID처럼 보이지 않는 Git 분기 이름을 선택하는 것이 좋습니다. 이렇게 하면 실제 커밋과 Git 체크아웃이 충돌하는 것을 방지할 수 있습니다.

**Git clone 깊이**  
**Git clone 깊이**를 선택하면 이력이 지정된 커밋 수로 잘린 부분 복제가 생성됩니다. 전체 복제가 필요할 경우 **전체**를 선택합니다.

**Git 하위 모듈**  
리포지토리에 Git 하위 모듈을 포함하려면 **Use Git submodules(Git 하위 모듈 사용)**를 선택합니다.

**빌드 상태**  
빌드 시작 및 완료 상태가 소스 공급자에게 보고되도록 하려면 **빌드가 시작되고 완료될 때 소스 공급자에게 빌드 상태 보고**를 선택합니다.  
소스 공급자에게 빌드 상태를 보고하려면 소스 공급자와 연결된 사용자에게 리포지토리에 대한 쓰기 권한이 있어야 합니다. 사용자에게 쓰기 권한이 없는 경우 빌드 상태를 업데이트할 수 없습니다. 자세한 내용은 [소스 공급자 액세스](access-tokens.md) 단원을 참조하십시오.  
**상태 컨텍스트**의 경우 GitHub 커밋 상태의 `context` 파라미터에 사용할 값을 입력합니다. 자세한 내용은 GitHub 개발자 안내서의 [커밋 상태 생성](https://developer.github.com/v3/repos/statuses/#create-a-commit-status)을 참조하세요.  
**대상 URL**에 GitHub 커밋 상태의 `target_url` 파라미터에 사용할 값을 입력합니다. 자세한 내용은 GitHub 개발자 안내서의 [커밋 상태 생성](https://developer.github.com/v3/repos/statuses/#create-a-commit-status)을 참조하세요.  
Webhook에 의해 트리거된 빌드의 상태는 항상 소스 공급자에게 보고됩니다. 콘솔 또는 API 직접 호출에서 시작된 빌드의 상태를 소스 공급자에게 보고하려면 이 설정을 선택해야 합니다.  
프로젝트 빌드가 webhook에 의해 트리거되는 경우 이 설정의 변경 사항을 적용하려면 새 커밋을 리포지토리에 푸시해야 합니다.

**비보안 SSL**  
GitHub Enterprise 프로젝트 리포지토리에 연결되어 있는 동안 SSL을 무시하려면 **Enable insecure SSL(안전하지 않은 SSL 활성화)**을 선택합니다.

코드 변경 사항이 이 리포지토리에 푸시될 때마다 CodeBuild가 소스 코드를 빌드하도록 하려면 **기본 소스 webhook 이벤트**에서 **코드 변경이 이 리포지토리에 푸시될 때마다 다시 빌드**를 선택합니다. webhook 및 필터 그룹에 대한 자세한 내용은 [GitHub Webhook 이벤트](github-webhook.md) 섹션을 참조하세요.

------
#### [ GitLab ]

 **자격 증명**   
**기본 소스 자격 증명** 또는 **사용자 지정 소스 자격 증명을** 선택하고 지침에 따라 기본 소스 자격 증명을 관리하거나 소스 자격 증명을 사용자 지정합니다.

 **연결 유형**   
**CodeConnections**는 GitLab을 CodeBuild에 연결하는 데 사용됩니다.

 **Connection**   
CodeConnections를 통해 연결할 GitLab 연결을 선택합니다.

 **리포지토리**   
사용할 리포지토리를 선택합니다.

 **소스 버전**   
pull 요청, 분기, 커밋 ID, 태그 또는 참조와 커밋 ID를 입력합니다. 자세한 내용은 [를 사용한 소스 버전 샘플 AWS CodeBuild](sample-source-version.md) 단원을 참조하십시오.  
`811dd1ba1aba14473856cee38308caed7190c0d` 또는 `5392f7`과 같이 커밋 ID처럼 보이지 않는 Git 분기 이름을 선택하는 것이 좋습니다. 이렇게 하면 실제 커밋과 Git 체크아웃이 충돌하는 것을 방지할 수 있습니다.

 **Git clone 깊이**   
**Git clone 깊이**를 선택하면 이력이 지정된 커밋 수로 잘린 부분 복제가 생성됩니다. 전체 복제가 필요할 경우 **전체**를 선택합니다.

**빌드 상태**  
빌드 시작 및 완료 상태가 소스 공급자에게 보고되도록 하려면 **빌드가 시작되고 완료될 때 소스 공급자에게 빌드 상태 보고**를 선택합니다.  
소스 공급자에게 빌드 상태를 보고하려면 소스 공급자와 연결된 사용자에게 리포지토리에 대한 쓰기 권한이 있어야 합니다. 사용자에게 쓰기 권한이 없는 경우 빌드 상태를 업데이트할 수 없습니다. 자세한 내용은 [소스 공급자 액세스](access-tokens.md) 단원을 참조하십시오.

------
#### [ GitLab Self Managed ]

 **자격 증명**   
**기본 소스 자격 증명** 또는 **사용자 지정 소스 자격 증명을** 선택하고 지침에 따라 기본 소스 자격 증명을 관리하거나 소스 자격 증명을 사용자 지정합니다.

 **연결 유형**   
**CodeConnections**는 GitLab Self Managed를 CodeBuild 연결하는 데 사용됩니다.

 **Connection**   
GitLab Self Managed 연결을 선택하여 CodeConnections 통해 연결합니다.

 **리포지토리**   
사용할 리포지토리를 선택합니다.

 **소스 버전**   
pull 요청, 분기, 커밋 ID, 태그 또는 참조와 커밋 ID를 입력합니다. 자세한 내용은 [를 사용한 소스 버전 샘플 AWS CodeBuild](sample-source-version.md) 단원을 참조하십시오.  
`811dd1ba1aba14473856cee38308caed7190c0d` 또는 `5392f7`과 같이 커밋 ID처럼 보이지 않는 Git 분기 이름을 선택하는 것이 좋습니다. 이렇게 하면 실제 커밋과 Git 체크아웃이 충돌하는 것을 방지할 수 있습니다.

 **Git clone 깊이**   
**Git clone 깊이**를 선택하면 이력이 지정된 커밋 수로 잘린 부분 복제가 생성됩니다. 전체 복제가 필요할 경우 **전체**를 선택합니다.

**빌드 상태**  
빌드 시작 및 완료 상태가 소스 공급자에게 보고되도록 하려면 **빌드가 시작되고 완료될 때 소스 공급자에게 빌드 상태 보고**를 선택합니다.  
소스 공급자에게 빌드 상태를 보고하려면 소스 공급자와 연결된 사용자에게 리포지토리에 대한 쓰기 권한이 있어야 합니다. 사용자에게 쓰기 권한이 없는 경우 빌드 상태를 업데이트할 수 없습니다. 자세한 내용은 [소스 공급자 액세스](access-tokens.md) 단원을 참조하십시오.

------

### 환경
<a name="change-project-console-environment"></a>

**환경** 섹션에서 **편집**을 선택합니다. 변경이 완료되면 **구성 업데이트**를 선택하여 새 구성을 저장합니다.

다음 속성을 수정할 수 있습니다.

**프로비저닝 모델**  
프로비저닝 모델을 변경하려면 **프로비저닝 모델 변경**을 선택하고 다음 중 하나를 수행합니다.  
+ 에서 관리하는 온디맨드 플릿을 사용하려면 **온디맨**드를 AWS CodeBuild선택합니다. CodeBuild는 온디맨드 플릿을 통해 빌드에 맞는 컴퓨팅 기능을 제공합니다. 빌드가 완료되면 머신이 파괴됩니다. 온디맨드 플릿은 완전 관리형이며, 수요 급증을 처리할 수 있는 자동 규모 조정 기능이 포함되어 있습니다.
+ 에서 관리하는 예약 용량 플릿을 사용하려면 **예약 용량을** AWS CodeBuild선택한 다음 **플릿 이름을** 선택합니다. 예약 용량 플릿을 사용하면 빌드 환경을 위한 전용 인스턴스 세트를 구성할 수 있습니다. 이러한 머신은 유휴 상태로 유지되므로 빌드 또는 테스트를 즉시 처리하고 빌드 기간을 단축할 수 있습니다. 예약 용량 플릿을 사용하면 머신이 상시 가동되므로 프로비저닝하는 한 계속해서 비용이 발생합니다.
자세한 내용은 [예약 용량 플릿에서 빌드 실행](fleets.md) 단원을 참조하세요.

**환경 이미지**  
빌드 이미지를 변경하려면 **이미지 재정의**를 선택하고 다음 중 하나를 수행합니다.  
+ 에서 관리하는 Docker 이미지를 사용하려면 **관리형 이미지를** AWS CodeBuild선택한 다음 **운영 체제**, **런타임, 이미지(Image)** 및 **이미지 버전**에서 선택합니다. **** 사용 가능한 경우 **환경 유형**에서 항목을 선택합니다.
+ 다른 도커 이미지를 사용하려면 **사용자 지정 이미지**를 선택합니다. **환경 유형**에서 **ARM**, **Linux**, **Linux GPU** 또는 **Windows**를 선택합니다. **Other registry(다른 레지스트리)**를 선택한 경우 **External registry URL(외부 레지스트리 URL)**에 Docker Hub의 도커 이미지 이름 및 태그를 `docker repository/docker image name` 형식으로 입력합니다. **Amazon ECR**을 선택하는 경우 **Amazon ECR 리포지토리**와 **Amazon ECR 이미지를** 사용하여 AWS 계정에서 도커 이미지를 선택합니다.
+ 프라이빗 도커 이미지를 사용하려면 **사용자 지정 이미지**를 선택합니다. **환경 유형**에서 **ARM**, **Linux**, **Linux GPU** 또는 **Windows**를 선택합니다. **Image registry(이미지 레지스트리)**에서 **Other registry(다른 레지스트리)**를 선택한 다음 프라이빗 도커 이미지에 대한 보안 인증 정보의 ARN을 입력합니다. 보안 인증은 Secrets Manager에서 생성됩니다. 자세한 내용은 AWS Secrets Manager사용 설명서의 [AWS Secrets Manager 이란?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/) 섹션을 참조하세요.**
CodeBuild는 사용자 지정 도커 이미지에 대해 `ENTRYPOINT`를 재정의합니다.

**서비스 역할**  
다음 중 하나를 수행하세요.  
+ CodeBuild 서비스 역할이 없는 경우 **새 서비스 역할**을 선택합니다. **역할 이름**에 새 역할의 이름을 입력합니다.
+ CodeBuild 서비스 역할이 있는 경우 **기존 서비스 역할**을 선택합니다. **역할 ARN**에서 서비스 역할을 선택합니다.
콘솔을 사용하여 빌드 프로젝트를 생성하는 경우, 이와 동시에 CodeBuild 서비스 역할을 생성할 수 있습니다. 기본적으로 역할은 해당 빌드 프로젝트에서만 작동합니다. 콘솔을 사용하여 이 서비스 역할을 다른 빌드 프로젝트와 연결하는 경우 다른 빌드 프로젝트에서 작동하도록 역할이 업데이트됩니다. 하나의 서비스 역할은 최대 10개의 빌드 프로젝트에서 작동할 수 있습니다.

**추가 구성**    
**제한 시간**  
빌드가 완료되지 않는 경우 CodeBuild가 해당 빌드를 중지할 제한 시간으로 5분에서 36시간 사이의 값을 지정합니다. [**hours**] 및 [**minutes**]가 비어 있는 경우 기본값인 60분이 사용됩니다.  
**권한 있음**  
이 빌드 프로젝트를 사용하여 Docker 이미지를 빌드하려는 경우에만 **Docker 이미지를 빌드하거나 빌드에서 승격된 권한을 얻으려는 경우 이 플래그 활성화**를 선택합니다. 그렇지 않으면 Docker 데몬과 상호 작용을 시도하는 모든 연결된 빌드가 실패합니다. 또한 빌드가 상호 작용할 수 있도록 Docker 데몬을 시작해야 합니다. 이를 수행하는 한 가지 방법은 다음 빌드 명령을 실행하여 빌드 사양의 `install` 단계에서 Docker 데몬을 초기화하는 것입니다. 선택한 빌드 환경 이미지가 Docker 지원을 통해 CodeBuild에서 제공되지 않는 경우 이 명령을 실행하지 마세요.  
기본적으로 비 VPC 빌드에는 Docker 데몬이 활성화됩니다. VPC 빌드에 Docker 컨테이너를 사용하려면 Docker Docs 웹 사이트의 [런타임 권한 및 Linux 기능](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)을 참조하고 권한 부여 모드를 활성화합니다. 또한 Windows는 권한 모드를 지원하지 않습니다.

```
- nohup /usr/local/bin/dockerd --host=unix:///var/run/docker.sock --host=tcp://127.0.0.1:2375 --storage-driver=overlay2 &
- timeout 15 sh -c "until docker info; do echo .; sleep 1; done"
```  
**VPC**  
CodeBuild를 사용하여 VPC에서 작업을 수행하려는 경우:  
+ **VPC**에서 CodeBuild가 사용하는 VPC ID를 선택합니다.
+ **VPC 서브넷**에서 CodeBuild가 사용하는 리소스가 포함된 서브넷을 선택합니다.
+ **VPC 보안 그룹**에서 CodeBuild가 VPC의 리소스에 대한 액세스를 허용하기 위해 사용하는 보안 그룹을 선택합니다.
자세한 내용은 [Amazon Virtual Private Cloud AWS CodeBuild 와 함께 사용](vpc-support.md) 단원을 참조하십시오.  
**컴퓨팅**  
사용 가능한 옵션 중 하나를 선택합니다.  
**레지스트리 자격 증명**  
프로젝트가 비공개 레지스트리 이미지로 구성된 경우 레지스트리 자격 증명을 지정합니다.  
이 자격 증명은 이미지가 프라이빗 레지스트리의 이미지로 재정의된 경우에만 사용됩니다.  
**환경 변수**  
사용할 빌드의 각 환경 변수에 대해 이름 및 값을 입력하고 유형을 선택합니다.  
CodeBuild는 AWS 리전의 환경 변수를 자동으로 설정합니다. buildspec.yml에 추가하지 않은 경우 다음 환경 변수를 설정해야 합니다.  
+ AWS\$1ACCOUNT\$1ID
+ IMAGE\$1REPO\$1NAME
+ IMAGE\$1TAG
콘솔과 AWS CLI 사용자는 환경 변수를 볼 수 있습니다. 환경 변수의 가시성에 대한 문제가 없다면 [**Name**] 및 [**Value**] 필드를 설정한 다음 [**Type**]을 [**Plaintext**]로 설정합니다.  
액세스 키 ID, AWS 보안 AWS 액세스 키 또는 암호와 같은 민감한 값을 가진 환경 변수를 Amazon EC2 Systems Manager Parameter Store 또는에 파라미터로 저장하는 것이 좋습니다 AWS Secrets Manager.  
Amazon EC2 Systems Manager Parameter Store를 사용하는 경우 **유형**에서 **파라미터**를 선택합니다. **이름**에 CodeBuild가 참조할 식별자를 입력합니다. **값**에 Amazon EC2 Systems Manager Parameter Store에 저장되는 파라미터의 이름을 입력합니다. 예를 들어 `/CodeBuild/dockerLoginPassword`라는 이름의 파라미터를 사용하여 **유형**에서 **파라미터**를 선택합니다. **이름**에 `LOGIN_PASSWORD`를 입력합니다. **값**에 `/CodeBuild/dockerLoginPassword`를 입력합니다.  
Amazon EC2 Systems Manager Parameter Store를 사용하는 경우 `/CodeBuild/`로 시작하는 파라미터 이름(예: `/CodeBuild/dockerLoginPassword`)으로 파라미터를 저장하는 것이 좋습니다. CodeBuild 콘솔을 사용하여 Amazon EC2 Systems Manager에서 파라미터를 생성할 수 있습니다. **파라미터 생성**을 선택하고 대화 상자에 표시되는 지시에 따릅니다. (그 대화 상자에서 **KMS 키**에 대해 계정에 있는 AWS KMS 키의 ARN을 지정할 수 있습니다. Amazon EC2 Systems Manager는이 키를 사용하여 저장 중에 파라미터의 값을 암호화하고 검색 중에 복호화합니다.) CodeBuild 콘솔을 사용하여 파라미터를 생성하는 경우 콘솔은 이름이 `/CodeBuild/`인 파라미터가 저장되면 시작합니다. 자세한 내용은 Amazon EC2 Systems Manager 사용 설명서의 [Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-paramstore.html) 및 [Systems Manager Parameter Store 콘솔 연습](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-walk.html#sysman-paramstore-console)을 참조하세요.**  
빌드 프로젝트가 Amazon EC2 Systems Manager Parameter Store에 저장된 파라미터를 참조하는 경우 해당 빌드 프로젝트의 서비스 역할은 `ssm:GetParameters` 작업을 허용해야 합니다. 앞에서 **새 서비스 역할**을 선택한 경우에는 CodeBuild는 빌드 프로젝트의 기본 서비스 역할에 이 작업을 포함합니다. **Existing service role(기존 서비스 역할)**을 선택한 경우에는 이 작업을 서비스 역할에 별도로 포함해야 합니다.  
빌드 프로젝트가 `/CodeBuild/`로 시작되지 않는 파라미터 이름으로 Amazon EC2 Systems Manager Parameter Store에 저장된 파라미터를 참조하는 경우 **새 서비스 역할**을 선택하면 `/CodeBuild/`로 시작하지 않는 파라미터 이름에 액세스할 수 있도록 해당 서비스 역할을 업데이트해야 합니다. 이는 서비스 역할이 `/CodeBuild/`로 시작하는 파라미터 이름에만 액세스할 수 있기 때문입니다.  
**새 서비스 역할**을 선택하면 Amazon EC2 Systems Manager Parameter Store에 있는 `/CodeBuild/` 네임스페이스의 모든 파라미터를 해독할 권한이 서비스 역할에 포함됩니다.  
사용자가 설정한 환경 변수는 기존 환경 변수를 대체합니다. 예를 들어 도커 이미지에 값이 `my_value`인 `MY_VAR`이라는 환경 변수가 이미 포함되어 있는데, 사용자가 `MY_VAR` 환경 변수의 값을 `other_value`로 설정하면, `my_value`가 `other_value`로 바뀝니다. 마찬가지로, 도커 이미지에 값이 `/usr/local/sbin:/usr/local/bin`인 `PATH`라는 환경 변수가 이미 포함되어 있는데, 사용자가 `PATH` 환경 변수의 값을 `$PATH:/usr/share/ant/bin`으로 설정하면, `/usr/local/sbin:/usr/local/bin`이 `$PATH:/usr/share/ant/bin` 리터럴 값으로 바뀝니다.  
`CODEBUILD_`로 시작하는 이름으로 환경 변수를 설정하지 마십시오. 이 접두사는 내부 전용으로 예약되어 있습니다.  
여러 위치에서 동일한 이름의 환경 변수가 정의되는 경우, 다음과 같이 값이 결정됩니다.  
+ 시작 빌드 작업 호출의 값이 가장 높은 우선 순위를 갖습니다.
+ 빌드 프로젝트 정의의 값이 다음 우선 순위를 갖습니다.
+ buildspec 선언의 값이 가장 낮은 우선 순위를 갖습니다.
Secrets Manager를 사용하는 경우 **유형**으로 **Secrets Manager**로 선택합니다. **이름**에 CodeBuild가 참조할 식별자를 입력합니다. **값**에 `secret-id:json-key:version-stage:version-id` 패턴을 사용하여 `reference-key`를 입력합니다. 자세한 내용은 [Secrets Manager reference-key in the buildspec file](build-spec-ref.md#secrets-manager-build-spec) 단원을 참조하세요.  
Secrets Manager를 사용하는 경우 이름이 `/CodeBuild/`로 시작하는 암호를 저장하는 것이 좋습니다(예: `/CodeBuild/dockerLoginPassword`). 자세한 내용은 AWS Secrets Manager사용 설명서의 [AWS Secrets Manager 이란?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) 섹션을 참조하세요.**  
빌드 프로젝트가 Secrets Manager에 저장된 암호를 참조하는 경우 해당 빌드 프로젝트의 서비스 역할은 `secretsmanager:GetSecretValue` 작업을 허용해야 합니다. 앞에서 **새 서비스 역할**을 선택한 경우에는 CodeBuild는 빌드 프로젝트의 기본 서비스 역할에 이 작업을 포함합니다. **Existing service role(기존 서비스 역할)**을 선택한 경우에는 이 작업을 서비스 역할에 별도로 포함해야 합니다.  
빌드 프로젝트가 `/CodeBuild/`로 시작되지 않는 보안 암호 이름으로 Secrets Manager에 저장된 암호를 참조하는 경우 **새 서비스 역할**을 선택하면 `/CodeBuild/`로 시작하지 않는 보안 암호 이름에 액세스할 수 있도록 해당 서비스 역할을 업데이트해야 합니다. 이는 서비스 역할이 `/CodeBuild/`로 시작하는 암호 이름에만 액세스할 수 있기 때문입니다.  
**새 서비스 역할**을 선택하면 에 있는 `/CodeBuild/` 네임스페이스의 모든 암호를 해독할 권한이 서비스 역할에 포함됩니다.

### Buildspec
<a name="change-project-console-buildspec"></a>

**Buildspec** 섹션에서 **편집**을 선택합니다. 변경이 완료되면 **구성 업데이트**를 선택하여 새 구성을 저장합니다.

다음 속성을 수정할 수 있습니다.

**빌드 사양**  
다음 중 하나를 수행하세요.  
+ 소스 코드에 buildspec 파일이 있는 경우 **Use a buildspec file(빌드 사양 파일 사용)** 을 선택합니다. 기본적으로 CodeBuild는 소스 코드 루트 디렉터리에서 `buildspec.yml`이라는 파일을 찾습니다. buildspec 파일이 다른 이름이나 위치를 사용하는 경우 **Buildspec 이름**에 소스 루트의 경로를 입력합니다(예: `buildspec-two.yml` 또는 `configuration/buildspec.yml`). buildspec 파일이 S3 버킷에 있는 경우 해당 파일은 빌드 프로젝트와 동일한 AWS 리전에 있어야 합니다. ARN을 사용하여 buildspec 파일을 지정합니다(예: `arn:aws:s3:::<my-codebuild-sample2>/buildspec.yml`).
+ 소스 코드에 buildspec 파일이 포함되어 있지 않거나, 소스 코드의 루트 디렉터리에 있는 `buildspec.yml` 파일의 `build` 단계에 지정된 것과 다른 빌드 명령 세트를 실행하려는 경우 **빌드 명령 삽입**을 선택합니다. **빌드 명령**의 `build` 단계에서 실행하려는 명령을 입력합니다. 명령이 여러 개인 경우 각 명령을 `&&`로 구분합니다(예: `mvn test && mvn package`). 다른 구문에서 명령을 실행하려는 경우 또는 `build` 단계에 대해 특히 긴 명령 목록이 있는 경우에는 소스 코드 루트 디렉터리에 `buildspec.yml` 파일을 추가하고, 이 파일에 명령을 추가한 다음, **소스 코드 루트 디렉터리에서 buildspec.yml 사용**을 선택합니다.
자세한 내용은 [buildspec 참조](build-spec-ref.md) 단원을 참조하십시오.

### 배치 구성
<a name="change-project-console-batch-config"></a>

**배치 구성** 섹션에서 **편집**을 선택합니다. 변경이 완료되면 **구성 업데이트**를 선택하여 새 구성을 저장합니다. 자세한 내용은 [배치로 빌드 실행](batch-build.md) 단원을 참조하십시오.

다음 속성을 수정할 수 있습니다.

**배치 서비스 역할**  
배치 빌드에 대한 서비스 역할을 제공합니다.  
다음 중 하나를 선택합니다.  
+ 배치 서비스 역할이 없는 경우 **새 서비스 역할**을 선택합니다. **서비스 역할**에 새 역할의 이름을 입력합니다.
+ 배치 서비스 역할이 있는 경우 **기존 서비스 역할**을 선택합니다. **서비스 역할**에서 서비스 역할을 선택합니다.
배치 빌드는 배치 구성에 새로운 보안 역할을 도입합니다. CodeBuild가 사용자 대신 `StartBuild`, `StopBuild` 및 `RetryBuild` 작업을 호출하여 배치의 일부로 빌드를 실행할 수 있어야 하므로 이 새 역할이 필요합니다. 고객은 다음과 같은 두 가지 이유로 빌드에 사용하는 것과 동일한 역할이 아닌 새 역할을 사용해야 합니다.  
+ 빌드 역할 `StartBuild`, `StopBuild` 및 `RetryBuild` 권한을 부여하면 단일 빌드에서 buildspec을 통해 더 많은 빌드를 시작할 수 있습니다.
+ CodeBuild 배치 빌드는 배치의 빌드에 사용할 수 있는 빌드 및 컴퓨팅 유형의 수를 제한하는 제한을 제공합니다. 빌드 역할에 이러한 권한이 있는 경우 빌드 자체가 이러한 제한을 우회할 수 있습니다.

**배치에 허용되는 컴퓨팅 유형**  
배치에 허용되는 컴퓨팅 유형을 선택합니다. 해당하는 항목을 모두 선택합니다.

**배치에 허용되는 플릿**  
배치에 허용되는 플릿을 선택합니다. 해당하는 항목을 모두 선택합니다.

**배치에 허용되는 최대 빌드 수**  
배치에 허용되는 최대 빌드 수를 입력합니다. 이 제한을 초과하는 배치는 실패합니다.

**배치 제한 시간**  
배치 빌드가 완료되는 최대 시간을 입력합니다.

**아티팩트 결합**  
**배치의 모든 아티팩트를 단일 위치로 결합**을 선택하면 배치의 모든 아티팩트가 단일 위치로 결합됩니다.

 **배치 보고서 모드**   
배치 빌드에 대해 원하는 빌드 상태 보고서 모드를 선택합니다.  
이 필드는 프로젝트 소스가 Bitbucket, GitHub 또는 GitHub Enterprise이고 **소스**에서 **빌드 시작 및 종료 시 소스 공급자에게 빌드 상태 보고**를 선택한 경우에만 사용할 수 있습니다.  
 **빌드 집계**   
배치의 모든 빌드 상태를 단일 상태 보고서로 통합하려면 선택합니다.  
 **개별 빌드**   
배치에 있는 모든 빌드의 빌드 상태를 별도로 보고하려면 선택합니다.

### 아티팩트
<a name="change-project-console-artifacts"></a>

**아티팩트** 섹션에서 **편집**을 선택합니다. 변경이 완료되면 **구성 업데이트**를 선택하여 새 구성을 저장합니다.

다음 속성을 수정할 수 있습니다.

**유형**  
다음 중 하나를 수행하세요.  
+ 빌드 출력 결과물을 생성하지 않으려면 [**No artifacts**]를 선택합니다. 빌드 테스트만 실행하고 있는 경우 또는 Amazon ECR 리포지토리에 도커 이미지를 푸시하려는 경우에 이 작업을 원할 수 있습니다.
+ S3 버킷에 빌드 출력을 저장하려면 **Amazon S3**를 선택하고 다음 작업을 수행합니다.
  + 빌드 출력 ZIP 파일이나 폴더에 프로젝트 이름을 사용하려는 경우 **이름**을 비워 둡니다. 그렇지 않으면 이름을 입력합니다. (ZIP 파일을 출력하고 ZIP 파일에 파일 확장명을 넣으려는 경우, ZIP 파일 이름 뒤에 이를 포함하십시오.)
  + buildspec 파일에 지정된 이름으로 콘솔에서 지정한 이름을 재정의하려는 경우 **의미 체계 버전 관리 사용**을 선택합니다. buildspec 파일의 이름은 빌드 시 계산되며 Shell 명령 언어를 사용합니다. 예를 들어 아티팩트 이름이 항상 고유하도록 날짜와 시간을 아티팩트 이름에 추가할 수 있습니다. 고유한 결과물 이름을 사용하면 결과물을 덮어쓰지 않을 수 있습니다. 자세한 내용은 [buildspec 구문](build-spec-ref.md#build-spec-ref-syntax) 단원을 참조하십시오.
  + [**Bucket name**]에서 출력 버킷의 이름을 선택합니다.
  + 이 절차의 앞부분에서 **빌드 명령 삽입**을 선택한 경우 **출력 파일**에 빌드 출력 ZIP 파일 또는 폴더에 넣으려는 빌드의 파일 위치를 입력합니다. 위치가 여러 개인 경우 각 위치를 쉼표로 구분합니다(예: `appspec.yml, target/my-app.jar`). 자세한 내용은 [buildspec 구문](build-spec-ref.md#build-spec-ref-syntax)의 `files` 설명을 참조하십시오.
  + 빌드 아티팩트를 암호화하지 않으려면 **Remove artifacts encryption(결과물 암호화 제거)**을 선택합니다.
각각 원하는 보조 아티팩트 세트마다 다음과 같이 실행합니다.  

1. **Atrifact identifier(아티팩트 식별자)**에서 128자 미만으로 영숫자와 밑줄만 포함된 값을 입력합니다.

1. **Add artifact(아티팩트 추가)**를 선택합니다.

1. 이전 단계에 따라 보조 결과물을 구성합니다.

1. **Save artifact(아티팩트 저장)**를 선택합니다.

**추가 구성**    
**암호화 키**  
다음 중 하나를 수행하세요.  
+ 계정의 AWS 관리형 키 Amazon S3를 사용하여 빌드 출력 아티팩트를 암호화하려면 **암호화 키를** 비워 둡니다. 기본값입니다.
+ 고객 관리형 키를 사용하여 빌드 출력 아티팩트를 암호화하려면 **암호화 키**에 고객 관리형 키의 ARN을 입력합니다. `arn:aws:kms:region-ID:account-ID:key/key-ID` 형식을 사용합니다.  
**캐시 유형**  
**Cache type(캐시 유형)**에서 다음 중 하나를 선택합니다.  
+ 캐시를 사용하지 않으려면 [**No cache**]를 선택합니다.
+ Amazon S3 캐시를 사용하려면 **Amazon S3**를 선택하고 다음을 수행합니다.
  + **버킷**에서 캐시가 저장된 S3 버킷의 이름을 선택합니다.
  + (선택 사항) **캐시 경로 접두사**에 Amazon S3 경로 접두사를 입력합니다. **Cache path prefix(캐시 경로 접두사)** 값은 디렉터리 이름과 비슷합니다. 따라서 캐시를 버킷의 동일한 디렉터리에 저장할 수 있습니다.
**중요**  
경로 접두사 끝에 후행 슬래시(/)를 추가하지 마십시오.
+  로컬 캐시를 사용하려면 **로컬**을 선택한 다음 하나 이상의 로컬 캐시 모드를 선택해야 합니다.
**참고**  
Docker 계층 캐시 모드는 Linux에서만 사용할 수 있습니다. 이 모드를 선택할 경우 프로젝트를 권한이 있는 모드에서 실행해야 합니다.
캐시를 사용하면 빌드 환경의 재사용 가능한 특정 부분이 캐시에 저장되고 빌드 전반에서 사용되기 때문에 상당한 빌드 시간을 절약할 수 있습니다. buildspec 파일에 캐시를 지정하는 것에 대한 자세한 정보는 [buildspec 구문](build-spec-ref.md#build-spec-ref-syntax) 단원을 참조하십시오. 캐싱에 대한 자세한 정보는 [성능을 개선하기 위한 캐시 빌드](build-caching.md)을 참조하십시오.

### 로그
<a name="change-project-console-logs"></a>

**로그** 섹션에서 **편집**을 선택합니다. 변경이 완료되면 **구성 업데이트**를 선택하여 새 구성을 저장합니다.

다음 속성을 수정할 수 있습니다.

생성하려는 로그를 선택합니다. Amazon CloudWatch Logs 또는 Amazon S3 로그 중 하나 또는 둘 다를 생성할 수 있습니다.

**CloudWatch**  
Amazon CloudWatch Logs 로그를 원할 경우:    
**CloudWatch 로그**  
**CloudWatch 로그**를 선택합니다.  
**그룹 이름**  
Amazon CloudWatch Logs 로그 그룹의 이름을 입력합니다.  
**스트림 이름**  
Amazon CloudWatch Logs 로그 스트림 이름을 입력합니다.

**S3**  
Amazon S3 로그를 원할 경우:    
**S3 로그**  
**S3 로그**를 선택합니다.  
**버킷**  
로그에 대한 S3 버킷 이름을 선택합니다.  
**경로 접두사**  
로그의 접두사를 입력합니다.  
**S3 로그 암호화 비활성화**  
S3 로그를 암호화하지 않으려면 선택합니다.

## 빌드 프로젝트 설정 변경(AWS CLI)
<a name="change-project-cli"></a>

와 AWS CLI 함께를 사용하는 방법에 대한 자세한 내용은 단원을 AWS CodeBuild참조하십시오[명령줄 참조](cmd-ref.md).

를 사용하여 CodeBuild 프로젝트를 업데이트하려면 업데이트된 속성으로 JSON 파일을 AWS CLI생성하고 해당 파일을 [https://docs.aws.amazon.com/cli/latest/reference/codebuild/update-project.html](https://docs.aws.amazon.com/cli/latest/reference/codebuild/update-project.html) 명령에 전달합니다. 업데이트 파일에 포함되지 않은 속성은 변경되지 않습니다.

업데이트 JSON 파일에는 `name` 속성과 수정된 속성만 필요합니다. `name` 속성은 수정할 프로젝트를 식별합니다. 수정된 구조의 경우 해당 구조의 필수 파라미터도 포함되어야 합니다. 예를 들어, 프로젝트에 대한 환경을 수정하려면 `environment/type` 및 `environment/computeType` 속성이 필요합니다. 다음은 환경 이미지를 업데이트하는 예입니다.

```
{
  "name": "<project-name>",
  "environment": {
    "type": "LINUX_CONTAINER",
    "computeType": "BUILD_GENERAL1_SMALL",
    "image": "aws/codebuild/amazonlinux-x86_64-standard:4.0"
  }
}
```

프로젝트의 현재 속성 값을 가져와야 하는 경우 [https://docs.aws.amazon.com/cli/latest/reference/codebuild/batch-get-projects.html](https://docs.aws.amazon.com/cli/latest/reference/codebuild/batch-get-projects.html) 명령을 사용하여 수정하려는 프로젝트의 현재 속성을 가져오고 결과를 파일에 기록합니다.

```
aws codebuild batch-get-projects --names "<project-name>" > project-info.json
```

*project-info.json* 파일에는 프로젝트 배열이 포함되어 있으므로 프로젝트를 업데이트하는 데 직접 사용할 수는 없습니다. 하지만 *project-info.json* 파일에서 수정하려는 속성을 복사한 다음, 수정하려는 속성의 기준으로 업데이트 파일에 붙여넣을 수 있습니다. 자세한 내용은 [빌드 프로젝트 세부 정보 보기(AWS CLI)](view-project-details.md#view-project-details-cli) 단원을 참조하십시오.

[빌드 프로젝트 생성(AWS CLI)](create-project.md#create-project-cli)에 설명된 대로 업데이트 JSON 파일을 수정하고 결과를 저장합니다. 업데이트 JSON 파일의 수정이 끝나면 [https://docs.aws.amazon.com/cli/latest/reference/codebuild/update-project.html](https://docs.aws.amazon.com/cli/latest/reference/codebuild/update-project.html) 명령을 실행하여 업데이트 JSON 파일을 전달합니다.

```
aws codebuild update-project --cli-input-json file://<update-project-file>
```

성공하면 업데이트된 프로젝트 JSON이 출력에 나타납니다. 필수 파라미터가 누락된 경우 누락된 파라미터를 식별하는 오류 메시지가 출력에 표시됩니다. 예를 들어, `environment/type` 파라미터가 누락된 경우 표시되는 오류 메시지는 다음과 같습니다.

```
aws codebuild update-project --cli-input-json file://update-project.json

Parameter validation failed:
Missing required parameter in environment: "type"
```

## 빌드 프로젝트의 설정 변경(AWS SDKs)
<a name="change-project-sdks"></a>

를 SDK와 AWS CodeBuild 함께 사용하는 방법에 대한 자세한 내용은 섹션을 참조하세요[AWS SDKs 및 도구 참조](sdk-ref.md). AWS SDKs