AWS CodePipeline에서 GitHub 연동 – 실무 후기 및 CI/CD 구축 가이드

목차

GitHub에 있는 코드를 AWS CodePipeline으로 빌드하고 배포하는 CI/CD 파이프라인을 구축해보았습니다. 이번 포스트에서는 “AWS CodePipeline에서 GitHub 연동”하는 방법을 실무 관점에서 공유하고, 자주 만난 문제들과 해결 방법을 정리합니다. 특히 AWS CodeStar Connector를 통한 GitHub 연결 설정, 권한 오류(codestar-connections:UseConnection) 해결, buildspec.yml 설명, 그리고 Artifact 개념 이해 등을 다룹니다. 최대한 쉬운 비유와 함께 단계별로 설명하고자 하니, AWS 환경에 익숙하지 않은 초심자분들도 끝까지 따라오실 수 있을 것입니다.

 

※ Git이 아직 어려운 분들은 아래 글을 참고하시기 바랍니다.

2025.07.29 - [IT 트렌드/알아두면 좋은 IT 상식] - Git 없이 S3로 구축하는 AWS DevOps 배포 파이프라인

Git 없이 S3로 구축하는 AWS DevOps 배포 파이프라인

 

Github - Codepipeline

*AWS CodePipeline과 GitHub을 연동한 CI/CD 파이프라인 흐름을 나타낸 다이어그램입니다. 개발자가 GitHub에 코드를 커밋하면 CodePipeline이 변경을 감지하여 파이프라인을 실행합니다. 그런 다음 CodeBuild가 소스 코드를 빌드하여 아티팩트(산출물)를 생성하고, 해당 아티팩트를 Amazon S3 버킷에 저장합니다. 이후 필요에 따라 배포 단계에서 이 아티팩트를 가져다가 배포하게 됩니다.

GitHub 연동 설정 (AWS CodeStar Connector 사용)

AWS CodePipeline에서 GitHub 저장소를 소스(Source)로 연동하려면 AWS CodeStar Connector를 사용하여 두 서비스를 통합해야 합니다. CodeStar Connector는 GitHub와 AWS 간에 OAuth 앱 형태로 연결을 맺어주는 서비스입니다. 아래는 GitHub 연동 설정을 위한 단계별 가이드입니다:

1. Pipeline 생성 및 소스 설정: AWS Management Console에서 CodePipeline 파이프라인을 생성합니다. 파이프라인 생성 마법사에서 소스 공급자(Source Provider)로 GitHub (GitHub App)을 선택합니다. 이 옵션을 선택하면 AWS가 GitHub과 통신하기 위한 연결(Connection)을 설정해야 합니다.
2. GitHub 연결 생성: 소스 단계 설정에서 “연결” 항목에 기존 연결이 없다면, “Connect to GitHub” 버튼을 눌러 새로운 연결을 만듭니다. 클릭하면 GitHub 인증 페이지로 이동하므로 AWS Connector 앱을 GitHub에 승인해야 합니다. 개인 계정 저장소의 경우 본인 계정으로 승인하면 되고, 조직(org) 저장소의 경우 조직 소유자 권한으로 AWS Connector 앱을 설치해야 합니다. 승인이 완료되면 AWS 측에 Connection(연결) 자원이 생성되고, CodePipeline 콘솔로 돌아와 해당 연결을 선택할 수 있습니다.

CodePipeline - Github App

GitHub 소스 연동을 설정하는 CodePipeline 콘솔 화면 예시입니다. 소스 공급자로 GitHub (via GitHub App)을 선택하고 “Connect to GitHub”를 클릭하면 AWS와 GitHub 간 연결을 생성하게 됩니다. 연결 생성 후에는 목록에서 GitHub 연결과 해당 리포지토리를 선택할 수 있습니다. 이렇게 하면 CodePipeline이 지정한 GitHub 저장소의 특정 브랜치를 소스 코드로 사용하여 파이프라인을 트리거할 수 있습니다.

