소개
지속적 배포(CD) 는 검증된 소프트웨어를 실행할 수 있는 환경으로 전달하는 단계입니다.
소프트웨어 공장을 다시 떠올려 보겠습니다.
- CI: 로봇이 결함을 검사합니다.
- Artifact: 로봇이 제품을 상자에 포장합니다.
- CD: 배송 트럭이 상자를 매장 (Server) 으로 운반하여 고객이 사용할 수 있게 합니다.
실제 환경에서 배포는 SSH, API 또는 플랫폼별 릴리스 메커니즘을 사용해 실행 중인 시스템을 업데이트하는 작업을 의미하는 경우가 많습니다. 이 실습에서는 그 과정을 시뮬레이션합니다. 여기서 중요한 점은 테스트를 통과한 코드가 실행 환경으로 전달되는 흐름입니다.
이것이 CI 와 CD 의 핵심적인 차이입니다. CI 는 소프트웨어 변경 사항이 배포를 고려할 만큼 안정적인지 확인하고, CD 는 검증된 변경 사항을 환경에 통제된 방식으로 반영합니다.
이 실습에서는 다음을 수행합니다.
- 수동 트리거(클릭하여 배포) 의 개념을 배웁니다.
- 실제 배포 과정을 시뮬레이션하는 배포 워크플로를 작성합니다.
- "배송 트럭"(CD) 을 "품질 관리"(CI) 에 연결합니다.
사전 요구 사항
계속해서 github-actions-basics 저장소를 사용합니다.
수동 배포 만들기
코드를 푸시할 때마다 배포하고 싶지는 않을 수 있습니다. 승인을 기다리거나, 준비가 되었을 때만 배포해야 할 수도 있습니다.
수동 트리거와 스테이징 환경이 자주 사용되는 이유가 여기에 있습니다. 배포 파이프라인은 성공한 빌드를 즉시 프로덕션에 배포하기보다 속도와 운영상의 신중함 사이에서 균형을 잡는 경우가 많습니다.
GitHub Actions 를 사용하면 버튼을 클릭했을 때만 실행되는 워크플로를 만들 수 있습니다. 이를 위해 workflow_dispatch 트리거를 사용합니다.
프로젝트의 워크플로 디렉터리로 이동합니다.
cd ~/project
git clone https://github.com/your-username/github-actions-basics.git
cd github-actions-basics
참고: your-username을 실제 GitHub 사용자 이름으로 바꾸세요.
deploy.yml이라는 새 파일을 만듭니다.
touch .github/workflows/deploy.yml
nano로 파일을 엽니다.
nano .github/workflows/deploy.yml
다음 내용을 추가합니다.
name: Deploy to Production
on: workflow_dispatch
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Deploying
run: echo "Starting deployment..."
on: workflow_dispatch가 보이나요? 이것이 마법의 버튼입니다.
nano에서 저장하고 종료한 다음, 이 파일을 GitHub 에 푸시합니다.
git add .
git commit -m "Add manual deployment workflow"
git push
이제 GitHub 에서 Actions 탭으로 이동합니다.
- 왼쪽 사이드바에서 Deploy to Production을 클릭합니다.
- "This workflow has a dispatch event trigger."라는 문구가 표시된 파란색 배너가 나타납니다.
- Run workflow 버튼을 클릭한 다음, 드롭다운에 표시되는 초록색 Run workflow 버튼을 클릭합니다.

