• AI 시대의 디자인 시스템은 디자인을 코드로 넘기는 기존 흐름을 넘어, AI가 만든 제품을 역설계해 일관된 코드와 캔버스로 되돌리는
  코드 중심 워크플로로 확장되고 있음
• 안정적인 AI 결과물에는 검증된 컴포넌트·토큰·문서·접근성 속성을 아우르는 충분한
  맥락(context) 이 필요하며, 디자인 시스템이 이를 제공함
• 여러 팀이 만든 23개 바이브 코딩 제품은 색상 일부를 제외하면 간격·테두리 반경·서체·UI 프레임워크가 달라, 하나의 프레임워크와 코드베이스로 통합해야 했음
• Meta의
  Asterisk는 컴포넌트·CLI·문서·MCP를 함께 제공해 기계도 읽을 수 있는 디자인 시스템을 지향하며, 장기적으로 계약(contract)이 코드와 캔버스의 기준점이 될 수 있음
• AI가 제작 비용을 낮춰도 불완전한 소프트웨어를 완성하는 대행 수요는 남으며, 에이전시는 도구와 경험을 오픈소스로 공유해 신뢰를 쌓고 맞춤형 프로젝트를 확보할 수 있음

SouthLeft에서 Figma로 이동한 과정

• Figma 합류는 TJ Pietre가 계획했던 이직이 아니라 외부 제안에서 시작됐으며, 수개월간
  디자인 시스템의 미래와 장기적인 사업 확장 전략을 논의함

• 14년 반 동안 운영한 SouthLeft를 떠나면서도 회사가 계속 성장할 수 있도록 경영 인계를 준비함

• 약 16년간 함께 일한 Nicole Hampton을 1월에 부분 근무 형태의 매니징 디렉터로 영입함

• 여러 규모의 에이전시를 관리한 경험과 사업 개발·파트너십 역량을 바탕으로 Nicole이 회사를 맡음

• 디자인 시스템 경험을 보완하기 위해 Banks의 Baseline과 MSA를 체결하고, 양사가 문의를 함께 듣고 제안하며 요구사항을 발견하는 협력 구조를 구축함

• 현재 TJ는 일상 운영에 관여하지 않고 Nicole에게 약 한 달 간격으로 현황을 전달받음

창업자가 실무에서 빠져나오기 어려운 이유

• SouthLeft 운영 초기 12년 동안 사업 자체를 관리하기보다 프로젝트 실무에 깊이 관여함

• 약 5년 차에 직원이 8명가량 있어 위임을 시작해야 했지만, 자신만큼 잘할 사람이 없다는 생각 때문에 전환이 늦어짐

• 당시 일부 고객이나 매출을 잃더라도 팀원에게 책임을 맡겼다면, 실패에서 배우며 프로젝트 리더로 성장할 수 있었을 것으로 돌아봄

• 실제로 프로젝트에서 빠져나오기 시작한 시점은 약 10년 차였음

• 초기 발견 통화와 관계 형성은 직접 담당함

• 이후 실행은 프로젝트 팀이 책임진다는 점을 고객에게 명확히 알림

• 가장 큰 장애물은 팀의 역량이 아니라 창업자 자신의
  통제 욕구와 성향이었음

• 위임한 뒤에도 프로젝트 종료나 고객 이탈로 매출 공백이 생기면, 현금 흐름을 위해 창업자가 다시 실무에 투입되는 문제가 반복될 수 있음

에이전시 영업과 콘텐츠 전략

• 디지털 서비스 업체의 영업에는 화려한 비법보다
  규율 있는 반복 실행이 중요함

• 서비스를 명확한 패키지로 구성하면 제안서와 판매 방식을 표준화하기 쉬움

• 반면 AI와 디자인 시스템처럼 고객별 차이가 큰 서비스는 상품화하기 어려움

• 적극적인 영업이 맞지 않는 조직에는 내부 도구·방법과 성공·실패 경험을 무료로 공개하는 방식이 효과를 냈음

• 판매보다 같은 문제를 겪는 실무자를 돕기 위해 자료를 공개함

• 고객마다 적용 결과가 달라질 수 있어
  일률적인 해법이 아님을 명확히 밝힘

