우리는 디자이너를 코드로부터 분리하기 위해 20년을 보냈습니다. AI는 방금 디자인을 다시 코드의 주도권을 잡게 만들었습니다.

시계추가 다시 돌아오고 있습니다

과거에 디자이너들은 코드 안에 있었습니다. Dreamweaver와 WYSIWYG(What You See Is What You Get) 시대에는 시각적 도구로 페이지를 배치하면 도구가 대신 마크업 (Markup)을 작성해 주었습니다. 그 후 업계는 20년 가까운 시간 동안 그 과정을 되돌리는 데 집중했습니다. 우리는 선을 그었습니다. 디자이너는 디자인하고, 개발자는 구축하며, 인간이 그 둘 사이를 번역합니다.

AI는 시계추를 다시 돌리고 있습니다. 디자이너를 다시 코드 안으로 밀어 넣는 방식이 아니라, 그들의 디자인을 코드를 작성하는 기계에 전달하는 방식입니다. 모델을 파일에 지정하면 컴포넌트 (Components)가 나옵니다. 디자인이 다시 코드를 주도하게 된 것입니다.

여기서 잠시 멈춰 생각해야 할 부분이 있습니다. 이것은 Dreamweaver 시절로의 깔끔한 회귀가 아닙니다. 당시에는 생성된 마크업이 아무리 엉망이었더라도, 여전히 사람이 번역 과정에 참여하며 그 결과물에 대한 책임을 졌습니다. 하지만 지금은 아무도 운전석에 앉지 않은 채 디자인이 코드로 직행합니다. 그 운전석이야말로 품질이 강제되던 자리였습니다.

더 나아가기 전에 두 가지만 빠르게 짚고 넘어가겠습니다. 이 논점은 예측 가능한 두 가지 방식으로 오해받곤 하기 때문입니다.

첫째, 이것은 디자이너를 비판하는 것이 아닙니다. 디자이너들은 훌륭한 작업을 합니다. 핵심은 차이점에 있습니다. 훌륭한 디자인 파일을 만드는 요소는 훌륭한 디자인 시스템 (Design System)을 만드는 요소나 좋은 코드를 만드는 요소와 다릅니다. 파일은 디자인을 기준으로 판단됩니다. 시스템은 재사용성, 상태 (States), 내구성(Durability)을 기준으로 판단됩니다. AI 워크플로우 (Workflow)는 그 경계를 흐릿하게 만들며, 바로 그 모호함이 주제의 핵심입니다.

둘째, 만약 당신이 단순한 정적 사이트 (Static Site)를 구축하고 있다면, 디자인에 AI를 적용하는 것은 진정으로 괜찮습니다. 스냅샷 (Snapshot)이 곧 결과물이며, 그대로 배포하면 됩니다. 제가 설명하는 문제는 디자인이 재사용 가능한 시스템, 즉 디자인 시스템, 커스텀 CMS, 동적 UI (Dynamic UI)가 되어야 할 때만 발생합니다. 이 범위를 염두에 두시기 바랍니다.

꿈은 현실입니다

저는 이 꿈에 대해 공정하게 말하고 싶습니다. 왜냐하면 그것은 매혹적이며 부분적으로는 사실이기 때문입니다. 디자인에 AI를 지정하고, 작동하는 코드를 얻는 것, 단 한 단계면 됩니다.

AI는 진정으로 가치 있습니다. 저도 사용합니다. AI 덕분에 이전에는 할 수 없었던 일들을 할 수 있게 되었고, 잘 알지 못하는 코드베이스에서도 촉박한 마감 기한 내에 프로젝트를 마칠 수 있었습니다. 저는 이 도구가 나쁘다고 말하려는 것이 아닙니다.

하지만 그 가치가 어디에 머무는지 주목하십시오. 그 가치는 스냅샷 (snapshot) 수준에 머뭅니다. 진정한 가치는 토대 (foundation)와 같은 것이 아닙니다. 그 간극이 이 포스트의 나머지 내용입니다.

디자인은 토대가 아닙니다

여기에 구체적인 실패 사례가 있으며, 이는 가설이 아닙니다. 팀들은 디자이너가 Figma에서 선택한 변수 이름 (variable names)을 중심으로 전체 토큰 파이프라인 (token pipelines)을 구축합니다. 명명 (Naming)은 디자인 결정이지만, 자동 번역 (auto-translation)은 이를 조용히 하중을 견디는 계약 (load-bearing contract)으로 격상시킵니다. 디자인 파일에서 변수 하나를 변경하면 파이프라인은 하류의 세 단계에서 끊어져 버립니다. 디자인이 토대의 역할을 수행하고 있으며, 원래 그런 용도로 만들어지지 않았기 때문에 망가지고 있는 것입니다.

