Claude Design에 대한 생각과 감상

• 디자인 시스템화가 강화되면서 Figma는 컴포넌트, 스타일, 변수, props 같은 자체 단위를 중심으로 복잡한 구조를 키웠고, 실제 구현 매체와의 거리가 생겨 버림
• Figma의 독자 포맷은 LLM 학습 데이터에서 자연스럽게 배제되었고, 에이전트 시대에 코드 기반 도구가 부상하면서 디자인의 원본(source of truth)이 다시 코드로 이동
• Claude Design은 HTML/JS를 직접 다루는 정직한 매체로서, Figma처럼 코드의 손실 있는 근사치(lossy approximation)를 거치지 않고 실제 구현 매체에서 바로 작업하는 접근
• Claude Code와의 형제 관계를 통해 디자인과 구현 사이의 피드백 루프를 하나의 대화로 통합할 수 있는 구조적 강점 보유
• 디자인 도구 시장이 코드 기반 도구와 순수 탐색 도구로 분기하면서, Figma가 Sketch의 전철을 밟을 가능성이 생겨버림 **Sketch moment**

---

Figma 체계화의 역설

• 제품 팀 규모가 커지면서 디자인이 엔지니어링 조직 안에서 존재를 정당화해야 했고, 이를 위해 체계화(systematization) 방향으로 밀려남
• Figma는 이를 위해 컴포넌트, 스타일, 변수, 프롭 등 독자적 프리미티브를 발명했으나, 일부는 프로그래밍에서 차용하고 일부는 그렇지 않아 어느 것과도 깔끔하게 대응되지 않는 구조
• 가이드라인은 계속 바뀌고, 마이그레이션은 쌓이며, 자동화를 하려면 품질 낮은 플러그인 몇 개에 의존해야 하는 상황
• 이 시스템 자체를 관리하는 데 특화된 디자인 역할이 별도로 생길 정도로 복잡성이 증가

Source of Truth의 이동

• Figma와 코드 사이에는 무엇이 원본(source of truth)이 되어야 하는지에 대한 긴장 관계가 항상 존재
• Figma는 Sketch를 이기면서 자사 도구가 정본(canonical) 이 될 것이라는 입장을 취함
• 그러나 이 승리에는 숨겨진 대가가 존재: 락다운(locked-down) , 대부분 문서화되지 않은 포맷은 프로그래밍적으로 다루기 어려워 LLM의 학습 데이터에서 자연스럽게 배제
• LLM은 코드로 학습되었지 Figma 프리미티브로 학습되지 않았기 때문에, 모델이 Figma의 체계를 배우지 못함
• 코드 작성이 디자이너에게도 쉬워지고 에이전트가 개선되면서, source of truth는 자연스럽게 코드로 회귀하는 흐름을 보임
• Figma가 지난 10년간 도입한 복잡한 인프라가 이에 비하면 과도하게 보일 수밖에 없음

  "도자기를 만들고 싶은데 왜 도자기의 수채화를 그리고 있는가? 그냥 흙을 빚으면 되지 않나?"

Figma 자체 디자인 시스템의 복잡성

• 실제 업무에서 코드에서 직접 수정한 디자인 변경 사항을 Figma로 역이식(back-porting)하는 작업이 매우 고됨
• Figma 자체 제품의 디자인 시스템 파일을 예시로 제시하며, 가장 유능한 디자인 시스템 팀이 만든 결과물임에도 극도로 복잡한 상태
  • 946개의 색상 변수가 "bg/desktopBackgrounded" 같은 중첩 그룹으로 구성되고, 하나의 변수에 Light, Dark, FigJam-Light 등 8가지 모드별 값 존재
  • 모달 푸터 컴포넌트에 12개의 배리언트가 있고, "DS Library Swap", "QA Plugin" 등의 값을 가진 드롭다운과 8개의 프롭 포함
  • 슬라이더 컴포넌트의 이펙트 스타일이 0.5px 드롭 쉐도우 하나를 위해 별도 명명된 스타일로 존재 — CSS 변수와의 대응 관계를 문서화하는 유일한 방법이기 때문
  • 콤보 입력 컴포넌트에 16개 배리언트가 있고, 레이어 이름이 "Default, Default, Close Button=False" 같은 형태
