<div id="readability-page-1" class="page"><div>
  <p><span>Written by</span>
    KimCoding

    
      <br>
      <span>on&nbsp;</span><time datetime="2026-06-30 00:00:00 +0900">June 30, 2026</time>
    
  </p>

  
  

  <p>디자인 시스템을 만드는 사람으로서 요즘 계속 맴도는 물음이 있다. ‘AI 시대에 디자인 시스템은 무슨 가치가 있을까.’</p>

<p><img src="https://huns.me/assets/images/new/2026-06-30/1.png" loading="lazy"></p>

<p>이 물음의 힌트를 얻으려고 지난주 <a href="https://config.figma.com/">Figma Config 2026</a>에 다녀왔다. FE 개발자인 나에게도 흥미로운 이야기가 꽤 있었다.</p>

<p>
  <iframe src="https://www.youtube.com/embed/2ZCc4k_IV5w" title="Config 2026 keynote" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen=""></iframe>
</p>

<p>“프롬프트 한 줄로 화면이 뚝딱 나오는 시대에, 디자이너에게 중요한 건 무엇일까?”</p>

<p>Figma CEO 딜런은 이렇게 답한다.</p>

<ul>
  <li>
<a href="https://www.youtube.com/watch?v=2ZCc4k_IV5w">“AI는 바닥을 낮췄지만, 천장은 사람이 높인다”</a> - 딜런 필드(Figma CEO)</li>
</ul>

<p>Figma CPO가 얼마 전 올린 글도 같이 떠오른다.</p>

<ul>
  <li>
<a href="https://www.figma.com/blog/what-matters-when-anyone-can-build/">“누구나 출시할 수 있게 되면 차별점은 속도가 아니라 방향”</a> - 야마시타(Figma CPO)</li>
</ul>

<p>사람, 그리고 방향.</p>

<p>행사 아젠다를 훑으며 AI 시대 디자인 시스템의 가치를 찾아봤다. 두 가지로 정리된다.</p>

<ol>
  <li>디자인 시스템은 AI 시대에 여전히, 아니 더 중요해졌다.</li>
  <li>사람은 방향과 판단에 집중할 수 있어야 한다.</li>
</ol>

<h2 id="1-디자인-시스템은-ai-시대에-여전히-아니-더-중요해졌다">1. 디자인 시스템은 AI 시대에 여전히, 아니 더 중요해졌다</h2>

<p>AI가 화면을 다 그려주는데 디자인 시스템을 공들여 만들 필요가 있을까? Config의 답은 분명했다. 오히려 더 중요해졌다.</p>

<h3 id="ai에게-의도를-전달하는-공통-언어">AI에게 의도를 전달하는 ‘공통 언어’</h3>

<p>
  <iframe src="https://www.youtube.com/embed/TQaYwH6f4DA" title="Designed to be read: making a system AI can actually use" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen=""></iframe>
</p>

<p>AI는 빠르지만 우리 프로젝트의 디자인 규칙을 모른다. 그래서 모르는 문제를 만나면 학습한 공개 데이터로 빈칸을 제멋대로 채운다.</p>

<p>Meta의 Product Designer Harvey는 이제 디자인이 ‘AI가 읽을 수 있어야’ 한다고 말한다. 정의되지 않은 토큰 하나, 문서화 안 된 규칙 하나가 곧 AI가 제멋대로 추론하는 지점이 되니까.</p>

<p><img src="https://huns.me/assets/images/new/2026-06-30/2.png" loading="lazy"></p>

<p>디자인 시스템을 ‘맥락(Context)’으로 구축하고, 이를 활용하는 ‘기술(Skills)’을 쌓고, 최종적으로 ‘에이전트(Agents)’에게 쥐어주는 3단계 계층을 만들어야 한다는 제안이다. 맥락 없이 쌓은 AI 활용은 “모래 위에 건물 짓기”와 같다고.</p>

<p>
  <iframe src="https://www.youtube.com/embed/D5WUW9X_-L0" title="Figma deep dive: Agentic workflows and the MCP | Config 2026" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen=""></iframe>
</p>

