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

2026년 현재, CI/CD 파이프라인은 현대 소프트웨어 개발의 핵심 인프라로 자리잡았습니다. GitHub Actions는 GitHub 저장소와의 원활한 통합으로 빠르게 확산되었고, GitLab CI는 플랫폼 내 통합 솔루션으로서 확고한 입지를 구축했습니다. Jenkins는 풍부한 플러그인 생태계를 갖춘 오픈소스 도구로서 엔터프라이즈 환경에서 여전히 중요한 역할을 수행하고 있습니다. DevOps 직무 기술 면접에서는 이 세 가지 플랫폼에 대한 실무 지식이 필수적으로 요구됩니다. 이론적 개념뿐만 아니라 구체적인 구현 패턴, 보안 모범 사례, 성능 최적화 기법까지 폭넓은 이해가 필요합니다. 이 글에서는 2026년 면접에서 실제로 출제되고 있는 질문과 답변을 체계적으로 정리하고, 효과적인 준비 방법을 제시합니다.

GitHub Actions: 워크플로 설계와 Matrix Builds

GitHub Actions는 이벤트 기반 워크플로 모델을 채택하고 있습니다. Git 이벤트, 스케줄, 외부 Webhook 등 다양한 트리거에 의해 워크플로가 실행됩니다. 각 작업(Job)은 독립된 VM 또는 컨테이너에서 실행되며, 여러 단계(Step)로 구성됩니다. 면접에서는 작업 간 의존성 제어, 매트릭스 빌드, 환경 보호 메커니즘에 대한 깊은 이해가 평가됩니다.

# .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 키워드는 작업 간 실행 순서를 제어하며, lint 작업이 성공한 후에만 test 작업이 실행됩니다. strategy.matrix는 서로 다른 Node.js 버전에서 병렬 테스트를 가능하게 하여 호환성 검증을 자동화합니다. environment: production 설정을 통해 배포 전 수동 승인 프로세스를 요구할 수 있습니다.

면접에서 자주 출제되는 질문 중 하나는 if: github.ref == 'refs/heads/main'과 if: github.ref == 'main'의 차이입니다. github.ref는 완전한 브랜치 경로를 반환하므로 refs/heads/ 접두사를 포함한 전체 형식으로 작성해야 합니다. 이 부분을 간과하면 조건 분기가 의도대로 작동하지 않습니다.

Reusable Workflows도 빈출 토픽입니다. 조직 전체에서 공유할 수 있는 워크플로 템플릿을 정의하고, 여러 저장소에서 참조할 수 있습니다. 보안 스캔이나 배포 게이트를 중앙에서 관리함으로써 코드 중복을 줄이고 컴플라이언스 요구사항 대응을 효율화할 수 있습니다. actions/setup-node의 cache 매개변수를 사용한 캐싱은 node_modules를 워크플로 실행 간에 재사용하여 빌드 시간을 크게 단축합니다.

실행 컨텍스트(github, env, secrets, steps)에는 워크플로 실행 시점의 메타데이터가 저장됩니다. Expression 문법 ${{ }}를 사용하면 동적 값 계산과 조건 로직 작성이 가능합니다.

GitLab CI: 스테이지 기반 파이프라인과 Artifact 관리

GitLab CI는 스테이지 기반 파이프라인 모델을 채택하고 있습니다. 동일 스테이지 내의 작업은 병렬로 실행되지만, 스테이지 간에는 순차적으로 실행됩니다. 이는 "기본적으로 병렬 실행, needs로 제어"하는 GitHub Actions 모델과 근본적으로 다른 접근 방식입니다.

# .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

rules 키워드는 GitLab CI 14 이후 기존의 only/except 모델을 대체하는 권장 구문입니다. 브랜치명, 태그, 머지 리퀘스트 상태, 사용자 정의 변수를 기반으로 작업 실행을 세밀하게 제어할 수 있습니다. when: manual과 rules의 조합으로 프로덕션 배포에 대한 승인 게이트를 구현할 수 있습니다.

Artifact와 Cache의 차이는 면접에서 특히 주목받는 논점입니다. Cache는 node_modules 같은 의존성을 재사용하여 리빌드 시간을 최적화하기 위한 메커니즘입니다. 반면 Artifact는 스테이지 간 데이터를 전달하기 위한 명시적인 메커니즘입니다. reports 블록을 사용하면 테스트 커버리지나 SAST 스캔 결과를 GitLab UI에 직접 통합할 수 있습니다. expire_in 디렉티브는 대규모 코드베이스에서 Artifact 스토리지의 무한 증가를 방지합니다.

