책에 포함된 노트AI 시대의 피그마: 프롬프트로 디자인하고, 디자인으로 출시하는 법

1장. 피그마의 5가지 얼굴 — Design, FigJam, Slides, Buzz, Make, 무엇을 언제 쓰는가

2026-04-26Views 237약 11분생성형 AI 활용

1장. 피그마의 5가지 얼굴 — Design, FigJam, Slides, Buzz, Make, 무엇을 언제 쓰는가

피그마를 처음 배우는 사람은 대개 이렇게 생각한다. "아, 화면 그리는 툴이구나."

그 말은 맞지만, 2026년의 피그마를 설명하기엔 조금 부족하다. 지금의 피그마는 하나의 앱이라기보다, 서로 연결된 여러 작업 공간의 묶음에 가깝다. 실제로 피그마는 디자인 파일만 다루는 도구를 넘어, 화이트보드, 프레젠테이션, 브랜드 자산 제작, 프롬프트 기반 프로토타이핑까지 한 생태계 안에서 제공하고 있다.¹²

이 차이를 빨리 이해할수록 시행착오가 줄어든다. 문제는 "피그마로 할 수 있나?"가 아니라, "이 일을 피그마의 어디에서 시작해야 가장 덜 돌아가나?"이기 때문이다.

이 장에서는 피그마의 다섯 얼굴, 곧 Design, FigJam, Slides, Buzz, Make를 각각 어떤 순간에 꺼내야 하는지 살펴본다. 기능 목록을 외우는 대신, 업무 장면을 떠올리며 읽어보자. 그러면 머릿속에서 제품 구분이 훨씬 또렷해진다.

1부. 기본기 / 1장. 피그마의 5가지 얼굴 — Design, FigJam, Slides, Buzz, Make, 무엇을 언제 쓰는가

먼저 큰 그림부터: 피그마는 하나가 아니라 작업대 세트다

목공소를 떠올려보자. 톱 하나로 모든 걸 해결할 수는 없다. 나무를 자를 때 쓰는 도구와, 표면을 다듬을 때 쓰는 도구, 조립할 때 쓰는 도구는 다르다. 피그마도 비슷하다.

Design는 화면과 컴포넌트를 만드는 정밀 작업대다. FigJam은 생각을 풀어놓고 정리하는 넓은 탁자다. Slides는 이야기를 구조화해 발표하는 무대다. Buzz는 브랜드 자산을 빠르게 대량 생산하는 제작 라인이다. Make는 "이런 걸 만들고 싶어"라는 의도를 기능하는 결과물로 밀어 올리는 실험실에 가깝다.¹³⁴

다섯 제품은 서로 분리되어 있으면서도 연결된다. FigJam에서 회의를 하고, 그 결과를 Slides로 발표 자료로 바꾸고, Design에서 제품 화면을 다듬고, Make에서 동작하는 프로토타입이나 웹 앱으로 실험하고, Buzz에서 마케팅 자산을 정리하는 식이다. 중요한 건 순서를 외우는 것이 아니라, 각 제품이 잘하는 질문을 아는 것이다.

Design가 잘하는 질문은 "어떻게 정확하게 설계할까?"다. FigJam은 "무엇을 만들지 함께 정리할까?"를 묻는다. Slides는 "이걸 어떻게 설득력 있게 보여줄까?"를 다룬다. Buzz는 "이 브랜드를 여러 채널에 맞게 빠르게 늘릴까?"에 가깝고, Make는 "이 아이디어를 얼마나 빨리 작동하게 만들 수 있을까?"를 묻는다.

Design: 제품 디자이너의 본진

대부분의 독자가 가장 오래 머물게 될 곳은 역시 Design다. 우리가 흔히 "피그마 한다"라고 말할 때, 실제로는 Design에서 프레임을 만들고, 자동 레이아웃을 잡고, 컴포넌트를 만들고, 프로토타입을 연결하는 경우가 많다. 피그마가 업계 표준으로 자리 잡은 이유도 바로 이 공간의 밀도에 있다.⁵

Design를 써야 하는 순간은 비교적 명확하다. 앱 화면, 웹 인터페이스, 대시보드, 설정 페이지, 컴포넌트 라이브러리, 디자인 시스템, 반응형 레이아웃처럼 "정확한 구조와 재사용"이 필요한 작업이라면 거의 여기서 시작한다.

