스케치43 포맷으로 Git 버전관리를 시도해보다.
https://brunch.co.kr/@kimdal/1
스케치의 43 버전 업데이트 이후, 스케치 파일의 포맷이 변화해 Git을 통한 버전관리가 가능해질 수도 있게 되었다는 내용을 지난 글을 통해 말씀드렸습니다.
회사일이 바빴고ㅠ, 생각보다 허들도 많았기에. 한 달이 훌쩍 넘어서야 다음 글을 써봅니다..
(그 사이 또 다음 메이저 업데이트까지 나와버렸네요..)
오늘 글에서 크게 다루려는 주제는, "압축 해제한 스케치 폴더를 Git으로 관리하는 데에 어떤 문제들이 있는가?"입니다.
먼저, 문제들을 이야기하기 전에, 스케치 폴더를 GitHub에 적용하는 과정을 하나씩 말씀드려 보겠습니다.
어떤 문제들이 있는지 설명을 돕기 위해, 시행착오의 과정이 포함되어있기 때문에 따라 해 보실 필요는 없을 것 같습니다..
압축 해제한 스케치를
GitHub에서 버전관리 시도하기.
1. 스케치 파일을 압축 풀기 한다.
먼저 당연하게도, 스케치 파일의 압축을 풀어줍니다. (아래 GIF를 참고해주세야)
압축이 풀려있는 스케치 폴더를 다시 스케치 파일로 압축시키는 방법은 아래의 GIF를 참고해주세요.
압축을 풀 때와는 달리, 폴더가 아니라 내부 파일들을 바로 압축해야 합니다..
2. json파일을 formatting 한다.
이게 뭔 소린가 싶으시겠지만...
git에 대한 설명을 잠깐 드리면, git에서 코드를 버전 관리를 할 때에는 변경사항을 코드 한 줄의 단위로 파악합니다.
예로 어떤 코드 중에서, 34번째 줄의 코드의 일부가 변경되었을 때.
'34번째 줄의 10번째 글자가 바뀌었다.'라고 저장하는 게 아니라, '34번째 줄의 내용이 통째로 A에서 B로 바뀌었다'라고 인식합니다.
그런데 문제는, 압축을 푼 스케치의 json파일이 엄청 긴 1줄짜리 코드라는 겁니다;... 때문에 특정 영역만 변경하더래도, 파일 하나가 통째로 바뀌었다고 인식하는 문제가 발생합니다.
자동줄바꿈이 있어서 여러줄 처럼 보이지만, 한줄짜리 코드다.포맷팅을 한다는 것은 바로 위와 같은 json파일을 아래처럼 바꿔주는 겁니다.
보기 좋게 정보의 구조대로 줄바꿈이 된다.포맷팅을 하는 방법은 여러 가지가 있겠지만, 구글에 json formatter라고 치면 많이 많이 나옵니다..
저는 우선 https://jsonformatter.curiousconcept.com 요 사이트에서 하나하나 올려서 포맷팅을 해봤습니다.
3. 깃헙에 저장소 파고 SourceTree 연결하기
이 부분은 이 글에서 다루기에는 잘 설명된 글이 너무 많습니다. (귀찮은 건 아닙니다.)
또한 깃에 대한 이해가 필요하기 때문에, 설명을 하기 시작하면 너무 길어질 것 같아, 몇 가지 링크를 첨부하고 넘어가겠습니다..
아무튼 저는 SourceTree라는 Git을 GUI 환경에서 편하게 사용할 수 있게 해 주는 프로그램을 이용해 진행했습니다.
http://hackersstudy.tistory.com/41
이런 방식으로 깃으로 스케치 파일 관리를 시작하실 수 있습니다.
하지만 척 봐도 실무에 도입하기에는 아직은 몇 가지 문제들이 있습니다.
압축 해제한 스케치를
Git으로 관리하는 것의 문제점.
1. 스케치 파일을 압축 풀고, 다시 압축하는 과정이 너무 복잡하다.
변경사항을 새로 올릴 때마다 스케치 파일의 압축을 풀고, json파일을 포맷팅 해야 합니다.
새로운 변동사항을 내려받을 때도, 압축을 푼 상태에서 최신 변경내역을 적용하고, 다시 압축을 해서 실 사용할 수 있는 스케치 파일로 만들어줘야 하죠. 전혀 직관적이지도 못하고, 복잡하고, 노가다성이 짙은 작업입니다. 해당 작업에 대한 자동화 없이는 실질적인 도입이 불가능할 것 같습니다.
2. 동시 협업 시 충돌을 피하기 힘들다.
압축을 푼 스케치 폴더의 구조는 아래와 같습니다.
- user.json
- meta.json
- document.json
- pages
- PAGE_ID.json
-...
- previews
- preview.png
각 파일의 이름대로 각자의 정보가 들어있는데, 문제가 되는 것은 user.json파일과 preview.png입니다.
user.json은 각 페이지별 사용자가 마지막으로 보고 있던 위치 값과 zoom값의 정보를 가지고 있고, preview.png는 사용자가 마지막으로 보고 있던 페이지를 저장해둔 이미지 파일입니다.
때문에 두 파일은 별도의 브랜치에서 작업 후 통합을 시도했을 때, 100% 충돌이 발생할 수밖에 없습니다.
user.json파일은 아예 없으면 스케치 파일이 열리지도 않기 때문에 꼭 필요하고, preview.png는 가시적인 변경내역 기록을 위해 제외시킬 수 없습니다.
그래도 다행인 것은 두 파일 모두 스케치 작업 내용에는 직접적인 영향을 주지 않기 때문에, 적당히 아무 변경사항으로 적용을 하고 열어도 파일은 잘 열립니다.
문제는 다음 항목입니다.
여러 번의 실험 진행과 json파일을 살펴본 결과, 동시 협업 시 user.json, preview.png가 아닌 파일에서 충돌이 발생하는 경우는 다음과 같습니다.
같은 레이어를 수정했을 때
같은 아트보드에 새로운 레이어를 동시에 추가했을 때
같은 페이지에서 새로운 아트보드를 동시에 추가했을 때
같은 페이지에서 아트보드에 포함되지 않는 레이어를 추가했을 때
새로운 페이지를 동시에 추가했을 때
.. 그 외 스타일, 심볼 등에서도 같은 항목을 수정하거나, 새로운 항목을 동시에 추가했을 때 충돌이 발생합니다.
같은 항목을 수정하는 것에 대한 충돌은 당연하지만, 새로운 항목을 추가하면서 생기는 충돌은 많이 아쉽습니다. 아무튼 완전한 의미의 동시 협업은 힘들것으로 보이며, 결국 동시에 작업한 내용에 대해서는, 두 파일을 열어 비교하며 손으로 직접 통합시켜주는 작업이 필요할 것으로 보입니다.
결론은, 아직은 넘어야 할 산이 몇 가지 있으며, 해결을 위해서는 버전 관리를 도와주는 별도의 프로그램이 필요합니다.
그래도 나쁘지 않다 (라고 믿는다...)
여러 문제점들이 남아있지만, 개인적으로는 최소한 1번 항목의 문제만 잘 해결되면 충분히 가치 있는 수준의 버전 관리를 해낼 수 있을 거라고 믿습니다.. 적어도 기존의 방식들 보다는 이점이 크지 않을까요?
최소한의 리소스로 변경사항을 저장하고, 빠르게 버전을 오갈 수 있으며, 프로젝트의 변경사항에 대해 가시적으로 기록되고 살펴볼 수 있습니다. 적절한 수준의 동시 수정은 충돌 없이도 합쳐질 수 있고, 연속적인 협업 또는 개인 작업에서는 무리 없이 버전 관리가 가능해질 겁니다...
스케치 파일의 압축 해제와 json 포맷팅의 자동화만 해결되면 말 입죠..
그래서 만들어 봤습니다.
여차저차 저차여차 해서, (자세한 건 생략합니다...)
electron 이라는 node js기반의 앱 제작 라이브러리를 이용해 아래와 같은 앱을 만들었습니다.
스케치 파일을 끌어다 넣으면 압축이 풀린 스케치 폴더로 바꾼 후 json파일을 포맷팅 해주고,
스케치 폴더를 넣으면 스케치 파일로 바꿔 주는 간단한 앱입니다.
평소에는 스케치 파일로 만들어 작업을 진행하고, 변경사항을 커밋하거나, 변경사항을 내려받을 때는 앱을 이용해 압축을 풀어 적용하고, 다시 압축해 스케치 파일로 사용할 수 있습니다.
주의해야 할 점은, 스케치 파일이 된 후 수정되고 다시 압축을 푼 폴더에는, 스케치와 관련 없는 파일들이 모두 삭제됩니다. 때문에, 저장소를 만들 때 스케치 폴더를 root로 하시면 git과 관련된 숨겨진 파일들이 지워질 수 있으니, root 폴더 내부에 스케치 폴더를 두셔야 합니다.
얼마나 이 앱이 깃을 이용한 버전관리에 큰 도움이 되는지는 조금 더 사용해 봐야겠지만, 최소한의 github 프로세스 적용에는 큰 도움이 되리라 믿습니다.
팀 내부에서 우선적으로 해당 앱을 통한 도입을 진행해보고, 또 다른 이슈가 있다면 글을 통해 알려드릴 수 있도록 하겠습니다.
해당 앱은 아래 링크에서 다운로드하실 수 있습니다.
근본 없이 되는대로 만든 거라 많이 부족할 수 있습니다. 감안해주셔요..;ㅠ
https://drive.google.com/open?id=0ByP7MgS6OEoMMDBncDloSjlZYnM
읽어주셔서 감사합니다.
