요약

  • 연결된 폴더는 양측의 유료 좌석으로 협업하게 해 주지만, 연결을 끊으면 원본은 호스트에 남고 외부 팀은 폴더 파일에 접근할 수 없게 된다.
  • 폴더 복사본에는 댓글, 버전 이력, 브랜치가 따라가지 않는다. 같은 화면을 받아도 설계의 배경까지 넘겨받는 것은 별개다.
  • 라이브러리를 남겨 두고 파일만 이전하면 업데이트가 끊긴다. 공용 라이브러리를 함께 옮기면 원래 팀에 남은 파일이 업데이트를 잃는다.

디자인 납품에서 가장 곤란한 질문은 종종 마지막 회의가 끝난 뒤 나온다. 새 담당자가 버튼 하나를 바꾸려는데, 그 버튼의 원본은 어디에 있는가. 파일은 받았고 화면도 열리는데, 앞으로 고치는 방법은 아직 인수하지 못한 상황이다.

가상의 고객사와 디자인 업체를 생각해 보자. 두 회사는 Figma에서 함께 시안을 검토하고 각자의 좌석 비용을 냈다. 계약이 끝나자 고객사는 다른 팀에 유지보수를 맡기려 한다. 그때 중요한 것은 누가 회의에서 더 많이 발언했는지가 아니라, 누가 연결된 폴더의 호스트였는지다.

호스트는 폴더를 만들고 상대에게 연결을 요청한 쪽이다. 협업이 대등하게 느껴졌더라도 제품 안의 권한은 그 출발점을 기억한다.

나가는 버튼은 둘, 남는 원본은 하나

Figma의 연결된 폴더 안내에 따르면 양쪽 모두 유료 요금제를 사용하고 관리자가 연결을 승인해야 한다. 파일을 편집하려면 자기 쪽 좌석뿐 아니라 해당 파일의 편집 권한도 있어야 한다. 좌석과 파일 권한은 따로 움직인다.

호스트는 보안과 개인정보 설정, 제공 기능, 외부 팀이 사용할 라이브러리를 통제한다. 양쪽 모두 파일을 만들거나 안으로 가져올 수 있지만, 폴더 밖으로 파일을 빼낼 수 있는 사람은 호스트 쪽 사람이다.

연결을 해제하는 권한은 양쪽 관리자에게 있다. 그러나 해제 뒤 폴더는 호스트에 남고 외부 팀은 안의 모든 파일에 대한 접근을 잃는다. 호스트는 그대로 둘 수도, 복사본을 보내 줄 수도 있으며 나중에 폴더를 이전할 수도 있다.

이것이 퇴장권과 반출권의 차이다. 둘 다 관계를 끝낼 수 있지만, 끝난 뒤 원본 앞에 서 있는 쪽은 하나다. 각자 비용을 냈다는 사실은 그 차이를 없애 주지 않는다.

따라서 프로젝트를 시작할 때 호스트를 정하는 일은 사소한 준비 작업이 아니다. 고객 내부팀이 장기적으로 관리할 예정인지, 외주사가 계속 관리 서비스를 제공할 예정인지에 따라 맞는 배치가 달라진다. 아무나 먼저 폴더를 만들고 마지막 날에 결정하자는 방식은 결말을 제품의 기본 구조에 맡기는 셈이다.

화면을 넘겨도 설명은 남을 수 있다

Figma의 폴더·팀 이전 문서는 원본 이전과 복사본 전송을 구분한다. 복사본을 보내면 댓글과 버전 이력, 브랜치는 원본 쪽에 남는다.

다음 팀이 필요한 것은 현재의 예쁜 화면만이 아니다. 왜 그 배치를 버렸는지, 어떤 예외 때문에 색상을 달리했는지, 어느 문구를 고객이 최종 선택했는지도 중요하다. 그 설명이 댓글과 이력에 있었다면, 복사본만 받은 팀은 이미 끝난 논의를 다시 조사할 수 있다. 납품한 파일 수는 같아도 인수 비용은 달라진다.

