grep

디자인 시스템 팀은 디자인 시스템만 잘 만들면 될까

당근

2026년 6월 11일

원문에서 보기 ↗

안녕하세요. 당근에서 디자인시스템 SEED를 만드는 프론트엔드 엔지니어 June이에요. 저희 팀은 당근을 만드는 구성원들의 효율과 제품의 퀄리티를 함께 고민하는 팀이에요.

오늘은 저희가 요즘 자주 떠올리는 질문 하나를 같이 나눠보려고 해요. 그런데 그 전에, 디자인시스템이 익숙하지 않은 분도 계실 테니 잠깐만 짚고 갈게요.

디자인시스템은 제품을 만드는 사람들이 함께 쓰는 '레고 블록 세트'예요. 버튼이나 입력창, 알림처럼 화면을 이루는 조각을 매번 새로 깎는 대신, 미리 맞춰둔 블록을 꺼내 조립하는 거죠. 그래서 색과 글자 크기, 간격 같은 가장 작은 재료(토큰)부터 버튼 하나(컴포넌트), 화면까지가 모두 이 세트 안에 들어 있어요. 당근에도 SEED라는 디자인시스템이 있어서, 저희 앱의 거의 모든 화면이 이 블록들로 만들어지고 있어요.

디자인시스템 팀은 디자인시스템만 잘 만들면 될까요?

사실 조금 이상한 질문처럼 들릴 수도 있어요. 디자인시스템 팀이 디자인시스템을 잘 만드는 건 너무 당연한 일이니까요. 파운데이션을 정리하고, 컴포넌트를 만들고, 디자인과 개발이 같은 언어로 이야기하도록 돕는 일. 이건 디자인시스템 팀의 가장 기본적인 역할이에요.

그런데 요즘은 이 질문을 더 자주 떠올리게 돼요. 저희가 정말 만들고 있는 게 무엇인지 다시 생각하게 되거든요. 버튼일까요, 컴포넌트 라이브러리일까요? 물론 그것도 맞아요. 하지만 조금 더 들어가 보면, 디자인시스템은 결국 사람들이 제품을 만들 때 더 좋은 결정을 내리도록 돕는 장치예요. 어떤 화면에 어떤 컴포넌트를 쓸지, 어떤 정보를 얼마나 크게 보여줄지, 어떤 행동은 한 번 더 확인받게 할지. 이런 작은 결정들이 모여서 제품의 경험을 만드니까요. 좋은 디자인시스템은 이 결정을 매번 처음부터 다시 고민하지 않게 해줘요. 같은 문제를 마주쳤을 때 이미 검증된 선택지를 빠르게 꺼내 쓸 수 있게요. 같은 컴포넌트를 여러 팀이 따로 만들지 않아도 된다는 이유도 있지만, 무엇보다 애매한 의사결정을 줄여주기 때문이에요.

그렇다면 2026년에도 저희의 목표는 그저 디자인시스템을 더 잘 만드는 걸까요? 파운데이션을 더 정교하게 다듬고, 컴포넌트를 더 많이 만들고, 가이드를 더 친절하게 쓰면 충분할까요?

요즘 AI 도구로 개발하다 보면, 이 질문이 자꾸 맴돌아요. AI가 화면을 만들고, 코드를 쓰고, 디자인 파일까지 다루기 시작했거든요. 그러다 보니 "디자인시스템을 잘 만들어두면 사람이 알아서 잘 쓰겠지"라고만 생각하기가 어려워졌어요. 앞으로는 사람뿐 아니라 AI도 디자인시스템을 읽고, 이해하고, 사용하게 될 테니까요.

그래서 이 글은 완성된 답이라기보다, 지금 저희가 하고 있는 고민에 가까워요. AI 디자인 도구가 어디까지 갈지, 저도 아직은 잘 모르겠어요. 그래도 변화의 방향을 보면서, 디자인시스템 팀이 앞으로 어떤 질문을 더 잘 던져야 할지 같이 생각해보고 싶었어요.

UI의 하한선을 빠르게 끌어올리고 있는 AI

최근 몇 년 사이에 AI로 UI를 만드는 도구가 정말 많이 나왔어요. Lovable이나 Bolt, v0처럼 프롬프트만으로 웹앱이나 프로토타입을 만들어주는 도구가 있고, Figma Make나 Figma Sites처럼 디자인 도구 안에서 아이디어를 바로 화면으로 이어주는 흐름도 생겼어요. Google Stitch는 자연어와 이미지로 UI를 만들어 Figma나 코드로 넘겨주고, Claude Design은 조직의 디자인시스템과 브랜드 자산을 바탕으로 결과물을 만드는 실험을 하고 있고요. Pencil.dev나 Open Design처럼 디자인 파일 자체를 AI가 읽고 고칠 수 있는 대상으로 다루기 시작했고요.