단 한 쌍의 이름만 봐도 알 수 있습니다. --blue-500은 값 (value)이고, --color-primary는 의도 (intent)입니다. 시스템은 의도에 의존해야 하지만, AI는 디자인이 어느 쪽을 의도했는지 신뢰성 있게 판단할 수 없습니다.

명백한 해결책은 디자이너들이 시스템에 올바른 방식으로 이름을 짓도록 교육하는 것입니다. 하지만 이는 노력을 잘못된 사람에게 투입하는 것입니다. 저는 디자이너들과 협업하는 것을 좋아하지만, 정답은 그들을 모든 토큰 이름을 협상하는 시스템 엔지니어 (systems engineers)로 만드는 것이 아닙니다. 그들의 비전을 내구성 있는 시스템으로 번역하는 것은 그들의 일이 아니라 저의 일입니다. 그 번역은 파이프라인이 되어야 합니다. 디자인 토큰 (design tokens)을 보편적인 표준 (universal standard)에 매핑한 다음, 드리프트 (drift)를 감시하는 것입니다. 그 표준이 무엇인지에 대해서는 다시 다루겠습니다.

명명은 첫 번째 실패 모드 (failure mode)일 뿐입니다. 그것을 제쳐두더라도 더 깊은 문제가 남아 있습니다. 디자인은 정적인 스냅샷 (static snapshot)입니다. 그것은 하나의 화면의 하나의 상태만을 보여줍니다. 재사용 가능한 것과 일회성인 것, 비어 있는 상태 (empty state), 로딩 상태 (loading state), 에러 상태 (error state), 콘텐츠 주도형 (content-driven)인지 고정된 것인지, 또는 CMS가 어떻게 데이터를 공급하는지 등을 인코딩 (encode)하지 않습니다. 그러한 시스템적 맥락 (systemic context)은 개발자의 머릿속과 코드 안에 존재합니다. 파일 안에는 없습니다.

업계는 입력(input) 문제를 인지했으며, 이를 해결하기 위해 움직이고 있습니다. Google은 최근 가공되지 않은 파일 대신 코딩 에이전트(coding agent)에게 구조화된 디자인 시스템을 전달하기 위한 형식인 DESIGN.md를 오픈 소스로 공개했으며, 이미 이에 대한 카탈로그가 형성되고 있습니다.1 이는 실질적인 진전이며, 입력이 줄곧 취약한 연결 고리(weak link)였다는 사실을 말해줍니다. 하지만 이 생각을 잠시 멈춰보세요. DESIGN.md가 멈추는 지점이 바로 핵심이기 때문입니다.

더 깊은 한계는 입력 형식이 아닙니다. 어떤 형태든 디자인 자체가 의사결정을 위한 잘못된 소스(source)라는 점입니다. 모델이 마주할 수 있는 최선의 경우는 디자인 파일의 내부 데이터(guts)이지만, 이는 파운데이션(foundation)이 필요로 하는 그 어떤 것에도 최적화되지 않은 산물입니다. 즉, 디자인 시스템 구조도, 코딩 베스트 프랙티스(coding best practices)도, 개발자나 에이전트의 경험(experience)도 고려되지 않았습니다. 최악의 경우는 스크린샷으로, 구조가 전혀 없는 픽셀(pixels)일 뿐입니다. 결점 없는 추출(extraction)이라 할지라도, 인간이 디자인을 수용하기 위해 내리는 아키텍처적 결정(architectural decisions)을 제공할 수는 없습니다.2 결정은 여전히 인간의 영역으로 남습니다.

따라서 결론은 이렇습니다. 디자인은 파운데이션이 아닙니다. 디자인을 코드로 자동 번역하는 것은 디자인을 파운데이션으로 암묵적으로 격상시키는 것이며, 디자인은 결코 그 역할을 위해 만들어지지 않았습니다.

사람들이 이 문제를 해결하고 있습니다

