GSP330

개요

챌린지 실습에서는 특정 시나리오와 일련의 작업이 주어집니다. 단계별 안내를 따르는 대신, 과정의 실습에서 배운 기술을 사용하여 스스로 작업을 완료하는 방법을 알아내 보세요. 이 페이지에 표시되어 있는 자동 채점 시스템에서 작업을 올바르게 완료했는지 피드백을 제공합니다.

챌린지 실습을 진행할 때는 새로운 Google Cloud 개념에 대한 정보가 제공되지 않습니다. 학습한 기술을 응용하여 기본값을 변경하거나 오류 메시지를 읽고 조사하여 실수를 바로잡아야 합니다.

100점을 받으려면 시간 내에 모든 작업을 성공적으로 완료해야 합니다.

이 실습은 Google Cloud에서 DevOps 워크플로 구현 과정에 등록한 수강생에게 권장됩니다. 챌린지에 도전할 준비가 되셨나요?

실습 시작 버튼을 클릭하기 전에

다음 안내를 확인하세요. 실습에는 시간 제한이 있으며 일시중지할 수 없습니다. 실습 시작을 클릭하면 타이머가 시작됩니다. 이 타이머는 Google Cloud 리소스를 사용할 수 있는 시간이 얼마나 남았는지를 표시합니다.

실무형 실습을 통해 시뮬레이션이나 데모 환경이 아닌 실제 클라우드 환경에서 실습 활동을 진행할 수 있습니다. 실습 시간 동안 Google Cloud에 로그인하고 액세스하는 데 사용할 수 있는 새로운 임시 사용자 인증 정보가 제공됩니다.

이 실습을 완료하려면 다음을 준비해야 합니다.

• 표준 인터넷 브라우저 액세스 권한(Chrome 브라우저 권장)

참고: 이 실습을 실행하려면 시크릿 모드(권장) 또는 시크릿 브라우저 창을 사용하세요. 개인 계정과 학습자 계정 간의 충돌로 개인 계정에 추가 요금이 발생하는 일을 방지해 줍니다.

• 실습을 완료하기에 충분한 시간(실습을 시작하고 나면 일시중지할 수 없음)

참고: 이 실습에는 학습자 계정만 사용하세요. 다른 Google Cloud 계정을 사용하는 경우 해당 계정에 비용이 청구될 수 있습니다.

챌린지 시나리오

여러분은 몇 개월 전에 Cymbal Superstore의 DevOps 엔지니어로 채용되면서 이 회사에서 이커머스 웹사이트를 운영하는 방식을 전반적으로 파악하게 되었습니다. 특히 DevOps팀에서 현재 진행 중인 대규모 CI/CD 파이프라인 구축을 지원해 달라는 요청을 받았습니다. 이 파이프라인이 구축되면 사내 개발자가 작업을 자동화하고 다른 팀과 보다 효과적으로 협업하며 소프트웨어를 보다 자주 안정적으로 출시할 수 있게 됩니다. Cymbal Superstore에서는 파이프라인에 네이티브 Google Cloud 서비스와 현대적인 DevOps 관행을 사용하고자 하므로 여러분의 Git, Artifact Registry, Docker, Cloud Build 경험이 큰 도움이 될 것입니다.

이 프로젝트를 시작하기 전에 DevOps팀은 새로 습득한 기술 역량을 보여주기를 원합니다. 그 일환으로 DevOps팀에서는 여러분이 샌드박스 환경에서 지정된 시간 내에 수행해야 할 작업 목록을 만들었습니다.

챌린지

수행해야 할 작업은 다음과 같습니다.

• 제공된 일련의 구성을 기반으로 GKE 클러스터 만들기
• Go 애플리케이션 코드를 호스팅하기 위해 전용 Git 서버에서 Git 저장소 초기화하기
• 프로덕션 및 개발 애플리케이션을 배포하는 Cloud Build 트리거 만들기
• 앱에 업데이트를 푸시하고 새 빌드 만들기
• 프로덕션 애플리케이션을 이전 버전으로 롤백하기

전반적으로 전용 Git 서버의 Git 저장소, Artifact Registry, Cloud Build를 사용하여 간단한 CI/CD 파이프라인을 만듭니다.

작업 1. 실습 리소스 만들기

이 섹션에서는 데모 환경을 위해 Google Cloud 프로젝트를 초기화합니다. 환경 변수를 가져오고, 필요한 API를 사용 설정하고, Cloud Shell에서 Git을 구성하며, Artifact Registry Docker 저장소를 만들고, 프로덕션 및 개발 애플리케이션을 실행할 GKE 클러스터를 만듭니다.

