AI가 읽는 디자인 시스템에 필요한 것

“AI한테 디자인 시스템을 넣어줬는데요. 생각보다 퀄리티가 좋지 않네요. 원래 이런가요?”

디자인 토큰도 간신히 다 정리했고 컴포넌트도 다 고쳐놨다. 잘은 모르겠지만, 다른 사람들이 얘기한 ‘design.md’라는 것도 만들어서 넣으면 될 것 같다. 이제 디자인을 일일이 하는 일은 없을 것이다. 드디어 프롬프트만으로 우리 회사의 디자인을 이전과는 완전히 다른 압도적인 효율로 만들어 낼 수 있을 것 같다.

좋은 건 딱 여기까지고 지금부턴 현실이다. AI가 갑자기 없는 색을 가져다 쓰질 않나, 제목이랑 본문에 뒤죽박죽 아무 폰트 스타일이나 가져다 쓰고, UI를 이상한 규칙으로 제멋대로 조합하고, 만들어놓은 컴포넌트는 굳이 굳이 안 쓰고 또 제3의 덩어리를 자꾸만 만들어 낸다. 몇 번 고쳐 달라고 하면 알아듣는 척하더니, 결국 프롬프트로 일일이 만들어 달라고 할 때랑 별반 차이가 없는 상태로 돌아간다.

이 AI가 말을 안 들으면 저 AI도 써보고, 또 이것도 저것도 또 써보고, 커뮤니티에 ‘디자인 시스템 넣어줬는데 원래 이렇게 별론가요?’라고 질문도 해보고 내가 모르는 뭔가 기능이 더 있을 것만 같아서 MCP 연결 방법을 다시 찾아본다. 원티드나 당근 디자인 시스템처럼 잘 만들어진 걸 가져오면 뭐가 달라질까 싶어서 또 기웃기웃 찾아본다. 

여기까지 하다 보면 내가 지금 일을 하려고 일을 더 만드는 건가 싶다. 어딘가에는 우리 회사 디자인 시스템을 한 번에 찰떡같이 이해해주는 AI가 있을 것 같은 생각에 오픈채팅이나 커뮤니티에 ‘다들 AI 뭐 쓰세요?’라고 질문도 해보지만, 다들 비슷하게 쓰고 있다. 그럼 이제 우리가 넣어준 디자인 시스템이 문제라는 생각을 할 차례다.

파일만 준다고 일을 가르친 게 아니다

처음 입사한 날을 돌이켜 보자. 자리에 앉았는데, 피그마 라이브러리 링크 하나만 보내고, 다음 주에 출시할 핵심 기능을 이걸 활용해서 디자인해 달라는 업무를 갑자기 받았다. 일단 입사 첫날부터 중요한 작업을 줄 리는 없지만, 지금 우리가 AI한테는 그렇게 일을 시키는 중인 셈이다. 아무튼, 신입으로써 라이브러리를 열심히 들여다볼 것이다. 버튼과 텍스트 필드가 어디 있는지는 찾을 수 있다. 컬러와 타이포그래피도 대충 훑어볼 수 있을 것이다. 아는 건 아는데, 이제 화면을 그려보는 게 문제다. 이 화면에 이 버튼을 써도 되나? 이 화면에서 버튼 크기는 이건가? 탭이 2가지 종류가 있던데 어떤 상황에 뭘 쓰는 거지? 신입으로써 궁금한 게 산더미일 것이다.

사람이라면 대충 눈치껏 이미 만들어진 화면을 찾아보기도 할 거고, 정 안 될 것 같으면 다른 동료에게 묻는다. 비슷한 사례가 없으면 기획자나 개발자에게 왜 이렇게 만들었는지도 물어볼 것이다. 그러다 보면 문서에 쓰여 있지 않은 규칙을 하나씩 알게 된다. 우리 서비스에선 버튼 사이즈 기본값이 라지라든가, 카드 안의 제목엔 타이틀이 아니라 라벨 폰트 스타일을 써야 된다거나, 숫자가 길어질 때는 말 줄임이 아니라 줄 바꿈을 쓴다거나, 하는 자잘한 규칙들이 등장한다. 그런 경우들을 다 떠나서, 신입 입장에선 내가 이 재료들만으로 화면을 만들 때 뭘 해야 하고 하지 말아야 하는지 모르는 상황이 너무 답답하다.

