Figma Make 크레딧을 더 효율적으로 사용하는 7가지 팁

1년 전 Figma Make를 출시한 이후, 반복적으로 나타나는 한 가지 패턴이 있습니다. AI 프로토타입 제작에서 가장 좋은 결과를 얻어내는 팀들이 반드시 가장 길고 장황한 프롬프트를 작성하는 것은 아닙니다. 그들은 업무를 잘 구성하고, 편집 범위를 명확하게 설정하며, 협업을 위한 컨텍스트를 확장하는 방법을 이해하고 있는 사람들입니다.

이 7가지 팁을 통해 Make에서 같은 방식으로 작업할 수 있습니다.

1. 첫 번째 프롬프트가 가장 중요한 역할을 해야 합니다

첫 번째 프롬프트는 프로젝트의 구조를 설정하고, 제약 조건을 확립합니다. 시작 지점이 완전할수록 나중에 수정하는 데 드는 시간이 줄어듭니다.

유용한 실무 원칙 하나는 첫 번째 프롬프트는 브리프로 생각하고, 이후의 모든 프롬프트는 변경 사항으로 취급하는 것입니다. 즉, 첫 번째 프롬프트에는 다음 내용이 반드시 포함되어야 합니다.

• 목표
• 컨텍스
• 모든 주요 요소, 동작 및 제약 조건
• 최종적으로 "완료된 결과물"의 모습

구축하기 좋은 탄탄한 기반이 마련되면, 후속 프롬프트는 훨씬 짧아질 수 있습니다. 좋은 후속 프롬프트는 보통 다음 세 가지를 포함합니다.

• 무엇을 변경할 것인지
• 어떻게 변경될 것인지
• 무엇이 그대로 유지되어야 하는지

규모가 큰 제작이라면 작업을 여러 단계로 나누어 진행하는 것을 고려해 보세요. 콘텐츠 세부 사항에 너무 신경 쓰지 말고, 먼저 프로젝트의 구조를 제대로 잡으세요. 제작이 깊이 있게 진행된 후에는 구조를 바꾸는 것이 가장 어려운 일이기 때문입니다. 그다음으로 인텔리전스와 동작을 추가하고, 그 후 콘텐츠를 다듬고 마무리하세요.

동일한 로직이나 UI와 관련된 수정인 경우를 제외하고 하나의 후속 프롬프트에 너무 많은 변경 사항을 포함하지 마세요. 세 가지 수정 사항이 모두 동일한 컴포넌트에 영향을 미친다면, 여러 번 반복하기보다 한 번에 묶어서 요청하는 것이 더 효율적입니다.

후속 프롬프트는 범위가 명확할수록 더 효과적입니다. Make가 무엇을 변경해야 하는지 구체적으로 명시할수록 더 효율적으로 작업할 수 있습니다. 예를 들어, "캘린더 컴포넌트를 업데이트해 줘", "이 화면에 새로운 상태를 추가해 줘" 또는 "tokens.ts 파일을 편집해 줘"와 같은 명확한 지시는 "그건 맞지 않아, 다시 해줄 수 있어?"보다 Make에 훨씬 더 명확하게 전달할 수 있습니다. 구체적인 프롬프트는 Make가 어디를 보고 무엇을 해야 할지 정확히 알려줍니다. 모호한 프롬프트는 Make가 사용자의 의도를 해석한 후 가장 효과적으로 달성할 방법을 추측해야 하며, 추가 비용이 발생합니다.

2. 특정 변경 사항에 대해서는 수동 편집을 우선으로 합니다

Make를 가장 잘 활용하는 팀들은 언제 프롬프트 입력을 중단하고 직접 편집을 시작해야 하는지도 알고 있습니다. 간격 미세 조정, 요소 삭제, 텍스트 수정과 같은 작은 시각적 변경은 편집 도구가 가장 빠른 방법인 경우가 많습니다. 편집 도구를 사용하여 전체 문제를 다시 열지 않고도 필요한 부분만 조정할 수 있습니다. 이것이 중요한 이유는 많은 후속 프롬프트가 실제로 Make에 새로운 디자인 문제 해결을 요청하는 것이 아니라, 이미 기본적으로 완성된 결과물을 미세 조정해 달라고 요청하는 것이기 때문입니다.

