더 당근답게: SEED는 어떻게 진화했나

당근에는 다른 IT 서비스에서 느끼기 어려운, 어딘가 인간적이고 따뜻한 인상이 있어요. 저희가 디자인 시스템을 만들고 가꿔온 이유도 결국 거기에 있습니다. 빠르게 커지는 서비스 속에서도 더 당근답게, 그리고 누구에게나 더 편하게 제품을 만들고 싶었거든요.
당근 디자인 시스템 SEED는 흩어져 있던 디자인 자산을 정리하는 데서 출발해, 컴포넌트 라이브러리를 갖추고, 여러 플랫폼이 같은 기준으로 제품을 만들 수 있는 시스템으로 조금씩 자라왔습니다. 디자인 시스템이란 결국 제품을 만들 때 따라오는 수많은 디자인 의사결정을, 당근에 맞는 기준으로 정리하고 반복 가능한 형태로 압축해주는 일이라고 생각해요.
SEED가 걸어온 길
우리가 같은 실수를 반복하지 않으려 했던 기록
SEED의 시작은 '디자인 시스템'이라는 이름과는 거리가 있었어요. 2021년 6월 무렵, 당근의 디자인 시스템은 "앱 개발에 날개를 달아줄 지원 라이브러리 모음"이라는 소박한 설명에서 출발했습니다.
V1: 스타일을 모아두던 시절
디자인 시스템이라기보다는, 자주 쓰는 스타일을 정의해 함께 쓰는 정도였어요. 컴포넌트나 토큰의 개념보다는 '반복을 줄이는 모음집'에 가까웠죠.
V2: 시스템의 형태를 갖추다, 그러나
Foundation과 Component를 제대로 지원하기 시작하며 비로소 '시스템'의 모양을 갖췄습니다. 다만 당근만의 의미를 담은 토큰과 프레임워크의 토큰이 뒤섞여 체계가 일관되지 않았어요. 쓰이지 않는 토큰이 쌓였고, 무엇보다 색상이 충분한 명도 대비를 보장하지 못하는 한계가 있었습니다. 접근성의 한계가 시스템의 가장 아랫단에 박혀 있던 셈이에요.
V3: 다시 세운 큰 개편
그래서 V3는 단순한 버전 업이 아니라, 이 구조적 약점을 정면으로 다시 세운 대규모 개편이었습니다. 접근성에 기반해 색상 체계를 새로 짜고, 최소 터치 영역을 고려하고, 타이포의 토큰 수를 줄여 직관적인 스케일 단위로 정리했어요. 그리고 디자인 결정을 한곳에서 관리해 모든 플랫폼으로 흘려보내는 Rootage라는 기반까지 더했습니다.
이 글에서 다룰 이야기가 바로 이 V3예요. 개편이 단단하려면 결국 두 가지가 함께 가야 했습니다. 사용자가 만나는 화면이 더 당근다워지는 것, 그리고 그 화면을 떠받치는 구조가 흔들리지 않는 것. 그래서 지금부터, 먼저 눈에 보이는 화면의 변화부터 하나씩 풀어볼게요. 과연 무엇을 '더 당근답게' 바꿨을까요?
Part 1. 보이는 변화: 더 당근답게, 더 누구에게나
당근스러움을 UI의 문법으로
로고의 친근한 인상을 형태·아이콘·색의 규칙으로 옮기다
당근 로고에는 둥글면서도 모서리 엣지에서 오는 친근한 인상이 있어요. SEED V3에서는 이 인상을 UI에도 옮겨 담고 싶었습니다. 형태와 아이콘, 디자인 요소 하나하나에 당근다움을 녹여, 화면을 좀 더 생동감 있고 일관되게 구성할 수 있도록 했는데요.


아이콘은 특히 공을 들인 부분이에요. 일관된 형태와 네이밍 규칙을 적용해 약 300개에 이르는 UI 아이콘 세트를 새로 정리했습니다. 단순히 더 예쁘게 다듬은 게 아니라, 당근다움을 '감각'이 아니라 '규칙'으로 만들고 싶었어요.
접근성 — '배려'가 아니라 '기준'이 되도록
색·대비·터치 영역·포커스까지, 누구에게나 닿는 화면을 기본값으로
이번 개편에서 가장 깊이 다룬 주제는 접근성이었어요. 그동안 접근성은 '여유가 되면 챙기는 것'에 가까웠는데요. 이번엔 WCAG와 APCA 같은 업계 표준을 충족하는 경험을 처음부터 기준으로 삼았습니다.

