핸드오프

시안을 개발에 넘기는 일은 오랫동안 파일을 보내는 일이었습니다. 문제는 시안에 그려져 있는 것이 언제나 잘 풀린 경우 한 장이라는 데 있었습니다. 문서가 열두 개 있는 목록은 그려져 있어도, 문서가 하나도 없는 목록은 그려져 있지 않습니다. 제목이 열다섯 자인 문서는 있어도 여든 자인 문서는 없습니다. 저장에 실패한 화면도, 권한이 없어 열지 못하는 화면도 없습니다.

그 화면들도 결국 누군가는 만들어야 합니다. 시안에 없으면 그 자리에서 만들고 있는 사람이 정하게 됩니다. 태오가 문서 목록을 구현하다가 빈 목록을 만나면, 물어보는 데 반나절이 걸리니 일단 아무것도 없는 화면으로 두고 넘어갑니다. 출시 뒤에 가입한 사람이 처음 보는 화면이 텅 빈 목록이었다는 사실은 한 달쯤 지나 지현이 이탈 수치를 들여다보다 알게 됩니다.

값을 옮기는 문제는 도구가 해결했습니다. 예전에는 디자이너가 여백과 글자 크기를 손으로 적어 넣었지만 지금은 피그마 같은 도구가 시안에서 값을 읽어 줍니다. 그런데 이 두 가지는 다른 문제였습니다. 값은 시안 안에 있고, 빠진 경우와 확정 여부는 시안 밖에 있습니다. 핸드오프가 파일을 보내는 행위가 아니라 하나의 과정으로 불리게 된 이유가 이것입니다. 도구가 채워 주지 않는 쪽을 사람이 채우는 자리입니다.

넘기기 전에 시안 위에서 할 일이 셋이고, 넘기는 자리에서 할 일이 둘입니다.

1. 확정 여부 표시 — 화면마다 정해진 것과 아직 아닌 것을 갈라 적습니다. "이 영역은 다음 주에 문구만 바뀝니다" 처럼 무엇이 언제 바뀌는지까지 적으면 개발자가 그 부분을 나중에 고치기 쉽게 만들어 둘 수 있습니다.
2. 예외 상황 채우기 — 잘 풀린 경우 말고 나머지를 그려 넣습니다. 목록이 비었을 때, 글자가 아주 길 때, 불러오는 중일 때, 요청이 실패했을 때, 권한이 없을 때가 기본 다섯입니다. 다섯 장을 더 그리는 데 반나절이 들고, 빠뜨리면 구현 중에 다섯 번 되묻거나 다섯 번 임의로 결정됩니다.
3. 값과 부품 연결 — 새로 그린 것과 이미 있는 부품을 구분해 표시합니다. 디자인 시스템에 있는 버튼을 썼다면 그 이름을 적고, 새로 만든 것이라면 왜 기존 것으로 안 되는지를 함께 적습니다. 간격과 크기를 숫자로 표시한 레드라인이 붙는 자리도 여기입니다.
4. 함께 훑기 — 파일을 보내고 끝내지 않고 30분 정도 같은 화면을 보며 훑습니다. 이 자리에서 나오는 질문의 대부분은 "이 경우엔 어떻게 됩니까" 입니다. 다섯 개쯤 나오면 성공한 자리이고, 하나도 안 나오면 아직 읽지 않았다는 뜻입니다.
5. 질문 창구 정하기 — 구현 중에 새로 생기는 질문을 어디에 올릴지 정해 둡니다. 구현은 시안이 예상하지 못한 것을 반드시 만나기 때문에, 이 창구가 없으면 그 질문들이 다시 각자의 판단으로 처리됩니다.

시안을 그린 디자이너와 그것을 실제로 구현할 개발자가 반드시 같이 있어야 합니다. 팀을 대표해 한 사람만 듣고 가는 방식은 잘 작동하지 않습니다. 넘겨받은 사람이 다시 옮기는 과정에서 예외 상황에 대한 이야기가 가장 먼저 떨어져 나갑니다. 무엇을 먼저 만들지와 무엇을 이번에 뺄지를 정하려면 기획도 그 자리에 있는 편이 낫습니다.

