4,883장의 스크린, Figma로 이사하기

안녕하세요.

숨고에서 Product Designer로 일하고 있는 Ean입니다.

다소 늦은 감이 있지만 숨고의 Design Chapter는 스케치(Sketch)와 헤어질 결심을 갖고 올해 8월에 피그마(Figma)로 이사를 완료했습니다.

숨고는 투 사이드 플랫폼(Two-Side Platform)이면서 앱, 모바일 웹, 데스크톱 웹까지 대응하다 보니 생각보다 방대한 분량을 가지고 있습니다. 이로 인해 전환을 결정하고 실행하는 데까지 꽤 오랜 시간이 걸렸고 목적 조직에는 영향 없이 최소한의 리소스로 4,800 여장의 스크린을 이관하는 작업이었기에 내부 리소스를 투자해서 이관하는 보편적인 방식보다 조금은 다른 방법으로 이사를 했습니다.

요새는 디자인 툴 전환이 스타트업에선 흥미있는 토픽은 아니지만 물리적인 양이 많고 시간과 리소스가 제한적인 환경에서 툴 전환을 고민하고 계신다면 이렇게 옮길 수도 있겠구나 참고의 글 정도로 읽어주시면 좋을거 같습니다.

👋 스케치와 헤어질 결심

여러분은 2020년도에 디자인 툴 삼국시대를 기억하시나요?

2023년 지금은 대부분의 회사가 피그마로 대동단결하는 분위기이지만, 몇 년 전까지만 하더라도 스케치와 피그마, 그리고 어도비의 XD가 삼파전을 이루고 있었습니다.

스케치는 기존 포토샵 환경의 단점을 해소하고 개발 친화적인 UI 드로우 툴의 시작점이 되었고, 디자인 라이브러리와 심볼이라는 개념을 제대로 심어준 툴이었지 않았나 싶습니다. 때문에 당시에는 포토샵에서 스케치로 옮겨가는 흐름이 꽤 거셌던 것으로 기억합니다. 그 흐름에 저도 포함되어 있었고요.

이런 스케치에 대항하기 위해 어도비에서는 XD를 출시했고, 피그마도 알음알음 국내 사용자들에게 알려져 점점 사용자가 늘어가던 추세였습니다.

이렇게 기존 포토샵 일변도였던 UI 툴에 다양한 선택지가 생김에 따라 조직규모와 환경에 맞춰 각각 적합한 툴을 선택하는 상황이 되었습니다.

예를 들어 스케치는 MacOS에서만 사용이 가능하기 때문에 Windows를 사용하거나 산출물을 외부에 전달해야 한다면 스케치 대신 XD를 선택하는 경우가 있었습니다. 한편 많은 사람이 동시에 협업해야하는 업무가 중심인 경우에는 피그마를 고려하기도 했습니다.

실제로 제가 이전에 근무했던 곳에서도 비슷한 고민이 있었고 제가 숨고에 합류하기 전 여러 곳과 인터뷰를 했을 때도 디자인 툴 변경에 대한 고민이 있던 곳이 숨고를 포함해 대략 30%나 되었을 정도였습니다.

이렇게 저와 비슷한 시기를 겪은 스타트업들은 한 번쯤은 UI 툴 전환에 대해 고민했거나 혹은 지금까지도 고민하고 있을거라 생각합니다. (아니면 처음부터 피그마를 사용했던 선구자들이었거나!)

2023년 8월 이전 숨고 Design Chapter의 툴 환경은요

피그마로 이사를 가기 전 Design Chapter 내 Product Designer들의 일감 환경을 공개합니다.

보시면 아시겠지만 와이어프레임부터 Hand-Off 까지 모든 단계에 툴이 파편화 된 상태였습니다. 와이어프레임과 GUI 산출물들이 3개의 툴로 흩어져 있다보니, 다른 디자이너의 작업물을 참고하거나 히스토리 파악을 위해 파일을 찾으려면 담당자에게 물어보지 않고서는 탐색하기가 수월하지 않았습니다.

하지만 가장 큰 불편함은 거의 매일 겪었던 피그마 - 스케치 - 제플린 간의 삼중 동기화 문제였습니다.

협업 과정에서 GUI 수정 사항이 단 하나만 발생하더라도 세 개의 툴에 모두 업데이트를 해야했습니다. 특히 제플린의 경우 애자일 조직인 스쿼드의 일감이 많이 쌓여 이미 포화 상태였습니다. 업데이트만 10분 이상 걸릴 때도 있었고 업데이트 실패도 종종 있었습니다. 이렇게 잦은 버그들로 제플린 CX팀에 자주 메일을 보내기도 했지만 실질적으로 해결되는건 많이 없었어요.

