스케치에서 피그마로 이사 프로젝트 1편 - 전반적인 프로세스 회고

첫 직장에서의 버전을 세번째 회사에서 만나다

 

늦었다고 생각할때가 늦.. 아니 빠르다는 말이 있듯이, 드디어 스케치에서 피그마로 교체하게 되었다!!

현재 회사에서 스케치+제플린 조합으로 작업을 하고 있는데, 스케치 버전도 내가 첫 디자이너로 취업할 당시의 버전이라..!! 피그마 오토레이아웃과 같은 기능도 없고 애니마 같은 플러그인도 현 버전에서 잘 지원해주지 않았다😂 UI를 만들고 안에 콘텐츠를 집어넣을때, 컨펌받고 수정하는데에만 반나절이라 스트레스를 너무 많이 받았다. 미쳐버려.. 모든 디자인 업무가 이미지로만 공유하는 프로세스로 스케치 사용에 이골이 날 때쯤 피그마로 옮기게 되었다.

주요 프로그램을 바꾼다는 것은 생각만해도 쉬운 일이 아닌데, 최근까지 피그마를 사용한 사람은 우리팀에 나까지 2명.. omg 이유는 즉슨 둘다 입사한지 얼마 안되어 이전까지 모두 피그마로 작업했기 때문이었다. 심지어 스케치에서 피그마로 이사를 해본 사람은 나뿐이어서 이 프로젝트를 담당.. 까지는 아니더라도 대부분 내가 고안한 프로세스대로 진행하게 되었다. 그래서 이번 프로젝트를 위해 정말 많은 인사이트를 뒤졌었는데, 혹시나 피그마를 잘 모르는 상태로 이 업무를 수행해야하는 상황이라면 이 글로 많이 얻어가실 수 있으면 좋겠다.

 

 

프로젝트는 아래의 단계로 진행되었다. 회사 사정상으로 단계마다 다른 작업이 추가된 것도 있지만 그건 제외하고 큰 골자는 이렇다. 이 프로젝트가 이렇게만 진행되었다면 더 빨리 끝날 수 있었을지도 모른다.^^

1. 마스터 파일 만들기
2. 스케치 파일을 피그마로 임포트하기
3. 라이브러리 파일과 최신파일 연결하기
4. 라이브러리 파일 디자인 구조 변경하기
5. 최신파일 디자인 구조 변경하기

 

이런 진행 흐름으로 시작된 이사 프로젝트의 프로세스를 소개합니다👏👏

(아마 보시는 대부분의 분들은 2~5번까지의 업무를 수행하시게 되지 않을까 싶다.)

1. 마스터 파일 만들기
이전부터 디자인 파일이 현행화되지 않았고.. 그로 인한 업무 소통 비용이 굉장히 높았다. 가령, 디자인 파일에서 a부분을 수정하는 프로젝트에서 a와 똑같은 쓰임인 b컴포넌트를 본따 수정했지만, 개발에서는 원래의 a가 실섭의 a와 달랐으며, 본따서 작업한 b컴포넌트는 실섭에 적용되지 않은 디자인이라던가...ㅎ(그럼 디자인 라이브러리에 있는 b는 무엇이냐 말인가..🤯) 처음에는 내가 히스토리 파악이 안되서 그런거구나 생각했지만, 알고보니 다른 분들도 이미 겪어온 문제였다. 개발팀에게 업무마다 실섭과 다른 시안으로 협업하는 것은 우리팀이 시안 관리가 제대로 되어있지 않은 부분을 보여주는 것이라고 생각했기 때문에 피그마로 넘어오면서 이 문제를 꼭 해결하고 싶었다.
그래서 실섭지향의 마스터 파일(현행화 파일)을 만들기로 결정했고, 해당 작업은 스케치에서 진행하기로 했다. 이 작업을 피그마에서 진행할 수도 있었겠지만, 한 화면당 프로젝트 파일이 너무 많아 모두 피그마에 임포트하기 어려웠다. 스케치에서 일단 적당히 마스터 파일을 만들어서 피그마로 옮기기로 했다.
혹시 마스터 파일이 없는 스타트업의 병아리님들..! 꼭 만드세요 제바류ㅠㅜ 이런건 학원에서도 안알려줬었어.. 마스터 파일 없으면 히스토리 파악이 전혀 안돼요!! 서비스가 확장할수록 꼭 필요한 프로세스더라구요! 어떻게 알았냐구요..? 알고싶지 않았어요..

 

• 해야할 업무
  ✅ 마스터 파일의 규칙 정하기 : 프로젝트 파일에는 굉장히 많은 리소스가 있는데 우리는 현행화를 위한 화면만 있으면 되기 때문에 그에 대한 규칙을 정한다. (업무를 수행하는 디자이너가 여럿이라면 이런 자잘해 보이는 규칙일지라도 꼭 정하고 시작하길 추천드려요.)
  ✅ 글로벌 심볼의 네이밍 수정⭐️⭐️ : 연결은 되어있지만 라이브러리와 로컬 파일에서의 이름이 다른 경우가 많다. 이 경우 이름을 라이브러리와 똑같이 수정해준다. (해당 문제는 스케치 버전 문제로 파악되며 이후 External Symbols 연결을 위해 필수로 수정해주세요.)
  *스케치의 심볼 = 피그마의 컴포넌트
  
  