캐시 키에는 브랜치별 고유 값(${CI_COMMIT_REF_SLUG})을 사용하는 것이 권장됩니다. 서로 다른 브랜치에서 동시에 실행되는 파이프라인 간의 경쟁 상태(race condition)를 방지하기 위함입니다. GitLab CI 버전 16 이후에는 needs 키워드를 통한 DAG(방향 비순환 그래프) 파이프라인이 지원되어, 직접 의존성이 충족되면 이전 스테이지 전체의 완료를 기다리지 않고 작업을 실행할 수 있습니다. 이 하이브리드 전략은 스테이지 기반 파이프라인의 가독성과 세밀한 병렬화를 통한 성능 최적화를 동시에 달성합니다.

Jenkins: Declarative Pipeline과 Plugin 생태계

2026년에도 Jenkins는 복잡한 온프레미스 요구사항을 가진 엔터프라이즈 환경에서 널리 사용되고 있습니다. Declarative Pipeline 구문은 Scripted Pipeline보다 구조적이고 유지보수가 용이하여 현재의 모범 사례로 정착했습니다.

// 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}"
        }
    }
}

agent 디렉티브는 파이프라인의 실행 환경을 정의합니다. agent any는 사용 가능한 임의의 에이전트를 사용하고, agent { label 'linux' }는 특정 레이블을 가진 에이전트로 제한합니다. 컨테이너 기반 빌드에는 agent { docker 'node:22' }가 적합하며, Jenkins 서버에 도구를 영구 설치하지 않고도 격리된 환경을 제공합니다.

tools 블록은 Jenkins에 등록된 도구 설치를 참조합니다. 이를 통해 파이프라인 정의가 구체적인 경로에서 분리되고, Node.js, Maven, JDK 등의 버전을 중앙에서 관리할 수 있습니다. environment 블록 내의 credentials 키워드는 Jenkinsfile에 시크릿을 노출하지 않으면서 Jenkins Credentials를 환경 변수로 바인딩합니다.

병렬 실행은 스테이지 내의 parallel 블록으로 구현됩니다. GitHub Actions나 GitLab CI의 Matrix Builds와 달리, 각 병렬 분기에 대해 명시적인 스테이지 정의가 필요합니다. post 디렉티브는 빌드 결과와 무관하게 실행되는 정리 작업이나 알림 로직을 정의합니다. always, success, failure, unstable, changed 등의 조건을 지정할 수 있습니다.

1,800개 이상의 플러그인을 보유한 Jenkins 생태계는 DevOps 영역의 거의 모든 도구와의 연동을 지원합니다. Blue Ocean(모던 UI), Pipeline Stage View(파이프라인 시각화), Configuration as Code(JCasC, 선언적 Jenkins 구성)는 면접에서 자주 다루어지는 플러그인입니다. 다만 플러그인 관리에는 지속적인 유지보수가 필요하며, 오래되거나 호환되지 않는 플러그인은 장애의 원인이 될 수 있습니다.

보안 모범 사례: 시크릿 관리와 공급망 공격 대응

2026년 CI/CD 면접에서 보안 관련 질문은 가장 중요하게 다루어지는 주제 중 하나입니다. SolarWinds와 CodeCov 사례 이후, 빌드 파이프라인에 대한 공급망 공격 방어는 최우선 과제가 되었습니다.

# .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

GitHub Workflows에서 Action의 SHA 고정(pinning)은 태그명이 악성 코드로 리다이렉트되는 위험을 방지합니다. Dependabot이 보안 수정이 포함된 새 버전의 Pull Request를 자동으로 생성하므로, SHA 고정과 자동 업데이트의 조합으로 보안과 유지보수성 사이의 균형을 맞출 수 있습니다.

시크릿 관리는 플랫폼별로 다른 전략이 필요합니다. GitHub Actions는 Repository, Organization, Environment의 세 가지 범위(scope)에서 시크릿을 관리합니다. Environment Secrets는 승인 워크플로와 브랜치 제한을 추가로 설정할 수 있습니다. GitLab CI는 일반 변수와 Protected Variables를 구분하며, 후자는 Protected Branch에서만 사용 가능합니다. Jenkins는 Credentials Plugin을 통해 Username/Password, Secret Text, SSH 키, 인증서 등 다양한 유형의 자격 증명을 관리합니다.

