Spring Boot 신입 배포·운영 기술면접
새 면접Q. CI/CD가 무엇인지 설명하고, Spring Boot 프로젝트에 CI/CD를 적용하면 어떤 장점이 있는지 말씀해주세요.
CI는 지속적 통합, CD는 지속적 배포를 의미하며, 자동화가 핵심입니다.
CI/CD는 Continuous Integration과 Continuous Deployment의 약자로, 코드 변경사항을 자동으로 빌드, 테스트, 배포하는 프로세스입니다. CI는 개발자가 코드를 커밋할 때마다 자동으로 빌드와 테스트를 수행하여 통합 문제를 조기에 발견합니다. CD는 테스트를 통과한 코드를 자동으로 프로덕션 환경에 배포합니다. Spring Boot 프로젝트에 적용하면 수동 배포로 인한 휴먼 에러를 줄이고, 배포 시간을 단축하며, 빠른 피드백을 통해 개발 생산성을 높일 수 있습니다.
- • CI는 지속적 통합으로 자동 빌드와 테스트 수행
- • CD는 지속적 배포로 자동 배포 프로세스 구현
- • 휴먼 에러 감소와 배포 시간 단축이 주요 장점
코드를 push하면 자동으로 빌드, 테스트, 배포가 진행되어 개발자는 코드 작성에만 집중할 수 있습니다.
GitHub Actions, Jenkins, GitLab CI 중 사용해본 CI/CD 도구가 있나요? 어떤 작업을 자동화했는지 설명해주세요.
Q. Docker를 사용하는 이유와 Spring Boot 애플리케이션을 Docker 컨테이너로 배포할 때의 장점을 설명해주세요.
환경 일관성과 격리, 이식성 측면에서 생각해보세요.
Docker는 애플리케이션을 컨테이너라는 격리된 환경에서 실행하는 기술로, 개발·테스트·운영 환경을 동일하게 유지할 수 있습니다. 로컬에서 작동하던 애플리케이션이 서버에서 안 되는 '내 컴퓨터에서는 잘 되는데' 문제를 해결합니다. Spring Boot 애플리케이션을 Docker로 배포하면 Java 버전, 라이브러리 의존성 등을 컨테이너 이미지에 포함시켜 어느 환경에서나 동일하게 실행됩니다. 또한 가볍고 빠른 배포가 가능하며, 여러 컨테이너를 독립적으로 관리할 수 있어 마이크로서비스 아키텍처에 적합합니다.
- • 환경 일관성 보장으로 개발과 운영 환경 차이 해소
- • 애플리케이션과 의존성을 하나의 이미지로 패키징
- • 격리된 환경에서 독립적 실행 가능
개발자의 로컬 환경과 AWS 같은 클라우드 서버 환경이 달라도 Docker 이미지만 있으면 동일하게 실행됩니다.
Dockerfile을 작성해본 경험이 있나요? Spring Boot 애플리케이션을 위한 Dockerfile에는 어떤 내용이 들어가야 할까요?
Q. Spring Boot 애플리케이션을 배포할 때 서비스 중단 없이 배포하는 방법에는 어떤 것들이 있나요? 최소 두 가지 방식을 설명해주세요.
블루-그린 배포, 롤링 배포 등 여러 전략이 있으며, 각각의 특징을 생각해보세요.
무중단 배포 방법으로는 블루-그린 배포와 롤링 배포가 대표적입니다. 블루-그린 배포는 현재 운영 중인 환경(블루)과 동일한 새 환경(그린)을 준비한 후, 로드밸런서를 통해 트래픽을 한 번에 전환하는 방식입니다. 문제 발생 시 즉시 롤백이 가능하지만 두 배의 서버 자원이 필요합니다. 롤링 배포는 여러 인스턴스 중 일부씩 순차적으로 새 버전으로 교체하는 방식으로, 추가 자원 없이 배포할 수 있지만 배포 중 구버전과 신버전이 공존합니다. Spring Boot에서는 Actuator의 health check를 활용해 새 버전이 정상 동작하는지 확인 후 트래픽을 전환합니다.
- • 블루-그린 배포는 전체 트래픽을 한 번에 전환
- • 롤링 배포는 인스턴스를 순차적으로 교체
- • 무중단 배포를 위해 헬스체크가 필수
사용자가 서비스를 이용하는 중에도 새 기능을 배포해야 할 때 무중단 배포 전략을 사용합니다.
배포 중 새 버전에 문제가 발견되면 어떻게 대응해야 할까요? 롤백 전략에 대해 설명해주세요.
Q. Spring Boot 애플리케이션을 운영할 때 모니터링해야 할 주요 지표는 무엇이며, Spring Boot Actuator는 어떻게 활용할 수 있나요?
애플리케이션의 건강 상태, 성능, 자원 사용량 등을 생각해보세요.
운영 시 모니터링해야 할 주요 지표는 CPU, 메모리 사용률, 응답 시간, 에러율, 활성 스레드 수, DB 커넥션 풀 상태 등입니다. Spring Boot Actuator는 이러한 메트릭을 수집하고 노출하는 라이브러리로, /actuator/health로 애플리케이션 상태를, /actuator/metrics로 다양한 성능 지표를 확인할 수 있습니다. Prometheus와 Grafana 같은 도구와 연동하여 시각화하고 알림을 설정할 수 있습니다. 또한 /actuator/info로 애플리케이션 버전 정보를, /actuator/loggers로 로그 레벨을 동적으로 변경할 수 있어 운영 중 디버깅에 유용합니다.
- • CPU, 메모리, 응답시간, 에러율 등이 주요 모니터링 지표
- • Actuator는 다양한 엔드포인트로 메트릭 제공
- • Prometheus, Grafana와 연동하여 시각화 가능
새벽에 서버 응답이 느려졌다는 알림을 받으면 Grafana 대시보드를 확인해 CPU나 메모리 급증 여부를 파악합니다.
애플리케이션의 메모리 사용량이 계속 증가하는 상황을 발견했다면 어떤 문제를 의심하고 어떻게 대응하시겠습니까?
Q. Spring Boot 애플리케이션을 새 버전으로 배포한 후 치명적인 버그가 발견되었습니다. 빠르게 이전 버전으로 롤백하기 위해 어떤 준비가 필요하고, 롤백 과정은 어떻게 진행되나요?
버전 관리, 이미지 태깅, 배포 이력 관리 측면에서 생각해보세요.
빠른 롤백을 위해서는 먼저 각 배포 버전을 명확히 관리해야 합니다. Docker를 사용한다면 이미지에 버전 태그(v1.0.0, v1.0.1 등)를 붙여 관리하고, Git 커밋 해시를 태그에 포함시키면 추적이 용이합니다. 이전 버전의 이미지나 빌드 산출물을 삭제하지 않고 보관해야 합니다. 롤백 시에는 로드밸런서나 Kubernetes의 설정을 이전 버전 이미지로 변경하고, 무중단 배포 방식을 적용하여 트래픽을 이전 버전으로 전환합니다. 데이터베이스 스키마가 변경된 경우 마이그레이션 롤백도 함께 고려해야 하며, 롤백 후에는 모니터링을 통해 정상 동작을 확인합니다.
- • 버전별 Docker 이미지나 빌드 산출물 보관 필수
- • 명확한 버전 태깅과 배포 이력 관리 필요
- • 무중단 방식으로 이전 버전으로 트래픽 전환
신규 기능 배포 후 주문이 처리되지 않는 버그가 발견되면 즉시 이전 버전으로 롤백하여 서비스를 정상화합니다.
데이터베이스 스키마 변경을 포함한 배포를 롤백해야 한다면 어떤 점을 추가로 고려해야 할까요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!