1. Cloud Shell에서 다음 명령어를 실행하여 프로젝트 ID, 리전, Git 서버 IP를 설정합니다.

export PROJECT_ID=$(gcloud config get-value project) export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)') export REGION={{{ project_0.default_region }}} export ZONE={{{ project_0.default_zone }}} gcloud config set compute/region $REGION gcloud config set compute/zone $ZONE export GIT_SERVER_IP=$(gcloud compute instances describe git-server --zone=$ZONE --format='get(networkInterfaces[0].accessConfigs[0].natIP)') echo "Git Server IP is: ${GIT_SERVER_IP}"

2. 다음 명령어를 실행하여 GKE 및 Cloud Build용 API를 사용 설정합니다.

gcloud services enable container.googleapis.com \ cloudbuild.googleapis.com

3. Cloud Build 서비스 계정에 대해 Kubernetes Developer 역할을 추가합니다.

export PROJECT_ID=$(gcloud config get-value project) gcloud projects add-iam-policy-binding $PROJECT_ID \ --member=serviceAccount:$(gcloud projects describe $PROJECT_ID \ --format="value(projectNumber)")@cloudbuild.gserviceaccount.com --role="roles/container.developer"

4. Cloud Shell에서 사용자 이름과 이메일로 Git을 구성합니다.

git config --global user.name "Student" git config --global user.email "student@qwiklabs.net"

5. 리전에 my-repository라는 Artifact Registry Docker 저장소를 만들어 컨테이너 이미지를 저장합니다.

6. 다음 구성을 사용하여 hello-cluster라는 GKE Standard 클러스터를 만듭니다.

설정	값
영역
출시 채널	일반
클러스터 버전	1.29 이상
클러스터 자동 확장 처리	사용 설정됨
노드 수	3
최소 노드 수	2
최대 노드 수	6

7. 클러스터에 prod 및 dev 네임스페이스를 만듭니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 실습 리소스 만들기

작업 2. Git 서버의 Git 저장소에 연결하기

이 작업에서는 전용 Git 서버(git-server)에서 sample-app 저장소를 초기화하고 초기 샘플 코드를 푸시합니다. 이 저장소에는 Go 애플리케이션 코드가 있으며 빌드의 기본 소스가 됩니다.

1. 다음 명령어를 사용하여 샘플 코드를 sample-app 디렉터리에 복사합니다.

cd ~ gcloud storage cp -r gs://spls/gsp330/sample-app/* sample-app

2. 다음 명령어를 실행합니다. 그러면 cloudbuild-dev.yaml 파일과 cloudbuild.yaml 파일의 <your-region> 및 <your-zone> 플레이스홀더가 자동으로 프로젝트에 할당된 리전 및 영역으로 바뀝니다.

export REGION="{{{project_0.default_region | REGION}}}" export ZONE="{{{project_0.default_zone | ZONE}}}" for file in sample-app/cloudbuild-dev.yaml sample-app/cloudbuild.yaml; do sed -i "s/<your-region>/${REGION}/g" "$file" sed -i "s/<your-zone>/${ZONE}/g" "$file" done

3. sample-app 디렉터리에서 Git 저장소를 초기화하고, 샘플 코드로 최초 커밋을 수행하고, Git 서버의 master 브랜치에 변경사항을 푸시합니다.

cd ~/sample-app git init git remote add origin http://${GIT_SERVER_IP}:3000/giteaadmin/sample-app.git git branch -m master git add . && git commit -m "initial commit" git push -u http://giteaadmin:GiteaPassword123@${GIT_SERVER_IP}:3000/giteaadmin/sample-app.git master

4. dev라는 브랜치를 만들고, sample-app 디렉터리에 추가된 샘플 코드로 커밋을 수행하고, dev 브랜치에 변경사항을 푸시합니다.

cd ~/sample-app git checkout -b dev git push -u http://giteaadmin:GiteaPassword123@${GIT_SERVER_IP}:3000/giteaadmin/sample-app.git dev

5. 샘플 코드와 브랜치를 Git 저장소에 저장했는지 확인합니다.

방금 클론한 코드는 Red와 Blue의 2가지 진입점이 있는 간단한 Go 애플리케이션을 포함합니다. 각 진입점은 접속하는 경로에 따라 웹페이지에 서로 다른 색상의 정사각형을 보여줍니다.

작업 3. Cloud Build 트리거 만들기

