디자인에 Git을 도입한지 3주가 지났다
디자인인가 싶은 이야기
❝ 이 글은 Git의 튜토리얼이 아닙니다.
분산적, 일회적 솔루션 수습하는 중
한동안 디자이너가 나 혼자일 때가 있었는데 그 기간 동안 나는 큰 실수를 하게 된다. 갑자기 혼자가 되어 커버할 업무량이 많아졌는데 제품들은 대대적인 업데이트를 했다. 파일은 점점 분산되고 나는 일회성 솔루션을 내기 바빴다. 업무 로그는 점점 내 머리 속에만 정리되기 시작했다.
그래서 최근 새로운 디자이너 분이 오셔서 온보딩할 때 상당히 애를 먹었다. 사실 지금도 하루하루 수습 중에 있다.. :) 새로운 버전을 만들어내면서 지난 버전과의 공백을 f/u하고 있는 느낌이랄까.. 그래서 소스 및 버전 관리에 대한 필요성을 절실히 느끼며 앞으로 잘하면 되지! 라고 생각하고 있었다.
Sketch가 또다시 트렌드를 만들어냈다
New Sketch documents are basically zipped folders, containing JSON files that describe the document data, plus a number of binary assets (bitmap images, document preview…)
하지만 어떻게? 마침 지난 2월, 스케치가 파일 포맷을 바꾸면서 Git을 통한 버전 관리가 본격적으로 가능해졌다. (이전에도 가능했고 Plug-in도 있었지만 한계가 있었다) 항상 Trend로 다가와 Dominance가 되곤 하는 스케치는 또다시 디자인 팀(혹은 그 이상)의 업무 방식에 변화를 주었다.
사실 나는 '개인 혹은 기업이 Git을 통해 협업하고 Github이라는 서비스에 아카이브를 한다' 정도로만 알고 있었는데 어떤 글에서 평행 우주라는 비유를 듣고 바로 도입을 제안했다.
적절한 비유 - 평행 우주
확실히 디자이너 커뮤니티에서 화제가 되고 있는 Git. 핫해보이지만 도입하기 어려워 보인다. 그럼에도 불구하고 드라이브 이상의 것을 사용해야 하는 이유가 무엇일까?
내가 알고 있던 평행우주는 디씨와 마블 등 코믹스 세계관이었다. 여러 작가들이 수많은 캐릭터들로 몇십 년간 스토리를 이어오면서, 다른 작가의 설정을 바꾸어 새로운 이야기를 만들어내고 싶은 경우도 있을 것이다. 하지만 이미 등장한 설정을 바꾸면 '설정 상의 오류'가 될 위험이 있다.
그래서 해결책으로 내놓은 것이 평행우주(Multi-Universe)와 연속성(Continuity) 개념이다. '지구-51'에서 일어나는 일은 다른 우주의 '지구-8'에는 영향을 주지 않는다. 물론 차원 간의 연결고리가 될 수 있는 능력을 가진 캐릭터가 차원을 연결시켜 차원 간의 충돌이 일어나기도 한다. 정확히 매칭 되지는 않지만 좋은 비유라 생각된다.
출처 : publiclab.org
Git 개념 요약
마찬가지로 브랜치라는 개념으로 파일의 버전 컨트롤을 하는 것이다. 브랜치는 각 작업자들에게로 갈라지고 master로 다시 만난다. master 브랜치에서 여러 분산 작업이 가능하고 다시 master 브랜치로의 병합이 가능하다는 의미다. 물론 '버전 관리' 툴인만큼 원하는 지점(버전)으로의 롤백이 가능하다는 것이 가능하다.
브랜치의 개념을 이해했다면 아래 네 가지 기능만으로도 충분하다고 생각한다.
Commit: 수정된 버전 정보의 기록. 여기까지는 로컬에서의 기록이다.
Push: 내 로컬 저장소에서 수정된 내역을 Git 서버 저장소로 보낸다.(master 브랜치로의 푸시가 아니다)
Pull: 내 로컬 저장소에 서버에 저장된 버전의 클론을 만든다. 클라우드 서비스처럼 특정 폴더를 지정해둘 수 있다. 브랜치별 동기화가 가능하다.
Merge: 분산된 버전을 master로 병합하는 작업. 마스터 브랜치는 한 명이 관리하며 merge하는 것이 좋다. 이 과정에서 팀원 간 검토와 리뷰가 행해질 수 있다.
수정 내역의 기록은 커밋 혹은 푸시할 때의 코멘트로 이루어진다. 태그는 정하기 나름이며 중요한 것은 Add/ edit/ Update/ Fix 등 그 팀의 서로가 알아볼 수 있는 규칙을 만들면 된다.
함께 쓰고 있는 서비스들
Sourcetree
터미널에 직접 명령어를 입력하며 더 전문적인 기능을 활용할 수 있지만 훌륭한 그래픽 인터페이스를 가진 도구의 도움을 받을 수 있다. 여러 가지 툴이 있겠지만 우리는 많은 기업들이 사용하고 있는 Sourcetree를 사용한다. 동작 방식이 이해하기 쉽게 시각화되어 있다.
Bitbucket
Sourcetree를 만든 Atlassian사에서 만들었다. 오픈 소스의 팀 협업을 위한 Github과 비슷한 서비스. Git을 원격 관리하는데 Github보다 더 프라이빗한 성격.
Slack
버전 관리 툴은 아니지만 Integration의 대명사 슬랙. 한 채널을 만들어 연동해두면 어떤 이슈들이 발생했고 관리되고 있는지 한눈에 보기 편하다.
파일의 플로우별 분리
모든 제품들을 순차적으로 리뉴얼하면서 제품 하나당 스케치 파일 하나인 적이 있었다. 그러나 Git을 도입하면서 각 제품을 플로우별로 나누는 작업을 하고 있다. 다음과 같은 세 가지 이유가 있다.
용량 문제 : 스케치 파일 하나가 100MB를 넘어가면 Github으로 관리하는 의미가 없다. 패키지를 통째로 로드하는 시간부터 오래 걸린다.
충돌 문제 : 한 파일을 동시에 작업할 때 생길 충돌의 위험을 피하기 위함. (가장 치명적인 문제 : 스케치 파일은 merge시 충돌 문제가 아직 해결되지 않은 상태라고 한다. 한 파일을 동시 작업을 못 한다는 의미)
업무 방식 : 태스크 단위 업무 방식에서 유연하게 대응할 수 있도록 하기 위함.
그러나 플로우가 병합되고 겹치는 스크린은 어디에 넣을지에 대한 합의라는 작은 어려움이 있다. 물론 파일이 정리된다는 것 자체가 긍정적이다.
업무방식의 변화
아카이브/ 버전 관리/ 롤백 외에도 긍정적인 변화가 있다.
산발적인 작업 혹은 일회성 솔루션을 내는 업무 방식에서 벗어날 수 있었다. 사실 나는 여러 파일들을 켜놓고 왔다 갔다 하며 작업을 하는 스타일이었다. 하지만 Git 도입 후 시스템 상 매번 커밋/푸시가 기록되는 것에 부담감이 있어서 그런지 태스크 단위의 업무 방식에서 한 가지 태스크에 집중할 수 있게 된 것 같다.
그리고 당장 효과를 보기는 어렵겠지만 후에 다른 디자이너가 온보딩했을 때도 도움이 되지 않을까 생각해본다.
리뷰
- 이번 글에서는 툴의 도입과 디자이너의 업무 방식의 변화를 기록했다.
- 분산 버전 관리/ 롤백 등의 이점은 충분히 누리고 있다. 개인적인 업무 방식의 변화도 긍정적이다.
- 하지만 개발자/디자이너만 쓰고 있기 때문에 어쩐지 업무 로그가 한번 더 분산된 느낌도 든다.
- 아직은 '조직 문화'라기보다는 팀의 '업무 방식'인 것 같다.
Git을 활용해 디자인 협업 환경을 구축하는데 좋은 팁이 있다면 댓글로 알려주시면 감사하겠습니다 :)
내용 추가 : 글을 발행하자마자 Abstract가 출시되었습니다. 지금은 Git의 사용이 보다 일반화되었고 저도 개인적으로 Github과 Abstract를 쓰고 있습니다. 확실히 이 필드는 변화하는 속도가 빠르다는 것을 느끼네요. 어떤 방법이 더 유용할지는 팀의 규모, 회사의 상황, 조건 등에 따라 달라지겠죠 :)
