디자인 엔지니어

시안을 넘기고 구현을 기다리는 방식에는 늘 새는 자리가 있었습니다. 색값과 여백처럼 숫자로 적을 수 있는 것은 잘 옮겨졌는데, 숫자로 적기 어려운 것이 매번 어긋났습니다. 버튼에 마우스를 올렸을 때 색이 변하는 속도, 목록이 접혔다 펴질 때의 움직임, 글자가 화면 폭을 넘길 때 줄을 바꿀지 잘라 낼지 같은 것들입니다.

이것들은 시안 파일에 담기지 않습니다. 시안은 멈춰 있는 그림이라 움직임을 보여 줄 수 없고, 잘 풀린 경우 한 장만 그려져 있어서 글자가 아주 긴 경우는 아예 들어 있지 않습니다. 그래서 민서가 "여기는 0.2초쯤으로 부드럽게" 라고 적어 보내면 태오가 나름대로 구현하고, 나온 결과를 민서가 보고 다시 말로 설명하는 왕복이 시작됐습니다. 한 번 도는 데 반나절이 들었고, 세 번을 돌아도 민서가 머릿속에 그린 것과는 조금씩 달랐습니다.

값을 정해 이름을 붙여 두는 디자인 시스템이 자리를 잡으면서 이 문제가 더 선명해졌습니다. 시스템은 시안 도구 안에만 있어서는 쓸모가 없고, 같은 값이 코드 쪽에도 똑같이 있어야 합니다. 양쪽을 맞춰 두는 일은 그림을 그리는 일도 아니고 기능을 만드는 일도 아니라서 누구의 일도 아니었습니다. 디자인 엔지니어는 새어 나가던 이 자리를 한 사람에게 묶은 결과입니다. 넘기는 단계를 없애는 것이 이 역할의 방식입니다.

하루의 절반 이상은 코드를 쓰는 데 들어가고, 나머지가 시안과 논의입니다. 다만 그 코드가 기능이 아니라 화면을 이루는 재료라는 점이 다릅니다.

1. 부품 만들기 — 버튼과 입력창처럼 여러 화면에서 쓰이는 조각을 코드로 만들어 컴포넌트 라이브러리에 넣습니다. 여기서 가장 손이 많이 가는 것은 평상시 모습이 아니라 나머지입니다. 비활성일 때, 불러오는 중일 때, 글자가 스무 자를 넘을 때, 값이 없을 때를 전부 만들어 둡니다.
2. 값 맞추기 — 색과 간격에 붙인 이름이 시안 도구와 코드에서 같은 값을 가리키게 유지합니다. 디자인 토큰이 이 이름들이고, 한쪽에서 값을 바꿨는데 다른 쪽이 따라오지 않으면 시스템은 그날부터 둘로 갈라집니다.
3. 움직임 만들어 보기 — 말로 설명이 안 되는 인터랙션은 실제로 동작하는 화면을 만들어 보여 줍니다. 세 가지 속도로 만들어 나란히 놓고 고르게 하는 편이 회의에서 설명하는 것보다 빠릅니다.
4. 구현 확인 — 나온 화면과 시안을 나란히 놓고 어긋난 곳을 찾습니다. 여백이 4씩 밀린 것 같은 문제는 눈으로 찾는 대신 자동으로 걸리게 만들어 두기도 합니다.
5. 시안 자리에 앉기 — 화면을 정하는 자리에 들어가 구현 비용을 그때 알려 줍니다. 제품에 아직 저장돼 있지 않은 값을 화면에 띄우려는 설계라면 이 시점에 아는 것이 가장 쌉니다.

다섯 가지를 매일 다 하지는 않습니다. 시스템을 처음 세우는 팀에서는 1번과 2번이 하루를 다 가져가고, 자리를 잡은 팀에서는 3번과 5번의 비중이 커집니다.

두 방향으로 붙어 앉습니다. 한쪽은 UX 디자이너나 프로덕트 디자이너처럼 화면을 정하는 사람이고, 다른 쪽은 그 화면 위에 기능을 얹는 개발자입니다. 이 역할이 오래 붙어 있는 쪽은 앞이지만, 코드를 합치는 규칙을 따르는 쪽은 뒤입니다.

겹치는 자리에서 마찰이 생깁니다. 화면 쪽 코드를 둘이 건드리게 되니 어디까지가 누구 것인지 정해 두지 않으면 같은 파일을 서로 다른 방향으로 고칩니다. 흔히 쓰는 경계는 부품과 화면입니다. 여러 곳에서 쓰이는 부품은 디자인 엔지니어가 맡고, 그 부품을 조립해 만드는 화면과 그 뒤의 데이터는 개발자가 맡습니다. 부품을 따로 띄워 상태별로 확인하는 스토리북 같은 도구를 쓰면 경계가 눈에 보여서 이 합의가 쉬워집니다.

소속은 둘 중 하나입니다. 디자인팀에 두면 시안 자리에 자연스럽게 앉지만 코드 쪽 논의에서 빠지기 쉽고, 개발팀에 두면 반대가 됩니다. 구성원 50명 아래에서는 대개 한 명이라 소속보다 어느 자리에 참석하느냐로 정해집니다.

"이건 디자인 엔지니어가 붙어야 할 것 같은데요."

시안만으로는 정할 수 없고 만들어 봐야 아는 문제라는 뜻입니다.

"토큰은 제가 양쪽 맞춰 둘게요."

시안 도구와 코드에 같은 값이 들어가도록 정리하겠다는 말입니다.

"일단 세 가지로 만들어 놨으니까 보고 고르시죠."

말로 하던 논의를 동작하는 화면 세 개로 바꿔 놓았다는 뜻입니다.

페이지덱에서는 문서 목록의 정렬 방식을 바꾸는 일이 이 역할의 자리였습니다. 민서는 목록이 다시 정렬될 때 항목들이 자리를 옮기는 모습을 보여 주고 싶어 했는데, 그 움직임을 시안 파일로는 설명할 수 없었습니다. 회의에서 손으로 허공에 궤적을 그리는 일이 두 번 반복된 뒤에 방향이 바뀌었습니다.

디자인 엔지니어가 세 가지 버전을 만들어 실제 브라우저에서 돌려 놓고, 민서와 태오와 지현이 같은 화면을 눌러 보며 하나를 골랐습니다. 30분이 걸렸고 그날 그대로 코드에 남았습니다. 태오는 그 뒤로 목록 뒤에서 데이터를 가져오는 쪽만 맡았습니다.

코드를 조금 아는 디자이너를 부르는 다른 이름으로 아는 경우가 흔합니다. 직함에 두 분야가 다 들어 있으니 어느 한쪽에 곁다리가 붙은 형태로 읽기 쉽습니다. 실제로는 만들어 배포하는 코드를 쓰는 자리라, 코드를 합치는 규칙과 테스트와 성능을 개발자와 같은 기준으로 지킵니다. 곁다리로 알고 뽑으면 시안은 잘 나오는데 코드가 합쳐지지 않아 결국 개발자가 다시 쓰게 되고, 그러면 없애려던 넘기는 단계가 그대로 돌아옵니다.

둘을 반씩 하니 양쪽 다 어중간하다는 오해도 있습니다. 이 역할이 값을 내는 자리는 양쪽의 평균이 아니라 둘 사이에서만 보이는 문제입니다. 움직임의 속도, 글자 길이가 변할 때 무너지는 배치, 시안에는 그려져 있지만 코드로는 만들 수 없는 그림자 같은 것들입니다. 이런 문제는 두 사람이 각자 잘해도 사이에서 사라지고, 회의를 늘려도 잘 드러나지 않습니다.