가장 구조적인 변화는 색상의 역할을 명확히 나눈 것이었어요. 색을 전경(fg), 배경(bg), 외곽선(stroke)으로 분리하고 일관된 네이밍 체계를 입혔습니다. 이렇게 만든 조합은 충분한 명도 대비를 보장하기 때문에, 색약이 있거나 나이가 드신 이웃들도 정보에 무리 없이 접근할 수 있어요. 더 많은 색에 섬세한 역할을 부여한 덕분에, 디자이너 입장에서도 "이 색을 써도 괜찮을까" 하는 고민이 한결 줄었습니다.

색의 톤도 다시 정리했어요. 모든 색이 같은 단계에서 같은 시각적 대비를 갖도록 맞췄는데요. 그래서 한 화면 안에서 서로 다른 색의 컴포넌트가 더 일관된 주목도를 갖게 됐고, 터치할 때의 색 변화도 더 자연스러워졌습니다. 서비스팀이 자체 컴포넌트의 variant를 만들 때도 "같은 단계에서 톤만 바꾸면 되는" 단순한 작업으로 바뀌었죠.

다크모드에서는 배경은 더 어둡게, 앞에 놓인 레이어는 상대적으로 밝게 조정해 또렷한 대비를 만들었어요. 덕분에 어두운 화면에서도 시각적 계층이 분명해지고, 정보의 가독성과 공간감이 한결 정돈됐습니다.

접근성 이야기에서 저희가 가장 의미 있게 생각하는 결정은 터치 영역을 스펙으로 정의한 것이에요. Figma 가이드에도, 모든 구현이 공유하는 스펙에도 터치 영역(targetSize)을 기록했습니다. 어느 개발자가 어느 플랫폼에 구현하더라도 같은 의도가 그대로 보장되도록요. 접근성을 '잘 챙기자'는 권고가 아니라, 누구나 확인할 수 있는 명시적인 기준으로 바꾼 셈입니다.

접근성은 모바일에만 머무르지 않아요. 당근을 PC에서 사용하는 경우도 늘고 있는 만큼, 키보드로 화면을 탐색하는 경험도 함께 챙기고 있습니다. 그래서 focus 상태를 추가했어요. 키보드 사용자나 보조기기를 쓰는 분들에게는 이 작은 표시 하나가 화면을 읽어내는 핵심 단서가 됩니다.
또 하나 더하고 있는 건 피드백이에요. 버튼처럼 누를 수 있는 요소를 클릭하면 살짝 줄어들었다 돌아오며 "지금 눌렸어요"라는 신호를 즉각 돌려주는 인터랙션인데요. 터치든 클릭이든, 내 동작이 제대로 전달됐다는 확신을 주는 건 사용성의 기본이라고 생각했어요.
타이포그래피: 이전보다 적은 수지만 오히려 풍부하게
스타일은 38개에서 24개로, 의미는 더 또렷하게

타이포그래피는 '덜어내는 방향'으로 개편했습니다. 텍스트 스타일을 기존 38개에서 24개로 크게 압축해, 작업할 때의 복잡도를 낮추고 Medium 굵기를 더해 위계를 표현할 수 있는 범위는 오히려 넓혔어요.

