컴포넌트 디자인을 AX로 바꾼 이유

혼자 만드는 디자인 시스템의 병목

젝트에는 JDS(젝트 디자인 시스템)라는 디자인 시스템이 있습니다. 메이커스 팀이 젝트의 여러 프로덕트를 만들 때 쓰는 공통의 컴포넌트와 규칙이에요. 저는 이 JDS의 디자인을 혼자 맡고 있습니다.

컴포넌트 하나를 만드는 과정을 떠올려 볼게요. 내부 레이아웃을 어떤 구조로 쌓을지, 프로퍼티를 어떻게 나눌지, 어디까지를 하나의 컴포넌트로 보고 어디서부터 컴파운드(Compound)로 나눌지를 정해야 합니다. 이렇게 정한 내용을 Figma에서 직접 마우스를 움직이고 타이핑하며 만들고, 마지막에는 문서화까지 해야 하죠. 돌아보면 이 작업의 80% 이상이 제가 손수 설계하고 판단하는 일이었습니다.

이 방식에도 장점은 있었어요. 모든 결정을 제 손으로 내리다 보니 판단의 근거를 진하게 남길 수 있었습니다. 문제는 공수였어요. 컴포넌트 하나를 만드는 데 순수하게 10시간 정도가 들었고, 여기에 검토와 추가 판단에 드는 시간까지 더해졌습니다. 이렇게 만든 컴포넌트가 50개 정도 되니, 만들고 검토하고 관리하는 일이 쉴 틈 없이 이어졌죠.

'무엇을 만들어야 하는가'는 비교적 분명했습니다. 메이커스 팀 안의 니즈와 피드백, 그리고 스스로 찾은 개선안을 활발하게 논의하면서 다음에 무엇이 필요한지 명료하게 알 수 있었거든요. 압박은 '만드는 일' 자체에서 왔습니다. 무엇을 만들지는 알고 있는데 손이 따라가지 못하는 상황이었고, 디자인을 혼자 하고 있었기 때문에 결국 제가 병목이 되는 일이 많았어요.

비율을 뒤집다

그래서 비율을 뒤집기로 했습니다. 이제는 컴포넌트 작업의 80% 이상을 AI가 설계하고 제작합니다. 저는 AI가 내놓은 설계의 트레이드오프 지점과 논리적 타당성을 검토하고, 나아갈 방향을 잡아 주는 역할을 맡고 있어요.

도구는 두 가지를 씁니다. 하나는 Figma MCP 연결이에요. AI가 Figma 파일을 직접 읽고, 레이어를 만들고, 변수를 연결할 수 있게 해 줍니다. 다른 하나는 JDS 컴포넌트를 만들고 문서화하는 과정을 정리해 둔 AI용 작업 지침(Skill)입니다. 컴포넌트를 만들거나 고치는 방법부터 개요, 디자인, 변형 문서와 리소스 이미지, 라이브러리 게시 체인지로그를 쓰는 방법까지 담겨 있어요.

작업은 이렇게 흘러갑니다.

1. 어떤 컴포넌트를 새로 만들거나 고쳐야 하는지 파악합니다.
2. 그 작업을 '왜' 하는지를 AI에게 충분히 설명합니다.
3. AI가 Figma에서 컴포넌트를 설계하고 만든 뒤 문서와 리소스까지 작성합니다.
4. 저는 결과를 검토합니다. 규칙과 어긋나거나 판단이 아쉬운 부분이 있으면 이유를 다시 설명하고 고치게 합니다.
5. 마지막으로 체인지로그를 받아 검토하고 라이브러리를 게시합니다.

1번은 예전과 똑같습니다. 무엇을 만들지는 여전히 팀과의 논의에서 나와요. 달라진 건 2번부터입니다. 예전에는 '왜'를 제 머릿속에 둔 채로 바로 손을 움직였다면, 이제는 그 이유를 먼저 말로 꺼내 AI에게 건넵니다.

새로 준비할 것이 거의 없었던 이유

