15장. 디자인을 Make로 가져가기 — Import from Figma, 점진적 정교화

Figma Make를 잘 쓰는 사람은 프롬프트를 화려하게 쓰는 사람이 아니라, 무엇을 가져가고 무엇을 나중에 고칠지 구분하는 사람입니다. 많은 초보자가 여기서 서두릅니다. 이미 만든 디자인 파일이 있으니 그걸 한 번에 넣고, "이걸 완성품으로 만들어줘"라고 말합니다. 그러면 Make는 친절하게 열심히 일하긴 합니다. 다만 결과는 자주 과하게 바뀌거나, 반대로 어색하게 멈춥니다.

실무에서는 오히려 반대로 가는 편이 빠릅니다. 기존 디자인을 맥락으로 붙이고, 먼저 작동하는 뼈대를 만들고, 그다음 한 겹씩 정교화하는 방식입니다. Figma Make는 기존 Figma 디자인을 가져와 기능형 프로토타입이나 웹 앱으로 발전시키는 데 강하고, 디자인을 하나만 붙이는 것이 아니라 여러 개를 함께 첨부해 맥락을 줄 수도 있습니다. 프레임이나 컴포넌트를 채팅에 직접 붙여 넣는 방법도 지원합니다.¹²

한마디로 요약하면 이 장의 핵심은 이것입니다. 잘 가져오고, 잘 나누고, 잘 다듬어라. 결국 가장 빨리 원하는 결과에 도달하는 사람은 한 번에 완성하려는 사람이 아니라, 단계적으로 정확도를 올리는 사람입니다.

가져오기 전에 먼저 고를 것

Import from Figma 버튼을 누르기 전에 먼저 해야 할 일은 의외로 단순합니다. 무엇을 가져갈지 고르는 일입니다.

Make에 붙이는 디자인은 많을수록 좋은 것이 아닙니다. 맥락이 풍부해지는 대신, 판단 범위도 넓어집니다. 그래서 처음에는 제품 전체를 통째로 넘기기보다, 이번에 검증하고 싶은 흐름을 대표하는 프레임을 골라야 합니다. 예를 들어 회원가입 흐름을 검증하고 싶다면 홈, 입력, 오류, 완료 화면이 더 중요하지, 설정 화면 전체가 꼭 필요하진 않습니다.

또 한 가지 중요한 점이 있습니다. Make가 참고할 디자인은 흩어진 레이어 묶음보다 프레임이나 컴포넌트 형태가 훨씬 낫다는 점입니다. 실제로 Figma 커뮤니티 안내에서도 첨부하려는 디자인은 컴포넌트이거나 최소한 프레임 안에 들어 있어야 기대한 대로 동작하는 경우가 많다고 설명합니다.³

처음 가져갈 단위는 보통 세 가지면 충분합니다.

• 기준이 되는 핵심 화면 1~3개

• 비어 있음, 오류, 완료 같은 대표 상태 화면

• 반드시 지켜야 하는 컴포넌트 예시

이 조합이 좋은 이유는 Make에게 "무슨 제품인지", "어떻게 생겨야 하는지", "어디까지가 예외 상태인지"를 한 번에 알려 주기 때문입니다. 예쁜 기본 화면 하나만 주면 Make는 성공 상태만 이해합니다. 반대로 오류 상태까지 함께 주면, 갑자기 이 도구가 현실 감각을 갖기 시작합니다.

Import from Figma는 버튼이 아니라 맥락 전달 방식이다

실제로 가져오는 방법은 생각보다 유연합니다. Make에서는 + 메뉴를 통해 Import from Figma로 기존 디자인을 붙일 수 있고, 필요하면 여러 디자인을 함께 첨부할 수 있습니다. 또한 Figma Design에서 프레임이나 컴포넌트를 복사해서 채팅창에 직접 붙여 넣는 방법도 가능합니다.¹

여기서 중요한 건 "어느 경로가 더 고급 기능인가"가 아니라, 이번 작업에 어떤 방식이 더 정확한가입니다.

세 가지 방식은 대체로 이렇게 쓰면 됩니다.

• Import from Figma: 특정 파일 안의 디자인을 참조 자료로 붙일 때 좋습니다.

• 복사해서 채팅에 붙여 넣기: 정확히 원하는 프레임이나 컴포넌트를 직접 지정하고 싶을 때 편합니다.

• 이미지 첨부: 아직 Figma 파일이 없거나 스케치, 레퍼런스 사진만 있을 때 보조적으로 씁니다.

