{"meta":{"title":"GitLab CI/CD를 GitHub Actions으로 마이그레이션","intro":"GitHub Actions와 GitLab CI/CD는 몇 가지 구성상 유사점이 있어 GitHub Actions(으)로 마이그레이션하는 것이 비교적 간단합니다.","product":"GitHub Actions","breadcrumbs":[{"href":"/ko/actions","title":"GitHub Actions"},{"href":"/ko/actions/tutorials","title":"자습서"},{"href":"/ko/actions/tutorials/migrate-to-github-actions","title":"GitHub Actions로 마이그레이션"},{"href":"/ko/actions/tutorials/migrate-to-github-actions/manual-migrations","title":"수동 마이그레이션"},{"href":"/ko/actions/tutorials/migrate-to-github-actions/manual-migrations/migrate-from-gitlab-cicd","title":"GitLab CI/CD에서 마이그레이션"}],"documentType":"article"},"body":"# GitLab CI/CD를 GitHub Actions으로 마이그레이션\n\nGitHub Actions와 GitLab CI/CD는 몇 가지 구성상 유사점이 있어 GitHub Actions(으)로 마이그레이션하는 것이 비교적 간단합니다.\n\n## 소개\n\nGitLab CI/CD와 GitHub Actions 둘 다 코드를 자동으로 빌드, 테스트, 게시, 릴리스 및 배포하는 워크플로를 만들 수 있습니다. GitLab CI/CD 및 GitHub Actions 워크플로 구성에서 몇 가지 유사점을 공유합니다.\n\n* 워크플로 구성 파일은 YAML로 작성되며 코드의 리포지토리에 저장됩니다.\n* 워크플로에는 하나 이상의 작업이 포함됩니다.\n* 작업에는 하나 이상의 단계 또는 개별 명령이 포함됩니다.\n* 작업은 관리형 컴퓨터 또는 자체 호스팅 컴퓨터에서 실행할 수 있습니다.\n\n몇 가지 차이점이 있으며, 이 가이드에서는 워크플로를 GitHub Actions로 마이그레이션할 수 있도록 그 중요한 차이점을 설명합니다.\n\n## 작업\n\nGitLab CI/CD의 작업은 .의 GitHub Actions작업과 매우 유사합니다. 두 시스템 모두에서 작업은 다음과 같은 특징을 갖습니다.\n\n* 작업은 순차적으로 실행되는 일련의 단계 또는 스크립트를 포함합니다.\n* 작업은 별도의 컴퓨터나 별도의 컨테이너에서 실행될 수 있습니다.\n* 기본적으로 동시에 실행되지만 순차적으로 실행되도록 구성할 수 있습니다.\n\n작업에서 스크립트 또는 셸 명령을 실행할 수 있습니다. GitLab CI/CD에서 스크립트 단계는 `script` 키를 사용하여 지정됩니다.\nGitHub Actions에서는 모든 스크립트가 `run` 키를 사용하여 지정됩니다.\n\n다음은 각 시스템에 대한 구문의 예입니다.\n\n### 작업에 대한 GitLab CI/CD 구문\n\n```yaml\njob1:\n  variables:\n    GIT_CHECKOUT: \"true\"\n  script:\n    - echo \"Run your script here\"\n```\n\n### GitHub Actions 작업에 대한 구문\n\n```yaml\njobs:\n  job1:\n    steps:\n      - uses: actions/checkout@v6\n      - run: echo \"Run your script here\"\n```\n\n## 러너\n\n실행기는 작업이 실행되는 컴퓨터입니다. GitLab CI/CD와 GitHub Actions는 모두 관리형과 자체 호스팅 버전의 러너를 제공합니다. GitLab CI/CD에서는 `tags`을(를) 사용해 서로 다른 플랫폼에서 작업을 실행하는 반면, GitHub Actions에서는 `runs-on` 키로 이를 수행합니다.\n\n다음은 각 시스템에 대한 구문의 예입니다.\n\n### GitLab CI/CD 러너 구문\n\n```yaml\nwindows_job:\n  tags:\n    - windows\n  script:\n    - echo Hello, %USERNAME%!\n\nlinux_job:\n  tags:\n    - linux\n  script:\n    - echo \"Hello, $USER!\"\n```\n\n### GitHub Actions 러너용 구문\n\n```yaml\nwindows_job:\n  runs-on: windows-latest\n  steps:\n    - run: echo Hello, %USERNAME%!\n\nlinux_job:\n  runs-on: ubuntu-latest\n  steps:\n    - run: echo \"Hello, $USER!\"\n```\n\n자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idruns-on)을(를) 참조하세요.\n\n## Docker 이미지\n\nGitLab CI/CD와 GitHub Actions Docker 이미지에서 실행 중인 작업을 모두 지원합니다. GitLab CI/CD에서는 Docker 이미지를 `image` 키로 정의하는 반면, GitHub Actions에서는 `container` 키로 정의합니다.\n\n다음은 각 시스템에 대한 구문의 예입니다.\n\n### Docker 이미지에 대한 GitLab CI/CD 구문\n\n```yaml\nmy_job:\n  image: node:20-bookworm-slim\n```\n\n### GitHub Actions Docker 이미지 구문\n\n```yaml\njobs:\n  my_job:\n    container: node:20-bookworm-slim\n```\n\n자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idcontainer)을(를) 참조하세요.\n\n## 조건 및 표현식 구문\n\nGitLab CI/CD는 `rules`를 사용하여 특정 조건에 대한 작업을 실행할지 여부를 결정합니다.\nGitHub Actions 는 `if` 조건이 충족되지 않는 한 작업이 실행되지 않도록 키워드를 사용합니다.\n\n다음은 각 시스템에 대한 구문의 예입니다.\n\n### 조건 및 식에 대한 GitLab CI/CD 구문\n\n```yaml\ndeploy_prod:\n  stage: deploy\n  script:\n    - echo \"Deploy to production server\"\n  rules:\n    - if: '$CI_COMMIT_BRANCH == \"master\"'\n```\n\n### GitHub Actions 조건 및 식 구문\n\n```yaml\njobs:\n  deploy_prod:\n    if: contains( github.ref, 'master')\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo \"Deploy to production server\"\n```\n\n자세한 내용은 [워크플로 및 작업에서 식 평가](/ko/actions/reference/workflows-and-actions/expressions)을(를) 참조하세요.\n\n## 작업 간의 종속성\n\nGitLab CI/CD와 GitHub Actions 작업에 대한 종속성을 설정할 수 있습니다. 두 시스템 모두에서 작업은 기본적으로 병렬로 실행되지만 키로 GitHub Actions 작업 종속성을 `needs` 명시적으로 지정할 수 있습니다. 또한 GitLab CI/CD에는 한 스테이지의 작업이 동시에 실행되는 `stages` 개념도 있지만, 이전 스테이지의 모든 작업이 완료되면 다음 스테이지가 시작됩니다.\nGitHub Actions에서 `needs` 키로 이 시나리오를 재현할 수 있습니다.\n\n다음은 각 시스템에 대한 구문의 예입니다. 워크플로는 `build_a` 및 `build_b`라고 명명된 병렬로 실행되는 두 개의 작업으로 시작하며, 이 작업이 완료되면 `test_ab`라는 다른 작업이 실행됩니다. 마지막으로 `test_ab`가 완료되면 `deploy_ab` 작업이 실행됩니다.\n\n### 작업 간 종속성에 대한 GitLab CI/CD 구문\n\n```yaml\nstages:\n  - build\n  - test\n  - deploy\n\nbuild_a:\n  stage: build\n  script:\n    - echo \"This job will run first.\"\n\nbuild_b:\n  stage: build\n  script:\n    - echo \"This job will run first, in parallel with build_a.\"\n\ntest_ab:\n  stage: test\n  script:\n    - echo \"This job will run after build_a and build_b have finished.\"\n\ndeploy_ab:\n  stage: deploy\n  script:\n    - echo \"This job will run after test_ab is complete\"\n```\n\n### GitHub Actions 작업 간 종속성에 대한 구문\n\n```yaml\njobs:\n  build_a:\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo \"This job will be run first.\"\n\n  build_b:\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo \"This job will be run first, in parallel with build_a\"\n\n  test_ab:\n    runs-on: ubuntu-latest\n    needs: [build_a,build_b]\n    steps:\n      - run: echo \"This job will run after build_a and build_b have finished\"\n\n  deploy_ab:\n    runs-on: ubuntu-latest\n    needs: [test_ab]\n    steps:\n      - run: echo \"This job will run after test_ab is complete\"\n```\n\n자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idneeds)을(를) 참조하세요.\n\n## 작업 흐름 예약\n\nGitLab CI/CD를 GitHub Actions 모두 사용하여 특정 간격으로 워크플로를 실행할 수 있습니다. GitLab CI/CD에서 파이프라인 일정은 UI를 사용하여 구성되며 GitHub Actions , \"on\" 키를 사용하여 예약된 간격으로 워크플로를 트리거할 수 있습니다.\n\n자세한 내용은 [워크플로를 트리거하는 이벤트](/ko/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule)을(를) 참조하세요.\n\n## 변수 및 비밀\n\nGitLab CI/CD 및 GitHub Actions 파이프라인 또는 워크플로 구성 파일에서 변수 설정 및 GitLab 또는 GitHub UI를 사용하여 비밀 만들기를 지원합니다.\n\n자세한 내용은 [변수에 정보 저장](/ko/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables) 및 [비밀](/ko/actions/concepts/security/secrets)을(를) 참조하세요.\n\n## 캐싱\n\nGitLab CI/CD와 GitHub Actions는 구성 파일에서 워크플로 파일을 수동으로 캐시하는 방법을 제공합니다.\n\n다음은 각 시스템에 대한 구문의 예입니다.\n\n### 캐싱에 대한 GitLab CI/CD 구문\n\n```yaml\nimage: node:latest\n\ncache:\n  key: $CI_COMMIT_REF_SLUG\n  paths:\n    - .npm/\n\nbefore_script:\n  - npm ci --cache .npm --prefer-offline\n\ntest_async:\n  script:\n    - node ./specs/start.js ./specs/async.spec.js\n```\n\n### GitHub Actions 캐싱 구문\n\n```yaml\njobs:\n  test_async:\n    runs-on: ubuntu-latest\n    steps:\n    - name: Cache node modules\n      uses: actions/cache@v4\n      with:\n        path: ~/.npm\n        key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }}\n        restore-keys: v1-npm-deps-\n```\n\n## Artifacts\n\nGitLab CI/CD와 GitHub Actions 모두 작업에서 생성된 파일 및 디렉터리를 아티팩트로 업로드할 수 있습니다. 에서 GitHub Actions아티팩트가 여러 작업에 걸쳐 데이터를 유지하는 데 사용될 수 있습니다.\n\n다음은 각 시스템에 대한 구문의 예입니다.\n\n### 아티팩트에 대한 GitLab CI/CD 구문\n\n```yaml\nscript:\nartifacts:\n  paths:\n    - math-homework.txt\n```\n\n### GitHub Actions 아티팩트용 구문\n\n```yaml\n- name: Upload math result for job 1\n  uses: actions/upload-artifact@v4\n  with:\n    name: homework\n    path: math-homework.txt\n```\n\n자세한 내용은 [워크플로 아티팩트와 데이터 저장 및 공유](/ko/actions/tutorials/store-and-share-data)을(를) 참조하세요.\n\n## 데이터베이스 및 서비스 컨테이너\n\n두 시스템 모두 데이터베이스, 캐싱 또는 기타 종속성에 대한 추가 컨테이너를 포함할 수 있습니다.\n\nGitLab CI/CD에서는 작업용 컨테이너를 `image` 키로 지정하는 반면, GitHub Actions에서는 `container` 키를 사용합니다. 두 시스템 모두에서 추가 서비스 컨테이너가 `services` 키로 지정됩니다.\n\n다음은 각 시스템에 대한 구문의 예입니다.\n\n### 데이터베이스 및 서비스 컨테이너에 대한 GitLab CI/CD 구문\n\n```yaml\ncontainer-job:\n  variables:\n    POSTGRES_PASSWORD: postgres\n    # The hostname used to communicate with the\n    # PostgreSQL service container\n    POSTGRES_HOST: postgres\n    # The default PostgreSQL port\n    POSTGRES_PORT: 5432\n  image: node:20-bookworm-slim\n  services:\n    - postgres\n  script:\n    # Performs a clean installation of all dependencies\n    # in the `package.json` file\n    - npm ci\n    # Runs a script that creates a PostgreSQL client,\n    # populates the client with data, and retrieves data\n    - node client.js\n  tags:\n    - docker\n```\n\n### GitHub Actions 데이터베이스 및 서비스 컨테이너에 대한 구문\n\n```yaml\njobs:\n  container-job:\n    runs-on: ubuntu-latest\n    container: node:20-bookworm-slim\n\n    services:\n      postgres:\n        image: postgres\n        env:\n          POSTGRES_PASSWORD: postgres\n\n    steps:\n      - name: Check out repository code\n        uses: actions/checkout@v6\n\n      # Performs a clean installation of all dependencies\n      # in the `package.json` file\n      - name: Install dependencies\n        run: npm ci\n\n      - name: Connect to PostgreSQL\n        # Runs a script that creates a PostgreSQL client,\n        # populates the client with data, and retrieves data\n        run: node client.js\n        env:\n          # The hostname used to communicate with the\n          # PostgreSQL service container\n          POSTGRES_HOST: postgres\n          # The default PostgreSQL port\n          POSTGRES_PORT: 5432\n```\n\n자세한 내용은 [Docker 서비스 컨테이너와 통신](/ko/actions/tutorials/use-containerized-services/use-docker-service-containers)을(를) 참조하세요."}