코드에서도 마찬가지입니다. Make에서 가장 효율적인 변경 중 일부는 소스로 바로 이동하여 관련 값을 직접 수정할 때 이루어집니다. 이는 특히 어떤 요소가 동적이어서 미리보기만으로는 편집할 수 없는 경우에 유용합니다. 예를 들어, 반복되는 컴포넌트 내의 텍스트를 업데이트해야 하거나, 같은 폴더의 목록에서 가져온 데이터를 변경해야 하는 경우입니다. 원하는 결과물이 나올 때까지 프롬프트를 계속 입력하는 대신, 소스로 이동 기능을 사용해 코드를 검색하고 해당 위치에서 직접 변경할 수 있습니다.

이 장점을 누리기 위해서는 개발자가 아니어도 됩니다. Make 코드는 충분히 읽기 쉬워서 필요한 부분을 찾을 수 있습니다. 특히 어떤 요소나 동작을 수정하려는지 이미 알고 있다면 더 쉽습니다.

더 큰 규모의 시각적 변경이 필요하다면 Figma Design 캔버스를 사용하는 것을 권장합니다. 디자인 복사 기능을 사용하면 Make 미리보기를 Figma Design에 편집 가능한 레이어로 가져온 다음, 익숙한 도구로 디자인을 변경하고 한 줄의 프롬프트로 그 방향성을 다시 Make로 보낼 수 있습니다. 이러한 하이브리드 업무 흐름은 시각적 변경을 하나씩 프롬프트로 입력하는 것보다 훨씬 빠를 수 있습니다. 예를 들어, 동료 디자이너 옹호자 Miggi Cardona는 다크 모드로 완성된 작동 가능한 오디오 앱을 생성했는데, 이를 캔버스로 복사하여 라이트 버전을 제작한 뒤 그 결과를 프로토타입 업데이트를 위한 컨텍스트로 다시 Make에 전달했습니다. 단 한 번의 프롬프트만 필요했고, 추측하거나 해석할 필요도 없었습니다. 간단하고 효율적입니다!

요점은 프롬프트를 생성, 추론, 대규모 변환과 같이 가장 잘하는 작업에 사용하고, 작업이 더 시각적일 때는 수동 편집을 선택하는 것입니다.

3. 반복되는 프롬프트를 규칙과 업무 흐름으로 변환하세요

같은 지시사항을 반복하고 있다면, 이제 그 내용을 프롬프트 밖으로 분리해 낼 때입니다. 이때 guidelines.md 같은 마크다운 파일이 가치를 발휘합니다. 업무 흐름에서 AI를 가장 잘 활용하는 팀들은 이러한 파일을 보유하고 있으면 좋은 요소가 아닌 체계적인 프로젝트 필수 요구사항으로 취급합니다.

좋은 guidelines.md 파일에는 Make가 프로젝트 전체에서 따라야 할 규칙들이 정리되어 있습니다.

• 디자인 시스템에 무엇이 포함되어 있는지
• 어떤 명명 규칙을 따라야 하는지
• 어떤 패턴을 선호하는지
• 어떤 품질 기준을 목표로 할 것인지
• 공통적인 결정을 위한 올바른 단일 진실 공급원(SSOT)이 어디에 있는지

이를 Make가 항상 숙지하고 있어야 하는 규칙과 참고 자료를 보관하는 재사용 가능한 프로젝트 메모리라고 생각해 보세요. 매번 다시 학습할 필요가 없기 때문에 두 가지 이점을 얻을 수 있습니다. 프롬프트에서 반복이 줄어들고 첫 결과물이 더 좋아집니다.

여기서는 구조가 중요합니다. 하나의 방대한 마크다운 파일이 항상 최선의 방법은 아닙니다. 대부분의 경우 기본 가이드라인 파일 하나와, 더 구체적인 주제를 다루는 작은 보조 .md 파일인 컴포넌트, 모션, 토큰 또는 콘텐츠 패턴 등으로 나누는 것이 더 깔끔합니다. 모델이 이러한 파일을 더 쉽게 읽을 수 있을수록, 그 파일들은 더 유용해집니다. 명확한 섹션 제목, 일관된 라벨, 의미론적 명명 규칙, 그리고 중복을 줄이는 것이 모두 도움이 됩니다.