• 색상이 잘못 보일 때의 디버깅 과정: 컴포넌트 확인 → 변수 확인 → 별칭(alias)된 다른 변수 확인 → 모드 확인 → 인스턴스 레벨 오버라이드 확인 → 라이브러리 스왑이 적용된 중첩 컴포넌트 확인이라는 다단계 추적이 필요

Figma Make vs Claude Design

• source of truth가 코드로 이동하면서 Figma는 수동적이고 에이전트 이전(pre-agentic) 시스템을 들고 있는 어색한 위치에 놓임
• 앞으로의 디자인 도구는 두 가지 뚜렷한 형태로 갈라질 가능성이 있음
  • 2016년에 Figma가 답했던 질문: "디자이너인 나의 아이디어를 가장 빨리 꺼낼 수 있는 도구는 무엇인가?" 에 대한 경쟁이 다시 시작
• Figma Make는 이미 Figma 체계에 익숙한 사람들을 위한 도구
  • Figma 스타일, 컴포넌트 라이브러리, 독자 프롭(Prop Props)을 읽어 들이며, 이 새로운 환경에서 여전히 디자인 파일이 정본이라고 가정하는 유일한 도구
  • 시스템 안에 머물고 싶거나 머물 수밖에 없는 사람들을 위한 도구
• Claude Design은 정반대의 베팅
  • Arts and Crafts 운동의 "truth to materials" 원칙 — 사물이 그 자체와 제작 방식에 정직해야 한다는 개념 — 에 부합
  • Figma는 이와 반대로, 극도로 경직된 스키마 위에 자유로운 "바이브" 외피를 씌운 형태 — 타입A 성격이 억지로 편안한 척하면서 내면에서는 프레임 중첩과 토큰 분리를 소리 지르는 것에 비유
  • Claude Design은 거칠지만 최소한 자신이 무엇인지에 대해 정직: 끝까지 HTML과 JS

Claude Design의 구조적 강점

• Claude Design의 형제가 코드를 잘 다루는 Claude Code라는 점이 핵심 구조적 이점
• 궁극적으로 Claude Design에서 Claude Code로 직접 전달하거나 그 반대가 가능한 구조
• Claude Design의 온보딩에서 이미 저장소(repo) 가져오기 기능 제공
• 디자인과 구현 사이의 (역사적으로 항상 마찰의 원인이었던) 피드백 루프가 하나의 대화로 수렴

코드와 무관한 다른 도구의 출현 가능성: 순수 탐색 환경

• 분기의 다른 한 축에서는 코드에 대한 기대가 전혀 없는 도구가 등장할 가능성
• 사각형을 놓고, 레이어 스타일을 쌓고, 블렌드 모드와 그라디언트를 자유롭게 다루며 시스템이나 프롬프트 규칙에 구애받지 않는 순수 탐색 환경
• iPad + Pencil 지원 앱에서 빠르게 사각형을 스케치하는 형태일 수도 있고, 37signals가 재미있는 시도를 할 수 있는 영역
• 반대 방향으로는 Photoshop처럼 고충실도(high-fidelity) 합성에 올인하여 CSS 이펙트의 한계에서 벗어난 상상력 해방 도구로 가는 것
• Figma가 수명의 90% 동안 레이어 이펙트로 드롭 쉐도우나 블러만 제공했다는 점이 이상하게 느껴짐

Figma의 "Sketch 모먼트"

• Figma의 Sketch 모먼트(Sketch가 Figma에 밀려난 것처럼 Figma가 밀려나는 순간)가 빠르게 다가오고 있음

[GN⁺]

Hacker News 의견들