1. 리포지토리 및 브랜치 선택: GitHub 연결을 완료한 후, Repository 이름 목록에서 파이프라인에 사용할 GitHub 리포지토리를 선택하고 브랜치를 지정합니다. 예를 들어 my-repo의 main 브랜치를 소스로 지정할 수 있습니다. 이후 파이프라인을 생성하면 이 리포지토리의 해당 브랜치에 새로운 커밋이 푸시될 때마다 CodePipeline이 실행되도록 설정됩니다.
2. Full Clone 옵션 (선택 사항): CodePipeline 소스 단계 설정 시 “Full clone” 옵션을 활성화할 수 있습니다. 기본적으로 CodePipeline은 소스 코드를 ZIP 파일 형태로 받아 빌드 단계에 전달하지만, Full clone을 사용하면 CodeBuild 단계에서 Git 클론을 수행하여 전체 Git 히스토리를 가져올 수 있습니다. 예를 들어 Git 커밋 해시나 이전 기록을 빌드 과정에서 활용해야 한다면 Full clone 모드를 선택하세요. 단, 이 옵션을 켜면 초기 파이프라인 실행 시 권한 오류가 발생할 수 있는데, 이는 다음 섹션에서 다루겠습니다.

CodePipeline - Create a connection

참고: 기존에 CodePipeline 서비스 역할(파이프라인 실행 IAM Role)을 2019년 12월 18일 이전에 생성했다면, GitHub 연결 기능을 사용하기 전에 해당 역할에 codestar-connections:UseConnection 권한을 추가로 부여해야 합니다. 최신 파이프라인 생성 마법사는 필요한 권한을 자동으로 포함하지만, 오래된 IAM 역할을 재사용한다면 권한을 확인해주세요.

CodePipeline - Git Connection

※ 상세설명

[Install a new app]을 선택하여 Github 계정에 연동프로그램을 설치하자.
- 특정 공급자에 대한 모든 연결에 대해 하나의 앱을 설치합니다. AWS Connector for GitHub 앱을 이미 설 치한 경우 해당 앱을 선택하고이 단계를 건너뜀
- 권한 허용 [All repositories] 선택
- AWS Connector for GitHub는 AWS 서비스(특히 CodePipeline, CodeBuild 등)가 여러분의 GitHub 리포지토리와 상호작용할 수 있도록 중개자 역할을 하는 AWS Marketplace 애플리케이션입니다.
= 이유: AWS 서비스는 기본적으로 GitHub와 직접 통신할 수 없습니다. GitHub는 보안상의 이유로 외부 애플리케이션이 자신의 리포지토리에 접근할 때 명시적인 권한 부여를 요구합니다. AWS Connector for GitHub는 이러한 보안 채널과 인증 메커니즘을 제공하여 AWS 서비스가 GitHub에서 코드를 가져오거나 (CodePipeline 소스), 빌드 상태를 업데이트하거나 (CodeBuild), 배포 후 결과를 통지하는 등의 작업을 수행할 수 있게 해줍니다.
= Install App은 GitHub Marketplace에서 제공하는 애플리케이션을 여러분의 GitHub 계정에 설치 하는 과정입니다. 이는 GitHub의 보안 모델에 따라 AWS Connector for GitHub가 여러분의 리포지 토리에 접근하고 작업을 수행할 수 있는 공식적인 권한을 부여하는 행위입니다.
- Only select repositories : 해당 git이 여러 repository(보안상 안전이 필요한 것)이 있는 경우 All 권한은 지양한다.

Full Clone

CodePipeline 오류 해결 팁 (권한 문제 및 기타 함정)

실무에서 CodePipeline과 GitHub을 연동하여 CI/CD 파이프라인을 구축할 때 흔히 마주친 문제들과 오류 해결 팁을 정리했습니다:

• codestar-connections:UseConnection 권한 오류: 파이프라인을 설정한 후 첫 빌드 실행에서 실패하고, CodeBuild 로그에 아래와 같은 에러 메시지가 나타날 수 있습니다:

User: ANONYMOUS_USER is not authorized to perform: codestar-connections:UseConnection on resource: connection-ARN

 

