당근 SEED V3를 읽고 남긴 메모 넷: 영향도 추적엔 박수, 열어 둔 컴포넌트엔 조건

"솔직히 고백하자면 V3 이전의 디자인 시스템에는 큰 약점이 하나 있었습니다. 바로 고치기 두려웠다는 것이에요." 당근 디자인 시스템 SEED의 V3 개편기는 새 색상 체계와 아이콘과 타이포그래피로 시작하지만, 제가 이 글에서 가장 오래 붙잡은 건 Part 2 첫머리의 이 고백이었습니다. 디자인 시스템 개편기를 여러 편 읽었지만, 시스템이 무서워서 못 고쳤다고 이렇게 정면으로 쓴 글은 드뭅니다.

글은 길고 다루는 것도 많습니다. 2021년 6월 '지원 라이브러리 모음'에서 출발해 스타일 모음이던 V1, Foundation과 Component를 갖췄지만 토큰이 뒤섞이고 명도 대비를 보장하지 못하던 V2를 거쳐, 접근성을 바탕으로 다시 세운 V3까지. 그중 네 가지만 골라 메모를 남깁니다. 둘은 그대로 가져갈 만하고, 하나는 조건을 달아 읽어야 하고, 하나는 앞으로 다시 따져 봐야 할 지점입니다.

하나, '고치기 두려웠다'와 토큰 영향도 추적

V3 이전의 SEED에는 동기화 장치가 있었지만 토큰의 영향도를 추적할 수 없었습니다. 토큰 하나를 바꾸면 어느 컴포넌트와 어느 서비스까지 번지는지 모르니 업데이트는 늘 조심스러웠고, 컴포넌트 사양은 손으로 고쳐야 했고, iOS와 Android와 Web 구현을 따로 확인하느라 지연과 불일치가 생겼습니다. 팀마다 반영 시기도 달랐고요. 그래서 V3의 구조적 방향은 무엇을 더 넣을까가 아니라 왜 우리는 시스템을 자신 있게 고치지 못하는가라는 질문에서 출발했습니다.

지금은 모든 디자인 토큰마다 그 토큰을 쓰는 다른 토큰과 컴포넌트를 추적할 수 있고, 어느 서비스까지 영향을 주는지도 파악해 가고 있습니다. 화면을 보면 $color.palette.static-white 하나에 대해 라이트와 다크 테마의 정의, 그리고 그 값을 참조하는 action-button의 레이블·아이콘 색 같은 목록이 이어집니다. 그 위에서 컴포넌트 디자인을 고치면 문서와 각 플랫폼 구현이 함께 동기화되고, 구조 변경이 없는 한 변경이 모든 플랫폼에 동시에 퍼집니다.

이 추적이 가능한 건 V3에서 디자인 결정을 한곳에서 관리해 모든 플랫폼으로 흘려보내는 Rootage라는 기반을 먼저 깔았기 때문입니다. 결정의 원본이 하나여야 그 원본에서 뻗어 나간 가지를 셀 수 있습니다. 원본이 Figma 파일과 iOS 코드와 Android 코드에 셋으로 흩어져 있으면, 영향도 추적은 세 군데를 따로 뒤지는 일이 되고 결국 아무도 하지 않게 됩니다. Foundation·Component·Spec·React 문서를 한곳에 모은 Docs와 플랫폼마다 정기적으로 배포하는 카탈로그 앱도 같은 원본을 다른 창으로 보여 주는 장치라고 읽었습니다.

제가 이걸 첫째로 고른 이유는 개발자로서 익숙한 문제라서입니다. 코드베이스가 썩는 가장 흔한 이유도 고치기 무서워서입니다. 테스트가 없고 의존 관계가 안 보이면 아무도 손대지 않고, 손대지 않은 코드 위에 우회로가 쌓입니다. 디자인 시스템도 똑같습니다. 고치기 무서운 토큰은 그대로 남고, 각 팀은 시스템을 피해 자기 색을 만들고, 시스템과 제품 사이의 간극이 벌어집니다. SEED 팀이 '고치기 싫은 시스템'에서 '계속 고쳐도 괜찮은 시스템'으로 바뀌었다고 쓴 건, 컴포넌트를 몇 개 늘렸다는 말보다 훨씬 큰 성취라고 봅니다. 디자인 시스템을 운영하는 팀이라면 새 컴포넌트보다 이 참조 목록부터 만드는 게 맞다고 생각합니다.