안타깝게도 AI는 이런 눈치도 없고 그런 답답함도 안 느낀다. 안 답답하니까 나한테 안 물어본다. 그리고 너무나 내가 시킨 것만을 과하게 정확하게 해온다. 금융 서비스인지, 게임인지, 운영자가 하루 종일 들여다보는 B2B 도구인지 모르니까. 이게 제일 큰 문제인데 색상도 얼추 썼고, 모서리도 둥글게 잘 깎았고, 폰트도 맞는데 우리 서비스 같지 않다. 이게 ‘AI가 디자인 시스템을 무시’한 게 아니라, 우리가 AI한테 알아서 눈치껏 하라고 맡긴 부분이 너무 많았던 것이다.

디자인 시스템은 단어장이 아니다

영문학을 공부하고 나서 디자인 시스템을 알게 됐을 때, 언어 구조와 굉장히 많이 닮아있단 생각을 했다. 비유하자면, 우리가 흔히 ‘디자인 시스템’이라고 알고 있는 수준은 대체로 단어장 수준이다. 색상, 폰트, 버튼, 인풋, 체크박스처럼 그냥 단어가 늘어져 있는 상태다.

그런데 우리가 말을 할 땐 단어만 가지고 말을 하지 않는다. ‘가방, 무게, 넣다, 병원, 노트북, 나, 어깨, 통증’ 식으로 말을 하는 사람은 아무도 없다. 이대로 한다 쳐도 이 말을 듣고 무슨 뜻인지 이해할 수 있는 사람이 없다. 알아들었다면, 그건 그 사람이 이 언어를 어느 정도 알고 있는 상태에서 눈치껏 ‘이게 이거겠거니’ 하고 추론해서 맞혔을 뿐, 내가 실제로 의도한 바를 100% 맞히진 못한다. 

즉, 단어를 많이 준비한다고 소통이 잘 되는 게 아니라는 뜻이다. 단어가 있다면 그 다음엔 용태와 문법이 필요하다. 어떤 문맥에서 그 단어를 쓰는지, 서로 어떤 순서로 이어지는지, 같은 뜻처럼 보여도 무엇을 골라야 하는지 알아야 한다. 한국어가 서툰 사람이 쓴 문장이 어색한 건 여기에 있다. AI가 만든 화면이 바로 외국인이 쓰는 한국어 문장인 셈이다. 토큰은 맞는데 결과가 이상하다.

디자인 시스템이 이 언어의 성질을 그대로 닮고 있다. 작은 요소부터 큰 요소까지 결합해 나가는 아토믹 디자인 체계는 물론이거니와, 컴포넌트만 달랑 던져둔다고 뭔가 만들어지지 않는다는 것도 마찬가지다. 컴포넌트의 자세한 사양, 간격, 사용한 토큰들, UX 가이드라인, 위치, 인터랙션 등 우리가 암묵적, 무의식적으로 이해하고 쓰는 그 부분들이 바로 AI에게 줘야 하는 더 중요한 것들이다.

사람이 보는 디자인 시스템이라면 어느 정도 생략이 가능했다. 우리는 모두 맥락을 서로 어느 정도 이해하니까. 하나는 배경색이 모두 칠해진 버튼이고 다른 하나는 테두리에만 색상이 들어가 있다면, 사람이라면 이 중 어떤 것이 더 강조되는 버튼인지 이해한다. 비슷한 화면 몇 개만 보더라도 대략적인 일관된 규칙들을 파악해 볼 수 있다. 예를 들면, 한 화면에 Primary Button을 네 개씩 늘어놓으면 안 된다는 것들일 것이다. 위험한 행동에는 어떤 색을 써야 하는지, 취소와 삭제 중 무엇을 더 조심스럽게 다뤄야 하는지도 기존 제품을 보면서 배운다.

AI가 읽을 문서에는 이 생략된 판단이 더 많이 드러나야 한다. 물론 추론 역량이 더 올라갔다고는 해도, 어디까지나 ‘추론’이다. 즉, ‘이런 의도로 만들었겠지’ 하고 넘겨짚는다는 것이다. 디자인 시스템에선 추론이 있어선 안 된다. 명시여야 한다. 심지어 어떤 컴포넌트는 임의로 수정해 사용할 수 있다는 가이드라인 문구마저도 명시적으로 작성해둬야 한다. 버튼의 색상이 무엇인지 적는 것이 전부가 아니다. 

사용자가 현재 작업을 끝낼 때 쓴다, 한 영역 안에서는 하나만 있는 것이 원칙이다, 이 원칙을 어길 수 있는 예외의 경우는 이런 경우들이다, 취소나 단순 이동에는 사용하지 않는다 등의 내용이 필요하다. 로딩 중에는 어떻게 보이는지, 비활성화 상태는 언제 허용하는지, 텍스트 라벨이 길어지면 어디까지 늘어나다가 말줄임표가 붙는지 그 글자의 최대 수도 알려줘야 한다. 퀄리티가 나오지 않는다면 지금 우리의 디자인 시스템을 다시 확인해보자. 디자인 사양이나 토큰만 상세하게 적고는 다 됐다고 생각하고 있을지 모른다.