이 오류는 CodeBuild의 서비스 역할(CodeBuild IAM Role)에 해당 GitHub 연결(Connection)을 사용할 권한이 없어서 발생합니다. 앞서 Full clone 옵션을 활성화한 경우에 특히 이 문제가 나타납니다. 해결 방법은 간단합니다. 문제가 된 CodeBuild 서비스 IAM 역할에 다음과 같은 정책을 추가해주세요:

{ 
 "Version": "2012-10-17", 
 "Statement": [ 
 { 
 "Effect": "Allow", 
 "Action": "codestar-connections:UseConnection", 
 "Resource": "arn:aws:codeconnections:ap-northeast-2:1234567890:connection/1234545676-1234-4724-9861-1234543" 
 }  ] 
}

 

• 위 예시는 모든 Connection 자원에 대한 권한을 부여하고 있지만, 보안상 권장되는 방법은 Resource에 특정 연결의 ARN 값을 넣어 해당 GitHub 연결에만 권한을 주는 것입니다. 정책 적용 후 파이프라인을 재실행하면 인증 오류 없이 정상적으로 소스 코드를 가져올 수 있습니다.
• 파이프라인이 커밋 푸시에 반응하지 않을 때: CodePipeline을 생성한 후 GitHub에 코드를 푸시했는데 파이프라인이 시작되지 않는다면, 연결 상태와 트리거 설정을 점검해야 합니다. AWS 콘솔의 CodePipeline > 해당 파이프라인 > 편집 메뉴에서 소스 단계의 Webhook 또는 Trigger 설정을 확인하세요.
  일반적으로 GitHub (CodeStar 연결) 소스는 내부적으로 웹훅/이벤트로 연동되며 Poll 설정이 필요없지만, 연결이 Pending 상태이거나 제대로 완료되지 않았을 경우 트리거되지 않을 수 있습니다.
  이때는 AWS Developer Tools의 Connections 설정 페이지에서 해당 GitHub 연결의 상태가 Available(사용 가능)인지 확인하고, 필요하다면 연결을 다시 생성합니다. 또한 파이프라인을 처음 만들었을 때 수동으로 한 번 Release change를 눌러줘야 초기 실행이 되는 경우도 있으니 참고하세요.
• buildspec.yml을 찾지 못해 CodeBuild 실패: 파이프라인의 Build 단계에서 빌드 스펙 파일을 찾지 못했다는 오류로 실패하는 경우, 두 가지를 확인해야 합니다.
  (1) 레포지토리에 buildspec.yml 파일이 존재하고 루트 디렉터리에 위치해있는지,
  (2) 또는 CodeBuild 프로젝트 설정에서 사용자 지정 buildspec 경로를 올바르게 지정했는지입니다.
  기본적으로 CodeBuild는 소스 루트에 있는 buildspec.yml 파일을 자동으로 찾습니다. 파일명이 다르거나 위치가 다르면 파이프라인 생성 시 해당 경로를 설정해야 합니다.
• Artifacts 미출력 및 S3 업로드 문제: CodeBuild 빌드는 성공했지만 아티팩트가 S3에 없거나 다음 단계로 전달되지 않는 문제를 겪을 수 있습니다. 이는 대개 buildspec.yml의 artifacts 섹션 설정이 잘못되었을 때 발생합니다. artifacts 섹션은 빌드 완료 후 어떤 파일들을 결과물로 묶어서 S3에 업로드할지 지정하는 부분으로, 제대로 설정되지 않으면 CodePipeline이 빌드 산출물을 인식하지 못합니다.
  예를 들어 빌드 결과물이 특정 경로에 생성되는데 artifacts에 그 경로가 포함되지 않으면 S3에 파일이 업로드되지 않습니다. 해결책은 buildspec.yml의 artifacts files에 원하는 산출물 경로를 정확히 지정하고, 불필요한 디렉토리 경로를 제거하려면 discard-paths: yes 옵션을 사용하는 것입니다. 설정을 수정한 후에는 파이프라인을 재실행하여 S3 버킷에 아티팩트 ZIP 파일이 생성되는지 확인합니다.
