본문은 요즘 IT와 번역가 Yuna가 함께한 에이미 로저스(Amy Rogers)의 <Getting rid of Figma>을 번역한 글입니다. 필자는 사회적 가치를 지향하는 기술 기업 Vouchsafe에서 리드 디자인 엔지니어로 일하고 있습니다. 10년 이상 프로덕트 디자인과 사용자 리서치 분야에서 일하며, 소규모 팀과 에이전시, 프리랜서를 거쳐 왔습니다. 사용자 리서치부터 최종 디자인까지 전 과정을 직접 이끌어온 경험을 바탕으로 디자인과 개발 사이의 협업 방식을 고민해 왔습니다.

이번 글에서는 디자인 엔지니어로 일하며 겪은 경험을 토대로, 우리가 익숙하게 사용해 온 도구와 프로세스를 다시 돌아보고 더 나은 일하는 방식에 관해 이야기합니다.

*필자의 허락을 받아 번역했습니다.

제가 디자이너로 커리어를 시작했을 때만 해도 ‘피그마(Figma)’가 없었습니다. UI 시안은 Adobe Illustrator로 만들고, Keynote에 옮겨서 공유했죠. 클라이언트가 수정 요청을 하면 이 과정을 처음부터 다시 반복해야 했고, 그만큼 번거롭고 고된 작업이었습니다.

그 시절에 비하면 지금은 정말 많은 게 달라졌죠. 디자이너들은 무한 캔버스에서 실시간으로 협업하고, 작업 내용은 자동 저장되고 버전 히스토리도 남습니다. 개발자에게 넘기는 과정도 훨씬 쉬워졌습니다. Figma에는 ‘개발자 모드’도 있어서 개발자들은 별다른 추가 작업 없이 디자인 파일 그대로 활용할 수 있습니다. 적어도 저는 그렇게 생각했죠. 하지만 디자인 엔지니어로 일하게 되면서, 개발자 입장에서 이 과정을 다시 보니 전혀 그렇지 않았습니다.

새로 합류한 회사 ‘Vouchsafe’에서는 예전부터 해오던 방식 그대로 Figma를 사용하고 있었습니다. 제 프론트엔드 역량을 시험해 보기 위해, 아직 코드베이스에 없는 컴포넌트 하나를 직접 구현해 보려고 했습니다. 하지만 디자인과 코드를 오가는 과정이 생각보다 훨씬 어려웠죠. 우리 팀은 ‘Tailwind’를 사용하고 있었는데, Figma 디자인 시스템에서는 컬러 네이밍 규칙이 완전히 달랐기 때문입니다.

Figma라는 싱크홀

한 번은 새로운 카드 컴포넌트를 디자인해야 했는데요. Figma에서 새 컴포넌트를 만드는 데 정말 많은 시간을 썼습니다. 그런데 문제는 그걸 결국 코드베이스에서 다시 한번 만들어야 했다는 점이었죠. 그제야 깨달았습니다. Figma에서 들인 노력이 꽤나 헛수고였죠. 결국 제가 만든 건 저 혼자만 쓰는 디자인 시스템이었던 셈이었습니다.

아이디어 단계에서도 비슷한 일이 반복됐습니다. 팀원들과 화이트보드 앞에 모여 새로운 기능의 플로우를 스케치했고, 최종 디자인 방향에도 모두 합의했죠. 그리고 Figma에 앉아 하이파이 프로토타입을 만들려던 순간, 문득 이런 생각이 들었습니다. “이건 대체 누구를 위한 걸까?” 이미 구현 범위는 정해져 있었고, 기존 컴포넌트와 패턴을 그대로 재사용할 계획이었습니다. 그렇다면 굳이 이 단계를 거치지 않고 바로 만들어버리지 못할 이유가 있을까 싶었죠.

Figma는 제 커리어 절반 이상 동안 ‘업계 표준’이었지만, 이런 간극을 반복해서 경험하다 보니 생각이 달라졌습니다. 이렇게 오랜 시간이 지났는데도 여전히 더 나은 방식이 없다는 게 과연 말이 될까 하는 의문이 들었죠.

프로세스를 다시 설계하기

다행히도 저는 저를 믿고 맡겨주는 소규모 팀에서 일하고 있습니다. 덕분에 기존 업무 방식을 이것저것 실험해 볼 수 있었죠. 그리고 프로세스를 개편하기 전까지 우리는 디자인하고, 넘기고, 다시 만드는 과정을 반복하고 있었습니다.

디자인과 관련된 모든 일을 Figma에서 했고, 그 사이에서 개발자에게 넘기는 과정은 늘 매끄럽지 않았습니다. 그러다 문득 Figma가 없다면 우리는 어떻게 일했을지 궁금해졌습니다.

컴포넌트 라이브러리로 일하기

디자인 라이브러리를 두 개나 유지하는 대신, 저는 코드베이스에 존재하는 컴포넌트에만 집중하고 싶었습니다. 어차피 최종 사용자가 실제로 보게 되는 화면은 코드 쪽이니까요.

