당신의 디자인 시스템은 AI에 친화적이지 않습니다
AI 시대를 살아가는 디자이너를 위한 객체지향적 사고 실무 가이드
*원문 출처를 번역한 글입니다.
어떤 기분인지 다들 아실 겁니다.
AI 도구를 써서 레이아웃을 빠르게 하나 뽑아봅니다. 스크린샷으로 볼 때는 아주 완벽해 보이죠.
하지만 막상 실제로 써보려고 하면 모든 게 엉망진창이 됩니다.
'버튼'은 그냥 파란색 사각형일 뿐입니다. 간격은 디자인 토큰이 아니라 픽셀값으로 하드코딩되어 있죠. 카드처럼 보이는 컴포넌트는 실제 시스템의 카드 컴포넌트와는 아무런 연결 고리도 없습니다.
결국 다음 한 시간 동안 레이어 이름을 다시 바꾸고, 가짜 컴포넌트들을 지우고, 모든 요소를 실제 디자인 시스템에 다시 연결하느라 진을 뺍니다.
AI는 우리를 더 빠르게 만들어줘야 했습니다. 그런데 현실은 디자인 시스템의 뒷정리나 하는 청소부가 된 기분이죠.
당신 잘못이 아닙니다. 시스템의 문제입니다.
불편한 진실을 하나 말씀드릴까요? 지금의 디자인 시스템은 기계가 아니라 사람을 위해 만들어졌습니다.
우리가 버튼을 볼 때는 즉각적으로 그 의미를 이해합니다. 맥락을 파악하는 것이죠. 이 버튼이 결제 액션이라는 것, 클릭하기 전에 유효성 검사가 필요하다는 것, 그리고 장바구니에 상품이 담기기 전까지는 비활성화되어야 한다는 점을 우리는 이미 알고 있습니다. 경험과 비즈니스 규칙, 그리고 패턴 인식을 통해 이 모든 것을 학습했기 때문입니다.
반면 AI가 똑같은 버튼을 볼 때, AI의 눈에 보이는 건 그저 '모서리가 둥근 파란색 사각형'뿐입니다.
그게 전부죠.
AI는 이것이 결제 버튼인지 모릅니다. 장바구니 유효성 검사도 모르죠. 'Primary'가 '페이지에서 가장 중요한 액션'을 의미한다는 사실도 모릅니다. AI는 그저 도형, 색상, 텍스트만을 볼 뿐입니다.
이건 버그가 아닙니다. AI 모델이 작동하는 방식과 대부분의 디자인 시스템이 구조화된 방식 사이의 근본적인 불일치 때문에 발생하는 문제입니다.
The Semantic Gap
이 문제에는 '시맨틱 갭'이라는 이름이 붙어 있습니다. 디자인이 '보이는 모습'과 디자인이 '의미하는 바' 사이의 단절을 뜻하죠.
우리가 '시맨틱'이라고 말할 때는 단순히 겉모습만이 아니라, 그 대상이 무엇인지, 어떤 동작이 허용되는지, 그리고 다른 요소들과 어떤 관계를 맺고 있는지를 의미합니다.
현재의 AI 디자인 도구들은 주로 스크린샷과 markup 데이터를 통해 학습됩니다. 그래서 시각적인 패턴을 인식하는 데는 능숙하죠. 폼이 어떻게 생겼는지, 카드는 주로 어떻게 배치되는지, 네비게이션은 어디에 위치하는지 같은 것들 말입니다.
하지만 AI가 명확히 보지 못하는 것은 그 이면에 깔린 '비즈니스 로직'입니다. 실제로 이러한 간극은 다음 세 가지 영역에서 두드러지게 나타납니다.
토큰의 간극
여러분의 디자인 시스템은 시맨틱 토큰을 사용합니다.
color.primary.500
spacing.xl
radius.md
여기에는 제작자의 의도가 담겨 있죠. 예를 들면 "브랜드 Primary 컬러", "넓은 간격", "중간 크기의 곡률" 같은 것들입니다.
반면 대부분의 AI 레이아웃 도구는 기본적으로 원시 값(raw values)을 다룹니다.
#0055FF
24px
8px
결과물은 똑같아 보일지 몰라도, 브랜드 컬러가 바뀌거나 간격 시스템을 조정하는 순간 문제가 터집니다. AI가 만든 UI는 실제 시스템과 전혀 연결되어 있지 않으니까요.
컴포넌트의 간극
시스템에는 이미 특정 속성을 가진 'Card' 컴포넌트가 존재합니다.
showImage: boolean
variant: "default" | "compact"
하지만 AI는 종종 사각형, 텍스트, 이미지를 그저 하나로 묶어버리곤 하죠. 시각적으로는 카드처럼 보일 수 있습니다. 하지만 구조적으로는 그저 '그룹'일 뿐입니다. 실제 카드 컴포넌트의 속성을 상속받지 않기 때문에, 진짜 카드 컴포넌트를 업데이트해도 AI가 만든 결과물에는 아무런 변화가 없습니다.
겉만 번지르르할 뿐, 시스템의 일부는 아닌 셈이죠.
상태(State)의 간극
여러분의 시스템은 다양한 상태를 고려합니다.
Loading
Error
Empty
Disabled
Hover
Focus
하지만 AI는 주로 '이상적인 시나리오'만 생성하는 경향이 있습니다. 모든 필드가 채워진 완벽한 폼, 에러도 없고, Empty 상태도 없으며, 비활성화된 액션도 없는 아주 이상적인 상태 말이죠.
나머지 80%, 즉 실제로 버그 리포트가 쏟아지는 골치 아픈 케이스들을 처리하는 건 여전히 디자이너의 몫으로 남아 있습니다.
기분 탓이 아닙니다. 여러분이 느끼는 그 불편함은 실재합니다.
요즘 디자이너들이 AI에 대해 나누는 이야기들을 들어보면 흥미로운 패턴이 발견됩니다.
리더들은 'AI 보조 디자인'이나 '에이전트 네이티브 시스템'을 논합니다.
툴 제조사들은 무대 위에서 AI가 생성한 아름다운 UI 데모를 선보이죠.
하지만 실무자들은 뒷정리와 재연결 작업, 그리고 "우리 시스템이랑 전혀 맞지 않아요"라는 고충을 토로합니다.
2025년 디자인 시스템 현황을 조사하면서 두 가지 이슈가 계속해서 언급되었습니다.
시각 레이어에서의 '토큰 피로도' — 너무 세분화된 토큰과 배리언트의 홍수 속에 팀들이 매몰되고 있습니다.
제품 레이어에서의 '시맨틱의 간극' — 겉모습은 정의하지만, 그 의미나 동작 방식은 담아내지 못하는 시스템의 문제입니다.
"AI에게는 시맨틱과 맥락이 중요하다"라는 말에는 다들 어느 정도 동의합니다. 하지만 컴포넌트로 가득 찬 피그마 파일을 보고 있으면, 그것이 구체적으로 무엇을 의미하는지 감을 잡기 어렵죠.
이제 그 실체를 구체적으로 파헤쳐 봅시다.
문제는 AI가 아닙니다. 우리의 멘탈 모델이 문제죠.
우리가 시스템을 구축해 온 방식을 떠올려 보세요.
Atoms → molecules → organisms
Buttons, cards, modals, forms
Atomic Design은 우리에게 '원자(Atoms) → 분자(Molecules) → 유기체(Organisms)'라는 시각적 위계 구조를 심어주었습니다.
우리는 '어떻게 보이는가'를 중심으로 시스템을 조직합니다. 디자인 시스템의 주요 사용자가 사람(컴포넌트를 고르는 디자이너, 이를 구현하는 개발자)이었을 때는 이 방식이 아주 효과적이었습니다.
하지만 AI는 시각적인 요소를 인식하는 데 큰 도움이 필요하지 않습니다. "이건 버튼처럼 생겼네"라고 알아채는 건 이미 충분히 잘하니까요.
AI가 정말 힘들어하는 지점은 바로 '의미'를 파악하는 것입니다.
이 버튼은 어떤 객체에 작용하고 있나요?
그 객체는 현재 어떤 상태인가요>
이 요소가 지금 할 수 있는 일과 없는 일은 무엇인가요?
이 화면이 제품의 나머지 부분과 어떻게 연결되나요?
겉모습(컴포넌트)을 기준으로 정리하는 대신, '객체(Object)'와 그 '동작'을 중심으로 정리해야 합니다.
단순히 컴포넌트가 아니라 '객체'로 사고하세요.
구독 대시보드를 예로 들어보겠습니다.
컴포넌트 중심의 사고방식에서는 이렇게 말하곤 합니다.
“여기에 카드 하나가 필요해요.”
“저기에는 버튼을 넣고요.”
“하단에는 테이블을 배치합시다.”
반면 객체지향 사고방식에서는 이런 질문부터 시작합니다.
“우리에게는 ‘Subscription’이라는 객체가 있습니다.”
이 구독 객체는 status를 가집니다: trialing, active, past-due, canceled.
capabilities도 가지고 있죠: 일시 정지, 업그레이드, 취소.
relationships도 형성합니다: 특정 유저에게 속하고, 플랜에 연결되며, Invoices을 생성합니다.
이제 여러분의 UI 요소들은 서로 다른 맥락에서 보여지는 동일한 객체의 'View'가 됩니다.
리스트에 노출되는 '구독 카드'
'구독 상세' 레이아웃
정보를 수정할 때 사용하는 '구독 폼'
디자인 시스템이 단순한 비주얼을 넘어 이러한 객체 로직을 담게 되면, AI는 훨씬 더 유용한 정보를 바탕으로 작업할 수 있습니다.
'연체된 구독'은 경고 메시지와 '결제 해결' 액션이 필요하다는 것을 암시합니다.
'취소된 구독'에는 '업그레이드'나 '일시 정지' 컨트롤이 보이지 않아야 함을 뜻하죠.
송장 리스트는 단순히 모든 데이터를 보여주는 대신 '구독 ID(subscriptionId)'를 기준으로 필터링될 수 있습니다.
이제 여러분은 AI에게 픽셀을 보고 의미를 추측하라고 강요하지 않아도 됩니다. AI에게 '의미'를 직접 전달하고 있으니까요.
피그마에서는 어떻게 적용할 수 있을까요?
이러한 이점을 누리기 위해 기존 디자인 시스템을 통째로 버릴 필요는 없습니다.
변화는 '이름을 짓는 방식'과 '시맨틱을 어디에 부여할 것인가'에서부터 시작됩니다.
1. 객체 이름을 명확하게 지정하세요.
일반적인 ‘Card’ 대신 ‘구독 카드(SubscriptionCard)’처럼 만드세요.
SubscriptionCard
InvoiceRow
UserSummary
단순한 UI 껍데기가 아니라 실제 제품의 객체를 반영하는 이름을 사용해야 합니다. 이는 협업하는 동료는 물론, 여러분의 파일을 읽는 AI 에이전트에게도 큰 도움이 됩니다.
2. 베리어블을 속성(Attributes)으로 취급하세요.
피그마 변수를 사용해 객체의 실제 속성을 표현해 보세요.
subscription.status = trialing | active | pastDue | canceled
subscription.isManaged = true | false
user.role = admin | manager | viewer
invoice.amountDue
이제 '상태 배지'는 단순한 색상 선택의 문제가 아닙니다. 시맨틱 값과 직접적으로 연결된 데이터가 됩니다.
3. 컴포넌트 프로퍼티를 기능(Capabilities)으로 활용하세요.
컴포넌트 프롭스를 통해 이 맥락에서 객체가 무엇을 할 수 있는지 표현하세요.
canCancel
canUpgrade
hasOutstandingBalance
showUsageMetrics
이는 단순한 레이아웃 수정용 옵션이 아니라, 실제 동작 및 권한 설정과 직접 연결됩니다.
4. 크기가 아닌 '상태'를 중심으로 배리언트를 만드세요.
물론 [size = small | medium | large] 같은 시각적 배리언트도 여전히 필요합니다. 하지만 핵심 축은 실제 제품의 상태와 일치해야 합니다.
status = trialing | active | pastDue | canceled
mode = readOnly | editable
view = listItem | detail | summary
이제 여러분의 컴포넌트는 단순히 어떻게 보이는가를 넘어, 제품이 실제로 어떻게 작동하는지에 맞게 정렬됩니다.
파일을 이런 식으로 구조화하면 다음과 같은 변화가 생깁니다.
개발자들은 자신들의 도메인 모델을 그대로 투영한 UI를 보게 됩니다.
AI는 픽셀을 보고 추측하는 대신 객체, 속성, 상태로 이루어진 명확한 구조를 파악할 수 있습니다.
사람들의 머릿속에만 갇혀 있거나 지라 티켓 여기저기에 흩어져 있던 로직들이 겉으로 드러나게 됩니다.
객체지향 디자인 시스템(OODS)이 필요한 이유
지금까지 말씀드린 모든 내용은 제가 작업해 온 시스템인 'OODS Foundry'의 배경이기도 합니다.
OODS를 설계하며 엔터프라이즈 디자인 시스템들을 조사한 결과, 한 가지 공통된 패턴을 발견했습니다. 모두가 컴포넌트와 토큰을 만드는 데는 선수급이지만, 비즈니스 의미를 구조화된 방식으로 코드화하는 곳은 거의 없었다는 사실입니다.
OODS는 이에 대한 하나의 해답입니다.
객체(사용자, 구독, 송장 등)를 시스템의 핵심 요소로 취급합니다.
Stateful, Cancellable, Billable과 같은 '특성(Traits)'을 사용해 기능과 제약 사항을 담아냅니다.
기존 토큰 모델을 확장하여, 객체와 상태의 시맨틱을 코드화하는 '레이어 4'를 도입합니다.
이러한 사고방식을 활용하기 위해 반드시 OODS를 도입해야 할 필요는 없습니다. 대신 OODS를 다음과 같이 활용해 보세요.
'에이전트 인지 시스템(agent-aware system)'이 실제로 어떤 모습인지 보여주는 구체적인 사례.
팀원들과 객체, 특성(traits), 시맨틱에 대해 논의할 때 사용할 수 있는 공통 언어.
필요에 따라 빌려 쓰거나, 재조합하거나, 비판적으로 검토할 수 있는 참고 자료.
중요한 건 단 하나의 '정답'인 시스템을 정하는 것이 아닙니다. 핵심은 우리가 픽셀과 컴포넌트의 수준을 넘어, 사람과 기계 모두가 읽고 이해할 수 있는 시스템을 설계하기 시작해야 한다는 점을 보여주는 것입니다.
우리가 나아가야 할 방향
지금 여러분의 워크플로우에서 AI가 서투르거나 불안정하게 느껴진다면, 그건 프롬프트의 문제가 아닐 수도 있습니다. 여러분의 디자인 시스템이 AI에게 그저 '어떻게 보이는지'만 알려줄 뿐, 그것이 '무엇인지'는 알려주지 않기 때문일 수 있죠.
이러한 변화를 위해 새로운 툴이 출시될 때까지 기다릴 필요는 없습니다.
작은 것부터 시작해 보세요.
카드 하나를 'SubscriptionCard'로 이름을 바꾸고 실제 'status' 변수를 부여해 보세요.
로직을 텍스트 속에 숨겨두는 대신 'canCancel' 프로퍼티를 추가해 보세요.
이상적인 시나리오를 넘어, 딱 하나의 객체라도 그 객체가 가질 수 있는 다양한 상태를 설계해 보세요.
이러한 시도 하나하나가 모여 여러분의 시스템은 제품이 실제로 어떻게 작동하는지에 대해 조금 더 정직해질 것입니다. 또한, 피그마 플러그인이든 MCP 서버든, 혹은 아직 세상에 나오지 않은 그 무엇이든 미래의 에이전트들이 여러분을 다시 '청소부'로 만들지 않고도 유용한 작업을 수행할 수 있도록 도와줄 것입니다.
이 내용에 대해 더 깊고 아키텍처적인 버전이 궁금하다면, 'Design Systems Collective'에 기고한 아티클에서 OODS Foundry의 전체 명세와 토큰/특성 모델을 상세히 다루고 있습니다. 만약 핵심 아이디어만 가져와 여러분의 시스템에 맞게 응용하고 싶다면, 그 또한 이 글이 존재하는 목적이니 마음껏 활용해 보세요.
어떤 방식이든 우리가 나아갈 방향은 명확합니다. 단순히 겉모습이 아니라 '의미'를 코드화하는 디자인 시스템을 만드는 것이죠. 객체로 사고하는 것은 그 여정을 시작하는 좋은 방법 중 하나입니다.
기술적인 측면을 더 깊이 파고 싶으신가요? 'Design Systems Collective'의 "OODS Foundry" 아티클에서 객체지향적이고 에이전트-네이티브한 디자인 시스템의 아키텍처를 분석해 두었습니다. 이러한 방식이 데이터 시각화에서 어떻게 적용되는지 구체적인 사례가 궁금하다면 "디자인 시스템을 위한 객체지향 데이터 시각화" 글을 참고해 보세요.
원문 출처: https://medium.com/design-bootcamp/your-design-system-wasnt-built-for-ai-here-s-what-to-do-about-it-69e9cba80f1f
만식 +) 구글에서 인간 중심의 AI 제품을 설계하기 위해 실무적인 지침들을 모아놓은 리소스인 ‘People + AI 가이드북’을 공개했습니다. 관련된 내용으로 읽어보시면 좋을 것 같습니다.
