Figma의 'Sketch 모멘트'가 온다 — Claude Design이 바꾸는 디자인 도구 지형

• 디자이너 Sam Henri Gold가 Claude Design을 써보고 내린 예언 — "Figma의 Sketch 모멘트가 빠르게 다가오고 있다"
  • Sketch가 Figma에 밀렸듯, 이제 Figma가 code-first 도구들에 밀릴 차례라는 얘기
• 핵심 논지는 하나 — "Source of truth가 다시 코드로 돌아간다"

Figma의 숨은 기술 부채

• 제품팀이 커지고 디자인이 엔지니어링 조직 안에서 스스로를 정당화해야 했던 시절, 디자인은 시스템화 압박을 받았음
  • Figma는 components, styles, variables, props 같은 자체 primitives를 발명해서 이 요구를 감당
  • 일부는 프로그래밍에서 빌려왔지만 깔끔하게 매핑되진 않음 — "이 괴물을 길들이는 게 전업인 디자인 역할"이 따로 생길 정도
• Figma가 Sketch를 이긴 이유: "툴링이 canonical source"라는 포지셔닝
  • 그 승리에 숨겨진 비용이 있었음 — Figma 포맷은 lock-down 돼 있고 문서화도 빈약해서 프로그램적으로 다루기 힘듦
  • 결과: LLM 학습 데이터에서 사실상 제외됨 → agentic 시대에 관련성을 잃는 결정타
  • LLM은 Figma primitives를 못 배웠고, 배울 데이터가 없음

Figma 내부 파일조차 지옥인 이유

• 필자는 Figma가 공개한 자기네 디자인 시스템 파일을 봤다고 함 — "가장 유능한 디자인 시스템 팀이 만든 gold standard"
• 그런데도 색 하나 디버그하려면:
  • 컴포넌트 → variable → 다른 variable로 aliased → mode → instance 레벨에서 오버라이드 → 또 nested component 안에 있고 → library swap까지 적용됨
  • "한 분만 더 있으면 시골로 양치기 하러 떠날 지경"이라는 필자의 표현
• 코드에서 이뤄진 디자인 변경을 Figma로 역이식하는 작업을 회사에서 해봤는데 고통스러웠다고 증언

디자인 도구는 두 갈래로 분화된다

• 갈래 1: Claude Design류 — 코드가 source of truth
  • Arts and Crafts 운동의 "truth to materials" 원칙 — 물건은 자기가 뭐고 어떻게 만들어졌는지 정직해야 함
  • Figma는 이 원칙의 반대: 극도로 경직된 스키마 위에 "그냥 느낌대로" 코스튬
  • Claude Design은 거칠어도 정직함 — "HTML과 JS all the way down"
  • 결정적 구조적 우위: sibling이 Claude Code. 곧 Claude Design ↔ Claude Code 왕복이 한 대화로 통합될 것
• 갈래 2: 코드 기대 전혀 없는 순수 탐색 환경
  • 사각형 쌓고 블렌드 모드 뒤섞고 그라데이션에 미쳐도 되는 도구
  • iPad + Apple Pencil로 빠르게 사각형 스케치 하는 앱, 혹은 Photoshop처럼 high-fidelity compositing 올인 도구
  • 필자의 뼈있는 지적: "Figma는 수명의 90% 동안 layer effect가 drop shadow랑 blur뿐이었다는 게 이상하지 않아?"

Figma Make는 왜 답이 아닌가

• Figma Make는 이미 Kool-Aid 마신 사람들에게만 도움됨
  • Figma styles, component libraries, 자체 props(필자 표현: "Prop Props")를 읽음
  • 이 새 지형에서 유일하게 여전히 "디자인 파일이 canonical"이라고 우기는 도구
  • 즉 Figma 생태계 안에 계속 남고 싶은(혹은 떠날 수 없는) 사람용

---

기술 맥락

이 글의 진짜 주장은 "LLM이 학습한 매체가 미래 도구의 source of truth가 된다" 는 거예요. LLM은 HTML·CSS·JavaScript 같은 공개된 텍스트 기반 포맷은 수억 샘플로 학습했지만, Figma의 내부 바이너리 포맷이나 node tree는 본 적이 없거든요. Claude Design이 HTML/JS로 출력을 만드는 이유가 바로 이거예요 — 모델이 잘 아는 매체에서 작업하니까 agent가 곧바로 편집하고 반복할 수 있어요. 반면 Figma Make는 디자인 파일에서 시작해서 코드로 내보내는데, 이 변환 과정에 lossy transformation이 계속 끼어들어요.

두 번째 포인트는 "systematization의 역설" 이에요. 디자인 시스템은 원래 팀 커뮤니케이션을 단순화하려고 만들어졌는데, 현실에서는 variable → variable → mode → instance override → nested component로 이어지는 간접 참조 체인을 만들어냈어요. 이건 프로그래밍의 나쁜 추상화(leaky abstraction)랑 똑같은 문제예요. 코드에서는 이런 체인을 IDE의 "Go to definition"이나 grep으로 추적할 수 있지만, Figma에서는 GUI로 한 단계씩 파고들어야 해서 디버깅이 훨씬 힘들어요.

마지막으로 도구의 분화 예측이 흥미로워요. 필자는 도구가 "코드 기반 생산성 도구"와 "자유로운 탐색 환경" 두 갈래로 갈라질 거라고 봐요. 디자인 시스템이 필요한 단계에서는 코드가 canonical이 되지만, 아이디에이션 단계에서는 오히려 제약 없는 탐색 도구(Photoshop·iPad Pencil 앱)가 필요하거든요. Figma는 둘 다 하려다가 둘 다 애매해진 상태로 남을 수도 있다는 게 이 글의 경고예요.