이러다보니 텍스트 수정처럼 자잘한 사항들은 우선 구두로 해결하고 나중에 업데이트를 하다보니 점점 동기화가 늦어졌고, 어떤게 제일 최신 스크린인지는 디자이너 본인만 아는 상황이 많아졌어요.

이렇게 불편한데 왜 툴 변경을 바로 안했나요?

이런 어려움에도 협업 툴을 변경한다는 것은 그 당시에 바로 할 수 있는 가벼운 일은 아니었습니다. 제가 숨고에 입사했을 당시 숨고는 서비스의 규모를 키우기 위해 막 시동을 걸고 있었기 때문에 모든 스쿼드가 소위 말해 ‘악셀을 밟고 달려야’ 하는 시점이었거든요. 프로덕트 성장이 1순위였던 당시 상황 상 툴 변경은 상대적으로 우선순위가 낮았습니다.

또 당시에는 지금처럼 Product Designer가 많지 않은 상황이었던데다가 모든 디자이너가 스쿼드 업무에 100%의 리소스를 사용하고 있었습니다. 숨고 프로덕트의 전반적인 영역에서 실험과 개선이 많이 이루어지고 있었기 때문에 일부만 피그마로 변경했을 때 오히려 문제점이 더 크다고 생각했죠.

하지만 협업 툴의 파편화로 인한 문제는 디자이너들만의 문제는 아니었습니다. 엔지니어들은 피그마와 제플린을 이중으로 띄워두고 작업을 해야했고, 만약 피그마와 제플린 간의 차이가 있다면 디자이너에게 다시 한번 확인을 해야하는 과정을 거쳐야 했습니다. 다시 생각해봐도 이런 환경은 엔지니어들에게도 썩 원활한 업무 환경이라고 말하긴 어려울 것 같습니다.

어떻게 하면 디자이너들이 효율적인 환경에서 더 생산적으로 일할 수 있을지는 디자이너, 그리고 CPO인 Reo에게도 오랫동안 중요한 아젠다였습니다.

협업 툴을 일원화했을때의 이점을 디자이너 뿐만 아니라 엔지니어를 포함한 이해관계자들 모두가 공감하고 있었기에 조직이 어느 정도 안정적인 궤도에 올랐을 시점, ‘툴 전환을 정말로 해보자!’ 라는 결심 끝에 이사를 시작하게 되었습니다.

📦 피그마로 이사 준비하기

이사의 전제조건

피그마로 이사의 전제 조건은 아래와 같았습니다.

1. 스쿼드(목적조직) 리소스에는 영향을 주지 않기
2. 이사 이후 마스터 최신화를 위해 최소 기간(1개월 이내)에 마무리하기

이사 여부는 순조롭게 결정되었지만 전제 조건을 충족시키면서 이사를 하는 것은 쉽지 않았습니다.

우선 가장 큰 제약 사항은 인원이었어요. 작업 대상 스크린이 100장~200장 내외였다면 디자이너들과 협업하며 일주일에서 열흘 정도라면 옮길 수 있겠지만, 숨고는 앱과 모바일 웹, 데스크톱 웹까지 포함하면 플랫폼 전체의 스크린이 무려 5,000여 장이나 됐습니다

그렇다고 모든 디자이너를 투입하기엔 리소스 낭비라고 생각했습니다. 전체 인원이 합을 맞추는 기간까지 포함하면 이사 기간이 3주 이상 소요될 것 같았거든요.

결국 두 가지 전제조건을 충족하면서 피그마로 빠르게 이사를 할 방법으로 선택한 것이 바로 외부 어시스턴트와 함께 일하는 방법이었습니다. 이사를 담당하는 디자이너를 한 명 정해서 외부 어시스턴트와의 커뮤니케이션 채널을 일원화해 단기간에 옮기는 방법을 전제로 상세 이관 방식과 타임라인, 비용을 산정했습니다

이사 준비

가이드라인 제작하기

스크린이 워낙 많기 때문에 피그마에서 스크린을 모두 새롭게 그리지 않고, 피그마에 Import 된 화면을 교정하는 방식으로 진행했습니다.

이렇게 했을 경우 상당수의 화면에서 UI Element 사이즈나 X, Y 점들이 정수가 아닌 소수점으로 깨져있기도 합니다. 아이콘, 그래픽도 복잡도가 있을 경우 Shape이나 Stroke가 틀어져있습니다. 당연히 라이브러리도 연결이 끊어져 있기 때문에 다시 연결해 주는 작업도 필요합니다.

슬프게도 스케치에서 라이브러리를 적극적으로 활용했다면 보정해야하는 대상이 좀 더 많을 수 있습니다. 케이스에 따라 다르겠지만 숨고의 경우 자주 사용되는 컴포넌트의 텍스트가 Placeholder로 깨져있는 상태였어요.

