· Interview  · 9 min read

CI/CD & GitOps 면접 질문 20선 — 파이프라인 설계부터 운영까지

GitLab CI, ArgoCD, Helm을 활용한 실무 CI/CD 면접 질문. 파이프라인 설계 원칙, GitOps 패턴, 배포 전략, 트러블슈팅까지 핵심 정리.

GitLab CI, ArgoCD, Helm을 활용한 실무 CI/CD 면접 질문. 파이프라인 설계 원칙, GitOps 패턴, 배포 전략, 트러블슈팅까지 핵심 정리.

CI/CD 기초

1. CI와 CD의 차이를 명확히 설명해주세요.

  • CI (Continuous Integration): 코드 변경을 자주 통합하고, 자동 빌드/테스트로 품질 확인
  • CD (Continuous Delivery): CI 이후 스테이징까지 자동 배포. 프로덕션은 수동 승인.
  • CD (Continuous Deployment): 프로덕션까지 완전 자동 배포.

2. CI/CD 파이프라인 설계 원칙은?

  1. Fast Feedback: 빠른 실패 감지 (빌드 → 유닛테스트 → 통합테스트 순서)
  2. Reproducibility: 동일 커밋은 항상 동일 결과
  3. Immutable Artifacts: 빌드된 아티팩트는 변경 불가
  4. Environment Parity: DEV/STG/PRD 환경 최대한 동일하게
  5. Security Shift-Left: 보안 검사를 파이프라인 초기에 배치

3. 빌드 아티팩트 관리 전략은?

  • Docker 이미지: ECR/Harbor에 태그 관리 (Git SHA + 날짜)
  • Helm Chart: Chart Museum/OCI Registry에 버전 관리
  • Immutable Tag 정책: 같은 태그 덮어쓰기 금지
  • Lifecycle Policy: 오래된 이미지 자동 삭제 (30일/최근 N개 유지)

GitOps

4. GitOps란 무엇이고, 기존 CI/CD와 차이는?

GitOps는 Git을 단일 진실의 원천(Single Source of Truth)으로 사용하는 배포 방식입니다.

구분Push 기반 (기존)Pull 기반 (GitOps)
배포 트리거CI가 클러스터에 Push클러스터가 Git에서 Pull
보안CI에 클러스터 접근 권한 필요클러스터 내부에서만 동작
Drift 감지불가자동 감지 및 복구
감사 로그CI 로그Git 히스토리

5. ArgoCD의 동작 원리를 설명해주세요.

  1. Git Repository를 주기적으로 폴링 (기본 3분) 또는 Webhook 수신
  2. Git의 Desired State와 클러스터의 Live State 비교
  3. 차이(Drift) 발견 시 Sync 수행 (자동/수동 설정 가능)
  4. Health Check로 배포 성공 여부 확인

6. ArgoCD Application vs ApplicationSet 차이는?

  • Application: 하나의 Git 소스 → 하나의 클러스터/네임스페이스 배포
  • ApplicationSet: 템플릿 기반으로 여러 Application 자동 생성

ApplicationSet Generator 종류:

  • Git Generator: Git 디렉토리/파일 기반으로 앱 생성
  • Cluster Generator: 등록된 클러스터별로 앱 생성
  • Matrix Generator: 여러 Generator 조합

7. ArgoCD Sync Policy 옵션을 설명해주세요.

syncPolicy:
  automated:
    prune: true        # Git에서 삭제된 리소스 자동 삭제
    selfHeal: true     # 수동 변경 시 자동 복구
  syncOptions:
    - CreateNamespace=true
    - ApplyOutOfSyncOnly=true  # 변경된 리소스만 적용

8. GitOps에서 시크릿 관리 방법은?

Git에 평문 시크릿을 저장하면 안 되므로:

  1. External Secrets Operator (권장)

    • AWS Secrets Manager/Vault에서 런타임에 가져옴
    • ExternalSecret CR → K8s Secret 자동 생성

  2. Sealed Secrets

    • 공개키로 암호화하여 Git에 저장
    • 클러스터 내 컨트롤러가 복호화

  3. SOPS + Age

    • 파일 레벨 암호화
    • ArgoCD SOPS 플러그인으로 복호화

GitLab CI

9. GitLab CI 파이프라인 구조를 설명해주세요.

stages:
  - build
  - test
  - publish
  - deploy

variables:
  DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA

build:
  stage: build
  script:
    - docker build -t $DOCKER_IMAGE .
    - docker push $DOCKER_IMAGE

deploy:
  stage: deploy
  script:
    - yq e ".image.tag = \"$CI_COMMIT_SHORT_SHA\"" -i values.yaml
    - git commit -am "chore: update image tag to $CI_COMMIT_SHORT_SHA"
    - git push

10. GitLab Runner를 Fargate에서 운영하는 이유는?

  • 온디맨드 스케일링: 빌드 요청 시만 컨테이너 생성
  • 격리: 빌드 간 환경 오염 방지
  • 비용: 유휴 시간 과금 없음
  • 보안: 빌드 환경이 임시적이므로 자격증명 노출 위험 감소

