CI/CD 파이프라인 면접 질문: GitHub Actions, GitLab CI, Jenkins 2026년 가이드

CI/CD 파이프라인 면접 질문은 2026년 DevOps 채용 라운드에서 가장 자주 출제되는 주제입니다. GitHub Actions는 현재 하루 7,100만 개 이상의 작업을 처리하고 있으며, 2026년 6월에 병렬 스텝 실행 기능을 출시했습니다. GitLab CI는 버전 19에 도달하여 네이티브 Secrets Manager를 탑재했고, Jenkins는 여전히 28%의 채택률을 유지하고 있습니다. 면접관은 지원자에게 세 가지 플랫폼 모두에서 실무적인 숙련도를 보여줄 것을 기대합니다.

GitHub Actions 워크플로 구조와 트리거

GitHub Actions는 워크플로, 작업(Job), 스텝을 중심으로 자동화를 구성합니다. 워크플로는 .github/workflows/에 저장되는 YAML 파일로, 자동화가 언제 어떻게 실행되는지 정의합니다. 각 워크플로는 하나 이상의 작업을 포함하고, 각 작업은 별도의 러너에서 실행됩니다.

면접에서 자주 묻는 질문은 on 트리거, 작업 의존성, needs 키워드 간의 관계를 설명하는 것입니다.

# .github/workflows/ci.yml
name: CI Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint

  test:
    needs: lint              # waits for lint to pass
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [20, 22]       # runs tests on both versions
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
          cache: npm
      - run: npm ci
      - run: npm test

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: production  # requires approval
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy.sh

이 워크플로는 세 가지 핵심 개념을 보여줍니다. needs 키워드는 작업 간 의존성 그래프를 생성하고, matrix 전략은 Node.js 버전 간 병렬 테스트를 가능하게 하며, environment 키워드는 수동 승인 뒤에 배포를 게이트합니다.

GitHub Actions 병렬 스텝

GitHub Actions는 2026년 6월 25일에 병렬 스텝 실행을 출시하여 가장 많이 요청된 기능 중 하나에 대응했습니다. 이전에는 작업 내 모든 스텝이 순차적으로 실행되었습니다. 이 새로운 기능은 단일 작업 내에서 동시 실행을 가능하게 하는 네 가지 키워드를 도입합니다.

# .github/workflows/parallel-steps.yml
name: Build with Parallel Steps

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci

      # Run lint and typecheck in parallel
      - name: lint
        run: npm run lint
        background: true

      - name: typecheck
        run: npm run typecheck
        background: true

      - wait-all:              # wait for both to complete

      # Or use the parallel shorthand
      - parallel:
          - name: build-frontend
            run: npm run build:frontend
          - name: build-backend
            run: npm run build:backend

      - run: npm run deploy

background: true 키워드는 스텝을 비동기적으로 시작하고 즉시 다음 스텝으로 진행합니다. wait-all 키워드는 모든 선행 백그라운드 스텝이 완료될 때까지 실행을 일시 중지합니다. parallel 키워드는 여러 스텝을 동시에 실행하고 모두 완료될 때까지 대기한 후 계속 진행하는 약식 표현을 제공합니다.

추가로 두 가지 키워드가 있습니다. wait는 특정 이름의 백그라운드 스텝을 대상으로 하고, cancel은 더 이상 필요하지 않은 백그라운드 스텝을 정상적으로 종료합니다(장시간 실행되는 서비스 중지에 유용함).

GitLab CI 파이프라인 구성과 스테이지

GitLab CI는 리포지토리 루트에 .gitlab-ci.yml 파일을 사용합니다. 작업이 기본적으로 독립적으로 실행되는 GitHub Actions와 달리, GitLab CI는 작업을 스테이지로 구성하고, 스테이지는 순차적으로 실행되지만 동일 스테이지 내 작업은 병렬로 실행됩니다.

면접관은 GitHub Actions 워크플로를 GitLab CI 파이프라인으로 변환하거나 그 반대를 요구하는 경우가 많습니다.

# .gitlab-ci.yml
stages:
  - validate
  - test
  - deploy

variables:
  NODE_VERSION: "22"

lint:
  stage: validate
  image: node:${NODE_VERSION}
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - node_modules/
  script:
    - npm ci
    - npm run lint

unit-tests:
  stage: test
  image: node:${NODE_VERSION}
  parallel:
    matrix:
      - NODE_VERSION: ["20", "22"]
  script:
    - npm ci
    - npm test
  artifacts:
    reports:
      junit: coverage/junit.xml
    expire_in: 7 days

deploy-production:
  stage: deploy
  image: alpine:latest
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual                   # manual gate
  environment:
    name: production
    url: https://app.example.com
  script:
    - ./deploy.sh

GitHub Actions와의 주요 차이점: 스테이지가 전역적으로 실행 순서를 강제하고, parallel:matrix 키워드가 매트릭스 빌드를 처리하며, artifacts:reports:junit이 테스트 결과를 머지 리퀘스트 뷰에 직접 통합합니다.