• 기타 IAM 권한 관련: CodePipeline을 구성하는 서비스들은 서로 연동하기 위해 IAM 권한이 필요합니다. 일반적으로 파이프라인 생성 과정에서 CodePipeline 역할과 CodeBuild 역할이 자동 생성되며 필요한 권한이 부여됩니다. 하지만 커스터마이징이나 수동 설정 시에는 아래 권한도 고려하세요:
  • CodePipeline 서비스 역할에는 CodeBuild를 시작할 수 있는 codebuild:StartBuild 등의 권한이 필요합니다.
  • CodeBuild 서비스 역할에는 S3 아티팩트 버킷에 객체를 업로드할 수 있는 s3:PutObject 권한 등이 필요합니다.
  • 배포 단계를 AWS CodeDeploy와 연동하는 경우 CodeDeploy 권한이나 EC2 접근 권한 등이 추가로 필요할 수 있습니다.
  대부분 이러한 권한은 AWS에서 미리 정의한 관리형 정책이나 파이프라인 생성 마법사에서 자동 처리되지만, 오류 메시지에 Access Denied가 나타나면 어떤 액션에 대한 권한이 부족한지 확인하고 해당 IAM Role에 정책을 추가하면 해결됩니다.

buildspec.yml 설명 (구성 요소와 작성 방법)

AWS CodeBuild를 사용할 때는 buildspec.yml이라는 빌드 스펙 파일을 작성해야 합니다. buildspec.yml 파일은 CodeBuild가 빌드를 실행하는 데 사용하는 YAML 형식의 빌드 명령 및 설정 모음입니다. 파이프라인의 Build 단계에서 CodeBuild는 이 파일을 읽어 빌드 절차를 자동으로 수행하므로, CI/CD 구성 시 매우 중요합니다. 여기서는 buildspec.yml의 주요 구성 요소인 version, phases, commands, artifacts 섹션에 대해 자세히 설명하겠습니다:

• version: buildspec 파일 형식의 버전을 명시합니다. 현재 최신 버전은 "0.2"이며, YAML 맨 첫 줄에 version: 0.2로 작성합니다. (구버전인 0.1은 사용법이 조금 달랐지만 이제는 0.2 사용을 권장합니다.)
• phases: 빌드 과정을 단계별(phase)로 기술하는 섹션입니다. 보통 install, pre_build, build, post_build의 4단계로 구분하며, 필요한 단계만 선택적으로 사용합니다. 각 단계마다 commands 리스트를 지정하여 해당 단계에서 실행할 쉘 명령어들을 순서대로 나열합니다. 예를 들어 install 단계에서는 의존성 설치를, pre_build 단계에서는 환경 설정이나 로그인(예: Docker 로그인)을, build 단계에서는 실제 빌드 작업을, post_build 단계에서는 빌드 결과 확인이나 정리 작업을 수행할 수 있습니다. 모든 단계가 필수는 아니며, 단순한 빌드라면 build 한 단계만 두고 나머지는 생략할 수도 있습니다.
• commands: 각 phase 아래에 위치하며, 해당 단계에서 실행될 구체적인 커맨드들을 순서대로 작성합니다. 예를 들어 npm 프로젝트의 빌드라면 build 단계의 commands에 "npm install"과 "npm run build"를 추가할 수 있습니다. 명령어는 순서대로 실행되며, 하나라도 실패하면 CodeBuild 빌드가 실패로 간주됩니다. Bash 명령어뿐 아니라 스크립트 실행 등도 자유롭게 넣을 수 있습니다. (참고로 env나 runtime-versions 등의 설정을 통해 빌드 환경(예: Node.js 버전, 자격 증명 등)을 지정할 수도 있습니다.)
• artifacts: 빌드 완료 후 산출물(Artifact)로서 다음 단계에 넘길 파일들을 정의하는 섹션입니다. CodeBuild는 이 artifacts 설정에 따라 지정된 파일들을 압축(zip)하여 S3의 파이프라인 버킷에 업로드하고, CodePipeline은 이를 받아 다음 단계(배포 등)의 입력 아티팩트로 사용합니다. artifacts 섹션에는 최소한 files 속성을 포함해야 하며, 여기서 "**/*" 같은 패턴이나 구체적인 파일 경로를 지정합니다.
  예를 들어 Maven 빌드에서 생성된 target/myapp.war 파일 하나만 배포한다면 files: - target/myapp.war 식으로 지정하면 됩니다. 추가로 discard-paths: yes 옵션을 주면 경로 구조를 제거하고 파일 자체만 압축 루트에 넣어줍니다. artifacts를 제대로 설정하지 않으면 CodeBuild가 어떤 결과물을 내보내야 할지 모르기 때문에 필수로 올바르게 작성해야 합니다. (여러 출력물이 필요한 고급 시나리오에서는 secondary-artifacts 섹션을 사용하여 추가 아티팩트를 정의할 수도 있습니다.)

