[기술 면접] 2026-04-16 — CI/CD

오늘의 면접 주제

 

GitHub Actions, Jenkins, 배포 자동화에 대한 관심이 높아진 지금, CI/CD는 주니어 면접에서도 매우 자주 나오는 기본 주제입니다.

핵심 한 줄 요약

CI/CD는 코드 변경을 더 자주, 더 안전하게, 더 예측 가능하게 배포하기 위한 자동화된 개발·배포 방식입니다.

면접 질문 & 모범 답변

Q1. CI/CD가 무엇인가요?

기본 답변 (2-3문장): CI는 Continuous Integration입니다. 여러 개발자가 작업한 코드를 자주 합치고, build와 test를 자동으로 실행하는 과정입니다. CD는 Continuous Delivery 또는 Continuous Deployment를 뜻하며, 검증된 코드를 운영 환경까지 일관되게 배포하는 흐름입니다.
심화 포인트: 많은 지원자가 CI와 CD를 그냥 "자동화"로만 설명합니다. 중요한 것은 속도보다도 품질을 일정하게 유지하고, 사람 실수를 줄이는 데 있다는 점입니다.

Q2. CI는 왜 필요한가요?

기본 답변 (2-3문장): 코드를 오래 따로 들고 있다가 한 번에 합치면 충돌이 커집니다. 작은 단위로 자주 합치면 문제를 빨리 발견할 수 있습니다. 그래서 버그 원인을 추적하기도 쉬워집니다.
심화 포인트: CI의 핵심은 test 자동화만이 아닙니다. lint, build, unit test를 같은 기준으로 반복 실행해 팀 전체의 개발 기준을 맞추는 역할도 합니다.

Q3. GitHub Actions와 Jenkins는 어떻게 비교할 수 있나요?

기본 답변 (2-3문장): GitHub Actions는 GitHub와 통합이 자연스럽고 설정이 간단합니다. Jenkins는 플러그인이 많고 커스터마이징이 강력합니다. 작은 팀이나 GitHub 중심 조직은 GitHub Actions가 편하고, 복잡한 사내 환경은 Jenkins가 더 유리할 수 있습니다.
심화 포인트: 도구 비교에서 "무조건 무엇이 더 좋다"는 답은 약합니다. 저장소 위치, 운영 인프라, 보안 요구사항, 유지보수 인력까지 같이 말해야 실무 감각이 드러납니다.

Q4. CI/CD 파이프라인은 보통 어떤 단계로 구성되나요?

기본 답변 (2-3문장): 일반적으로 checkout -> build -> test -> deploy 순서로 구성합니다. 프로젝트에 따라 lint, security scan, integration test가 추가됩니다. 운영 배포 전에는 staging 환경 검증도 자주 넣습니다.
심화 포인트: 모든 테스트를 매번 다 돌리면 느려질 수 있습니다. 그래서 PR 단계와 main branch 단계의 검증 강도를 나누는 설계가 실무에서 중요합니다.

Q5. Blue/Green 배포와 Canary 배포는 무엇이 다른가요?

기본 답변 (2-3문장): Blue/Green은 기존 버전과 새 버전을 동시에 준비한 뒤, 트래픽을 한 번에 전환하는 방식입니다. Canary는 일부 사용자에게만 새 버전을 먼저 보내고, 문제가 없으면 점진적으로 확대합니다. Blue/Green은 rollback이 빠르고, Canary는 위험을 더 잘게 나눌 수 있습니다.
심화 포인트: 배포 전략은 서버 교체 방식이 아니라 장애를 어떻게 통제할지의 문제입니다. 면접에서는 "어떤 상황에서 어떤 전략이 맞는가"까지 설명해야 좋습니다.

Q6. 실무에서 CI/CD를 도입할 때 가장 먼저 챙길 것은 무엇인가요?

기본 답변 (2-3문장): 자동화보다 먼저 배포 가능한 상태를 정의해야 합니다. 예를 들어 test 통과, 환경 변수 관리, DB migration 절차가 정리되어 있어야 합니다. 기준이 없으면 자동화만 해도 불안정한 배포가 반복됩니다.
심화 포인트: CI/CD 실패 원인은 도구보다 프로세스가 더 많습니다. 배포 승인 기준과 실패 시 복구 절차가 없으면 파이프라인이 있어도 사고는 줄지 않습니다.

Q7. CI/CD에서 자주 발생하는 문제는 무엇인가요?

기본 답변 (2-3문장): 테스트는 통과했는데 운영에서만 실패하는 경우가 많습니다. 개발, staging, production 환경 차이 때문입니다. 그래서 환경을 최대한 비슷하게 맞추고, secret과 설정을 체계적으로 관리해야 합니다.
심화 포인트: flaky test도 큰 문제입니다. 테스트가 가끔 실패하면 팀은 경고를 신뢰하지 않게 됩니다. 자동화는 많을수록 좋은 것이 아니라, 신뢰할 수 있어야 가치가 있습니다.

꼬리 질문 대비

PR 머지 전에는 어떤 테스트까지 자동화해야 하나요?
Continuous Delivery와 Continuous Deployment는 정확히 어떻게 다른가요?
Jenkins를 직접 운영할 때 어떤 비용이 드나요?
Canary 배포 중 오류가 나면 어떤 기준으로 중단하나요?
DB schema 변경이 있는 배포에서는 무엇을 조심해야 하나요?

헷갈리기 쉬운 포인트

CI/CD는 "배포를 빨리 하는 기술"이 아닙니다. 핵심은 안전하고 반복 가능한 배포입니다.
Continuous Delivery는 운영 배포 직전까지 자동화하는 개념입니다. 운영 반영은 사람 승인일 수 있습니다.
Blue/Green이 항상 무중단을 보장하는 것은 아닙니다. 세션 처리, DB 변경, 캐시 정합성까지 맞아야 실제로 안정적입니다.

면접관 시각

이 주제에서는 용어 암기보다 흐름 이해를 봅니다. CI, CD, 배포 전략을 따로 외운 사람이 아니라, 왜 필요한지와 언제 어떤 선택을 하는지 설명할 수 있는지를 봅니다. 특히 도구 비교에서 기능 나열만 하지 않고, 팀 규모와 운영 환경에 따라 판단 기준을 말하면 좋은 평가를 받습니다.