반복하는 것이 단순한 컨텍스트가 아니라 전체 업무 흐름이라면, 그다음 단계는 skills.md 파일입니다. Guidelines.md와 skills.md는 모두 마크다운 파일이기 때문에 헷갈리기 쉽습니다. 본질적으로 둘 다 Make가 더 신뢰할 수 있는 결과를 생성하도록 돕는 일반적인 텍스트 지침입니다. 차이점은 각자 수행하는 역할입니다.

• 가이드라인: Make 프로젝트가 배경에서 항상 유지하는 항상 활성화된 앰비언트 프로젝트 메모리
• 스킬: 특정 작업이 필요할 때 호출하는 온디맨드 업무 흐름

가이드라인이 Make에게 무엇을 알아야 하는지 알려준다면, AI 스킬은 Make에게 무엇을 해야 하는지를 알려줍니다. 스킬은 디자인 표준에 따른 화면 검토, 제품 개발 로드맵(PRD) 기반 제작, 제품 카피 검사, 또는 특정 유형 인터페이스 생성 등 반복되는 작업의 매뉴얼처럼 작동합니다. 매번 길고 동일한 일련의 프롬프트를 다시 작성하는 대신 그 프로세스를 하나의 스킬로 만들어 필요할 때마다 호출할 수 있습니다.

4. 외부 컨텍스트를 가져올 때는 신중하게 판단하세요

guidelines.md가 상시 지침을 저장하는 곳이라면, MCP 커넥터는 작업에 필요한 외부 컨텍스트를 가져오는 방입니다.

커넥터는 Make가 프로젝트 자체의 범위를 벗어난 항목에 접근해야 할 때 가장 유용합니다. 예를 들어 실시간 사양, 티켓, 디자인 시스템 레퍼런스, 기술 문서, 버그 리포트, 다른 도구에서의 작업공간, 또는 맞춤형 내부 시스템 등입니다. 그러나 더 많은 컨텍스트가 항상 더 좋은 것은 아닙니다.

주의 깊게 봐야 할 세부 사항을 지정하지 않은 채 Make를 거대한 외부 자료에 연결하는 것은, 작업을 필요 이상으로 어렵게 만드는 가장 쉬운 방법 중 하나입니다.거대한 Notion 페이지, 광범위한 Jira 또는 Linear 쿼리, 또는 커넥터 작업공간 전반에 걸친 오픈 엔드 검색은 모두 노이즈를 유발합니다. 모델은 무엇을 해야 하는지뿐만 아니라, 어떤 컨텍스트가 실제로 해당 작업과 관련되어 있는지를 판단해야 하기 때문입니다.

더 좋은 접근 방식은 검색 범위를 좁게 설정하는 것입니다. 정확한 문서를 지정하고, 정확한 티켓을 링크하며, 특정한 파일, 오류, 또는 컴포넌트트의 이름을 정확히 명시하세요. Make가 필요한 것이 단락 하나나 요구사항 몇 가지뿐이라면, AI가 직접 찾게 하기보다 해당 발췌를 그대로 붙여넣는 것을 고려해 보세요.

또한 여기에서 파일 첨부 기능이 유용할 수 있습니다. 작업에 라이브 소스가 필요하다면 커넥터가 적합한 도구입니다. 그러나 이미 가지고 있는 특정 파일을 활용하는 경우라면, 프롬프트 내에 그 파일을 직접 첨부하는 것이 더 효율적인 방법입니다. 연구 결과 보고서 PDF는 Make에 작업할 때 필요한 근거 자료를 제공할 수 있습니다. CSV 데이터 세트를 사용하면 Make가 실제 값으로 대시보드, 테이블 또는 프로필 화면을 프로필 화면을 채울 수 있습니다. 동영상이나 미디어 에셋을 이용하면 Make가 입력 예시를 생성하는 대신 실제 자료를 임베드할 수 있습니다.

