Part I — The Notice
토요일 저녁, 단체방에 올라온 공지
CTO — Saturday 18:45
git.prost.team 쓰시는 분 에게 안내말씀
내일 git.prost.kr 로 옮길 예정입니다.
부탁 드릴 내용이 있는데 아래에 해당 하시는 분들 확인 하셔서 말씀 부탁드립니다
토요일 18시 45분 이후에 git.prost.team 에 commit & push 하신 분들 추후에 git.prost.kr 로 한번 더 부탁드립니다.
git.prost.kr 설정 완료하고 모든 프로젝트의 remote를 git.prost.kr로 옮겨주세요.
prost.kr 에 올라온 프로젝트들 사내 별도 VM에 옮겨주세요. 필요하신 사양, VM 대수 말씀 해주시면 서버 만들어 드리겠습니다. ( VM 당 4 Core, RAM 16 GB 제한 )
그 서버에 필요하신 세팅 후 말씀 부탁드립니다.
내일 18시 이후에는 prost.kr 에 연결 되어있는 내부 IP 설정 없애고 서버 PC로 옮길 예정입니다.
다들 바쁘시겠지만 협조 부탁드립니다.
NAS에서 git.prost.team으로 GitLab을 서빙하고 있었다. 자사 서버 구매를 계기로 prost.kr 도메인으로 깃랩을 이전하는 작업이다. 서버 이전 자체는 올바른 판단이다. NAS의 성능 한계, 디스크 I/O 병목, 백업 제약 — 전용 서버로 옮기면 해결되는 문제들이다.
하지만 이 공지에는 몇 가지 중요한 문제가 숨어 있다. 서버를 옮기는 것과 도메인을 바꾸는 것은 전혀 다른 차원의 작업이다. 서버 이전은 하드웨어의 문제다. 도메인 변경은 그 서버에 의존하는 모든 시스템, 모든 설정, 모든 링크의 문제다.
Part II — The Blast Radius
도메인 하나 바꾸면 깨지는 것들
git.prost.team이 git.prost.kr로 바뀌는 순간 영향을 받는 범위를 나열한다. "URL 하나 바꾸면 되지 않나?"라는 질문에 대한 답이다.
01 — Git Remote
로컬 클론 전체
모든 개발자의 모든 로컬 클론에 하드코딩된 remote URL이 깨진다. 개발자 N명 x 리포지토리 M개 = N x M번의 수동 변경. 한 명이라도 누락하면 push가 실패한다.
02 — CI/CD Pipeline
파이프라인 전체
.gitlab-ci.yml의 include 지시자, trigger URL, 환경 URL, 아티팩트 다운로드 경로, Runner 등록 토큰이 전부 구 도메인을 가리킨다. 파이프라인이 침묵 속에 실패한다.
03 — Webhook
외부 연동 전체
Slack 알림, Jira 연동, 배포 후 알림 등 프로젝트별로 설정된 webhook URL이 전부 무효화된다. 프로젝트가 100개면 webhook 설정도 100개.
04 — Container Registry
Docker 이미지 전체
Docker 이미지 태그에 호스트명이 포함된다. git.prost.team:5050/group/project:tag — 모든 이미지를 pull, retag, push 해야 한다. Dockerfile과 docker-compose.yml의 레지스트리 URL도 전부 수정.
05 — GitLab Pages
사내 문서 링크
기존 URL이 404를 반환한다. 사내 문서에 공유된 Pages 링크가 전부 사망한다. 위키, 컨플루언스, 슬랙 메시지에 붙여넣은 모든 링크가 죽은 링크가 된다.
06 — DB Internal URLs
이슈, MR, 위키
이슈, MR 설명, 위키, 릴리스 노트에 하드코딩된 전체 URL은 자동으로 갱신되지 않는다. 수천 개의 데드 링크가 DB에 남는다.
그 외에도 깨지는 것들
- 브라우저 북마크 — 개발자마다 수십 개씩 저장해둔 프로젝트, 이슈, MR 링크
- IDE 설정 — VS Code, IntelliJ의 저장된 Git remote URL, 프로젝트 설정 파일
- 셸 스크립트 — 배포 스크립트, 자동화 스크립트에 하드코딩된 호스트명
- SSH config — ~/.ssh/config에 설정된 호스트 별칭과 키 매핑
- .gitmodules — 서브모듈을 사용하는 프로젝트의 모든 참조 URL
- 사내 위키/컨플루언스 — 기술 문서, 온보딩 가이드에 공유된 모든 GitLab 링크
서버를 옮기는 건 하드웨어의 문제다.
도메인을 바꾸는 건 생태계 전체의 문제다.
Part III — What Went Wrong
ITIL이 말하는 변경관리,
이 공지가 어긴 것들
ITIL(Information Technology Infrastructure Library)은 IT 서비스 관리의 국제 표준 프레임워크다. 변경관리(Change Management) 프로세스는 인프라 변경의 위험을 최소화하기 위한 체계로, 전 세계 대부분의 IT 조직이 참조한다. 이 공지를 ITIL의 기준으로 대조하면, 거의 모든 항목에서 벗어나 있다.
이 공지
사전 공지: 약 24시간
작업 시점: 주말 (토요일 저녁 ~ 일요일)
데이터 이전: 개발자에게 re-push 요청
롤백 계획: 구 서버 접근 경로 차단 예고
전환 방식: 구 도메인 즉시 중단 (hard cutoff)
업계 권장
사전 공지: 최소 2주 (Normal Change)
작업 시점: 평일 업무시간, 모니터링 가능 시점
데이터 이전: backup/restore로 완전 이전
롤백 계획: 구 서버 최소 2주 병행 운영
전환 방식: DNS 리디렉트 + 병행 운영 후 전환
ITIL Normal Change 최소 기준의 1/14
ITIL은 서버 마이그레이션을 Normal Change(계획된 고위험 변경)로 분류한다. Normal Change의 최소 사전 공지 기간은 2주다. 24시간은 Emergency Change(보안 사고, 서비스 장애 등 긴급 상황) 수준이다. 도메인 변경은 긴급 상황이 아니다. 다음 주에 해도, 다음 달에 해도 되는 작업이다. 24시간 공지는 준비할 시간을 주지 않겠다는 것과 같다.
월요일 아침에 발견되는 재앙
토요일 18:45 공지 → 일요일 이전 작업 → 월요일 출근하면 전부 깨져 있다. 개발자가 주말에 메시지를 확인하지 않으면, 월요일 아침에 git pull이 실패하는 것으로 하루가 시작된다. CI/CD가 멈추고, 배포가 막히고, webhook 알림이 사라진다. 한 사람이 아니라 팀 전체가 동시에 이 상황에 직면한다.
backup/restore가 아닌 수동 re-push의 위험
GitLab 서버 마이그레이션의 정석은 gitlab-backup create로 전체 백업을 생성하고, 신규 서버에서 gitlab-backup restore로 복원하는 것이다. 이 방법은 리포지토리, 이슈, MR, 위키, CI/CD 설정을 완전히 이전한다. 개발자에게 re-push를 요청하면 다음의 위험이 발생한다: unpushed 로컬 브랜치 누락, git push --all --tags 미사용으로 인한 태그/브랜치 유실, 이슈/MR/위키 데이터의 완전 소실. 데이터 이전을 개발자 개인의 책임으로 전가하는 구조다.
되돌아갈 곳이 없다
"내일 18시 이후에는 prost.kr에 연결되어 있는 내부 IP 설정 없애고 서버 PC로 옮길 예정입니다." 이 문장의 의미는 명확하다. 구 서버의 접근 경로를 차단하겠다는 것이다. 신규 서버에 문제가 생기면 되돌아갈 곳이 없다. 변경관리의 가장 기본적인 원칙 — "언제든 이전 상태로 복구할 수 있어야 한다" — 이 부재하다.
hard cutoff의 대가
도메인 변경의 업계 표준은 구 도메인에서 신 도메인으로의 리디렉트를 설정하는 것이다. git.prost.team으로 들어오는 요청을 git.prost.kr로 자동 전달하면, 모든 기존 링크와 설정이 당장은 깨지지 않는다. 병행 운영 기간(보통 2주 이상) 동안 개발자들이 순차적으로 설정을 변경할 시간을 확보한다. 이 공지에는 리디렉트도, 병행 운영 기간도 없다. 즉시 전환(hard cutoff)이다. 하루 뒤 구 도메인은 소멸한다.
서버를 옮기는 건 맞다
도메인까지 바꾸는 건 다른 문제다
NAS의 한계를 벗어나 전용 서버로 이전하는 판단은 올바르다. 하지만 도메인 변경과 서버 이전은 분리해야 할 두 개의 작업이다.