돌이켜보면 지금까지 우리는 신입 사원에게 단어장을 건네주고 아무도 알려주지 않은 우리 회사 문체로 소설을 써오라고 한 셈이다.

문제는 콘텐츠다

디자인 시스템을 AI에 넣는 이야기가 나오면 곧바로 md(markdown)파일과 JSON 이야기가 자연스럽게 붙는다. 디자인 토큰을 파일별로 나눌지, 컴포넌트까지 한 문서에 넣을지, 피그마 변수를 어떻게 추출할지 고민하기 시작한다. 추출해서 어떤 확장자를 넣어줘야 하냐도 꾸준히 올라오는 질문이다. 물론 필요한 고민이다. AI는 사람처럼 피그마 페이지를 넘겨가면서, 변수 패널 다 눌러보면서 찾아다니는 게 아니니 말이다.

다만 퀄리티의 문제는 파일 형식의 문제가 아니다. md파일을 json으로 바꾼다고 갑자기 디자인 시스템 이해도가 확 올라가지 않는다. 우리로 치면 한컴 hwp 문서로 보던 걸 워드 문서로 바꿔서 보는 거와 별반 다를 바 없다. 애초에 디자인 시스템을 사용해야 하는 규칙이 사람에게도 모호했다면, 즉 명시적이지 않고 추론이나 암묵지에 과하게 의존하고 있었다면, 파일 형식을 바꾸면 기계가 읽기 좋은 형식으로 아주 정갈하게 모호해질 뿐이다. 파일 형식은 그냥 어떤 포맷으로 보여줄지를 결정할 뿐이지, 안 되던 걸 갑자기 되게 하는 인피니티 스톤이 아니라는 거다.

그럼 제대로 된 디자인 시스템 문서를 만들려면 어떻게 시작해야 하느냐가 관건인데, 먼저 당연히 이런 AI에게 적합한 파일 형식으로 바꾸기 전에도 이미 피그마에서 디자인 시스템의 완성도가 어느 수준 이상이어야 한다. 디자인 토큰이나 스타일이 정교한 건 당연한 거고, 컴포넌트의 구조나 배리언츠, 프로퍼티가 모두 잘 잡혀 있어야 한다.

컴포넌트 구조까지 됐다면 이제 끝이냐, 당연히 아니다. 이제 이 컴포넌트를 쓰는 방법도 기록해야 한다.

컴포넌트 배리언츠나 프로퍼티는 특히 고정되는 것, 바뀌는 것, 최대 너비나 길이, 높이, 글자 수 등이 모두 핸드오프든 텍스트로든 준비되어 있어야 한다. 로딩, 오류, 빈 상태, 권한 부족, 긴 텍스트처럼 컴포넌트가 가지는 에러 케이스들도 같이 보여줘야 한다.

그 후엔 이제 how to use, 가이드라인, 인터랙션, 포지션 등등이 필요하다. 이 버튼은 이렇게 쓰세요, 이렇게는 쓰지 마세요, 어디에는 어떻게 배치하세요, 배치할 땐 이렇게 저렇게 하세요 처럼 우리가 디자인할 때 꺼내 쓰는 원칙들을 모두 기록해줘야 한다.

첫 결과물부터 잘 나오길 바라는 마음

문서를 이 정도로 만들었다면 이제 화면이 잘 나오겠지? 싶은 마음은 당연히 욕심이다. 이제서야 시작점에 선 것이다. 문서를 모두 만들고, AI에게 전달했다면 이제 지난한 반복의 시간이다. 생성을 요청하고, 우리가 유지하는 디자인과 다른 부분이나 잘못 사용한 부분을 피드백해서 다시 학습시키고, 다시 생성을 요청하고, 다시 피드백을 넣고, 다시 생성하기를 반복하면서 이제 신입 사원을 계속 훈련시키는 것이다.

이 과정이 AI와 디자인 시스템의 핵심 루프다. 많은 사람들이 design.md 파일 만들었는데 퀄리티가 별로다 라고 하는 건 대부분 2가지 이유인데, 첫 번째는 애초에 피그마에서부터 디자인 시스템이 부실한 상태였다는 것, 두 번째가 바로 이 ‘반복’을 하지 않는다는 것. 첫 번째 이유는 위에서 얘기했지만, 우리가 시각적으로 만든 피그마 산출물을 모두 텍스트/코드로 변경해서 AI가 읽는 것이고, 그만큼 우리가 잘 만들어놔야 시작점이 그만큼 더 올라간다. 두 번째 이유는, 그렇게 시작하더라도 ai는 실전 경험이 없으니, 이제 이 design.md를 놓고 계속 실전 사례를 만들어보게 하면서 이건 저렇게 저건 이렇게 하라고 교정을 꾸준히 하는 것이다.