이 섹션에서는 두 개의 Cloud Build 트리거를 만듭니다.

• sample-app-prod-deploy라는 첫 번째 트리거는 cloudbuild.yaml 구성 파일을 사용하여 애플리케이션 컨테이너 이미지를 빌드하고 이를 GKE 클러스터의 prod 네임스페이스에 배포합니다.

• sample-app-dev-deploy라는 두 번째 트리거는 cloudbuild-dev.yaml 구성 파일을 사용하여 애플리케이션 컨테이너 이미지를 빌드하고 이를 GKE 클러스터의 dev 네임스페이스에 배포합니다.

1. sample-app-prod-deploy라는 Cloud Build 트리거를 만듭니다.

gcloud builds triggers create manual \ --name="sample-app-prod-deploy" \ --inline-config="cloudbuild.yaml" \ --region={{{ project_0.default_region }}}

2. sample-app-dev-deploy라는 Cloud Build 트리거를 만듭니다.

gcloud builds triggers create manual \ --name="sample-app-dev-deploy" \ --inline-config="cloudbuild-dev.yaml" \ --region={{{ project_0.default_region }}}

트리거 설정을 마쳤다면 이제 cloudbuild.yaml 및 cloudbuild-dev.yaml 파일에 정의된 대로 애플리케이션을 빌드하고 배포하는 Cloud Build 파이프라인을 직접 실행해 볼 수 있습니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. Cloud Build 트리거 만들기

작업 4. 애플리케이션의 첫 번째 버전 배포하기

이 섹션에서는 프로덕션 애플리케이션과 개발 애플리케이션의 첫 번째 버전을 빌드합니다.

첫 번째 개발 배포 빌드

1. Cloud Shell에서 sample-app 디렉터리에 있는 cloudbuild-dev.yaml 파일을 검사하여 빌드 프로세스의 단계를 확인합니다. cloudbuild-dev.yaml 파일에서 9줄과 13줄의 <version>을 v1.0으로 바꿉니다.

2. dev/deployment.yaml 파일로 이동하여 17줄의 <todo>를 올바른 컨테이너 이미지 이름으로 업데이트합니다. 또한 컨테이너 이미지 이름에서 PROJECT_ID 변수를 실제 프로젝트 ID로 바꿉니다.

참고: dev/deployment.yaml 파일과 cloudbuild-dev.yaml 파일의 컨테이너 이미지 이름이 동일한지 확인하세요.

3. dev 브랜치에서 변경사항을 커밋하고 Git 서버로 푸시합니다.

cd ~/sample-app git checkout dev git add . git commit -m "Deploy v1.0 on dev" git push http://giteaadmin:GiteaPassword123@${GIT_SERVER_IP}:3000/giteaadmin/sample-app.git dev

4. sample-app-dev-deploy 빌드 작업을 실행합니다.

cd ~/sample-app gcloud builds submit --config=cloudbuild-dev.yaml .

5. Cloud Build 기록 페이지에서 빌드가 성공적으로 실행되었는지 확인하고 development-deployment 애플리케이션이 클러스터의 dev 네임스페이스에 배포되었는지 확인합니다.

6. development-deployment 배포를 포트 8080에서 dev-deployment-service라는 LoadBalancer 서비스에 노출하고 컨테이너의 대상 포트를 Dockerfile에 지정된 포트로 설정합니다.

7. 서비스의 부하 분산기 IP로 이동하고 URL 끝에 /blue 진입점을 추가하여 애플리케이션이 실행 중인지 확인합니다. http://34.135.97.199:8080/blue와 유사한 형태여야 합니다.

첫 번째 프로덕션 배포 빌드

1. master 브랜치로 전환합니다. sample-app 디렉터리에 있는 cloudbuild.yaml 파일을 검사하여 빌드 프로세스의 단계를 확인합니다. cloudbuild.yaml 파일에서 11줄과 16줄의 <version>을 v1.0으로 바꿉니다.

2. prod/deployment.yaml 파일로 이동하여 17줄의 <todo>를 올바른 컨테이너 이미지 이름으로 업데이트합니다. 또한 컨테이너 이미지 이름에서 PROJECT_ID 변수를 실제 프로젝트 ID로 바꿉니다.

참고: prod/deployment.yaml 파일과 cloudbuild.yaml 파일의 컨테이너 이미지 이름이 동일한지 확인하세요.

3. master 브랜치에서 변경사항을 커밋하고 Git 서버에 변경사항을 푸시합니다.