아직 이 도구들이 충분하게 성숙하지 않아서, 어떤 게 정답이라고 말하긴 조심스러워요. 그래도 써보면서 한 가지는 확실해졌어요.

AI는 이미 UI의 하한선을 빠르게 끌어올리고 있습니다.

디자이너 없이 만들면 어딘가 어설프던 화면이, 이제는 누가 만들어도 처음부터 제법 그럴듯하게 나오거든요.

예전에는 랜딩 페이지 하나를 보기 좋게 만드는 데에도 시간이 꽤 들었어요. 레이아웃을 잡고, 색을 고르고, 반응형을 맞추고, 문구까지 다듬어야 했으니까요. 그런데 지금은 "이런 목적의 페이지를 만들어줘"라고 말하면 몇 분 안에 제법 그럴듯한 첫 화면이 나와요. 참고할 레퍼런스를 같이 주거나 원하는 톤을 구체적으로 설명하면 결과는 더 좋아지고요. 아무것도 없는 흰 화면이 아니라, 어느 정도 모양을 갖춘 화면에서 출발할 수 있게 된 거죠.

그런데 바로 여기서 중요한 질문이 하나 생겨요.

AI가 만들어준 80%짜리 화면을, 99% 수준의 제품 경험으로 끌어올리는 일은 무엇으로 가능할까요?

80%는 빨라졌지만, 99%는 맥락의 문제

사실 AI가 만들어주는 화면을 보면 종종 감탄하게 돼요. 빠르고, 생각보다 예쁘고, 몇 번 대화하다 보면 꽤 괜찮아지거든요. 그런데 이미 운영되고 있는 제품에 새 화면을 더한다고 생각하면, 이야기가 조금 달라져요.

운영 중인 제품에서 화면은 혼자 존재하지 않아요. 그 화면 앞에는 사용자가 지나온 흐름이 있고, 뒤에는 이어서 해야 할 일이 있어요. 이미 익숙해진 탐색 방식이 있고, 같은 문제를 다뤘던 예전 화면들도 있고요. 거기에 브랜드의 말투, 제품이 지켜온 밀도와 리듬까지 얽혀 있어요. 그래서 새 화면 하나를 만들 때도 저희는 생각보다 많은 질문에 답해야 해요.

이 질문들은 그냥 "예쁘게 만들기"의 문제가 아니에요. 하나하나가 제품 경험을 두고 내리는 판단이거든요. AI는 화면을 빠르게 제안할 수 있지만, 어떤 화면이 저희 제품에 더 맞는지, 어떤 표현이 당근다운지까지 판단하려면 맥락이 필요해요. 그런데 그 맥락은 어디 정리돼 있는 게 아니라, 대부분 사람들 머릿속에 흩어져 있어요.

예를 들어 어떤 디자이너는 오랜 경험으로 "이 화면은 정보가 빡빡하니 좀 덜어내는 게 낫겠다"고 판단해요. 어떤 개발자는 "이 패턴은 구현은 쉬운데 예외 상태가 많아서 나중에 복잡해진다"고 말하고요. 또 어떤 PM은 "사용자가 이 화면에 들어오는 목적을 생각하면 이 정보가 먼저 보여야 한다"고 이야기해요. 이런 판단들이 모이면 그게 곧 팀의 자산이에요.

그래서 저는 이런 자산도 디자인시스템의 일부가 되어야 한다고 생각해요. 디자인시스템을 단순히 컴포넌트 목록으로 본다면 Button이나 List, BottomSheet를 잘 제공하는 것으로 충분할지도 몰라요. 하지만 "제품을 만드는 사람들이 더 좋은 결정을 하도록 돕는 시스템"으로 본다면, 어떤 상황에서 왜 그 컴포넌트를 골라야 하는지에 대한 판단까지 담겨야 하니까요.

문제는 이 자산이 구조화되어 있지 않으면, AI도 제대로 쓰지 못하고 사람도 매번 다시 고민해야 한다는 거예요. 그래서 AI 시대에는 디자인시스템이 오히려 더 중요해진다고 생각해요.

