이번 글은, 저희 팀 프로덕트 디자이너 분께서 작성해주신 글입니다.

👉 원본 링크: https://rdo.sh/v84VI8V

안녕하세요, AI 프로젝트 관리 도구 뤼이도에서 디자인을 담당하고 있는 프로덕트 디자이너 김채원입니다.

뤼이도는 대왕 이도, 즉 세종대왕입니다. 프로젝트 관리 도구를 만드는데 우리나라 최고의 PM은 세종대왕이라고 생각해서 붙여진 이름입니다. 이런 한국적인 이름에 맞게 최근 저희는 디자인 시스템 2.0을 만들고 문방사우라고 이름 붙였습니다. 조선시대에 글을 쓰고 그림을 그리던 네 가지 도구, 종이와 붓, 먹과 벼루입니다. 디자인 시스템도 결국 디자이너의 도구니까요.

팀 전체가 AI 네이티브로 전환하는 9주 프로젝트 안에서, 디자인팀은 디자인 시스템부터 완전히 뜯어고쳤습니다. 왜 하필 지금 시점에 뜯어고쳤을까요?

1/ 사람이 관리할 때는 견딜 수 있었습니다

1. 토큰화가 되어 있지 않았습니다.

이 문장 하나로 대부분의 디자이너분들이 공감하실 것 같습니다. 파운데이션이 토큰화되어 있지 않았고, primitive와 semantic, component 같은 단계도 당연히 없었습니다.

토큰이 없다는 건 색과 간격이 이름 없이 값으로만 있다는 뜻입니다. 같은 보라색이 강조에 쓰였는지 링크에 쓰였는지 파일이 구분해주지 않습니다. 그래서 하나를 바꾸려면 쓰인 곳을 전부 찾아야 하는데, 기준이 값뿐이라 반드시 놓칩니다.

2. 디자인 SSOT가 없었습니다.

스프린트마다 새 파일을 만들던 방식 그대로 이어받아서, 디자인 파일이 수십 개가 되었고, 그중 최신 디자인 시스템이 적용되지 않은 파일도 수십 개였습니다. 즉, 레거시가 계속 쌓이는 구조였습니다. 이 화면이 어떤 파일에 있는지 몰라 짧게는 5분, 길게는 20분 넘게 찾기만 한 적도 있습니다. 찾았다고 끝도 아니었습니다. 최신본이 맞는지 production과 비교해야 했습니다.

3. 같은 사이즈의 버튼인데 크기가 달랐습니다.

같은 md 사이즈인데 solid button과 text button의 크기와 패딩이 각각 달라서, 어떤 화면에서는 작아 보이고 어떤 화면에서는 커 보였습니다. 이는 button, input, dropdown 등 모든 컴포넌트에 해당되었습니다.

4. 같은 기능인데 페이지마다 다르게 되어 있었습니다.

같은 서비스 안에 디자인 시스템 1.0이 적용된 화면과 적용되지 않은 화면이 함께 있었습니다.

최근에 디자인한 화면에는 디자인 시스템 1.0을 적용한 참여자 드롭다운이 나갔지만, 레거시 화면에는 적용되지 않은 드롭다운이 나갔습니다. 여러 곳에서 공통으로 쓰이는데 패턴으로 관리되지 않아 생긴 문제였습니다. 코드에서도 복사와 붙여넣기로 관리돼서, 일부를 고치려면 쓰이는 모든 곳을 고쳐야 했습니다.

네 가지 모두 사람인 제가 작업할 때는 어찌저찌 진행할 수 있었습니다. 필요하다는 건 알았지만 당장 급한 실무가 더 중요했고, 너무 큰 작업이라고 생각했습니다. 그래서 견딜 수 있었고, 견뎌야 했습니다.

2/ AI가 들어오자 견딜 수 없게 됐습니다

AI를 사람처럼 생각하고 일을 맡겼는데, 사람보다 훨씬 빠르고 많은 양을 작업하다 보니 견디던 것들이 견딜 수 없게 됐습니다.

AI가 레거시 파일을 최신본인 줄 알고 읽고 있었습니다. 최신본이 어디 있는지 저조차 몰랐으니 사람과 AI 둘 다 옛 버전을 보고 있었습니다.

그럼 모든 화면에 디자인 시스템을 적용해볼까 싶었는데, 디자인 시스템부터 기준이 명확하지 않았습니다. 디자인팀은 시스템을 Figma로만 관리했고, 코드와 싱크가 어긋난 곳이 많았습니다. 또 MCP로 Figma를 읽을 수는 있었지만, 읽을 때마다 결과물이 조금씩 달라졌습니다.

가장 큰 문제는 아무것도 토큰화되어 있지 않았다는 것입니다. 색과 간격이 값으로만 있으니, 어디에 어떤 역할로 써야 하는지가 명확하지 않았습니다. AI에게 디자인 시스템을 따르라고 말하려면, 먼저 따라야 할 기준부터 정리해야 했습니다. 저한테는 파운데이션을 토큰화하는 일이 그 시작이었습니다.

