예전에 만든 디자인 시스템을 로고, 브랜딩, 폰트까지 넣어서 오늘 점검해봤는데, 짜증날 정도로 계속 수정한 끝에 겨우 만족할 만한 결과를 얻었음
그런데 사용량을 보니 주간 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개가 달릴 정도로 반응이 컸음
Hacker News 의견들
예전에 만든 디자인 시스템을 로고, 브랜딩, 폰트까지 넣어서 오늘 점검해봤는데, 짜증날 정도로 계속 수정한 끝에 겨우 만족할 만한 결과를 얻었음
그런데 사용량을 보니 주간 Claude Design 한도의 95% 를 이미 써버린 상태였음
이 정도면 실전 도구라기보다 예시용 장난감에 더 가깝다고 느꼈음
우리가 원하는 스타일과는 전혀 맞지 않았지만, 콘텐츠 그룹핑이나 IA 판단 몇 가지는 내 작업에도 가져올 만했음
전반적으로 인상은 좋았는데, 나중에 Twitter에서 다른 사람의 성공 사례를 보니 내가 받은 목업과 거의 똑같아서 웃겼음
이런 획일화 문제는 AI가 만든 텍스트, 코드, 이미지처럼 계속 따라다닐 거라고 봄
내 처제는 작은 의류 회사를 운영하는데, 지난 6년 동안 실력은 많이 늘었어도 초반에는 아이디어를 실제 결과물로 옮기는 데 정말 고생했음
그런 사람에게는 초기 진입장벽을 낮춰주는 어떤 도구든 충분히 시도해볼 가치가 있다고 생각함
그래도 지금은 research preview 단계니까 앞으로 바뀔 거라고 봄
첫 번째 디자인 시스템으로는 내 iPaaS 스타트업의 새 푸터 섹션을 만들었고, 네 가지 안 중 네 번째가 꽤 좋았음
그다음 Claude Code와 연동해서 조금 다듬고, 코드 생성해서 바로 배포까지 끝냈음. 관심 있으면 tediware.com의 하단 섹션에서 왼쪽 "Origin story"와 오른쪽 가입 패널 부분을 보면 됨
복잡한 구현은 아니었지만, 나온 아이디어와 연동 흐름이 아주 쉬워서 가능성이 크게 느껴졌음
Claude Design은 Opus 4.7을 써서 이전 모델보다 비쌈
아직 출시 이틀째라 완성품이 아니고, Anthropic은 원래 엄청 빠르게 개선하는 편임
게다가 Claude를 오래 써왔다면 이미 내 취향과 스타일을 알고 있어서, 다른 AI 디자인 도구로 갈아타면 다시 처음부터 시작해야 함
대신 ZIP 내보내기는 가능해서, 그 파일을 Google의 Stitch에 넣어봤지만 호환성은 별로 좋지 않았음
나는 Claude Design이 디자인의 모든 복잡성을 없애줄 거라는 주장에는 잘 동의하지 않음
Claude로 바이브 코딩한 앱이 단순해 보이는 건 실제로 제품 범위가 단순하기 때문임
자전거와 비행기를 같은 기준으로 비교하면서 단순함을 착각하는 느낌임
같은 디자인 시스템 컴포넌트를 코드와 Figma에서 만들면 코드는 조건문과 제어 흐름 덕분에 더 간결할 수는 있음
하지만 코드는 화면 위에서 직접 그리는 것보다 덜 유연하고, 창의적 자유도를 내기가 더 어려움
결국 복잡성은 사람이 4개 제품에 8개 모드와 라이트/다크 테마를 얹는 식으로 스스로 만들어내는 경우가 많음
Claude가 유지보수를 조금 쉽게 해줄 수는 있어도 복잡성 자체를 크게 없애주진 못한다고 봄
그래서 이런 흐름은 Figma에 꽤 큰 타격이 될 거라고 봄
그걸 해내는 소프트웨어가 결국 이긴다고 생각함
내가 이해한 게 맞는지 묻고 싶었음
나는 어릴 때부터 개발했지만 CSS는 자신이 없는데, 실제로 개발자들, 심지어 프론트엔드 개발자들까지도 단순히 로고나 랜딩 페이지 스케치가 아니라 제품 전체 디자인을 Figma 같은 걸로 관리하는 디자이너와 협업하는 조직이 많은지 궁금했음
그리고 그런 디자이너들이 개발자가 아닌 상태로도 어떤 스타일 데이터베이스 같은 걸 유지하면서 코드 변경 없이 외형을 다루는 게 목표인지, 아니면 보통은 프론트엔드 개발자들이 Figma를 같이 다루되 코드와 분리된 점을 싫어하는 건지 궁금했음
클라이언트도 그걸 직접 보거나, 최소한 그 Figma 결과물이 반영된 브랜딩 슬라이드를 보며 승인함
이후 프론트엔드는 Figma를 보고 CSS로 다시 구현하는데, Figma의 CSS 복사 기능은 사실상 쓸모없는 inline CSS 수준이라 거의 항상 최선의 근사치로 다시 만듦
단위 체계도 안 맞고, 조상/자식 관계나 CSS 변수, 클래스 계층 같은 것도 반영되지 않음
여러 프론트엔드 개발자가 각자 컴포넌트를 따로 구현하다 보면 드리프트도 생김
그래서 Storybook 같은 Storybook으로 또 다른 프론트엔드 기준점을 만들고, 거기서 React나 NextJS로 넣거나 CMS 컴포넌트로 다시 구현하기도 함
그러다 보면 무엇이 진짜 source of truth냐는 질문이 나오는데, 실제로는 전화 게임처럼 이어진 여러 기준점의 사슬에 가까움
메인 프로젝트 밖에서 따로 만드는 프로모션 랜딩 페이지까지 생기면, 또 다른 시스템에서 같은 디자인을 한 번 더 구현하게 됨
결국 디자인에서 코드로 넘어가는 handoff 간극에서 디자이너 의도가 훼손되거나, 개발자가 문자열 길이, 요소 개수 변화, 실제 스크롤, 다양한 화면 크기 대응 같은 현실 문제를 뒤늦게 떠안게 됨
이 짧은 밈 영상이 웃기면서도 안 웃긴 이유가 바로 그 현실을 너무 잘 찌르기 때문임
대체로 디자이너는 코드를 안 하고 개발자는 디자인을 안 하는 편이고, 둘 다 잘하는 사람은 정말 드묾
솔직히 꽤 끔찍한 방식이지만, 예전 대안들보다는 낫다고 느끼긴 함
그래도 시각 디자인을 코드로 번역하는 지루한 작업을 대부분 자동화하고, 코드와 바로 연결되는 도구보다는 못하다고 봄
나는 Claude Design은 아직 안 써봤지만, Figma의 수많은 GUI 옵션보다는 코드가 훨씬 편한 사람임
나도 질문자와 비슷한 이력이라 그런지, 그런 관점에는 본능적으로 거부감이 듦
시간이 지나도 모든 엔지니어가 스타일 차이 없이 일관된 구현을 하게 만들려면 어느 정도 중앙집중식 기준이 있어야 하기 때문임
나는 요즘 figma-kiwi-protocol로 Figma 프로토콜을 역공학하고 있어서, "Figma가 에이전트 시대에 필요한 학습 데이터를 스스로 배제했다"는 말에 정말 공감했음
Figma의 바이너리 포맷은 모든 걸 새로 만들겠다는 식이라서, 웹·안드로이드·iOS·기타 모든 디자인을 다루다 보니 결국 만능이지만 웹과는 완전한 1:1 대응이 안 됨
그리고 에이전트에게 유용하려면 의도가 분명해야 하는데, 실제로 UX 디자이너가 만든 Figma를 구현해본 사람은 알겠지만 인간도 디자인 의도를 정확히 알기 어려운 경우가 많음
독일어처럼 글자가 길어지면 버튼은 어떻게 되는지, CSS로 옮기니 두 줄로 깨지면 어떻게 할지, iPhone 말고 다른 폰에서는 어떤지, CSS에서 불가능한 그라디언트 보더는 뭘로 대체할지, 4K 화면에서는 어떤지 같은 질문이 계속 나옴
props나 autolayout으로 일부 답할 수는 있지만, 현실의 UX 담당자가 늘 Figma를 완벽히 다루는 신화적 존재는 아님
그래서 내부가 HTML 기반인 도구들이 빨리 따라잡길 기대하고, 가능하면 제품 매니저가 UX 담당자에게 준 프롬프트까지 같이 볼 수 있으면 좋겠다고 생각함
글 자체는 좋았고, 마지막 몇 문단은 정말 웃겼음
특히 뭔가가 다른 것인 척하지 않고, 자기 정체성에 솔직해야 한다는 대목이 마음에 들었음
그러면서 PenPot이 이 에이전트 시대에 꽤 유리한 위치일 수도 있겠다고 떠올렸음
fig 계열의 캔버스 접근과 달리 실제 마크업 기반 디자인 쪽으로 갔으니, 만약 그 방향에 관심이 있다면 더더욱 가능성이 있어 보였음
InVision이 문을 닫고 디지털 화이트보드 쪽으로 선회한 시점부터, 내게 이 디자인 툴 시장은 사실상 끝난 느낌이었음
그만큼 어려운 시장이라고 봄
더 근본적으로는 디자인 시스템을 장기적으로 제대로 유지하기가 너무 어렵고, 특히 코드와 컴포넌트 라이브러리에 깊게 얽혀 있는데 그 층위는 디자이너가 거의 건드리지 않음
Claude Design도 Figma도 다른 어떤 도구도, 재사용 가능하고 보기 좋은 컴포넌트와 레이아웃을 둘러싼 Storybook 지옥을 근본적으로 해결하진 못할 것 같음
해법은 더 아래쪽, 즉 컴포넌트 수준에서 바뀌어야 할 문제처럼 느껴졌음
지금은 새 디자인마다 꽂아 넣을 컴포넌트를 만들어두는 사고방식에 갇혀 있음
마음에 드는 컴포넌트가 생기면 그 정의를 markdown으로 저장하고, 다음 디자인에서는 도구에게 그 markdown을 읽고 필요할 때마다 그 컴포넌트를 써달라고 하면 됨
이렇게 되면 훨씬 더 유연하고 흥미로운 흐름이 나올 거라고 봄
스크립트 가능하고 직접 그릴 수도 있어야 하며, 디자인을 바꾸면 프런트엔드 코드가 곧바로 바뀌고, 코드 변경도 같은 수준으로 디자인에 반영되어야 함
최종형은 디자이너와 프론트엔드 엔지니어가 handoff 없이 공동 저자가 되는 모델이라고 생각함
다만 앞으로는 수정, 추출, 정리가 거의 공짜처럼 되니 그런 구조화 자체가 덜 중요해질 거라는 주장도 있긴 함
나는 아직 완전히 확신하진 않지만, 왜 그런 이야기가 나오는지는 이해함
나는 지난 몇 년간 디자인 도구를 직접 만들어온 입장에서, 이 글은 디자인 영역과 Figma라는 회사 둘 다를 꽤 근본적으로 오해하고 있다고 느낌
Figma는 원래부터 성공적인 제품 못지않게 성공적인 회사를 만드는 데 초점을 맞췄음
처음에는 더 야심찬 방향도 있었고 Evan Wallace 같은 인재 덕분에 실행력도 있었지만, 결국 WebGL 시연보다 돈이 되는 구체적 제품에 집중했기에 지금의 비즈니스가 된 것임
3D 기능 같은 게 없는 것도 그 선택의 결과라고 봄
Figma는 디자인 툴 자체보다 먼저 기업이 실제로 쓰는 제품을 만드는 회사였고, IPO까지 간 시점에서 이미 그 목표는 상당 부분 달성했음
앞으로 시장이 어떻게 될지는 모르지만, 기술적으로 화려한 데모보다 전쟁 자금을 가진 쪽이 훨씬 유리할 수 있음
그리고 기사에서 말하는 문제들은 Figma 사람들도, 사실 디자인 툴을 만들어본 누구나 이미 잘 알고 있음
UI/UX가 디자인·개발·PM의 교차점이라는 것도, 코드 같은 source of truth에 가까워야 한다는 것도 다 자명함
문제는 그걸 실제로 구현하려 하면 디자인 도구를 넘어 코딩, 데이터 관리, 아키텍처 도구까지 번져나가는 엄청난 난제가 된다는 점임
AI 쪽은 나도 확신은 없지만, 최근의 SOTA 모델은 너무 범용성이 높아서 전용 데이터보다 기본 모델의 추론력이 더 중요할 수도 있다고 느낌
UI 디자인은 외부에 드러난 정보가 많아서 웹에서 긁어올 수도 있기 때문임
나는 이 싸움에 특별한 이해관계도 없고, 원글 분석이 맞는지도 잘 모르겠음
그래도 "독점 파일 포맷 때문에 뒤처졌다"는 이야기는 언제 들어도 약간의 샤덴프로이데가 느껴짐
몇몇 지적은 좋았지만, 전체적으로는 완전히 동의하진 않음
Sketch가 Figma에 진 건 디자인 툴링과 멀티플레이어 경험 때문이었다고 봄
물리적 제품도 실제 제작 전에 먼저 설계하듯, 디지털 제품에서도 설계 단계 자체가 사라지진 않을 거라고 생각함
오히려 Figma는 이쪽저쪽 다 하려 하기보다, 자기가 정확히 무엇이 될지 정체성을 빨리 정해야 한다고 봄
Mac 앱을 깔고 특정 파일을 열라고 해야 하는 방식은 시간이 갈수록 파일도 낡고 접근성도 떨어졌음
관련해서 최근 HN 스레드로 Claude Design이 있었고, 2026년 4월 기준으로 댓글 732개가 달릴 정도로 반응이 컸음