가장 중요한 건 Scale 토큰을 도입한 것이었어요. 기존에는 폰트 스타일에 부여된 역할과 실제 사용이 어긋나, 디자인과 개발 사이에 오해가 잦았기에 V3에서는 용도가 분명한 스타일에만 역할을 부여해, 본래 목적대로 쓰이도록 정리했어요.
새 기준을 한 번에 갈아타지 않기로 했어요
Foundation부터 컴포넌트까지 차근차근, 그리고 화면으로 증명하기
이렇게 새로 정한 기준을 실제 제품에 어떻게 입힐지도 중요한 문제였어요. V3와 V2가 한 화면에 뒤섞이면 관리가 어렵기에 점진적인 롤아웃을 택했어요.
가장 아랫단인 Foundation(색·타이포·아이콘 같은 기본 요소)부터 먼저 자리 잡게 한 뒤, 그 위에서 컴포넌트도 차근차근 가져다 쓸 수 있도록 단계를 밟았어요.
Figma 디자인 키트를 배포하고, 전사에 소개한 뒤 팀별 온보딩을 거쳐 자유롭게 쓰도록 안내했죠. PV 상위 페이지를 그해 안에 새 시스템으로 옮기겠다는 구체적인 목표를 두되, 전환이 어려운 팀은 직접 마이그레이션을 도왔습니다. 시스템 전환을 '기술 배포'가 아니라 '조직이 함께 익혀가는 과정'으로 본 결정이었어요.
프로필 화면 개편 이야기
실험으로 증명한 첫 번째 화면, 그리고 그 결과
새로 정한 디자인 기준이 실제 화면에서 어떻게 작동하는지가 결국 중요했어요. 저희가 먼저 새 스타일을 입혀본 화면은 프로필 화면이었어요.

기존 프로필 화면을 다시 보니, 색은 역할이 또렷하지 않아 어떤 정보가 중요한지 한눈에 들어오지 않았고, 텍스트 위계도 흐릿해 시선이 머물 곳을 안내해주지 못했어요. 터치 영역이나 명도 대비처럼 접근성의 기본도 화면마다 제각각이었고요.

여기에 V3의 기준을 그대로 적용해 봤습니다. fg·bg·stroke로 역할이 나뉜 색상 체계로 정보의 우선순위를 다시 잡고, Scale 토큰과 새 타이포 위계로 먼저 봐야 할 것과 나중에 봐도 될 것을 분명히 구분했어요. 당근다운 형태의 아이콘과 정돈된 다크모드, 보장된 터치 영역까지 개편 요소들이 한 화면 안에서 정리될 수 있었어요.
디자이너가 매번 새로 판단하던 것들을 시스템이 대신 정리해주니, 화면은 더 당근다워지면서도 더 읽기 쉬워졌어요.
변경 이후 결과는 어땠을까요?

프로필에서 다른 이웃을 모아보기하는 수가 약 44% 늘었고, 화면 체류 시간이 Android 68%·iOS 83% 증가했어요. 새 스타일이 단지 '더 예뻐 보인다'에서 그치지 않고, 사용자가 화면을 더 잘 이해하고 더 자연스럽게 움직이도록 도왔다는 신호였죠. 무엇보다 의미 있었던 건, 이 화면이 새 SEED의 기준을 그대로 적용했을 때 어떤 결과가 나오는지를 보여주는 첫 번째 레퍼런스가 되었다는 점이에요.
Part 2. 보이지 않는 변화: 시스템은 구조적으로 어떻게 자랐나
한때 우리는 시스템을 '고칠 자신'이 없었어요
개선을 망설이게 만든 구조적 약점
솔직히 고백하면, V3 이전의 디자인 시스템에는 큰 약점이 하나 있었습니다. 바로 고치기 두려웠다는 것이에요.
동기화 메커니즘 자체는 있었지만 디자인 토큰의 영향도를 추적할 수가 없었어요. 어떤 토큰 하나를 바꾸면 그게 어떤 토큰과 컴포넌트, 나아가 어떤 서비스까지 번지는지 알 수 없으니, 업데이트는 늘 조심스러운 일이었죠.
컴포넌트 쪽도 비슷했어요. 디자인 사양을 일일이 수동으로 업데이트해야 했고, iOS·Android·Web의 구현을 따로따로 확인하다 보니 지연 및 불일치가 생겼어요. 문서와 실제 디자인이 어긋나 혼란이 일기도 했고, 팀마다 반영 시기가 달라 같은 변경이 비동기적으로 롤아웃되곤 했죠. 시스템과 제품 사이의 간극은 그렇게 조금씩 벌어지고 있었어요.
그래서 V3의 구조적 방향은 "무엇을 더 추가할까"가 아니라 "왜 우리는 시스템을 자신 있게 고치지 못할까"라는 질문에서 출발했어요.
디자인 토큰 영향도 추적: 개선을 두렵지 않게
현재 버전에서는 모든 디자인 토큰에 대해 이 토큰을 사용하고 있는 다른 토큰과 컴포넌트를 추적할 수 있게 됐어요. 나아가 그 토큰이 어떤 서비스에까지 영향을 주는지도 파악해 나가고 있어요.

