면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.
저는 CI/CD에서 가장 중요한 건 되돌릴 수 있는 구조라고 생각합니다. 백엔드 서비스를 구축하며 DB 스키마 변경이 포함된 배포에서 마이그레이션이 실패하면 애플리케이션과 DB 상태가 어긋나는 문제를 겪었습니다. 이후 마이그레이션을 애플리케이션 배포와 분리된 별도 단계로 만들고, 항상 하위 호환 가능한 방식(컬럼 추가 후 애플리케이션 배포, 이후 컬럼 정리)으로 설계했습니다. 이 원칙을 팀 배포 가이드로 문서화한 뒤로 마이그레이션 관련 장애가 한 건도 발생하지 않았습니다.
백엔드 API 서버의 CI/CD를 설계할 때 안정성, 속도, 가시성 순으로 우선순위를 두었습니다. 먼저 모든 배포에 자동 헬스체크와 롤백을 넣어 안정성을 확보하고, 그 위에서 빌드 캐싱으로 속도를 개선했습니다. 구현 과정에서는 헬스체크 엔드포인트가 실제 DB 연결 상태를 반영하지 못해 죽은 인스턴스가 정상으로 잘못 판정된 적이 있었는데, 헬스체크 로직에 DB ping을 추가해 해결했습니다. 우선순위를 명확히 두고 설계했더니 이후 기능 추가도 그 틀 안에서 판단하기 쉬웠습니다.
마이크로서비스 환경에서 CI/CD 파이프라인을 설계하며 가장 어려웠던 부분은 서비스 간 배포 순서였습니다. A 서비스가 B 서비스의 새 API를 호출하도록 배포했는데 B가 아직 배포되지 않아 장애가 난 적이 있습니다. 이 경험 이후 API 계약을 먼저 하위 호환되게 확장하고, 소비자 서비스가 이를 사용하기 시작한 뒤에야 이전 버전을 제거하는 순서를 팀 규칙으로 만들었습니다. 이후 서비스 간 의존성으로 인한 배포 장애가 사라졌습니다.
같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.
진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.