대규모 시스템 배포·운영 주니어 기술면접
새 면접Q. CI/CD가 무엇인지 설명하고, CI와 CD의 차이점을 말씀해주세요.
CI는 코드 통합과 테스트에, CD는 배포 자동화에 초점을 맞춥니다.
CI(Continuous Integration)는 개발자가 작성한 코드를 자동으로 빌드하고 테스트하여 메인 브랜치에 지속적으로 통합하는 프로세스입니다. CD(Continuous Deployment/Delivery)는 테스트를 통과한 코드를 자동으로 프로덕션 환경에 배포하는 프로세스입니다. CI는 코드 품질 검증과 빠른 피드백에 집중하고, CD는 배포 자동화와 신속한 릴리스에 집중합니다. 두 가지를 함께 사용하면 개발부터 배포까지 전체 프로세스를 자동화할 수 있습니다.
- • CI는 코드 통합과 자동 테스트
- • CD는 배포 자동화
- • 빌드-테스트-배포의 자동화 파이프라인
코드 변경 시 자동으로 빌드·테스트·배포되어 수동 작업 오류를 줄이고 배포 시간을 단축합니다.
실제 프로젝트에서 사용해본 CI/CD 도구가 있나요? 어떤 단계로 파이프라인을 구성했는지 설명해주세요.
Q. Docker 컨테이너와 가상머신(VM)의 차이점을 설명해주세요.
운영체제 공유 여부와 리소스 사용량 측면에서 비교해보세요.
가상머신은 하이퍼바이저 위에 게스트 OS를 포함한 전체 시스템을 가상화하는 반면, Docker 컨테이너는 호스트 OS의 커널을 공유하며 애플리케이션 레벨에서만 격리합니다. 컨테이너는 OS를 포함하지 않아 VM보다 훨씬 가볍고 시작 속도가 빠릅니다. VM은 GB 단위의 용량과 분 단위의 부팅 시간이 필요하지만, 컨테이너는 MB 단위이며 초 단위로 시작됩니다. 컨테이너는 이식성이 뛰어나 개발 환경과 프로덕션 환경을 동일하게 유지할 수 있습니다.
- • 컨테이너는 OS 커널 공유
- • VM보다 가볍고 빠름
- • 높은 이식성과 환경 일관성
동일한 애플리케이션을 로컬, 테스트, 프로덕션 환경에서 동일하게 실행하여 환경 차이로 인한 버그를 방지합니다.
Docker 이미지와 컨테이너의 차이는 무엇인가요?
Q. 서비스 중단 없이 새 버전을 배포해야 합니다. 무중단 배포 방식 중 Blue-Green 배포와 Rolling 배포의 차이점과 각각의 장단점을 설명해주세요.
리소스 사용량과 롤백 속도 측면에서 비교해보세요.
Blue-Green 배포는 기존 환경(Blue)과 동일한 새 환경(Green)을 구성한 후 트래픽을 한 번에 전환하는 방식입니다. Rolling 배포는 기존 서버를 순차적으로 하나씩 새 버전으로 교체하는 방식입니다. Blue-Green은 즉시 롤백이 가능하고 안전하지만 2배의 인프라 비용이 발생합니다. Rolling 배포는 추가 리소스가 적게 들지만 배포 중 구버전과 신버전이 공존하며, 롤백 시 다시 순차 배포가 필요합니다. 서비스 특성과 비용을 고려해 선택해야 합니다.
- • Blue-Green은 환경 전체 전환
- • Rolling은 순차적 교체
- • 비용과 롤백 속도의 트레이드오프
대규모 트래픽을 처리하는 서비스에서 사용자가 느끼지 못하게 새 버전을 배포할 때 사용합니다.
Canary 배포는 어떤 경우에 유용한가요?
Q. 프로덕션 환경에서 애플리케이션 성능 저하가 발생했습니다. 원인을 파악하기 위해 어떤 메트릭(지표)들을 모니터링해야 하는지 설명해주세요.
서버 리소스, 애플리케이션 응답, 에러율 등 다양한 레이어를 고려하세요.
먼저 CPU 사용률, 메모리 사용률, 디스크 I/O 등 인프라 레벨 메트릭을 확인하여 리소스 부족 여부를 파악합니다. 애플리케이션 레벨에서는 응답 시간(latency), 처리량(throughput), 에러율을 모니터링하여 성능 저하 구간을 식별합니다. 데이터베이스 쿼리 실행 시간, 커넥션 풀 상태, 슬로우 쿼리 로그를 확인하여 병목 지점을 찾습니다. 외부 API 호출 시간과 네트워크 지연도 함께 확인해야 합니다. 이러한 메트릭들을 시간대별로 분석하여 패턴을 파악하고 근본 원인을 찾아야 합니다.
- • 인프라 리소스 메트릭 확인
- • 애플리케이션 응답 시간과 에러율 모니터링
- • 데이터베이스와 외부 의존성 확인
갑작스러운 트래픽 증가나 메모리 누수 등의 문제를 조기에 발견하여 장애를 예방합니다.
실시간 알림을 설정한다면 어떤 임계값(threshold)을 기준으로 설정하시겠습니까?
Q. 새 버전 배포 후 30분이 지나 심각한 버그가 발견되어 긴급하게 이전 버전으로 롤백해야 하는 상황입니다. 안전하게 롤백하기 위해 어떤 절차와 주의사항을 고려해야 하나요?
데이터베이스 스키마 변경과 사용자 데이터 정합성을 함께 고려해야 합니다.
먼저 현재 상황을 팀에 공유하고 롤백 결정을 문서화합니다. 데이터베이스 스키마가 변경되었다면 이전 버전과 호환되는지 확인하고, 필요시 스키마도 함께 롤백합니다. 애플리케이션 코드를 이전 버전으로 재배포하되, 무중단 배포 방식을 사용하여 서비스 중단을 최소화합니다. 롤백 후 모니터링 대시보드에서 에러율, 응답 시간 등이 정상화되는지 확인합니다. 롤백 중 생성된 데이터의 정합성을 검증하고, 근본 원인을 분석하여 재발 방지 대책을 수립합니다. 전체 과정을 포스트모템 문서로 작성하여 공유합니다.
- • DB 스키마 호환성 확인
- • 무중단 방식으로 롤백 수행
- • 롤백 후 모니터링과 데이터 정합성 검증
프로덕션 장애 시 신속하게 서비스를 복구하고 사용자 영향을 최소화하기 위해 필수적인 프로세스입니다.
롤백이 불가능한 상황(예: 데이터 마이그레이션이 완료된 경우)이라면 어떻게 대응하시겠습니까?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!