초보자는 Design를 그림판처럼 쓰기 쉽다. 사각형을 놓고, 텍스트를 쓰고, 보기 좋게 정렬하는 식이다. 물론 그렇게도 시작할 수 있다. 다만 Design의 진짜 힘은 예쁘게 그리는 데 있지 않고, 구조를 설계하는 데 있다. 프레임은 화면 단위가 되고, 자동 레이아웃은 요소 간 관계를 만들고, 컴포넌트는 반복을 줄이며, 변수는 규칙을 부여한다. 이 네 가지가 묶이는 순간, 파일은 단순한 시안이 아니라 제품 설계도로 바뀐다.

예를 들어 로그인 화면을 만든다고 해보자. 제목, 입력 필드, 버튼을 보기 좋게 놓는 것만으로는 충분하지 않다. 버튼의 높이는 바뀌는가, 에러 메시지가 추가되면 아래 요소는 어떻게 밀리는가, 모바일과 데스크톱에서 간격은 어떻게 달라지는가, 다크 모드에서는 어떤 색 토큰을 읽는가 같은 질문이 이어진다. 이런 질문에 답해야 할 때 Design가 빛난다.

하지만 Design는 아이디어를 처음 꺼내기엔 때때로 너무 정밀하다. 머릿속이 아직 흐릿한데 바로 픽셀을 만지기 시작하면, 문제 정의보다 버튼 둥글기부터 고민하게 된다. 그럴 때는 Design로 뛰어들기 전에 한 걸음 물러설 필요가 있다. 그 한 걸음 뒤가 바로 FigJam이다.

FigJam: 생각을 펼치고 합의를 만드는 곳

FigJam은 피그마의 디지털 화이트보드다. 브레인스토밍, 사용자 여정 정리, 워크숍, 회의 메모, 아이디어 분류처럼 "아직 답이 확정되지 않은 문제"를 다룰 때 특히 강하다.⁶⁷

Design가 정교한 설계라면, FigJam은 거친 대화다. 스티키 노트, 도형, 텍스트, 섹션, 표, 스탬프, 위젯을 이용해 생각을 빠르게 꺼내고 묶을 수 있다. 이 단계에서 중요한 것은 깔끔함보다 속도다. 회의 도중 누군가 아이디어를 말하면, 우선 붙인다. 모순이 있으면 나중에 정리한다. 이 순서가 중요하다.

많은 팀이 실수하는 지점도 여기다. 아직 문제를 정의하지 않았는데 곧바로 화면을 그리기 시작한다. 그러면 화면은 만들어지는데, 정작 왜 그렇게 만들었는지는 흐려진다. 반대로 FigJam에서 먼저 사용자 문제, 핵심 흐름, 필요한 정보, 우선순위를 붙여두면, Design에서 무엇을 줄이고 무엇을 강조할지가 훨씬 쉬워진다.

FigJam이 특히 좋은 장면은 이런 경우다.

킥오프 회의에서 목표와 제약을 한 판에 모을 때
사용자 플로우를 팀과 함께 그릴 때
리서치 결과나 인터뷰 메모를 묶어 패턴을 찾을 때
디자인 리뷰 전에 쟁점을 먼저 정리할 때
워크숍에서 모두가 동시에 참여해야 할 때

여기서 재미있는 연결이 하나 나온다. FigJam은 생각을 모으는 데서 끝나지 않고, 그 보드를 Slides의 개요로 옮기는 흐름도 지원한다. 즉, 회의에서 흩어진 포스트잇이 발표 자료의 뼈대가 될 수 있다.⁸⁹

이 말은 아주 실무적이다. 예전에는 회의하고, 메모를 정리하고, 발표 파일을 새로 만들고, 다시 구조를 잡느라 같은 내용을 세 번 손대는 일이 흔했다. 이제는 FigJam에서 합의한 구조를 Slides로 넘겨 발표 흐름으로 바꾸는 길이 생겼다. 정리의 중복이 줄어드는 셈이다.

Slides: 설명이 아니라 설득을 만드는 공간

Slides는 "디자이너도 발표 툴을 따로 써야 하나?"라는 질문에 대한 피그마의 대답이다. 피그마는 Slides를 디자이너와 팀을 위한 프레젠테이션 도구로 설명하며, 디자인 모드로 전환해 자동 레이아웃, 레이어 패널, 고급 속성, 라이브러리 등을 활용할 수 있게 한다.³¹⁰