2. 스케치 심볼 라이브러리를 피그마로 Import
심볼 라이브러리를 피그마에서도 디자인 라이브러리로 활용하기 위해 Import한다. 피그마에서 필요한 스타일 등록을 하면 그 스타일을 컴포넌트에도 적용해둔다. 

 

• 해야할 업무
  ✅ 스타일을 라이브러리에 등록
  ✅ 등록한 스타일을 컴포넌트에 적용
  
  

3. 마스터 파일을 다 만들었다면 이젠 피그마로 Import(드디어!!)
이제부터 실질적인 이사가 시작된다.. (한 2~3년 전 스케치를 피그마로 임포트할 때 심볼을 잘 못알아먹고 진짜 난리였던 기억이 있는뎈ㅋㅋㅋㅋㅋ 이번에 해보니 많이 발전된 것을 알 수 있었다. 글로벌 심볼로 사용한 것도 잘 캐치하고, 이미지로 안불러와지구!)

 

• 현재 상황
  ☑️ Import한 라이브러리와 마스터 파일은 당연하게도 각각의 파일이다. 전혀 연결성 없음!
  ☑️ 대신 심볼 라이브러리에서 가져다쓴 심볼은 마스터 파일의 레이어를 보면 'External Symbols'로 눈꺼짐 상태로 들어와있다.
  ☑️ 이 external symbols을 라이브러리의 컴포넌트와 연결하는 작업이 필요하다.
  
  

4. 디자인 라이브러리와 마스터 파일의 External Symbols를 연결한다. (해당 버전의 스케치라면 제일 중요한 단계 ⭐️⭐️⭐️⭐️⭐️)
이 작업시 연결되지 않는 컴포넌트들이 생각보다 많았다😭 플러그인을 사용하지 않고 피그마자체에서 진행하려고 하다보니 컴포넌트 이름이 매우 중요했는데, 마스터 파일과 라이브러리에서의 컴포넌트 이름이 다른 경우가 꽤 많았다.. 여러 시행착오^^를 겪고 난뒤 모든 파일을 연결할 수 있게 되었다. 연결 방법과 그 시행착오에 대한 내용까지 다음 편에서 상세히 정리해 보려고 한다. (예전에 이걸 잘못하고 파일 하나를 새로 만든 전적이 있다^^.. 그 경험을 바탕으로 이번엔 실수하지 않았던거겠지...)

2025.07.23 - [UXUI 디자인 고찰] - 스케치에서 피그마로 이사 프로젝트 2편 - 끊어진 컴포넌트를 라이브러리와 연결하기 (스케치에서의 문제상황과 해결법)

 

5. 라이브러리를 피그마의 디자인 구조로 수정한다. 
스케치에서는 심볼(=컴포넌트)에 베리언트도 안돼, 속성 추가도 못해,.. 심볼 갯수가 계속 늘어나고, 수정이 매우 어려웠다. 또한  css의 flex속성과 같이 코드로 만들 수 있는 작업들을 디자인에 나타내기 어려웠기 때문에 이런 구조를 수정해야했다. 예를 들어 Rectangle과 Text의 그룹으로 버튼을 표현했다면, 피그마에서는 Auto layeout이 걸린 프레임 구조로 버튼을 수정하는 것이다.(다시한번 말하지만 버전문제 때문이다!! 아마 현재 버전에는 오토레이아웃같은 기능도 있고 플러그인도 있는 것으로 알고있다. 하지만 우린 플러그인이 제대로 안굴러가는 상황이었다..🥕🥕)
여기서 중요한 점은 기존 컴포넌트를 수정한다는 것이다. 기존 컴포넌트를 수정해야 연결된 인스턴스들이 함께 수정되기 때문에 기존 컴포넌트를 수정하는 방식으로 작업했다. 사실 새로 만드는 것이 더 빠르지만.. 마스터 파일에서 다시 교체해줘야하는 번거로움이 생기기 때문에 기존 것을 수정하는 것을 기본 방법으로 택했다. 어쩔 수 없이 베리언트로 묶이거나, 새로 작업해야하는 경우 마스터 파일에서 꼭 교체해주었다.

 

• 해야할 업무
  ✅ 라이브러리 정책 논의
  ✅ 컴포넌트 구조 수정
  
  

