Git 리드·아키텍트 배포·운영 기술면접

Trunk-Based Development를 선택하겠습니다. 대규모 조직에서는 장수명 브랜치가 많아질수록 머지 충돌과 통합 지연이 기하급수적으로 증가합니다. Trunk-Based에서는 개발자들이 main 브랜치에 최소 하루 1회 이상 커밋하며, Feature Flag를 통해 미완성 기능을 숨깁니다. CI 파이프라인은 모든 커밋마다 자동 테스트를 실행하고, CD는 main 브랜치의 모든 커밋을 프로덕션까지 자동 배포합니다. Git Flow는 릴리즈 주기가 긴 패키지 소프트웨어에 적합하지만, 빠른 배포가 필요한 마이크로서비스에는 브랜치 관리 오버헤드가 큽니다. GitHub Flow는 중간 규모에 적합하지만, 100명 이상 환경에서는 PR 리뷰 병목이 발생할 수 있습니다.

Expand-Contract 패턴을 적용한 3단계 배포 전략을 사용합니다. 1단계(Expand)에서는 새 컬럼을 추가하되 기존 코드와 호환되도록 nullable로 생성하고, 이를 migration-v1 태그로 표시합니다. 2단계에서는 애플리케이션 코드를 배포하여 신구 컬럼 모두에 데이터를 쓰도록 하며, release-v2 태그를 생성합니다. Blue-Green 스위칭은 이 단계에서 수행하고, 문제 발생 시 트래픽만 이전 환경으로 되돌립니다. 3단계(Contract)에서는 충분한 모니터링 후 구 컬럼을 제거하며, migration-v2 태그로 표시합니다. Git 워크플로우는 각 단계마다 별도 PR과 태그를 생성하고, CI/CD 파이프라인에서 태그 패턴에 따라 마이그레이션과 배포를 자동화합니다. 롤백 시에는 release 태그만 되돌리고 스키마는 그대로 유지하여 데이터 손실을 방지합니다.

Git diff를 활용한 Affected Service Detection과 의존성 그래프 기반 빌드 전략을 사용합니다. 먼저 각 서비스의 루트 디렉토리에 package.json 또는 service.yaml로 의존성을 명시하고, Nx나 Turborepo 같은 모노레포 도구로 의존성 그래프를 구축합니다. CI 파이프라인에서는 'git diff HEAD~1 --name-only'로 변경된 파일 목록을 추출하고, 영향받는 서비스와 그에 의존하는 모든 downstream 서비스를 식별합니다. 공유 라이브러리 변경 시에는 의존하는 모든 서비스를 빌드하되, 캐싱을 활용해 중복 빌드를 방지합니다. 각 서비스별로 독립적인 Docker 이미지를 빌드하고, Git 커밋 SHA를 이미지 태그로 사용하여 추적성을 확보합니다. 배포는 Kubernetes의 Argo CD를 사용해 GitOps 방식으로 자동화하며, 각 서비스의 배포 상태를 Git 히스토리로 추적합니다.

Git revert를 사용한 롤백을 선택합니다. 이전 커밋으로 직접 배포하는 방법은 빠르지만 Git 히스토리에 롤백 기록이 남지 않아 추적성이 떨어지고, 이후 정상 배포 시 이미 배포된 커밋을 다시 푸시해야 하는 혼란이 발생합니다. Git revert는 문제가 된 커밋을 되돌리는 새로운 커밋을 생성하여 히스토리를 보존하고, CI/CD 파이프라인이 정상적으로 동작합니다. 롤백 후에는 revert된 상태에서 새로운 브랜치를 생성하여 핫픽스를 작업하고, 수정이 완료되면 revert 커밋을 다시 revert하여 원래 기능을 복원한 뒤 핫픽스를 적용합니다. 모든 과정은 태그로 표시하여 각 배포 시점을 명확히 추적할 수 있도록 합니다. 롤백 프로세스는 Runbook으로 문서화하고 정기적으로 훈련하여 장애 대응 시간을 최소화합니다.

Git의 GPG 서명과 GitOps를 결합한 감사 추적 시스템을 구축합니다. 모든 개발자는 GPG 키로 커밋에 서명하고, Git 서버는 서명되지 않은 커밋을 거부하도록 설정합니다. 배포 승인은 Git 저장소의 별도 브랜치나 파일(예: deployments/production.yaml)에 대한 PR로 관리하며, 승인자의 서명된 머지 커밋이 배포 권한을 증명합니다. CI/CD 파이프라인은 배포 시 커밋 SHA, 타임스탬프, 배포자 정보, GPG 서명을 포함한 메타데이터를 불변 저장소(예: S3, Elasticsearch)에 기록합니다. Kubernetes 환경에서는 Argo CD의 Application 리소스가 Git 커밋과 1:1 매핑되어 배포 상태를 추적합니다. 정기적으로 Git 히스토리와 실제 프로덕션 상태를 비교하는 drift detection을 수행하여 수동 변경을 탐지하고, 모든 감사 로그는 WORM(Write Once Read Many) 스토리지에 보관하여 변조를 방지합니다.