이 제품의 핵심은 슬라이드를 예쁘게 만드는 데만 있지 않다. 디자인 자산과 발표 자산이 같은 생태계 안에 있다는 점이 더 중요하다. 제품 화면을 캡처해서 여기저기 붙이는 대신, 실제 피그마 자산과 더 가까운 상태로 발표를 구성할 수 있다. 인터랙티브 프로토타입을 넣고, 팀과 함께 스토리를 다듬고, AI로 문장을 짧게 하거나 발표자 노트를 보완하는 흐름도 지원한다.³¹⁰

Slides를 써야 하는 순간은 대체로 이렇다. 디자인 리뷰, 제품 제안, 전략 공유, 올핸즈 발표, 클라이언트 설명, 내부 의사결정 회의처럼 "무언가를 보여주며 정렬을 맞춰야 하는 자리"다. 이때 Slides의 장점은 두 가지다.

첫째, 디자인과 발표가 멀리 떨어지지 않는다. 둘째, 발표가 단순한 정적 페이지 모음으로 끝나지 않는다. 피그마 프로토타입을 슬라이드 안에 넣어 실제 동작을 보여줄 수 있고, 투표나 정렬 도구 같은 참여 기능도 활용할 수 있다.³¹⁰

입문자 입장에서는 이렇게 이해하면 쉽다. PowerPoint가 "발표를 위한 만능 슬라이드 툴"이라면, Slides는 "제품과 디자인 맥락을 품은 발표 툴"이다. 따라서 숫자 중심 보고서나 문서형 슬라이드만 만들 일이라면 기존 발표 툴이 더 빠를 때도 있다. 하지만 제품 화면, 사용자 흐름, 프로토타입, 브랜드 컴포넌트와 함께 이야기해야 한다면 Slides 쪽이 자연스럽다.

실무에서 자주 쓰는 좋은 흐름은 이렇다. FigJam에서 워크숍을 하고, Slides로 논리를 정리해 발표하고, 결정된 내용을 다시 Design 파일에 반영한다. 피그마 안에서 생각, 설득, 실행이 이어지는 셈이다.

Buzz: 브랜드 자산을 빠르게 늘리는 제작 라인

Buzz는 아직 많은 디자이너에게 가장 낯선 얼굴일 것이다. 이유는 간단하다. 제품 디자이너의 일상 중심에는 Design와 FigJam이 있고, 발표가 잦은 팀은 Slides를 자주 쓰지만, Buzz는 상대적으로 브랜드나 마케팅 운영에 더 가까운 도구이기 때문이다.

피그마는 Buzz를 온브랜드 자산을 대규모로 제작하는 제품으로 소개하고 있다.¹ 이 설명만 들어도 역할이 보인다. Buzz는 한 장의 정교한 UI를 만드는 공간이라기보다, 이미 정해진 브랜드 규칙 안에서 여러 형식의 시각 자산을 빠르게 생산하는 데 어울린다.

예를 들어 같은 캠페인 메시지를 인스타그램 정사각형 이미지, 세로 스토리, 링크드인 배너, 행사 안내 카드, 사내 공지 비주얼로 바꿔야 한다고 해보자. Design로도 만들 수는 있다. 하지만 그런 작업은 종종 "정밀한 설계"보다 "반복 생산과 규칙 유지"가 더 중요하다. 이럴 때 Buzz라는 별도 공간의 의미가 생긴다.

특히 브랜드팀, 마케팅팀, 소셜 운영팀과 협업하는 조직이라면 Design만으로 모든 것을 해결하려 하지 않는 편이 좋다. 제품 화면은 Design에서, 발표 자료는 Slides에서, 브랜드 자산은 Buzz에서 다루는 식으로 작업대를 나누면 파일 구조도 깔끔해지고, 각 팀이 익숙한 리듬으로 움직일 수 있다.

물론 모든 팀에 Buzz가 필수는 아니다. 작은 스타트업처럼 브랜드 자산을 소수 인원이 그때그때 만드는 조직에서는 당장 체감이 크지 않을 수 있다. 반대로 다채널 캠페인을 자주 운영하고, 같은 메시지를 다양한 형식으로 반복 배포하는 조직이라면 Buzz는 점점 더 중요해진다.

한마디로 정리하면 이렇다. Design가 "제품 화면의 일관성"을 책임진다면, Buzz는 "브랜드 표현의 일관성"을 책임지는 쪽에 가깝다.

Make: 프롬프트를 작동하는 결과물로 바꾸는 실험실

이제 많은 독자가 가장 궁금해할 얼굴로 가보자. Make는 피그마가 2026년에 단순 디자인 툴을 넘어 제품 제작 플랫폼으로 읽히게 만든 핵심 축 중 하나다.²¹¹