특히 기존 Figma 프레임을 복사해 Make에 가져가는 흐름은 단순 스크린샷 전달보다 낫습니다. Figma는 이 방식이 디자인의 구조와 메타데이터를 함께 보존하며, 그 결과 원래 디자인 의도를 살린 채 인터랙티브한 결과로 발전시키기 좋다고 설명합니다.²

쉽게 말해, 화면을 "보여주는 것"과 화면을 "이해시키는 것"은 다릅니다. Make에서 더 안정적인 결과가 나오는 쪽은 대개 후자입니다.

첫 번째 목표는 완성이 아니라 작동하는 뼈대다

기존 디자인을 Make에 붙이면 누구나 욕심이 납니다. "이제 반응형도 하고, 다크 모드도 하고, 로그인도 붙이고, 백엔드도 연결하고, 카피도 다 손봐 줘."

이 마음은 이해되지만, 첫 시도에서 가장 위험한 접근입니다.

처음 프롬프트의 목표는 완성품이 아니라 작동하는 뼈대여야 합니다. 즉, 화면 간 이동이 맞는지, 주요 입력이 실제 흐름으로 이어지는지, 상태 전환이 자연스러운지부터 확인해야 합니다. 보기 좋게 말하면 프로토타이핑이고, 솔직하게 말하면 "큰 사고가 나기 전에 뼈대를 먼저 점검하는 단계"입니다.

예를 들어 이런 식이 더 좋습니다.

첨부한 세 개의 모바일 프레임을 기준으로 예약 플로우의 기능형 프로토타입을 만들어줘. 먼저 날짜 선택, 시간 선택, 예약 확인의 3단계 흐름만 구현하고, 시각 스타일은 첨부한 컴포넌트 구조를 최대한 유지해줘. 새로운 화면은 추가하지 말고, 입력과 버튼 동작만 먼저 연결해줘.

이 프롬프트의 좋은 점은 욕심이 적다는 데 있습니다. 그런데 바로 그 점 때문에 결과는 오히려 더 좋아집니다.

큰 목표를 작은 단위로 쪼개는 방식은 Figma Make 활용 팁에서도 반복해서 권장되는 방법입니다. 복잡한 요청을 한 번에 해결하려 하기보다, 관리 가능한 단계로 나누는 편이 결과 안정성이 높습니다.⁵ 실제 사례에서도 꽤 복잡한 흐름을 실전에 가까운 수준으로 다듬는 데 수십 번의 반복이 필요했습니다. 한 사례에서는 최종 버전에 도달하기까지 64번의 이터레이션이 있었다고 소개합니다.⁶

듣고 나면 약간 허탈할 수도 있습니다. "64번이나?" 하고 말입니다. 하지만 오히려 안심해도 됩니다. 이상한 게 아닙니다. Make를 잘 쓰는 실무자는 대부분 한 번에 끝내지 않습니다.

점진적 정교화는 이런 순서가 잘 먹힌다

가져온 디자인을 다듬을 때는 순서가 중요합니다. 순서를 잘못 잡으면 뒤에서 고친 것이 앞의 문제를 다시 흔듭니다. 반대로 순서를 잘 잡으면 수정량은 비슷해도 결과 품질이 훨씬 빨리 올라갑니다.

1. 흐름부터 맞춘다

먼저 봐야 할 것은 픽셀이 아니라 흐름입니다. 버튼이 어디로 가는지, 탭이 실제로 전환되는지, 입력값이 다음 화면에 반영되는지 같은 기본 동작을 확인합니다.

이 단계에서는 스타일 불만을 잠시 참아야 합니다. 카드 그림자가 마음에 안 드는 것보다, 완료 버튼이 잘못된 단계로 가는 것이 훨씬 큰 문제이기 때문입니다.

2. 상태를 추가한다

기본 흐름이 맞으면 그다음은 상태입니다. 비어 있음, 로딩, 오류, 성공, 선택 전/후 같은 상태를 하나씩 붙입니다.

이 단계가 중요한 이유는 서비스의 진짜 성격이 여기서 드러나기 때문입니다. 성공 화면만 있는 앱은 대체로 데모에는 좋지만, 검증에는 약합니다. Make가 갑자기 덜 그럴듯해 보이기 시작하는 순간이 오히려 실무적으로는 가장 가치 있는 순간입니다.

3. 시스템 언어로 다시 묶는다