어떤 경우든 목표는 단순합니다. Make가 최대한 쉽게 작업할 수 있도록 원본 자료를 제공하는 것입니다. 여기에서 AI 스킬도 도움이 될 수 있습니다. 커넥터, 사용자 정의 MCP, 또는 첨부 파일을 사용할 때 Make가 따라야 할 정확한 단계를 제공함으로써 보다 통제되고 예측 가능하며 효율적인 결과를 얻을 수 있습니다. 목표는 최대한 많은 컨텍스트를 제공하는 것이 아니라, Make에 알맞은 컨텍스트를 제공하는 것입니다.

5. 재사용 가능한 기반을 만들고 확장하세요

Make에서 가장 빠르게 구축하는 방법은 매번 같은 UI를 처음부터 다시 만들지 않는 것입니다. Make 키트와 템플릿 둘 다 이미 컨텍스트, 재사용 가능한 패턴 및 심지어 작동하는 구조까지 포함된 출발점을 제공합니다. 이는 불필요한 재작업을 줄이는 가장 쉬운 방법 중 하나입니다. 잘 만들어진 재사용 가능한 기반은 백지상태에서 프롬프트를 작성하는 것을 방지하고, 할루시네이션 가능성을 줄여주며, 팀 내의 더 많은 사람에게 강력한 시작점을 빠르게 제공할 수 있습니다.

Make 키트를 공유된 시스템 재료라 생각하세요. 이를 통해 Make에서 0→1로 작업할 때, 기초 구조, 토큰, 컴포넌트 및 guidelines.md 같은 요소의 배포를 확장할 수 있습니다. React 컴포넌트를 npm 패키지로 사용할 수 있는 팀에게는 특히 강력한 기능이 될 수 있습니다. Make 키트는 처음부터 대략적으로 추측해서 만드는 대신에 개발 팀이 실제 프로덕션에서 사용 중인 컴포넌트와 패턴을 그대로 프로젝트로 가져올 수 있습니다.

반면 템플릿은 제품 기본 골격, 선호하는 레이아웃, 심지어 스타터 프롬프트까지 포함한 재사용 가능한 시작점을 팀에 제공합니다. 이는 다양한 AI 숙련도와 여러 제품 영역에 걸쳐 Make를 확장하는 대규모 팀에 특히 유용합니다. 예를 들어, 동료 디자이너 옹호자 Laura Fehre의 오픈 소스 SAP 템플릿에는 모든 제품이 공유하는 고정된 UI 요소(헤더, 네비게이션)와 함께, 프롬프트가 이를 쉽게 변경할 수 없도록 하기 위한 엄격한 가이드라인이 포함되어 있습니다. 또한, 템플릿 사용자가 필요할 때 특정 테마와 레이아웃을 빠르게 만들 수 있는 "레시피"도 포함되어 있습니다. 이 레시피들은 사전 제작된 코드 기반 프롬프트 형태로 템플릿 UI에 직접 포함되어 있어 클릭하여 복사한 후 Make에 붙여넣을 수 있습니다.

이런 종류의 설정은 두 가지 효과를 동시에 제공합니다. 템플릿을 즉시 활용할 수 있게 만들고 사용자들에게 템플릿을 올바르게 사용하는 방법도 알려줍니다. 그 결과 재작업이 줄어들고, 막다른 길에 가로막히는 일이 줄어들며, 팀이 실제로 구축하려는 프로토타입에 더 안정적으로 도달할 수 있습니다.

6. 작업에 적합한 모델을 선택하세요

모든 Make 업무 흐름에 완벽하게 들어맞는 한 가지 AI 모델은 없습니다. 올바른 선택은 작업이 얼마나 복잡한지, 얼마나 많은 추론이 필요한지, 얼마나 많은 시각적 컨텍스트를 첨부하는지, 그리고 결과물이 얼마나 정교해야 하는지에 따라 달라집니다.

좋은 원칙 중 하나는 해당 작업을 잘 처리할 수 있는 가장 가벼운 모델을 선택하는 것입니다.