이 격차는 실재하며, 거대 기업부터 개인 개발자까지 수많은 사람들이 현재 이 문제를 해결하기 위해 노력하고 있습니다. Google의 DESIGN.md는 하나의 움직임입니다. 그 주변에는 거의 하룻밤 사이에 생태계가 형성되었으며, 이미 프로덕션(production) 환경에서 테스트되고 있습니다. 제 친구인 Amrutha Kollu는 이 문제에 접근하는 독립 개발자 중 한 명입니다. 그녀의 도구인 Fixel은 지속적 통합(continuous integration) 과정에서 Figma를 기준으로 코드를 검증하며, 디자인 시스템 드리프트(design-system drift)가 머지(merge)되기 전에 이를 포착합니다. 드리프트가 발견되면 해당 내용을 Figma 캔버스에 댓글로 게시하여, 디자이너가 이미 작업 중인 공간에서 이를 확인할 수 있게 합니다.3 이는 실제적인 문제에 대한 유망한 작업입니다.

이 모든 것이 어디로 귀결될지는 진정으로 열려 있습니다. 많은 똑똑한 사람들이 동시에 서로 다른 각도에서 동일한 문제에 접근하고 있습니다. 이러한 열린 질문이 현재의 솔직한 상태이며, 제가 이 글을 쓰는 큰 이유이기도 합니다.

경계가 흥미로운 부분이기 때문에, 이것이 정확히 어디에 위치하는지 명확히 하고 싶습니다. Fixel은 코드 측면에 있으며, 전체 문제를 해결했다고 주장하지는 않습니다. 언급할 가치가 있는 한계점은—비판이 아닌 아키텍처(Architecture) 관점에서 말씀드리는 것입니다—디자인 도구로부터 직접 읽어온다는 점입니다. 따라서 도구에 결합된(tool-coupled) 방식은 그 밑단의 개방형 표준(open standard)을 목표로 하지 않는 한, 구식이 될 위험이 있습니다. 그 표준은 W3C Design Tokens format, 즉 DTCG입니다. 이는 주요 도구들이 수렴하고 있는 벤더 중립적(vendor-neutral) 사양이며, 여기서 지속 가능한 닻(anchor) 역할을 합니다.

누락된 중간 단계 (The missing middle)

최신 도구들이 이미 이 간극을 메웠다고 생각할 수도 있습니다. 그들은 스크린샷을 읽는 수준을 훨씬 넘어섰습니다. Claude Design은 코드베이스에서 디자인 시스템을 직접 가져와(import), 사용자가 확인하기 전에 출력물을 검증합니다.4 Google의 Stitch는 화면을 그리기 전에 토큰(tokens)을 읽습니다. 이것은 실재하며, 변환(convert) 단계가 진정으로 좋아지고 있다는 증거입니다.

하지만 그 어떤 것도 수행하지 못하는 두 가지가 있습니다. 첫째, 시스템이 이미 존재하며 가져오기에 충분히 깨끗하다고 가정한다는 점입니다. 이는 누군가가 그 기반을 구축했으며 여전히 그것을 소유하고 있음을 의미합니다. 둘째, 생성 시점에 단 한 번만 확인한다는 점입니다. 더 어려운 문제는 코드가 병합(merge)된 이후, 디자인과 시스템이 계속 움직이며 조용히 서로 어긋나기(drift apart) 시작할 때 발생하는 일입니다.

결국 우리는 이 지점에 놓이게 됩니다. 디자인이 코드를 주도하는 것도 아니고, 사람이 모든 화면을 일일이 수동으로 번역하는 것도 아닙니다. 우리에게 남은 것은 누군가가 반드시 책임지고 관리해야 하는 '중간 단계(middle)'입니다.

제가 생각하는 이 '누락된 중간 단계(missing middle)'의 모습에 대해 내릴 수 있는 베팅은 다음과 같습니다. 저는 이것이 빌드 타임의 타입이 지정된 CSS 입력 (typed CSS inputs at build time)에서 시작된다고 생각합니다. 즉, 값이 단순히 모델이 틀릴 수 있는 문자열(string)이 아니라, 타입(type)과 의미(meaning)를 지니는 토대입니다. 그 위에 AI는 자신이 잘하는 일을 수행합니다. AI는 디자인에서 변수들을 추출하고, 그것들이 이미 구축된 시스템에 어떻게 매핑될지를 제안합니다. 그런 다음 UX 엔지니어는 오직 그들만이 할 수 있는 일을 합니다. 그들은 그 제안을 실제로 원하는 시스템의 형태로 다듬고, 각 값이 무엇을 의미하는지 결정하며, 결과물이 충족해야 할 동작(behaviour)과 성공 기준(success criteria)을 설정합니다. 타입이 지정된 입력(Typed inputs)과 자동화된 검사(automated checks)는 AI의 제안이 정직하게 유지되도록 만듭니다.