<p>Figma Developer Advocate도 콘텍스트의 중요성을 강조한다. 디자인 시스템은 “적은 표면적에 더 많은 의도를 담아내는 콘텍스트”다. AI 추론을 줄이고, 더 적은 코드로 더 많은 구현을 하게 돕는다. 결국 토큰 사용의 ROI가 높아지는 셈이다.</p>

<p><img src="https://huns.me/assets/images/new/2026-06-30/3.png" loading="lazy"></p>

<p>그렇다면 이제 디자인은 화면을 ‘그리는’ 일을 넘어 ‘AI에게 제공할 디자인 데이터를 설계’하는 일이 된 것 같다.</p>

<h3 id="디자인과-코드를-연결하기">디자인과 코드를 연결하기</h3>

<p>
  <iframe src="https://www.youtube.com/embed/Q3BkuQRBg-w" title="Designing in code | Config 2026" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen=""></iframe>
</p>

<p>Figma엔 버튼 모서리가 8px인데 코드엔 6px인 상황, 많이 겪지 않나? 디자인 파일 속 컴포넌트는 결국 ‘그림’이다. 개발자가 코드로 옮기는 과정에서 조금씩 균열이 생긴다. 디자인 시스템이 있어도 규칙을 ‘벗어나는(divergence)’ 상황은 생기고, AI는 이 균열을 더 빠르게 키운다.</p>

<p>우리 팀도 디자인-코드 ‘공통 언어’를 타이트하게 맞춰보려 한 적이 있다. 그때 디자인-개발 간 커뮤니케이션 비용을 꽤 치렀다. 각자의 작업 공간이 분절되어 있으니 조율에 많은 대화가 필요했다. 본업이 따로 있는 상황에서 이런 비용은 반갑지 않다.</p>

<p>이번에 공개된 Code Layer가 그래서 반갑다. Code Layer는 코드를 ‘디자인의 재료(Material)’로 만들어 디자인-코드 간 ‘번역과 정렬’의 수고를 줄이려는 시도다.</p>

<p><img src="https://huns.me/assets/images/new/2026-06-30/4.png" loading="lazy"></p>

<p>Figma 캔버스 위에 실제 코드로 렌더링한 프레임을 배치해, 디자인 시스템 에셋이 실제 제품 코드와 같은 환경에서 작동하게 만들 수 있다.</p>

<p>코드에서 프레임 단위로 디자인을 뽑아낼 수도 있고,</p>

<p><img src="https://huns.me/assets/images/new/2026-06-30/5.png" loading="lazy"></p>

<p>GitHub 저장소를 캔버스로 직접 가져오거나 캔버스에서 수정한 내용을 저장소로 보낼 수도 있다.</p>

<p><img src="https://huns.me/assets/images/new/2026-06-30/6.png" loading="lazy"></p>

<p>Code Layer가 잘 동작한다면 디자이너가 Figma에서 직접 UI 코드를 검수하거나, 디자인 시스템 구현 시 디자인-코드 동기화를 더 간결하게 만들어 줄 수 있을 것 같다. Canvas와 DOM의 미묘한 차이를 Figma가 어떻게 풀어냈을지 궁금하다. (아직 베타라 쓰려면 <a href="https://www.figma.com/config-betas/">별도 신청</a>해야 한다.)</p>

<h2 id="2-사람은-방향과-판단에-집중할-수-있어야-한다">2. 사람은 방향과 판단에 집중할 수 있어야 한다</h2>

<p>“누구나 빠르게 만들 수 있는 시대일수록, 무엇을 만들지 정하고 책임지는 사람의 몫이 더 또렷해진다.”</p>

<h3 id="속도를-더-빨리-만들기가-아니라-더-잘-고르기에">속도를 ‘더 빨리 만들기’가 아니라 ‘더 잘 고르기’에</h3>

<p>
  <iframe src="https://www.youtube.com/embed/4fZ3CeFu954" title="Designing in the age of the 10x engineer ft. Andy Zhang (Google) | Config 2026" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen=""></iframe>
</p>

<p>Google AntiGravity의 Design Engineer Lead Andy Zhang의 세션이다. “모든 코드가 사용자에게 전달되어야 하는 건 아니다”는 메시지가 인상적이었다.</p>