• 도구가 자신의 경력을 구했다는 메시지를 받은 경험이 추가 공개로 이어짐

• 축적한 경험은 Frost와 함께 여섯 장으로 구성된 과정으로 정리함

• 바이브 코딩 앱을 14일 안에 고치거나 환불하는 패키지는 반복 가능한 고객 유입 경로가 될 수 있지만, 실제 수익성은 고객 예산에 좌우됨

• 바이브 코딩은 앱 제작 장벽을 낮췄지만, 이를 선택한 고객에게 전문 에이전시의 수정 비용을 감당할 예산이 없는 경우가 많았음

• 사용자와 매출이 이미 발생한 제품에서 문제가 생긴 경우가 더 적합한 고객 조건임

AI가 뒤집은 디자인 시스템 구축 순서

• 전통적인 디자인 시스템은 Figma 같은 디자인 도구를
  정본(canon) 으로 삼았음

• 디자인을 개발자에게 전달함

• 개발자가 컴포넌트를 구현함

• 시각적 품질 보증과 단위 테스트를 수행함

• 패키지로 만들어 제품에 적용함

• 일부 조직은 약 1~2년 전부터 코드를 정본으로 관리하는 코드 중심 디자인 시스템을 발전시켜 왔음

• 다른 조직은 AI를 활용하라는 지시를 받았지만, 디자인 시스템의 어느 지점에 AI를 넣어야 효율을 얻을지 알지 못했음

• 충분한 맥락 없이 AI를 투입하면 팀이 내부 동작을 이해하지 못한 채 바이브 디자인과 바이브 코딩을 진행하게 됨

• AI를 목줄에 매고 함께 걷는 동안에는 통제할 수 있음

• AI가 사람보다 앞서가면 작업의 연결고리를 잃게 됨

• 바다로 너무 멀리 헤엄쳐 기준점인 해안을 볼 수 없는 상태와 같음

• AI가 만든 결과물을 안정화하는 과정은 기존 흐름을 뒤집음

• 제품에서 출발해 코드를 역설계함

• 코드로부터 캔버스를 생성함

• 캔버스에서 합의한 뒤 다시 전통적인 선형 워크플로로 돌아감

23개 제품을 하나의 시스템으로 통합한 사례

• 한 조직의 여러 팀이 만든
  23개 제품은 시장성이 있을 수 있었지만 그대로 출시하기 어려운 상태였음

• 제품 사이에 일관성이 거의 없었음

• 색상과 일부 브랜드 요소만 비슷했음

• 간격·테두리 반경·색조·글자 크기·서체가 서로 달랐음

• 각 앱은 Radix UI, Material 3, Base UI 등 서로 다른 기반으로 제작됨

• 과거 은행의 기본 사이트·모기지 사이트·신용카드 사이트가 로고만 공유하고 전혀 다르게 보였던 상황과 유사함

• 제품들을 진단한 뒤 하나의 통합 코드베이스로 역설계함

• 공통 프레임워크를 선택함

• 기성 디자인 시스템을 사용할지 맞춤형으로 구축할지 결정함

• 통합한 코드를 다시 캔버스로 옮겨 제품 디자이너가 UI 구성과 프로토타입을 검토하도록 함

• 바이브 코딩 결과물에는 이해관계자와 이미 합의한 사업 논리가 담겨 있어 재구축 속도를 높일 수 있지만, 실제 작업은 상당 부분
  전면 재구축에 가까울 수 있음

디자인 시스템이 AI에 제공하는 맥락

• AI는 코드를 쉽게 복제하므로 컴포넌트 없이 작업하면 비슷한 폼과 UI가 반복 구현될 수 있음

• 프로젝트 중간이라도 확장성이 흔들리기 전에 작업을 멈추고 공통 컴포넌트와 디자인 시스템을 삽입해야 함

• 디자인 시스템은 AI가 선택할 수 있는 검증된
  레고 블록 집합과 같음

• AI가 임의의 조각을 조합하지 못하도록 제한함

• 여러 프로덕션 앱에서 사용된 컴포넌트를 제공하면 최종 제품의 기반을 신뢰할 수 있음

• 백엔드와 프런트엔드 모두 특정 선택 자체보다 합의한 규칙을 일관되게 적용하는 것이 중요함