• 예전에 만든 디자인 시스템을 로고, 브랜딩, 폰트까지 넣어서 오늘 점검해봤는데, 짜증날 정도로 계속 수정한 끝에 겨우 만족할 만한 결과를 얻었음
  그런데 사용량을 보니 주간 Claude Design 한도의 95% 를 이미 써버린 상태였음
  이 정도면 실전 도구라기보다 예시용 장난감에 더 가깝다고 느꼈음

  • 나는 몇 주 동안 작업하던 디자인을, 꽤 촘촘한 프롬프트와 요구사항 문서만으로 Claude Design에 다시 시켜봤음. 시각 자료는 넣지 않았는데 결과 자체는 꽤 괜찮았음
    우리가 원하는 스타일과는 전혀 맞지 않았지만, 콘텐츠 그룹핑이나 IA 판단 몇 가지는 내 작업에도 가져올 만했음
    전반적으로 인상은 좋았는데, 나중에 Twitter에서 다른 사람의 성공 사례를 보니 내가 받은 목업과 거의 똑같아서 웃겼음
    이런 획일화 문제는 AI가 만든 텍스트, 코드, 이미지처럼 계속 따라다닐 거라고 봄
  • 이 표현 방식만 봐도 원댓글 작성자는 평균 사용자보다 훨씬 숙련된 사람 같고, 기대치도 더 높아 보였음
    내 처제는 작은 의류 회사를 운영하는데, 지난 6년 동안 실력은 많이 늘었어도 초반에는 아이디어를 실제 결과물로 옮기는 데 정말 고생했음
    그런 사람에게는 초기 진입장벽을 낮춰주는 어떤 도구든 충분히 시도해볼 가치가 있다고 생각함
  • 나도 비슷하게 사용량이 금방 바닥났음. 디자인 시스템 하나를 제대로 세팅하고 두 번째도 거의 완성할 즈음 한도에 가까워졌음
    그래도 지금은 research preview 단계니까 앞으로 바뀔 거라고 봄
    첫 번째 디자인 시스템으로는 내 iPaaS 스타트업의 새 푸터 섹션을 만들었고, 네 가지 안 중 네 번째가 꽤 좋았음
    그다음 Claude Code와 연동해서 조금 다듬고, 코드 생성해서 바로 배포까지 끝냈음. 관심 있으면 tediware.com의 하단 섹션에서 왼쪽 "Origin story"와 오른쪽 가입 패널 부분을 보면 됨
    복잡한 구현은 아니었지만, 나온 아이디어와 연동 흐름이 아주 쉬워서 가능성이 크게 느껴졌음
  • 몇 가지는 감안할 필요가 있음
    Claude Design은 Opus 4.7을 써서 이전 모델보다 비쌈
    아직 출시 이틀째라 완성품이 아니고, Anthropic은 원래 엄청 빠르게 개선하는 편임
    게다가 Claude를 오래 써왔다면 이미 내 취향과 스타일을 알고 있어서, 다른 AI 디자인 도구로 갈아타면 다시 처음부터 시작해야 함
  • 내 경우에는 10분 만에 결과는 아주 좋았는데, 그 직후 사용량이 다 날아가서 일주일을 기다려야 하게 됐음
    대신 ZIP 내보내기는 가능해서, 그 파일을 Google의 Stitch에 넣어봤지만 호환성은 별로 좋지 않았음

• 나는 Claude Design이 디자인의 모든 복잡성을 없애줄 거라는 주장에는 잘 동의하지 않음
  Claude로 바이브 코딩한 앱이 단순해 보이는 건 실제로 제품 범위가 단순하기 때문임
  자전거와 비행기를 같은 기준으로 비교하면서 단순함을 착각하는 느낌임
  같은 디자인 시스템 컴포넌트를 코드와 Figma에서 만들면 코드는 조건문과 제어 흐름 덕분에 더 간결할 수는 있음
  하지만 코드는 화면 위에서 직접 그리는 것보다 덜 유연하고, 창의적 자유도를 내기가 더 어려움
  결국 복잡성은 사람이 4개 제품에 8개 모드와 라이트/다크 테마를 얹는 식으로 스스로 만들어내는 경우가 많음
  Claude가 유지보수를 조금 쉽게 해줄 수는 있어도 복잡성 자체를 크게 없애주진 못한다고 봄

  • 대부분의 사람은 비행기보다 자전거나 자동차만 필요로 함
    그래서 이런 흐름은 Figma에 꽤 큰 타격이 될 거라고 봄
  • 핵심은 결국 복잡한 것을 더 단순하게 만드는 일임
    그걸 해내는 소프트웨어가 결국 이긴다고 생각함