GitLab 19.0(2026년 5월)은 오픈 베타로 Secrets Manager를 도입하여 HashiCorp Vault 같은 외부 서비스 없이 네이티브 시크릿 스토리지를 제공합니다. GitLab 19.2(2026년 7월)는 예약된 파이프라인 실행 정책을 일반 제공하여, 단일 정책 정의에서 여러 프로젝트에 걸쳐 고정된 주기로 컴플라이언스 스캔이나 의존성 검사를 실행할 수 있게 했습니다.

Jenkins Declarative 파이프라인 구문

Jenkins는 리포지토리 루트에 저장된 Jenkinsfile을 사용합니다. 2026년 기본값으로 권장되는 Declarative 파이프라인 구문은 구조화된 오류 처리와 명확한 스테이지 기반 레이아웃을 제공합니다.

면접에서 자주 묻는 질문: Declarative 파이프라인과 Scripted 파이프라인의 차이점, 그리고 각각을 언제 사용하는지 설명하는 것입니다.

// Jenkinsfile
pipeline {
    agent any

    tools {
        nodejs 'node-22'       // configured in Jenkins Global Tool
    }

    environment {
        CI = 'true'
        DEPLOY_ENV = credentials('deploy-env-secret')
    }

    stages {
        stage('Install') {
            steps {
                sh 'npm ci'
            }
        }

        stage('Lint & Test') {
            parallel {             // parallel execution
                stage('Lint') {
                    steps {
                        sh 'npm run lint'
                    }
                }
                stage('Test') {
                    steps {
                        sh 'npm test'
                    }
                    post {
                        always {
                            junit 'coverage/junit.xml'
                        }
                    }
                }
            }
        }

        stage('Deploy') {
            when {
                branch 'main'
            }
            input {
                message 'Deploy to production?'
            }
            steps {
                sh './deploy.sh'
            }
        }
    }

    post {
        failure {
            mail to: 'team@example.com',
                 subject: "Build failed: ${env.JOB_NAME}",
                 body: "Check ${env.BUILD_URL}"
        }
    }
}

Declarative 파이프라인은 필수 pipeline, agent, stages 블록을 통해 구조를 강제합니다. 스테이지 내 parallel 디렉티브는 lint와 test를 동시에 실행합니다. input 디렉티브는 GitHub Actions 환경 및 GitLab 수동 게이트와 유사하게 수동 승인을 위해 실행을 일시 중지합니다. Jenkins는 2026년 1월부터 Java 21이 필요하므로 파이프라인 환경에서 이 런타임 의존성을 고려해야 합니다.

CI/CD 플랫폼 간 시크릿 관리

모든 CI/CD 면접에는 시크릿 관리에 관한 질문이 포함됩니다. 각 플랫폼은 자격 증명을 다르게 처리하며, 보안 영향을 이해하는 것이 중요합니다.

GitHub Actions는 리포지토리, 환경, 조직 수준에서 시크릿을 저장합니다. 시크릿은 로그에서 자동으로 마스킹되지만, 현재 범위 모델에는 제한이 있습니다. 2026년 보안 로드맵은 과도하게 광범위한 접근 위험을 해결하기 위해 자격 증명을 명시적 실행 컨텍스트에 바인딩하는 범위 지정 시크릿을 도입합니다.

GitLab CI는 보호 규칙이 있는 CI/CD 변수를 제공합니다. 보호된 변수는 보호된 브랜치나 태그에서 실행되는 파이프라인에만 주입됩니다. GitLab 19.0에서 Secrets Manager가 도입되어 팀이 외부 vault 없이 네이티브로 시크릿을 저장하고 참조할 수 있습니다. 시크릿은 프로젝트나 그룹에 범위가 지정되고 명시적으로 요청하는 작업만 접근할 수 있습니다.

Jenkins는 여러 자격 증명 유형(사용자명/비밀번호, SSH 키, 시크릿 텍스트, 인증서)을 가진 Credentials 플러그인을 사용합니다. Declarative 파이프라인의 credentials() 헬퍼는 시크릿을 환경 변수에 바인딩하고, 폴더 수준 자격 증명은 특정 프로젝트로 접근을 범위 지정합니다.

면접에서의 핵심 답변: 파이프라인 파일에 시크릿을 하드코딩하지 않고, 항상 플랫폼의 네이티브 시크릿 관리를 사용하고, 자격 증명을 정기적으로 순환하며, 장기 API 키보다 단기 토큰을 선호합니다.

파이프라인 최적화와 캐싱 전략

느린 파이프라인은 개발자 생산성에 직접적인 영향을 미칩니다. 면접관은 CI/CD 시스템의 성능 병목을 진단하고 수정할 수 있는지 테스트합니다.

세 플랫폼 모두에 적용되는 세 가지 보편적인 최적화 기법이 있습니다:

의존성 캐싱은 매 실행마다 패키지를 다시 다운로드하는 것을 피합니다. GitHub Actions는 actions/cache나 설정 액션의 내장 캐시 지원을 사용합니다. GitLab CI는 키 전략이 있는 cache를 사용합니다. Jenkins는 워크스페이스 영속성이나 stash/unstash 명령에 의존합니다.