AI에게 작업을 맡기려면 많은 준비가 필요할 거라고 생각하기 쉽습니다. 저도 언젠가는 AI 기반 작업으로 전환해야겠다고 생각만 해 두고 있었어요. 막상 실행하려고 보니, 크게 바꿀 것이 없다는 걸 알게 됐습니다.

디자인 시스템의 본질은 협업 규칙을 정의하는 공통의 언어라고 생각합니다. 디자이너와 개발자가 같은 이름으로 같은 것을 가리키고, 같은 기준으로 판단할 수 있게 해 주는 언어죠. 그렇다면 AI도 우리 팀의 작업자라고 생각해 볼 수 있습니다. 새로운 팀원이 들어왔을 때 우리는 그 사람을 위해 디자인 시스템을 새로 만들지 않아요. 이미 있는 원칙과 컨벤션을 건네고 함께 일하면서 맞춰 갑니다. AI도 마찬가지였습니다.

JDS는 Principles를 비교적 잘 정리해 둔 편이었고, 디자인 협업 컨벤션도 마련되어 있었어요. 레이어 이름을 어떻게 붙이는지, 간격과 색상 변수를 어떤 기준으로 거는지, 문서에는 무엇을 어떤 순서로 쓰는지 같은 내용입니다. 원래는 사람 사이의 협업을 위해 써 둔 글이었는데, 이 문서들이 AI가 바로 이해하는 작업 지침으로 굉장히 잘 작동했습니다.

결과적으로 별도의 참고 사례나 인사이트 없이 바로 전환을 실행했어요. 10번 이내의 요청을 주고받는 것만으로, 제가 하던 작업 퀄리티의 90% 이상을 만족하는 AI 작업자가 나왔습니다. 지금 와서 보면 이 전환은 AI를 위해 무언가를 새로 만든 일이라기보다, 그동안 사람을 위해 써 둔 규칙이 제 역할을 한 일에 가깝습니다.

사례 1: Link, 이유를 설명하는 일은 여전히 내 몫

첫 번째 사례는 작은 개선 작업입니다. Link 컴포넌트에 hierarchy 프로퍼티를 추가하고, 값을 accent, primary, secondary로 나눴어요. 원래 있던 파란색 링크가 accent이고, primary와 secondary가 새로 생긴 값입니다.

이 작업에서 AI에게 전한 이유는 이랬습니다.

• 링크는 보편적인 멘탈 모델상 파란색으로 표시하는 것이 관습입니다. '파란색 텍스트'는 '클릭할 수 있는 링크'라는 강한 인지적 기대가 형성되어 있기 때문이에요.
• JDS도 이 멘탈 모델을 따라 기본 Link 색상을 파란색(accent)으로 표시했습니다. 하지만 링크가 강조되었을 때 시각적 위계가 어긋나는 맥락이 많다고 판단해, 맥락에 맞게 primary, secondary처럼 쓸 수 있는 대안을 준비하려는 것입니다.
• toc, breadcrumb, footer 같은 UI 맥락에서도 Link 요소를 쓰는 것이 바람직한데, 이때 위계가 어긋나는 문제가 주로 생깁니다. 이런 상황에서 새로운 위계 값이 유의미하게 쓰일 것이라고 판단했습니다.

이 작업은 규모가 작아서 AI를 쓰는 것보다 제가 직접 고치는 편이 빨랐어요. 그래서 컴포넌트는 먼저 손으로 고치고, 그 뒤의 문서 수정, 리소스 편집, 라이브러리 게시용 텍스트 작성을 AI에게 맡겼습니다.

이 사례에서 눈여겨볼 부분은 손으로 할지 AI에게 맡길지를 나누는 기준입니다. AI로 전환했다고 해서 모든 작업을 AI에게 넘길 필요는 없어요. 직접 하는 편이 빠른 일은 직접 하고, 그 결과를 여러 문서와 리소스에 반영하는 반복적인 일을 맡기면 됩니다.