재밌는 건, 요즘 도구들이 향하는 방향도 비슷하다는 거예요. v0는 컴포넌트와 토큰을 AI가 꺼내 쓰도록 목록으로 정리해두는 registry라는 방식을 제공하고, Google Stitch는 디자인 규칙을 DESIGN.md라는 텍스트 파일에 적어 주고받아요. AI가 그 파일을 읽고 화면에 그대로 반영하는 거죠. 디자인 문서가 사람만 읽는 웹페이지가 아니라, AI가 읽고 적용하는 계약서에 가까워지고 있는 거예요. Figma의 MCP와 Code Connect도 같은 방향이고요. MCP는 AI가 디자인 파일 같은 외부 자료를 직접 들여다보게 해주는 연결 통로이고, Code Connect는 Figma의 컴포넌트와 실제 코드를 이어줘서 어떤 속성으로 써야 하는지까지 알려주는 기능이에요. 이렇게 도구마다 방식은 달라도, 향하는 곳은 닮아 있어요.

좋은 결과를 만들려면 좋은 맥락이 필요합니다.

그리고 그 맥락을 가장 잘 만들 수 있는 팀 중 하나가 바로 디자인시스템 팀이에요. AI가 UI의 하한선을 끌어올릴수록, 저희는 상한선을 높이는 맥락을 더 잘 쌓아야 하는 거죠.

디자인시스템은 결정 피로를 줄이는 시스템

디자인시스템을 이야기할 때 저희는 자주 재사용성을 말해요. 같은 버튼을 여러 번 만들지 않으려고, 또 같은 컴포넌트를 디자인과 개발이 다르게 이해하지 않으려고요. 이 이유는 지금도 여전히 중요해요. 그런데 요즘 저는 재사용성보다 더 자주 입에 올리는 단어가 하나 있어요.

바로 **'결정 피로'**예요.

제품을 만들다 보면 매 순간 무언가를 결정해야 해요. 화면 하나에도 수십 개의 작은 결정이 필요하고, 그 결정에는 대부분 정해진 정답이 없거든요. 그럼 AI가 들어오면 이 피로가 사라질까요? 처음엔 저도 그럴 줄 알았어요. 초안 잡는 시간도, 여러 아이디어를 펼쳐보는 비용도 확실히 줄었으니까요. 그런데 막상 써보니 줄어든 만큼 다른 일이 또 생기더라고요. AI가 시안을 여러 개 뽑아주면 이번엔 그중에 뭐가 제일 나은지를 저희가 골라야 하고, 코드를 그럴듯하게 만들어줘도 그게 진짜 저희 제품에 맞는지는 결국 사람이 다시 봐야 하니까요.

AI는 선택지를 만드는 비용을 낮춰줘요. 하지만 무엇을 고를지에 대한 기준이 없으면, 결정 피로는 형태만 바꿔서 그대로 남아요. 그래서 디자인시스템은 선택지를 무한히 늘리는 시스템이 아니라, 좋은 선택지로 좁혀주는 시스템이어야 해요. 저희가 쌓아야 할 맥락도, 결국 이 기준이거든요.

예를 들어 사용자가 짧은 설정만 바꾸고 원래 흐름으로 돌아와야 한다면, 화면을 통째로 옮기는 것보다 바텀시트가 더 자연스러울 수 있어요. 하지만 선택지가 많고 설명이 길어지면, 그 모든 걸 바텀시트 안에 넣는 게 오히려 부담이 되고요. 또 되돌릴 수 없는 행동에는 확인 단계가 필요하지만, 가벼운 행동까지 매번 확인받게 하면 사용자는 금세 피로해져요. 이런 판단을 팀마다 매번 새로 하지 않도록 돕는 것. 이게 디자인시스템이 할 수 있는 중요한 일이에요.

AI에게 "당근의 디자인시스템인 SEED 컴포넌트로 화면을 만들어줘"라고 말하는 것과, "이 화면은 사용자가 여러 항목을 비교해야 하니 리스트 중심으로 정보를 구성하고, 주요 액션은 하나로 좁히고, 위험한 액션에는 확인 단계를 둬. 이때 SEED의 Button과 List, BottomSheet를 이런 기준으로 써줘"라고 말하는 건 전혀 달라요. 앞은 도구 쓰는 법을 알려주는 거고, 뒤는 경험에 대한 판단을 넘겨주는 거거든요. 앞으로 디자인시스템이 쌓아야 하는 건 바로 이 두 번째 종류의 정보라고 생각해요.

