월요일 아침, git push가 안 될 때

Part I — Monday Morning

출근하면 벌어지는 일

월요일 아침 9시. 터미널을 열고 습관적으로 git pull을 입력한다. "fatal: Could not resolve host: git.prost.team". 어제 저녁 CTO가 올린 공지를 뒤늦게 확인한다. git.prost.team은 이제 없다. git.prost.kr이 새 주소다.

당황하지 말 것

가장 먼저 해야 할 일은 당황하지 않는 것이다. 로컬에 클론된 코드는 안전하다. Git은 분산 버전 관리 시스템이고, 로컬 저장소에 전체 히스토리가 있다. remote URL만 바꿔주면 된다.

remote URL 변경

가장 먼저 해야 할 것

현재 설정된 remote URL을 확인하고, 구 도메인을 새 도메인으로 변경한다. HTTPS와 SSH 중 자신이 사용하는 방식에 맞게 설정한다.

remote url 변경
# 현재 remote 확인
git remote -v

# origin URL 변경
git remote set-url origin https://git.prost.kr/group/project.git

# 변경 확인
git remote -v

# SSH를 사용하는 경우
git remote set-url origin git@git.prost.kr:group/project.git

SSH 키 확인

SSH 사용자라면 반드시 확인

SSH로 GitLab에 접속하고 있었다면 새 도메인에 대한 SSH 접속을 확인해야 한다. known_hosts에 새 호스트가 등록되어 있지 않으면 첫 접속 시 경고가 뜬다. ~/.ssh/config에 호스트 별칭을 사용하고 있었다면 새 호스트를 추가한다.

ssh 설정
# SSH 접속 테스트
ssh -T git@git.prost.kr

# ~/.ssh/config에 새 호스트 추가 (필요 시)
Host git.prost.kr
    HostName git.prost.kr
    User git
    IdentityFile ~/.ssh/id_ed25519
    PreferredAuthentications publickey

.gitmodules 확인

서브모듈을 사용하는 프로젝트

서브모듈을 사용하는 프로젝트라면 .gitmodules 파일에 구 도메인이 하드코딩되어 있다. URL을 수정한 후 반드시 git submodule sync를 실행해야 실제 설정에 반영된다.

submodule 동기화
# .gitmodules 파일에서 구 도메인 찾기
grep -r "git.prost.team" .gitmodules

# URL 수정 후 동기화
git submodule sync --recursive
git submodule update --init --recursive

Part II — Automation

한 방에 해결하는 자동화 스크립트

리포지토리가 1~2개면 수동으로 해도 된다. 하지만 10개, 20개라면 스크립트가 필요하다.

스크립트 1 — 현재 디렉토리의 단일 리포지토리에서 remote URL을 한 줄로 변경한다.

one-liner
git remote set-url origin $(git remote get-url origin | sed 's/git.prost.team/git.prost.kr/g')

스크립트 2 — 워크스페이스 전체를 순회하며 모든 리포지토리의 remote URL을 일괄 변경한다.

update-all-remotes.sh
#!/bin/bash
# 사용법: ./update-all-remotes.sh ~/workspace

OLD_DOMAIN="git.prost.team"
NEW_DOMAIN="git.prost.kr"
WORKSPACE="${1:-.}"
COUNT=0

find "$WORKSPACE" -name ".git" -type d | while read gitdir; do
    repo=$(dirname "$gitdir")
    cd "$repo"

    for remote in $(git remote); do
        old_url=$(git remote get-url "$remote")
        if echo "$old_url" | grep -q "$OLD_DOMAIN"; then
            new_url=$(echo "$old_url" | sed "s|$OLD_DOMAIN|$NEW_DOMAIN|g")
            git remote set-url "$remote" "$new_url"
            echo "[OK] $repo ($remote): $new_url"
            COUNT=$((COUNT + 1))
        fi
    done

    cd - > /dev/null
done

echo ""
echo "총 ${COUNT}개 remote URL 변경 완료"

