{"meta":{"title":"GitHub Actions 사용하여 배포","intro":"GitHub Actions를 사용하면 환경, 동시성 그룹 및 보호 규칙을 통해 배포 환경을 정밀하게 제어할 수 있습니다.","product":"GitHub Actions","breadcrumbs":[{"href":"/ko/actions","title":"GitHub Actions"},{"href":"/ko/actions/how-tos","title":"사용법"},{"href":"/ko/actions/how-tos/deploy","title":"배포"},{"href":"/ko/actions/how-tos/deploy/configure-and-manage-deployments","title":"배포 구성 및 관리"},{"href":"/ko/actions/how-tos/deploy/configure-and-manage-deployments/control-deployments","title":"제어 배포"}],"documentType":"article"},"body":"# GitHub Actions 사용하여 배포\n\nGitHub Actions를 사용하면 환경, 동시성 그룹 및 보호 규칙을 통해 배포 환경을 정밀하게 제어할 수 있습니다.\n\n## 필수 구성 요소\n\nGitHub Actions의 구문에 익숙해야 합니다. 자세한 내용은 [워크플로 작성](/ko/actions/learn-github-actions)을(를) 참조하세요.\n\n## 배포 트리거\n\n다양한 이벤트를 사용하여 배포 워크플로를 트리거할 수 있습니다. 가장 일반적인 것은 `pull_request`, `push`, `workflow_dispatch`입니다.\n\n예를 들어 다음 트리거가 있는 워크플로는 언제든 실행됩니다.\n\n* `main` 분기에 푸시가 있습니다.\n* `main` 분기를 대상으로 하는 끌어오기 요청이 열리거나 동기화되거나 다시 열립니다.\n* 누군가가 이를 수동으로 트리거합니다.\n\n```yaml\non:\n  push:\n    branches:\n      - main\n  pull_request:\n    branches:\n      - main\n  workflow_dispatch:\n```\n\n자세한 내용은 [워크플로를 트리거하는 이벤트](/ko/actions/using-workflows/events-that-trigger-workflows)을(를) 참조하세요.\n\n## 환경 사용\n\n환경은 일반적인 배포 대상(예: `production`, `staging` 또는 `development`)을 설명하는 데 사용됩니다. GitHub Actions 워크플로가 환경에 배포되면 환경이 리포지토리의 기본 페이지에 표시됩니다. 작업을 진행하기 위해 승인을 요구하거나 워크플로, 사용자 지정 배포 보호 규칙을 사용하여 게이트 배포를 트리거할 수 있는 분기를 제한하거나 비밀에 대한 액세스를 제한할 수 있습니다. 환경을 만드는 방법에 대한 자세한 내용은 [배포 환경 관리](/ko/actions/deployment/targeting-different-environments/managing-environments-for-deployment)을(를) 참조하세요.\n\n보호 규칙 및 비밀을 사용하여 환경을 구성할 수 있습니다. 워크플로 작업이 환경을 참조하는 경우 환경의 모든 보호 규칙이 통과될 때까지 작업이 시작되지 않습니다. 또한, 작업이 모든 배포 보호 규칙을 통과할 때까지 환경에 정의된 비밀에 액세스할 수 없습니다. 자세한 내용은 이 문서의 [사용자 지정 배포 보호 규칙 사용](#using-custom-deployment-protection-rules)을 참조하세요.\n\n## 동시성 사용\n\n동시성은 동일한 동시성 그룹을 사용하는 단일 작업 또는 워크플로만 한 번에 실행되도록 합니다. 환경에 최대 하나의 배포가 진행 중이고 한 번에 하나의 배포가 보류되도록 동시성을 사용할 수 있습니다. 동시성에 대한 자세한 내용은 [워크플로 및 작업의 동시 실행 제어](/ko/actions/using-jobs/using-concurrency)을(를) 참조하세요.\n\n## 배포 없이 환경 사용\n\n기본적으로 워크플로 작업이 환경을 참조하는 경우 GitHub는 배포를 추적하는 배포 개체를 만듭니다. 환경 구성에서 `deployment`를 `false`로 설정하여 배포 생성을 제외할 수 있습니다. 유효한 값은 `true` (기본값) 및 `false`. 예를 들어 `deployment: ${{ github.ref_name == 'main' }}`식을 사용할 수도 있습니다.\n\n```yaml\njobs:\n  test:\n    runs-on: ubuntu-latest\n    environment:\n      name: staging\n      deployment: false\n    steps:\n      - name: run tests\n        env:\n          API_KEY: ${{ secrets.API_KEY }}\n        run: echo \"Running tests with staging secrets\"\n```\n\n```\n          `deployment`가 `false`로 설정될 때:\n```\n\n* 작업에는 환경 비밀 및 변수에 대한 모든 권한이 있습니다.\n* GitHub 배포 개체가 만들어지지 않습니다. 환경에 대한 배포 기록이 업데이트되지 않습니다.\n* 대기 타이머 보호 규칙이 계속 적용됩니다. 작업은 구성된 기간 동안 대기합니다.\n* 필수 검토자는 여전히 적용됩니다. 검토자는 작업을 실행하기 전에 승인해야 합니다.\n\n이 기능은 다음을 위해 환경을 사용하려는 경우에 유용합니다.\n\n* **비밀 구성** - 배포 레코드를 만들지 않고 환경 이름으로 관련 비밀을 그룹화합니다.\n* **액세스 제어** - 배포 추적 없이 환경 분기 정책을 통해 특정 비밀을 사용할 수 있는 분기를 제한합니다.\n* **CI 및 테스트 작업** - 배포 기록에 노이즈를 추가하지 않고 구성 환경을 참조합니다.\n\n### 보호 규칙과의 상호 작용\n\n```\n          `deployment` 속성은 어떤 보호 규칙들이 적용되는지를 제어합니다.\n```\n\n\\| 보호 규칙 |\n`deployment: true`(기본값) | `deployment: false` |\n\\|----------------|------------------------------|---------------------|\n\\| **없음** | 배포 생성, 작업 실행 | 배포 없음, 작업 실행 |\n\\| **대기 타이머** | 대기 타이머 적용 | 대기 타이머가 계속 적용됨 |\n\\| **필수 검토자** | 검토자는 승인해야 합니다. | 검토자는 승인해야 합니다. |\n\\| **사용자 지정 배포 보호 규칙 앱** | 앱 웹후크가 전송되었으니 승인이 필요합니다. |\n**오류가 발생하여 작업이 실패함** |\n\n사용자 지정 배포 보호 규칙(GitHub Apps)이 작동하려면 배포 개체가 필요합니다. 사용자 지정 배포 보호 규칙이 있는 환경에서 `deployment: false`를 설정하면, `deployment: false` 작업이 즉시 실패하며, 환경의 보호 규칙이 호환되지 않는다는 주석 또는 오류 메시지가 표시됩니다. 워크플로에서 `deployment: false`를 제거하거나, 환경에서 사용자 지정 배포 보호 규칙을 제거하십시오.\n\n```\n          `concurrency` 및 `environment`는 연결되지 않았습니다. 동시성 값은 모든 문자열일 수 있습니다. 환경 이름이 될 필요는 없습니다. 또한 다른 워크플로가 동일한 환경을 사용하지만 동시성을 지정하지 않는 경우 해당 워크플로에는 동시성 규칙이 적용되지 않습니다.\n```\n\n예를 들어 다음 워크플로가 실행될 때 `pending` 동시성 그룹을 사용하는 작업이나 워크플로가 진행 중인 경우 상태가 `production`인 상태에서 일시 중지됩니다. 또한 `production` 동시성 그룹을 사용하고 상태가 `pending`인 모든 작업 또는 워크플로를 취소합니다. 즉, `production` 동시성 그룹을 사용하는 최대 하나의 실행 중인 작업 또는 하나의 보류 중인 작업 또는 워크플로가 있습니다.\n\n```yaml\nname: Deployment\n\nconcurrency: production\n\non:\n  push:\n    branches:\n      - main\n\njobs:\n  deployment:\n    runs-on: ubuntu-latest\n    environment: production\n    steps:\n      - name: deploy\n        # ...deployment-specific steps\n```\n\n작업 수준에서 동시성을 지정할 수도 있습니다. 이렇게 하면 동시 작업이 `pending`인 경우에도 워크플로의 다른 작업을 진행할 수 있습니다.\n\n```yaml\nname: Deployment\n\non:\n  push:\n    branches:\n      - main\n\njobs:\n  deployment:\n    runs-on: ubuntu-latest\n    environment: production\n    concurrency: production\n    steps:\n      - name: deploy\n        # ...deployment-specific steps\n```\n\n동일한 동시성 그룹에서 현재 실행 중인 작업 또는 워크플로를 취소하는 데 `cancel-in-progress`를 사용할 수도 있습니다.\n\n```yaml\nname: Deployment\n\nconcurrency:\n  group: production\n  cancel-in-progress: true\n\non:\n  push:\n    branches:\n      - main\n\njobs:\n  deployment:\n    runs-on: ubuntu-latest\n    environment: production\n    steps:\n      - name: deploy\n        # ...deployment-specific steps\n```\n\n배포 관련 단계 작성에 대한 지침은 [배포 예제 찾기](#finding-deployment-examples)를 참조하세요.\n\n## 배포 기록 보기\n\nGitHub Actions 워크플로가 환경에 배포되면 환경이 리포지토리의 기본 페이지에 표시됩니다. 환경에 대한 배포 보기에 대한 자세한 내용은 [배포 기록 보기](/ko/actions/deployment/managing-your-deployments/viewing-deployment-history)을(를) 참조하세요.\n\n## 워크플로 실행 모니터링\n\n모든 워크플로 실행은 실행 진행률을 보여 주는 실시간 그래프를 생성합니다. 이 그래프를 사용하여 배포를 모니터링하고 디버그할 수 있습니다. 자세한 내용은 [시각화 그래프 사용](/ko/actions/monitoring-and-troubleshooting-workflows/using-the-visualization-graph)을(를) 참조하세요.\n\n각 워크플로 실행의 로그와 워크플로 실행 기록을 볼 수도 있습니다. 자세한 내용은 [워크플로 실행 기록 보기](/ko/actions/monitoring-and-troubleshooting-workflows/viewing-workflow-run-history)을(를) 참조하세요.\n\n## 워크플로의 필수 검토 사용\n\n필수 검토자로 구성된 환경을 참조하는 작업은 시작하기 전에 승인을 기다립니다. 작업이 승인을 기다리는 동안 “대기 중” 상태가 됩니다. 작업이 30일 이내에 승인되지 않으면 자동으로 실패 처리됩니다.\n\n환경 및 필수 승인에 대한 자세한 내용은 [배포 환경 관리](/ko/actions/deployment/targeting-different-environments/managing-environments-for-deployment)을(를) 참조하세요. REST API를 사용하여 배포를 검토하는 방법에 대한 내용은 [워크플로 실행에 대한 REST API 엔드포인트](/ko/rest/actions/workflow-runs)을(를) 참조하세요.\n\n## 사용자 지정 배포 보호 규칙 사용\n\n> \\[!NOTE]\n> 사용자 지정 배포 보호 규칙은 현재 공개 미리 보기 버전이며 변경될 수 있습니다.\n\n타사 서비스를 사용하여 배포를 제어하는 사용자 지정 보호 규칙을 사용하도록 설정할 수 있습니다. 예를 들어 Datadog, Honeycomb, ServiceNow와 같은 서비스를 사용하여 GitHub에 대한 배포에 자동화된 승인을 제공할 수 있습니다.\n\n사용자 지정 배포 보호 규칙은 GitHub Apps에서 제공하며, 웹후크 및 콜백을 기반으로 실행됩니다. 워크플로 작업의 승인 또는 거부는 `deployment_protection_rule` 웹후크 사용을 기반으로 합니다. 자세한 내용은 [웹후크 이벤트 및 페이로드](/ko/webhooks-and-events/webhooks/webhook-events-and-payloads#deployment_protection_rule) 및 [배포 승인 또는 거부](/ko/actions/how-tos/managing-workflow-runs-and-deployments/managing-deployments/creating-custom-deployment-protection-rules#approving-or-rejecting-deployments)를 참조하세요.\n\n사용자 지정 배포 보호 규칙을 생성하여 리포지토리에 설치하면 해당 리포지토리 내의 모든 환경에서 해당 규칙을 자동으로 사용할 수 있습니다.\n\nIT 서비스 관리(ITSM) 시스템의 승인된 티켓, 종속성에 대한 취약점 점검 결과, 또는 클라우드 리소스의 안정성 지표 등 외부 서비스에 정의된 조건에 따라 환경 배포 여부를 승인하거나 거부할 수 있습니다. 배포 승인 또는 거부 결정은 제3자 애플리케이션 통합 및 배포에서 정의한 게이팅 조건에 따라 이루어집니다. 다음은 배포 보호 규칙을 설정할 수 있는 몇 가지 사용 사례입니다.\n\n* ITSM & 보안 작업: 배포 준비가 되었는지 확인하기 위해 품질, 보안, 규정 준수 프로세스의 유효성을 검사하여 서비스 준비 상태를 평가할 수 있습니다.\n* 가시성 시스템: 안전성과 배포 준비 상태를 모니터링 또는 관찰 시스템(자산 성능 관리 시스템, 로깅 집계 시스템, 클라우드 리소스 상태 확인 시스템 등)을 통해 확인할 수 있습니다.\n* 코드 품질 & 테스트 도구: CI 빌드 시 환경에 배포하기 전에 자동화된 테스트를 수행할 수 있습니다.\n\n또는 사용자 고유의 보호 규칙을 위의 사용 사례에 대해 작성하거나, 사전 프로덕션 환경에서 프로덕션 환경으로의 배포를 안전하게 승인하거나 거부하기 위한 사용자 지정 논리를 정의할 수 있습니다.\n\n## 앱을 통한 배포 추적\n\nGitHub의 개인 계정 또는 조직이 Microsoft Teams 또는 Slack과 통합된 경우 Microsoft Teams 또는 Slack을 통해 환경을 사용하는 배포를 추적할 수 있습니다. 예를 들어 배포가 승인 보류 중이거나 배포가 승인된 경우 또는 배포 상태가 변경된 경우 앱을 통해 알림을 받을 수 있습니다. Microsoft Teams 또는 Slack을 통합하는 방법에 대한 자세한 내용은 [주요 GitHub 통합](/ko/get-started/exploring-integrations/github-extensions-and-integrations#team-communication-tools) 참조하세요.\n\n배포 및 배포 상태 웹후크를 사용하여 배포를 추적하는 앱을 빌드할 수도 있습니다. 환경을 참조하는 워크플로 작업이 실행되면 환경 이름으로 설정된 `environment` 속성이 있는 배포 개체를 만듭니다. 워크플로가 진행됨에 따라 환경 이름으로 설정된 `environment` 속성, 환경의 URL로 설정된 `environment_url` 속성(워크플로에 지정된 경우), 작업의 상태로 설정된 `state` 속성이 있는 배포 상태 개체도 만듭니다. 자세한 내용은 [GitHub 앱 설명서](/ko/apps) 및 [웹후크 이벤트 및 페이로드](/ko/webhooks-and-events/webhooks/webhook-events-and-payloads#deployment)을(를) 참조하세요.\n\n## 실행기 선택\n\nGitHub 호스트 실행기 또는 자체 호스트 실행기에서 배포 워크플로를 실행할 수 있습니다. GitHub 호스트 실행기의 트래픽은 [광범위한 네트워크 주소](/ko/rest/meta/meta#get-github-meta-information)에서 올 수 있습니다. 내부 환경에 배포 중이고 회사에서 외부 트래픽을 개인 네트워크로 제한하는 경우 GitHub Actions 호스트 실행기에서 실행되는 GitHub 워크플로는 내부 서비스 또는 리소스와 통신하지 못할 수 있습니다. 이를 극복하기 위해 자체 실행기를 호스트할 수 있습니다. 자세한 내용은 [자체 호스팅 실행기](/ko/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners) 및 [GitHub 호스팅 실행기](/ko/actions/using-github-hosted-runners/about-github-hosted-runners)을(를) 참조하세요.\n\n## 상태 배지 표시\n\n상태 배지를 사용하여 배포 워크플로의 상태를 표시할 수 있습니다. 상태 배지는 워크플로가 현재 실패 중 또는 통과 중인지 보여줍니다. 상태 배지를 추가하는 일반적인 위치는 리포지토리의 `README.md` 파일이지만 원하는 웹 페이지에 추가할 수도 있습니다. 기본적으로 배지는 기본 분기의 상태를 표시합니다. 기본 분기 워크플로 실행이 없으면 모든 분기에서 가장 최근 실행의 상태가 표시됩니다. URL의 `branch` 및 `event` 쿼리 매개 변수를 사용하여 특정 분기 또는 이벤트에 대한 워크플로 실행의 상태를 표시할 수 있습니다.\n\n![워크플로 상태 배지의 스크린샷. 오른쪽에서 왼쪽으로는 GitHub 로고, 워크플로 이름(\"GitHub Actions 데모\") 및 상태(\"전달\")가 표시됩니다.](/assets/images/help/repository/actions-workflow-status-badge.png)\n\n자세한 내용은 [워크플로 상태 배지 추가](/ko/actions/monitoring-and-troubleshooting-workflows/adding-a-workflow-status-badge)을(를) 참조하세요.\n\n## 배포 예제 찾기\n\n이 문서에서는 배포 워크플로에 추가할 수 있는 GitHub Actions의 기능을 보여 줍니다.\n\nGitHub는 Azure Web App과 같은 여러 인기 서비스에 대한 배포 워크플로 템플릿을 제공합니다. 워크플로 템플릿으로 시작하는 방법을 알아보려면 [워크플로 템플릿 사용](/ko/actions/learn-github-actions/using-starter-workflows) 항목을 참조하거나 [배포 워크플로 템플릿의 전체 목록을 확인하세요](https://github.com/actions/starter-workflows/tree/main/deployments). [Azure App Service에 Node.js 배포하기](/ko/actions/deployment/deploying-to-your-cloud-provider/deploying-to-azure/deploying-nodejs-to-azure-app-service) 항목과 같은 특정 배포 워크플로에 대한 자세한 가이드를 확인할 수도 있습니다.\n\n또한 많은 서비스 공급자는 자사 서비스에 배포하기 위한 GitHub Marketplace에 대한 작업을 제공합니다. 전체 목록은 [GitHub Marketplace](https://github.com/marketplace?category=deployment\\&type=actions)를 참조하세요."}