디자인 도구

화면 전용 소프트웨어가 없던 시절에는 인쇄물과 사진을 다루려고 만든 프로그램으로 앱 화면을 그렸습니다. 그 프로그램들은 한 장짜리 결과물을 잘 만들도록 설계돼 있었는데, 제품 화면은 한 장으로 끝나지 않습니다. 가입 화면 하나를 그리면 아무것도 입력하지 않은 상태, 입력 중인 상태, 비밀번호가 틀린 상태, 가입이 끝난 상태가 줄줄이 따라붙고 그 넷이 서로 이어져 있습니다.

그래서 화면이 늘어날수록 같은 일이 반복됐습니다. 버튼 색을 한 번 바꾸기로 하면 그 버튼이 들어간 파일을 전부 열어 하나씩 고쳐야 했습니다. 파일은 각자의 노트북 안에 있었고 주고받는 방법은 메신저로 보내는 것뿐이었습니다. 폴더에는 최종 파일 옆에 수정본과 진짜 최종본이 나란히 쌓였고, 개발자는 작업을 시작하기 전에 어느 파일이 맞는지부터 물어야 했습니다.

값을 확인하는 일도 매번 사람을 거쳤습니다. 페이지덱의 개발자 태오가 버튼 위쪽 여백이 몇인지 물으면 디자이너 민서가 파일을 열어 눈금을 재고 24라고 답했습니다. 그런 질문이 하루에 열 번씩 오갔고, 둘 중 하나가 회의에 들어가 있으면 그날 그 화면은 거기서 멈췄습니다. 답을 기다리다 지친 태오가 눈대중으로 20을 넣으면 구현된 화면과 시안이 4씩 어긋난 채로 배포됐습니다.

정리하면 불편은 세 가지였고 성격이 서로 달랐습니다. 첫째는 반복입니다. 같은 부품이 여러 파일에 흩어져 있어서 한 번의 결정이 수십 번의 손질로 불어납니다. 둘째는 최신본 확인입니다. 파일이 사람마다 따로 있으니 지금 열어 놓은 것이 맞는지를 매번 남에게 물어야 합니다. 셋째는 값 전달입니다. 시안 안의 숫자를 사람이 눈으로 읽어 말로 옮기는 동안 어긋날 자리가 생깁니다. 셋 중 어느 하나도 디자인을 더 잘하는 문제가 아니라, 정해진 것을 축내지 않고 옮기는 문제입니다.

디자인 도구는 이 셋을 한꺼번에 겨냥해 나왔습니다. 여러 장의 화면을 한 파일 안에 나란히 두고, 같은 부품은 한 번만 만들어 여러 화면이 나눠 쓰게 하고, 개발자가 시안에서 숫자를 직접 읽어 가게 만드는 것입니다. 상위 갈래인 디자인 축의 지형에서 보면 이 자리는 무엇을 설계하느냐가 아니라 어떻게 일하느냐 쪽에 있습니다. 화면의 좋고 나쁨을 정하는 갈래가 아니라, 정해진 것을 다른 사람에게 어긋남 없이 전달하는 경로를 맡는 갈래입니다.

디자인 도구 아래 용어는 두 갈래입니다. 하나는 실제로 켜는 프로그램의 이름이고, 다른 하나는 그 프로그램 안에서 같은 일을 두 번 하지 않게 해 주는 기능의 이름입니다. 앞엣것만 알면 어떤 창을 띄우는지까지만 알게 되고, 뒤엣것을 알아야 그 창 안에서 무슨 일이 벌어지는지가 보입니다.

두 갈래를 보기 전에 도구가 하루 동안 맡는 일을 네 칸으로 끊어 두면 이름들이 어디에 걸리는지가 분명해집니다.

1. 그립니다. 화면 한 장의 배치와 색과 글자를 정합니다.
2. 묶습니다. 여러 화면에 똑같이 들어가는 조각을 부품으로 만들어 한 자리에서 관리합니다.
3. 이어 봅니다. 화면들을 눌러 넘어가는 순서대로 연결해 실제로 써 보게 만듭니다.
4. 넘깁니다. 색과 간격과 글자 크기를 개발이 읽어 갈 수 있는 형태로 내놓습니다.

도구 갈래는 이 네 칸이 벌어지는 그릇이고 기능 갈래는 2번 칸을 가능하게 만드는 장치입니다. 1번과 3번은 도구라면 대개 다 하는 일이라 따로 이름이 붙지 않았고, 4번은 넘기는 쪽 과정에 이름이 따로 붙어 있습니다.

