배경과 문제

서비스가 빠르게 늘어나면 화면도 빠르게 늘어납니다. 투표, 티켓팅, 라이브, 굿즈처럼 성격이 다른 서비스를 동시에 만들다 보면 각자 필요한 버튼과 카드, 입력창을 그때그때 만들게 됩니다. 처음에는 작은 차이였지만 시간이 지나자 같은 역할을 하는 버튼이 화면마다 다른 크기와 모서리, 색을 갖게 되었습니다.

이 차이는 팬에게는 서비스가 하나로 느껴지지 않는 경험으로, 팀에게는 같은 것을 여러 번 만드는 비용으로 돌아왔습니다. 디자이너는 어떤 버튼을 써야 할지 매번 찾아야 했고, 개발 쪽에서도 비슷한 코드가 여러 벌 생겼습니다.

우리는 이 작업의 목표를 “새로 만들기 전에, 이미 있는 것을 먼저 찾을 수 있게 하기”로 정했습니다.

과정

1. 모두 꺼내 놓기

가장 먼저 한 일은 실제 서비스 화면에서 컴포넌트를 모두 수집하는 것이었습니다. 버튼, 카드, 탭, 입력창처럼 종류별로 한자리에 모아 놓고 보니, 비슷하지만 미묘하게 다른 것들이 생각보다 많았습니다. 이 과정을 거치며 팀 모두가 문제의 크기를 같은 눈으로 볼 수 있었습니다.

2. 역할로 묶고, 차이는 이유를 묻기

모은 컴포넌트를 모양이 아니라 역할로 묶었습니다. “가장 중요한 행동을 이끄는 버튼”, “보조 행동 버튼”처럼 역할을 먼저 정하고, 그 안에서 생긴 차이마다 “꼭 달라야 하는 이유가 있는가”를 물었습니다. 이유가 있는 차이는 변형으로 남기고, 이유가 없는 차이는 하나로 합쳤습니다.

3. 쓰는 사람을 위한 문서

컴포넌트를 정리하는 것만큼 중요한 것이 쓰는 방법을 알리는 일이었습니다. 각 컴포넌트에 언제 쓰는지, 언제 쓰지 않는지, 상태별 모습은 어떤지를 함께 적었습니다. 디자이너와 개발자가 같은 이름으로 부를 수 있도록 이름 규칙도 맞췄습니다.

4. 한 번에 바꾸지 않기

모든 화면을 한꺼번에 새 컴포넌트로 바꾸는 것은 현실적이지 않았습니다. 서비스는 계속 운영되고 있었고, 새로운 기능도 쉬지 않고 만들어지고 있었기 때문입니다. 우리는 새로 만드는 화면부터 정리된 컴포넌트를 쓰고, 기존 화면은 고칠 일이 생길 때 함께 바꾸는 방식으로 순서를 정했습니다. 어떤 컴포넌트가 어디까지 바뀌었는지 팀 모두가 볼 수 있도록 진행 상황을 한곳에 기록해, 같은 화면에서 옛 버튼과 새 버튼이 섞이는 일을 줄였습니다.

결과

정리된 컴포넌트는 으로 모였습니다. 새 화면을 만들 때 기존 컴포넌트를 먼저 찾아보는 흐름이 자리 잡기 시작했고, 서비스 간 인상도 한층 일관되게 정리되었습니다.

배운 점

디자인 시스템은 한 번에 완성되는 결과물이 아니라 계속 돌보는 습관에 가깝다는 것을 배웠습니다. 정리보다 어려운 것은 정리된 상태를 유지하는 일이었고, 그래서 새 컴포넌트를 추가하는 기준과 절차를 함께 정하는 것이 중요했습니다. 무엇보다 시스템은 쓰는 사람이 편해야 살아남는다는 점을 잊지 않으려 합니다. 다음에는 모션과 접근성 기준까지 시스템 안으로 들여오려고 합니다.