• 내가 이해한 게 맞는지 묻고 싶었음
  나는 어릴 때부터 개발했지만 CSS는 자신이 없는데, 실제로 개발자들, 심지어 프론트엔드 개발자들까지도 단순히 로고나 랜딩 페이지 스케치가 아니라 제품 전체 디자인을 Figma 같은 걸로 관리하는 디자이너와 협업하는 조직이 많은지 궁금했음
  그리고 그런 디자이너들이 개발자가 아닌 상태로도 어떤 스타일 데이터베이스 같은 걸 유지하면서 코드 변경 없이 외형을 다루는 게 목표인지, 아니면 보통은 프론트엔드 개발자들이 Figma를 같이 다루되 코드와 분리된 점을 싫어하는 건지 궁금했음

  • 맞음. 특히 에이전시 쪽에서는 지난 수년간 디자이너가 Figma 안에 픽셀 단위의 컴포넌트 기반 원본을 만들고, 그게 계속 진화하는 단일 기준처럼 쓰이는 경우가 흔했음
    클라이언트도 그걸 직접 보거나, 최소한 그 Figma 결과물이 반영된 브랜딩 슬라이드를 보며 승인함
    이후 프론트엔드는 Figma를 보고 CSS로 다시 구현하는데, Figma의 CSS 복사 기능은 사실상 쓸모없는 inline CSS 수준이라 거의 항상 최선의 근사치로 다시 만듦
    단위 체계도 안 맞고, 조상/자식 관계나 CSS 변수, 클래스 계층 같은 것도 반영되지 않음
    여러 프론트엔드 개발자가 각자 컴포넌트를 따로 구현하다 보면 드리프트도 생김
    그래서 Storybook 같은 Storybook으로 또 다른 프론트엔드 기준점을 만들고, 거기서 React나 NextJS로 넣거나 CMS 컴포넌트로 다시 구현하기도 함
    그러다 보면 무엇이 진짜 source of truth냐는 질문이 나오는데, 실제로는 전화 게임처럼 이어진 여러 기준점의 사슬에 가까움
    메인 프로젝트 밖에서 따로 만드는 프로모션 랜딩 페이지까지 생기면, 또 다른 시스템에서 같은 디자인을 한 번 더 구현하게 됨
  • 위 설명이 거의 완전히 맞고, 이런 구조는 대략 지난 20년 가까이 계속 이어져 왔음. 예전에는 Figma 대신 Photoshop 파일이 디자인 진실의 원천이었을 뿐임
    결국 디자인에서 코드로 넘어가는 handoff 간극에서 디자이너 의도가 훼손되거나, 개발자가 문자열 길이, 요소 개수 변화, 실제 스크롤, 다양한 화면 크기 대응 같은 현실 문제를 뒤늦게 떠안게 됨
    이 짧은 밈 영상이 웃기면서도 안 웃긴 이유가 바로 그 현실을 너무 잘 찌르기 때문임
    대체로 디자이너는 코드를 안 하고 개발자는 디자인을 안 하는 편이고, 둘 다 잘하는 사람은 정말 드묾
  • 맞음. 큰 회사와 일부 작은 회사에서도 Figma는 디자이너가 개발자에게 UI를 넘기는 사실상의 표준임
    솔직히 꽤 끔찍한 방식이지만, 예전 대안들보다는 낫다고 느끼긴 함
    그래도 시각 디자인을 코드로 번역하는 지루한 작업을 대부분 자동화하고, 코드와 바로 연결되는 도구보다는 못하다고 봄
    나는 Claude Design은 아직 안 써봤지만, Figma의 수많은 GUI 옵션보다는 코드가 훨씬 편한 사람임
  • 나는 코드 변경 없이 외형만 조정한다는 그림보다는, Figma가 제품 자체보다 더 권위 있는 원본처럼 여겨지는 사고방식을 실제로 많이 봤음
    나도 질문자와 비슷한 이력이라 그런지, 그런 관점에는 본능적으로 거부감이 듦
  • 큰 회사에서는 그런 구조가 실제로 필요함
    시간이 지나도 모든 엔지니어가 스타일 차이 없이 일관된 구현을 하게 만들려면 어느 정도 중앙집중식 기준이 있어야 하기 때문임