이러한 결정들은 누군가의 머릿속에만 머물거나 매 실행 시마다 다시 유도되지 않습니다. 그것들은 하나의 아티팩트(artifact), 즉 엔지니어가 소유하며 커밋(commit)되고 버전 관리(versioned)되는 '이 디자인이 시스템에 어떻게 매핑되는가'에 대한 기록이 됩니다. Fixel은 이미 이와 유사한 방식을 구현하고 있습니다. Fixel의 오버라이드 레지스트리(overrides registry)는 의도적인 모든 편차를 이유 및 타임스탬프와 함께 git에 커밋하며, 이는 무언의 추측이 아닌 감사 추적(audit trail) 역할을 합니다. 이것이 바로 DESIGN.md가 도달할 수 없는 영역입니다. DESIGN.md의 서술적인

따라서 진짜 실수는 그곳에 도달하기 위해 AI를 사용하는 것이 아닙니다. 판단(judgment)이 가장 필요할 때, UX 엔지니어를 루프(loop) 밖으로 밀어내고 있다는 점이 문제입니다. 이 역할은 사라지지 않습니다. 대신 이 중간 영역(middle)을 소유하는 사람으로 변화하고 있습니다. 즉, 디자인이 입력되는 시스템, 매핑(mapping), 그리고 디자인이 조용히 (코드의) 기반이 되어버리는 것을 방지하는 계약(contract)을 관리하는 역할로 말입니다.

이 모든 것의 지속 가능한 닻은 매핑 권한을 당신이 쥐고 있는 표준(standard)이며, 그 표준이 바로 제가 다음 기사에서 다룰 내용입니다.

만약 당신이 이 중간 영역을 구축하고 있다면, AI가 제안하는 것과 당신이 결정권을 유지해야 하는 것 사이의 경계를 어떻게 긋고 있는지 진심으로 듣고 싶습니다. 그것이 바로 제가 시작하려는 대화입니다.

1. DESIGN.md는 AI 코딩 에이전트에게 디자인 시스템을 구조화된 방식으로 설명하는 마크다운(Markdown) 파일입니다. 즉, 기계가 읽을 수 있는 토큰(tokens)과 인간이 읽을 수 있는 산문(prose)의 결합입니다. Google Labs는 2026년 4월에 이를 오픈 소스로 공개했습니다. Google Labs의 발표(blog.google, "Stitch DESIGN.md")와 사양 저장소(github.com/google-labs-code/design.md)를 참조하십시오. getdesign.md(VoltAgent가 관리)의 커뮤니티 카탈로그에는 이미 해당 사양을 기반으로 구축된 75개의 DESIGN.md 파일이 나열되어 있습니다 (2026년 6월 기준). ↩

2. 이러한 한계는 실무에서 나타납니다. Atlassian이 DESIGN.md를 자사의 디자인 시스템 툴링과 벤치마킹했을 때, 시스템에 이미 존재하는 컴포넌트(component)를 가져오기보다는 기존 컴포넌트를 재생성할 가능성이 더 높다고 보고했습니다. 컴포넌트가 어떻게 보이는지에 대한 충실한 설명이, 이미 존재하는 컴포넌트를 재사용하겠다는 결정까지 담아내지는 못하기 때문입니다. Atlassian, "Atlassian's DESIGN.md is here: what we learned testing portable design context in practice" (atlassian.com, 2026년 6월)를 참조하십시오. ↩

Amrutha Kollu의 이 격차에 관한 글들을 참조하십시오: Figma를 단일 진실 공급원 (single source of truth)으로 사용하여 5주 만에 60개 이상의 디자인 시스템 컴포넌트를 출시한 방법, 왜 AI가 계속해서 잘못된 디자인 토큰 (design tokens)을 생성하는지와 Figma API를 통해 이를 해결한 방법, 그리고 Check Designs는 당신의 Figma를 검증합니다. 당신의 코드는 무엇을 검증합니까?. Fixel은 디자인 시스템 드리프트 (design-system drift)를 포착하기 위해 CI에서 Figma와 코드를 대조하여 검증합니다. ↩

4. Claude Design, Anthropic Labs (anthropic.com/news/claude-design-anthropic-labs). 2026년 6월 업데이트를 통해 리포지토리(repository)나 파일에서 디자인 시스템을 가져오고, 생성된 결과물을 그에 따라 검증하는 기능이 추가되었습니다. ↩