이제 배포 파이프라인을 수동으로 트리거했습니다!
배포 단계 시뮬레이션
실제 배포 스크립트는 복잡할 수 있지만, 일반적으로 다음과 같은 간단한 패턴을 따릅니다.
- 서버에 연결합니다.
- 소프트웨어의 새 버전을 가져옵니다.
- 애플리케이션을 다시 시작합니다.
구현 방식은 달라도 대부분의 배포 파이프라인은 인증하고, 원하는 아티팩트를 가져오고, 실행 중인 환경에서 해당 아티팩트를 사용하도록 만드는 일반적인 구조를 따릅니다.
이제 deploy.yml을 수정하여 이 단계를 시뮬레이션합니다. echo 명령을 사용해 실제로 수행될 작업을 표시합니다.
파일을 다시 엽니다.
nano .github/workflows/deploy.yml
jobs 섹션을 다음과 같이 더 자세한 시뮬레이션 내용으로 바꿉니다.
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Mock SSH Connection
run: echo "Connecting to production server at 192.168.1.1..."
- name: Pull New Image
run: |
echo "Logging into Registry..."
echo "Pulling image ghcr.io/myname/app:latest..."
- name: Restart Application
run: |
echo "Stopping old container..."
echo "Starting new container..."
echo "Deployment Successful!"
저장하고 종료합니다. 변경 사항을 푸시합니다.
git add .
git commit -m "Update deployment steps"
git push
GitHub Actions 로 돌아가 Deploy to Production 워크플로를 다시 수동으로 실행합니다. 로그를 확인합니다. 실제 배포와 매우 비슷하게 보일 것입니다!

이 "Mock" 기법은 실제로 매우 유용합니다. 전문적인 환경에서는 복잡한 실제 코드를 작성하기 전에 이러한 "Skeleton" 워크플로를 먼저 작성하여 프로세스에 합의하는 경우가 많습니다.
안전성 검사 추가
현재 "Deploy" 워크플로는 "Test"(CI) 워크플로와 완전히 분리되어 있습니다. 하지만 실제 환경에서는 오류가 있는 코드를 절대 배포해서는 안 됩니다. 품질 검사를 통과한 경우에만 배송 트럭이 출발하도록 해야 합니다.
needs 키워드를 사용해 워크플로를 연결할 수 있지만, 이 방법은 하나의 파일 안에서 사용할 때 가장 적합합니다. 별도의 파일을 사용하는 경우에는 일반적으로 프로세스로 관리합니다 (CI 는 Push 에서 실행하고, CD 는 Release 또는 수동 실행에서 실행).
이제 수동 배포에도 안전성 검사를 추가하는 방법을 알아봅니다. 여기서는 확실히 검증된 경우에만 배포한다고 가정합니다.
deploy.yml을 엽니다.
nano .github/workflows/deploy.yml
environment 보호 기능을 시뮬레이션하는 내용을 추가합니다. steps에 일시 중지 단계를 포함하도록 수정합니다.
steps:
- name: Safety Check
run: echo " verifying that CI passed..."
- name: Mock SSH Connection
run: echo "Connecting to production server at 192.168.1.1..."
## ... rest of the file
(참고: 실제 Enterprise 환경에서는 GitHub Environments라는 기능을 사용해 이 작업이 실행되기 전에 "CI must pass" 조건을 적용할 수 있습니다. 하지만 이를 사용하려면 이 파일 외부에서 별도의 구성을 해야 합니다.)
지금은 저장하고 종료한 다음, 변경 사항을 푸시합니다.
git add .
git commit -m "Add safety check"
git push
마지막으로 워크플로를 한 번 더 수동으로 실행합니다.
요약
축하합니다! GitHub Actions CICD 모듈을 완료했습니다.
이 최종 실습에서는 다음을 배웠습니다.
- 수동 트리거:
workflow_dispatch를 사용해 배포를 제어하는 방법 - 시뮬레이션: Mock 단계를 사용해 배포 프로세스를 프로토타이핑하는 방법
- 전체 흐름: CI, 아티팩트, 보안, CD 가 어떻게 함께 연결되는지
GitHub Actions 에 대해 아무것도 모르는 상태에서 시작했지만, 이제 자동화된 테스트, 패키징, 배포 스크립트를 갖춘 완전히 작동하는 저장소를 만들었습니다. 이제 직접 프로젝트 자동화를 시작할 준비가 되었습니다!



