SVN의 문제점 ? 아니 우리의 문제점 !
예전에 취뽀 글에서 언급했듯 한 제조업 회사의 IT부서에서 프론트엔드 개발자로 근무중이다.
본론부터 말하자면 우리 회사는 형상관리 툴로 SVN을 사용하고 있다.
(SVN은 SubVersion의 약자로서 2000년 아파치에서 개발한 형상관리 툴이다.)
🤭(??): 레거시 사용하고 계시네요 ㅋㅋ
🤨(나): ????
SVN을 잘 몰랐기에 공부를 하던 와중 커뮤니티에서 SVN이 레거시라는 이유만으로 꽤나 놀림 받고 있었다.
하지만 SVN이랑 Git을 비교해보았을 때 Git이 SVN보다 우월하며, SVN 따위는 감히 넘 볼 수 없는 그런 툴은 아니라고 생각한다.
그럼 쓸만한(?) 형상관리 툴인 SVN을 포기하고 왜 이번에 Git을 도입하려했는가 ?
먼저 SVN은 Git과 비슷하게 trunk라는 하나의 큰 줄기로부터 branch들을 생성해
병합하여 프로젝트를 만들어가는 형상관리 툴이다.
흔히 git에서도 main 브랜치를 바탕으로 branch들을 만들어 생성하고 병합하는 것과 유사하다고 보면 된다.
그런데 우리 회사는 trunk도 branch도 사용하지 않는다.
trunk를 사용하지 않고 그저 공유폴더처럼 사용하고 있으며
branch를 사용하지 않아 배포되는 소스코드를 팀원들이 update받고 commit하는 상황이다.
(SVN에서 update는 git의 pull, commit은 push와 같은 뜻을 지니고 있다.)
이렇듯 형상관리라는 포장지에 포장된 폭탄이 심지에 불이 붙은 채로 팀원끼리 주고 받은 셈이다.
비상🚨비상🚨
첫번째 문제 발생은 내가 만들어냈다.
입사 3일차부터 배터리가 부풀어 터질거 같은 노트북을 받고 react 마이그레이션 작업을 시작했다.
프로젝트의 디자인 패턴을 파악 및 분석을 마치고 재사용이 가능하다고 판단된 컴포넌트를 사용하여
기존 iframe으로 되어있는 JSP 컴포넌트를 지우고 리액트 컴포넌트로 만들어냈다.
이후 SVN에 commit(git으로 말하자면 push)을 사용하여 저장소에 소스코드를 올려야하는 상황이다.
처음 써보는 툴이고 따로 브랜치를 만들지 않아서 걱정스러운 마음에 과장급 부장급분들에게 여쭤보았다.
하지만 branch는 사용하지 않는다는 대답과 함께 그냥 commit하라는 이야기에 마음은 더욱 더 불안할 수 밖에 없었다.
그렇게 저장소에 올라가고 다른 분들이 저장소의 소스코드를 각자 로컬로 다운을 받기 시작했다.
🤨: 이거 에러가 엄청나오는데요 ???!!!
문제는 내가 재사용이 가능한 공용 컴포넌트라고 생각했던 컴포넌트가 사실 공용 컴포넌트가 아니였던 것이다.
이내 실수는 바이러스와 같이 퍼져나갔고 나의 commit 이전으로 원복을 시키고 배포는 진행되었다.
이렇게 사건이 마무리되나 싶었지만 에러가 발생한 소스코드를 다운 받으신 분들은 개인 로컬에 history가 없기 때문에 로컬에서 개발중이였던 자신의 기능들이 모두 뒤엉켰다는 것이다.
commit의 주기에 따라 어느정도 살릴 수 있겠지만 그렇지 않다면 처음부터 개발을 다시 해야할 수 있는 상황인 것이다.
이후 몇 개월이 지나고 기능을 배포 전 commit을 깜빡하는 분이 계셔서 팀장님이 회의 시간에 형상관리에 대한 문제를 지적하셨다.
내가 생각하는 우리의 문제와 해결방안
팀장님께서 웹 개발 팀원들에게 개발자가 이러한 문제를 계속해서 낸다는 것은 정말 어처구니 없는 일이라고 말씀하시고 문제를 빠르게 해결하라고 말씀하셨다.
년차가 높으신 분들은
이클립스에서 SVN 에러가 잦은 문제이다.
스프링 부트가 너무 무거워서 그렇다(?).
공용 컴포넌트는 한명이 수정해라(?).
등등의 아이디어를 내셨다.
(스프링 부트랑 공용 컴포넌트를 한명이 수정하라는 말씀은 문제가 아닌것 같은데...😅)
내가 생각한 문제는 다음과 같다.
첫째. 개인의 history를 가지지 않는 형상관리는 불안하다.
둘째. 관리자급의 감시가 없다.
먼저 SVN은 좋은 형상관리 툴이긴 하지만 잦은 충돌과 내 로컬에서의 history가 없기 때문에
추후 문제가 발생했을 때 내가 만든 코드와 기능들을 복원하기 어려울 수 있다.
(물론 기능을 잘게 쪼개고 자주 commit하면 어느정도 복원이 가능하다.)
그렇기 때문에 문제가 발생했을 때 개인이 개발한 소스코드 복원이 어려워 다시 개발을 해야하는 불상사가 일어나게 된다.
(이제 껏 다른분들은 커밋하기전에 폴더를 압축해서 백업 해놓으신다고...)
두번째로는 관리자급의 부재이다.
팀원이 main 브랜치에 PR을 넣을 때 대부분의 회사들은 코드리뷰와 이슈 컨벤션등을 확인하고
팀장급의 직급을 가지신 분이 최종적으로 PR을 승인하고 반영된다.
하지만 우리팀은 그러한 안전장치가 없다.
개개인이 손쉽게 저장소에 위험한 코드들을 올릴 수 있고 혹은 놓치는 부분에 있어 아무도 확인을 해주지 않는다.
또한 저장소에 에러가 발생한 코드를 그대로 올려놓고 방치하는 경우도 있어서 전체를 update(git에서의 pull)도 원하는 파일과 폴더를 선택해서 부분부분 받아야하고 commit(git에서의 push) 또한 부분부분 해야한다.
아무도 안해 ? 그럼 내가 해.
기존의 프로젝트는 규모가 큰 편이라 Git으로 마이그레이션 하기에는 리스크가 크며
사내에 Git을 잘 다루시는 분이 안계신다.
그렇다고 신입 개발자가 모든 책임을 가지고 마이그레이션을 진행한다는 것은 말도 안되는 짓이다.
그러다 사수와 함께 자그만한 프로젝트를 맡게 되었고 사수에게 이번 프로젝트는 깃으로 하는게 어떻겠냐고 물어봤다.
사수도 깃에 대한 열린 마음으로 프로젝트를 시작했다.
첫번째로 기존 모놀로식 방식에서 멀티레포 방식으로 바꾸었다.
프론트와 백의 레포를 따로 생성하고 관리하는 것인데 멀티레포를 선택한 이유는 프론트와 백의 commit을 분산시키기 위함이 가장 컸다.
기존의 모놀리식 방식으로 개발을 진행했었는데 프론트와 백의 commit이 뒤엉켜 백업을 하기도 힘들고
commit을 추적하는데에 어려움도 느꼈다.
두번째로 Issue를 활용한 티켓관리다.
github에서는 Issue라는 기능을 지원해주는데 이는 기능개발/에러핸들링/조언 등등 여러가지의 태그로
사용이 가능하다. 우리는 대부분 기능개발과 에러를 수정하는 티켓을 사용한다.
세번째로는 git flow 브랜치 전략이다.
아마 가장 많이 사용하는 브랜치 전략이 아닐까 생각이든다.
이전 SVN을 사용할 때 배포 용도로 사용하는 하나의 브랜치만 사용하다보니 너무나도 위험했다.
자그만한 실수가 사용자에게 큰 불편함을 주기 때문에 이는 큰 문제라 생각을 했다.
git flow 전략은 환경에 따른 브랜치들을 만들어 사용하는데 우리는 따로 QA가 있거나 프로젝트의 버전 관리를 하지 않아 배포 용도인 main과 개발 용도인 dev 그리고 각자의 기능들을 개발하는 branch들로 이루어져있다.
네번째로는 컨벤션이다.
개인적으로 컨벤션은 타이트하면 타이트 할 수록 에러를 방지하기 좋다는 생각을 가지고 있다.
그 중 컨벤션하면 가장 떠오르는 eslint가 있는데 eslint는 잠시 나중으로 미루었다.
왜 eslint를 사용하지 않았는지 궁금해 하실 수 있는데 git 명령어와 Issue관리로도 버거워하는 현시점에서 eslint까지 도입하면 도저히 개발 속도가 안날 거 같기 때문이다.
팀원들이 git에 대해 익숙해지고 형상관리가 원활하게 진행되면 그때 eslint를 적용해도 문제가 없다 생각이 들었다.
마지막으로는 서로가 관리자이다.
문제였던 관리자의 부재로 인한 형상관리의 이슈들은 서로가 서로를 감시하는 파놉티콘과 같은 형태로 이루워져있다.
PR은 모두가 같이 하도록 하였고 문제가 발생했을 때 숨기지말고 서로에게 도움을 요청하기로 약속했다.
github에 PR에 제한을 걸어놔 특정 인물이 허락하지 않으면 PR을 못하도록 하는 설정도 있었는데
이는 private 레포지토리에선 유료다...(우린 무료에요...)
결과는 성공
프로젝트가 마무리 된 것은 아니지만 어느정도 사수가 git 활용에 익숙해지기 시작하고
프로젝트도 60% 정도 개발이 진행되었다.
무엇보다 누군가 실수를 한다 하더라도 쉽게 문제점을 파악하고 이전 버전으로 되돌리고 해결할 수 있게 되었다.
하나의 안전 장치를 달아 놓은 셈이다.
그리고 PR을 하는 단계에서 서로 코드리뷰를 진행하고 각자가 어떠한 일을 하고 있는지 이슈를 통해 투명하게 공유되고 있다.
또한 Git은 업계표준이라고 할 정도로 많은 곳에서 사용하고 있기 때문에 다른 곳으로 이직을 하실 때도
큰 도움이 될거라고 생각이든다.
비록 신입 개발자가 주변 개발자분들 바짓가랑이 부여잡고 Git을 도입해서 많이 부족하지만
안전하게 개발을 할 수 있게 되어서 정말 행복합니다.
긴 글 읽어주셔서 감사해요.😘
글이 많은 도움이 되었습니다, 감사합니다.