디자인 시스템 이전으로 돌아가실래요?
지난 글에서는 디자인 시스템 운영 과정에서 겪은 비효율과 그로 인해 생긴 고민들을 공유드렸는데요. 혹시 공감되거나 비슷한 경험이 떠오르셨나요? 이번 글에서는 그 문제들을 어떻게 해결했는지, 더 나은 시스템을 구축하기 위해 어떤 시도와 개선을 이뤄냈는지 자세히 소개해드릴게요.
1. 버전 추적의 어려움을 어떻게 해결했을까?
① 명확한 업데이트 규칙과 버전 관리
많은 컴포넌트를 앱에 반영하는 것도 중요했지만, 그보다 더 중요한 건 확실하게 검증된 컴포넌트를 만드는 거였어요. 그래야 디자인 라이브러리를 넘어, YDS 컴포넌트는 기능적으로도, 심미적으로도 믿을 수 있다는 신뢰를 쌓을 수 있다고 생각했죠.
그래서 먼저 버전 업데이트의 규칙을 새롭게 정의했어요. 체인지로그는 코드 레벨에서 변경점이 있는지를 기준으로 상태값을 명확히 정의해서 작성했구요. 이 체인지로그와 함께 해당 버전의 스펙을 확인할 수 있는 피그마 브랜치 링크를 앱 개발팀에 전달했어요. 프로젝트와 분리된 지라 티켓으로 요청해 시스템 개발이 버전 단위로 진행되도록 했죠.
배포 일정이 정해지면 UX Owner분들께 공지해서, 작업 중인 피그마 파일에서 라이브러리 업데이트를 받을 시점을 조율할 수 있도록 했어요. 이렇게 프로세스를 정리하면서 업데이트 흐름을 명확하게 알 수 있게 했고, 개발과 시스템 디자인 간의 연결을 더 견고하게 만들게 되었어요.
② YDS 컴포넌트 검수용 샘플앱
앱에 아직 적용되지 않은 컴포넌트를 포함해 기존 컴포넌트의 검수가 절실했는데요, 이 부분은 앱개발팀이 먼저 적극적으로 방법을 제안해 주셔서 검수 전용 샘플앱(YDS Stage)을 구축하게 되었어요. 피그마 라이브러리 버전이 업데이트되면, 개발이 진행되는 동안 샘플앱 가이드를 작업하고, 이후 샘플앱 업데이트를 요청드리는 방식으로 검수를 이어가고 있어요. 상용 앱에서는 확인하기 어려운 상태값까지 포함해 Variants 단위로 꼼꼼히 검수가 가능해졌죠.
검수가 가능하다는 건 시스템 디자이너 입장에서 정말 큰 의미가 있었어요. 내가 검증한 컴포넌트를 개발자와 UX Owner가 실제로 활용할 거라는 확신이 생기니, 작업에 대한 불안감도 크게 줄어들었거든요. 더불어 샘플앱은 시간이 지날수록 그 중요성이 커질 거라고 생각해요. 앱 내 적용되는 컴포넌트 비율이 늘어날수록, 컴포넌트 변경이 앱 전반에 미치는 영향도 커지기 때문에 검수 과정은 더욱 민감한 사안이 될 거예요. 결국 샘플앱이 시스템의 신뢰를 유지하고, 변경의 리스크를 줄이는 데 필수적인 도구로 자리 잡을 거라고 생각해요.
2. A/B 테스트와 실험 UI 관리의 문제은 어떻게 해결했을까?
사후 대응과 위닝 패턴 수집
업데이트와 버전 관리 규칙이 생긴 덕분에 덕분에 디자인 시스템이 프로젝트 일정에 휘둘리던 문제는 어느 정도 해결됐어요. 시스템 자체를 고도화할 프로세스도 정립되었고요. 그런데 여전히 전체 컴포넌트가 개발되지 않았고, 앱에 충분히 반영되지 않은 상태라, 각 프로젝트에서 A 컴포넌트를 사용하려고 해도 그 컴포넌트를 당장 쓸 수 있는지 확실하지 않았어요. 게다가 실험 UI에 대한 대응도 여전히 모호했죠.
이 문제를 해결하기 위해 앱개발팀과 논의했는데, 실험 후 위너가 결정되면 코드를 정리하는 과정이 기존에 이미 진행되고 있다는 점에 주목했어요. 그래서 이 과정을 디자인 시스템 개선에 활용하기로 했죠. 프로젝트 개발 단계에서는 미개발된 YDS 컴포넌트나 실험 UI를 로컬 컴포넌트로 작업한 뒤, 실험 결과가 나온 후 코드를 정리하면서 YDS 컴포넌트로 교체하는 방식을 택했어요.
이렇게 모든 것을 사전에 대응하기보다는 사후 대응으로 전환하니, 위너가 되지 못한 컴포넌트가 불필요하게 YDS에 편입될 가능성을 줄일 수 있었어요. 게다가 실험 UI가 위닝 패턴으로 확인된 경우에는 이를 단순히 YDS에 추가만 하는 것이 아니라, 시스템 관점에서 한 번 더 검토하고 필요한 개선을 반영해 편입했어요. 덕분에, YDS에 포함되는 컴포넌트는 더 검증되고 단단한 형태로 발전할 수 있었죠.
결과적으로, 모든 컴포넌트가 완성되기 전까지도 시스템은 시스템대로 고도화를 이어갈 수 있었고, 프로젝트를 진행하는 데 있어 시스템이 허들이 되지 않도록 조율할 수 있었어요.
3. 리소스 부족과 이슈 처리 프로세스 부재는 어떻게 해결했을까?
이슈 대응 프로세스 정립
디자인 시스템 채널로 들어오는 이슈는 매우 다양했어요. 크게 보면 당장 해결이 필요한 버그와 그렇지 않은 문제들로 나뉘었죠. 후자의 경우, 앱 내 다양한 화면에서 적합성을 검토해야 하거나, 컴포넌트의 속성(property) 구조를 재설계해야하는 등 시간이 필요한 작업이 많았어요. 또한, 새로운 컴포넌트 추가 요청이 들어오면 그것이 특정 프로젝트에 국한된 건지, 앱 전반에서 활용 가능한 패턴인지 판단이 필요했죠.
이런 문제들을 체계적으로 관리하기 위해, 이슈 유형에 따라 처리 주기와 방식을 정리한 프로세스를 만들고, 이를 UX 디자이너와 개발자분들에게 공유했어요. 이후 디자인 시스템 채널로 들어오는 이슈는 모두 지라 티켓으로 기록했죠.
단순히 기록화 하는 데 그치지 않고, 티켓화된 이슈를 처리하기 위해 주 1회 YDS 트리아지(Triage)라는 회의를 운영했어요. 이 회의의 목적은 시스템 수정이나 추가 요청이 들어왔을 때, 모든 요청을 무조건 수용하지 않으면서도, 시스템 디자이너 단 한 사람의 판단만으로 “됩니다” 혹은 “안됩니다”를 결정하지 않는 데 있었죠.
트리아지에서는 시스템 디자이너와 UX Center 리더십이 함께 모여, 이슈의 성격과 우선순위를 검토했어요. 예를 들어, 어떤 이슈는 UX Owner가 시스템 가이드에 맞춰 해결해야 하는 문제라고 판단되기도 하고, 또 어떤 이슈는 시스템이 수정되거나 새로운 패턴을 추가해야 할 문제로 결정되기도 했어요. 이런 과정을 통해 이슈별로 누가, 언제, 어떻게 대응해야 할지 명확히 정의했죠.
이렇게 선정된 우선순위에 따라 버그 수정이나 개발 대응은 빠르게 마이너 업데이트로 처리했고, 컴포넌트 추가나 구조 변경 같은 주요 변경 사항은 분기별 메이저 업데이트로 진행했어요.
이슈를 티켓화하고, 각 이슈에 대한 논의와 결과를 차곡차곡 기록하다 보니, 유사한 이슈가 다시 발생해도 이전의 논의와 판단 과정을 쉽게 추적할 수 있어 문제 해결이 훨씬 수월해졌어요.
4. 부족했던 Usage, Content 가이드라인은 어떻게 해결했을까?
사전 공유와 가이드 접근성 향상
Usage 가이드와 Content 가이드는 언뜻 스펙 가이드보다 덜 중요해 보일 수 있지만, 사용자가 늘어나며 시스템 일관성을 유지하는 데 필수적이에요. 가이드가 없을 경우 발생하는 오해와 일관성 문제를 해결하기 위해 체계적인 정리가 필요했죠.
이러한 필요에 따라, 기존에 컨플루언스에 분산되어 있던 Content 가이드를 UX Writer인 제티와 협업해 디자인 시스템 피그마로 통합했어요. Usage 가이드 역시 현재 앱 내에서 컴포넌트가 사용되고 있는 화면을 나열하고, 대표적인 사용 패턴을 정리하면서 컴포넌트별로 축적하기 시작했어요.
하지만 피그마라는 디자인 툴은 본질적으로 다량의 텍스트를 담거나 탐색하기에 한계가 있었어요. 그래서 처음에는 가이드를 웹으로 퍼블리싱하려는 계획을 세웠죠. 하지만 시스템 업데이트 작업을 진행하면서 이 작업까지 병행하는 것이 쉽지 않았어요. 결국 현실적인 대안으로, 피그마에서 작업한 가이드를 웹으로 이전할 초안이라고 생각하며 양식을 개편했습니다. Usage, Spec, Content를 명확히 분리했고, 프로토타이핑 기능을 활용해 가이드 내에서 앵커링을 통해 원하는 내용을 바로 확인할 수 있게 했어요.
그럼에도 불구하고 피그마라는 툴의 한계는 여전히 존재하죠. 아무리 잘 정리된 가이드라도 바쁘게 돌아가는 프로젝트 속에서 사용자가 이를 일일이 확인하기란 쉽지 않았어요. 그래서 메이저 업데이트 시에는 UX와 개발팀을 대상으로 반드시 사전 공유를 진행했습니다. 이 자리를 통해 업데이트로 인해 변경되는 스펙, Usage 가이드, Content 가이드를 간략히 요약해 설명하며 팀 간의 이해도를 높이고, 가이드 적용을 원활하게 하는 데 집중했어요.
