AI가 만든 화면을 다시 묶는 코드 중심 디자인 시스템

AI가 만든 화면을 다시 묶는 코드 중심 디자인 시스템

AI 뉴스 썸네일

AI 코딩 도구로 화면을 빠르게 만들 수 있게 되면서 디자인 시스템의 역할도 달라지고 있어요. 여러 팀이 각자 만든 결과물을 하나의 제품처럼 정리하려면 검증된 컴포넌트와 토큰, 접근성 규칙을 기계가 읽을 수 있는 형태로 제공해야 해요. Figma의 제품 아키텍트 TJ Pietre는 디자인에서 코드로 넘기던 단방향 작업보다 코드와 캔버스를 오가는 흐름에 무게를 둬요. 1 2

핵심 요약

구분	핵심	왜 볼 만한가요
작업 순서	AI가 만든 제품에서 공통 코드를 추출한 뒤 캔버스로 되돌려 검토해요	이미 구현된 사업 논리를 살리면서 제품 간 차이를 정리할 수 있어요
품질 기준	컴포넌트·토큰·문서·접근성 속성을 함께 제공해요	AI가 비슷한 화면을 제각각 다시 만드는 일을 줄여요
기준점	계약 형태의 명세에서 코드와 캔버스를 함께 생성해요	변환을 반복할 때 생기는 패딩·속성 누락을 줄일 수 있어요
실무 사례	서로 다른 기반으로 만든 23개 제품을 공통 프레임워크와 코드베이스로 묶었어요	빠른 제작 뒤에 필요한 통합 비용과 운영 과제를 보여줘요

1. 코드가 디자인 시스템의 출발점이 되고 있어요

전통적인 흐름에서는 디자이너가 Figma에 컴포넌트를 만들고 개발자가 이를 코드로 구현했어요. 시각 검수와 테스트를 거친 컴포넌트는 패키지로 배포됐어요. AI 코딩 도구가 먼저 제품을 만드는 환경에서는 출발점이 달라져요. 구현된 제품의 코드를 분석해 공통 구조를 찾고, 정리한 코드를 다시 캔버스로 옮겨 디자이너와 이해관계자가 검토하는 순서가 생겼어요. 2

영상에서 소개한 사례에는 여러 팀이 만든 23개 제품이 등장해요. 색상과 일부 브랜드 요소는 비슷했지만 간격, 테두리 반경, 글자 크기, 서체가 달랐어요. Radix UI와 Material 3, Base UI처럼 기반 라이브러리도 제각각이었어요. 팀은 제품을 진단한 뒤 공통 프레임워크를 고르고 하나의 코드베이스로 다시 묶었어요. 통합한 결과를 캔버스로 가져와 화면 구성과 프로토타입을 검토했어요. 1

이 과정은 AI가 만든 결과물을 조금 다듬는 일보다 범위가 커질 수 있어요. 각 제품에 담긴 기능과 사업 논리는 재사용할 수 있지만, 화면 구조와 컴포넌트는 상당 부분 다시 만들어야 할 수 있어요. 초기 제작 시간이 짧아져도 여러 제품을 오래 운영하려면 공통 기반을 정리하는 비용이 남아요.

728x90

AI에는 선택지를 줄이는 맥락이 필요해요

AI는 비슷한 폼이나 버튼을 빠르게 복제해요. 공통 컴포넌트가 없으면 화면마다 조금씩 다른 코드가 쌓이기 쉬워요. 디자인 시스템은 사용할 수 있는 컴포넌트와 상태, 토큰, 문서를 제한된 선택지로 제공해요. 여러 실제 제품에서 검증한 구성 요소를 재사용하면 팀이 새 화면마다 품질 기준을 다시 설명할 필요도 줄어요. 2

버튼 하나에도 기본·보조 유형만 있는 것으로는 부족해요. hover와 disabled 상태, 좌우 아이콘, 로딩 표시, 키보드 조작과 접근성 속성까지 정의해야 해요. 이런 정보가 빠지면 개발자가 빈칸을 추정하고, AI도 서로 다른 방식으로 코드를 채울 수 있어요. `aria-label`처럼 화면에 보이지 않는 정보도 디자인 컴포넌트에 담아 두면 코드로 옮길 때 접근성 맥락을 유지하기 쉬워요. 1