둘, 터치 영역을 스펙에 적는다는 것

이번 개편에서 가장 깊이 다룬 주제는 접근성이었습니다. 그동안 여유가 되면 챙기던 것을, WCAG와 APCA 같은 업계 표준을 처음부터 기준으로 삼는 쪽으로 바꿨습니다. 색은 전경(fg), 배경(bg), 외곽선(stroke)으로 역할을 나누고 일관된 이름을 붙여, 조합만 지키면 충분한 명도 대비가 보장되게 했습니다. 모든 색이 같은 단계에서 같은 시각적 대비를 갖도록 톤을 맞춘 덕분에, 서비스팀이 자기 컴포넌트의 variant를 만들 때도 같은 단계에서 톤만 바꾸면 되게 됐고요.

그런데 제가 고른 건 색이 아니라 터치 영역입니다. SEED 팀은 터치 영역(targetSize)을 Figma 가이드에도, 모든 구현이 공유하는 스펙에도 적었습니다. 어느 개발자가 어느 플랫폼에 구현하든 같은 의도가 보장되도록요. 접근성 지침을 문서 끝의 권고로 두면 바쁜 일정에서 가장 먼저 빠집니다. 구현자가 읽는 스펙의 한 필드로 들어가면 빠뜨리는 쪽이 오히려 눈에 띕니다. '잘 챙기자'를 '누구나 확인할 수 있는 값'으로 바꾸는 방법은 결국 그 값을 구현이 읽는 자리에 두는 것이고, 이건 접근성뿐 아니라 시스템이 지키고 싶은 모든 원칙에 쓸 수 있는 방법이라고 봅니다.

PC에서 당근을 쓰는 경우가 늘면서 키보드 탐색을 위한 focus 상태를 더했고, 누를 수 있는 요소가 살짝 줄었다 돌아오는 눌림 피드백도 넣고 있다는 대목도 같은 맥락입니다. 모바일 앱 출신 시스템이 웹과 보조기기 사용자를 기본값으로 받아들이는 과정이죠.

셋, 프로필 화면의 44%는 무엇을 증명하나

새 기준을 처음 입힌 화면은 프로필이었습니다. 색의 역할이 흐려 무엇이 중요한지 한눈에 안 들어오고, 텍스트 위계가 흐릿하고, 터치 영역과 명도 대비가 화면마다 제각각이던 곳에 V3를 그대로 적용했습니다. 결과는 프로필에서 다른 이웃을 모아보기하는 수가 약 44% 늘고, 화면 체류 시간이 Android 68%, iOS 83% 늘었다는 것.

첫 화면을 하나 정해 V3를 끝까지 입혀 본 선택 자체는 좋다고 봅니다. SEED 팀은 V3와 V2가 한 화면에 뒤섞이면 관리가 어렵다는 이유로 한 번에 갈아타지 않고, 색·타이포·아이콘 같은 Foundation부터 자리 잡게 한 뒤 컴포넌트를 차근차근 가져다 쓰게 했습니다. Figma 디자인 키트를 배포하고 전사에 소개하고 팀별 온보딩을 거쳤고요. 이런 점진 전환에서는 모든 화면이 반쯤 바뀐 상태가 가장 위험한데, 완전히 바뀐 화면 하나를 먼저 보여 주면 나머지 팀이 따라갈 목표 그림이 생깁니다.

숫자 쪽은 조건을 달아 읽겠습니다. 이건 화면 하나를 다시 설계한 성과이지, 디자인 시스템의 성과를 따로 떼어 잰 값은 아닙니다. 위계를 다시 잡고 정보의 우선순위를 바꾸는 일은 시스템 없이도 좋은 디자이너가 할 수 있는 일이고, 어디까지가 토큰과 컴포넌트 덕인지는 이 숫자로 가를 수 없습니다. 체류 시간도 양면적인 지표입니다. 더 머물렀다는 건 더 흥미로웠다는 뜻일 수도, 찾는 데 더 오래 걸렸다는 뜻일 수도 있으니까요. 모아보기 수가 함께 늘었으니 앞쪽일 가능성이 크지만, 체류 시간만 따로 내세우기엔 약합니다.