cd ~/sample-app git checkout master git add . git commit -m "Deploy v1.0 on master" git push http://giteaadmin:GiteaPassword123@${GIT_SERVER_IP}:3000/giteaadmin/sample-app.git master

4. sample-app-prod-deploy 빌드 작업을 실행합니다.

cd ~/sample-app gcloud builds submit --config=cloudbuild.yaml .

5. Cloud Build 기록 페이지에서 빌드가 성공적으로 실행되었는지 확인하고 production-deployment 애플리케이션이 클러스터의 prod 네임스페이스에 배포되었는지 확인합니다.

6. prod 네임스페이스의 production-deployment 배포를 포트 8080에서 prod-deployment-service라는 LoadBalancer 서비스에 노출하고 컨테이너의 대상 포트를 Dockerfile에 지정된 포트로 설정합니다.

7. 서비스의 부하 분산기 IP로 이동하고 URL 끝에 /blue 진입점을 추가하여 애플리케이션이 실행 중인지 확인합니다. http://34.135.245.19:8080/blue와 유사한 형태여야 합니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 애플리케이션의 첫 번째 버전 배포하기

작업 5. 애플리케이션의 두 번째 버전 배포하기

이 섹션에서는 프로덕션 애플리케이션과 개발 애플리케이션의 두 번째 버전을 빌드합니다.

두 번째 개발 배포 빌드

1. dev 브랜치로 다시 전환합니다.

참고: 계속 진행하기 전에 dev 환경에 대한 배포를 만들 dev 브랜치에 있는지 확인하세요.

2. main.go 파일에서 main() 함수를 다음으로 업데이트합니다.

func main() { http.HandleFunc("/blue", blueHandler) http.HandleFunc("/red", redHandler) http.ListenAndServe(":8080", nil) }

3. main.go 파일의 내부에 다음 함수를 추가합니다.

func redHandler(w http.ResponseWriter, r *http.Request) { img := image.NewRGBA(image.Rect(0, 0, 100, 100)) draw.Draw(img, img.Bounds(), &image.Uniform{color.RGBA{255, 0, 0, 255}}, image.ZP, draw.Src) w.Header().Set("Content-Type", "image/png") png.Encode(w, img) }

4. cloudbuild-dev.yaml 파일을 검사하여 빌드 프로세스의 단계를 확인합니다. Docker 이미지의 버전을 v2.0으로 업데이트합니다.

5. dev/deployment.yaml 파일로 이동하여 컨테이너 이미지 이름을 새 버전(v2.0)으로 업데이트합니다.

6. dev 브랜치에서 변경사항을 커밋하고 Git 서버로 푸시합니다.

cd ~/sample-app git checkout dev git add . git commit -m "Deploy v2.0 on dev" git push http://giteaadmin:GiteaPassword123@${GIT_SERVER_IP}:3000/giteaadmin/sample-app.git dev

7. sample-app-dev-deploy 빌드 작업을 실행합니다.

cd ~/sample-app gcloud builds submit --config=cloudbuild-dev.yaml .

8. Cloud Build 기록 페이지에서 빌드가 성공적으로 실행되었는지 확인하고 development-deployment 애플리케이션이 클러스터의 dev 네임스페이스에 배포되었고 v2.0 이미지를 사용 중인지 확인합니다.

9. 서비스의 부하 분산기 IP로 이동하고 URL 끝에 /red 진입점을 추가하여 애플리케이션이 실행 중인지 확인합니다. http://34.135.97.199:8080/red와 유사한 형태여야 합니다.

참고: 업데이트가 부하 분산기에 적용되는 데 몇 분 정도 걸릴 수 있습니다.

두 번째 프로덕션 배포 빌드

1. master 브랜치로 전환합니다.

참고: 계속 진행하기 전에 master 환경에 대한 배포를 만들 master 브랜치에 있는지 확인하세요.

2. main.go 파일에서 main() 함수를 다음으로 업데이트합니다.

func main() { http.HandleFunc("/blue", blueHandler) http.HandleFunc("/red", redHandler) http.ListenAndServe(":8080", nil) }

3. main.go 파일의 내부에 다음 함수를 추가합니다.

func redHandler(w http.ResponseWriter, r *http.Request) { img := image.NewRGBA(image.Rect(0, 0, 100, 100)) draw.Draw(img, img.Bounds(), &image.Uniform{color.RGBA{255, 0, 0, 255}}, image.ZP, draw.Src) w.Header().Set("Content-Type", "image/png") png.Encode(w, img) }