시점은 시안이 확정된 뒤이면서 개발 착수 며칠 전입니다. 확정 전에 열면 바뀔 화면을 두고 세부를 정하게 되고, 착수 당일에 열면 나온 질문을 반영할 시간이 없습니다. 일정을 추정하는 자리보다 먼저 여는 것이 특히 값이 큽니다. 예외 상황 다섯 장을 보고 나면 같은 작업의 추정이 이틀에서 나흘로 바뀌는 일이 흔한데, 그 차이는 원래 있던 일을 뒤늦게 발견한 것입니다.

자리를 만들기 어려우면 시간을 줄이되 없애지는 않습니다. 화면 두 장짜리 작업이라면 15분이면 충분하고, 그 15분에 나오는 질문 하나가 이틀을 아끼는 경우가 많습니다. 부품의 속성과 상태를 적은 컴포넌트 명세가 이미 갖춰진 팀은 이 자리가 더 짧아집니다. 매번 정하던 것이 한 번 정해져 있으면 넘길 때마다 확인할 것이 줄어들기 때문입니다.

"핸드오프 목요일에 잡을게요. 예외 케이스까지 정리해서 갈게요."

시안만이 아니라 빠진 경우까지 그려서 넘기겠다는 뜻입니다.

"이 부분은 아직 확정이 아니어서 나중에 바꾸기 쉽게 만들어 주세요."

이 영역은 바뀔 예정이니 구현 방식을 그에 맞춰 달라는 요청입니다.

"핸드오프 때 빈 상태 얘기가 없었는데 어떻게 할까요."

넘기는 자리에서 빠진 결정을 구현 중에 되묻는 말입니다.

페이지덱의 문서 공유 화면은 시안이 세 장이었는데 핸드오프에서 여덟 장이 됐습니다. 민서가 그려 간 것은 사람을 고르는 화면, 권한을 정하는 화면, 링크를 복사하는 화면이었습니다. 태오가 훑으면서 물은 것은 넷이었습니다. 초대할 사람이 이미 그 문서를 볼 수 있는 상태라면 목록에 어떻게 보이는지, 외부 도메인 주소를 넣었을 때 막을지 말지, 초대 메일이 실패하면 어떻게 알릴지, 권한을 내리는 사람이 자기 자신이면 어떻게 되는지였습니다.

네 가지 중 셋은 민서가 그날 오후에 그려서 채웠고, 마지막 하나는 지현이 이번 범위에서 빼기로 정했습니다. 대신 그 경우에 보여 줄 문구 한 줄을 정해 함께 넘겼습니다. 태오의 추정은 사흘에서 닷새로 늘었지만, 그 이틀은 새로 생긴 일이 아니라 원래 있던 일이었습니다.

핸드오프를 파일을 건네는 한 번의 동작으로 아는 경우가 가장 많습니다. 도구에 공유 링크를 만드는 버튼이 있으니 그것으로 끝난다고 여기기 쉽습니다. 실제로 넘어가야 하는 것은 화면이 아니라 결정입니다. 무엇이 확정이고 무엇이 아닌지, 그려지지 않은 경우에는 어떻게 되는지가 함께 가지 않으면 그 결정을 구현하는 사람이 혼자 내리게 되고, 그렇게 내려진 결정은 아무 데도 적히지 않아서 나중에 누구도 이유를 설명하지 못합니다.

도구가 좋아졌으니 이 과정이 필요 없다는 오해도 같은 자리에서 나옵니다. 값을 자동으로 읽어 주고 코드 조각까지 뽑아 주니 사람이 할 일이 사라진 것처럼 보입니다. 도구가 답해 주는 것은 그려진 것에 대한 질문뿐입니다. 그려지지 않은 화면에 대해서는 도구도 아무 말을 하지 않고, 실제로 시간을 잡아먹는 질문은 대부분 그쪽에 있습니다.