brunch

You can make anything
by writing

C.S.Lewis

by designsystemguy Apr 12. 2023

피그마에서 브랜치 잘 사용하기

피그마는 디자이너에게 뿐만아니라 프로덕트를 만드는 모든 구성원에게 정말 잘 만들어진 툴입니다. ‘협업’이라는 단어 하나만 놓고 보아도 피그마가 팀에 기여할 수 있는 것들이 아주 많은데요. 오늘은 피그마가 제공하는 기능 중에서도 ‘브랜치’ 기능을 미치게 잘 활용하는 방법에 대해 이야기해보려고 합니다.

이 포스트는 개발 워크플로우, 그리고 스프린트에 대한 이해가 뒷받침되어야 깊이 이해하실 수 있을 것 같아요. 생소하고, 조금은 어려울 수도 있지만 도움이 되었으면 좋겠습니다. 한가지 더, 제가 스타트업에 몸담고 있기 때문에 스타트업 기준 워크플로우에 기반해서 경험을 공유드리는 것이니 이것 또한 참고부탁드려요 ㅎㅎ.

브랜치 튜토리얼은 인터넷에서 찾아보면 많이 있어서 여기서 다루지는 않을게요. 궁금하시다면 맨아래 참고링크를 확인해주세요. 여기서는 실무에서 활용하는 방법을 중점적으로 다루겠습니다.

브랜치란?

브랜치(Branch)는 나뭇가지라는 뜻이에요. 나무를 이입해서 생각해봅시다. 나무는 큰 줄기가 있고, 줄기로부터 가지가 이리저리 뻗어나와있죠? 말씀드린 이미지를 상상하며 프로덕트에 대입하면 돼요. 실제 라이브 중인 서버를 ‘마스터’라고 칭했을 때, 앞으로 출시할 신규 기능과 개선될 기능들은 모두 마스터로부터 뻗어나온 ‘브랜치’에서 개발되는 구조라고 보시면 돼요. 개발이 완료된 브랜치는 마스터로 병합돼서 실서버에 보여져요.

보시다시피 브랜치는 프로그래밍에서부터 시작된 개념이에요. 디자이너분들 깃허브(Github), 깃(Git)이라는 용어는 회사다니시는 분이라면 많이들 들어보셨을텐데, 깃허브라는 방대한 클라우드 저장소에 회사의 프로덕트(또는 프로젝트)가 저장되어있고, 그 프로덕트를 개발할 때는 항상 메인 줄기를 기준으로 가지를 쳐서 개발하는 구조로 일을 합니다.

왜 가지를 쳐서 개발을 할까요?

브랜치를 생성해서 개발하는 이유는 아래와 같아요.

1. 마스터를 건드리지 않아 유저가 안전하게 프로덕트를 누릴 수 있다.

마스터에서 작업한다고 생각해보세요. 실제 돌아가는 프로덕트가 뭔가 계속 꽁냥꽁냥 바뀌고, 버그도 계속 터져서 프로덕트를 이용할 수 없을 정도로 엉망진창일거에요. 브랜치를 사용하면 모든 변경사항을 테스트로 검증하고 난 뒤 병합하기 때문에 안정성이 보장돼요.

2. 개별 브랜치에서 작업함으로써 작업 효율성을 끌어올릴 수 있다.

브랜치를 사용하면 여러 개발자들이 동시에 개발할 수 있어요. 마스터로부터 여러 개발자가 각자의 구역을 나눠서 개발한 뒤 병합함으로써 개발과정이 가속화될 수 있어요.

3. 버전 관리에 용이하다.

브랜치를 사용하면, 이전 버전과 병합후 현재 버전을 비교하고, 변경사항을 추적하기에 용이합니다. 떄로는 문제해결을 위해 이전 버전으로 되돌릴 수도 있습니다.

4. 여러 실험을 할 수 있다.