컴포넌트보다 한 단계 높은 패턴

디자인시스템에는 이미 많은 컴포넌트가 있어요. Button과 TextField, Dialog, Toast, BottomSheet처럼 화면을 구성하는 재료들이죠. 이 재료들은 분명 중요하지만, 실제 제품 경험이 컴포넌트 하나만으로 결정되지는 않아요.

그래서 컴포넌트보다 한 단계 높은 패턴이 필요해져요.

이런 질문들은 컴포넌트 하나의 문서만으로는 답하기 어려워요. 여러 컴포넌트가 함께 쓰이고, 거기에 제품 맥락과 사용자 목적까지 얽히기 때문이에요.

앞으로의 디자인시스템은 컴포넌트 문서와 함께 패턴 문서를 더 많이 갖춰야 한다고 생각해요. 다만 이 패턴 문서는 단순한 예시 모음이 아니라, 의사결정의 기록이어야 하고요. 예를 들어 "선택"이라는 패턴을 다룬다면, Radio와 Checkbox의 차이를 설명하는 것만으로는 부족해요.

이런 기준까지 함께 있어야 하거든요.

그리고 실제 제품에서 어떤 선택을 했는지도 남겨두면 좋아요. 이런 기록은 다음에 비슷한 고민을 할 팀에게 도움이 돼요. 나중에 AI가 비슷한 화면을 만들 때도 좋은 컨텍스트가 되고요.

AI가 읽을 수 있는 디자인시스템

지금까지 디자인시스템 문서는 주로 사람이 읽는 문서였어요. 디자이너가 컴포넌트 사용법을 확인하고, 개발자가 API를 보고, PM이 어떤 패턴이 있는지 살펴보는 식이었죠. 그런데 앞으로는 여기에 독자가 하나 더 생겨요. 'AI'라는 독자죠.

AI가 디자인시스템을 잘 쓰려면, 문서가 보기 좋기만 해서는 부족해요. 무엇보다 잘 구조화되어 있어야 하거든요. 토큰도 단순한 색상 값의 목록이 아니라, 어떤 의미와 용도를 갖는지까지 설명되어 있어야 해요. 예를 들어 orange-500이라는 값 하나만으로는 부족해요. 이 색이 브랜드를 대표하는 색인지, 주요 액션에 쓰는 색인지, 경고에는 쓰면 안 되는 색인지까지 알아야, AI도 그냥 비슷한 색이 아니라 의도에 맞는 색을 고를 수 있으니까요.

컴포넌트도 마찬가지예요. BottomSheet라는 이름만 알아서는 부족해요. 어떤 상황에서 쓰고 어떤 상황에서는 피해야 하는지, 안에 액션을 몇 개까지 두는 게 적절한지까지 알아야 하거든요. 이런 의미에서 디자인시스템은 사람을 위한 문서와 AI를 위한 컨텍스트를 함께 갖춰야 해요.

그렇다고 거창한 플랫폼을 당장 만들 필요는 없어요. 작은 단위부터 시작할 수 있어요.

처음에는 그냥 문서 정리처럼 보이지만, 실은 팀이 머릿속에만 갖고 있던 판단을 밖으로 꺼내는 작업이거든요.

AI가 제안하고, 사람이 확인하는 흐름

저는 AI 시대의 디자인시스템이 모든 결정을 자동화해야 한다고 생각하진 않아요. 적어도 지금은요. 대신 이런 그림을 그리고 있어요. AI가 좋은 선택지를 만들고, 사람은 더 중요한 판단에 집중하는 그림이요.

새 화면을 만드는 상황을 한번 그려볼게요. 먼저 사람이 화면의 목적과 제품 맥락을 설명해요. 사용자가 어떤 상황에서 이 화면에 들어오는지, 무엇을 보고 무엇을 결정해야 하는지 알려주는 거죠. 그러면 AI는 디자인시스템의 패턴과 컴포넌트, 기존 화면의 맥락을 바탕으로 여러 안을 제안해요.

그러면서 각 안의 장단점도 함께 설명해줘요.

이 정도가 되면, 사람은 처음부터 모든 걸 직접 결정하는 사람이 아니라 좋은 안을 검토하고 마지막에 판단하는 사람이 돼요. 그렇다고 사람의 역할이 작아지는 건 아니에요. 오히려 더 중요해지죠. 다만 그 판단이 더 높은 질문에 쓰이게 돼요.

경험은 화면 밖에도 있다