그래서 ‘Storybook’을 도입했습니다. Storybook은 코드 레벨에서 개별 컴포넌트를 문서화하고 테스트할 수 있는 작업 공간인데요. 컨트롤 기능을 활용하면 하나의 컴포넌트가 가진 다양한 베리에이션을 바로 확인할 수 있고, hover 상태나 로딩 상태도 쉽게 확인할 수 있습니다. 또 ‘애드온’을 활용해 접근성 테스트도 진행했는데요. 단순히 색상 대비만 확인하는 수준이 아니라, 키보드 사용자나 스크린 리더 사용자도 문제없이 사용할 수 있도록 코드 구조까지 함께 살펴볼 수 있었죠.

Vouchsafe의 Storybook 컴포넌트가 동작하는 모습을 보여주는 애니메이션

무엇보다 좋았던 점은 Storybook에 있는 컴포넌트가 실제로 개발자들이 그대로 사용하는 컴포넌트라는 사실이었습니다. 그래서 버튼이 제가 의도한 모습 그대로 구현될 거라는 확신이 있었죠. 또 앱을 보다가 스타일이 어긋난 부분을 발견하더라도, 이제는 개발자를 기다리지 않고 제가 직접 바로 수정할 수 있게 됐습니다.

지금은 같은 컴포넌트를 중심으로 함께 만들어가는 프로세스로 바뀌었습니다.

컴포넌트는 정리했으니 이제 프로세스의 앞단을 살펴볼 차례입니다. 사용자 플로우와 와이어 프레임은 어떻게 빠르게 만들어 볼 수 있을까요?

만들기 전에 함께 탐색하기

탐색 단계는 원래 좀 어수선한 법입니다. 그럼에도 와이어 프레임을 그릴 때 Figma를 쓰는 건 생일 케이크 초에 불을 붙이려고 토치를 들이대는 것과 비슷하죠. 다른 도구들도 충분히 많지만 너무 익숙하다 보니 결국 손이 가는 건 늘 Figma입니다.

그래서 Vouchsafe에서는 탐색 단계에 몇 가지 도구를 정해두고 사용합니다.

우리는 화이트보드를 정말 좋아합니다. 사무실 곳곳에 화이트보드가 있는데요. 모두 출근한 날에는 노트북을 들고 보드 앞에 둘러앉아 함께 생각합니다. 기존 디자인과 코드도 함께 보면서, 펜으로 다양한 패턴을 직접 스케치하죠.
원격으로 일할 때는 Miro 보드를 열어 함께 정리합니다. 좀 더 구조화된 내용을 적거나, 사용자 리서치나 다른 미팅에서 나온 메모를 엮을 때는 Notion을 활용합니다.
시각적인 결과물이 필요할 때는 Penpot을 열어서 빠르게 몇 가지 안을 만들어봅니다. ‘Penpot’은 오픈소스 기반의 Figma 대안으로 웹 디자인에 적합합니다.

이 방식들의 가장 중요한 공통점은 모두 ‘협업에 최적’이라는 것입니다. 과거에 Figma로 탐색 작업을 할 때는 보통 제가 마우스를 쥐고 있고, 다른 사람들은 “이걸 저쪽으로 옮겨보자” 같은 의견만 던지는 구조였죠. 화이트보드나 Notion 문서에서는 누구나 바로 참여할 수 있습니다. 이 단계에서는 모든 사람의 관점이 중요하기 때문에 디자인 과정에 누구나 자연스럽게 참여할 수 있습니다.

그래서 지금은 여러 도구로 함께 아이디어를 풀어보고, 이후에는 컴포넌트를 기준으로 바로 구현하는 프로세스로 일하고 있습니다.

우리에게 맞는 도구들로 하나씩 바꿔가다 보니 어느 순간 Figma는 자연스럽게 사라졌습니다. 모두가 함께 사용할 수 있는 도구에서 생각을 정리하고, 곧바로 코드로 넘어가게 됐죠. 조금 이상하게 들릴 수도 있겠지만, 지금 우리의 제품 디자인 프로세스 어디에도 Figma는 없습니다.

돌아보며

도구는 정말 빠르게 변합니다. 몇 년 뒤에 이 글을 다시 읽어보면, 완전히 다른 프레임워크들을 쓰고 있을지도 모르겠죠. 하지만 한 가지는 변하지 않을 거라고 생각합니다. 디자이너가 코드에 더 가까워지고 있다는 점입니다. 저는 이미 2019년에 디자이너는 코드를 이해해야 한다고 이야기했는데요. 지금도 그 생각은 변함이 없습니다. 다만 최근에는 코드를 직접 작성하는 디자이너들도 점점 늘어나고 있고, 이 흐름이 쉽게 멈출 것 같지는 않습니다.

물론 우리가 시도한 방식이 모두에게 맞지는 않을 겁니다. 저는 코딩을 좋아하고, 그에 대한 자신감도 있는 편이니까요. 우리 팀은 규모가 작고, 빠르게 움직이는 제너럴리스트 팀입니다. 각자 여러 역할을 맡아 일하는 구조라 이런 방식이 가능했죠. 그래서 이 접근법이 규모가 큰 조직에서도 그대로 통할지는 모르겠습니다. 그래도 각자의 상황에 맞게 한 번쯤은 시도해 봤으면 좋겠습니다.

디자인 업계가 변해가더라도, 우리가 테이블 위에 가져오는 가치가 무엇인지는 계속해서 의식해야 합니다. 설령 그 가치를 만들어내는 도구의 모습이 달라지더라도 말이죠.

<원문>

Getting rid of Figma