SEED 팀 스스로도 이 결과를 '신호'라고 부르고, 더 의미 있는 건 이 화면이 새 기준의 첫 레퍼런스가 됐다는 점이라고 정리합니다. 저는 그 표현이 정확하다고 봅니다. 다만 디자인 시스템의 가치를 경영진에게 설명해야 하는 팀이라면, 화면 지표와 별도로 시스템 자체의 지표를 같이 재 두길 권합니다. 토큰 하나를 바꾸는 데 걸리는 시간, 플랫폼 간 불일치 건수, PV 상위 페이지의 전환율 같은 것들이요. V3 롤아웃 때 PV 상위 페이지를 그해 안에 새 시스템으로 옮기겠다는 목표를 세우고, 전환이 어려운 팀은 직접 마이그레이션을 도왔다는 대목을 보면 이미 그런 숫자를 갖고 있을 가능성이 커 보입니다.

넷, 열어 둔 컴포넌트는 누가 닫아 주나

라이브러리 철학의 변화는 이 글에서 가장 대담한 결정입니다. 기존 라이브러리는 통일성을 지키려고 커스터마이징을 제한했는데, 따져 보니 통일성은 디자인 단계에서 풀 문제이지 라이브러리가 닫힌 인터페이스로 제약을 걸 일이 아니라는 결론에 이르렀습니다. 그래서 구성요소를 분해해 제공하기 시작했습니다. Figma에서도 Variants를 곱연산으로 펼쳐 두던 방식을 Property 조합으로 옮기고, Property 이름 규칙을 다잡고, Slot을 열어 두고, 폼 뼈대는 책임지되 입력 요소는 자유롭게 끼우는 Header + Slot + Footer 구조의 Field와 별도의 Input을 만들었습니다. 여기에 페이지 단위 템플릿까지 얹어, 복사해 붙이기만 해도 일정 수준의 품질과 패턴이 따라오게 했고요.

사람 디자이너가 화면을 만드는 조직이라면 저도 이 판단에 동의합니다. 닫힌 인터페이스는 제품팀의 시도를 막고, 막힌 팀은 결국 시스템 밖에서 자기 컴포넌트를 만듭니다. 문제는 이 글의 마지막 챕터와 겹칠 때입니다. SEED는 다음 단계로 에이전트도 읽고 쓰는 문서, 자연어로 탐색하는 문서 어시스턴트, 아이디어를 바로 화면으로 만드는 프로토타이핑 파이프라인을 준비하고 있고, 이미 Figma MCP와 Code Connect, Claude 같은 도구로 컴포넌트를 찾고 코드를 받는 흐름이 돌고 있습니다.

통일성을 디자인 단계에서 푼다는 원칙은 그 단계에 판단하는 사람이 앉아 있다는 전제 위에 서 있습니다. 에이전트가 화면을 빠르게 만들수록 그 단계는 얇아집니다. 분해된 부품과 열린 Slot은 사람에게는 자유지만, 맥락 없이 조합하는 에이전트에게는 브랜드에서 벗어난 조합을 만들 여지이기도 합니다. 저는 그래서 둘째 메모가 넷째 메모의 답이라고 봅니다. 닫힌 인터페이스가 하던 울타리 역할을, 이제는 targetSize처럼 기계가 읽을 수 있는 스펙과 조합 규칙이 맡아야 합니다. 어떤 Slot에 무엇이 들어가도 되는지, 어떤 fg와 bg를 같이 써도 되는지가 문서의 문장이 아니라 검사할 수 있는 데이터로 있어야 에이전트가 만든 화면도 당근답게 남습니다.

그 외에 텍스트 스타일을 38개에서 24개로 줄이면서 Medium 굵기를 더해 위계 표현은 오히려 넓힌 것, 역할과 실제 사용이 어긋나던 스타일을 Scale 토큰으로 정리한 것, 약 300개의 UI 아이콘을 형태와 네이밍 규칙으로 다시 묶은 것도 좋은 작업입니다. 다만 다른 팀이 가져갈 교훈으로는 위 네 가지보다 덜 새롭다고 봤습니다.

이 글은 모든 단계를 관통한 질문으로 "이 고민, 어떻게 하면 다시 하지 않게 할까?"를 꼽습니다. 저는 그 질문에 답하는 능력이 고칠 수 있는 능력에서 나온다고 생각합니다. 디자인 시스템의 성숙도는 컴포넌트 개수가 아니라, 토큰 하나를 바꿀 때 팀이 얼마나 덜 무서운가로 재는 편이 정확합니다.