작은 변경 사항이나 일상적인 반복 작업이라면 Gemini Flash 같은 가벼운 모델이 더 적합한 경우가 많습니다. 작업이 더 모호하거나 까다로운 디버깅이 포함되어 있거나 강력한 추론이 요구되거나 시각적 완성도를 높게 유지해야 하는 경우에는 비용은 더 들더라도 Claude Opus 같은 강력한 모델이 더 빠르게 더 나은 결과를 얻을 수 있습니다. 이러한 경우에는 초기 투자 비용을 더 들이는 것이 품질이 낮은 첫 결과물을 여러 차례에 걸쳐 수정하는 것보다 더 효율적일 수 있습니다.

특히 새로운 Make 파일을 시작하거나 프롬프트에 풍부한 시각적 컨텍스트를 첨부할 때 더욱 그렇습니다. 디자인 모형 첨부는 Make가 기존 방향성에 맞추고자 할 때 매우 유용합니다. 하지만 디자인 파일이 복잡할수록 Make이 해석해야 할 양도 많아집니다. 처음부터 한꺼번에 많은 컨텍스트를 제공해야 한다면, 그 복잡성을 처리할 수 있는 모델을 사용하거나 현재 단계에 필요한 것만 남기고 컨텍스트를 줄여야 합니다.

오래 진행된 Make 프로젝트는 시간이 지날수록 무거워질 수 있다는 점을 알아둘 필요가 있습니다. 채팅 기록이 쌓일수록 Make는 매번 더 많은 컨텍스트를 고려해야 하며, 이는 비용 증가로 이어질 수 있습니다. 특히 더 비싼 모델을 사용하는 경우에는 더욱 그렇습니다. 그런 일이 발생하는 경우, 채팅 컨텍스트를 지우면 프로젝트를 포기하거나 모든 내용을 새 파일로 옮기지 않고도 Make가 더 깔끔하게 다시 작업할 수 있습니다.

7. 자동화할 가치가 있는 것을 결정하세요

마지막으로, Make를 통해 가장 큰 효과를 거두고 있는 팀들은 단순히 개개인이 더 잘 사용하는 방법만 가르치는 것이 아닙니다. 그들은 Make가 업무 흐름의 어느 부분에 적합하고, 어느 부분에는 적합하지 않은지를 함께 결정합니다.

이는 모호함과 반복 작업이 가치가 있는 0→1 단계의 탐색보다는, 기존 디자인을 구현하는 데 Make를 사용하는 것을 의미할 수 있습니다. 또는 팀이 이미 신속하고 자신 있게 업무를 수행하고 있는 분야에서 수작업 기술을 대체하는 것이 아니라, 프로토타입 제작을 가속화하는 데 사용한다는 뜻일 수도 있습니다. 템플릿, 가이드라인, 키트에 투자하는 것을 의미할 수도 있는데, 이는 시간이 지날수록 그 보상이 누적되기 때문입니다.

모든 작업이 자동화로 동일하게 이점을 얻는 것은 아닙니다. 가장 강력한 팀들은 Make가 어디서 레버리지를 일으키는지, 어디서 인간의 정밀함이 여전히 가장 중요한지, 그리고 초기에 약간의 설정 작업을 해두면 나중에 많은 수고를 덜 수 있는 곳은 어디인지를 정확히 알고 있습니다.

목표는 모든 것을 자동화하는 것이 아니라, 무엇을 어떤 방식으로 자동화할지에 대한 더 나은 결정을 내리는 것입니다. 더 나은 템플릿, 더 명확한 가이드라인, 더 깔끔한 프롬프트, 또는 팀이 공유하는 플레이북 같이 처음에 조금 더 많은 주의를 기울여야 하는 투자가 때로는 가장 효율적인 투자가 되기도 합니다. 그 보상으로 이후의 모든 프로젝트는 더 탄탄한 기반에서 시작하게 됩니다.

Figma Make 크레딧에 대한 프롬프트 최적화 관련 자세한 안내는 도움말 센터를 방문하세요. Make에서 더 효과적으로 작업할 수 있는 다른 접근 방식을 발견했다면, 꼭 알려주시기 바랍니다. 온라인이나 Figma 포럼에 여러분이 만들고 계시는 작업을 공유해 주세요.