AI 시대의 UI 라이브러리

• shadcn과 Radix UI는 웹에서 쉽게 접근하고 복사할 수 있으며, React와 Tailwind 기반이라 AI 이전부터 플러그앤드플레이 방식으로 사용하기 쉬웠음
• 문서와 코드가 충분히 공개돼 언어 모델이 학습하고 소비하기 좋은 구조였고, React 프로젝트를 요청하면 AI가 기본 선택지처럼 가져오는 경우가 많음
• 높은 테마 유연성을 이용해 Radix UI 의존을 줄이고 전형적인 shadcn 외형에서 벗어나는 방법도 생김
• Mantine 역시 AI 이전과 이후 모두 선호한 기성 라이브러리임
• TJ는 개인적으로 의존성이 적은
  고전적 CSS와 BEM을 선호하며, 프레임워크와 패키지를 최소화하고 Web Components를 사용하는 프런트엔드 기본주의 입장을 유지함

Asterisk와 기계가 읽는 디자인 시스템

• Meta의
  Asterisk는 AI가 소비할 수 있도록 설계된 디자인 시스템임

• 디자인 시스템을 API처럼 다루고 사람뿐 아니라 기계도 읽을 수 있게 함

• 컴포넌트와 CLI를 제공함

• 적절한 맥락과 문서를 포함함

• MCP도 함께 제공함

• 연결 직후부터 지침을 따르며 복잡한 대시보드 구성을 만들 수 있는 도구들을 사용할 수 있음

• 특정 산업에 치우치지 않은 범용 시스템으로, 여러 기본 테마와 Node 패키지, 맞춤형 테마 방식을 지원함

• Meta가 Instagram, Facebook, Facebook Messenger와 일부 다른 제품에서 내부적으로 사용해온 시스템임

계약을 기준으로 한 코드와 캔버스의 왕복

• 캔버스 기반 디자인은 사라지지 않으며, 코드와 캔버스 사이의 이동이 더 유연해질 수 있음

• 언어 모델로 코드에서 캔버스, 다시 코드로 계속 변환하면 복사본을 거듭 복사하는 것처럼
  드리프트가 생김

• 패딩이 달라질 수 있음

• 속성 하나가 누락될 수 있음

• 계약(contract)을 정본으로 두면 동일한 명세로부터 코드와 캔버스를 결정론적으로 생성할 수 있음

• 언어 모델의 해석 없이도 계약이 양쪽 결과를 일치시키는 기준점이 됨

• Figma MCP는 Figma 컴포넌트와 React 컴포넌트를 연결할 수 있지만, 프로젝트 초기부터 그 구조를 준비해야 함

• 디자이너가 Figma 컴포넌트 구조를 올바르게 사용하면 MCP 결과가 좋아지지만, 패딩이 2픽셀만 달라도 AI가 Tailwind의 임의 값 문법으로 그대로 재현할 수 있음

Figmalint의 검증 방식

• 원자 단위 컴포넌트를 철저히 검증해야 이후 조합에서도 AI가 버튼과 속성을 정확히 이해할 수 있음
  Figmalint는 Figma 컴포넌트 집합을 AI 사용에 맞게 검증하는 플러그인임

• 결정론적 테스트와 언어 모델 기반 추천을 함께 사용함

• 토큰 참조, 레이어 이름, 분리된 컴포넌트의 존재 여부 등을 검사함

• SouthLeft가 다른 디자인 주도 에이전시와 협업할 때 전달받은 결과물이 완전한 디자인 시스템이 아니라 단순 UI 키트에 머무는 경우가 많았음

• 기본·보조 버튼만 있고 hover·disabled 상태가 없었음

• 좌우 아이콘, spinner, loader 등이 빠져 있었음

• 개발팀이 누락된 디자인을 추론하면 예상하지 못한 추가 업무와 일정 위험이 생겼음

• 개발팀에 컴포넌트를 전달하기 전에 Figmalint를 실행해 디자인 측의 책임 범위를 명확히 함

Design Systems Assistant MCP와 접근성

• Figmalint의 추천 기능은 별도로 만든
  Design Systems Assistant MCP를 사용함