이렇게 교정이 필요한 화면들을 어시스턴트와 함께 작업하기 위해서는 최소한의 가이드라인이 필요하다고 생각했습니다. 그래서 주요 가이드라인을 아래와 같이 정했습니다.

1. 스케치에 적용된 Style과 Components는 세팅된 피그마 라이브러리로 연결해주기
2. 모든 레이어는 Frame과 Auto Layout을 사용하여 교정하기
3. 소수점은 정수로 교정하기
4. 깨진 텍스트 내용을 교정하기

이 중에서 2. 모든 레이어는 Frame 과 Auto Layout을 사용하여 교정하기가 실제로 가장 적용하기 어려운 가이드라인이었습니다.

생각보다 디자이너들이 피그마에서 Frame과 Group, Auto Layout을 사용하는 규칙이 저마다 다르기 때문에 공통의 방식을 숙지하는데 시간이 걸리기 때문입니다. 하지만 원활한 이사를 위해서는 최소한의 규칙을 잡아두는 것이 일관된 화면 정리에 도움이 될 것이라 생각했습니다.

실제로 어시스턴트 분들도 이 룰에 적응하는데만 1주일 정도 걸렸는데요. 그럼에도 이 룰을 제외하지 않았던 이유는 물론 추후에 내부 디자이너들이 손을 봐야겠지만 그 전에라도 화면이 최소한의 일관된 기준으로 정리가 되어있어야 했고, 일정 기간이 지나면 작업에 속도가 붙을 것으로 기대했기 때문입니다.

타임라인 세우기

숨고는 앱과 데스크탑 웹, 모바일 웹의 스크린을 모두 합치면 5,245장이 나옵니다. 물론 반복되는 스크린이 많고 모든 스크린이 손이 많이 가지는 않기 때문에 단순히 장수가 많다고 해서 소요 기간이 오래 걸리는 것은 아닙니다.

다만 대략적인 일정 산정과 일감 분배를 위해 각 도메인별 스크린 수를 계산하고 여기서 불필요하거나 우선 순위가 낮은 도메인을 배제했습니다. 그 결과 2명의 어시스턴트와 총 4,883장의 스크린을 작업하는 일정을 산정할 수 있었습니다.

타임라인을 대략적으로 세우고 담당 어시스턴트와 상세 업무 조율을 진행했습니다. 그리고 최대한 업무 유사성이 있는 도메인별로 묶어 담당자를 배정하고 데일리, 위클리 별 목표 분량을 설정했습니다.

이 글을 쓰면서 회고를 해보니 당시 제가 세운 타임라인은 내부 인력 기준으로 산정한 타임라인이었던 터라 일정이 타이트했던 것 같습니다. 일주일은 온보딩 기간으로 소요되고, 작업 속도가 붙기까지 또 일주일이 걸렸기 때문에 생각하는 기간보다 최소 2~3주를 더해 산정하는 것이 현실적인 것 같습니다. 저희 이관 계획도 계획상으로는 한 달이었지만 실제로는 한 달 반정도 소요되었습니다.

🚚 어시스턴트와 함께 피그마로 이사하기

온보딩 기간 갖기

어시스턴트 분들께 처음 가이드라인을 안내드리고 난 후 일주일 정도는 가이드라인에 맞추어 교정한 화면을 담당자가 한번 더 확인했습니다. 담당자는 누락되었거나 재교정해야할 사항은 없는지 확인하고 이를 다시 어시스턴트 분들이 수정해주시는 것을 반복하는 방식으로 교정을 진행했습니다.

이런 방법을 사용하게 되면 처음에 속도가 나지 않아 조급할 수는 있겠지만 저희의 경험 상 대략 일주일 정도만 합을 맞춰보면 속도는 충분히 붙습니다. 이 기간을 거쳐야지 재교정 건 수가 확연하게 줄기 때문에 조급해하기보다는 충분한 온보딩 기간을 갖는 것이 좋다고 생각합니다.

온보딩 이후 교정 프로세스

가이드라인이 충분히 숙지되었다고 생각된다면 초기 작업은 그대로 어시스턴트가 하되, 재교정은 담당자가 직접 진행했습니다.

이 기간 동안에 전달되는 교정 스크린들은 내부 디자이너들만 캐치할 수 있는 마이너한 수정사항이 대부분이고, 이를 위해 어시스턴트와 커뮤니케이션하는 리소스가 더 크기 때문에 담당자가 직접 재교정을 하는 것이 전체적인 속도를 높이는데 효율적입니다

저희 같은 경우 정말 감사하게도 함께 일했던 어시스턴트분들이 짧은 기간에 가이드라인에 잘 적응해주셔서 온보딩 기간 이후로 재교정 사항이 적었습니다.

