13장. Figma Make의 작동 원리 — prompt-to-code, 디자인 시스템과의 연동
13장. Figma Make의 작동 원리 — prompt-to-code, 디자인 시스템과의 연동
Figma Make를 처음 보면 묘한 착각이 듭니다. '이제는 말만 하면 앱이 나오네?' 맞는 말이지만, 끝까지 맞는 말은 아닙니다. Figma Make는 무에서 유를 만드는 마술 상자가 아니라, 프롬프트와 디자인 구조, 컴포넌트, 토큰, 프로젝트 자료를 한데 엮어 작동하는 초안을 빠르게 만드는 엔진에 가깝습니다. 그래서 원리를 이해한 사람은 Make를 과대평가하지도, 과소평가하지도 않습니다. 대신 어디에 써야 가장 강한지 정확히 압니다.
Make는 스크린 생성기가 아니라 작동하는 초안 엔진이다
Figma Make는 아이디어나 기존 Figma 디자인을 바탕으로 작동 가능한 프로토타입, 웹 앱, 대화형 UI를 만드는 프롬프트 기반 도구입니다. 중요한 점은 결과가 단순한 정적 화면이 아니라는 것입니다. 클릭해 보고, 흐름을 확인하고, 경우에 따라 코드를 들여다보며 계속 고칠 수 있는 상태로 나온다는 데 의미가 있습니다.12
이 차이는 꽤 큽니다. 예전의 디자인 초안이 '어떻게 보일까'를 확인하는 데 강했다면, Make의 초안은 '어떻게 움직일까'까지 보여줍니다. 그래서 팀은 더 빨리 질문할 수 있습니다. 이 버튼을 누르면 정말 다음 단계로 넘어가는가, 이 카드가 접히고 펼쳐질 때 정보 위계가 유지되는가, 이 온보딩 플로우가 실제로 매끄러운가 같은 질문 말입니다.
정리하면, Make의 핵심 산출물은 완제품이 아니라 검증 가능한 작동 모델입니다. 이 한 문장을 기억하면 기대치가 훨씬 건강해집니다.
Make는 네 가지 맥락을 먹고 결과를 만든다
Make가 똑똑해 보일 때는 대개 모델이 좋아서가 아니라 맥락이 좋아서입니다. 실제로 Make의 품질은 다음 네 가지 입력이 얼마나 선명한지에 크게 좌우됩니다.
프롬프트 맥락: 무엇을 만들지, 누구를 위한 것인지, 어떤 플랫폼인지, 어떤 행동이 일어나야 하는지, 무엇을 지켜야 하는지를 말해 주는 텍스트입니다. 첫 프롬프트에 목적, 구조, 핵심 요소, 기대 동작, 제약을 충분히 담을수록 결과가 빨라지고 안정됩니다.3
디자인 맥락: 기존 Figma 프레임, 컴포넌트, 이미지 같은 시각적 기준입니다. 사용자는 디자인을 첨부하거나 붙여 넣어서 Make가 이미 존재하는 구조와 스타일을 참고하게 할 수 있습니다.2
시스템 맥락: 팀의 디자인 시스템, 토큰, 가이드라인, 코드 패키지입니다. 최근의 Make kits는 단순히 부품 목록을 주는 것이 아니라 '이 부품을 언제, 어떻게 써야 하는가'까지 함께 전달합니다.45
프로젝트 맥락: PDF 명세서, CSV·JSON 데이터, 스크린샷, 브랜드 가이드, 법무 문구 같은 현실 자료입니다. 이 자료가 들어가면 결과물은 멋진 가짜가 아니라 실제 제약을 반영한 초안에 가까워집니다.4
이 네 가지를 보면 Figma Make의 본질이 보입니다. Make는 '생성' 도구이기 이전에 '맥락 결합' 도구입니다. 프롬프트만으로 모든 것을 해결하려 하면 자주 흔들리고, 반대로 맥락을 잘 붙여 주면 놀랄 만큼 현실적인 결과를 냅니다.
디자인 시스템과 연결될 때 Make는 비로소 팀의 도구가 된다
개인 실험에서는 예쁜 v1만 나와도 만족할 수 있습니다. 하지만 팀 작업에서는 다릅니다. 버튼이 우리 버튼이어야 하고, 입력창이 우리 상태 체계를 따라야 하며, 간격과 반경도 우리 규칙에 맞아야 합니다. 바로 이 지점에서 디자인 시스템 연동이 중요해집니다.
Make kits는 Figma Make에 팀의 디자인 시스템 문맥을 가르치는 장치입니다. 공용 또는 비공개 npm 패키지로 배포된 React 기반 디자인 시스템을 연결할 수 있고, 여기에 가이드라인 파일을 붙여서 컴포넌트 사용 원칙까지 함께 전달할 수 있습니다. Figma는 이 가이드라인을 자동 생성하도록 돕기도 하지만, 실제 팀에서는 꼭 검토가 필요합니다. 부품 이름만 알아서는 충분하지 않고, 어떤 상황에 어떤 컴포넌트를 우선 사용해야 하는지까지 알아야 좋은 결과가 나오기 때문입니다.5
여기서 중요한 포인트는 두 가지입니다. 첫째, Make는 디자인 시스템을 '장식'으로 쓰는 것이 아니라 생성의 출발점으로 삼을 때 가장 강해집니다. 둘째, 디자인 시스템이 엉성하면 AI도 엉성하게 배웁니다. 토큰 구조가 뒤섞여 있고, 컴포넌트가 일관되지 않으며, 이름이 불분명하면 Make는 결국 그 혼란까지 함께 증폭합니다.
한 단계 더 나아가면 Code Connect 같은 연결도 의미가 커집니다. Code Connect는 Figma 컴포넌트와 실제 코드 컴포넌트를 이어 주는 다리인데, 이런 연결 정보는 MCP 기반 코드 생성 맥락을 더 정확하게 만들어 줍니다. 즉, AI가 비슷하게 생긴 새 버튼을 발명하는 대신, 이미 팀이 쓰고 있는 버튼을 재사용할 가능성이 커집니다.6
prompt-to-code는 픽셀 복사가 아니라 구조 해석에 가깝다
많은 사람이 prompt-to-code를 '화면을 보고 비슷하게 코딩해 주는 기능'으로 이해합니다. 하지만 그렇게만 보면 왜 어떤 결과는 그럴듯하고, 어떤 결과는 금방 무너지는지 설명이 안 됩니다.
좋은 prompt-to-code는 스크린샷을 흉내 내는 데서 끝나지 않습니다. 디자인 안에 들어 있는 구조를 읽어야 합니다. 예를 들어 카드가 부모 안에서 가운데 정렬된 것인지, 단순히 x값이 우연히 그렇게 놓인 것인지는 결과 코드에 큰 차이를 만듭니다. 색상도 마찬가지입니다. 단순한 hex 값으로 보느냐, 의미 있는 토큰 참조로 보느냐에 따라 재사용성과 유지보수성이 완전히 달라집니다. Figma의 디자인-코드 연결 흐름은 바로 이 지점에서 노이즈를 줄이고, 레이아웃 관계와 토큰 참조, 컴포넌트 맵핑 같은 구조화된 문맥으로 바꾸는 방향으로 발전해 왔습니다.7
그래서 Make가 잘 작동하려면 디자인 파일도 구조적이어야 합니다. 자동 레이아웃은 단지 정렬을 편하게 해 주는 기능이 아니라, AI에게 '이 요소들은 이런 관계다'라고 설명하는 문법입니다. 변수는 색과 간격을 바꾸는 스위치일 뿐 아니라, AI가 '무엇이 브랜드의 규칙인가'를 이해하게 만드는 표식입니다. 결국 Make의 결과 품질은 모델의 상상력보다 파일의 문법에 더 많이 좌우됩니다.
코드와 데이터는 결과를 현실로 끌어내리는 무게추다
Make가 재미있는 이유는 그럴듯한 화면을 빨리 만드는 데 있지만, 실무에서 진짜 가치가 생기는 순간은 코드와 데이터가 붙을 때입니다. 예를 들어 온보딩을 만든다고 해 봅시다. 프롬프트만으로 만들면 아주 매끈한 이상형이 나올 수 있습니다. 그런데 실제 약관 문구 PDF, 국가별 입력 규칙이 담긴 명세, 가입 샘플 데이터 CSV를 붙이면 이야기가 달라집니다. 갑자기 줄바꿈이 무너지고, 버튼 길이가 바뀌고, 예외 상태가 늘어나며, 진짜 문제들이 화면 위로 올라옵니다.4
이건 나쁜 일이 아닙니다. 오히려 빨리 발견할수록 좋은 일입니다. 예쁜 거짓말보다 투박한 사실이 낫기 때문입니다.
또한 Make는 결과물을 미리보기만 하는 공간이 아니라, 대화하면서 다시 고치고, 특정 요소를 가리켜 수정하고, 필요하면 코드까지 함께 손볼 수 있는 작업 공간입니다. 즉, 프롬프트 한 번으로 끝나는 도구가 아니라 생성과 편집이 오가는 왕복형 도구라고 보는 편이 맞습니다.2
좋은 결과는 좋은 프롬프트보다 좋은 준비에서 나온다
물론 프롬프트는 중요합니다. 하지만 실무에서는 '프롬프트를 잘 쓰는 법'보다 'Make가 잘 읽을 수 있게 준비하는 법'이 더 중요할 때가 많습니다. 특히 다음 네 가지는 결과 차이를 크게 만듭니다.
첫 프롬프트를 아끼지 않기: 목적, 사용자, 화면 구조, 핵심 동작, 제약을 처음부터 자세히 적을수록 뒤에서 수선할 비용이 줄어듭니다.3
복잡한 작업을 한 번에 시키지 않기: 큰 서비스를 한 번에 만들려 하지 말고 구조, 콘텐츠, 인터랙션 순서로 쪼개면 흔들림이 줄어듭니다.3
디자인 파일을 정리하고 가져가기: 자동 레이아웃, 의미 있는 레이어 이름, 정리된 컴포넌트 구조는 단순한 미관 문제가 아니라 해석 가능성의 문제입니다.37
매직 넘버를 줄이기: 임의의 수치와 직접 입력한 색상은 사람도 해석하기 어렵고 AI는 더 어렵습니다. 변수와 토큰으로 의미를 부여해야 합니다.7
이쯤 되면 한 가지가 분명해집니다. 좋은 Make 사용자는 프롬프트를 길게 쓰는 사람이 아니라, 맥락을 설계하는 사람입니다.
어디까지 믿고, 어디서부터 의심해야 할까
Figma Make는 초반 탐색, 흐름 검증, 인터랙션 설명, 이해관계자 설득에 아주 강합니다. 특히 빈 캔버스 앞에서 멈추는 시간을 크게 줄여 줍니다. 반면, 깊은 비즈니스 로직, 복잡한 예외 처리, 접근성 검수, 시맨틱 품질, 보안 검토까지 알아서 끝내 주는 도구는 아닙니다.8
쉽게 말해 Make는 빠른 동료이지, 최종 책임자는 아닙니다. 초안을 밀어 주고, 구조를 제안하고, 인터랙션을 살아 움직이게 만들 수는 있습니다. 하지만 어떤 상태가 정말 필요한지, 법적 문구를 축약하면 안 되는지, 스크린리더에서 의미가 유지되는지, 실제 서비스의 실패 상태가 충분히 반영되었는지는 결국 사람이 판단해야 합니다.8
그래서 Make를 잘 쓰는 팀은 결과물을 보고 감탄하는 팀이 아니라, 결과물을 보고 바로 질문하는 팀입니다. '멋지다' 다음에 '그런데 실제 가입 실패 상태는 어디 있지?'가 나와야 합니다.
실무에서는 이렇게 돌리면 안정적이다
실제로는 다음과 같은 루프로 접근하면 가장 덜 흔들립니다.
먼저 작은 화면이나 한 개의 플로우로 시작해 구조를 잡습니다. 그다음 디자인 시스템 맥락을 붙여 우리 팀의 언어로 바꿉니다. 이어서 실제 데이터와 문서를 넣어 현실성을 높입니다. 마지막으로 사람의 기준으로 다시 검토합니다. 접근성, 예외 상태, 카피 정확성, 기술 구현 가능성까지 확인한 뒤에야 다음 단계로 넘깁니다.
이 순서를 거꾸로 하면 자주 망합니다. 처음부터 모든 것을 다 넣으려 하면 생성 결과가 흐려지고, 반대로 시스템과 데이터를 너무 늦게 붙이면 처음 만든 멋진 화면을 거의 다시 만들어야 합니다.
Make를 이해한다는 것은 AI를 덜 신비하게 보는 일이다
Figma Make의 핵심은 '프롬프트로 앱을 만든다'가 아닙니다. 더 정확히 말하면 '프롬프트를 중심으로 컴포넌트, 토큰, 코드, 데이터 맥락을 엮어 작동하는 초안을 만든다'입니다. 이 차이는 작아 보여도 실무에서는 결정적입니다.
이 원리를 이해하면 Make는 더 이상 만능 도구도, 장난감도 아닙니다. 생각보다 훨씬 실용적인 도구가 됩니다. 빈 캔버스를 넘기고, 팀의 디자인 시스템을 타고, 실제 데이터를 미리 받아 보며, 아이디어를 검증 가능한 형태로 바꾸는 도구 말입니다.
다음 장에서는 이 엔진을 더 정확하게 움직이게 만드는 언어, 즉 좋은 프롬프트의 네 가지 요소를 본격적으로 살펴보겠습니다.
참고
38 ways to build with Figma Make
4Build with more context and more control in Figma Make
5Use your design system package in Make kits
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.