피그마는 Make를 AI 기반 prompt-to-app 도구로 설명한다. 말 그대로, 프롬프트와 기존 디자인을 바탕으로 기능하는 프로토타입, 웹 앱, 인터랙티브 UI를 만들 수 있는 환경이다.⁴ 중요한 건 이것이 단순한 이미지 생성기가 아니라는 점이다. "그럴듯한 그림"이 아니라 "어느 정도 작동하는 것"으로 넘어가게 해준다.

입문자는 Make를 종종 Design의 상위 버전처럼 오해한다. 하지만 둘은 결이 다르다. Design는 정밀하게 설계하고 다듬는 공간이고, Make는 빠르게 실험하고 동작을 붙여보는 공간이다. Design가 설계도라면, Make는 시험 주행장에 가깝다.

예를 들어 이런 상황을 생각해보자. 당신은 핀테크 앱의 대시보드 아이디어가 있다. 화면 구조는 대충 떠오르지만, 실제로 버튼을 눌렀을 때 어떤 흐름이 될지, 차트 토글이 자연스러운지, 월간 리포트로 넘어갈 때 느낌이 어떤지 빨리 확인해보고 싶다. 이럴 때 Make는 텍스트 설명만으로 기본 작동 구조를 세우는 데 도움을 준다. 기존 Figma 프레임이나 컴포넌트를 첨부해서 스타일과 구조의 맥락을 주는 것도 가능하다.⁴¹²

다만 기대치는 정확히 잡아야 한다. Make는 초고속 출발 장치이지, 자동 완성 버튼이 아니다. 공식 FAQ도 Make가 기존 디자인을 붙여 쓰고, 포인트 앤 에디트 방식으로 수정하고, 코드 편집기를 통해 직접 코드도 다룰 수 있다고 설명하지만, 생성 결과를 그대로 제품에 넣어도 된다고 말하지는 않는다.⁴ 실제로 많은 리뷰도 Make의 강점은 탐색 속도와 프로토타이핑 가속에 있고, 세밀한 UX 판단과 품질 보증은 여전히 사람의 몫이라고 지적한다.¹¹¹³

그러니 Make를 가장 잘 쓰는 방법은 "처음부터 완벽한 결과를 요구하는 것"이 아니라 "빠른 첫 버전과 반복의 엔진으로 쓰는 것"이다. 이때 잘 정리된 디자인 시스템과 자동 레이아웃, 명확한 컴포넌트 구조가 있으면 결과 품질이 훨씬 좋아진다. 이 책 2부에서 자꾸 파일 구조를 강조하는 이유도 여기에 있다.

다섯 얼굴을 어떻게 구분할까: 헷갈릴 때 쓰는 판단 기준

실무에서는 제품 이름보다 상황이 먼저 온다. 그래서 다음 질문 순서로 고르면 덜 헷갈린다.

첫째, 지금 내가 해야 할 일이 "생각 정리"인가 "정밀 설계"인가를 본다. 아직 문제를 정의하고 의견을 모으는 단계라면 FigJam이 맞다. 화면 구조와 컴포넌트를 구체화해야 한다면 Design다.

둘째, 결과물이 "설명용"인가 "작동 확인용"인가를 본다. 이해관계자를 설득하고 발표 흐름을 잡는 것이 목적이면 Slides가 자연스럽다. 반대로 실제로 눌러보고 반응을 확인해야 한다면 Make 쪽이 더 가깝다.

셋째, 작업의 중심이 "제품 UI"인가 "브랜드 자산"인가를 본다. 서비스 화면, 상태, 인터랙션이 핵심이면 Design다. 이미 정해진 브랜드 규칙 안에서 다양한 채널용 비주얼을 빠르게 만들어야 한다면 Buzz가 맞다.

짧게 요약하면 이렇게 기억하면 좋다.

Design: 제품 화면을 정확하게 설계할 때
FigJam: 문제를 함께 풀고 생각을 정리할 때
Slides: 이야기 구조를 만들고 설득할 때
Buzz: 브랜드 자산을 빠르게 반복 생산할 때
Make: 프롬프트로 동작하는 결과물을 빠르게 실험할 때

이 다섯 개를 기능으로 외우지 말고, "내가 지금 줄이고 싶은 낭비가 무엇인가"로 떠올리면 더 잘 기억된다. 막연함을 줄이고 싶으면 FigJam, 반복 수작업을 줄이고 싶으면 Design와 라이브러리, 발표 재작업을 줄이고 싶으면 Slides, 채널별 자산 생산 시간을 줄이고 싶으면 Buzz, 첫 프로토타입까지의 시간을 줄이고 싶으면 Make다.