도구는 작업물이 담기는 그릇입니다. 두 자리가 있고, 둘은 담는 것이 서로 다릅니다.

1. 피그마 — 브라우저에서 열어 여러 사람이 같은 파일을 동시에 편집하는 디자인 도구입니다. 설치와 파일 전송 없이 링크 하나로 시안을 공유한다는 점이 이전 세대 도구와 갈리는 지점입니다. 디자이너가 화면을 고치는 중에 개발자가 같은 파일을 열어 색과 간격을 읽어 갈 수 있어서, 앞 절의 여백 24 같은 질문이 대화 없이 해결됩니다. 파일이 한 곳에만 있으니 최신본을 묻는 일도 같이 사라집니다.
2. 스토리북 — 완성된 화면이 아니라 화면을 이루는 부품 하나만 따로 띄워 보는 도구입니다. 개발자가 코드로 만든 버튼을 화면 없이 단독으로 띄워 놓고, 눌린 상태와 비활성 상태와 글자가 아주 긴 상태를 한자리에서 확인합니다. 그리는 쪽이 아니라 만들어진 쪽을 담는 그릇이라, 시안이 실제 코드로 얼마나 옮겨졌는지 대조하는 자리에서 쓰입니다. 버튼 하나에 상태가 여섯 가지인데 시안에는 두 가지만 그려져 있었다는 사실이 여기서 드러납니다.

기능은 그릇 안에서 반복을 없애는 장치입니다. 역시 두 자리가 있고, 하나는 크기를 다루고 하나는 원본과 복제본의 관계를 다룹니다.

1. 오토 레이아웃 — 내용이 바뀌면 상자 크기와 간격이 따라 움직이게 만드는 배치 기능입니다. 버튼 안 글자를 저장에서 변경 사항 저장으로 바꾸면 상자가 글자 길이에 맞춰 스스로 늘어나고, 그 버튼 옆에 있던 취소 버튼도 밀린 만큼 옮겨 갑니다. 이 기능을 쓰지 않으면 글자를 고칠 때마다 상자와 이웃 요소를 손으로 다시 맞춰야 하는데, 열 곳에서 그러다 보면 한두 곳은 틀린 채 남습니다. 한국어 시안을 영어로 바꿔 보면 차이가 한눈에 드러납니다. 글자 수가 두 배로 늘어난 화면에서 상자가 따라 늘어나면 그대로 쓸 수 있고, 안 늘어나면 스무 곳을 다시 그려야 합니다.
2. 인스턴스 — 원본 부품을 가져다 쓴 복제본입니다. 원본 하나를 고치면 그것을 쓴 복제본 전부가 함께 바뀝니다. 버튼 원본을 한 번 만들어 40개 화면에 인스턴스로 넣어 두면 색을 바꾸는 작업이 파일 40번 열기에서 원본 한 번 고치기로 줄어듭니다. 그냥 복사해 붙여 둔 것과 겉보기에는 똑같아 보이지만, 세 달 뒤에 색을 바꿔 보면 차이가 드러납니다. 원본과 이어진 39개는 따라오고 복사해 둔 한 개만 옛 색으로 남습니다.

두 갈래는 따로 노는 것이 아니라 하나의 흐름을 이룹니다. 기능이 없으면 도구는 그림판에 가까워지고, 도구가 없으면 기능은 쓸 자리가 없습니다. 이 흐름이 제대로 돌면 화면에 쓰이는 색과 간격과 부품이 한 벌로 정리되는데, 그 정리된 기준 자체를 디자인 시스템이라 부르고 그 안에 담긴 재사용 부품 하나하나를 UI 컴포넌트라 부릅니다. 도구와 기능은 그 기준을 실제로 굴러가게 만드는 바닥입니다. 기준 문서만 있고 도구 안에 부품이 없으면 그 문서는 아무도 열지 않는 규칙집으로 남습니다.

나가는 쪽도 봐 둘 만합니다. 도구에서 나온 결과물은 핸드오프, 즉 디자인을 개발에 넘기는 과정을 거쳐 구현으로 이어집니다. 예전에는 이 자리에서 화면 이미지와 간격을 적은 문서를 따로 만들어 보냈지만, 지금은 개발자가 시안 파일을 직접 열어 값을 읽는 쪽으로 바뀌었습니다. 앞의 네 칸 중 4번이 사람 손을 덜 타게 된 것이 최근 10년의 가장 큰 변화입니다. 만들기 전에 반응을 보려고 화면들을 임시로 연결해 둔 프로토타입도 같은 도구 안에서 만들고, 꾸밈 없이 구조만 그린 와이어프레임도 같은 파일에서 시작합니다. 도구 갈래가 디자인 축의 다른 갈래들과 붙어 있는 자리가 여기입니다.