영상에 나온 Figmalint는 Figma 컴포넌트의 토큰 참조, 레이어 이름, 상태와 속성 누락을 검사해요. 규칙 기반 검사와 추천을 함께 사용하지만, 제안을 모두 자동 반영하지는 않아요. 디자이너가 결과를 살펴보고 필요한 항목을 선택해요. 이 단계가 있으면 개발팀이 구현 중에 누락된 디자인을 뒤늦게 발견할 가능성을 줄일 수 있어요.

계약이 코드와 캔버스의 공통 기준이 돼요

코드를 캔버스로 바꾸고 다시 코드로 옮기는 일을 언어 모델에만 맡기면 조금씩 차이가 생길 수 있어요. 패딩이 2픽셀 달라지거나 컴포넌트 속성 하나가 빠지는 식이에요. 변환을 여러 번 반복하면 작은 차이가 제품 전체로 퍼질 수 있어요.

TJ Pietre가 제안한 방향은 계약 형태의 명세를 공통 기준으로 두는 방식이에요. 코드와 캔버스가 같은 명세를 읽고 결과를 만들면 어느 쪽이 최신인지 다투는 일을 줄일 수 있어요. Figma 컴포넌트와 React 컴포넌트를 연결할 때도 초기부터 구조와 속성을 맞춰 둬야 해요. 캔버스에서 임의 패딩을 쓰면 코드에도 Tailwind 임의 값이 그대로 들어갈 수 있어요. 2

Meta의 Asterisk도 기계가 읽을 수 있는 디자인 시스템 사례로 소개됐어요. 컴포넌트와 CLI, 문서, MCP 연결 수단을 함께 제공해 도구가 사용 규칙과 구성 요소를 찾도록 돕는 방식이에요. 사람을 위한 컴포넌트 카탈로그를 넘어 개발 도구가 직접 조회할 수 있는 인터페이스까지 디자인 시스템의 범위에 들어온 셈이에요. 1

왜 중요한가요

바이브 코딩으로 제품 수가 빠르게 늘면 디자인 시스템 팀의 일이 사라지기보다 뒤로 이동해요. 출시 전에 모든 화면을 설계하는 대신 이미 만들어진 제품을 진단하고, 중복 코드를 걷어내고, 여러 팀이 따를 공통 규칙을 정해야 해요. 빠르게 만든 시제품이 실제 서비스로 넘어갈수록 상태 관리, 접근성, 테스트, 유지보수 비용이 더 구체적으로 드러나요. 2

실무에서는 AI 도구를 추가하기 전에 컴포넌트의 완성도를 먼저 확인할 필요가 있어요. 버튼과 입력창의 모든 상태가 정의됐는지, 토큰 참조가 끊기지 않았는지, 접근성 속성이 코드까지 전달되는지 살펴봐야 해요. 새 화면을 만들 때 기존 컴포넌트를 우선 사용하도록 문서와 개발 환경을 연결하면 제각각인 구현을 줄일 수 있어요.

코드 중심 접근이 캔버스 작업을 없애는 것은 아니에요. 디자이너와 제품팀이 화면을 비교하고 합의하는 공간은 계속 필요해요. 달라지는 부분은 기준점이에요. 코드와 캔버스가 같은 계약을 읽도록 만들면 두 결과물 사이의 차이를 사람이 매번 찾아 고치는 일을 줄일 수 있어요. 다만 영상에서 다룬 방식은 Figma와 SouthLeft의 경험을 중심으로 한 제안이에요. 팀 규모와 기존 코드 품질에 따라 통합 범위와 비용은 달라질 수 있어요. 1

참고 자료

1. 디자인 시스템의 미래 — GeekNews
2. TJ Pietre | The Future of Design Systems — Into Design Systems, YouTube