이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
GitHub Actions로 처음 자동화한 것은 PR 생성 시 린트와 테스트를 자동 실행하는 워크플로우였습니다. yaml 파일 하나로 구성할 수 있어 진입 장벽이 낮았고, 규칙을 어기는 코드가 머지되는 빈도가 눈에 띄게 줄었습니다.
이후 배포 파이프라인도 연결했습니다. main 브랜치에 머지되면 스테이징 환경에 자동 배포되도록 구성했고, 배포 완료 후 헬스체크가 실패하면 Slack 알림으로 즉시 확인할 수 있는 구조를 만들었습니다.
캐시 설정도 중요했습니다. 패키지 설치 단계를 캐싱하지 않으면 CI가 매번 전체 의존성을 다시 설치해서 실행 시간이 길어졌습니다. actions/cache를 활용해 패키지 캐시를 유지하니 평균 빌드 시간이 절반 이하로 줄었습니다.
GitHub Actions를 여러 레포지토리에 적용하다 보니 같은 워크플로 설정이 반복되는 문제가 생겼습니다. 린트, 테스트, 빌드 단계가 프로젝트마다 거의 동일한데 각각 따로 관리해야 했습니다. Reusable Workflow로 공통 로직을 별도 파일로 분리하고 각 레포지토리에서 호출하는 방식으로 바꾸니 공통 파이프라인이 업데이트되면 모든 레포지토리에 자동 반영됐습니다. 관리 포인트가 하나로 줄었습니다. 매트릭스 빌드도 활용했는데, 여러 OS와 언어 버전을 조합해 병렬로 테스트하니 호환성 문제를 배포 전에 잡을 수 있었습니다.
Ubuntu와 Windows 환경에서 동작이 다른 파일 경로 처리 버그를 매트릭스 덕분에 발견한 경험이 있습니다. 설정 재사용으로 팀의 전체 워크플로 파일 수가 3분의 1로 줄고, 파이프라인 변경 이력을 한 곳에서 추적할 수 있게 됐습니다. 자동화 파이프라인도 코드처럼 중복 없이 관리해야 유지 비용이 낮아진다는 것을 이 경험에서 배웠습니다.
GitHub Actions에서 클라우드에 배포할 때 서비스 계정 키를 Secrets에 저장해두고 쓰는 방식의 위험성을 인식한 경험이 있습니다. 장기 유효한 키가 여러 레포지토리의 Secrets에 분산돼 있으면 키 로테이션이 누락될 위험이 있었습니다. OIDC(OpenID Connect) 방식을 공부하면서, GitHub Actions 워크플로가 단기 토큰을 직접 클라우드 제공자에게 받아 사용할 수 있다는 것을 이해했습니다. 장기 크리덴셜을 Secrets에 저장할 필요 없이 워크플로 실행 시마다 임시 토큰이 발급되는 방식이었습니다. 실제로 적용했을 때 배포 권한을 워크플로 단위로 제한할 수 있어서 특정 브랜치의 배포만 허용하는 세밀한 접근 제어가 가능해졌습니다. 측정 면에서는 Secrets 관리 항목이 6개에서 2개로 줄었고 키 로테이션 관련 작업이 없어졌습니다.
CI/CD 파이프라인 보안은 기능 구현 이후에 추가하는 것이 아니라 초기 설계에서 함께 고려해야 한다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 무신사 모바일 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.