이게 왜 중요하냐면, 비로소 "안전하게 개선할 수 있는 영역"을 쉽게 가늠할 수 있게 됐기 때문이에요. 한때 '고치기 싫은 시스템'이었던 SEED가, '계속 고쳐도 괜찮은 시스템'으로 바뀐 거죠.
보장된 디자인: 구현 동기화

추적의 기반 위에서 동기화도 한 단계 올라섰습니다. 이제 컴포넌트 디자인을 업데이트하면 문서와 각 플랫폼의 구현체가 함께 동기화돼요. 구조 변경이 없는 한, 모든 플랫폼별 구현에 변경이 동시에 전파되기 때문에 일관성을 유지하면서 개발 시간도 줄일 수 있어요.
확장 가능한 기반으로 만들기
기존 라이브러리는 디자인 통일성을 지키기 위해 커스터마이징을 '제한'하는 방향으로 설계돼 있었어요. 그런데 곰곰이 따져보니, 통일성은 디자인 단계에서 풀어야 할 문제이지, 라이브러리가 닫힌 인터페이스로 제약을 거는 건 불필요한 일이더라고요.
그래서 구성요소를 분해해 제공하는 방식으로 바꿨어요. 제품에서 다양한 시도를 할 때 라이브러리의 제약이 더는 걸림돌이 되지 않기를 바라는 마음을 코드 구조에 그대로 담았습니다.
Figma: '나열'에서 '조합'으로
라이브러리 못지않게 Figma에서도 큰 변화가 있었어요. 디자이너가 매일 만지는 도구이기 때문에, 여기서의 구조가 곧 작업의 속도와 일관성을 좌우하거든요.
가장 크게 손보고 있는 건 Variants를 나열하는 방식에서 Property를 조합하는 방식으로 옮기는 일이에요. 그동안은 경우의 수를 미리 계산해 Variant로 펼쳐두는 방식이라 직관적이긴 했지만, 곱연산으로 늘어나는 탓에 유지보수가 만만치 않았어요.

예를 들어 아래 컴포넌트는 타이틀 타입 하나를 관리하느라 수많은 Variant를 갖고 있었어요. 이걸 Property 조합으로 바꾸면, 같은 표현을 훨씬 적은 수의 컴포넌트로 유연하게 다룰 수 있어요.

동시에 Property 이름 규칙도 다시 정리했어요. 색의 톤을 가리키는 Property와 레이아웃과 같이 전혀 다른 Property가 같은 방식으로 뒤섞여 있으면 헷갈리니, '이 Property가 무엇을 의미하는지'가 이름만 봐도 드러나도록 체계를 다잡았어요.

또한, Slot을 적극적으로 제공했어요. 컴포넌트 내부를 꽉 닫아두는 대신 필요한 자리를 슬롯으로 열어두면, 디자이너가 그 안에 필요한 요소를 끼워 넣어 다양한 변형을 직접 구성할 수 있어요. 앞서 이야기한 라이브러리의 '분해해서 제공하는' 철학이, Figma에서는 Slot이라는 형태로 똑같이 적용되는 거죠.

마지막으로 조합형 컴포넌트를 제공했어요. 대표적인 예시가 Field예요. 폼은 일관된 모양을 보장해야 하지만, 동시에 그 안에 들어갈 입력 요소는 상황에 따라 달라져요. 이 두 가지를 함께 만족시키기 위해 Field를 Header + Slot + Footer 구조로 나눴어요. 레이블·설명·에러 메시지처럼 폼의 뼈대를 이루는 영역은 Field가 책임지고, 실제 입력 요소는 Slot에 자유롭게 끼워 넣을 수 있도록 열어둔 거예요. 그리고 이 Slot에 들어갈 수 있는 Input 컴포넌트를 별도로 만들어, 필요한 조합을 직접 구성할 수 있게 했어요.