새로운 아이디어를 브랜치로 생성해서 자기가 원하는대로 만들어보고 폐기할 수도 있고, 마스터로부터 서로 다른 안을 만들어보고 선택된 안만 병합시킬 수도 있어요.

브랜치 전략: Git Flow

위에서 설명한 브랜치에 대해 피그마에서는 어떻게 사용할지를 알아보기 전에 개발자들은 어떻게 브랜치를 생성하고 관리하는지에 대해 이해할 필요가 있습니다. 먼저 길을 닦아놓은 사람들의 산물을 보면 더 쉽게갈 수 있지 않겠어요? ㅎㅎ.

개발자들은 버전 관리라는 주제에 있어 SVN, Git까지 이어져 내려오는 나름 긴 역사동안 ‘어떻게하면 깃을 효과적으로 사용할 수 있을까?’라는 고민을 꾸준히 해왔던 것 같아요. 그렇게 Git Flow라는 방식이 나타나게 되었고요, 지금까지도 저희 회사를 포함한 많은 회사에서 이 방식을 채택하고있는 것 같습니다.

Git Flow 방식은 브랜치를 아래와 같이 나누고 있어요.

master: 제품으로 출시(배포)되는 브랜치

develop: 다음 버전이 개발될 브랜치

feature: 단위별로 기능을 개발하는 브랜치 (완료되면 develop 브랜치로 병합)

release: 배포 전 (master와 병합 전) QA를 통해 버그를 찾아내기 위한 브랜치

hotfixes: master브랜치에서 발생한 버그를 긴급하게 수정하는 브랜치

위 그림처럼 마스터는 냅두고 각자 브랜치에서 꽁냥꽁냥 만들고 팀 리뷰후에 한 뭉텅이로 병합되는 구조인 것이죠.

스프린트

브랜치를 잘 활용하기 위해 필수로 알아야할 두번째 개념은 스프린트예요. 스프린트에 대해 생소하신 분들을 위해 짧게만 말씀드리자면 단거리 달리기(개발)를 반복적으로 하는 행위라고 보시면 될 것 같아요. 굳이 이 글하고는 크게 상관은 없으니 여기서는 깊게는 다루지는 않을게요. 원하신다면 나중에 이와 관련된 글도 올리겠습니다 ㅎㅎ.

저희 팀은 스프린트를 수차례 진행해오고 있는데요. 대개 2주 기간 내에서 완료할 수 있는 목표를 설정하고 개발합니다. 설정한 목표에 해당하는 유저스토리가 존재하고, 그 유저스토리를 배포까지 하는 것을 한 사이클로 보았을 때, 위에서 말씀드린 개발 실무에 기반해서 생각해보자면 아래와 같은 순서로 이루어집니다.

Develop 브랜치로부터 유저스토리에 따른 새로운 개인 브랜치 생성

개발 작업

완료된 작업 Pull Request (*Pull Request는 내 작업 병합시켜주세요~라는 의미입니다.)

코드 리뷰

Develop 브랜치에 Merge

QA 진행

QA 반영을 위한 브랜치 생성

피드백 반영 후 PR & Merge

실서버 배포

주의를 기울여야할 포인트는 유저스토리에 기반한 브랜치 생성과 스프린트 기간 내 머지 및 배포입니다.

피그마에서 브랜치 활용

스크럼팀은 ‘유저스토리’를 매개로 PM/디자이너/개발자가 동기화 될 수 있습니다. 모두가 동의하는 유저스토리 하에 개발에서 브랜치를 생성했듯, 디자인팀에서도 피그마를 통해 동일한 스토리에 대한 브랜치를 생성하여 주어진 기간 안에 작업하고 소통합니다.

이 때, 피그마의 페이지도 굉장히 중요한데요. ‘Draft’와 ‘Ready to dev’페이지 둘로 나누어 Draft 페이지에서는 개인이 자유롭게 만들어볼 수 있는 공간으로 활용해야하며, 시안이 확정되고 개발에 정리된 채로 전달되기 위한 일종의 쇼케이스가 되는 공간은 Ready to dev 페이지에 존재해야 합니다.

