# Claude Design을 둘러싼 생각과 감정 > Clean Markdown view of GeekNews topic #28682. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28682](https://news.hada.io/topic?id=28682) - GeekNews Markdown: [https://news.hada.io/topic/28682.md](https://news.hada.io/topic/28682.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-04-19T18:40:08+09:00 - Updated: 2026-04-19T18:40:08+09:00 - Original source: [samhenri.gold](https://samhenri.gold/blog/20260418-claude-design/) - Points: 2 - Comments: 1 ## Topic Body - **디자인 시스템화**가 강화되면서 Figma는 components, styles, variables, props 같은 자체 단위를 중심으로 복잡한 구조를 키웠고, 실제 구현 매체와의 거리가 커진 상태 - **source of truth** 경쟁에서는 Figma가 canonical 위치를 내세웠지만, 잠긴 형식과 다루기 어려운 구조 때문에 agentic 환경에서 중요한 학습 기반이 **코드 중심**으로 기운 상태 - 업무 현장에서는 코드에서 직접 바뀐 디자인을 다시 Figma로 옮기는 작업까지 발생했고, color variables 946개, 다중 mode, 복잡한 variants와 props처럼 파일 구조 자체의 부담이 크게 드러난 상태 - **Claude Design**은 Figma Make와 반대로 design file의 정준성을 전제하지 않고, 거칠더라도 **HTML과 JS 기반**임을 숨기지 않는 도구로 자리한 상태 - Claude Code와의 **형제 관계**, 저장소 import 지원, 디자인과 구현을 하나의 대화로 잇는 흐름이 결합되면서, Figma의 **Sketch moment**가 빠르게 다가온다는 인식 형성 --- ### Claude Design와 디자인 도구 변화 - **디자인 시스템화**는 엔지니어링 조직 안에서 정당성을 요구받으면서 강화됐고, Figma는 이를 위해 components, styles, variables, props 같은 자체 기본 단위를 만들어 온 상태 - 일부 개념은 프로그래밍에서 차용됐지만 전체 체계가 깔끔하게 대응되지는 않으며, 가이드 변화와 마이그레이션 누적으로 자동화도 조잡한 플러그인 몇 개에 의존하는 구조 - 이 복잡성 때문에 시스템 자체를 다루는 데 특화된 디자인 역할까지 생긴 상태 - **Figma와 코드 사이의 source of truth 경쟁**이 계속됐고, Figma는 tooling이 canonical이라는 위치를 내세우며 Sketch보다 우위를 점한 상태 - 그러나 잠긴 형식과 부족한 문서화, 프로그래밍적으로 다루기 어려운 구조 때문에 agentic 시대에 중요해진 학습 데이터에서 스스로 배제되는 비용 발생 - LLM은 **Figma primitives가 아니라 코드**로 학습됐고, 모델이 Figma의 내부 단위를 익히지 못한 상태 - 디자이너가 코드를 더 쉽게 작성하게 되고 에이전트 성능이 계속 좋아지면서 **source of truth가 다시 코드로 이동**하는 흐름 - 지난 10년간 Figma가 도입한 복잡한 인프라는 그에 비해 과도하게 보이게 되며, 실제로 구현될 매체를 손실된 근사치로 다루기보다 직접 그 매체에서 작업하는 편이 자연스러운 구조 - 업무 현장에서도 **코드에서 직접 바뀐 디자인을 Figma로 역이식**하는 작업이 있었고, 그 과정은 즐겁지 않은 상태 - 비교 대상으로 Figma 자체 제품의 디자인 시스템 파일을 제시하며, 가장 유능한 팀이 만들었을 것으로 가정해도 구조가 매우 복잡한 상태 ### Figma 파일 복잡성 사례 - **변수 패널**에 946개의 color variables가 중첩 그룹으로 정리되어 있고, 단일 변수에 Light, Dark, FigJam-Light, FigJam-Dark, DevMode-Light, DevMode-Dark, Slides-Light, Slides-Dark의 8개 mode 값 연결 상태 - **모달 footer 컴포넌트**의 variant 편집기에는 12개 variants가 있고, 드롭다운에 DS Library Swap, QA Plugin, Growth Stepper, Sharing Actions 같은 값 포함 - 오른쪽 패널에는 Border, Second CTA, Helper Text 등 8개 props 표시 상태 - **effect styles 패널**에서 slider 컴포넌트의 style 이름이 light/elevation-300-tooltip으로 지정되어 있고, 정의를 펼치면 30% black의 0.5px drop shadow 하나가 전체 내용 - 해당 CSS variable과 대응 관계를 문서화하는 유일한 방법이기 때문에 이런 이름의 style이 별도로 존재하는 구조 - **combo input 컴포넌트**에는 16개 variants가 있고, layers 패널의 자식 이름이 "Default, Default, Close Button=False", "Default, Focused, Close Button=True" 같은 형태 - 색상이 잘못 보이는 문제를 디버깅하는 과정도 복잡한 체인 구조 - 컴포넌트가 variable을 사용하고, 그 variable이 다른 variable에 alias되며, 다시 mode를 참조하고, mode는 instance 수준에서 override되며, 그 instance는 library swap이 적용된 중첩 컴포넌트 안에 존재하는 형태 ### 갈라지는 두 가지 디자인 도구 형태 - 앞으로의 디자인 도구는 **두 가지 뚜렷한 형태**로 갈라질 가능성 제기 - 2016년 Figma와 다른 도구들이 겨뤘던 질문인 “디자이너가 아이디어를 가장 빨리 꺼내게 도와주는 도구가 무엇인가”가 다시 초기화되는 구도 - **Figma Make**는 새 환경에서도 design file이 canonical이라는 전제를 유지하는 도구로 규정된 상태 - Figma styles, component libraries, proprietary props를 읽고, 시스템 내부에 머무르려는 사람 또는 머물 수밖에 없는 사람에게 유리한 성격 - 반대로 **Claude Design**은 정반대 선택을 하는 첫 번째 도구로 위치한 상태 - Arts and Crafts의 “truth to materials” 원칙과 연결되며, 사물이 무엇이고 어떻게 만들어졌는지에 솔직해야 한다는 관점과 맞닿은 상태 - Figma는 매우 경직된 스키마 위에 자유로운 것처럼 보이는 외형을 덧씌운 반대편 사례로 배치된 상태 - Claude Design은 거칠더라도 **HTML과 JS 기반**이라는 점을 숨기지 않는 구조 - Gustav Stickley의 1902년경 lamp table 사례와 연결되며, joinery를 숨기지 않고 wood는 그대로 wood인 상태와 비슷한 비유 ### Claude Design의 구조적 이점 - **Claude Code와 형제 관계**라는 점이 큰 구조적 이점 - 장기적으로 Claude Design이 결과물을 직접 Claude Code로 넘기고, 반대로도 연결되는 흐름 예상 - Claude Design의 onboarding에서 이미 **저장소 import** 지원 상태 - 디자인과 구현 사이의 피드백 루프는 오래된 마찰 지점이었지만, 하나의 대화로 합쳐지는 방향 제시 ### 코드와 무관한 다른 도구 가능성 - 다른 한 축의 새 도구는 **코드에 대한 기대가 전혀 없는 순수 탐색 환경** 가능성 - rectangles를 놓고, layer styles를 쌓고, blend modes와 gradients를 조정하며, 시스템이나 프롬프팅 규약에 얽매이지 않고 실험하는 공간 성격 - iPad app과 Pencil 지원으로 빠르게 사각형을 스케치하는 형태 가능성 언급 - 37signals의 Draft for iPad 링크 함께 제시 - 또는 더 반대 방향으로 가서 **Photoshop에 가까운 고충실도 compositing** 중심 도구 가능성 - CSS effects의 한계에 더 이상 얽매이지 않게 되면서 상상력을 더 넓게 쓰는 방향 - Figma는 수명의 90% 동안 사실상 **drop shadow와 blur만 layer effect로 제공**했다는 지적 포함 ### Figma의 Sketch moment - **Figma의 Sketch moment**가 빠르게 다가오는 상태라는 표현 - 추가 설명 없음 ### 추가 문구 - ## 추신 - Figma 내부 Slack에서 이 글이 퍼질 수 있다는 상상과 함께, 지난해 인터뷰 당시 채용했더라면 이런 일이 없었을 것이라는 문구 포함 - Sketch를 향해 particle effects, debossing effects, mesh transforms, metal shaders 추가와 같은 강한 표현의 촉구 포함 - Mac native라는 점에 기대지 말고 더 적극적으로 움직이라는 표현 포함 - 욕설에 대한 사과 문구 포함 - ## 덧붙이는 추신 - @jonnyburch가 비슷한 생각을 담은 블로그 글 링크를 공유했고, 더 깊게 보고 싶다면 좋다는 언급 포함 ## Comments ### Comment 55828 - Author: neo - Created: 2026-04-19T18:40:09+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47818700) - 예전에 만든 **디자인 시스템**을 로고, 브랜딩, 폰트까지 넣어서 오늘 점검해봤는데, 짜증날 정도로 계속 수정한 끝에 겨우 만족할 만한 결과를 얻었음 그런데 사용량을 보니 주간 Claude Design 한도의 **95%** 를 이미 써버린 상태였음 이 정도면 실전 도구라기보다 예시용 장난감에 더 가깝다고 느꼈음 - 나는 몇 주 동안 작업하던 디자인을, 꽤 촘촘한 프롬프트와 요구사항 문서만으로 Claude Design에 다시 시켜봤음. 시각 자료는 넣지 않았는데 결과 자체는 꽤 괜찮았음 우리가 원하는 스타일과는 전혀 맞지 않았지만, **콘텐츠 그룹핑**이나 IA 판단 몇 가지는 내 작업에도 가져올 만했음 전반적으로 인상은 좋았는데, 나중에 Twitter에서 다른 사람의 성공 사례를 보니 내가 받은 목업과 거의 똑같아서 웃겼음 이런 **획일화** 문제는 AI가 만든 텍스트, 코드, 이미지처럼 계속 따라다닐 거라고 봄 - 이 표현 방식만 봐도 원댓글 작성자는 평균 사용자보다 훨씬 숙련된 사람 같고, 기대치도 더 높아 보였음 내 처제는 작은 의류 회사를 운영하는데, 지난 6년 동안 실력은 많이 늘었어도 초반에는 아이디어를 실제 결과물로 옮기는 데 정말 고생했음 그런 사람에게는 **초기 진입장벽**을 낮춰주는 어떤 도구든 충분히 시도해볼 가치가 있다고 생각함 - 나도 비슷하게 사용량이 금방 바닥났음. 디자인 시스템 하나를 제대로 세팅하고 두 번째도 거의 완성할 즈음 한도에 가까워졌음 그래도 지금은 **research preview** 단계니까 앞으로 바뀔 거라고 봄 첫 번째 디자인 시스템으로는 내 iPaaS 스타트업의 새 푸터 섹션을 만들었고, 네 가지 안 중 네 번째가 꽤 좋았음 그다음 Claude Code와 연동해서 조금 다듬고, 코드 생성해서 바로 배포까지 끝냈음. 관심 있으면 [tediware.com의 하단 섹션](https://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**](https://storybook.js.org)으로 또 다른 프론트엔드 기준점을 만들고, 거기서 React나 NextJS로 넣거나 CMS 컴포넌트로 다시 구현하기도 함 그러다 보면 무엇이 진짜 source of truth냐는 질문이 나오는데, 실제로는 전화 게임처럼 이어진 여러 기준점의 사슬에 가까움 메인 프로젝트 밖에서 따로 만드는 프로모션 랜딩 페이지까지 생기면, 또 다른 시스템에서 같은 디자인을 한 번 더 구현하게 됨 - 위 설명이 거의 완전히 맞고, 이런 구조는 대략 지난 **20년** 가까이 계속 이어져 왔음. 예전에는 Figma 대신 Photoshop 파일이 디자인 진실의 원천이었을 뿐임 결국 디자인에서 코드로 넘어가는 **handoff 간극**에서 디자이너 의도가 훼손되거나, 개발자가 문자열 길이, 요소 개수 변화, 실제 스크롤, 다양한 화면 크기 대응 같은 현실 문제를 뒤늦게 떠안게 됨 이 [짧은 밈 영상](https://www.youtube.com/shorts/r6JXc4zfWw4)이 웃기면서도 안 웃긴 이유가 바로 그 현실을 너무 잘 찌르기 때문임 대체로 디자이너는 코드를 안 하고 개발자는 디자인을 안 하는 편이고, 둘 다 잘하는 사람은 정말 드묾 - 맞음. 큰 회사와 일부 작은 회사에서도 Figma는 디자이너가 개발자에게 UI를 넘기는 **사실상의 표준**임 솔직히 꽤 끔찍한 방식이지만, 예전 대안들보다는 낫다고 느끼긴 함 그래도 시각 디자인을 코드로 번역하는 **지루한 작업**을 대부분 자동화하고, 코드와 바로 연결되는 도구보다는 못하다고 봄 나는 Claude Design은 아직 안 써봤지만, Figma의 수많은 GUI 옵션보다는 코드가 훨씬 편한 사람임 - 나는 코드 변경 없이 외형만 조정한다는 그림보다는, Figma가 제품 자체보다 더 **권위 있는 원본**처럼 여겨지는 사고방식을 실제로 많이 봤음 나도 질문자와 비슷한 이력이라 그런지, 그런 관점에는 본능적으로 거부감이 듦 - 큰 회사에서는 그런 구조가 실제로 필요함 시간이 지나도 모든 엔지니어가 스타일 차이 없이 **일관된 구현**을 하게 만들려면 어느 정도 중앙집중식 기준이 있어야 하기 때문임 - 나는 요즘 [figma-kiwi-protocol](https://github.com/allan-simon/figma-kiwi-protocol)로 **Figma 프로토콜**을 역공학하고 있어서, "Figma가 에이전트 시대에 필요한 학습 데이터를 스스로 배제했다"는 말에 정말 공감했음 Figma의 바이너리 포맷은 모든 걸 새로 만들겠다는 식이라서, 웹·안드로이드·iOS·기타 모든 디자인을 다루다 보니 결국 만능이지만 웹과는 완전한 1:1 대응이 안 됨 그리고 에이전트에게 유용하려면 의도가 분명해야 하는데, 실제로 UX 디자이너가 만든 Figma를 구현해본 사람은 알겠지만 인간도 **디자인 의도**를 정확히 알기 어려운 경우가 많음 독일어처럼 글자가 길어지면 버튼은 어떻게 되는지, CSS로 옮기니 두 줄로 깨지면 어떻게 할지, iPhone 말고 다른 폰에서는 어떤지, CSS에서 불가능한 그라디언트 보더는 뭘로 대체할지, 4K 화면에서는 어떤지 같은 질문이 계속 나옴 props나 autolayout으로 일부 답할 수는 있지만, 현실의 UX 담당자가 늘 Figma를 완벽히 다루는 **신화적 존재**는 아님 그래서 내부가 HTML 기반인 도구들이 빨리 따라잡길 기대하고, 가능하면 제품 매니저가 UX 담당자에게 준 프롬프트까지 같이 볼 수 있으면 좋겠다고 생각함 - 글 자체는 좋았고, 마지막 몇 문단은 정말 웃겼음 특히 뭔가가 다른 것인 척하지 않고, **자기 정체성**에 솔직해야 한다는 대목이 마음에 들었음 그러면서 [PenPot](https://penpot.app)이 이 에이전트 시대에 꽤 유리한 위치일 수도 있겠다고 떠올렸음 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](https://news.ycombinator.com/item?id=47806725)이 있었고, 2026년 4월 기준으로 **댓글 732개**가 달릴 정도로 반응이 컸음