• 나는 요즘 figma-kiwi-protocol로 Figma 프로토콜을 역공학하고 있어서, "Figma가 에이전트 시대에 필요한 학습 데이터를 스스로 배제했다"는 말에 정말 공감했음
  Figma의 바이너리 포맷은 모든 걸 새로 만들겠다는 식이라서, 웹·안드로이드·iOS·기타 모든 디자인을 다루다 보니 결국 만능이지만 웹과는 완전한 1:1 대응이 안 됨
  그리고 에이전트에게 유용하려면 의도가 분명해야 하는데, 실제로 UX 디자이너가 만든 Figma를 구현해본 사람은 알겠지만 인간도 디자인 의도를 정확히 알기 어려운 경우가 많음
  독일어처럼 글자가 길어지면 버튼은 어떻게 되는지, CSS로 옮기니 두 줄로 깨지면 어떻게 할지, iPhone 말고 다른 폰에서는 어떤지, CSS에서 불가능한 그라디언트 보더는 뭘로 대체할지, 4K 화면에서는 어떤지 같은 질문이 계속 나옴
  props나 autolayout으로 일부 답할 수는 있지만, 현실의 UX 담당자가 늘 Figma를 완벽히 다루는 신화적 존재는 아님
  그래서 내부가 HTML 기반인 도구들이 빨리 따라잡길 기대하고, 가능하면 제품 매니저가 UX 담당자에게 준 프롬프트까지 같이 볼 수 있으면 좋겠다고 생각함

• 글 자체는 좋았고, 마지막 몇 문단은 정말 웃겼음
  특히 뭔가가 다른 것인 척하지 않고, 자기 정체성에 솔직해야 한다는 대목이 마음에 들었음
  그러면서 PenPot이 이 에이전트 시대에 꽤 유리한 위치일 수도 있겠다고 떠올렸음
  fig 계열의 캔버스 접근과 달리 실제 마크업 기반 디자인 쪽으로 갔으니, 만약 그 방향에 관심이 있다면 더더욱 가능성이 있어 보였음

  • Penpot UI 자체가 원래 SVG로 만들어진 걸로 기억하는데, 중간에 바뀐 건지 궁금했음

• InVision이 문을 닫고 디지털 화이트보드 쪽으로 선회한 시점부터, 내게 이 디자인 툴 시장은 사실상 끝난 느낌이었음
  그만큼 어려운 시장이라고 봄
  더 근본적으로는 디자인 시스템을 장기적으로 제대로 유지하기가 너무 어렵고, 특히 코드와 컴포넌트 라이브러리에 깊게 얽혀 있는데 그 층위는 디자이너가 거의 건드리지 않음
  Claude Design도 Figma도 다른 어떤 도구도, 재사용 가능하고 보기 좋은 컴포넌트와 레이아웃을 둘러싼 Storybook 지옥을 근본적으로 해결하진 못할 것 같음
  해법은 더 아래쪽, 즉 컴포넌트 수준에서 바뀌어야 할 문제처럼 느껴졌음

  • 어쩌면 미래의 접근은 재사용 가능한 것이 아니라 재구성 가능한 것일 수 있다고 생각함
    지금은 새 디자인마다 꽂아 넣을 컴포넌트를 만들어두는 사고방식에 갇혀 있음
    마음에 드는 컴포넌트가 생기면 그 정의를 markdown으로 저장하고, 다음 디자인에서는 도구에게 그 markdown을 읽고 필요할 때마다 그 컴포넌트를 써달라고 하면 됨
    이렇게 되면 훨씬 더 유연하고 흥미로운 흐름이 나올 거라고 봄
  • 내가 보는 해법은, 디자인과 코드가 완전히 같은 자리에 공존하는 열린 캔버스임
    스크립트 가능하고 직접 그릴 수도 있어야 하며, 디자인을 바꾸면 프런트엔드 코드가 곧바로 바뀌고, 코드 변경도 같은 수준으로 디자인에 반영되어야 함
    최종형은 디자이너와 프론트엔드 엔지니어가 handoff 없이 공동 저자가 되는 모델이라고 생각함
  • 참고로 Claude Code는 예제가 충분히 좋으면 그런 컴포넌트 뼈대를 만드는 데는 제법 괜찮음
    다만 앞으로는 수정, 추출, 정리가 거의 공짜처럼 되니 그런 구조화 자체가 덜 중요해질 거라는 주장도 있긴 함
    나는 아직 완전히 확신하진 않지만, 왜 그런 이야기가 나오는지는 이해함