폴더 원본을 받을 수 있는 요금제는 Professional, Organization, Enterprise다. 팀 전체를 받으려면 Organization 또는 Enterprise가 필요하다. 이전 뒤 파일과 프로토타입의 기존 링크는 유지되지만 폴더와 팀 링크는 새로 생긴다. 복사본 전달을 이런 이전과 같은 것으로 적어 놓으면, 서로 다른 결과를 같은 납품 항목으로 파는 꼴이다.

고객 협업 안내에 있는 로컬 저장 후 다른 계정으로 가져오기 역시 별도 경로다. 이 경우 원래 팀 라이브러리에서 오던 업데이트는 이어지지 않는다. 다운로드 완료 표시가 유지보수 인수증까지 대신해 주지는 않는다.

공용 부품 창고를 누구에게 넘길 것인가

Figma의 라이브러리는 컴포넌트, 스타일, 변수를 하나의 원본 파일에 모아 다른 파일에서도 쓰게 한다. 디자인 업체에는 반복 작업을 줄이는 자산이다. 여러 프로젝트가 같은 버튼과 색상 체계를 이용하면, 공통 수정도 한곳에서 시작할 수 있다.

그 편리함이 이별할 때는 경계 문제가 된다. 이전 대상에 라이브러리가 빠져 있으면 컴포넌트는 마지막 상태로 남고 이후 업데이트를 받지 않는다. 반대로 게시된 라이브러리 파일 자체를 이전하면, 보내는 팀이나 조직에 남은 파일들이 더 이상 그 라이브러리의 업데이트를 받지 못한다.

한 고객의 인수인계를 위해 다른 고객들도 쓰는 부품 창고를 통째로 옮길 수는 없다. 그렇다고 모든 원본을 외주사에 둔 채 화면만 넘기면서 완전한 독립 유지보수를 기대하게 해서도 곤란하다. 고객 전용 자산과 업체의 공통 자산, 앞으로 제공할 관리 서비스의 범위를 나눠야 한다.

연결된 폴더에서 호스트가 라이브러리 사용을 허용하면 구성원이 받는 것은 그 원본 파일에 대한 보기 권한이다. 부품을 가져다 쓸 수 있는 능력과 부품의 원형을 고칠 수 있는 능력은 다르다. 같은 작업실에 앉았다고 공구함의 열쇠까지 하나씩 받은 것은 아니다.

다음 변경이 도착하는지 확인해야 한다

Figma의 라이브러리 교체 기능은 파일을 다른 게시된 라이브러리의 자산으로 연결할 수 있다. 이때 이름을 기준으로 대응 항목을 찾는다. 일치하는 항목이 없으면 교체되지 않고 기존 라이브러리에 남는다. 모양이 비슷하거나 이름을 새로 붙였다는 이유로 자동 대응되지는 않는다.

그래서 이관 결과에는 일치한 항목과 남은 항목이 함께 있어야 한다. 같은 이름으로 잡힌 항목도 용도가 맞는지 확인해야 한다. 일부만 새 라이브러리로 옮겨진 파일은 화면상으로 멀쩡해 보이면서 서로 다른 유지보수 경로를 품을 수 있다.

마지막 검증은 실제 업데이트다. 업데이트 검토와 수락은 편집 권한이 있는 사용자가 수행한다. 합의한 원본에서 대표 컴포넌트 하나를 수정해 게시하고, 인수팀의 파일에서 그 변경을 검토해 받아 보는 것이다. 파일이 열리는 것보다 훨씬 많은 것을 확인할 수 있다.

특정 인수인계의 비용을 계산하려면 실제 호스트, 자산 의존 관계, 합의한 납품 범위가 필요하다. 공개된 제품 규칙이 이미 보여 주는 것은 명확하다. 제대로 받은 디자인은 내일도 고칠 수 있어야 한다. 좌석 청구서는 따로 와도, 그 능력의 배분은 함께 정해야 한다.