개발 워크플로우로 대입해서 생각하면 Ready to dev 페이지는 Develop 브랜치가 되고 Draft 페이지는 Develop 브랜치의 서브 브랜치 즉, 개인 브랜치가 됩니다. 디자이너는 Draft 페이지에서 자신이 생각하는 여러 안을 작업해보고, 개발팀처럼 피드백 과정을 거쳐 Ready to dev 페이지에 핸드오프가 가능한 수준으로 만들어 놓게 되는 것이죠.

피그마는 개발팀의 Pull Request 후에 코드리뷰를 하는 것처럼, 브랜치를 머지하기 전에 리뷰어를 추가할 수 있습니다. 추가된 리뷰어의 피드백에 따라 Approve되거나, Reject(Suggest to change)되는데요. 피그마 브랜치를 피그마의 의도에 맞게 쓰기 위해서는 이 부분도 쉽게 지나치면 안됩니다.

저는 이 기능을 적극 활용하여 피드백 내용은 코멘트를 달아놓아 정기 디자인 리뷰 세션을 갖고 리뷰어의 동의에 따라 Approve하는 것을 지향하고 있습니다. Approve된 브랜치는 핸드오프 완료로 취급하여 개발자가 확인하고 구현하는 과정으로 이어지고요.

핸드오프 후에 모든 개발까지 완료되면, QA를 진행하게 되는데요. 아직 실서버에 배포되기 전인 개발서버에서 QA를 진행하고, QA내용은 피그마와 지라를 활용하여 남기게됩니다.

QA까지 모두 마무리되면 배포를 하게되는데요. 실서버 배포와 동시에 디자인도 마스터에 머지를 하게되면, 개발측 Master 브랜치(사용자가 보고있는 실서버)와 피그마의 Master 파일은 항상 동기화되어있는 상태를 유지할 수 있게 됩니다. 그리고 나서 다음 스프린트를 준비하면 되겠죠?

정말 중요한 코멘트의 역할

위 과정속에서 코멘트는 정말 중요한 역할을 하게되는데요. Phase에 따라 코멘트를 통해 전달/해결하고자 하는 내용, 그리고 대상자가 달라지게 됩니다. 이를 통해 더욱 긴밀한 작업이 가능해집니다.

Phase1 : Design Review

디자이너 간 소통

디자이너 간 리뷰를 진행할 때에는 리뷰자와 리뷰어가 질답형태로 코멘트를 작성할 수 있는 Phase로 활용하며 해당 Phase가 마무리 된다면 모든 코멘트가 Resolve되어있어야 합니다.

Phase2 : Hand off

디자이너와 개발자 간 소통

Approve된 디자인은 작업자가 개발자의 작업 편의성을 위해 코멘트를 달아야 합니다. 코멘트는 Added/Modified/Deleted/추가 설명 네가지 정도로 나뉠 수 있고, 개발자 또한 궁금증이 생길 시 코멘트를 남길 수 있습니다.

Phase3 : QA

QA 진행자와 개발자 간 소통

개발서버와 피그마 디자인을 비교해보고 피그마에 코멘트로 수정이 필요한 부분을 달아놓을 수 있습니다. 이 때, 가장 이상적인건 수정 반영하고 개발자가 Resolve를 누르는 것까지 입니다.

정리

오늘은 피그마 브랜치에 대해 알아보았는데요. 이 글은 생각보다 작성하는데 시간이 오래걸렸네요. 쓰고나니 제가 발행한 글만으로는 이해가 어려우실 수도 있을 것 같다는 생각도 들지만, 최대한 쉽게 녹여내려고 노력했습니다. 만약 디테일하게 궁금하신 분이 있다면 언제든 연락주세요! 도움드릴 수 있도록 하겠습니다. 읽어주셔서 감사합니다~ 다음에도 재밌는 글로 찾아뵐게요!