"시안은 도구 안에 있으니까 파일은 안 보내 드리고 링크로 드릴게요."

받는 쪽이 늘 최신 상태를 보게 하겠다는 뜻입니다. 파일을 보내면 보낸 시점에서 멈춘 사본이 상대 노트북에 남고, 그 사본을 보고 만든 화면은 이미 지난 결정을 따릅니다.

"이 카드가 화면마다 간격이 다른데, 인스턴스로 안 쓰고 복사해서 붙이신 것 같아요."

같은 부품처럼 보이지만 원본과 끊긴 복제본이라 한쪽만 고쳐졌다는 지적입니다. 지금 간격을 손으로 맞춰도 다음 수정에서 또 벌어진다는 말이 붙어 있습니다.

"글자가 길어지면 상자가 터져요. 오토 레이아웃으로 다시 잡아 주세요."

내용 길이에 따라 크기가 따라 움직이도록 배치 방식을 바꿔 달라는 요청입니다. 시안에서만 예뻐 보이고 실제 데이터가 들어가면 깨지는 상태를 막자는 뜻입니다.

페이지덱에서 이 말들이 오가는 자리는 대개 화면 검수 회의입니다. 민서가 시안 링크를 띄우면 태오가 같은 파일을 열어 구현한 화면과 나란히 놓고 봅니다. 어긋난 곳이 나오면 원인은 둘 중 하나입니다. 시안 쪽이 원본과 끊긴 복제본을 쓰고 있었거나, 구현 쪽이 시안이 아니라 기억으로 만들었거나입니다. 앞엣것이면 민서가 그 자리에서 인스턴스로 바꾸고, 뒤엣것이면 태오가 값을 다시 읽어 갑니다. 어느 쪽이든 회의 중에 끝나고 따로 문서를 주고받지 않습니다.

지현은 이 회의에 숫자를 들고 들어오지 않습니다. 대신 화면 목록을 놓고 어디까지 시안이 정리됐는지만 확인합니다. 도구가 잘 돌고 있는 팀에서는 이 확인이 5분이면 끝나고, 그렇지 않은 팀에서는 어느 파일이 최신인지 찾는 데만 그만큼 걸립니다. 그래서 도구 이야기는 디자이너들끼리의 취향 문제로 보이지만 실제로는 일정에 먼저 나타납니다.

도구를 능숙하게 다루는 것이 곧 디자인 실력이라고 여기는 경우가 가장 많습니다. 배우기 시작할 때 눈에 보이는 진전이 대부분 도구 쪽에서 나오기 때문에 생기는 오해입니다. 단축키를 익히면 어제 두 시간 걸리던 화면이 오늘 30분에 나오니 늘고 있다는 느낌이 분명합니다. 하지만 도구가 답해 주는 것은 어떻게 그리느냐까지이고, 무엇을 그릴지와 왜 그렇게 그리는지는 도구 밖에 있습니다. 이 구분을 놓친 채로 몇 년을 보내면 시안은 빠르고 깔끔하게 나오는데 왜 이 배치인지를 묻는 자리에서 할 말이 없어집니다. 면접에서 작업물을 펼쳐 놓고 설명하는 단계에 이르면 차이가 분명해지는데, 그때는 이미 몇 년치 습관이 굳어 있습니다.

도구의 부품 기능을 켜 두면 디자인 시스템이 저절로 생긴다고 생각하는 것도 흔합니다. 원본과 복제본이라는 장치가 이미 시스템처럼 보이니 그럴듯합니다. 실제로는 기능이 만들어 주는 것은 부품을 한 번에 고칠 수 있는 연결뿐이고, 어떤 경우에 어느 부품을 쓸지에 대한 합의는 사람이 따로 만들어야 합니다. 그 합의 없이 기능만 켜 두면 원본이 늘어납니다. 이름이 비슷한 버튼 원본이 열일곱 개가 되고, 새로 들어온 사람은 어느 것을 골라야 하는지 물어볼 데가 없어서 하나를 더 만듭니다. 1년쯤 지나면 정리하는 일 자체가 별도 과제가 되어 두세 주를 잡아먹습니다.