SVN 잘 쓰고 있는데 왜 바꿔야 하나요 — 그때 제대로 못한 답변을 다시
미팅에서 나는 "협업이 좀 더 들어가 있다"고 답했다. 틀린 말은 아닌데 부족한 답이었다. SVN 과 TortoiseSVN 이 실제로 괜찮은 지점을 먼저 인정하고, 형상관리 관점에서 정확히 무엇이 다른지, 그리고 우리가 파는 게 기능이 아니라 속성이라는 이야기까지.
"저희는 SVN 에 TortoiseSVN 조합으로 잘 쓰고 있습니다. 이걸 왜 바꿔야 하나요?"
이 질문을 받았을 때 내 답은 "협업이 좀 더 들어가 있습니다" 정도였다. 틀린 말은 아니다. 근데 돌아오는 길에 계속 걸렸다. SVN 을 20년 쓴 조직에게 "협업이 더 된다"는 말은 아무 정보가 없는 답이다. 그쪽 입장에서는 지금도 협업을 잘 하고 있으니까. 그 자리에서 했어야 하는 답을 여기 다시 쓴다.
SVN과 TortoiseSVN은 실제로 무엇을 잘하나?
바꿔야 할 이유를 말하기 전에, 바꾸지 않아도 되는 경우부터 정직하게 정리하는 게 순서다. SVN 은 중앙집중식이라 소스의 단일 원본이 어디 있는지 물을 필요가 없고, 리비전 번호가 선형으로 올라가서 이력이 직관적이다. TortoiseSVN 의 탐색기 통합은 지금 봐도 잘 만든 UX 다. 커맨드라인을 쓰지 않는 인력도 우클릭 몇 번으로 형상관리에 참여할 수 있다는 건 작은 장점이 아니다. 그리고 머지가 불가능한 바이너리 산출물(설계 파일, 문서 원본류)에 락을 거는 워크플로우는 사실 Git 보다 SVN 쪽이 자연스럽다.
그래서 이런 조직이라면 나는 교체를 권하지 않는다. 인원이 적고, 저장소가 하나이고, 반영이 순차적이어서 브랜치가 사실상 필요 없고, 감사 대응 요구가 낮은 조직. 거기서 SVN 은 문제가 아니라 답이다. 도구를 바꾸는 비용은 확정적이고 이득은 불확실한데, 이득이 작은 조직에게 그 거래를 권하는 건 영업이지 조언이 아니다.
그러면 형상관리 관점에서 정확히 뭐가 다른가?
차이는 "커밋을 기록하는가"가 아니라 "커밋 앞뒤의 맥락을 기록하는가"에 있다. SVN 은 무엇이 언제 바뀌었는지를 안다. 그건 잘 안다. SVN 이 모르는 건 그 변경이 어떤 요구사항에서 왔고, 누가 검토했고, 어떤 테스트를 통과했고, 언제 어느 서버로 나갔는지다. 그 맥락은 지금 어딘가에 있긴 하다. 결재 문서에, 메일함에, 회의록에, 담당자의 기억에. 형상관리 도구 밖에.
CollabOps 에서 형상관리를 한다는 건 그 맥락이 커밋과 같은 평면에 남는다는 뜻이다. 이슈에서 브랜치가 나오고, 변경요청에서 승인이 남고, 파이프라인에서 검증 결과가 남고, 배포 기록이 그 전부와 연결된다. 3년 뒤에 "이 코드 왜 이렇게 됐지?"의 답이 리비전 로그 한 줄이 아니라, 클릭 몇 번으로 내려가지는 연결된 기록으로 나온다. 브랜치·머지 동시 개발이나 줄 단위 추적 같은 기능 차이도 물론 있고 그건 락 기반 형상관리 글에서 다뤘지만, 솔직히 그건 부차적이다. Git 대 SVN 기능 비교표는 15년 전에 끝난 논쟁이고, 그 표로는 20년 무사고 조직을 설득할 수 없다는 것도 안다.
설득이 되는 건 이 질문이다. 감사나 장애 원인 분석 때, 변경의 전후 맥락을 재구성하는 데 며칠이 걸리는가. 그 며칠이 매번 누구의 야근인가. SVN 을 잘 쓰는 조직일수록 이 비용을 "형상관리 비용"으로 집계하지 않는다. 형상관리 도구 밖에서 발생하니까. 근데 그게 형상관리가 진 빚이다.
기능이 아니라 무엇을 파는 건가
이 글에서 제일 하고 싶었던 말이 이거다. 우리가 파는 건 기능 목록이 아니라 속성이다. "이슈 트래커 있음, 저장소 있음, CI 있음"의 합은 도구 세 개를 사면 SVN 옆에도 만들 수 있다. 우리가 파는 건 그 셋이 처음부터 한 평면에 있어서, 증적이 일하는 행위의 부산물로 쌓이는 속성이다. 폭포수 글에서 쓴 문장을 다시 쓰면, 기능은 나중에 추가할 수 있지만 속성은 처음부터 있거나 영원히 없다.
사람들이 스마트폰을 살 때 CPU 클럭을 비교해서 사지 않는 것과 같은 구조다. 사는 건 "그냥 된다"는 경험이다. 우리 데모가 잘 되는 날은 기능을 많이 보여준 날이 아니라, 이슈 하나가 배포와 감사 로그까지 끊김 없이 흘러가는 걸 보여준 날이었다. 그 흐름이 가치고, 기능은 그 가치의 부품이다.
그러니까 그 질문에 대한 제대로 된 답은 이거였다. "SVN 을 잘 쓰고 계시다는 말을 의심하지 않습니다. 다만 SVN 이 잘하는 일은 형상관리 업무의 절반이고, 나머지 절반인 맥락과 증적은 지금 사람이 하고 있습니다. 저희는 그 나머지 절반을 시스템으로 옮기는 걸 팝니다. 그게 필요 없는 조직이면 안 사시는 게 맞습니다."
전환을 결정한 조직에게는 기존 이력을 잃지 않는 세 가지 경로(전체 이전, 읽기 전용 인덱싱, 미러 공존)가 있고, 한 팀부터 시작하라는 조언은 안정성이 곧 레퍼런스에서 한 그대로다. 급할 게 없다. SVN 은 어디 도망가지 않고, 무사고 기록은 쌓이는 쪽이 이긴다.
비슷한 글
소스 수정 전에 락을 겁니다만 — 락 기반 형상관리에서 동시 개발로 넘어간다는 것
공공기관 미팅에서 반복해서 받는 질문이 있다. 지금은 파일에 락을 걸고 수정하는데, 이 솔루션은 어떤 형태냐는 것. 락 모델과 브랜치·머지 모델의 차이, 락 없이 사고를 막는 방법, 그리고 기존 이력을 잃지 않는 전환 경로까지.
백재민
GPU가 없는데 PoC가 되나요 — AI를 옵션 레이어로 설계한 이유
PoC 를 하려는데 GPU 가 없다는 기관에게 하는 답. 에이전트만 GPU 를 요구하고 플랫폼의 나머지는 전부 CPU 서버에서 돈다. 30일 PoC 가 실제로 어떻게 진행되는지, 문서 자동 생성은 어디까지 자동인지, 그리고 검증하고 쓰는 게 맞다는 기관의 말이 왜 옳은지.
백재민
공공기관은 왜 SVN을 계속 쓰는가, 안정성이 곧 레퍼런스라는 말
어느 공공기관 실장님이 말했다. SVN 왜 쓰냐고? 내부에서 힘들다고 해도 안정적이라 쓰는 거다. 안정성이 제일 중요하다. 그것이 레퍼런스다. 공공 도입의 실제 의사결정 구조와, 벤더가 그 앞에서 해야 할 일에 대해.
백재민