Design
디자인 시스템 이전으로 돌아가실래요? (1)
여기어때 UX Center여기어때
2025년 1월 17일
원문에서 보기 ↗글. 김지영(Terna) / Platform Design Team Lead
부제. 디자인 시스템 운영의 명암
디자인 시스템이 없던 시절로 돌아간다고 생각해보세요. 그때는 대체 어떻게 그 많은 반복 작업을 해냈을까요? 가끔 피그마 라이브러리가 사라지는 상상을 하면 정말 아찔해지곤 해요. 그만큼 지금은 디자인 시스템이 없어서는 안 될 존재가 됐죠. 요즘은 대부분의 서비스가 일관성과 효율성을 위해 디자인 시스템을 구축하고 운영하고 있는데, 여기어때 역시 ‘YDS(Yeogi Design System)’라는 이름으로 자체 디자인 시스템을 운영하고 있어요.
저는 23년 하반기부터 YDS를 맡아 운영하게 되었는데요, 그 과정에서 새로운 비효율을 마주하게 됐고, 이를 개선하기 위해 다양한 시도를 하게 되었어요. 이번 글에서는 비효율을 발견했던 과정과, 그걸 개선해나간 경험을 나눠보려 합니다.
디자인 시스템 = 새로운 프로덕트
제가 YDS 업무를 맡았을 때, 여기어때는 이미 앱 내 UI 패턴을 기반으로 한 피그마 라이브러리가 있었고, 본격적으로 컴포넌트도 개발 중이었어요.
완전한 무에서 시작하는 건 아니어서 다행이었지만, 애매한 시점에 인볼브된 것 같다는 생각이 들더라고요. 단순히 개발 대응을 넘어 YDS에 어떤 기여를 할 수 있을지 고민이 많았죠.
지금 돌아보면 그런 고민이 생긴 이유는 제가 디자인 시스템을 그저 구조적이고 일관된 UI 라이브러리로만 봤기 때문인 것 같아요. ‘컴포넌트를 잘 만들면 당연히 잘 쓰이겠지’라고 단순하게 생각했던 거죠. 물론, 그게 디자인 시스템에 핵심인 건 맞지만, 한 달 동안 초심자의 마음으로 기존 가이드랑 컴포넌트를 뜯어보고, UX Designer와 개발자의 문의에 대응하면서 그게 전부는 아니라는 걸 깨달았어요.
컴포넌트를 잘 만들어도 효율적으로 쓰이는 것은 완전히 다른 문제더라구요. 결국, 초기 라이브러리 구축 이후의 디자인 시스템은 단순히 리소스를 모아놓은 게 아니라 하나의 새로운 프로덕트가 된다는 결론에 다다르게 됐어요.
효율 속의 비효율
효율성을 높이고자 만든 디자인 시스템인데 정작 운영하는 과정에 많은 비효율이 존재했는데요. 그 중에서도 당장 해결이 필요하다 느껴지는 부분은 크게 네 가지였어요.
1. 버전 추적의 어려움
당시 피그마 라이브러리는 계속 업데이트되고 있었지만, 개발은 버전 단위로 업데이트되는게 아니라 필요한 컴포넌트를 그때그때 피처 단위로 개발하는 방식이었어요. 문제는 이렇게 하다 보니 실제 개발된 컴포넌트가 피그마 라이브러리의 어떤 버전에 해당하는지 알 수 있는 방법이 없었어요.
그렇다 보니 피그마 라이브러리를 수정할 때마다 개발팀에 넘겨야할 체인지로그를 정리하기가 애매했어요. 일부 스펙이 누락되거나 피그마와 싱크가 안 맞아도 바로 앱에 적용되지 않으니 쉽게 드러나지 않았고요. 개발이 완료됐다는 상태값은 있었지만, 그걸 보고도 이 컴포넌트가 정말 제대로 만들어졌는지 퀄리티를 보장할 수 없는 상황이었죠.
2. A/B 테스트와 실험 UI 관리의 문제
A/B 테스트로 프로덕트를 고도화하는 조직 특성상, 실험안을 만들 때 피그마 컴포넌트를 디태치하거나 새로운 UI 패턴을 만드는 일이 종종 있었어요. 모든 걸 YDS에 반영하려다 보니, Winner가 되지 못한 컴포넌트들의 사후 처리가 제대로 이루어지지 않았죠.
게다가 디자인 시스템이 1.5명의 리소스로 운영되다 보니, 여러 프로젝트가 동시에 몰리면 그 속도를 따라가기 힘들었고, 결국 실제 앱과 디자인 시스템의 간의 간극은 좀처럼 좁혀지지 않았어요.
3. 리소스 부족과 이슈 처리 프로세스 부재
앞서 말한 문제에서 파생된 또 다른 문제는, 시스템 디자이너가 1.5명의 리소스로 운영되고 있다는 점과 고정된 개발 담당자 없이 프로젝트마다 필요한 컴포넌트만 개발하는 구조였다는 거예요. 이러다 보니 시스템 디자이너와 개발자 간의 공통된 정의를 내리거나 장기적으로 시스템을 함께 고민하고 소통하기 어려웠죠.
부족한 리소스로 이슈가 발생할 때마다 빠르게 대응하려다 보니, 피그마 코멘트나 슬랙에서만 처리하고 지라 티켓으로 리포트하지 않아서 이게 단순 버그인지 심각한 문제인지, 일관성을 지켜야 하는 문제인지 아니면 유연하게 대처할 문제인지를 판단하기 어려웠어요. 당연히 히스토리를 추적하는 것도 힘들었죠.
4. Usage, Content 가이드라인 부족
다수의 디자이너가 컴포넌트를 사용하면서 디자인 시스템 슬랙 채널로 사용이나 추가 케이스에 대한 문의가 끊임없이 들어왔어요. 그러다 보니 하루 대부분의 시간을 문의 대응에 쓰게 됐고, 정작 디자인 시스템을 고도화할 시간이 부족했죠.
돌이켜보니 이건 결국 시스템 내 사용 가이드라인 부족에서 비롯된 문제였어요. Usage 가이드가 충분하지 않아서 사소한 사용법도 문의로 이어졌고, 컴포넌트를 사용할 때 지켜야 하는 Content 가이드도 컴포넌트별로 세분화되지 않아 혼란을 주었어요. 게다가 Content 가이드를 피그마가 아닌 컨플루언스에서 따로 확인해야 하다 보니, 번거로움이 더해졌죠.
1~4번 문제들은 디자인 시스템 안에서 비효율을 조금씩 쌓아갔고, 저뿐만 아니라 컴포넌트를 쓰는 사람들한테도 디자인 시스템이 도움이 되기보다는 불편한 족쇄처럼 느껴지게 만들었어요.
이 문제들을 해결해보려고 함께 디자인 시스템 업무를 진행하는 픽시(Platform Designer), 제티(UX Writer)와 다양한 시도를 해봤는데요. 우리가 설정한 목표는 한정된 시간 안에 디자인 시스템을 고도화하면서 이슈도 잘 처리할 수 있는 프로세스를 만드는 거였어요. 또한 한 두 사람만 고군분투하는 게 아니라, 더 많은 사람들이 자연스럽게 시스템에 관심을 가질 수 있는 문화를 만드는 것도 큰 숙제였죠.
이번 글에서는 디자인 시스템 운영에서 마주한 비효율과 그로 인한 고민들을 나눠보았는데요. 다음 편에서는 이러한 문제들을 어떻게 해결했는지, 더 나은 시스템을 구축하기 위해 시도한 과정을 자세히 공유해볼게요.
✔️ 글쓴이를 더 알고 싶다면? 링크드인
편집: 이소연(Jetty) UX Writer
그래픽: 김제린(Riny) Visual Interaction Designer
*해당 글과 이미지를 인용 또는 재가공 시 출처를 꼭 밝혀주세요.
관련 글