EC2 Runner 대비 시작 시간은 느리지만 (30초~1분), 관리 부담과 비용이 크게 줄어듭니다.

11. Multi-project Pipeline은 어떻게 구성하나요?

# 다른 프로젝트의 파이프라인 트리거
trigger-infra:
  stage: deploy
  trigger:
    project: team/infra-repo
    branch: main
    strategy: depend  # 트리거된 파이프라인 완료까지 대기

사용 사례:

  • 앱 빌드 → 인프라 배포 → E2E 테스트
  • 공통 라이브러리 변경 → 의존 프로젝트 자동 빌드

Helm

12. Helm의 3-way Merge를 설명해주세요.

Helm 3는 업그레이드 시 3가지를 비교합니다:

  1. 이전 릴리즈의 manifest
  2. 현재 클러스터의 live state
  3. 새로운 Chart의 manifest

수동으로 변경된 리소스도 올바르게 처리할 수 있습니다.

13. Helm Chart 구조와 Best Practice는?

mychart/
├── Chart.yaml          # 메타데이터
├── values.yaml         # 기본값
├── values-dev.yaml     # 환경별 오버라이드
├── values-prd.yaml
├── templates/
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   ├── hpa.yaml
│   └── _helpers.tpl    # 공통 템플릿 함수
└── charts/             # 서브차트 (의존성)

Best Practice:

  • _helpers.tpl에 공통 라벨/이름 정의
  • 환경별 values 파일 분리
  • Chart 버전과 앱 버전 분리 관리
  • README에 values 설명 문서화

14. Helm hooks는 어떤 경우에 사용하나요?

annotations:
  "helm.sh/hook": pre-install,pre-upgrade
  "helm.sh/hook-weight": "0"
  "helm.sh/hook-delete-policy": hook-succeeded

사용 사례:

  • pre-install: DB 마이그레이션, 스키마 생성
  • post-install: 초기 데이터 시딩
  • pre-upgrade: 백업 생성
  • post-upgrade: 캐시 워밍업

배포 전략

15. Feature Branch 기반 Preview 환경 구성 방법은?

  1. Feature 브랜치 Push 시 CI 트리거
  2. 브랜치명 기반 네임스페이스 생성 (preview-feature-123)
  3. Helm으로 해당 네임스페이스에 배포
  4. Ingress에 브랜치별 서브도메인 설정 (feature-123.preview.example.com)
  5. PR 머지/닫힘 시 네임스페이스 자동 삭제

16. Canary 배포를 ArgoCD로 구현하는 방법은?

ArgoCD Rollouts를 사용합니다:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
spec:
  strategy:
    canary:
      steps:
        - setWeight: 5
        - pause: { duration: 5m }
        - setWeight: 25
        - pause: { duration: 10m }
        - setWeight: 50
        - pause: { duration: 10m }
      analysis:
        templates:
          - templateName: success-rate
        startingStep: 2

Analysis Template으로 Prometheus 메트릭 기반 자동 Promote/Rollback 가능.

17. 롤백 전략과 주의사항은?

Helm 롤백:

helm rollback <release> <revision>

ArgoCD 롤백:

  • Git revert → 자동 Sync
  • 또는 UI에서 이전 Sync 포인트로 수동 Sync

주의사항:

  • DB 마이그레이션이 포함된 경우 단순 롤백 불가
  • 롤백 후 Git 상태와 클러스터 상태 일치 확인 필요
  • PV/PVC 데이터는 롤백되지 않음

테스트 자동화

18. CI 파이프라인에 포함해야 할 테스트 종류는?

단계테스트도구시간
Build정적 분석/린트SonarQube, ESLint초
Unit단위 테스트JUnit, Jest분
Integration통합 테스트Testcontainers분
Security취약점 스캔Trivy, Snyk분
E2EEnd-to-EndPlaywright, Selenium분~시간

Shift-Left 원칙: 빠른 테스트를 앞에 배치하여 빠른 피드백.

19. SonarQube Quality Gate 설정 경험은?

Quality Gate 기준:

  • 커버리지: 80% 이상
  • 중복 코드: 3% 이하
  • 버그: 0개
  • 취약점: 0개
  • Code Smell: A등급

Gate 미통과 시 파이프라인 실패 처리하여 품질 하한선을 보장합니다.

트러블슈팅

20. CI/CD 파이프라인 장애 대응 경험을 말해주세요.

사례 1: Docker 빌드 실패

  • 원인: Layer 캐시 무효화로 빌드 시간 급증
  • 해결: Multi-stage build + BuildKit 캐시 마운트 적용

사례 2: ArgoCD Sync 실패

  • 원인: CRD 의존성 순서 문제
  • 해결: Sync Wave 어노테이션으로 순서 제어

사례 3: Helm 업그레이드 실패

  • 원인: immutable field 변경 시도 (Service type 변경 등)
  • 해결: force 옵션 또는 리소스 삭제 후 재생성
# ArgoCD Sync Wave 예시
annotations:
  argocd.argoproj.io/sync-wave: "-1"  # CRD 먼저
  argocd.argoproj.io/sync-wave: "0"   # 그 다음 리소스
Share:
Back to Blog

Related Posts

View All Posts »