6. 마스터 파일을 피그마 디자인 구조로 수정한다.
사실 이사 프로젝트는 4번 단계에서 이미 끝났다고도 할 수 있다.(옮겨왔다는 의미로는) 5번과 6번은 구조를 바꾸는 단계로, 구조를 변경할 필요가 없다면 굳이 필요하지 않을 것이지만, 피그마와 스케치가 엄연히 다른 프로그램이다보니 어느정도 구조 수정은 필수일 것 같다. 이 단계는 사실 시간과의 싸움이다. 필요한 작업을 위에서 모두 마쳤기 때문에 글로벌 컴포넌트를 잘 교체해주고 구조만 수정하면 끝나는 단계다. 하지만 복병이 있었는데... 더보기.. 가 아니라 말하자면, 사실 마스터 파일이 사실 실섭과 똑같지 않은 파일이 많았던 것이다. 또한 스케치에서 요소를 그룹지어서 디자인하다보니 간격이 조금씩 틀어지는 문제가 많았는데, 그런 것들이 실섭과 많이 다른 경우가 많았다. 테스트중인 화면도 있고, 디자인없이 배포되는 화면, 또...ㅠㅠㅡㅠㅜㅡㅠㅡㅠ 생각만해도 울고싶다. 진짜 현행화는 필수다.

• 해야할 업무
  ✅ 최신 파일을 실섭과 대조..🤬
  ✅ 디자인 구조 수정

 

이렇게 이사 프로젝트 프로세스를 정리해 보았다. 실제 업무는 이보다 (훨씬)더 방대했지만, 프로그램 이사 자체로는 이 정도 설명으로 정리할 수 있을 것 같다. 사실 이렇게 쓰니까 업무가 조금 축소되어 보여서 속상한데(ㅠㅋㅋㅋ) 이 단계로 오기까지 정말 수차례의 회의와 스터디를 거쳤다. 회의만 하루종일 했다고오오~~~!!~!~! 회사는 이번 업무에 리소스를 주지 못했고, 나도 모든걸 확실히 아는 게 아니였기 때문에 진땀 뺀 날도 한 두 번이 아니였다. 그래도 이런 불확실한 상황에서 의견 전달과 업무 공유의 중요성을 깨닫게 되어 오래도록 기억에 남을 프로젝트가 될 것 같다.

 

 

 

 

💟 프로젝트를 통해 느낀점

1. 파일 현행화를 귀찮아 하지 말자..!
   • 현행화가 안된 디자인 파일은 히스토리 파악이 몇 개월만 지나도 어려워진다. 심하면 몇 주만에도.. 디자인 시안과 실섭 사이에서 개발과 소통이 꺼려지게 되고(다닌지 몇 주도 안됐는데, 디자인 시안 관리가 안됐다는 것을 개발한테 들키고 싶지 않은 부끄러운 마음이 들었었다..ㅠㅠ) 디자인 시안을 보여주는게 불편하게 된다. 디자인이 계속 안맞으니 개발자도 점점 새로운 디자인을 용인해 주기 어렵게 된다.
2. 팀에서 일어나는 모든 내용은 기록하고 공유하자.
   • 기록이 중요하다는 것은 알고 있었지만, 그럼에도 더~ 중요하다고 생각하게 되었다. 공유되지 않고 남지 않는 기록은 나중에 다 잊혀지게 되고, 묻고 또 묻는 상황의 연속이 된다. 이번 프로젝트는 다들 생소한 업무였기 때문에 더더욱 규칙이나 해당 과제의 문제를 하나하나 정리할 필요가 있었다. 이전에는 회의나 메신저로 나눈 내용을 각자 정리하고 있었는데 나중에 서로 물어보면 다르게 알고 있는 경우가 많았다. 또한 다른 업무를 하다보면 이전의 업무는 잊을 수 있기에, 꼭 공유 문서로 기록하는 것이 중요하다고 깨달았다. 그래서 덤으로 노션 일지와 회의록 파일도 만들어 버렸다..
3. 개발과의 소통을 놓치지 말자.
   • 라이브러리를 만들며 생각한 점인데, 정말 UI디자인은 개발과 뗄 수 없다는 것이다. 아이콘 하나를 업로드 하는 것도 쉽게 되는 것이 아니고, 배포일정과 개발 리소스에 맞춘 디자인도 필요. 디자인의 일관성을 위한 컴포넌트 재활용하는 것도 다 개발과 연결되어있다. 그냥 디자인을 잘 만든 것에만 만족하면 안되고,.. 그 사이의 협업을 잘 이루어내야 하는 것이 큰 역량이라는 것을 다시 한 번 깨달았다.
4. 최신 툴, 트렌드에 대해 공부하자.
   • 다른 곳에서는 잘 만나기 힘든 프로젝트를 수행하면서, 이 전에 들었던 강의나 찾아놓은 인사이트들이 굉~장히 많은 도움이 되었다. 툴 이해도 측면에서도 앞서나간다는 생각이 들기도 했고.. 어느정도 내가 생각한대로 프로젝트를 구성해 볼 수도 있었다. 또한 덕분에 이번 프로젝트를 성공적으로 마무리 할 수 있었기 때문에 앞으로도 배움을 놓치지 않아야 겠다고 생각했다.
     꺅 앞으로도 홧팅~!😎