• 나는 지난 몇 년간 디자인 도구를 직접 만들어온 입장에서, 이 글은 디자인 영역과 Figma라는 회사 둘 다를 꽤 근본적으로 오해하고 있다고 느낌
  Figma는 원래부터 성공적인 제품 못지않게 성공적인 회사를 만드는 데 초점을 맞췄음
  처음에는 더 야심찬 방향도 있었고 Evan Wallace 같은 인재 덕분에 실행력도 있었지만, 결국 WebGL 시연보다 돈이 되는 구체적 제품에 집중했기에 지금의 비즈니스가 된 것임
  3D 기능 같은 게 없는 것도 그 선택의 결과라고 봄
  Figma는 디자인 툴 자체보다 먼저 기업이 실제로 쓰는 제품을 만드는 회사였고, IPO까지 간 시점에서 이미 그 목표는 상당 부분 달성했음
  앞으로 시장이 어떻게 될지는 모르지만, 기술적으로 화려한 데모보다 전쟁 자금을 가진 쪽이 훨씬 유리할 수 있음
  그리고 기사에서 말하는 문제들은 Figma 사람들도, 사실 디자인 툴을 만들어본 누구나 이미 잘 알고 있음
  UI/UX가 디자인·개발·PM의 교차점이라는 것도, 코드 같은 source of truth에 가까워야 한다는 것도 다 자명함
  문제는 그걸 실제로 구현하려 하면 디자인 도구를 넘어 코딩, 데이터 관리, 아키텍처 도구까지 번져나가는 엄청난 난제가 된다는 점임
  AI 쪽은 나도 확신은 없지만, 최근의 SOTA 모델은 너무 범용성이 높아서 전용 데이터보다 기본 모델의 추론력이 더 중요할 수도 있다고 느낌
  UI 디자인은 외부에 드러난 정보가 많아서 웹에서 긁어올 수도 있기 때문임

• 나는 이 싸움에 특별한 이해관계도 없고, 원글 분석이 맞는지도 잘 모르겠음
  그래도 "독점 파일 포맷 때문에 뒤처졌다"는 이야기는 언제 들어도 약간의 샤덴프로이데가 느껴짐

• 몇몇 지적은 좋았지만, 전체적으로는 완전히 동의하진 않음
  Sketch가 Figma에 진 건 디자인 툴링과 멀티플레이어 경험 때문이었다고 봄
  물리적 제품도 실제 제작 전에 먼저 설계하듯, 디지털 제품에서도 설계 단계 자체가 사라지진 않을 거라고 생각함
  오히려 Figma는 이쪽저쪽 다 하려 하기보다, 자기가 정확히 무엇이 될지 정체성을 빨리 정해야 한다고 봄

  • Sketch가 Figma에 진 이유는 툴 기능이나 협업도 있지만, 조직 누구에게나 브라우저 링크 하나만 보내면 열렸다는 점도 컸다고 봄
    Mac 앱을 깔고 특정 파일을 열라고 해야 하는 방식은 시간이 갈수록 파일도 낡고 접근성도 떨어졌음

• 관련해서 최근 HN 스레드로 Claude Design이 있었고, 2026년 4월 기준으로 댓글 732개가 달릴 정도로 반응이 컸음