• 벡터 데이터베이스에는 대규모 디자인 시스템과 관련 자료가 포함됨

• Google Material UI

• Microsoft Fluent

• Adobe Spectrum

• Shopify Polaris

• 디자인 시스템 실무자의 자료와 서적

• 감사 결과를 바탕으로 누락된 속성과 커뮤니티 모범 사례를 추천하며, 사용자는 이를 선택적으로 반영할 수 있음

• 검증 도구는 제품 디자이너에게 개발자 의도와 디자인 시스템의 세부 구조를 교육하는 역할도 맡음
  aria-label

처럼 화면에 보이지 않는 접근성 속성도 Figma 컴포넌트에 포함해야 함

• 해당 정보가 Figma MCP를 통해 코드 컴포넌트로 전달됨
• 초기 컴포넌트에 설정한 맥락이 전체 워크플로를 거쳐 최종 제품까지 유지될 수 있음

에이전트 하네스와 개발 환경

• pi.dev는 오픈소스 CLI형 에이전트 하네스로, Codex나 Claude Code보다 내부 동작을 수정하기 쉬움

• 기본 계획 모드나 반복 모드는 없지만 플러그인으로 추가할 수 있음

• 계획·디자인·검토·CI/CD·품질 보증 에이전트를 상태 머신 형태로 연결하는 데 활용함

• 구성 가능한 프롬프트에 각 단계의 역할, 필요한 기술, 사용할 MCP를 명시하면 하네스의 자동 판단에 덜 의존할 수 있음

• Linux에는 Figma 데스크톱 앱이 없어 Figma MCP 인증과 사용에 제약이 생길 수 있음

• Warp의 AI는 SSH로 연결한 환경에서 DevOps 작업, 호스팅 설정, 로컬 Node 패키지 정리 등에 활용할 수 있음

• 교육 대상이 제품 디자이너라면 CLI보다 Cursor나 Claude Desktop 같은 시각적 인터페이스가 적합할 수 있음

• AI가 기존 작업을 쉽게 만들수록 Neovim이나 필기체처럼 별도의 도전 과제를 택해 사고력을 계속 사용하는 습관도 권장함

오픈소스가 맞춤형 사업으로 이어지는 방식

• 에이전시가 내부 도구를 공개하면 영업 비밀이나 SaaS 기회를 잃는다는 우려가 있지만, SaaS는 고객 지원·환불·마케팅까지 포함한 별도 사업 운영을 요구함
• 직접 필요한 도구를 만들고 자신에게 유용하다면 다른 사람에게도 공개하는 접근을 권함
• 여러 Google 계정의 일정을 통합하려고 만든 Calendly 대체 도구
  Uncal은 유료 SaaS로 가입자를 확보하지 못했지만 무료 프로젝트로 계속 사용됨
• Uncal을 본 고객이 일정 기능이 필요한 자체 도구의 맞춤 개발을 의뢰함
• 이메일 추천 보상 프로그램을 공개한 사례도 맞춤형 프로젝트와 장기적인 관계로 이어짐
• 고객은 월 10달러짜리 범용 SaaS보다 자신의 요구에 맞춘 구현을 원할 수 있어, AI 시대에도
  완성형 대행(done-for-you) 시장이 남아 있음
• AI가 프로젝트 구축 비용을 낮추면서 시간·재료 기반 과금에서 벗어날 여지가 생겼고, 동시에 절반만 완성된 소프트웨어를 정리할 에이전시 업무가 늘어날 수 있음

커리어 조언과 추천 도서

• 추천 도서는 Veronica Kindred의
  Sentient Design으로, 디자인 시스템 이후의 미래를 다룸

• 업계에 진입하는 사람에게는 처음에는 민망하게 느껴지는 일을 감수하라는 “embrace the cringe”를 권함

• 오픈소스 공개나 영상 제작은 성과가 없을 것이라는 반응을 받을 수 있음

• 원하는 결과에 도달하려면 자신을 드러내고 취약함을 감수하면서 규율 있게 지속해야 함

• 프로젝트 사이에 새로운 기술이나 도구를 실험하고 결과를 저장소와 함께 공개하면, 다른 사람에게 도움을 주면서 새로운 기회로 이어질 수 있음

댓글과 토론