4. cloudbuild.yaml 파일을 검사하여 빌드 프로세스의 단계를 확인합니다. Docker 이미지의 버전을 v2.0으로 업데이트합니다.

5. prod/deployment.yaml 파일로 이동하여 컨테이너 이미지 이름을 새 버전(v2.0)으로 업데이트합니다.

6. master 브랜치에서 변경사항을 커밋하고 Git 서버에 변경사항을 푸시합니다.

cd ~/sample-app git checkout master git add . git commit -m "Deploy v2.0 on master" git push http://giteaadmin:GiteaPassword123@${GIT_SERVER_IP}:3000/giteaadmin/sample-app.git master

7. sample-app-prod-deploy 빌드 작업을 실행합니다.

cd ~/sample-app gcloud builds submit --config=cloudbuild.yaml .

8. Cloud Build 기록 페이지에서 빌드가 성공적으로 실행되었는지 확인하고 production-deployment 애플리케이션이 클러스터의 prod 네임스페이스에 배포되었고 v2.0 이미지를 사용 중인지 확인합니다.

9. 서비스의 부하 분산기 IP로 이동하고 URL 끝에 /red 진입점을 추가하여 애플리케이션이 실행 중인지 확인합니다. http://34.135.245.19:8080/red와 유사한 형태여야 합니다.

참고: 업데이트가 부하 분산기에 적용되는 데 몇 분 정도 걸릴 수 있습니다.

좋습니다. 완벽하게 작동하는 프로덕션 및 개발 CI/CD 파이프라인을 성공적으로 만들었습니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 애플리케이션의 두 번째 버전 배포하기

작업 6. 프로덕션 배포 롤백하기

이 섹션에서는 프로덕션 배포를 이전 버전으로 롤백합니다.

1. production-deployment를 롤백하여 v1.0 버전의 애플리케이션을 사용합니다.

힌트: Cloud Build 기록을 사용하면 배포를 이전 버전으로 간편하게 롤백/다시 빌드할 수 있습니다.

2. 서비스의 부하 분산기 IP로 이동하고 프로덕션 배포의 URL 끝에 /red 진입점을 추가합니다. 페이지의 응답은 404가 되어야 합니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 프로덕션 배포 롤백하기

수고하셨습니다

수고하셨습니다. 이 실습에서는 Google Cloud에서 DevOps 워크플로를 구현하는 기술 역량을 확인했습니다. 먼저 애플리케이션을 실행할 GKE 클러스터를 구축한 후 코드베이스를 호스팅할 전용 Git 서버에 Git 저장소를 만들었습니다. 그런 다음 Cloud Build 트리거를 만들고 코드와 템플릿을 수정한 후 저장소에 업데이트를 푸시하여 첫 번째 개발 및 프로덕션 애플리케이션 빌드를 만들었습니다. 마지막으로 애플리케이션에 업데이트를 푸시하여 새 빌드를 만들고 프로덕션 애플리케이션을 이전 버전으로 롤백했습니다. 이제 사용자 환경에서 DevOps 작업을 시작할 준비가 되었습니다.

다음 기술 배지 획득

이 사용자 주도형 실습은 Google Cloud에서 DevOps 워크플로 구현 과정의 일부입니다. 이 기술 배지 과정을 완료하면 위의 배지를 획득하여 수료를 인증할 수 있습니다. 이력서 및 소셜 미디어 플랫폼에 배지를 공유하고 #GoogleCloudBadge 해시태그를 사용해 스스로 달성한 업적을 널리 알리세요.

이 기술 배지는 Google Cloud의 Cloud DevOps Engineer 학습 과정의 일부입니다. Google Cloud Observability로 모니터링 및 로깅 과정에 등록하여 학습 여정을 계속하세요.

Google Cloud 교육 및 자격증

Google Cloud 기술을 최대한 활용하는 데 도움이 됩니다. Google 강의에는 빠른 습득과 지속적인 학습을 지원하는 기술적인 지식과 권장사항이 포함되어 있습니다. 기초에서 고급까지 수준별 학습을 제공하며 바쁜 일정에 알맞은 주문형, 실시간, 가상 옵션이 포함되어 있습니다. 인증은 Google Cloud 기술에 대한 역량과 전문성을 검증하고 입증하는 데 도움이 됩니다.

설명서 최종 업데이트: 2026년 8월 27일

실습 최종 테스트: 2026년 8월 27일

Copyright 2026 Google LLC. All rights reserved. Google 및 Google 로고는 Google LLC의 상표입니다. 기타 모든 회사명 및 제품명은 해당 업체의 상표일 수 있습니다.