CI/CD 신입 성능 최적화 면접

CI 도구(Jenkins, GitLab CI, GitHub Actions 등)의 대시보드에서 각 스테이지별 실행 시간을 확인할 수 있습니다. 각 Job이나 Step의 로그에 타임스탬프가 기록되므로 어느 단계에서 시간이 오래 걸리는지 파악할 수 있습니다. 빌드 도구(Maven, Gradle, npm 등)의 verbose 옵션이나 프로파일링 플러그인을 활성화하여 세부 작업별 소요 시간을 분석합니다. 히스토리 데이터를 비교하여 특정 시점부터 빌드 시간이 증가했는지 추세를 파악합니다. 이를 통해 의존성 다운로드, 컴파일, 테스트 실행 등 어느 구간이 병목인지 식별할 수 있습니다.

의존성 패키지(node_modules, .m2, pip cache 등), 빌드 결과물, Docker 레이어 등을 캐싱할 수 있습니다. 캐싱을 사용하면 매번 의존성을 다운로드하거나 처음부터 빌드하지 않아도 되므로 파이프라인 실행 시간을 크게 단축할 수 있습니다. 주의할 점은 캐시 키를 적절히 설정하여 의존성 파일(package.json, pom.xml 등)이 변경되면 캐시가 무효화되도록 해야 합니다. 또한 캐시가 손상되거나 오래된 경우 오히려 빌드 실패나 잘못된 결과를 초래할 수 있으므로 주기적으로 캐시를 클리어하는 전략도 필요합니다.

서로 의존성이 없는 Job들을 병렬로 실행하도록 파이프라인을 구성할 수 있습니다. 예를 들어 단위 테스트, 통합 테스트, 린트 검사를 각각 별도의 Job으로 분리하여 동시에 실행하면 전체 시간을 단축할 수 있습니다. 테스트 스위트가 큰 경우 테스트를 여러 그룹으로 나누어 병렬 실행하는 매트릭스 전략을 사용할 수 있습니다. 고려사항으로는 CI 러너의 리소스(CPU, 메모리) 제약이 있으므로 너무 많은 Job을 동시에 실행하면 오히려 성능이 저하될 수 있습니다. 또한 공유 리소스(데이터베이스, 파일 등)를 사용하는 테스트는 격리하여 충돌을 방지해야 합니다.

롤링 배포 전략에서 동시에 배포하는 서버 수를 늘리면 전체 배포 시간을 단축할 수 있습니다. 예를 들어 한 번에 1대씩이 아니라 2~3대씩 배치로 배포하면 속도가 빨라집니다. Blue-Green 배포를 사용하면 새 버전을 별도 환경에 미리 배포하고 트래픽을 한 번에 전환하여 배포 시간을 크게 줄일 수 있습니다. Canary 배포는 일부 서버에만 먼저 배포하여 문제가 없으면 점진적으로 확대하는 방식으로, 안정성과 속도의 균형을 맞출 수 있습니다. 컨테이너 환경에서는 이미지를 미리 빌드하고 레지스트리에 푸시해두면 각 서버에서 빠르게 pull하여 배포할 수 있습니다.

CI 러너(Agent)의 수를 증가시켜 동시에 처리할 수 있는 빌드 수를 늘릴 수 있습니다. 클라우드 기반 CI 서비스에서는 Auto Scaling을 설정하여 부하에 따라 자동으로 러너를 추가할 수 있습니다. 불필요한 빌드를 줄이기 위해 특정 파일(문서, 설정 등) 변경 시에는 빌드를 스킵하도록 조건을 설정합니다. PR 빌드와 메인 브랜치 빌드의 우선순위를 다르게 설정하여 중요한 빌드가 먼저 처리되도록 할 수 있습니다. 또한 빌드 시간 자체를 최적화(캐싱, 병렬화 등)하여 각 빌드가 빨리 완료되도록 하면 큐 대기 시간도 자연스럽게 줄어듭니다.