OIDC(OpenID Connect)는 클라우드 배포의 모범 사례로 확립되었습니다. 정적 액세스 키 대신 파이프라인이 단기 토큰을 사용하여 클라우드 공급자에 직접 인증합니다. GitHub Actions는 AWS, Azure, GCP에 대한 OIDC를 네이티브로 지원합니다. GitLab CI는 $CI_JOB_JWT를 통해 ID 토큰을 제공합니다. Jenkins의 경우 OIDC 통합을 위해 전용 플러그인이 필요합니다.

성능 최적화: 캐싱 전략과 Matrix 효율화

성능 관련 질문은 파이프라인 비용 인식과 최적화 역량을 평가하는 것입니다. 하루에 10번 실행되는 20분짜리 파이프라인은 상당한 러너 시간을 소비하고 개발자 피드백 루프를 저해합니다.

캐싱은 가장 효과적인 최적화 기법입니다. GitHub Actions의 actions/cache는 실행 간 의존성을 저장합니다. 캐시 키에는 의존성 파일의 해시(hashFiles('package-lock.json'))를 포함시켜 의존성이 변경될 때 자동으로 무효화되도록 해야 합니다. restore-keys 매개변수는 정확히 일치하는 키가 없을 때 대체 키를 사용할 수 있게 합니다.

GitLab CI 캐시는 key: files: ['package-lock.json']으로 유사한 로직을 구현할 수 있습니다. policy: pull-push(기본값)와 policy: pull의 구분은 여러 작업이 동일한 캐시를 사용할 때 경쟁 상태를 방지하는 데 중요합니다. 캐시를 업데이트하는 작업은 하나만 두고 나머지는 읽기 전용으로 설정하는 것이 권장됩니다.

Jenkins는 순차 실행 스테이지에서 워크스페이스 재사용을 기본으로 합니다. 병렬 작업이나 멀티 브랜치 파이프라인에서는 Stash/Unstash 기능이 에이전트 간 아티팩트 전송에 유용합니다. 대규모 코드베이스에서는 Job Cacher Plugin이나 Artifact Manager on S3 Plugin을 사용한 외부 캐싱이 더 확장 가능합니다.

Matrix Builds는 병렬화를 촉진하지만 비용도 증가시킵니다. 5개 Node 버전 x 3개 OS = 15개 병렬 작업이 생성됩니다. 면접에서는 매트릭스 차원을 합리적으로 제한할 수 있는지가 평가됩니다. GitHub Actions의 strategy.matrix.exclude와 include를 통해 선택적인 조합이 가능합니다.

플랫폼 비교: GitHub Actions vs GitLab CI vs Jenkins

면접 패널은 조직 요구사항에 기반한 근거 있는 추천을 기대합니다. 다음 표는 기술적 차이를 정리한 것입니다.