나아가 디자이너가 매번 처음부터 조합하지 않고 페이지 단위로 바로 가져다 쓰는 템플릿으로도 제공해요. 이로써 복사해서 붙이는 것만으로 일정 수준의 품질과 패턴이 자연스럽게 따라올 수 있어요.
Figma에서 코드까지, 그리고 여러 플랫폼으로
컴포넌트 모음에서, 의사결정을 잇는 연결망으로
지금의 당근 디자인 시스템은 더 이상 Figma 안의 라이브러리에 머물지 않아요. 초기의 자산 정리 단계에서 출발해, 이제는 Docs, React, iOS, Android까지 실제 제품을 만드는 과정 전반에서 함께 작동하고 있어요.
Docs는 Foundation·Component·Spec·React 문서를 한곳에서 확인하는 지식 베이스가 됐어요. 단순한 참고 문서를 넘어, 당근 안에서 같은 기준으로 판단하고 구현하도록 돕습니다. 각 플랫폼에서는 컴포넌트의 실제 동작과 인터랙션을 확인할 수 있는 카탈로그 앱을 정기적으로 배포하고 있고요. Figma MCP와 Code Connect를 통해 Figma에서 컴포넌트를 고르면 실제 구현 코드를 바로 확인하고, Claude와 같은 도구에 자연어로 물어보면 컴포넌트 유무와 사용 예시까지 얻을 수 있어요.
이 모든 채널을 관통하는 원칙은 하나예요. 각 플랫폼을 따로 운영하지 않고, 가능한 한 같은 스펙과 같은 맥락이 이어지도록 연결하는 것. 시스템의 정체성이 '컴포넌트 모음'에서 '의사결정이 흩어지지 않게 잇는 연결망'으로 옮겨온 셈입니다.
새로운 챕터: AI와 함께 쓰는 시스템
사람도 에이전트도 같은 기준으로 읽고 쓰는 시스템을 향해
지금까지 당근 디자인시스템이 공통 기준을 만들고 연결하는 데 집중해왔다면, 앞으로는 그 기반이 작동하는 범위와 방식이 한 단계 더 넓어지려고 해요.
더 다양한 환경에서 당근다운 경험을 만들 수 있도록 확장하고, 더 빠르게 아이디어를 검증하고 구현할 수 있도록 돕고, 더 풍부한 맥락까지 자연스럽게 전달할 수 있는 방향으로 나아가고 있어요.

문서도 달라지고 있어요. 이제는 사람만 읽는 참고 자료를 넘어, 에이전트도 이해하고 활용할 수 있는 구조를 함께 갖추려 해요. 자연어로 대화하듯 탐색하는 문서 어시스턴트도 준비하고 있고요. 아이디어를 빠르게 화면으로 만들고 바로 확인해 보는 프로토타이핑 파이프라인, 그리고 패치노트를 일일이 따라가지 않아도 필요한 변경이 프로젝트에 자연스럽게 반영되는 유지보수·마이그레이션 자동화도 실험하고 있어요.
디자인 시스템이 '의사결정의 압축'이라면, 다음 진화는 그 압축을 사람과 도구가 함께 풀어 쓰는 단계라고 생각해요.
마치며
자산을 정리하던 시절부터 멀티플랫폼과 AI 시대로 오는 동안, 화면 위의 결과물은 계속 바뀌었어요. 색상 체계가 바뀌고, 타이포가 절반으로 줄고, 라이브러리의 철학이 변경되고, 시스템이 다루는 단위가 자산에서 맥락으로 올라갔죠. 그런데 그 모든 단계를 관통하는 질문은 늘 같았어요.
"이 고민, 어떻게 하면 다시 하지 않게 할까?"
디자인 시스템은 한 번에 완성되는 것이 아니라고 생각해요. 유저의 행동 패턴이 달라지고, 서비스의 성격이 바뀌고, 기술 환경이 움직이면 시스템도 함께 자랍니다. 그리고 그 진화는 언제나, 더 좋은 제품을 더 빠르게, 그리고 더 다정하게 만들기 위한 단단한 기반을 향하고 있어요.
당근 디자인 시스템의 다음 장도, 결국 이 질문의 연장선 위에 있을 거예요.
함께 SEED를 활용해 좋은 제품을 만들어가고 싶다면?
Design Engineer 채용 공고 보러가기
Last updated on