이제야 비로소 "우리 제품답게" 만들 차례입니다. Figma는 Make에서 라이브러리와 스타일 문맥을 붙여 결과물을 디자인 시스템에 맞게 유지할 수 있다고 설명합니다. 즉, 처음부터 완벽하게 시스템에 맞추려 애쓰기보다, 흐름과 상태가 어느 정도 선 뒤에 시스템 언어를 다시 강하게 입히는 편이 훨씬 수월합니다.⁴

이 단계에서 좋은 수정 프롬프트는 대개 이렇게 생깁니다.

레이아웃 구조는 유지하고, 첨부한 디자인 시스템의 버튼·입력·카드 패턴을 우선 사용해줘. 색상과 간격은 라이브러리 기준에 맞추고, 새 컴포넌트는 가능하면 발명하지 마.

이 문장은 짧지만 강합니다. 바꿀 것과 지킬 것이 함께 들어 있기 때문입니다.

4. 현실 데이터를 넣는다

다음은 진짜 시험입니다. 실제 문구, 긴 이름, 비어 있는 데이터, 예상보다 긴 오류 메시지, 길이가 들쭉날쭉한 목록을 넣어 봅니다.

이 과정을 거치면 종종 멀쩡해 보이던 화면이 갑자기 무너집니다. 좋은 일입니다. 실제 출시 전에 망가지는 법을 미리 본 것이니까요.

5. 미세 조정은 넓게 말하지 말고 좁게 말한다

마지막 단계에서는 넓은 지시보다 좁은 지시가 잘 먹힙니다. Make는 특정 미리보기 영역을 가리켜 수정하는 편집 방식도 지원하므로, 이 시점부터는 "전체를 더 세련되게"보다 "상단 카드의 패딩을 줄이고 제목 위계를 올려 달라"가 훨씬 효과적입니다.¹

결국 정교화란 거창한 재창조가 아니라, 수정 범위를 줄이면서 정확도를 높이는 과정입니다.

Make와 Design은 일방통행이 아니라 왕복 통로다

많은 사람이 Design에서 Make로 가는 흐름만 생각합니다. 하지만 실무에서는 다시 돌아오는 길도 똑같이 중요합니다.

Figma Make에서는 미리보기 스냅샷을 디자인 레이어로 복사해 Figma Design에 붙여 넣을 수 있고, 이후에는 Make 미리보기를 Design으로 editable layers 형태로 가져오는 흐름도 가능해졌습니다.¹⁸

이 왕복이 중요한 이유는 분명합니다. Make는 작동과 탐색에 강하고, Design은 정밀 편집과 팀 협업에 강합니다. 그래서 실제로는 이런 루프가 자주 가장 안정적입니다.

• Design에서 기준 프레임과 시스템을 정리한다.

• Make에서 기능형 흐름과 인터랙션을 빠르게 검증한다.

• 다시 Design으로 가져와 세밀한 시각 조정과 팀 리뷰를 진행한다.

이 방식은 특히 스테이크홀더 리뷰에서 강합니다. 먼저 Make로 "움직이는 초안"을 보여 주고, 의견이 모이면 Design에서 "관리 가능한 자산"으로 정리할 수 있기 때문입니다.

언제 Make에 남고, 언제 Design으로 돌아가야 할까

여기서 판단을 잘해야 시간을 아낍니다.

다음 같은 경우에는 Make에 조금 더 남아 있는 편이 좋습니다.

• 인터랙션과 조건 분기를 더 시험해 보고 싶을 때

• 입력, 상태 변화, 데이터 흐름을 확인하고 싶을 때

• 여러 방향의 기능형 초안을 빠르게 비교하고 싶을 때

반대로 다음 같은 경우에는 Design으로 돌아가는 편이 좋습니다.

• 컴포넌트 자체 구조를 정교하게 손봐야 할 때

• 라이브러리, 변수, 토큰 수준의 정리가 필요할 때

• 여러 파일에서 재사용될 공용 자산으로 만들어야 할 때

이 구분이 중요한 이유는 Figma Make 파일끼리는 아직 디자인 시스템처럼 촘촘한 재사용 구조를 갖기 어렵기 때문입니다. 커뮤니티 안내에 따르면 Make 파일 간 컴포넌트 연결이나 자동 업데이트 재사용은 제한적이고, 실질적으로는 수동 복사·붙여 넣기가 중심입니다. 공용 재사용성은 여전히 Figma Design의 라이브러리 쪽이 더 강합니다.⁷