아래는 예시적인 buildspec.yml 파일의 구조입니다:

version: 0.2
phases:
  install:
    runtime-versions:
      nodejs: 14
    commands:
      - echo "Installing dependencies"
      - npm install
  build:
    commands:
      - echo "Building project"
      - npm run build
  post_build:
    commands:
      - echo "Build stage completed successfully."
artifacts:
  files:
    - "build/**/*"
  discard-paths: yes

 

위 예시에서, version을 명시한 뒤 phases 아래에 설치, 빌드, 포스트빌드 단계를 정의하였습니다. 각 단계에는 수행할 commands 목록이 들어가 있습니다. 마지막으로 artifacts 섹션에서는 build/ 디렉토리 내 모든 파일을 결과물로 압축하여 출력하도록 지정했습니다. 실제 사용 시에는 프로젝트에 맞게 파일 경로나 명령어를 변경해야 합니다. 이처럼 buildspec.yml을 작성해두면, CodeBuild가 빌드 실행 시 이 설정대로 동작하며 빌드 로그를 통해 각 명령어의 출력 결과를 확인할 수 있습니다.

Codepipeline - codebuild.yml

S3 output - jar

Tip: buildspec.yml 파일을 레포지토리 루트에 넣고 소스와 함께 관리하면 형상 관리에 용이합니다. CodePipeline에서는 기본적으로 해당 파일을 찾아 사용하며, 만약 다른 경로나 이름을 쓰고 싶다면 파이프라인 설정에서 Build stage 편집 시 “Buildspec name”을 지정할 수 있습니다.

Artifact 개념 이해 (파이프라인 산출물 알아보기)

아티팩트(Artifact)란 CodePipeline 파이프라인 실행 중에 생성되어 다음 단계로 전달되는 파일 묶음(산출물)을 말합니다. 쉽게 말해, 파이프라인 각 단계의 출력물(output)이며 동시에 다음 단계의 입력물(input)로 활용되는 패키지입니다. AWS 공식 문서에 따르면 “아티팩트는 애플리케이션 코드가 있는 파일 또는 폴더, 인덱스 페이지 파일, 스크립트 등과 같이 파이프라인의 작업에 의해 작동되는 파일”을 의미합니다. 예를 들어보겠습니다:

• 소스 단계의 아티팩트: GitHub 소스에서 가져온 애플리케이션 코드 파일들이 ZIP으로 묶여 출력 아티팩트가 됩니다. 이 ZIP 파일에는 해당 커밋의 모든 소스가 담겨 있으며, CodePipeline이 내부적으로 관리하는 S3 버킷에 업로드됩니다.
• 빌드 단계의 아티팩트: 빌드 단계(CodeBuild)는 입력으로 소스 단계의 출력 아티팩트(소스 ZIP)를 받아 빌드 명령을 실행합니다. 빌드가 완료되면 컴파일된 산출물(예: WAR 파일, Docker 이미지 파일 등)을 다시 ZIP으로 묶어 출력 아티팩트로 만들고, 이것을 S3에 업로드합니다. 이렇게 생성된 빌드 산출물 ZIP이 다음 배포 단계 등의 입력 아티팩트가 됩니다.
• 배포 단계의 아티팩트: 배포 단계(CodeDeploy 등)는 빌드 단계의 출력물을 입력으로 받아 실제 배포 작업을 수행합니다. 예컨대, S3에 올라온 ZIP을 EC2 서버에 내려받아 압축을 풀고, 애플리케이션을 배포하는 식입니다. 배포가 끝나면 그 단계에서 별도의 새로운 아티팩트를 만들지는 않지만, 로그나 결과물이 나올 수는 있습니다.

