자료구조/알고리즘 주니어 배포·운영 기술면접
새 면접Q. Git에 코드를 push했을 때 자동으로 빌드와 테스트가 실행되도록 설정하려고 합니다. 이를 위해 필요한 CI/CD 도구와 기본적인 파이프라인 구성 단계를 설명해주세요.
CI/CD 도구의 종류와 일반적인 빌드-테스트-배포의 3단계 흐름을 생각해보세요.
GitHub Actions, Jenkins, GitLab CI 등의 CI/CD 도구를 사용할 수 있습니다. 기본 파이프라인은 크게 3단계로 구성됩니다. 첫째, 소스코드 체크아웃 단계에서 저장소에서 코드를 가져옵니다. 둘째, 빌드 및 테스트 단계에서 의존성을 설치하고 컴파일한 후 단위 테스트를 실행합니다. 셋째, 테스트가 통과하면 배포 단계에서 Docker 이미지를 빌드하거나 서버에 배포합니다. 각 단계는 이전 단계가 성공해야만 진행되며, 실패 시 개발자에게 알림을 보냅니다.
- • CI/CD 도구 선택 (GitHub Actions, Jenkins, GitLab CI)
- • 소스코드 체크아웃 → 빌드/테스트 → 배포의 3단계 구조
- • 각 단계의 성공 여부에 따른 파이프라인 진행 제어
코드 변경사항이 발생할 때마다 자동으로 품질을 검증하고 배포 준비를 완료하여 개발 생산성을 높입니다.
파이프라인에서 테스트가 실패했을 때 개발자에게 어떤 방식으로 알림을 보낼 수 있을까요?
Q. Docker 컨테이너로 애플리케이션을 배포할 때의 장점 3가지를 설명하고, Dockerfile에서 반드시 포함되어야 하는 핵심 명령어들을 설명해주세요.
환경 일관성, 격리성, 이식성 측면에서 장점을 생각해보고, 베이스 이미지부터 실행 명령까지의 흐름을 떠올려보세요.
Docker의 주요 장점은 첫째, 개발/테스트/운영 환경을 동일하게 유지하여 환경 차이로 인한 오류를 방지합니다. 둘째, 각 컨테이너가 독립된 프로세스로 실행되어 애플리케이션 간 의존성 충돌을 방지합니다. 셋째, 컨테이너 이미지 하나로 어떤 서버에서도 동일하게 실행 가능하여 이식성이 뛰어납니다. Dockerfile의 핵심 명령어는 FROM으로 베이스 이미지를 지정하고, WORKDIR로 작업 디렉토리를 설정하며, COPY로 소스코드를 복사하고, RUN으로 의존성을 설치한 후, CMD나 ENTRYPOINT로 실행 명령을 정의합니다.
- • 환경 일관성, 격리성, 이식성의 3가지 주요 장점
- • FROM, WORKDIR, COPY, RUN, CMD 등 핵심 Dockerfile 명령어
- • 개발부터 운영까지 동일한 환경 보장
로컬에서 개발한 애플리케이션을 동일한 환경으로 클라우드 서버에 배포하여 예상치 못한 환경 오류를 방지합니다.
Docker 이미지의 크기를 최소화하기 위해 Dockerfile 작성 시 어떤 방법을 사용할 수 있을까요?
Q. 서비스 중인 웹 애플리케이션을 다운타임 없이 새 버전으로 업데이트해야 합니다. Blue-Green 배포 방식의 동작 원리와 장단점을 설명해주세요.
두 개의 동일한 환경을 준비하고, 트래픽을 전환하는 방식을 생각해보세요.
Blue-Green 배포는 현재 운영 중인 환경(Blue)과 동일한 새 환경(Green)을 준비하는 방식입니다. Green 환경에 새 버전을 배포하고 충분히 테스트한 후, 로드밸런서나 라우터 설정을 변경하여 트래픽을 Blue에서 Green으로 한 번에 전환합니다. 장점은 즉시 롤백이 가능하고 다운타임이 전혀 없으며, 새 버전을 충분히 검증할 수 있다는 점입니다. 단점은 두 배의 인프라 리소스가 필요하고, 데이터베이스 스키마 변경 시 양쪽 환경 모두와 호환되어야 한다는 제약이 있습니다.
- • Blue(구버전)와 Green(신버전) 두 환경을 동시에 운영
- • 트래픽을 한 번에 전환하여 무중단 배포 실현
- • 즉시 롤백 가능하지만 2배의 리소스 필요
사용자가 많은 서비스에서 배포 시간대에도 서비스 중단 없이 새 기능을 출시할 수 있습니다.
Rolling 배포 방식은 Blue-Green 배포와 어떻게 다르며, 어떤 상황에서 더 적합할까요?
Q. 프로덕션 환경에서 애플리케이션을 모니터링할 때 반드시 확인해야 하는 핵심 지표 3가지와 각각을 모니터링해야 하는 이유를 설명해주세요.
서버 상태, 응답 속도, 에러 발생 측면에서 생각해보세요.
첫째, CPU와 메모리 사용률을 모니터링하여 서버 리소스가 부족해지기 전에 스케일링을 준비할 수 있습니다. 둘째, 응답 시간(latency)을 측정하여 사용자 경험 저하를 조기에 감지하고 성능 병목 지점을 파악합니다. 셋째, 에러율(error rate)을 추적하여 배포 후 발생하는 버그나 장애를 즉시 발견할 수 있습니다. 이 세 가지 지표는 시스템 안정성과 사용자 경험에 직접적인 영향을 미치므로 실시간으로 모니터링하고, 임계치를 초과하면 알림을 받도록 설정해야 합니다.
- • CPU/메모리 사용률로 리소스 상태 파악
- • 응답 시간으로 성능 및 사용자 경험 모니터링
- • 에러율로 장애 및 버그 조기 감지
배포 후 에러율이 급증하는 것을 모니터링으로 감지하여 즉시 롤백을 결정할 수 있습니다.
이러한 지표들을 수집하고 시각화하기 위해 사용할 수 있는 모니터링 도구에는 어떤 것들이 있나요?
Q. 새로운 버전을 배포한 후 치명적인 버그가 발견되어 긴급하게 이전 버전으로 되돌려야 하는 상황입니다. 안전하고 빠르게 롤백하기 위한 절차와 롤백 시 주의해야 할 사항을 설명해주세요.
버전 관리, 데이터베이스 상태, 사용자 영향을 최소화하는 방법을 생각해보세요.
먼저 모니터링 시스템에서 이상 징후를 확인하고 롤백이 필요한지 판단합니다. 컨테이너 환경이라면 이전 버전의 이미지 태그로 재배포하고, Blue-Green 방식이라면 트래픽을 이전 환경으로 즉시 전환합니다. 롤백 전에 현재 상태를 스냅샷으로 저장하여 추후 분석에 활용합니다. 주의사항으로는 데이터베이스 마이그레이션이 있었다면 스키마 롤백도 함께 고려해야 하며, 새 버전에서 생성된 데이터의 호환성을 확인해야 합니다. 롤백 후에는 반드시 주요 기능을 테스트하고, 사용자에게 공지하며, 버그의 원인을 분석하여 재발을 방지합니다.
- • 이전 버전 이미지/태그로 신속하게 재배포
- • 데이터베이스 스키마 변경 시 롤백 호환성 확인 필수
- • 롤백 후 테스트 및 원인 분석으로 재발 방지
배포 후 결제 기능에 버그가 발견되어 매출 손실이 발생하기 전에 긴급 롤백으로 서비스를 복구합니다.
롤백이 자주 발생하지 않도록 배포 전에 어떤 검증 단계를 거칠 수 있을까요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!