시작하며 : 왜, 그리고 어떻게 이 작업을 시작했나
저는 22년부터 26년 상반기까지 오랫동안 풀리팀의 프로덕트 디자이너로 혼자 일해왔습니다. 그동안 B2C부터 B2G까지 다양한 비즈니스를 피봇해 보면서 신규 프로덕트가 나오면 만들고, 또 신규 기능이 추가되면 그 위에 다시 만들고. 빠르게 손을 움직여야 했던 시기였고, 머릿속의 감각이 곧 시스템 역할을 했습니다.
그러다 올해 초, 매쓰플랫팀으로 합류할 기회가 주어졌습니다. 디자이너로서 한 단계 더 성장할 수 있는 전환점이라 생각하여 이동을 결정했지만, 마음 한구석이 무거웠어요. 그동안 제가 만들어 놓은 화면들은 한 사람의 직감 위에 쌓여 있었거든요. 머지않아 디자이너 쌤들이 두 명, 세 명으로 늘어나고, 프론트엔드 개발 쌤들도 함께 늘어나는데, 제 머릿속에만 있는 약속을 그대로 두고 떠나는 건 여태 함께한 조직에 무책임한 일이라는 생각이 들었습니다.
그래서 마지막 프로젝트를 정했습니다. 떠나기 전 20일, 제대로 된 디자인 시스템을 남기고 가자.
그동안의 디자인 파일이 일종의 '디자인 라이브러리' 그러니까 비슷한 모양들을 모아둔 컴포넌트에 가까웠다면, 이번에는 진짜 의미의 디자인 시스템을 만들고 싶었습니다. 토큰에 의도와 규칙이 있고, 컴포넌트의 약속이 있고, 디자이너, 개발자, AI가 같은 언어로 부를 수 있는 그런 시스템이요. 이러한 인프라가 갖춰진다면, 동료들은 컴포넌트를 만드는 반복적인 리소스에서 벗어나 오롯이 사용성 강화와 일관성 있는 UX/UI 확보에만 집중할 수 있을 것입니다. 나아가 제품의 빌드업 속도 역시 비교할 수 없이 빨라질 것이라 확신했지요.
이 작업을 한 건 올해 3월 초, AI 디자인 도구가 막 등장하기 시작하던 시기였습니다. Claude Design도 Google Stitch도 아직 출시 직전이거나 세상에 없던 때라, 이번 작업은 운명적으로 AI 프리(free)였어요. 토큰 이름 하나까지 저의 인간지능으로 직접 고민해야 했죠. 돌이켜 보면, 그 시간이 이 글의 모든 깨달음의 출발점이었습니다.
처음 마주한 질문 : "AI도 읽을 수 있는 시스템이란 어떤 모습일까?"
풀리캠퍼스 디자인 시스템 AS-IS
작업을 시작하기 전, 한 가지 질문이 머릿속을 떠나지 않았습니다. "AI는 우리 디자인을 어떻게 읽을까?" AI가 디자인 파일을 읽고 코드를 만들어준다는 사례가 점점 늘어나고 있었습니다. 그럼 우리 파일은 얼마나 잘 읽힐까? 이 질문을 안고 기존 파일을 다시 들여다봤을 때, 두 가지가 눈에 들어왔습니다.
첫째, 색상이 '값'으로만 존재했습니다. 디자이너의 눈에는 분명 위계가 보였습니다. 이건 강조, 이건 본문, 이건 비활성. 하지만 피그마에 보이는 건 위계가 아니라 색값일 뿐이었습니다. AI 입장에서는 이게 'Primary 색상'인지, 단순히 어떤 화면의 보라색 배경인지 추론할 단서가 없었습니다. 사람도 마찬가지였죠. 새로 합류한 디자이너에게 "이건 우리의 Primary 컬러야"라고 매번 구두로 설명해야 했을 겁니다.
둘째, 컴포넌트 이름이 그때그때의 직감으로 적혀 있었습니다. 어떤 건 케밥 케이스로, 어떤 건 카멜 케이스로, 어떤 건 한국어로. 작업하던 그 순간의 손에 잡히는 대로 이름을 붙여왔던 거죠. 한 사람이 작업할 때는 그 직감이 곧 규칙이었지만, Figma 파일이 일종의 문서라면, 그 문서는 사실 제 머릿속에만 있는 약속에 기대고 있었던 셈입니다.
문제는 명확했습니다. 시스템이 의도를 말하지 못하고 있다. 디자이너의 의도는 화면에 분명히 담겨 있지만, 그 의도가 시스템의 언어로 적혀 있지 않았습니다. 의도가 적혀 있지 않으면 AI는 추론할 수 없고, 사람도 매번 묻거나 추측해야 합니다. 'AI도 잘 읽는다'는 결국 '사람도 잘 읽는다'와 같은 말이었습니다.
그래서 작업의 방향을 이렇게 잡았습니다.
모든 색, 모든 글자, 모든 컴포넌트의 이름에 ‘의도’와 ‘규칙’을 담기게 하자.
20일이라는 시간 안에 다른 프로젝트를 동시에 병행하면서 모든 걸 완벽하게 만들 수는 없었습니다. 하지만 적어도 이 방향성만큼은 흔들리지 않게 토대를 놓고 떠나자고 다짐했습니다. 작업은 큰 그림부터 시작해 점점 작은 단위로 내려갔습니다. 파운데이션 → 토큰 → 컴포넌트 순으로요.
1단계 : 파운데이션 — 디자인의 가장 깊은 약속 해
컬러 : 풀리캠퍼스의 보라, 그리고 그 너머의 팔레트
풀리캠퍼스 LXP 디자인 시스템 v1.0 TO-BE
가장 먼저 손댄 건 컬러였습니다. 풀리캠퍼스의 기존 브랜드 색인 Purple은 그대로 가져가되, 그 주변을 어떤 색으로 채울지가 진짜 고민이었습니다. 여러 후보를 늘어놓고 며칠을 들여다봤습니다. 결국 선택은 토스의 Grey 계열과 유사한 색 패밀리를 함께 가져와 풀리캠퍼스에 맞도록 튜닝하는 것이었습니다. 이 결정에는 두 가지 이유가 있었습니다.
첫 째, 토스의 Grey는 단순히 회색이 아닙니다. 채도가 살짝 살아있으면서 차가운 듯한 뉴트럴 컬러예요. 풀리캠퍼스의 보라색이 갖는 약간의 차가운 톤과 잘 어울렸습니다. 둘 째, 우리 제품은 교육 도메인입니다. 대학생과 교수님이 매일 들여다보고 신뢰를 가져야 하는 화면이죠. 토스의 Grey 팔레트가 가진 '오래 봐도 피로하지 않은 차분함'이 그 사용 맥락에 맞다고 봤습니다. 그래서 Sub로 해당 Grey 컬러를 적용했죠.
여기에 Light Blue, Teal, Green, Orange, Red를 더해 총 8개의 컬러 패밀리를 갖췄습니다. 각 패밀리는 5부터 90까지의 단계(Grey만 0~100)를 갖고, Alpha White와 Alpha Grey가 별도로 존재합니다. 같은 보라색이라도 왜 이렇게 많은 단계가 필요할까요? 마이크로한 Hierarchy와 Interaction 때문입니다. 텍스트의 강조와 본문, 배경의 강함과 약함, 호버와 프레스 상태. 이 모든 미세한 차이를 표현하려면 색 하나로는 부족합니다. 색을 '명사'가 아니라 '리듬'으로 다뤄야 하는 거죠.
타이포 : 읽기의 리듬을 설계하기
타이포는 Pretendard JP를 골랐습니다. 한국어와 영어, 일본어까지 모두 지원하는 무료 글꼴이죠. 한국어 본문에서 가장 신뢰받는 모던 산세리프 중 하나이고, 자획의 두께와 글자 너비가 안정적이어서 오래 읽어도 피로하지 않습니다. 학습 콘텐츠를 다루는 우리 제품에 꼭 필요한 특성이었어요. 그리고 다국어 지원이라는 점이 결정적이었습니다. 풀리캠퍼스 LXP는 추후 일본어 환경까지 염두에 두고 있어서, 한 가지 글꼴로 세 언어가 같은 인상을 유지할 수 있다는 점이 큰 매력이었습니다.
타이포 위계는 KRDS(Korea Design System)의 가이드를 따랐습니다. Display 1부터 Caption 2까지 11단계. 처음에는 단계가 너무 많다고 느꼈지만, 작업을 진행할수록 이 11단계가 정확한 간격을 갖고 있다는 걸 알게 됐습니다.
•
Display 60/44/36px — 랜딩 페이지의 거대한 헤드라인
•
Title 32/28/24px — 페이지 제목
•
Heading 22/20/18px — 컨테이너 제목
•
Body 18/16/14px — 본문
•
Label 14/13px — 인터페이스 레이블
•
Caption 12/11px — 보조 정보
여기서 의도적으로 신경 쓴 부분이 디바이스별 자동 분기입니다. 같은 'Title 1'이라도 Desktop과 Tablet-Horizontal에서는 32px, Tablet-Vertical과 Mobile에서는 28px로 자동으로 작아집니다. 디자이너가 매번 "이건 모바일에서 몇 px로 줄여야 할까"를 고민하지 않아도 되도록. 그리고 사용자는 디바이스가 달라져도 같은 위계의 글자를 만나게 됩니다. 반응형의 일관성은 결국 이 위계가 흔들리지 않을 때 완성됩니다.
행간은 모든 단계에서 150%, 자간은 0px로 통일했습니다. 굳이 변경을 주지 않은 이유는, 읽기의 리듬은 일관성에서 나온다는 원칙 때문이었습니다.
래디우스 : 엘리먼트의 높이와 둥글기를 한 세트로
마지막으로 손댄 건 요소의 둥글기 값이었습니다. 어떻게 보면 가장 간단해 보이는 요소인데, 그 간단함 속에 한 가지 함정이 숨어 있어요. 흔히 볼 수 있는 인풋 입력과 버튼처럼 서로 다른 엘리먼트가 조합될 때 래디우스가 조금이라도 어긋나면, 한 세트로 보여지지 않습니다. 높이 40px의 버튼 옆에 높이 32px의 인풋이 붙어있는데 둘 다 같은 래디우스를 쓰면, 사용자 눈에는 묘하게 이상해 보입니다.
그래서 래디우스 Semantic 토큰을 엘리먼트의 실제 높이 픽셀 단위로 이름을 지었습니다.
semantic / element-size
- 12 → primitive/4
- 16 → primitive/4
- 20 → primitive/6
- 24 → primitive/6
- 32 → primitive/8
- 40 → primitive/10
- 48 → primitive/12
- 56 → primitive/14
- 64 → primitive/14
- 72 → primitive/16
- 80 → primitive/16
- 400 → primitive/20
- 1000 → primitive/40
JSON
복사
일반적이라면 Small / Medium / Large 같은 추상적 단어를 썼겠지만, 일부러 숫자가 드러나는 이름을 골랐습니다. 디자이너가 높이 32px의 인풋을 만들 때, 바로 자연스럽게 radius-32 토큰을 떠올릴 수 있도록이요. 이름을 고르는 일이 곧 구조를 만드는 일이라는 걸 여기서도 느꼈습니다.
이렇게 해둔 덕분에, 높이 40px의 엘리먼트는 어디서든 같은 래디우스를 갖게 됩니다. 높이 32px의 엘리먼트도 마찬가지고요. 디자이너가 매번 "이 컴포넌트의 래디우스는 몇이었더라…"를 외울 필요가 없어지고, 서로 다른 요소가 나란히 놓여도 둥글기가 동일하게 맞아 떨어집니다. 눈에 띄는 이상함은 대개 이런 미세한 어긋남에서 오는데, 그 가능성을 시스템 차원에서 아예 차단한 셈이죠.
아이콘 : 0.6px이 인상을 바꾼다
아이콘은 24x24px(Medium)을 표준으로 두고, 12px부터 40px까지의 사이즈 베리에이션을 만들었습니다. 유형은 세 가지로 분류했습니다.
icon-info-line // 라인 타입 (2px)
icon-info-bold // 볼드 타입 (2.6px)
icon-info-filled // 솔리드 타입
JSON
복사
이 Stroke 두께 2px과 2.6px의 차이가 사실 아이콘 디자인에서 가장 까다로운 부분입니다. 2px은 일반적인 라인 아이콘의 무게입니다. 잘 보이면서 정돈된 느낌이죠. 그런데 어떤 컨텍스트에서는 이게 너무 약하게 보입니다. 강조가 필요한 자리, 작은 사이즈로 줄였을 때, 또는 배경 위에서 또렷이 보여야 할 때. 그렇다고 3px로 가면 너무 무거워집니다. 2.6px는 그 사이의 미묘한 균형점입니다. 충분히 강하지만 거칠지 않은. 이 0.6px의 차이가 아이콘 전체의 인상을 바꾼다는 걸 작업하면서 새삼 느꼈습니다.
2단계 : 토큰 체계 — 이름에 의도를 담는 일
파운데이션이 정리되자, 다음 과제는 그 색과 글자와 아이콘을 어떤 이름으로 부를 것인가였습니다. 사실 이 단계가 이번 시스템의 핵심이었어요. 시스템이 '의도'를 말하게 만드는 일은 결국 이름 짓기의 문제니까요.
컬러 토큰 : Primitive와 Semantic의 2계층
컬러는 다음과 같이 두 개의 층으로 나눴습니다.
•
Primitive Color: color-primitive-purple-50, color-primitive-grey-80처럼 순수한 색값입니다. 디자이너의 색상 사전에 가까운 층이고, 화면에는 직접 쓰이지 않습니다.
•
Semantic Color: color-semantic-text-primary, color-semantic-fill-danger, color-semantic-line-disable처럼 역할을 이름에 담은 층입니다. 화면에는 최대한 이 층의 토큰만 씁니다.
Semantic 토큰은 color-semantic-{카테고리}-{역할} 형태로 통일했습니다. 카테고리는 Icon, Text, Fill, Line, Background, Opacity, Gradient — 일곱 가지. 역할은 Primary, Strong, Normal, Sub, Muted, Disable, Inverse, Success, Danger, Warning, Accent로 정리했습니다. 이 두 단어의 조합만으로 화면 위의 거의 모든 색을 부를 수 있게 됩니다. color-semantic-icon-danger를 보면 별도 설명 없이 "위험을 알리는 아이콘에 쓰는 색"이라는 걸 알 수 있죠. AI 역시 이 이름을 읽고 같은 맥락을 추론할 수 있습니다.
그런데 가장 어려웠던 디자인 과제는 따로 있었습니다. 풀리캠퍼스 LXP는 학교별로 시그니처 컬러를 다르게 적용할 수 있어야 한다는 것. 어떤 학교는 파랑, 어떤 학교는 초록, 어떤 학교는 빨강이 상징색입니다. 그 학교 학생들이 우리 제품에 들어왔을 때, 자기 학교의 색을 만나야 했습니다.
이게 왜 디자인 과제냐면, 단순히 변수를 바꾸는 일이 아니기 때문입니다. Primary가 빨강으로 바뀌어도 Danger의 빨강과 충돌하지 않아야 합니다. Primary가 초록으로 바뀌어도 Success의 초록과 헷갈리지 않아야 합니다. 그래서 Primary 토큰은 Primitive의 40~80 넘버 안에서만 지정될 수 있도록 제약을 걸었습니다. 너무 연하지도, 너무 진하지도 않은 중간 톤에서만 학교 색을 받아들이는 거죠. 그리고 Success, Danger, Warning은 미리 충돌하지 않는 안전한 톤으로 고정해 두었습니다. 시스템이 디자이너의 미감을 대신 지켜주는 구조. 이번 작업에서 가장 신경 쓴 부분 중 하나입니다.
Gap : 같은 단어, 다른 값
Figma의 변수 기능을 활용해 컬러 외의 수치들도 시스템으로 끌어올렸습니다. Color, Gap, Padding, Radius, Pixel, Margin, Device Frame, Break Point — 여덟 개의 컬렉션으로 분리했고, 필요한 것에 Primitive와 Semantic 그룹으로 나눴습니다. 여기서 가장 신경 쓴 디자인 결정은 같은 아이콘 또는 버튼 요소여도 사이즈에 따라 서로 배열할 때 다른 Gap 값을 주도록 한 것이었습니다.
semantic / icon
- xxsmall → primitive/gap/2
- xmall → primitive/gap/4
- medium → primitive/gap/6
semantic / button
- xsmall → primitive/gap/6
- small → primitive/gap/8
- medium → primitive/gap/10
JSON
복사
같은 아이콘끼리 나란히 놓일 때도 그 아이콘의 사이즈에 따라 Gap이 달라야 하고, 버튼끼리 몇 개를 나란히 놓을 때도 마찬가지입니다. 요소가 커질수록 그들 사이의 여백도 비례해 커져야 시각적으로 같은 '여유'를 갖습니다. Xxsmall 아이콘 세 개를 8px 간격으로 놓으면 터무니없이 넓게 느껴지지만, 작은 아이콘은 개별 사이즈가 작으니 2px의 간격도 이미 절제된 여유로 다가옵니다. 버튼도 마찬가지로, Small 버튼끼리의 8px과 Medium 버튼끼리의 10px은 사용자 눈에는 같은 '여유의 정도'로 읽힙니다.
이걸 모든 배열에 같은 Gap을 쓰게 두면, 작은 아이콘 사이는 적절해 보이고 큰 버튼 사이는 답답해 보입니다. 디자이너가 그걸 눈치채고 일일이 다시 손보면, 시스템의 일관성은 그 순간 깨집니다.
Description : 사람을 위한 친절이 AI에게도 자산이 되다
파운데이션과 토큰 체계를 잡는 데 소요된 시간의 상당 부분은 사실 피그마 Variables에 Semantic 값을 등록하고, 각 변수와 컴포넌트에 Description을 채우는 작업에 들어갔습니다. 솔직히 가장 시간이 오래 걸린 일이었어요.
예를 들어, color-semantic-fill-danger라는 토큰에 이런 설명을 달아뒀습니다. "사용자에게 위험이나 경고를 알리는 Fill 용도. 삭제 확인 모달의 Weak 버튼 등에 쓰입니다." checkbox-group 컴포넌트에도 사용 맥락과 몇 개 이상 선택 가능 여부 등을 적어두었죠. 처음 이 작업을 시작한 이유는 온전히 디자이너와 개발자 동료를 위한 친절이었습니다. 새로 합류한 동료가 어떤 토큰을 골라야 할지 고민할 때, 변수를 클릭하면 바로 설명이 뜰 수 있도록. "우리는 이 색을 이런 경우에 이런 의도로 씁니다"라고 문서가 스스로 말해주도록 만들고 싶었어요.
그런데 작업을 진행하다 보니 예상치 못한 지점에서 깨달음이 왔습니다. Description이 사람에게 도움이 되는 건 물론, AI에게는 훨씬 더 강력한 자산이 된다는 사실이요. 생각해보면 당연합니다. AI는 토큰 이름만으로도 danger가 부정적 의미라는 건 추론할 수 있지만, "삭제 확인 모달의 주 버튼, 오류 알림 배경 등에 쓰입니다"라는 구체적 맥락까지 읽으면 "이 버튼에는 fill-danger를 써주세요"라는 지시를 훨씬 정확하게 따르게 됩니다. 일종의 메타 데이터가 되는 거죠. 디자이너에게 친절하게 적어둔 한 줄의 설명이, 가장 훌륭한 AI 프롬프트 재료가 된 것이죠.
사람을 위한 친절이 결국 AI에게도 가장 좋은 자산이 된다는 것. 이게 이번 작업에서 가장 뜻깊게 다가온 깨달음이었습니다. 결국 'AI 친화적'이란 '사람에게 친절한' 것의 다른 이름이었습니다.
3단계 : 컴포넌트 — 약속을 요소로 만들기
토큰 체계가 잡히자, 비로소 컴포넌트를 다듬을 수 있었습니다. 사실 이 순서가 중요했어요. 컴포넌트부터 만들기 시작하면 결국 그 컴포넌트 안의 색과 여백이 즉흥적으로 결정되고, 그게 다시 일관성을 무너뜨립니다. 토큰이 먼저 있어야 컴포넌트가 그 위에 체계적으로 일관성 있게 올라갈 수 있습니다.
어떤 인상의 화면을 만들 것인가
컴포넌트 설계는 Shadcn을 기준으로 잡았습니다. 여기에 KRDS, Wanted Design System, Toss Design System을 레퍼런스로 함께 봤습니다. (이 부분은 LXP 담당 프로덕트 디자이너 이연재쌤, 프론트엔드 고민영쌤과 사용 컴포넌트를 함께 빠르게 협의하여 결정했습니다.)
왜 이 조합이었는가, 사실 이게 디자인 시스템의 '인상'을 정하는 일이었습니다.
•
Shadcn은 절제된 미니멀의 기준점입니다. 화려하지 않고, 군더더기가 없고, 어떤 브랜드에도 잘 얹힙니다. 학교별로 컬러가 바뀌어야 하는 우리 제품의 특성에 정확히 맞는 베이스였어요.
•
KRDS는 한국 정부 디자인 시스템입니다. 우리는 교육 도메인이고, 교육은 공공성과 떼어놓을 수 없습니다. 정보 위계, 접근성, 명료한 레이블링 등 KRDS가 잘 다루고 있는 가치들이 우리 제품에도 필요했어요.
이 네 가지를 함께 본 결과, 우리가 그리고자 한 컴포넌트의 인상은 "공적인 신뢰감과 일상의 친근함 사이"였습니다. 너무 차갑지도, 너무 가볍지도 않은 중간 어딘가. 그것이 교육 서비스에 어울리는 톤이라고 봤습니다.
네이밍 : Figma 밖에서도 같은 이름
네이밍은 케밥 케이스(kebab-case)로 통일했습니다.
checkbox-atomic
checkbox-button
checkbox-group
JSON
복사
-atomic 접미사는 가장 작은 단위의 컴포넌트를 가리킵니다. 예를 들어 checkbox 안의 개별 체크박스 한 칸 같은 요소죠.
왜 케밥 케이스였는가 하면, 이유는 단순합니다. Figma 밖으로 나갔을 때 변환 없이 그대로 쓰일 수 있는 형식이기 때문이었습니다. CSS 속성도, 많은 코드 베이스의 컴포넌트 파일명도 케밥 케이스입니다. Figma의 이름이 그대로 코드의 이름이 되고, 다시 그대로 AI에게 전달되는 — 이 '단어의 일관성'이 시스템의 핵심이라고 봤습니다.
또 다른 선택지로 button/primary/hover 같은 슬래시(/) 방식도 고민했습니다. Figma에서 자동으로 폴더처럼 그룹핑되고, AI에게 계층 구조를 더 명시적으로 전달할 수 있다는 장점이 있죠. 다만 이번 v1.0에서는 'Figma 밖에서도 같은 이름'이라는 원칙을 우선해 하이픈으로 통일했습니다.
30여 개의 컴포넌트를 다듬으며
Accordion, Avatar, Alert Dialog, Badge, Breadcrumb, Button, Checkbox, Dialog, Dropdown, Input, Infobox, Pagination, Progress Bar, Radio, Scroll, Slider, Switch, Table, Tabs, Tooltip 등 약 30여 개의 컴포넌트와 사용가이드를 다듬어야 했습니다. 빠듯한 일정이었지만 한 가지 원칙은 지키려고 했어요. 각 컴포넌트가 토큰을 정직하게 사용하게 만들자. 어디 하나라도 토큰 없이 색이나 여백이 박혀 있으면, 그건 또 예전과 같은 직감의 시작이 될 테니까요.
작업을 진행하면서 LXP 담당 이연재쌤과 프론트엔드 고민영쌤, 백경민쌤께 수시로 여쭤봤습니다. "이 컴포넌트가 실제로 쓰이는 맥락은 어떤가요?", "이 변형이 정말 필요한가요?", "추가 제작이 필요한 컴포넌트가 있을까요?" 같은 질문들이었어요. 혼자 작업할 때는 한 번도 묻지 않았던 질문들이었습니다.
작업 이후 : 쌤들로부터 받은, 디자인 시스템의 검증
작업을 끝내고 LXP 담당 쌤들께 완성된 시스템을 공유드렸습니다. 제 손을 떠난 시스템이 실제 업무 안에서 어떻게 흐르는지, 혼자 작업하던 시절에는 확인해볼 수 없었던 한 장면이었죠. 며칠 뒤 쌤들로부터 기대 이상의 피드백이 도착했습니다.
"디자인 시스템을 도입하기 전과 후의 작업 효율은 체급 자체가 달라진 것 같아요."
"잘 닦인 아스팔트 고속도로가 깔린 기분입니다. 걱정 없이 그저 드라이브만 걸면 되니까 정말 든든해요."
그리드, 타이포그래피, 컬러, 간격과 라운드 값을 고를 때마다 겪던 망설임이 사라졌고, 공통의 컴포넌트 언어로 소통하게 되면서 협업의 마찰이 눈에 띄게 줄었다는 생생한 후기들이었습니다. 지난 20일간 밤낮으로 고민했던 모든 수고가 한순간에 보상받는 기분이었습니다. 디자인 시스템은 만드는 사람의 만족이 아니라, 쓰는 사람의 효율로 검증된다는 걸 새삼 느꼈습니다.
하지만 저를 가장 전율케 한 진짜 피드백은 따로 있었습니다. 바로 "AI가 디자인 시스템을 잘 읽고 있어요." 라는 말씀이었어요. 작업 이후 쌤들이 화면을 개발할 때 AI가 우리 토큰과 네이밍 규칙을 잘 따라온다는 걸 경험하셨다고요. 이 피드백이 가장 떨린 순간이었습니다. AI 프리로, 온전히 동료를 위해 만든 시스템이 결국 AI에게도 친절한 시스템이 되어 있더라는 그 긴 가설이, 쌤들의 실제 경험 속에서 검증된 순간이었으니까요.
아직 끝내지 않은 태스크
이번 v1.0은 AI가 잘 읽을 수 있는 디자인 시스템을 Figma 위에 구축한 단계까지입니다. 실제로 이 시스템을 AI 워크플로우에 연결해 Figma 파일을 AI가 직접 읽고 우리 토큰으로 코드를 생성하거나, 새 화면을 제안하게 만드는 단계까지는 진행하지 못했습니다.
하지만 그 다음 단계로 가기 위해 이 작업이 반드시 선행되어야 했습니다. 토대가 흔들리는 상태에서 자동화를 올리면, 자동화는 부정확함을 빠르게 퍼뜨리는 도구가 되어버립니다. 색과 글자와 비례에 의도가 담겨 있어야, 그 위에 어떤 자동화를 올려도 디자인의 결이 흔들리지 않습니다.
남겨두고 가는 다음 태스크는 이렇습니다.
•
Code Connect 연동: Figma의 컴포넌트와 실제 코드 베이스의 컴포넌트를 같은 이름으로 묶어, 디자인과 코드 사이의 '단어의 일치'를 코드 레벨까지 확장하기
•
MCP 기반 AI 협업 실험: 우리 시스템의 토큰만 사용해 바이브로 새 화면을 제안하게 하기
이 다음 챕터는 풀리캠퍼스 LXP 클라이언트 쌤들이 함께 이어가실 거라 믿습니다. 그동안 함께 작업하며 보여주신 깊은 이해와 애정이 있다면, 이 시스템 v1.0은 분명 더 좋은 모습으로 업데이트 될 거예요.
마치며 : 사람을 위한 친절이, 결국 AI에게도 답이었다
지난 20일을 돌아보면, 제가 그동안 한 일은 사실 하나로 요약됩니다. 남겨질 동료들이 조금이라도 더 수월하게 일할 수 있도록, 머릿속의 약속을 파일 위에 옮겨 적어둔 일이었습니다. 토큰의 이름을 고르고, 컴포넌트의 범위를 다듬고, 변수마다 Guide와 Description을 채우는 그 모든 작업은 처음부터 끝까지 사람을 위한 친절과 책임감이었습니다. 새로 합류할 동료가 몇 시간을 덜 고민하고, 개발 동료가 한 번 덜 질문하고, 이어서 디자인하는 팀이 조금이라도 더 빨리 움직일 수 있기를 바라는 마음으로요.
그런데 작업을 마치고 돌아보니 뜻밖의 결론이 하나 남습니다. 온전히 동료를 위해 쓴 그 모든 친절이, 결국 AI에게도 가장 강력한 자산이 되어 있더라는 것. 이건 작업을 시작할 때는 전혀 예측하지 못했던 부분이었어요.
동료가 토큰 이름을 보고 의도를 읽을 수 있도록 고심해 고른 이름은, AI가 따라 부르기도 딱 좋은 이름이었습니다. 동료가 설명 없이도 어디에 쓰이는지 이해하도록 채우고자 했던 Description은, AI에게는 고스란히 프롬프트 재료가 되었습니다. 동료가 컴포넌트 구조를 직관적으로 이해하도록 따져둔 네이밍 규칙은, AI가 계층 관계를 추론하는 단서가 되었고요. 따로 준비한 게 아니라, 동료를 위해 준비한 모든 것이 그대로 AI에게도 준비되어 있었던 거죠.
사실 이게 이번 프로젝트의 제목이 왜 'AI에게도 친절한 디자인 시스템'인지를 설명해주는 대목이기도 합니다. 처음부터 "AI를 위한 시스템을 만들자"고 시작한 게 아니에요. 동료를 위해 정성스럽게 만든 시스템이, 결과적으로 AI도 함께 읽을 수 있는 시스템이 되어있더라는 이야기입니다. 주어가 뒤바뀐 거죠.
그래서 제가 이번에 배운 가장 소중한 한 문장은 이겁니다.
동료를 아끼면, 시스템은 자연스럽게 AI에게도 친절해진다.
이전의 저는 디자인 라이브러리 정도밖에 다뤄보지 못한 미들 프로덕트 디자이너였습니다. 이번 20일을 거치며 진짜 의미의 디자인 시스템을 처음 경험했고, 그 안에서 디자이너로서 한 단계 자라난 것 같습니다. 이 모든 게 풀리라는 좋은 조직과 동료들이 있었기에 가능했습니다.
이제 저는 매쓰플랫팀에서 또 다른 디자인 시스템을 만나게 됩니다. 더 크고 많은 규모의 사용자가 매일 만나는 화면 위에서, 이번에 배운 모든 것을 다시 한 번 풀어내고 싶습니다. 동료를 아끼는 디자인 시스템, 그리고 그 결과로 AI와도 자연스럽게 대화하는 디자인 시스템 그 다음 챕터를 매쓰플랫에서도 이어 가겠습니다.