쉽게 말해, 제품의 실험장은 Make, 제품의 창고는 Design이라고 생각하면 덜 헷갈립니다.

흔한 실패는 대부분 가져가는 방식에서 시작된다

Make 결과가 이상할 때 사람들은 대개 프롬프트를 탓합니다. 하지만 실제로는 가져가는 방식에서 이미 절반쯤 승부가 납니다.

대표적인 실패 패턴은 이렇습니다.

• 너무 많은 화면을 한꺼번에 넣는다.

• 대표 상태 없이 예쁜 기본 화면만 가져간다.

• 시스템 기준 없이 결과만 보고 나중에 맞추려 한다.

• 첫 요청부터 반응형, 다크 모드, 백엔드, 정교한 카피를 한 번에 요구한다.

• 수정할 때 범위를 좁히지 않고 전체를 다시 흔든다.

이런 경우 Make는 나쁜 결과를 냈다기보다, 너무 넓은 시험지를 받아든 셈입니다.

반대로 잘 되는 사람들은 대체로 이렇게 움직입니다. 먼저 한 흐름만 붙입니다. 그다음 상태를 붙입니다. 그다음 시스템 정렬을 합니다. 마지막에 디테일을 조입니다. 겉보기엔 느려 보여도, 총 작업 시간은 오히려 짧아집니다.

게다가 이 방식은 비용 감각에도 유리합니다. Figma 안내에 따르면 AI 크레딧 사용량은 고정되어 있지 않고, 모델 종류, 작업 복잡도, 넣은 맥락의 양에 따라 달라질 수 있습니다. 즉, 크고 복잡한 요청일수록 더 비싸고 예측하기 어려울 수 있습니다.⁹

그러니 점진적 정교화는 품질 전략이면서 동시에 비용 전략이기도 합니다.

실무에서 바로 쓰는 가져오기 루틴

처음부터 안정적으로 가고 싶다면, 다음 루틴을 추천합니다.

먼저 Figma Design에서 이번에 검증할 핵심 프레임 2~4개를 따로 정리합니다. 가능하면 기본 상태와 예외 상태를 함께 묶습니다. 그다음 Make에서 Import from Figma 또는 직접 붙여 넣기로 이 프레임들을 첨부합니다. 첫 프롬프트에서는 화면을 새로 발명하게 하지 말고, 기존 구조를 기준으로 기능형 흐름만 연결하게 합니다. 결과가 나오면 레이아웃 미세 조정보다 먼저 흐름과 상태를 점검합니다. 이후 라이브러리 기준과 스타일 문맥을 다시 강조해 시스템 정렬을 합니다. 마지막으로 현실 데이터와 실제 문구를 넣고, 좁은 범위의 수정 프롬프트로 정밀하게 다듬습니다.

이 루틴의 장점은 분명합니다. 어디서 어긋났는지 추적하기 쉽습니다. 처음부터 모든 것을 한꺼번에 바꾸면, 무엇 때문에 결과가 좋아졌는지 나빠졌는지 알기 어렵습니다. 하지만 단계별로 가면 문제의 원인이 훨씬 또렷해집니다.

잘 가져오는 사람은 결국 빨리 만든다

Figma Make는 빈 화면에서 기적을 만드는 도구라기보다, 이미 있는 디자인 의도를 작동하는 형태로 밀어 올리는 도구에 가깝습니다. 그래서 출발점이 중요합니다. 무엇을 붙였는지, 어떤 범위로 시작했는지, 어디까지를 첫 목표로 삼았는지에 따라 결과가 크게 달라집니다.

잘 가져온 디자인은 Make 안에서 빠르게 살아 움직입니다. 잘 쪼갠 요청은 수정 루프를 짧게 만듭니다. 잘 정리된 시스템 문맥은 결과를 우리 제품답게 붙잡아 둡니다. 그리고 잘 돌아온 결과는 다시 Design에서 팀의 자산이 됩니다.

결국 속도를 만드는 건 조급함이 아닙니다. 작업의 순서를 설계하는 능력입니다.

참고

¹Explore Figma Make – Figma Learn

²Introducing Figma Make: A new way to test, edit, and prompt designs

³How to Import My Figma Design into Figma Make?

⁴Figma Make: Create with AI-Powered Design Tools

⁵5 ways to improve your Figma Make prompts

⁶Create Functional Prototypes with Figma Make

⁷How can I import a Figma Make file into another Figma Make file?

⁸Transfer from Make to Design

⁹Design / Prototype vs Iteration