그리고 어느 쪽이든 이유를 설명하는 일은 제 몫으로 남습니다. 지난 글 설득력 있는 디자인을 위한 원페이저에서 판단의 이유를 설명하는 것도 디자인 작업에 포함된다고 썼는데요. 협업자가 사람에서 AI로 바뀌어도 그 생각은 그대로입니다. 이유가 빠진 자리에는 누군가의 추측이 대신 들어가고, AI는 그 추측을 사람보다 훨씬 빠르고 그럴듯하게 해내니까요.

사례 2: Dialog, 남은 20%에서 하는 판단

두 번째 사례는 Dialog 컴포넌트입니다. 이번에는 컴포넌트 설계부터 문서화까지 처음부터 끝까지 AI로 진행했어요.

결과물의 대부분은 그대로 써도 될 만큼 좋았습니다. 그래도 검토하면서 방향을 다시 잡아 준 순간들이 있었어요. 남은 20%의 판단이 어떤 모습인지 보여 주는 장면들이라 몇 가지 소개할게요.

규칙의 문장이 아니라 의도를 읽기

AI는 Alert dialog와 Design conventions 문서를 근거로, 컴포넌트를 품는 레이어의 이름을 region으로 바꿨다고 보고했습니다. 언뜻 보면 규칙을 잘 따른 것 같지만, 실제로는 규칙을 조금 잘못 이해한 결과였어요.

JDS에서는 컴포넌트로 만든 요소를 의미론적 최하위 요소로 다룹니다. 컴포넌트 내부에 module이나 region 정도의 계층이 있다고 해도, 그 컴포넌트의 인스턴스를 품는 상위 레이어는 container예요. 복잡한 region이나 module 수준의 요소를 컴포넌트로 만들 수 있는지 검토하고, 만든 컴포넌트와 다른 레이어 요소들을 다시 container로 감싸는 식으로 체계를 쌓아 가고 있기 때문입니다.

AI는 규칙의 문장을 빠르고 정확하게 적용합니다. 다만 그 규칙이 왜 그렇게 정해졌는지, 어떤 순서로 체계를 쌓으려는 것인지까지는 스스로 짐작하기 어려워요. 그래서 저는 틀린 부분을 고치라고만 하지 않고, 규칙의 의도를 다시 설명했습니다.

변수를 거는 것과 의미 있게 거는 것

AI는 변수가 연결되지 않은 간격이 Header 안에 한 곳 있어서 semantic.spacing.10에 연결했다고 했습니다. 변수가 빠진 곳을 찾아 채운 것 자체는 좋은 습관이에요. 하지만 맥락상 좋은 조치는 아니었습니다.

• 그 간격은 close button을 품는 button container의 gap이었는데, 안에 든 요소가 하나뿐이라 간격 자체가 의미 없는 곳에 걸려 있었습니다.
• 앞으로 여러 요소가 들어올 것을 감안하더라도, 이 자리는 버튼이 추가로 들어올 확률이 높은 맥락입니다. 그렇다면 임의의 값보다 버튼 간격 지침을 따르는 편이 좋아요. JDS 문서에는 Icon button 사이의 간격을 spacing.16으로 쓴다고 명시되어 있습니다.

'변수가 걸려 있는가'는 규칙으로 검사할 수 있지만, '이 자리에 어떤 변수가 와야 하는가'는 앞으로 이 컴포넌트가 어떻게 쓰일지를 내다보는 판단입니다. 이런 판단은 아직 제가 하고 있어요.

문서 속 장면을 구성하는 기준 주기

문서에 넣을 사용 예시도 AI에게 맡겼습니다. Dialog 인스턴스로 장면을 조립해 달라고 요청하면서, JDS에서 가상의 사용례를 들 때 쓰는 콘셉트를 함께 알려 줬어요. 동아리 관리 백오피스, 공식 웹사이트, 테크 블로그, 행사 체크인 폼처럼 'IT 동아리와 조직'의 프로덕트를 예시로 든다는 기준입니다.