스크립트 3 — 변경이 제대로 되었는지 검증한다. 구 도메인이 남아있으면 경고를 출력한다.

verify-remotes.sh
#!/bin/bash
# 변경 후 검증 — 구 도메인이 남아있으면 경고

OLD_DOMAIN="git.prost.team"
WORKSPACE="${1:-.}"
FOUND=0

find "$WORKSPACE" -name ".git" -type d | while read gitdir; do
    repo=$(dirname "$gitdir")
    cd "$repo"

    for remote in $(git remote); do
        url=$(git remote get-url "$remote")
        if echo "$url" | grep -q "$OLD_DOMAIN"; then
            echo "[WARNING] $repo ($remote): $url"
            FOUND=$((FOUND + 1))
        fi
    done

    cd - > /dev/null
done

if [ "$FOUND" -eq 0 ]; then
    echo "모든 remote URL이 정상 변경되었습니다."
fi

Part III — A Better Way

CTO에게 제안하는 한 가지

아직 마이그레이션이 시작되지 않았다면, 혹은 비슷한 상황을 앞두고 있다면, CTO에게 이렇게 제안할 수 있다.

CTO에게 보내는 메시지

"서버 이전은 찬성합니다. 한 가지 제안이 있는데, 도메인은 기존 git.prost.team을 유지하고 DNS A 레코드만 새 서버 IP로 변경하면 어떨까요? 이렇게 하면 모든 개발자의 remote URL, CI/CD 파이프라인, Slack webhook이 그대로 작동합니다. 개발자 전원이 수동으로 remote를 바꾸는 것보다 DNS 설정 한 줄 바꾸는 게 리스크가 훨씬 적습니다."

도메인 변경

개발자 전원 remote 변경 필요

CI/CD 파이프라인 수정

webhook 재설정

Container Registry 이미지 retag

최소 2주 소요

롤백 복잡

DNS만 변경

개발자 작업 0건

CI/CD 그대로 작동

webhook 그대로 작동

Registry 그대로 작동

DNS 전파 5~30분

롤백은 DNS 원복

좋은 인프라 변경은
개발자가 눈치채지 못하는 변경이다.

물론 도메인 변경이 불가피한 상황도 있다. prost.team 도메인의 소유권/갱신 문제, 회사 리브랜딩, 보안 정책 등. 그럴 때는 1편에서 분석한 문제점을 인지하고, 2편의 4주 타임라인을 따르는 것이 정석이다.

Part IV — Checklist

마이그레이션 생존 체크리스트

마이그레이션 전 (Before)

모든 로컬 변경사항을 commit + push 했는가
중요 브랜치가 remote에 전부 올라가 있는가 (git branch -a로 확인)
stash에 남겨둔 작업이 있는가 (git stash list)
서브모듈을 사용하는 프로젝트가 있는가
CI/CD 파이프라인에서 구 도메인을 하드코딩한 곳이 있는가

마이그레이션 중 (During)

CTO/인프라팀에 마이그레이션 완료 확인을 받았는가
새 도메인으로 SSH/HTTPS 접속이 되는가
update-all-remotes.sh 스크립트를 실행했는가
verify-remotes.sh로 구 도메인 잔존 여부를 확인했는가
git pull이 정상 작동하는가

마이그레이션 후 (After)

IDE(VS Code, IntelliJ)의 Git 설정이 새 URL을 가리키는가
.gitmodules가 있다면 업데이트 + git submodule sync 했는가
Docker 이미지를 빌드하는 프로젝트의 레지스트리 URL을 변경했는가
로컬 CI/CD 설정(.gitlab-ci.yml)에 구 도메인 참조가 남아있지 않은가
브라우저 북마크를 업데이트했는가

좋은 인프라 변경은
개발자가 눈치채지 못하는 변경이다

서버가 바뀌든 도메인이 바뀌든, 개발자에게 중요한 건 코드가 안전하고 워크플로우가 끊기지 않는 것이다. 스크립트를 준비하고, 더 나은 방법을 제안하자.