<p>훌륭한 디자인은 훌륭한 큐레이션에서 나온다는 말처럼, 품질은 기능 몇 개를 출시했느냐가 아니라 수많은 버전에 ‘아니오’라고 한 끝에 무엇에 ‘예’라고 했느냐로 결정된다고 한다.</p>

<p>AI는 코드를 싸고 빠르게 만든다. 하지만 사용자에게 정말 좋은 경험인지 검증(Verify)하는 일은 결국 사람의 몫이다.</p>

<h3 id="양자택일이-아니라-언제-어디에-무게를-두느냐">양자택일이 아니라, 언제 어디에 무게를 두느냐</h3>

<p>시장엔 AI를 보는 두 기류가 있는 것 같다.</p>

<ul>
  <li>A. 더 빠른 빌드에 집중</li>
  <li>B. 더 좋은 선택에 집중</li>
</ul>

<p>이번 Config는 B의 메시지를 전하는 세션이 많았다. 그런데 A와 B는 양자택일일까? 제품 스테이지에 따라 균형점이 다르다면,</p>

<ul>
  <li>0→1(속도·선점·초기 MVP)에선 속도(A)가,</li>
  <li>1→n(경쟁 심화·높은 기대·쌓인 레거시)에선 선택(B)이 더 중요하고,</li>
  <li>많은 경우 둘 다 놓칠 수 없는 게 현실이기도 하다.</li>
</ul>

<p>올바른 질문은 “언제, 어디에 무게를 두느냐”인 것 같다. A든 B든 우리가 빨라져야 하는 이유는 ‘피드백을 빠르게 받기’ 위해서다. 경쟁자보다 시행착오를 더 많이, 더 빨리 할 수 있다면 더 빨리 성장하니까.</p>

<h3 id="그래서-사람이-판단에-집중하려면">그래서, 사람이 판단에 집중하려면</h3>

<p>방향을 정하고, 무엇에 ‘예’라고 할지 고르고, 어디에 무게를 둘지 정하는 일. 셋 다 사람이 해야 할 일이다.</p>

<p>디자인 시스템은 품질의 바닥을 높이고, 중복 작업을 줄여 사람이 더 중요한 판단에 집중하도록 돕는다.</p>

<h2 id="3-남는-고민---어떻게-디자인-시스템의-비용을-줄일-것인가">3. 남는 고민 - 어떻게 디자인 시스템의 비용을 줄일 것인가</h2>

<p>디자인 시스템은 여전히 중요하고, 속도와 품질의 균형에도 힘을 보탠다. 그런데 현실은 여전히 난관이다. 디자인 시스템은 공짜가 아니거든.</p>

<p>시스템을 만들고 유지하는 데는 지속적인 투자가 필요하고, 많은 디자인 시스템이 이 비용 장벽 앞에서 무너지고 사라진다.</p>

<p>그래서 이번 Figma Config 2026은 나에겐 조금 아쉬웠다. ‘왜, 무엇을’ 만들지는 많이 말했지만, 정작 ‘구축·유지 비용’을 다루는 세션은 없었다. 그래도 디자인 시스템의 중요성을 다시 확인한 계기가 됐으니 아주 실망스럽진 않다.</p>

<p>우리 팀은 디자인 시스템 비용을 풀어보려고 이런 문제들을 고민하고 있다.</p>

<ul>
  <li>서비스·제품 스테이지에 맞는 적정 수준의 디자인 시스템을 제시할 수 있을까?</li>
  <li>어떻게 하면 디자이너가 환영할 수준의 디자인 시스템을 더 저렴하고 빠르게 만들어 낼 수 있을까?</li>
  <li>어떻게 하면 더 적은 커뮤니케이션으로 디자인-코드 연결성을 유지할 수 있을까?</li>
</ul>

<p>비슷한 문제를 고민하거나 관심 있는 분이 있다면 언제든 연락 주면 좋겠다. 같이 고민하고 싶다.</p>


</div></div>

Huns.me

