사실 SVN은 따위가 아닙니다.

국내에서, 현대의 형상관리 툴 시장은 Git과 SVN이 양분하고 있습니다.

GitHub나 GitLab, Bitbucket 등, 여러 서비스가 있지만, 대부분의 플랫폼에서 제공하는 형상관리 서비스는 Git에 기반합니다.

게임에서 스킬트리를 찍듯이, 극소수의 외로운 늑대들을 제외한 개발자들은 필연적으로 Git과 SVN 트리 중 하나를 타게 됩니다.

형상관리의 목적은 동일합니다. 내 소스를 신뢰할 수 있는 저장소에 두고, 협업을 통해 코드를 생산/관리함에 목적이 있습니다.

Git과 SVN은 각자의 방식으로 목적을 이룩합니다.

리누스 토르발즈가 만족할만한 형상관리 툴이 없어서 직접 만든 Git이, 형상관리의 전국시대를 단번에 끝낸 일화는 다들 아시리라 생각합니다.

많은 형상관리 기업에겐 지금의 유료 서비스를 무료로 전환하고 남은 인원이라도 챙길지, 도산할지 선택해야했고, 선택의 결과물은 서두의 문장으로 나타나죠.

만든 사람이 컴퓨터 공학계의 천재라서 그런걸까요? Git은 그 중에서도 특히나 강력하고, 난해합니다.

형상관리 "도구" 주제에, Git은 많은 부분을 간섭합니다. SVN이였으면 대충 넘어갈 수 있는 요소들도 사사건건 시비를 걸면서 물어봅니다. 대답을 보류하거나 안 하면, 더 이상 진행하지 않은 꼬장까지 부립니다.

힘들게 코드 짠 사람은 난데, 지가 뭐라도 되는 지 싶습니다. 그냥 입닫고 코드 보관이나 했으면 좋을텐데요.

이와 같은 특징 때문에, Git을 더욱 잘, 효율적으로 쓰기 위해선 SVN에선 신경쓰지 않았던 형상관리 전략이 필수입니다.

이 전략 수준은 단순히, "브랜치 main 이걸로 하고, 여기에 모아" 정도의 수준이 아닙니다. 형상관리 단계에서 겪을 수 있는 케이스를 선별하고, 이에 대한 대응책을 마련해야 합니다. 각 환경별 브랜치도 나누고, feature는 어떻게 따고 합쳐야 하는지, 배포 브랜치는 어떤 방식으로 머지해야하는 지 등..

여러 회사들은 서비스 착수 이전에, 레포지토리의 브랜치 전략을 수립하는데도 많은 시간을 소모합니다.

이러한 고민의 결과물은 Git Flow, Trunk-based, Feature Flag 등, 다양한 정책으로 도출됩니다.

그럼에도 불구하고 Git은 강력합니다. SVN에 비해 많은 서비스에서 Git을 지원하고 있습니다. Git을 지원하지 않는 형상관리 서비스가 시장에서 차지할 수 있는 파이는 적습니다.

단순한 형상관리를 넘어, GitHub Actions 같은 CI/CD는 물론이거니와, AWS와 연동해서 배포 파이프라인을 구축할 수도 있습니다.

SVN에겐 오랜 친구 FTP가 있으니 너무 걱정은 안 해도 되겠네요. 힘들 때 친구가 진정한 친구 아니겠어요?

우리는 알고 있습니다. SVN을 고집하는, SVN이 아니면 안 되는 곳들이 어떻게 일하는지. OKKY 조금만 뒤적거려도, 생생한 경험담을 전해들을 수 있습니다.

사실 모두가 "개발만 잘하면 된다"고 말하지만, "잘한다"는 기준은 어떨까요? 단순히 본수나 속도로만 결정되진 않을겁니다.

개발은 단순히 코드를 치는 행위가 아닙니다. 서비스를 기획하는 순간부터, 코드를 생산하고, 생산한 코드를 관리, 배포하는 모든 요소가 개발입니다.

만약 그렇게 생각하지 않았다면, "개발만 잘하면 된다"는 말은 "코드 타이핑만 잘하면 된다" 라는 표현이 더 적합할겁니다.

잘 모르시겠다구요? 내가 간 식당의 요리사가 "요리사가 칼질만 잘하면 됐지 뭘 더 바래?"라고 말한다면 어떤가요?

불조절이나 간맞춤은 무신경하지만, 이 집 재료 썬 칼질 하나는 기가 막힙니다,

그 마저도 배달 온 음식이 죄다 섞여서 음식점에 전화했는데, "내가 기사에게 전달했을 땐 문제 없었으니, 내 잘못 아니니까 그냥 먹어라"라고 말하는 사장에게 별점을 몇 개 주실건가요?

사실 SVN은 따위가 아닙니다. 좋은 형상관리 도구입니다. 하지만 이걸 쓰는 우리, 그리고 당신은 어떤가요?

단순히 몰라서, 고민하기 귀찮아서, 배우기 싫다는 핑계를 포장하기 위해 SVN으로 모인다면, SVN은 지원 사후에도 따위로 불릴 것입니다.