제조업 고객사의 레거시 PLM 시스템 유지보수를 맡으면서, 형상관리를 SVN에서 git으로 이관했습니다. “체크아웃 받아서 새 리포에 푸시하면 끝 아닌가?” 싶었던 이 작업에서 실제로 겪은 것들 — 특히 이관하는 동안에도 계속 움직이는 레거시를 따라잡는 문제를 기록합니다.
배경: 왜 이관하는가
인수받은 시스템의 형상관리는 SVN이었습니다. 개발 환경은 Eclipse + SVN 플러그인 + Tomcat이라는 전형적인 구성이고, 이 자체로는 잘 돌아갑니다. 그런데 유지보수를 회사 체계에 태우려면 문제가 됩니다 — 사내 프로젝트 관리 시스템(PMS)의 개발 서버 프리뷰, 리뷰, 배포 연계가 전부 git 기반이기 때문입니다. 도구가 낡아서가 아니라, 우리 운영 체계와 물리는 지점이 git이라서 이관을 결정했습니다. 이관 명분은 이렇게 잡는 게 맞다고 생각합니다.
결정 1: 히스토리 전체냐, 스냅샷이냐
SVN → git 이관의 첫 갈림길입니다. git svn으로 리비전 히스토리 전체를 옮길 수도 있고, 최신 스냅샷만 옮겨 새 출발할 수도 있습니다. 이번엔 스냅샷 기준을 택했습니다.
- 과거 이력은 SVN 서버가 당분간 읽기 전용으로 남아 있어 조회 가능
- 10년치 리비전에는 바이너리·빌드 산출물이 섞여 있어 그대로 옮기면 리포만 무거워짐
- 유지보수 관점에서 필요한 건 “지금부터의 추적성”
히스토리가 법적·감사 요건이라면 다른 선택을 해야겠지만, 유지보수 인수 상황에서는 스냅샷 + 구 서버 보존이 실용적인 절충이었습니다.
결정 2: 움직이는 타깃 따라잡기
진짜 문제는 이겁니다. 이관 작업 중에도 운영 수정 건이 계속 SVN으로 들어옵니다. 서비스는 멈추지 않으니까요. “git으로 옮겼는데 그 사이 SVN에 커밋이 3개 더 쌓였다”가 반복되면 이관은 영원히 끝나지 않습니다.
그래서 이렇게 마무리했습니다.
- git 리포를 만들고 어느 시점의 스냅샷을 올린다 — 이 시점의 SVN 리비전 번호를 기록
- 개발·검증이 git 쪽에서 준비되는 동안, SVN에 추가된 리비전을 주기적으로 확인
- 전환 직전, 기준 리비전(이번 경우 r855)을 못 박고 그 시점까지의 변경분을 git main에 반영
- “이후의 모든 수정은 git으로만” — 전환 선언과 동시에 SVN은 읽기 전용 취급
포인트는 3번입니다. “대충 최신”이 아니라 정확한 리비전 번호로 동기화 지점을 못 박아야, 나중에 “그 수정 들어간 거 맞아요?”라는 질문에 “r855까지 전부 반영, 이후는 git 로그 보세요”라고 답할 수 있습니다. 형상관리 이관에서 가장 중요한 산출물은 코드가 아니라 이 한 문장이라고 느꼈습니다.
개발 워크플로우는 천천히 바꾼다
이관했다고 개발 방식을 하루에 다 바꾸지는 않았습니다. Eclipse에서 SVN 업데이트로 일하던 관성이 있으니, 전환 초기에는 기존 워크플로우를 유지하면서 git 쪽이 단일 소스라는 것만 확실히 했습니다. 도구 전환과 워크플로우 전환을 한 번에 하면 사고가 나기 좋습니다 — 소스의 진실이 어디 있는가(git)만 먼저 확정하고, 손에 익은 도구는 순차적으로 바꾸는 쪽이 안전했습니다.
PMS에 태우기
git이 단일 소스가 된 뒤에는 사내 PMS의 업무관리 > 서버관리에 개발 프리뷰 서버를 등록해, 다른 프로젝트들과 같은 화면에서 개발 서버 상태를 보고 관리할 수 있게 했습니다. 이관의 최종 목표가 이거였습니다 — “특수하게 관리되는 레거시”를 없애고, 회사의 다른 프로젝트와 똑같이 취급되는 프로젝트로 만드는 것.
교훈
- 이관 명분은 도구가 아니라 운영 체계에서 나온다. “SVN이 낡아서”보다 “우리 리뷰·프리뷰·배포 체계가 git이라서”가 정확한 이유다.
- 움직이는 시스템의 이관은 기준점 관리가 전부다. 동기화 시점의 리비전 번호를 못 박고, 전환 선언 이후의 진실은 한 곳에만 둔다.
- 스냅샷 이관은 부끄러운 선택이 아니다. 히스토리 요구사항을 확인하고, 구 서버 보존과 조합하면 실용적 정답일 수 있다.
- 도구 전환과 워크플로우 전환을 분리하라. 진실의 위치를 먼저 옮기고, 손버릇은 천천히.
덧붙여
이 작업도 AI 코딩 에이전트(Claude Code)와 페어로 진행했습니다. 리비전 확인·동기화 커밋·상태 스냅샷 기록 같은 반복 작업은 에이전트가, “스냅샷이냐 히스토리냐”와 “언제 전환을 선언하냐” 같은 결정은 사람이 했습니다. 다음 편에서는 이 시스템의 배포 체계를 다듬은 이야기를 다뤄볼 예정입니다.