이후 어시스턴트 분들과 데일리 스크럼을 통해 스크린을 교정하는데 어떤 것이 제일 오래걸리는지 확인하면서 작업에 방해가 되는 룰은 줄여나갔고, 자주 나오는 교정사항을 취합해 전달하며 타임라인에 맞추어 프로젝트를 진행했습니다.

그렇게 Product Designer 1명과 2명의 어시스턴트의 협업으로 약 한 달 반의 시간 동안 총 4,883장의 스크린을 피그마로 이관할 수 있었습니다.

🗃️ 피그마로 이사가 끝난 후

피그마 GUI 가이드라인 공유하기

피그마로 GUI를 산출하고 합을 맞추는 것은 이제 첫 걸음 단계입니다. 앞서 말씀드렸듯 디자이너들의 피그마 Frame과 Auto Layout 사용 방식이 정말 다르기 때문에 이를 통일시키기 위한 GUI 가이드라인*을 설정했습니다.

*숨고 Design Chapter의 Auto Layout 룰은 CSS Margin과 Padding을 참고하고 있습니다.

가이드라인은 모든 디자이너가 피그마를 처음 사용한다는 전제하에 작성했습니다. 때문에 기초적인 룰을 포함시켜야 해서 분량이 적진 않았지만 앞으로 디자인 산출물을 바탕으로 엔지니어와의 원활한 커뮤니케이션을 위해서 내용을 충분히 가져가야 했어요.

피그마 마스터 최신화 하기

이사 기간 동안 배포된 디자인을 마스터에 업데이트까지 완료해야 정말로 이사가 끝이 납니다.

물론 이 과정을 스킵하고 새로운 일감부터 피그마로 바로 작업할 수도 있습니다. 하지만 디자이너들도 GUI부터 Hand-off까지 피그마로 전달하는 것은 처음이기 때문에 일관된 산출물 관리와 GUI 가이드라인을 숙지를 위해 마스터 업데이트를 진행했습니다.

우선 슬랙에 마스터 업데이트 쓰레드를 생성하고 각자 일정과 업데이트 항목을 공유합니다.

그리고 마스터에 업데이트 된 스크린을 담당자가 검수하고 해당 디자이너가 검수 사항을 확인하여 다시 교정하는 방식으로 업데이트를 진행합니다.

디자이너들도 피그마로 처음 GUI 합을 맞추는 것이기 때문에 숙지 기간이 필요합니다. 그래서 어시스턴트와 마찬가지로 가이드라인 공유 후 업데이트 하는 프로세스를 어시스턴트 온보딩 기간과 동일하게 가져갔습니다.

마지막으로 검수 완료 후 업데이트 감옥에 가둔 디자이너들을 차례차례 석방했습니다.

장담컨대, 이 단계가 모든 이사 과정에서 고난과 역경의 최고봉이었습니다. 스케치에 있던 작업물을 GUI 가이드라인에 맞춰 피그마에 새롭게 그려야 했기 때문에 업데이트에 꽤 시간이 많이 걸렸고, 무엇보다 모든 디자이너들이 스쿼드 업무를 소화하면서 진행해야했기 때문에 단기간에 마스터를 최신화 하는 것은 쉽지 않았습니다. 게다가 7명이나 되는 Product Designer의 업데이트 항목을 담당자였던 제가 혼자 검수해야했기 때문에 상당히 흉폭한 상태였습니다.

그렇게 고난과 역경의 마스터 최신화 기간 끝에 올 7월 말, 드디어 마스터 최신화가 완료되어 피그마로 이사는 정말로 끝이 났고, 숨고의 Design Chapter는 이제 피그마로만 모든 협업을 진행하고 있습니다.

🐥 그래서 정리하자면

작성한 글을 되짚어보니 긴 회고록이 된 거 같습니다. 이전에 근무했던 회사에서 스케치에서 피그마로 전환 경험을 했었기에 수월할 줄 알았으나 5,000장 가까이 되는 스크린을 이관하는 건 결코 쉬운 일은 아니었습니다.

다행히 전사의 공감대가 형성되어 전환 리소스와 비용을 투자할 수 있었고, 어시스턴트의 협업을 통해 완료할 수 있었습니다. 저 혼자 했다면 넉 달은 걸리지 않았을까 싶네요.

이렇게 고생해서 이사를 한 만큼 당분간은 계속 피그마 가라사대였으면 좋겠지만 앞으로 툴 변경이 없다고 장담하긴 어렵습니다. 더 나은 협업 툴이 생긴다면, 조직과 협업 방식에 따라 언젠가 툴은 또 바뀌게 될 수도 있습니다.

현재 툴 변경을 하는데 물리적으로 양이 많고, 시간과 리소스가 제한적이라는 허들을 가지고 계신다면 외부 어시스턴트와 협업하여 툴을 전환하는 방법도 고려해 보면 좋을 거 같습니다.