figma2026년 5월 22일

Figma Make 크레딧을 더 효율적으로 사용하는 7가지 팁 | Figma 블로그 (새 탭에서 열림)

Figma Make에서 크레딧을 효율적으로 사용하려면 긴 프롬프트를 반복하기보다 초기 설계와 변경 범위를 명확히 해야 한다. 첫 프롬프트에 프로젝트의 목표·맥락·제약·완료 기준을 충분히 담고, 이후에는 필요한 부분만 구체적으로 수정하는 방식이 효과적이다. 단순한 시각 변경이나 데이터 수정은 AI에 다시 요청하기보다 Edit 도구나 소스 코드 직접 편집을 활용하는 것이 좋다. ## 초기 프롬프트에 프로젝트의 기준점 담기 - 첫 프롬프트는 단순한 요청이 아니라 프로젝트의 전체 브리프처럼 작성한다. - 다음 내용을 구체적으로 포함한다. - 프로젝트의 목표 - 사용 맥락 - 필요한 UI 요소와 동작 - 기술적·기능적 제약 - 최종적으로 “완료”라고 판단할 기준 - 초기 구조가 탄탄할수록 이후에 잘못된 구현을 되돌리는 비용과 크레딧 사용량이 줄어든다. - 대규모 프로젝트는 다음 순서로 나누는 것이 효과적이다. 1. 화면과 컴포넌트의 전체 구조 설계 2. 기능과 상호작용 구현 3. 콘텐츠 입력 및 시각적 세부 조정 - 구조는 프로젝트가 진행될수록 변경하기 어려우므로 가장 먼저 확정하는 것이 좋다. ## 후속 프롬프트는 변경 범위를 좁혀 작성하기 - 첫 프롬프트 이후의 요청은 전체 프로젝트를 다시 설명하는 것이 아니라 변경 사항(delta)을 전달하는 방식으로 작성한다. - 좋은 후속 프롬프트는 다음 세 가지를 포함한다. - 무엇을 바꿀지 - 어떻게 바꿀지 - 무엇은 그대로 유지할지 - “다시 해줘”, “뭔가 이상해”처럼 모호한 요청보다 다음처럼 대상과 위치를 명시한다. - “캘린더 컴포넌트를 수정해줘” - “이 화면에 새로운 상태를 추가해줘” - “`tokens.ts` 파일을 수정해줘” - 서로 관련된 수정이 같은 컴포넌트나 로직에 집중되어 있다면 한 번에 묶는 편이 효율적이다. - 반대로 관련 없는 변경을 하나의 프롬프트에 섞으면 Make가 의도를 해석하는 비용이 커지고 결과도 불안정해질 수 있다. - 특정 파일, 컴포넌트, 상태를 지정하면 Make가 탐색해야 할 범위가 줄어들어 크레딧을 절약할 수 있다. ## 작은 시각 변경은 Edit 도구로 처리하기 - 간격 조정, 요소 삭제, 텍스트 변경처럼 결과가 거의 완성된 상태에서의 작은 수정은 AI 프롬프트보다 Edit 도구가 빠르다. - 이런 작업을 매번 프롬프트로 요청하면 새로운 설계 문제를 해결하는 것이 아니라 기존 결과를 조금씩 조정하는 데 크레딧을 소비하게 된다. - 직접 편집이 적합한 예시는 다음과 같다. - 여백이나 간격 변경 - 특정 UI 요소 제거 - 문구 수정 - 이미 구현된 컴포넌트의 단순한 스타일 조정 ## 소스 코드에서 동적 콘텐츠 수정하기 - 미리보기 화면에서 직접 수정하기 어려운 동적 콘텐츠는 소스 코드에서 값을 변경하는 편이 효율적이다. - `Go to source`를 사용해 관련 코드로 이동한 뒤 실제 데이터가 정의된 부분을 수정한다. - 반복 컴포넌트 안의 텍스트나 같은 폴더의 목록에서 가져오는 데이터 변경에 특히 유용하다. - **⌘F** 단축키로 코드를 검색해 특정 태그나 콘텐츠를 빠르게 찾을 수 있다. - 우선 `App.tsx`를 확인하고, 해당 코드가 없다면 컴포넌트 폴더의 다른 `.tsx` 파일을 살펴보면 된다. ## 실용적인 작업 원칙 처음에는 프로젝트 구조와 제약을 충분히 설명하고, 이후 요청은 한 번에 하나의 명확한 변경에 집중하는 것이 좋다. 단순한 수정은 Edit 도구나 소스 코드에서 직접 처리하고, AI는 새로운 구조·기능·상호작용처럼 직접 구현하기 복잡한 작업에 사용하는 방식이 크레딧과 시간을 모두 절약한다.

component-designreacttypescriptfigma-make+3

