Git 배포·운영 주니어 기술면접
새 면접Q. GitHub Actions를 사용하여 main 브랜치에 푸시될 때마다 자동으로 테스트와 빌드를 수행하는 CI 파이프라인을 구축하려고 합니다. workflow 파일은 어디에 위치해야 하며, 어떤 이벤트 트리거를 설정해야 하나요? 또한 여러 Job을 순차적으로 실행하려면 어떻게 해야 하는지 설명해주세요.
GitHub Actions의 workflow 파일 경로와 YAML 구조, needs 키워드를 생각해보세요.
GitHub Actions의 workflow 파일은 저장소의 .github/workflows/ 디렉토리에 YAML 형식으로 작성해야 합니다. main 브랜치에 푸시될 때 트리거하려면 on: push: branches: [main] 이벤트를 설정합니다. 여러 Job을 순차적으로 실행하려면 needs 키워드를 사용하여 의존성을 정의합니다. 예를 들어 test job이 완료된 후 build job을 실행하려면 build job에 needs: [test]를 추가합니다. 이를 통해 테스트가 실패하면 빌드가 실행되지 않도록 파이프라인을 안전하게 구성할 수 있습니다.
- • .github/workflows/ 디렉토리에 YAML 파일 작성
- • on 키워드로 push 이벤트와 브랜치 지정
- • needs 키워드로 Job 간 의존성 설정
코드가 메인 브랜치에 병합될 때마다 자동으로 테스트와 빌드를 수행하여 배포 전 품질을 보장합니다.
workflow에서 secrets를 안전하게 관리하는 방법과 환경변수로 주입하는 방법을 설명해주세요.
Q. 프로덕션 배포를 위해 Git 태그를 사용하여 릴리즈 버전을 관리하려고 합니다. v1.2.3 형식의 태그를 생성하여 원격 저장소에 푸시하는 과정을 설명하고, CI/CD 파이프라인에서 특정 태그가 푸시될 때만 배포가 실행되도록 설정하려면 어떻게 해야 하나요?
annotated 태그 생성 명령어와 태그 푸시 방법, 그리고 workflow의 태그 패턴 필터링을 고려해보세요.
먼저 git tag -a v1.2.3 -m 'Release version 1.2.3' 명령어로 annotated 태그를 생성합니다. 생성한 태그는 git push origin v1.2.3 또는 git push --tags로 원격 저장소에 푸시합니다. GitHub Actions에서는 on: push: tags: ['v*.*.*'] 패턴을 사용하여 v로 시작하는 시맨틱 버전 태그가 푸시될 때만 배포 workflow가 트리거되도록 설정할 수 있습니다. 이를 통해 개발 중인 커밋은 배포되지 않고, 명시적으로 태그를 생성한 릴리스만 프로덕션에 배포되도록 제어할 수 있습니다.
- • git tag -a로 annotated 태그 생성
- • git push로 태그를 원격 저장소에 푸시
- • workflow에서 tags 패턴으로 배포 트리거 제어
프로덕션 배포 시 특정 버전을 명확히 표시하고, 해당 버전만 자동으로 배포되도록 안전장치를 마련합니다.
이미 푸시한 태그를 수정하거나 삭제해야 할 때 어떻게 처리해야 하며, 이미 배포된 버전에 대한 롤백은 어떻게 수행하나요?
Q. 프로덕션 환경에 배포한 후 심각한 버그가 발견되어 긴급하게 이전 버전으로 롤백해야 합니다. Git을 사용한 롤백 시나리오에서 git revert와 git reset 중 어떤 방법을 선택해야 하며, 그 이유는 무엇인가요? 또한 롤백 후 CI/CD 파이프라인은 어떻게 동작해야 하나요?
이미 배포된 커밋의 히스토리 보존과 협업 환경에서의 안전성을 고려해보세요.
프로덕션 환경에서는 반드시 git revert를 사용해야 합니다. git reset은 커밋 히스토리를 삭제하므로 이미 배포된 코드와 동료 개발자들의 작업에 혼란을 초래할 수 있습니다. git revert는 문제가 된 커밋을 되돌리는 새로운 커밋을 생성하므로 히스토리가 보존되고 추적 가능합니다. 롤백 커밋을 main 브랜치에 푸시하면 CI/CD 파이프라인이 자동으로 트리거되어 테스트를 거친 후 이전 버전이 다시 배포됩니다. 이후 버그를 수정한 새로운 커밋을 만들어 정상적인 배포 프로세스를 진행합니다.
- • 프로덕션에서는 git revert 사용 (히스토리 보존)
- • git reset은 히스토리 삭제로 협업에 위험
- • revert 후 자동으로 CI/CD가 재배포 수행
프로덕션 장애 발생 시 빠르게 안정 버전으로 복구하면서 변경 이력을 추적 가능하게 유지합니다.
여러 개의 커밋을 한 번에 롤백해야 할 때는 어떻게 처리하며, 롤백 과정에서 충돌이 발생하면 어떻게 해결하나요?
Q. 운영 환경에 배포되는 main 브랜치의 안정성을 보장하기 위해 브랜치 보호 규칙을 설정하려고 합니다. PR 병합 전에 반드시 CI 테스트를 통과해야 하고, 최소 1명의 코드 리뷰 승인을 받아야 하며, 관리자도 이 규칙을 따르도록 강제하려면 어떤 설정이 필요한가요?
GitHub의 Branch Protection Rules에서 설정 가능한 옵션들을 생각해보세요.
GitHub 저장소의 Settings > Branches에서 main 브랜치에 대한 보호 규칙을 추가합니다. 'Require status checks to pass before merging'을 활성화하여 CI 테스트 통과를 필수로 만들고, 'Require pull request reviews before merging'에서 최소 승인 수를 1로 설정합니다. 'Include administrators'를 체크하면 관리자 권한을 가진 사람도 이 규칙을 우회할 수 없습니다. 추가로 'Require branches to be up to date before merging'을 활성화하면 병합 전에 최신 main 브랜치 기준으로 테스트를 통과해야 하므로 더욱 안전합니다. 이를 통해 main 브랜치의 품질을 자동으로 보장하고 안정적인 배포를 유지할 수 있습니다.
- • Status checks 필수 설정으로 CI 테스트 강제
- • PR review 필수 설정으로 코드 리뷰 강제
- • Include administrators로 모든 사용자에게 규칙 적용
main 브랜치에 잘못된 코드가 병합되어 프로덕션 장애가 발생하는 것을 사전에 방지합니다.
긴급 상황에서 브랜치 보호 규칙을 일시적으로 우회해야 할 때는 어떻게 처리하며, 이후 어떤 조치를 취해야 하나요?
Q. 개발(dev), 스테이징(staging), 프로덕션(production) 세 가지 환경을 운영하는 프로젝트에서 Git 브랜치와 환경을 매핑하여 배포 파이프라인을 구성하려고 합니다. 각 환경에 맞는 브랜치 전략과 자동 배포 트리거를 어떻게 설계하시겠습니까?
각 환경별로 대응하는 브랜치를 만들고, 브랜치별로 다른 배포 환경을 타겟팅하는 방법을 고려해보세요.
develop 브랜치는 개발 환경에, staging 브랜치는 스테이징 환경에, main 브랜치는 프로덕션 환경에 매핑합니다. GitHub Actions에서 각 브랜치별로 별도의 workflow를 구성하거나, 하나의 workflow에서 브랜치에 따라 다른 환경 변수를 사용하도록 설정합니다. develop 브랜치에 푸시되면 자동으로 개발 서버에 배포하고, staging 브랜치는 PR 병합 시 자동 배포, main 브랜치는 태그 생성 시에만 배포하도록 트리거를 다르게 설정합니다. 각 환경별로 secrets와 환경 변수를 분리하여 관리하고, 스테이징에서 충분한 테스트를 거친 후에만 프로덕션으로 승격시킵니다.
- • 환경별 브랜치 매핑 (develop-dev, staging-staging, main-production)
- • 브랜치별로 다른 배포 트리거와 환경 변수 설정
- • 스테이징 검증 후 프로덕션 승격 프로세스
개발, 테스트, 운영 환경을 분리하여 각 단계에서 검증을 거친 후 안전하게 프로덕션에 배포합니다.
스테이징 환경에서 테스트를 통과한 정확히 같은 코드를 프로덕션에 배포하려면 어떤 방법을 사용해야 하나요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!