디자인 핸드-오프에 관해
3월 3주차 업무일지
과거 프렙 팀과 창업할 때 좋은 제품을 더 빠르게 만드는 프로세스에 대해 자주 생각했다. 당시 일을 하다가 불현듯 깨달은 것이 있었는데, 아무것도 정리를 하지 않으면서 일한다는 것이었다. 말하자면, 일을 잘하는 것처럼 보이게 만드는 잘 관리된 피그마 파일, 모든 스펙과 일정을 합의하는 킥오프 미팅은 없었다.
규모가 있는 팀에서 일을 할 때 가장 신경 쓰이는 미팅 중 하나가 킥오프 미팅이였다. 보통 프로젝트의 시작에서 ‘이번 프로젝트는 이런저런 배경에서 시작되었고요, 이런 일을 할 거예요’라는 개요 전달을 목적으로 하거나, 기획과 디자인이 다 끝났을 때 ‘이번 업데이트 스펙은 이렇습니다, 요런 거 주의해서 개발하면 될 것 같고요, 일정은 이렇게 가시죠!’라는 작업물 전달 및 일정 조율을 하는 목적으로 킥오프를 진행한다.
하지만 프렙에서는 킥오프가 없었다. 규모의 문제는 아니다. 작은 팀이라고 시작을 알리는 신호탄이 필요 없는 것은 아니다. 하다못해 두 명이라도 필요할 수도 있다. 우리가 킥오프 미팅이 필요 없었던 이유는 완성된 악보를 치는 것이 아니라 즉흥적으로 이어가는 재즈팀이 되어 제품을 만들었기 때문이다. 당시 상황을 그대로 옮기자면 이렇다.
크게 정해놓은 일정과 산출물 내에서 디자인을 계속 진행한다. 예를 들면 이번 주까지 문제 풀이 기능을 모두 만든다는 식이다.
어떤 세부 페이지까지 개발되고 있는지는 크게 신경 쓰지 않는다. 개발자가 알아서 할 일이다.
그럼, 보통 디자인을 하는 족족 개발이 계속 따라온다. 어느 순간 디자인을 하는 동시에 개발이 되고 있다. 심지어 어느 화면은 디자인은 없이 기능 구현만 먼저 개발되어 있는 경우도 있다.
그것을 어떻게 아냐면, 3시간에 한 번씩 테스트 앱이 빌드되어서 바로바로 확인할 수 있기 때문이다.
실제로 구현이 돌아가는 것을 보니까 어딘가 석연찮다. 이렇게 바꾸면 더 좋을 것 같다. 그럼, 디자인도 바꾸고 개발도 바꾼다.
개발자가 보니까 과도하게 개발 시간을 잡아먹는 화면 구조가 있다. 그걸 디자이너한테 말한다. 그럼 같이 더 나은 방법을 찾는다. 또 디자인도 바꾼다.
개발자가 화면 전환 인터랙션이 있으면 좋겠다고 생각해 그렇게 개발한다. 디자이너가 (3시간 후 빌드된 앱으로) 보니까 구현된 방식이 꽤 괜찮은 것 같아서 그 효과를 더 강조할 수 있도록 전환 이전 페이지의 디자인을 또 조금 바꾼다. 개발도 수정한다.
계속 이런 식이었다. 개발과 디자인 모두 계속 끝나지 않는 수정의 싸움이었다. 이건 이전에 어떤 팀에서도 생각해 본 적 없는 일이었다. 그전까지 내가 경험했던 대부분의 프로세스에서는 디자인 번복으로 개발을 다시 해야 하는 것에 엔지니어가 흔쾌히 인심을 써주거나, 아니면 인상을 찡그리며 거부하는 식이었다. 개발 중인 중간 산출은 거의 마감일 가까운 시점, 즉 QA가 시작될 때 볼 수 있었다. 이걸 빨리 보여달라고 하면 엔지니어 팀을 ‘쪼는’ 나쁜 디자이너가 되기도 한다.
그와 정반대였던, 그때 우리 팀이 일하는 방식은 너무 재밌었고, 빨랐다. 디자이너로써 이미 개발된 것이라도 더 좋은 디자인이 있다면 새로 제안하는 것에 거리낌이 없었고, 깔끔하게 모든 Status와 Edge case가 정리된 가이드 파일은 불필요했다. 대신 작동되는 화면과 핵심 디자인에만 집중할 수 있었다. 개발자는 디자인에 어떤 조심성도 없이 더 나은 디자인을 이야기할 수 있었고, 매끄럽게 작동하는 UI가 되도록 디자이너와 끊임없이 협업했다.
당시 위 프로세스를 경험하며 내 저널에 아래와 같이 적었다.
이건 너무 이상적인 얘기고 나도 짧게만 경험해 본 방식이라 내가 다른 회사에서 일할 때도 이렇게 할 수 있을지, 그 상황에서도 이게 맞을지는 확신은 없다. 하지만 언젠간 꼭 이런 방식으로 다시 일해보고 싶다.
요즘 이 생각을 다시 들춰본 것은 위와 같은 흐름이 실제로 일어나는 조짐을 발견했기 때문이다. Dive Club의 11분짜리 영상 “Design “handoff” is changing forever”에서는 여러 제품 팀의 디자이너와 엔지니어가 내게 가장 최고의 경험이었던, 프렙 팀의 제품 개발 방식을 동일하게 Vercel, Spotify, Airbnb, Anthropic, Perplexity에서 실행하고 있다고 증언한다.
그들은 “누군가 디자인을 할 때, 저는 ‘A가 낫다, B가 낫다’라고 말하기보다는 ‘좋아요, 둘 다 만들어서 배포 링크를 보내주세요. 둘 다 사용해 보고 하나는 버릴 거예요. 괜찮아요. 그게 좋은 결과물을 만들기 위한 비용이죠.’”라고 말하며
이렇게 제품을 만들어갈 때 “애초에 디자인을 더 잘했어야 한다고 말하지 않고, 디자이너들은 성능상의 이유로 디자인을 변경해야 할 때 불만을 느끼지 않으며, 디자인과 엔지니어링은 서로 깊이 존중”하게 된다고 말한다.
그 결과 “재능 있는 시각 디자이너와 재능 있는 UI 엔지니어를 함께 그들이 서로의 수준을 높이는, 매우 높은 수준의 동기 부여가 되고 마법”이 일어나는데, 그 마법이 일어나는지 일어나지 않는지는 얼마나 많은 코드가 버려지는지로 알 수 있다고 한다. 어떤 것이 더 나은지 찾아가는 탐색적 코드의 양은 디자이너와 엔지니어가 협업이 늘어날수록 더 늘어나기 때문이다.
디자이너는 빈틈없는 플로우 설계, Edge case의 나열, 1-2px 실수로 옮겨지지 않았는지 확인하는 데에 시간을 덜 쓰고, 작동하는 프로토타입을 보며 좋은 디자인을 한 번 더 고민하는 데 시간을 써야 한다. 엔지니어는 깨알같이 적힌 핸드오프를 읽고 이해하는데 시간을 쓰기보다 해결하려는 문제를 이해하고 작동하는 모습을 보며 한 번이라도 더 써보고 UT를 해보는 기회를 만드는 것에 시간을 써야 한다. 이런 관점에서 보면 킥오프 미팅 자체가 협업이 높은 수준으로 일어나지 않는다는 증거다. 킥오프는 ‘이제 솔루션은 확정되었고, 이대로 똑같이 개발을 시작합니다!’ 라고 보고서를 전달하는 세레모니다.
디자인, 개발을 잘해 보이는 것과 실제로 좋은 제품을 만드는 것은 다르다고 생각한다. 모든 것이 문서화되어있으면 좋겠다고 항상 이야기하지만, 실제로 좋은 제품을 만드는 것은 잘 정리된 문서의 양보단 버려지는 디자인 시안의 양과 코드의 양일지도 모른다.