브랜칭을 만든 방법 (새 탭에서 열림)
Figma는 대규모 협업에서 실험적 변경과 승인된 디자인을 분리하기 위해 브랜칭을 구축했다. 메인 파일은 단일 진실 공급원으로 유지하고, 브랜치에서는 기존 디자인을 훼손하지 않으면서 아이디어를 탐색·검토·수정할 수 있도록 한 것이다. Figma는 소프트웨어 개발의 브랜치 개념을 그대로 복제하기보다, 클라우드 기반 멀티플레이어 협업에 맞춰 단순성과 일관성을 우선했다. ## 대규모 협업에서 자유와 구조의 균형 - 실시간 협업은 모든 사람이 같은 파일에서 작업할 수 있다는 장점이 있다. - 그러나 팀 규모가 커지면 다음과 같은 문제가 발생한다. - 승인되지 않은 변경 사항이 코드에 반영됨 - 작업 내용이 다른 사람에 의해 덮어써짐 - 진행 중인 작업(WIP)과 실제 배포 가능한 디자인을 구분하기 어려움 - 브랜치는 메인 파일을 직접 변경하지 않고 새로운 아이디어를 시도할 수 있는 탐색 공간이다. - 디자인 라이브러리에 기여하거나, 이해관계자에게 작업물을 미리 보여주거나, 실험적인 반복 작업을 진행할 때 특히 유용하다. - 충분히 검토·승인된 변경만 메인 파일에 반영함으로써 메인 파일의 무결성을 유지한다. ## 소프트웨어 브랜칭과 Figma의 차이 - 소프트웨어 개발의 브랜치는 일반적으로 변경 사항이 개발자의 로컬 컴퓨터에 저장되는 구조를 전제로 한다. - 반면 Figma 파일은 클라우드에 저장되며, 여러 사용자가 동시에 같은 파일에 접속해 변경한다. - 따라서 Figma는 다음과 같은 설계 문제를 검토해야 했다. - 메인 파일에서 여러 사용자의 동시 편집을 계속 허용할 것인가 - 브랜치에서도 여러 사람이 동시에 작업할 수 있게 할 것인가 - 기존 멀티플레이어 협업 경험에 복잡성을 얼마나 추가할 것인가 - 핵심 과제는 전통적인 버전 관리 방식을 그대로 적용하지 않고, 온라인 협업 환경에 맞는 브랜칭 모델을 만드는 것이었다. ## 단순성과 일관성을 우선한 설계 - Figma는 브랜칭과 멀티플레이어 편집을 하나의 일관된 버전 관리 방식으로 이해할 수 있도록 설계했다. - 메인 파일은 기존처럼 여러 사람이 동시에 편집할 수 있다. - 브랜치도 일반적인 Figma 파일과 동일한 방식으로 작동한다. - 편집자와 뷰어의 접근 권한 및 권한 관리 방식은 변경하지 않았다. - 사용자의 데이터가 어떤 상황에서도 안전하게 보존되도록 데이터 무결성을 우선했다. - 기능을 의도적으로 단순하게 유지하기 위해 브랜치에서 다시 브랜치를 만드는 기능은 제공하지 않았다. - 이는 기능을 많이 추가하기보다, 디자이너가 별도의 복잡한 개념을 학습하지 않고 사용할 수 있게 하려는 선택이다. ## 병합 과정에서 고려한 예외 상황 - 병합의 가장 어려운 문제는 단순히 충돌을 해결하는 것만이 아니다. - 실제 구현에서는 다음과 같은 상황도 처리해야 했다. - 사용자가 병합 내용을 검토하는 동안 원본 파일이 변경되는 경우 - 병합 작업 도중 네트워크 연결이 끊기는 경우 - 병합이 완료되기 전에 다른 사용자의 변경 사항이 추가되는 경우 - 따라서 병합 기능은 충돌 해결 알고리즘뿐 아니라, 검토 중인 상태의 일관성, 연결 손실, 동시 변경에도 사용자의 데이터가 안전하게 유지되도록 설계되어야 했다. - 제공된 글은 이러한 병합 문제를 설명하던 중 문장이 중단되어 있어, 구체적인 해결 방식 전체는 확인할 수 없다. 브랜칭은 메인 파일을 무분별한 실험의 공간으로 사용하는 대신, 승인된 결과와 진행 중인 작업을 분리하고 싶은 팀에 적합하다. 특히 디자인 시스템이나 제품 디자인을 여러 사람이 함께 관리한다면, 메인 파일은 안정적인 기준점으로 유지하고 브랜치에서 탐색·리뷰·협업한 뒤 승인된 변경만 병합하는 운영 방식을 추천할 수 있다.