figma2023년 12월 5일

Headspace와 함께 살아 (새 탭에서 열림)

Headspace는 제품·파트너십·브랜드 확장에 대응하려면 수작업과 플러그인 중심의 디자인 시스템을 확장 가능한 구조로 전환해야 했다. 이를 위해 Figma의 변수와 디자인 토큰을 도입하고, 단일 브랜드용 시스템을 여러 브랜드와 플랫폼을 지원하는 시스템으로 재구축했다. 그 결과 디자인·엔지니어링 팀이 공유할 수 있는 소스 오브 트루스를 마련하고, 반복적인 색상·타이포그래피 변경 작업을 크게 줄일 수 있었다. ## 확장에 한계가 있던 기존 디자인 시스템 - Headspace는 앱, 웨어러블, VR, 다양한 브랜드 협업 등 100개국 이상에서 여러 접점을 운영하고 있었다. - 기존 시스템은 수작업과 플러그인에 크게 의존해 규모가 커질수록 유지보수가 어려웠다. - 색상이 고정된 hex 코드로 관리되어 동일한 색상에 여러 값이 생겼고, 화면과 제품 간 사용자 경험이 일관되지 않았다. - 색상 팔레트처럼 단순한 변경에도 디자인 시스템 담당자가 몇 시간에서 며칠을 소비해야 했다. - 플러그인은 임시 해결책이었지만 다음과 같은 문제가 있었다. - 디자이너가 자주 사용하지 않으면 학습 비용이 높았다. - Figma의 스타일을 수정할 때마다 플러그인을 다시 설정해야 했다. - 디자인·엔지니어링 팀이 신뢰할 수 있는 단일 기준점을 제공하지 못했다. ## 여러 브랜드를 위한 시스템으로 전환 - 2021년 Ginger와의 합병이 발표되면서 Headspace는 단일 브랜드용 시스템의 한계를 해결해야 했다. - 새 시스템은 Headspace뿐 아니라 Headspace Care와 향후 파트너 브랜드까지 수용할 수 있어야 했다. - 기존 시스템을 감사한 뒤 컴포넌트와 패턴을 다시 구축해 디자이너와 엔지니어가 쉽게 찾고 참조할 수 있도록 했다. - 이 과정에서 Headspace 최초의 디자인 토큰 시스템을 만들었다. - 색상, 타이포그래피 등 반복적으로 사용되는 디자인 속성을 추상화해 브랜드별로 재사용하고 변경할 수 있는 기반을 마련했다. ## Figma 변수와 디자인 토큰 도입 - Headspace는 기존 플러그인 중심 워크플로를 Figma의 네이티브 변수 기능으로 대체했다. - 색상 값을 직접 입력하는 대신 의미 기반 토큰으로 관리했다. - 예: 특정 hex 코드가 아니라 배경색, 텍스트색, 강조색과 같은 역할 중심 이름을 사용 - 변수에 값을 연결하면 하나의 값을 변경해 이를 사용하는 여러 컴포넌트와 화면에 일괄 반영할 수 있다. - 테마와 브랜드가 달라져도 같은 컴포넌트 구조를 유지하면서 변수 값만 교체할 수 있다. - Steven은 약 2년 동안 플러그인 기반 시스템을 구축했지만, 변수 도입 후 색상 토큰과 타이포그래피를 하루 만에 변수로 구현했다고 설명한다. - 변경 사항은 한 달 이내에 디자이너와 엔지니어에게 배포되었다. ## 디자인·엔지니어링 협업 개선 - 토큰과 컴포넌트를 명확하게 구조화해 디자인과 코드 사이의 대응 관계를 쉽게 만들었다. - 디자이너는 반복적인 스타일 수정 대신 제품 경험과 시스템 개선에 집중할 수 있게 되었다. - 엔지니어는 임의의 색상값이나 스타일을 해석하는 대신 공유된 토큰을 기준으로 구현할 수 있다. - 디자인 시스템이 브랜드 가이드 문서에 머무르지 않고 실제 제품 제작 과정에서 작동하는 소스 오브 트루스가 되었다. - 여러 제품과 플랫폼이 늘어나도 동일한 원칙과 컴포넌트를 재사용할 수 있는 확장성을 확보했다. Headspace 사례는 디자인 시스템을 단순히 컴포넌트 모음으로 관리하기보다, 변수와 토큰을 활용해 브랜드·테마·플랫폼 변화를 흡수하는 구조로 설계해야 한다는 점을 보여준다. 특히 제품과 조직이 빠르게 성장한다면 하드코딩된 스타일과 플러그인 의존성을 줄이고, 의미 기반 토큰과 네이티브 변수부터 정비하는 것이 실용적인 출발점이다.

component-designfigmadesign-systemsdesign-tokens+2