좋은 경험은 화면에 보이는 것만으로 완성되지 않아요.

이런 작은 감각들이 모여서 제품의 인상을 만들거든요. 그래서 앞으로의 디자인시스템은 컴포넌트 바깥의 경험까지 더 많이 다뤄야 한다고 생각해요. 모션, 햅틱, 사운드, 카피, 접근성, 상태 처리, 플랫폼 관습 같은 것들이요.

그런데 AI가 화면을 빠르게 만들어줄수록, 저희는 더 많은 화면을 더 빠르게 보게 돼요. 그 화면들이 다들 비슷하게 그럴듯하다면, 결국 차이를 만드는 건 이 작은 경험의 밀도예요. "저장 완료" 하나를 알려주는 데도 화면 안의 상태를 바꿀지, 토스트를 띄울지, 가벼운 햅틱을 줄지 답이 갈리거든요. 이런 기준을 디자인시스템이 미리 쌓아두면, 팀은 매번 처음부터 고민하지 않아도 되고 AI도 더 나은 제안을 할 수 있어요.

앞으로의 디자인시스템 팀의 역할

이제 처음 던졌던 질문으로 돌아와 볼게요.

디자인시스템 팀은 디자인시스템만 잘 만들면 될까요?

제 답은 "아니요"예요. 조금 더 정확히 말하면, 디자인시스템을 잘 만든다는 말의 의미 자체가 바뀌고 있어요. 예전에는 그게 좋은 파운데이션과 좋은 컴포넌트를 만드는 일에 가까웠어요. 그 일은 지금도 중요해요. 토큰이 흔들리면 제품의 시각 언어가 흔들리고, 컴포넌트의 품질이 낮으면 그걸 쓰는 팀의 신뢰가 떨어지니까요. 다만 AI 시대에는, 그 기본 위에 더 많은 역할이 올라와요.

이제 디자인시스템 팀은 이런 팀이어야 해요.

제품 경험에 대한 판단을 쌓는 팀 사람들이 반복해서 하는 고민을 줄여주는 팀 좋은 UI/UX가 무엇인지 계속 묻고, 그 답을 팀 전체가 쓸 수 있는 형태로 바꾸는 팀 사람과 AI가 함께 일할 때 필요한 맥락을 준비하는 팀

그런데 이건 단순히 AI에 잘 대응하기 위한 일만은 아니에요. 사실 원래 디자인시스템이 하던 일을, 더 본질적으로 들여다보는 일이거든요. 저희가 컴포넌트를 만드는 이유는 컴포넌트 그 자체가 좋아서가 아니라, 더 나은 제품 경험을 더 일관되게 만들기 위해서예요. 가이드를 쓰는 이유는 문서를 늘리기 위해서가 아니라, 팀이 같은 문제를 만났을 때 더 좋은 선택을 더 빠르게 하도록 돕기 위해서고요. 파운데이션을 정리하는 이유도 색과 글자를 관리하는 걸 넘어, 제품 전체가 하나의 목소리와 리듬을 갖게 하기 위해서예요.

신기하게도 AI랑 같이 일해 볼수록 이 목적이 오히려 더 또렷해졌어요.

지금 SEED Design으로 할 수 있는 일

그렇다면 SEED Design이 당장 할 수 있는 일은 뭘까요. 미래의 완성된 AI 디자인 플랫폼을 지금 만들 수는 없어요. 어떤 도구가 표준이 될지 점치기도 일러요. 하지만 도구가 어떻게 바뀌든, 변하지 않는 일이 하나 있어요. 바로 저희의 맥락을 쌓는 일이에요.

물론 이런 일은 한 번에 끝나지 않아요. 컴포넌트를 한 번 만들고 끝내지 않고 계속 다듬어가듯, 경험에 대한 판단도 계속 쌓고 다듬어야 하거든요.

그래서 어쩌면, 저희가 앞으로 만들어야 할 건 더 많은 컴포넌트가 아닐지도 몰라요. 더 많은 결정의 기록, 더 좋은 패턴의 언어, 더 잘 읽히는 맥락일 수 있어요. 결국 디자인시스템은 제품을 만드는 사람들이 더 좋은 결정을 하도록 돕는 시스템이니까요. 그리고 AI와 함께 일하는 시대에도, 어쩌면 그렇기 때문에 더더욱, 저희는 이 일을 더 잘해내고 싶어요.

디자인 시스템 팀은 디자인 시스템만 잘 만들면 될까 was originally published in 당근 기술 블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.