| 항목 | GitHub Actions | GitLab CI | Jenkins | |---|---|---|---| | 설정 파일 | .github/workflows/*.yml | .gitlab-ci.yml | Jenkinsfile | | 실행 모델 | 작업 기반(기본 병렬) | 스테이지 기반(스테이지 간 순차) | 스테이지 기반(유연) | | 러너 호스팅 | GitHub-hosted + Self-hosted | GitLab.com Shared + Self-hosted | Self-hosted만 | | 시크릿 관리 | Repository/Org/Environment Secrets | CI/CD 변수(보호 가능) | Credentials Plugin | | Matrix Builds | strategy.matrix | parallel:matrix | matrix(Plugin) | | 수동 게이트 | environment + Required Reviewers | when: manual | input 디렉티브 | | 마켓플레이스 | 20,000+ Actions | CI/CD Components Catalog | 1,800+ Plugins | | AI 기능 | Copilot for Actions(Preview) | Duo CI Expert Agent(Beta) | Community Plugins | | 가격 정책 | 공개 저장소 무료, 비공개는 분당 과금 | 월 400분 무료, 단계별 과금 | 무료(OSS), 자체 관리 |

GitHub Actions는 오픈소스 프로젝트나 이미 GitHub을 코드 호스팅으로 사용하는 팀에 최적입니다. GitLab CI는 저장소, CI/CD, 컨테이너 레지스트리, 보안 스캔, 인시던트 관리를 통합한 올인원 플랫폼으로서 강점을 발휘합니다. Jenkins는 레거시 시스템, 엄격한 컴플라이언스 요구사항, 클라우드 연결이 없는 복잡한 온프레미스 인프라를 보유한 조직에서 여전히 유력한 선택지입니다.

하이브리드 접근 방식도 실무에서 흔히 사용됩니다. Pull Request의 빠른 피드백에 GitHub Actions를, 복잡한 컴플라이언스 요구사항이 수반되는 배포에 Jenkins를 조합하는 패턴이 대표적인 예입니다. 면접에서는 하나의 플랫폼을 고집하기보다 이러한 실용적인 아키텍처를 논의할 수 있는 역량이 중요합니다.

모니터링과 관찰 가능성: 파이프라인 메트릭과 인시던트 대응

프로덕션 수준의 CI/CD에는 모니터링과 알림이 필수적입니다. Build Success Rate와 Mean Time to Recovery(MTTR)가 핵심 지표입니다. GitHub Actions의 Workflow Insights는 성공률과 평균 실행 시간을 제공합니다. GitLab CI Analytics는 Deployment Frequency, Lead Time, Change Failure Rate 등 DORA Metrics 4대 지표를 표시합니다. Jenkins는 Prometheus Metrics Plugin을 통해 빌드 통계를 Grafana 대시보드로 내보낼 수 있습니다.

Flaky Test(불안정한 테스트)는 파이프라인을 불안정하게 만드는 요인입니다. GitHub Actions는 워크플로 전체가 아닌 실패한 작업만 재실행할 수 있습니다. GitLab CI의 retry: 2는 실패한 작업을 자동으로 재시도합니다. Jenkins에는 Flaky Test Handler Plugin이 있어 간헐적 실패의 통계적 분석을 수행합니다. 다만 자동 재시도는 증상 완화에 불과하며 근본 원인 분석이 여전히 필수적이라는 점을 설명할 수 있어야 합니다.

알림 전략은 가시성(Visibility)과 알림 피로(Alert Fatigue) 사이의 균형을 맞춰야 합니다. 프로덕션 배포 시 GitHub Actions workflow_run Webhook에서 Slack으로 알림을 보내는 것은 효과적이지만, 모든 테스트 실패마다 알림을 보내면 채널이 과부하됩니다. GitLab CI의 Pipeline Schedules와 상태 변경 시에만 발송되는 이메일 알림은 노이즈를 줄여줍니다. Jenkins의 Email-ext Plugin과 Groovy 템플릿은 컨텍스트에 맞는 메시지 커스터마이징을 가능하게 합니다.

감사 로그는 누가 파이프라인을 트리거했는지, 시크릿을 변경했는지, 프로덕션 배포를 승인했는지를 기록합니다. GitHub Audit Log API는 보안 분석과 컴플라이언스 보고서를 지원하고, GitLab Audit Events는 모든 보안 관련 변경 사항을 추적합니다. Jenkins Audit Trail Plugin은 타임스탬프와 사용자 정보가 포함된 구성 변경 로그를 기록합니다.

CI/CD 면접 준비를 위해 CI/CD 기초와 플랫폼별 모듈인 GitHub Actions, GitLab CI, Jenkins에서의 실습이 효과적입니다. CI/CD 외의 DevOps 영역에 대해서는 DevOps 면접 질문 종합 가이드를 참고할 수 있습니다.

결론

• GitHub Actions는 GitHub과의 원활한 통합, 풍부한 Marketplace, Parallel Steps 등 신규 기능으로 오픈소스 생태계를 선도하고 있으나, 공급망 위험에 대비한 SHA 고정의 철저한 적용이 필요합니다
• GitLab CI는 CI/CD와 보안 스캔의 긴밀한 통합을 제공하며, 버전 18.3 이후 SLSA 인증과 세분화된 작업 토큰 권한 관리가 구현되어 있습니다
• Jenkins는 완전한 인프라 제어가 필요한 조직에 가장 유연한 선택지이지만, 2026년 1월부터 Java 21이 필수이며 운영 비용이 높다는 점을 고려해야 합니다
• 시크릿 관리는 세 플랫폼 모두에서 가장 자주 출제되는 보안 주제이며, 범위 지정 시크릿, 보호 변수, 자격 증명 순환 전략에 대한 지식이 필수적입니다
• 캐싱, 병렬화, 조건부 실행을 통한 파이프라인 최적화는 보편적인 스킬이며, 실무 경험의 증거로서 면접관에게 높이 평가됩니다
• 면접 준비 시 각 플랫폼에 대해 최소 하나의 실용적인 파이프라인 구성을 준비하고, 단순한 예제가 아닌 실전 패턴에 초점을 맞추는 것이 권장됩니다