여기에 하나를 더 요구했어요. 내부 이미지의 맥락이 잘 보이도록 문서에 쓰인 썸네일의 비율을 조정하고, 그에 맞춰 이미지 프레임 크기도 바꾸되, 한 문서 안의 이미지들은 컴포넌트가 같은 기준의 크기로 보이도록 프레임 크기를 균일하게 맞추라는 것이었습니다. 문서를 읽는 사람이 이미지마다 다른 배율로 컴포넌트를 보면 크기를 오해할 수 있기 때문이에요.

세 장면 모두 AI의 결과물이 '틀렸다'기보다 '규칙은 지켰지만 의도와 맥락이 빠졌다'에 가깝습니다. 남은 20%는 이 빈 곳을 채우는 일이에요. 그리고 그 빈 곳을 채우는 방법은 예전처럼 제가 직접 마우스를 움직이는 게 아니라, 왜 그래야 하는지를 다시 말로 설명하는 것입니다.

루프의 마지막은 직접 닫는다

아직 제가 직접 이어 줘야 하는 지점도 있습니다. Figma 라이브러리 게시예요.

JDS는 젝트의 n8n에서 Figma 라이브러리 게시 이벤트를 받아 Discord에 임베드 메시지를 보내는 자동화를 해 두었습니다. 팀원들은 이 메시지를 보고 디자인에서 어떤 부분이 바뀌었는지를 대략적으로라도 파악할 수 있어요.

이 메시지는 팀 전체가 보는 기록이라, 최종 검토는 제가 직접 하는 게 좋겠다고 생각했습니다. 그래서 AI에게 라이브러리 게시문 컨벤션에 맞춰 체인지로그를 출력하게 하고, 그 내용을 다시 한 번 읽으며 검토해요. 이상이 없으면 제가 그 로그대로 라이브러리를 게시합니다.

모든 단계를 AI에게 맡길 수도 있겠지만, 팀에 나가는 마지막 기록만큼은 사람이 확인하는 것이 맞다고 봅니다. 앞에서 본 것처럼 AI는 규칙을 지키면서도 의도를 놓칠 수 있고, 체인지로그에서 그런 실수가 나오면 팀원들이 잘못된 정보를 바탕으로 일하게 되니까요.

바뀐 것

컴포넌트 하나를 만드는 데 걸리던 작업 시간이 이전의 1/10 수준으로 줄었습니다. 10시간 정도 들던 일이 1시간 안팎이면 끝나는 셈이에요.

더 반가운 변화는 검토에 쓸 시간이 생겼다는 점입니다. 예전에는 만드는 데 시간을 다 써 버려서, 검토와 추가 판단은 늘 쫓기듯 해야 했어요. 이제는 AI가 만든 결과를 차분히 읽고 트레이드오프를 따져 볼 여유가 있습니다. 제가 병목이 되던 상황도 대부분 해결됐고요.

손에서 판단으로

이번 전환으로 제 일이 줄어들었다기보다, 일의 무게중심이 옮겨 갔다고 느낍니다. 예전에는 시간의 대부분을 손을 움직이는 데 썼다면, 지금은 판단하고 그 판단의 이유를 말로 정리하는 데 씁니다.

돌아보면 전환이 순조로웠던 이유도 여기에 있었어요. JDS는 처음부터 사람과 사람이 함께 일하기 위한 원칙과 컨벤션을 글로 남겨 왔고, 그 글이 AI에게도 그대로 통했습니다. 판단의 이유를 말로 정리해 둔 팀일수록 AI를 동료로 들이기 쉽다고 생각해요.

혹시 디자인 시스템을 혼자, 혹은 적은 인원으로 꾸려 가고 있다면 AI에게 무엇을 시킬지보다 먼저 지금 가진 원칙과 컨벤션을 살펴보면 좋겠습니다. 새로 들어온 팀원에게 건넬 수 있을 만큼 정리되어 있다면, AI에게도 건넬 준비가 된 거예요.