그래서 기존 디자인 시스템 1.0을 고치는 것이 아닌, 아예 갈아엎기로 했습니다. 파운데이션부터 토큰화하고 그 토큰으로 컴포넌트를 다시 만들어야 했으니 전면 재구축이 나았습니다. 다만 톤앤매너와 브랜드 컨셉은 유지했습니다. 뤼이도를 쓰시는 분들은 무엇이 바뀌었는지 잘 모르실 겁니다. 그게 목표였습니다.

3/ 3주, 디자이너 한 명과 프로덕트 엔지니어 한 명

9주 중 1주는 계획, 3주는 문방사우 재구축, 나머지 5주는 디자인 파일에 적용해 SSOT를 만들고 마무리하는 일이었습니다.

저는 디자인을 설계하고, 그 기준을 문서로 정리해 GitHub에 올렸습니다. 엔지니어는 Figma에서 추출한 정보와 이 문서를 대조하며 실제 컴포넌트로 구현했습니다.

디자인 작업은 제가 혼자 맡았습니다. 3주 안에 파운데이션부터 컴포넌트와 패턴까지, 승인과 핸드오프까지 끝내야 했습니다. 그래서 컨셉과 브랜딩, 톤앤매너는 1.0의 것을 그대로 가져왔습니다. 그걸 다시 만들었다면 3주 안에 끝내지 못했을 겁니다.

문방사우는 Tailwind 기반에 shadcn을 변형해 만들었고, 기존 컨셉과 맞지 않는 컬러는 primitive부터 새로 뽑았습니다. 키컬러인 보라색은 iris 팔레트로 새로 만들었는데, 사실 이 작업은 제가 한 게 아닙니다.

저는 미대를 나온 것도 아니고, 색상에 과학적으로 접근하는 방법을 잘 몰랐습니다. 3주 안에 전부 끝내야 하는 상황에서 그것부터 공부할 수는 없었습니다. 그래서 색상을 뽑는 일도, 컴포넌트를 통일하는 일도 거의 AI가 진행했습니다. Tailwind와 shadcn, 다른 회사 디자인 시스템을 참고로 주고 물어가면서 진행했습니다. AI가 없었다면 혼자서는 결코 끝내지 못했을 겁니다.

4/ 지금은 파일이 하나입니다

3주의 결과로 문방사우가, 5주의 결과로 모든 화면의 최신본 SSOT가 만들어졌습니다.

참여자 드롭다운처럼 공통적으로 사용되는 컴포넌트는 쓰이는 곳을 전부 찾아 패턴 파일로 정리해서, 이제 한 곳을 고치면 모든 곳이 같이 바뀌는 구조를 만들었습니다. 레거시 파일도 모두 제거했습니다. AI도 사람도 파일이 어디 있는지 찾지 않아도 되고, 최신본인지 production과 비교하지 않아도 됩니다. 5분에서 20분씩 쓰던 시간이 없어졌습니다.

그리고 문방사우는 컴포넌트마다 디자인 기준을 정리한 문서(md)를 갖고 있습니다. 개발팀은 Figma에서 추출한 정보(json)와 이 문서(md)를 비교하는 자동 검사도 구축했습니다. 디자인을 만드는 기준과 함께, 그 기준이 서로 어긋나지 않는지 확인하는 절차도 마련한 것입니다.

5/ 문방사우를 공개합니다

AI가 읽을 수 있게 만든다는 건, 결국 기준을 누구나 읽을 수 있는 글로 적는다는 뜻이었습니다. 색과 간격에 이름을 붙이고, 컴포넌트마다 어떤 기준으로 쓰는지 문서로 남겼습니다. 그렇게 만들고 나니 이 기준은 AI만 읽을 수 있는 것이 아니었습니다. 다른 직군의 동료도, 다른 팀의 디자이너도 같은 문서를 읽고 같은 기준을 볼 수 있습니다.

1절에서 적은 문제는 저희만의 이야기가 아닐 겁니다. AI가 읽을 수 없는 기준으로는 앞으로 AI와 함께 일하기가 점점 더 어려워질 겁니다. 저희가 3주 동안 부딪히며 만든 기준이 같은 전환을 앞둔 팀에게 출발점이 될 수 있다면, 공개하지 않을 이유가 없다고 생각했습니다.

뤼이도는 이렇게 일하는 팀이 만들고 있습니다. 사람과 AI가 같은 기준을 보고 일할 수 있게 먼저 정리하고, 그 위에서 더 빠르게 시도합니다. 문방사우는 그 과정에서 나온 결과물 중 하나입니다.

아래에 메일을 남겨주시면 공개할 때 가장 먼저 안내드리겠습니다.

🔔 문방사우 출시 알림 신청

다음 편에서는 AI와 실제로 어떻게 일했는지, 그리고 AI가 어떻게 틀렸는지를 자세히 적어보려 합니다.