위 흐름에서 볼 수 있듯이, 아티팩트는 릴레이 경주에서 바통과 같은 역할을 합니다. 개발자가 작성한 소스 코드라는 바통이 소스 단계에서 출발해, 빌드 단계를 거쳐 컴파일된 애플리케이션이라는 바통으로 바뀌고, 최종적으로 배포 단계까지 전달되는 것입니다. 이 바통(아티팩트)은 AWS 내부의 S3 버킷을 통해 안전하게 전송되고 보관됩니다.

Artifact 저장 버킷: 처음 CodePipeline을 생성하면 AWS가 자동으로 전용 S3 버킷을 만들어 아티팩트를 저장합니다. 버킷 이름은 보통 codepipeline-<region>-<계정ID> 형태이며, 파이프라인별로 고유한 폴더를 생성하여 그 안에 단계별 아티팩트를 관리합니다. 사용자는 굳이 이 버킷을 직접 다룰 필요는 없지만, 필요한 경우 해당 버킷에서 산출물 ZIP 파일을 다운로드하거나 권한을 설정할 수 있습니다. 다만 파이프라인을 삭제하면 관련 폴더의 파일도 정리되는 점을 기억하세요.

요약하자면, Artifact는 CodePipeline 파이프라인의 각 단계 산출물을 담은 파일 꾸러미입니다. 이를 통해 이전 단계의 출력이 다음 단계의 입력으로 매끄럽게 전달되어, 전체 CI/CD 프로세스가 자동화되고 연결되는 것이죠.

 

※ 다음글

2025.08.01 - [IT 트렌드/알아두면 좋은 IT 상식] - AWS Elastic Beanstalk를 활용한 Spring Boot 자동 배포: CodePipeline 연동 가이드

AWS Elastic Beanstalk를 활용한 Spring Boot 자동 배포: CodePipeline 연동 가이드

 

FAQ (자주 묻는 질문)

Q1. GitHub 연동 후 새로운 커밋이 생겼는데도 파이프라인이 자동 실행되지 않아요. 어떻게 해야 하나요?
A1. 먼저 CodePipeline 콘솔에서 해당 파이프라인의 소스 단계가 성공적으로 설정되었는지 확인하세요. GitHub 연결이 Available 상태여야 하며, 올바른 리포지토리와 브랜치가 지정되어 있어야 합니다. 커밋 푸시 후 보통 수십 초 내에 파이프라인이 시작됩니다. 실행되지 않는다면 웹훅(Webhook) 이슈일 수 있으므로, 개발자 도구 Connections 페이지에서 연결을 다시 한번 확인하거나, 필요한 경우 파이프라인 소스 설정에서 Poll for source changes 옵션을 활성화해보세요. (단, Polling 활성화 시 1분 주기로 체크하므로 지연이 있을 수 있습니다.)

Q2. CodeBuild 단계에서 buildspec.yml 없이도 빌드를 실행할 수 있나요?
A2. 기본적으로 buildspec.yml 파일이 필요합니다. 해당 파일에 빌드 명령과 절차가 정의되어 있어야 CodeBuild가 자동으로 빌드를 진행할 수 있습니다. 만약 프로젝트에 buildspec.yml을 포함시키기 어렵다면, CodeBuild 설정에서 명령 내장 옵션을 사용해 콘솔에 직접 빌드 명령을 입력할 수도 있지만 실추천되지는 않습니다. 가장 좋은 방법은 레포지토리 루트에 buildspec.yml을 포함하여 형상 관리하는 것입니다.

