피그마

디자인 도구가 개인 컴퓨터에 설치하는 프로그램이던 시절이 있었습니다. 작업 파일은 만든 사람의 노트북에만 있었고, 남에게 보여 주려면 이미지로 내보내 메신저에 올리거나 압축해서 메일로 보냈습니다.

여기서 세 가지가 매번 어긋났습니다. 첫째는 어느 것이 최신본인지였습니다. 메신저를 거슬러 올라가며 시안_최종.png와 시안_최종_수정.png 중 어느 쪽이 나중인지 확인하는 일이 회의 시작마다 붙었습니다. 둘째는 값이었습니다. 개발자가 이 여백이 24인지 32인지 물으면 디자이너가 파일을 열어 확인하고 답해 주는 왕복이 하루에도 몇 번씩 생겼습니다. 도구가 macOS에서만 돌던 시절에는 윈도를 쓰는 개발자나 기획자가 파일을 아예 열지 못했습니다.

셋째는 동시에 손을 대지 못한다는 것이었습니다. 한 파일은 한 사람이 열어 고치고 저장한 뒤 넘기는 식이라, 디자이너 둘이 같은 화면을 나눠 작업하면 나중에 두 파일을 하나로 합치는 일이 따로 생겼습니다. 이 도구는 파일을 각자 내려받는 물건에서 다 같이 들여다보는 자리로 옮겨 이 세 가지를 한꺼번에 없앴습니다.

이 도구가 없애는 문제는 파일이 여러 벌로 갈라지면서 생기는 것들입니다. 작업물이 서버 한 곳에만 있고 모두가 그 한 곳을 열기 때문에, 최신본을 묻는 대화와 합치는 작업과 열어 보지 못하는 사람이 같이 사라집니다.

1. 공유가 링크 하나로 끝납니다. 설치도 내려받기도 필요 없어서 개발자와 기획자와 대표가 같은 주소를 열어 봅니다. 시안을 보여 주려고 이미지를 내보내던 단계가 통째로 빠집니다.
2. 여러 명이 같은 화면을 동시에 고칩니다. 각자의 커서가 화면에 보이고 고친 내용이 바로 반영되니 합치는 일이 없습니다.
3. 개발자가 값을 직접 읽어 갑니다. 요소를 누르면 색과 간격과 글자 크기가 나오고 그대로 복사할 수 있습니다. 여백이 24냐고 묻는 대화가 사라지는 자리가 여기입니다. 디자인을 개발에 넘기는 핸드오프 과정이 별도 문서 없이 돌아가게 된 것이 지난 10년의 가장 큰 변화입니다.
4. 같은 일을 두 번 하지 않게 하는 장치가 안에 있습니다. 내용이 바뀌면 상자와 간격이 따라 움직이는 오토 레이아웃, 원본을 고치면 그것을 쓴 복제본 전부가 함께 바뀌는 인스턴스가 그것입니다. 버튼 색 하나를 바꾸는 작업이 화면 40개를 여는 일에서 원본 한 번 고치는 일로 줄어듭니다.
5. 만들기 전에 반응을 보는 프로토타입과 구조만 그린 와이어프레임도 같은 파일에서 만듭니다. 도구를 갈아타지 않고 한 파일 안에서 단계가 이어집니다.

여기까지 갖춰지면 색과 간격과 부품이 한 벌로 정리된 디자인 시스템을 실제로 굴릴 바닥이 생깁니다. 그 안의 재사용 부품 하나하나가 UI 컴포넌트입니다.

대안은 크게 셋입니다. 무엇을 고를지는 기능보다 회사의 사정이 정합니다.

1. 설치형 도구. 스케치처럼 macOS에 설치해 쓰는 도구가 여전히 있습니다. 오래된 팀은 수년치 작업 파일이 이 형식으로 쌓여 있어 옮기는 비용이 큽니다. 한 사람이 열어 고친 뒤 넘기는 방식이라 동시 편집은 따로 되지 않고, 보는 사람을 위한 웹 뷰어가 나중에 붙은 형태입니다.
2. 자체 서버에 올리는 오픈소스 도구. 펜팟 같은 도구는 회사 서버에 직접 설치해 씁니다. 작업물이 외부 서비스에 올라가면 안 되는 금융이나 공공 영역에서 고릅니다.
3. 도구를 쓰지 않는 선택. 화면 수가 적고 디자이너가 없는 팀은 발표 자료 도구로 배치만 잡고 바로 코드로 넘어갑니다. 화면이 스무 개를 넘어가기 전까지는 이쪽이 빠를 때도 있습니다.

고르는 기준은 셋입니다. 작업물을 외부 서버에 둘 수 있는지, 함께 파일을 여는 사람이 몇 명인지, 이미 쌓인 자산이 어느 형식인지입니다. 앞의 둘에 걸리지 않고 팀이 새로 시작하는 상황이면 사실상 고민이 생기지 않습니다.

"피그마 링크 주세요. 간격 값 직접 볼게요."

물어보는 왕복 없이 필요한 값을 스스로 확인하겠다는 뜻입니다.

"이거 인스턴스로 안 되어 있어서 화면마다 따로 고쳐야 해요."

부품을 원본에 이어 두지 않아 같은 수정이 여러 번 반복된다는 지적입니다.

"그 버튼 수정한 거 반영됐나요? 제가 보는 건 아직 옛날 색인데요."

같은 파일을 보는 중에도 어느 화면을 열고 있는지에 따라 보이는 것이 다르다는 상황입니다.

페이지덱에서 민서가 결제 화면을 고치는 동안 태오가 같은 파일을 열어 두고 작업하는 것이 일상입니다. 민서가 버튼 높이를 40에서 44로 올리면 태오 화면에도 그 순간 반영되고, 태오는 코드의 값을 같이 바꿉니다. 예전이라면 수정본을 내보내 전달하고 태오가 그것을 받아 다시 재는 데 반나절이 걸렸을 일입니다.

다만 모든 대화가 사라지지는 않았습니다. 태오가 자주 묻는 것은 값이 아니라 그려지지 않은 상태입니다. 목록이 비어 있을 때, 글자가 아주 길 때, 네트워크가 끊겼을 때의 화면은 시안에 없을 때가 많고 그건 파일을 아무리 자세히 봐도 나오지 않습니다.

이 도구를 쓰면 디자인 시스템이 생긴다고 여기는 경우가 많습니다. 부품을 만들고 재사용하는 기능이 들어 있으니 그렇게 보입니다. 하지만 도구가 주는 것은 부품을 담을 자리이고, 어떤 색을 몇 개만 쓸지와 언제 어느 부품을 쓸지는 사람이 정해 합의해야 합니다. 그 합의 없이 파일만 쌓이면 이름이 비슷한 버튼이 열두 개 생기고, 그 상태는 부품이 하나도 없던 때보다 고치기 어렵습니다.

시안이 곧 코드라고 보는 오해도 흔합니다. 화면에 보이는 것이 완성된 제품과 똑같이 생겼기 때문입니다. 실제로는 시안 한 장이 코드에서는 여러 상태로 갈라집니다. 버튼 하나에도 눌린 상태, 비활성 상태, 글자가 넘칠 때의 모습이 필요한데 시안에는 보통 기본 상태만 그려져 있습니다. 이 차이를 모른 채 일정을 잡으면 개발 단계에서 그려지지 않은 화면을 묻느라 시간이 흩어집니다. 시안을 받은 자리에서 빠진 상태를 먼저 목록으로 뽑아 두면 이 왕복이 앞으로 당겨집니다.