여기서 발생하는 실무적인 문제들도 있다. 첫 번째로는, AI의 결과물을 보고 우리 가이드라인에 맞는 것과 맞지 않는 것, 디자인 시스템 관점에서 이건 이래야 하고 저래야 한다고 알려줄 수 있으려면, 디자이너 스스로가 더 잘 알아야 한다. 항상 AI와 디자인 주제에서 나오는 말이다. 디자이너가 직접 컴포넌트를 뜯어고칠 게 아니라, UX적으로 더 나은 판단을 내릴 수 있는 디렉터가 되어야 한다는 이야기를 다른 글에서도 한 적이 있다.

두 번째로는 문서 자체를 만드는 건 시작에 불과하고 간단하지만, 결과물을 놓고 계속 대화를 반복하며 제대로 우리 회사의 디자인을 학습할 수 있는 수준까지 올리려면 이제 비용이 발생하기 시작한다는 점이다. AI를 사용하는 토큰 가격도 비용이지만, 시간이 사실은 제일 큰 비용이다.

우리가 AI로 결과물을 만든다고 했을 때 간편하고, 효율적인 것만 생각했겠지만 그건 가이드라인을 고려하지 않은 초안 수준의 작업물을 바로바로 만드는 정도에만 적용되는 특징이다. 우리 회사의 가이드라인에 맞게 실무에 바로 사용할 수준의 결과물을 만들어야 한다면, 그만큼 꾸준히 학습을 시키는 시간이 필요하다. 며칠이 걸릴 수 있고, 몇 주, 몇 달이 될 수도 있다. AI 파도의 시대에서 이 ‘시간’ 이라는 비용을 간과하는 경우가 너무나 많다. 그래서 AI에게 디자인 시스템을 학습시킨다는 건 쉽고 빠르게 할 수 있는 일이 절대 아니다. 한번 제대로 학습시킨다면 몇 명분의 일을 더 잘할 수 있는 기술이겠지만, 거기까지 도달하는 성장곡선은 매우 더디고, 비효율적이고, 어렵고, 오래 걸린다.

AI가 읽을 수 있다면 사람도 덜 헤맨다

AI가 읽는 디자인 시스템은 완전히 새로운 종류의 디자인 시스템이 아니다. 사람이 눈치와 소통으로, 으레 하던 습관들로 채우던 기준들을 밖으로 꺼내 명시적으로 작성해 둔 것이다. 토큰과 컴포넌트가 무엇인지 보여주는 데서 끝내지 않고 언제 쓰고, 언제 쓰지 않고, 틀리고 맞는 게 뭔지, 어떻게 쓰는지까지 적어두는 것이다.

비용이 많이 소모되지만, 그렇게 문서를 한번 만들어 둔다면 그 이후는 오히려 더 나아진다는 건 자신할 수 있다. 그렇게 만든 문서는 AI만을 위한 것도 아닐 것이기 때문이다. AI가 우리 회사의 디자인이 어떤 방향과 스타일, 테마, 구조를 가지고 있는지 학습하는 입장에서 새로 입사한 디자이너와 개발자, pm에게 오히려 가르치는 입장이 될 수 있고, 디자인 리뷰에서 반복되는 문제들도 줄어들 수 있다. AI가 자꾸 엉뚱한 화면을 만든다는 사실은 어쩌면 우리 디자인 시스템에 빠져 있는 논리적인 오류와 빈칸을 가장 성실하게 알려주는 사용성 테스트의 결과인지도 모른다.

디자인 시스템을 넣었는데 결과가 좋지 않다고 바로 다른 ai를 찾지는 말자. 내가 어떤 내용을 담았고, 어떻게 만들어서 전달했고, 거기에 빠진 건 뭔지, AI가 그 빠진 부분을 어떻게 대체했는지를 먼저 파악하고 시간을 들여 고쳐내보자. AI에게 금을 넣는다는 건 거대한 프롬프트를 준비하는 일이 아니다. 우리 팀은 무엇을 어떻게, 왜 디자인하는지 설명할 수 있게 만드는 일이다. AI에게 디자인 시스템을 가르치려고 시작하는 일에서 다시 배우게 되는 건 다름 아닌 디자이너 본인이어야 한다.

ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.