Q3. GitHub 연동을 위해 AWS에 개인 액세스 토큰을 제공해야 하나요?
A3. 아니요. AWS CodePipeline은 AWS Connector for GitHub 앱을 통해 OAuth로 인증하므로, 사용자가 별도로 GitHub Personal Access Token을 발행하여 넣을 필요가 없습니다. AWS CodeStar Connector 설정 과정에서 GitHub 승인을 한 번 거치면, 그 이후로는 해당 연결이 지속적으로 사용됩니다. 다만, OAuth 토큰 만료나 권한 변경이 발생하면 연결을 다시 인증해야 할 수도 있습니다. (CodePipeline 설정에서 커넥션 재인증 옵션을 통해 갱신 가능합니다.)

Q4. CodePipeline의 Artifact ZIP 파일을 직접 다운로드하고 싶습니다. 어디에서 찾을 수 있나요?
A4. 파이프라인 실행이 끝난 후 CodePipeline 콘솔의 해당 실행 내역을 보면, 각 단계의 출력 아티팩트에 S3 경로가 표시됩니다. 또는 AWS S3 콘솔에서 CodePipeline이 생성한 아티팩트 버킷을 찾아가 파이프라인 이름 폴더 아래 Artifact.zip 파일을 확인할 수도 있습니다. 파일명을 커스텀하게 지정하지 않았다면 보통 artifact.zip이나 codepipeline.zip과 같은 이름으로 저장됩니다. 해당 파일을 선택해 다운로드하면 빌드 산출물을 얻을 수 있습니다. (단, 보안상 이 버킷은 기본적으로 계정 내부에서만 접근 가능하며 퍼블릭 접근이 차단되어 있습니다.)

Q5. 파이프라인을 수정하여 새 리포지토리나 브랜치를 연결하려면 어떻게 해야 하나요?
A5. CodePipeline 콘솔에서 파이프라인을 편집(Edit) 한 뒤, Source 단계를 편집하여 다른 GitHub 리포지토리/브랜치를 선택할 수 있습니다. 이때 새로운 GitHub 저장소가 기존 연결과 다른 경우 새로운 Connection을 생성해야 할 수도 있습니다. 편집 내용을 저장하면 이후부터는 변경된 소스에 대해 파이프라인이 동작합니다. (만약 빌드나 배포 단계도 경로 등이 바뀐다면 buildspec.yml이나 배포 설정도 함께 수정해주어야 합니다.)

결론 및 핵심 요약 (Call to Action)

AWS CodePipeline과 GitHub 연동을 통해 코드 변경이 자동으로 빌드되고 배포되는 CI/CD 파이프라인을 구축하는 방법을 살펴보았습니다. 정리하면 다음과 같습니다:

• GitHub 연동: AWS CodeStar Connector로 손쉽게 OAuth 연결을 맺고 GitHub 커밋을 파이프라인 트리거로 사용한다. (키워드: AWS CodePipeline에서 GitHub 연동)
• 권한 문제 해결: 초기 설정 시 IAM 권한 에러(codestar-connections:UseConnection)가 발생할 수 있으며, CodeBuild 역할 등에 권한 정책을 추가해 해결한다.
• buildspec.yml: 빌드 단계의 청사진으로, 버전/페이즈/명령어/아티팩트 섹션을 정확히 작성해야 원활한 빌드와 아티팩트 출력이 가능하다.
• Artifact 개념: 파이프라인 단계 간에 전달되는 산출물 패키지로, S3 버킷을 통해 관리되며 다음 단계의 입력으로 쓰인다.

이러한 핵심 내용들을 토대로, 여러분의 프로젝트에 CI/CD를 적용해 보세요. AWS CodePipeline에서 GitHub 연동을 설정하면 코드 푸시 한 번으로 빌드부터 배포까지 자동화할 수 있어 개발 속도가 크게 향상됩니다. 실무에서도 유용한 트러블슈팅 팁들을 공유했으니 비슷한 문제를 만났을 때 참고하시기 바랍니다. 이제 직접 여러분의 AWS 환경에 적용해보세요! 궁금한 점이나 추가적인 팁이 있다면 댓글로 남겨주시고, 도움이 되셨다면 공유도 부탁드립니다. 🚀