병렬 실행은 작업을 여러 러너에 분산합니다. GitHub Actions는 현재 병렬 작업(matrix 전략)과 병렬 스텝(background/parallel 키워드) 모두를 지원합니다. GitLab CI는 parallel:matrix를 사용하고, Jenkins는 parallel 디렉티브를 사용합니다. 적절한 분할 단위는 프로젝트에 따라 다릅니다. 병렬 작업이 너무 많으면 러너 시작 시간이 낭비되고, 너무 적으면 용량이 미사용 상태로 남습니다.

조건부 실행은 불필요한 스테이지를 건너뜁니다. 세 플랫폼 모두 이를 지원합니다: GitHub Actions는 if 표현식, GitLab CI는 rules, Jenkins는 when 디렉티브를 사용합니다. 잘 설계된 파이프라인은 기능 브랜치에서 배포 스테이지를 건너뛰고, lint 전용 변경에서 전체 테스트 스위트 트리거를 건너뜁니다.

CI/CD 파이프라인 보안과 공급망 보호

CI/CD 시스템을 대상으로 한 공급망 공격이 2025년에 크게 증가했으며, tj-actions/changed-files 및 기타 인기 GitHub Actions에 영향을 미치는 인시던트가 있었습니다. 면접 질문은 이제 정기적으로 지원자의 강화 전략을 조사합니다.

태그 하이재킹 공격을 방지하기 위해 태그가 아닌 특정 커밋 SHA에 액션 버전을 고정합니다:

# .github/workflows/secure.yml
steps:
  # Vulnerable: tag can be moved to malicious commit
  - uses: actions/checkout@v4

  # Secure: pinned to exact commit SHA
  - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683

GitLab CI는 SLSA Level 1 증명이 있는 CI/CD 컴포넌트(GitLab 18.1 이후 사용 가능)를 통해 공급망 우려를 해결하며, 재사용 가능한 컴포넌트에서 파이프라인을 조립할 때 더 명확한 출처를 제공합니다. 불변 컨테이너 태그(GitLab 18.2)는 게시 후 이미지 교체를 방지합니다.

Jenkins의 경우, Shared Library 메커니즘은 브랜치 보호, 코드 리뷰 요구사항, 서명된 커밋이 있는 전용 리포지토리를 사용해야 합니다. 유럽 위원회는 YesWeHack을 통해 Jenkins Bug Bounty Program을 시작하여 엔터프라이즈 공급망에서 플랫폼의 중요한 역할을 반영했습니다.

면접 준비를 위한 크로스 플랫폼 비교

이 비교 표는 면접에서 가장 자주 테스트되는 차이점을 다룹니다. 후속 질문은 일반적으로 "새 프로젝트에 어떤 플랫폼을 선택하고, 그 이유는 무엇인가요?"입니다. 답변은 기존 도구, 팀 규모, 컴플라이언스 요구사항, 조직이 관리형 인프라(GitHub/GitLab)를 선호하는지 완전한 제어(Jenkins)를 선호하는지에 따라 달라집니다.

소스

• Actions steps can now be run in parallel (GitHub Changelog, 2026년 6월)
• GitLab 19.0 release notes (GitLab Docs, 2026년 5월)
• GitLab 19.2 release notes (GitLab Docs, 2026년 7월)
• Jenkins Changelog (Jenkins.io, 2026년 8월)
• GitHub Actions 2026 Security Roadmap (GitHub Blog)

CI/CD 기초와 GitHub Actions 면접 모듈로 이러한 질문을 실습하거나, GitLab CI와 Jenkins 관련 질문을 탐색해 보십시오. CI/CD 외 더 넓은 DevOps 준비를 위해서는 DevOps 필수 면접 질문 가이드가 주제 전체를 다룹니다.

CI/CD 파이프라인 면접 핵심 포인트

• GitHub Actions 병렬 스텝(background, wait-all, parallel)은 2026년 6월에 출시되어, 러너, 체크아웃, 워크스페이스를 공유하면서 단일 작업 내 동시 실행을 가능하게 합니다
• GitLab 19.x는 네이티브 Secrets Manager(오픈 베타, 2026년 5월)를 도입하고 예약된 파이프라인 실행 정책을 일반 제공(2026년 7월)하여 외부 도구 의존성을 줄였습니다
• Jenkins 2.574 이상은 JUnit과 Mailer를 포함한 코어 플러그인을 WAR 파일에서 언번들하여, 업데이트 센터에 접근할 수 없는 인스턴스에서 명시적 설치가 필요합니다
• 시크릿 관리는 세 플랫폼 모두에서 가장 자주 테스트되는 보안 주제입니다: 범위 지정 시크릿, 보호 변수, 자격 증명 순환 전략에 대한 지식을 보여주십시오
• 캐싱, 병렬화, 조건부 실행을 통한 파이프라인 최적화는 보편적으로 적용되며 면접관에게 실무적 프로덕션 경험을 보여줍니다
• 플랫폼별로 최소 하나의 작동하는 파이프라인 구성을 준비하고, 토이 예제가 아닌 실제 패턴에 집중하십시오