디자인 시스템을 만드는 사람으로서 요즘 계속 맴도는 물음이 있다. ‘AI 시대에 디자인 시스템은 무슨 가치가 있을까.’
이 물음의 힌트를 얻으려고 지난주 Figma Config 2026에 다녀왔다. FE 개발자인 나에게도 흥미로운 이야기가 꽤 있었다.
“프롬프트 한 줄로 화면이 뚝딱 나오는 시대에, 디자이너에게 중요한 건 무엇일까?”
Figma CEO 딜런은 이렇게 답한다.
“AI는 바닥을 낮췄지만, 천장은 사람이 높인다” - 딜런 필드(Figma CEO)
Figma CPO가 얼마 전 올린 글도 같이 떠오른다.
“누구나 출시할 수 있게 되면 차별점은 속도가 아니라 방향” - 야마시타(Figma CPO)
사람, 그리고 방향.
행사 아젠다를 훑으며 AI 시대 디자인 시스템의 가치를 찾아봤다. 두 가지로 정리된다.
디자인 시스템은 AI 시대에 여전히, 아니 더 중요해졌다.
사람은 방향과 판단에 집중할 수 있어야 한다.
1. 디자인 시스템은 AI 시대에 여전히, 아니 더 중요해졌다
AI가 화면을 다 그려주는데 디자인 시스템을 공들여 만들 필요가 있을까? Config의 답은 분명했다. 오히려 더 중요해졌다.
AI에게 의도를 전달하는 ‘공통 언어’
AI는 빠르지만 우리 프로젝트의 디자인 규칙을 모른다. 그래서 모르는 문제를 만나면 학습한 공개 데이터로 빈칸을 제멋대로 채운다.
Meta의 Product Designer Harvey는 이제 디자인이 ‘AI가 읽을 수 있어야’ 한다고 말한다. 정의되지 않은 토큰 하나, 문서화 안 된 규칙 하나가 곧 AI가 제멋대로 추론하는 지점이 되니까.
디자인 시스템을 ‘맥락(Context)’으로 구축하고, 이를 활용하는 ‘기술(Skills)’을 쌓고, 최종적으로 ‘에이전트(Agents)’에게 쥐어주는 3단계 계층을 만들어야 한다는 제안이다. 맥락 없이 쌓은 AI 활용은 “모래 위에 건물 짓기”와 같다고.
Figma Developer Advocate도 콘텍스트의 중요성을 강조한다. 디자인 시스템은 “적은 표면적에 더 많은 의도를 담아내는 콘텍스트”다. AI 추론을 줄이고, 더 적은 코드로 더 많은 구현을 하게 돕는다. 결국 토큰 사용의 ROI가 높아지는 셈이다.
그렇다면 이제 디자인은 화면을 ‘그리는’ 일을 넘어 ‘AI에게 제공할 디자인 데이터를 설계’하는 일이 된 것 같다.
디자인과 코드를 연결하기
Figma엔 버튼 모서리가 8px인데 코드엔 6px인 상황, 많이 겪지 않나? 디자인 파일 속 컴포넌트는 결국 ‘그림’이다. 개발자가 코드로 옮기는 과정에서 조금씩 균열이 생긴다. 디자인 시스템이 있어도 규칙을 ‘벗어나는(divergence)’ 상황은 생기고, AI는 이 균열을 더 빠르게 키운다.
우리 팀도 디자인-코드 ‘공통 언어’를 타이트하게 맞춰보려 한 적이 있다. 그때 디자인-개발 간 커뮤니케이션 비용을 꽤 치렀다. 각자의 작업 공간이 분절되어 있으니 조율에 많은 대화가 필요했다. 본업이 따로 있는 상황에서 이런 비용은 반갑지 않다.
이번에 공개된 Code Layer가 그래서 반갑다. Code Layer는 코드를 ‘디자인의 재료(Material)’로 만들어 디자인-코드 간 ‘번역과 정렬’의 수고를 줄이려는 시도다.
Figma 캔버스 위에 실제 코드로 렌더링한 프레임을 배치해, 디자인 시스템 에셋이 실제 제품 코드와 같은 환경에서 작동하게 만들 수 있다.
코드에서 프레임 단위로 디자인을 뽑아낼 수도 있고,
GitHub 저장소를 캔버스로 직접 가져오거나 캔버스에서 수정한 내용을 저장소로 보낼 수도 있다.
Code Layer가 잘 동작한다면 디자이너가 Figma에서 직접 UI 코드를 검수하거나, 디자인 시스템 구현 시 디자인-코드 동기화를 더 간결하게 만들어 줄 수 있을 것 같다. Canvas와 DOM의 미묘한 차이를 Figma가 어떻게 풀어냈을지 궁금하다. (아직 베타라 쓰려면 별도 신청해야 한다.)
2. 사람은 방향과 판단에 집중할 수 있어야 한다
“누구나 빠르게 만들 수 있는 시대일수록, 무엇을 만들지 정하고 책임지는 사람의 몫이 더 또렷해진다.”
속도를 ‘더 빨리 만들기’가 아니라 ‘더 잘 고르기’에
Google AntiGravity의 Design Engineer Lead Andy Zhang의 세션이다. “모든 코드가 사용자에게 전달되어야 하는 건 아니다”는 메시지가 인상적이었다.
훌륭한 디자인은 훌륭한 큐레이션에서 나온다는 말처럼, 품질은 기능 몇 개를 출시했느냐가 아니라 수많은 버전에 ‘아니오’라고 한 끝에 무엇에 ‘예’라고 했느냐로 결정된다고 한다.
AI는 코드를 싸고 빠르게 만든다. 하지만 사용자에게 정말 좋은 경험인지 검증(Verify)하는 일은 결국 사람의 몫이다.
양자택일이 아니라, 언제 어디에 무게를 두느냐
시장엔 AI를 보는 두 기류가 있는 것 같다.
A. 더 빠른 빌드에 집중
B. 더 좋은 선택에 집중
이번 Config는 B의 메시지를 전하는 세션이 많았다. 그런데 A와 B는 양자택일일까? 제품 스테이지에 따라 균형점이 다르다면,
0→1(속도·선점·초기 MVP)에선 속도(A)가,
1→n(경쟁 심화·높은 기대·쌓인 레거시)에선 선택(B)이 더 중요하고,
많은 경우 둘 다 놓칠 수 없는 게 현실이기도 하다.
올바른 질문은 “언제, 어디에 무게를 두느냐”인 것 같다. A든 B든 우리가 빨라져야 하는 이유는 ‘피드백을 빠르게 받기’ 위해서다. 경쟁자보다 시행착오를 더 많이, 더 빨리 할 수 있다면 더 빨리 성장하니까.
그래서, 사람이 판단에 집중하려면
방향을 정하고, 무엇에 ‘예’라고 할지 고르고, 어디에 무게를 둘지 정하는 일. 셋 다 사람이 해야 할 일이다.
디자인 시스템은 품질의 바닥을 높이고, 중복 작업을 줄여 사람이 더 중요한 판단에 집중하도록 돕는다.
3. 남는 고민 - 어떻게 디자인 시스템의 비용을 줄일 것인가
디자인 시스템은 여전히 중요하고, 속도와 품질의 균형에도 힘을 보탠다. 그런데 현실은 여전히 난관이다. 디자인 시스템은 공짜가 아니거든.
시스템을 만들고 유지하는 데는 지속적인 투자가 필요하고, 많은 디자인 시스템이 이 비용 장벽 앞에서 무너지고 사라진다.
그래서 이번 Figma Config 2026은 나에겐 조금 아쉬웠다. ‘왜, 무엇을’ 만들지는 많이 말했지만, 정작 ‘구축·유지 비용’을 다루는 세션은 없었다. 그래도 디자인 시스템의 중요성을 다시 확인한 계기가 됐으니 아주 실망스럽진 않다.
우리 팀은 디자인 시스템 비용을 풀어보려고 이런 문제들을 고민하고 있다.
서비스·제품 스테이지에 맞는 적정 수준의 디자인 시스템을 제시할 수 있을까?
어떻게 하면 디자이너가 환영할 수준의 디자인 시스템을 더 저렴하고 빠르게 만들어 낼 수 있을까?
어떻게 하면 더 적은 커뮤니케이션으로 디자인-코드 연결성을 유지할 수 있을까?
비슷한 문제를 고민하거나 관심 있는 분이 있다면 언제든 연락 주면 좋겠다. 같이 고민하고 싶다.

Figma Config 2026에서 찾은 AI 시대 디자인 시스템의 가치

댓글