자주 생기는 오해

피그마를 배우기 시작하면 몇 가지 오해가 거의 반드시 생긴다.

첫 번째 오해는 "모든 일은 Design에서 시작해야 한다"는 생각이다. 아니다. 생각이 흐릴 때 Design부터 열면, 해결해야 할 문제보다 정렬과 색상에 먼저 매달리기 쉽다. 방향이 안 보이면 FigJam으로 가는 편이 낫다.

두 번째 오해는 "Slides는 발표용이니까 디자이너에게는 부차적이다"라는 생각이다. 하지만 실무에서 디자인은 자주 설명되어야 하고, 설명은 곧 설득이다. 좋은 디자인이 묻히는 이유는 설계가 부족해서가 아니라, 맥락 전달이 약해서인 경우도 많다. 그래서 Slides는 생각보다 전략적인 도구다.

세 번째 오해는 "Make가 있으니 이제 Design를 깊게 배울 필요가 없다"는 기대다. 오히려 반대다. Make의 결과를 잘 끌어내고 제대로 평가하려면 Design의 구조적 이해가 더 중요해진다. 좋은 자동 레이아웃, 컴포넌트, 변수 체계 없이 AI에게 품질을 기대하는 것은, 정리 안 된 부엌에서 훌륭한 요리를 기대하는 것과 비슷하다.

네 번째 오해는 "Buzz는 마케터용이니 디자이너는 몰라도 된다"는 판단이다. 제품 디자이너라도 브랜드팀과 협업하는 순간, 어떤 자산이 제품 맥락이고 어떤 자산이 브랜드 운영 맥락인지 구분할 수 있어야 한다. 그래야 일을 괜히 Design 파일 하나에 다 몰아넣지 않는다.

추천 시작 흐름: 오늘 당장 실무에 적용하는 법

처음부터 다 잘 쓰려고 하면 오히려 꼬인다. 다섯 얼굴을 한꺼번에 마스터하려 하지 말고, 아래 흐름으로 익히는 편이 좋다.

먼저 Design와 FigJam의 역할 차이를 몸에 익힌다. 아이디어는 FigJam에서, 화면은 Design에서 시작하는 습관만 들어도 파일의 질이 달라진다.

그다음 Slides를 붙인다. 디자인 리뷰나 팀 공유를 할 때 캡처를 붙여 만든 슬라이드 대신, 피그마 안에서 자료를 정리해보자. 이 단계에서 "보여주기 위한 정리"가 얼마나 줄어드는지 체감할 수 있다.

그리고 나서 Make를 시도한다. 처음에는 거창한 앱보다 작은 흐름이 좋다. 회원가입 한 단계, 설정 패널 하나, 토글이 있는 카드 한 장처럼 범위를 좁히면 훨씬 덜 흔들린다. Make는 크게 한 번에 시키는 것보다, 작게 시작해 반복하는 쪽이 안정적이다.¹²

Buzz는 마지막에 붙여도 괜찮다. 다만 팀에 마케팅이나 브랜드 운영이 있다면, 제품 UI와 홍보 자산의 작업 공간을 어떻게 나눌지 일찍 대화해두는 편이 좋다.

이 장의 핵심 정리

2026년의 피그마는 더 이상 "UI 그리는 앱 하나"로 이해하면 자꾸 길을 잃는다. 지금의 피그마는 목적별 작업 공간이 연결된 플랫폼이다. 따라서 피그마를 잘 쓴다는 말은 툴 하나를 깊게 안다는 뜻만이 아니라, 지금의 문제를 어디에서 시작할지 잘 안다는 뜻이기도 하다.²

무언가를 만들기 전에 먼저 물어보자. 지금 필요한 것은 합의인가, 설계인가, 발표인가, 자산 생산인가, 작동 실험인가. 그 질문에 따라 Design, FigJam, Slides, Buzz, Make 중 시작점이 달라진다.

시작점이 맞으면 속도가 붙고, 시작점이 틀리면 같은 일을 두세 번 하게 된다. 이것이 피그마의 다섯 얼굴을 굳이 구분해서 배우는 이유다.

다음 장에서는 이 다섯 얼굴을 오갈 때 길을 잃지 않도록, UI3 인터페이스와 작업 환경부터 정리해보겠다. 피그마는 기능보다 화면이 먼저 낯설 수 있다. 하지만 지도만 한 번 제대로 보면, 그다음부터는 훨씬 덜 헤맨다.