Figma 하나로 이루어지는 일의 흐름

역할보다는 연결에 집중할 때

by ALIC EXPERIENCE



웹사이트 하나를 만들려면 기획자, 디자이너, 개발자 등 여러 역할이 필요해요. 우리는 그런 협업 구조 안에서 오랜 시간 일을 해왔고, 지금도 그 방식은 여전히 유효하다고 생각해요. 하지만 이제는, 더 간편해진 웹 퍼블리싱 도구의 출현으로 개발 단계까지 기다리지 않고도 디자이너와 기획자가 직접 결과물을 실험할 수 있는 환경이 열렸어요.


이 흐름 속에서 피그마가 Config 2025에서 선보인 새로운 기능들은 단순한 기능 추가를 넘어 ‘어떻게 일할 것인가’에 대한 변화를 시사하고 있었어요. 그중에서도 텍스트 프롬프트 입력만으로 UI와 인터랙션을 구현할 수 있는 Figma Make, 디자인 작업을 바로 웹에 게시할 수 있는 Figma Sites가 특히 인상 깊게 다가왔어요.


5월 Config 2025 당시 키노트


두 기능을 사용해 보며, 실제 업무에서 어떻게 활용하는 것이 적합할지 궁금했어요. 둘 다 개발 없이 퍼블리싱할 수 있다는 점에서 겉보기에 비슷해 보이지만, 지향하는 사용 목적이 다르다는 점을 알 수 있었어요. 그렇다면 각 툴은 어떨 때 사용하는 것이 가장 적합할까요?










Figma Make, 빠르게 아이디어를 시각화하고 싶을 때


Figma Make는 디자인 자원이 거의 없는 초기 단계에서, 머릿속에만 있는 아이디어를 빠르고 가볍게 시각화해서 팀원과 공유할 수 있는 큰 장점이 있어요. 디자인 시안을 만드는데 드는 시간을 아끼거나 UI 구조에 대한 감을 잡는 데도 도움이 되고요. 완성도 높은 화면을 만들기 위한 목적이라기보다는 아이디어에 대한 의사결정을 돕는 1차 커뮤니케이션용 도구에 가깝다고 느껴졌어요.


Figma 하나로 이루어지는 일의 흐름_img_2.png


아이디어의 윤곽을 빠르게 잡아보기에는 유용하지만, 텍스트 프롬프트로만 수정이 가능하고 화면 구성의 자유도가 제한적이라는 점은 아쉬웠어요. 그래서 Figma Make는 간단한 구조나 아이디어 흐름을 빠르게 시각적으로 보여주는데 초점을 맞춘 도구라는 걸 인지하고 접근하는 게 중요해 보여요.





Figma Sites, 실제 사용자 경험으로 연결하고 검증하고 싶을 때


Figma Sites는 디자인이 어느 정도 구체화된 단계에서, 완성된 시안을 그대로 웹에 퍼블리싱해 실제 사용자 경험을 테스트해보고 싶을 때 유용해요. 개발 없이도 실제 서비스처럼 동작하는 결과물을 만들 수 있어서, 단순한 내부 공유를 넘어 실제 사용자의 반응을 확인할 수 있어요.


Make와 Sites는 단순히 두 개의 퍼블리싱 툴이 아니라, 디자이너가 어떤 타이밍에 어떤 방식으로 결과물을 보여주고 싶은지에 따라 선택할 수 있는 두 가지 전략이에요. Make는 빠른 아이디어 스케치에, Sites는 완성된 경험 전달에 적합하다는 점에서 용도는 분명히 다르지만, 중요한 건 결국 이 두 툴은 경쟁 관계가 아니라, 서로 다른 목적을 채워주는 보완적 도구로 함께 활용될 수 있어요.


s (1).gif


그래서인지 Sites 내에서도 Make 기능을 사용할 수 있도록 설계되어 있어요. 두 가지 기능을 함께 쓰며 복잡하거나 번거로운 일을 Make로 처리하고, Sites로 바로 게시할 수 있어요.

특히 Sites는 기본적인 인터랙션만 제공되는 반면, Make를 사용하면 프롬프트 기반의 다양한 동적인 인터랙션을 구현하는데 큰 도움을 받을 수 있어요.





프로토타입 전문 툴과 어떤 점이 다를까?


사용자 테스트를 할 때, ProtoPie 같은 프로토타입 전문 툴을 사용해 프로토타입을 만들기도 해요. 이러한 프로토타이핑 툴은 제한된 사용자 플로우 안에서 인터랙션이나 전환 흐름을 확인하는 데 초점이 맞춰져 있었어요. 대개는 디자인된 화면을 프로토타이핑 툴로 내보내고, 플로우 별 프로토타입 작업을 마친 뒤, 미리 정의된 시나리오에 따라 사용자 테스트를 진행해요.


하지만 이 과정에는 몇 가지 한계가 있어요.

사용자가 예외적인 행동을 하면 작동이 멈추거나 흐름이 끊기기 쉽고, 테스트 전용 환경이라 실제 서비스처럼 느끼기엔 이질감이 커요. ‘진짜’라는 느낌이 부족하다 보니 사용자 반응도 실제와 다르게 나타날 수 있어요.


ProtoPie


반면, Figma Sites는 실제 서비스에 가까운 형태로 디자인 결과물을 퍼블리싱할 수 있기 때문에, 사용자가 예상 밖의 행동을 하더라도 흐름이 끊기지 않고 이어질 수 있어요. 사용자 입장에서도 ‘진짜’라는 인상을 주어서 자연스러운 반응을 관찰하기 쉬워요.





왜 Figma Sites를 써야 할까?


사실 Figma Sites와 유사한 기능을 제공하는 노코딩 퍼블리싱 툴은 Framer, Webflow, Wix, Bubble 등 시중에 다양하게 존재해요. 그럼에도 Figma Sites를 써야 할 이유는 분명했어요.





툴 전환 없는 워크플로우


별도의 프로토타이핑 툴로 옮길 필요 없이, Figma 내에서 작업한 디자인을 그대로 웹에 게시할 수 있어요. Figma Design에서 기획/디자인을 한 뒤, 오른쪽 클릭 후 Figma Sites로 복사하기만 하면 끝나요. 툴을 오갈 필요가 없다는 점, 그 단순함이 다른 툴 대비 효율적으로 느껴졌어요.


Figma 하나로 이루어지는 일의 흐름_img_5.png





기존 라이브러리 활용


Figma Design에서 이미 만들어둔 라이브러리를 그대로 불러와 사용할 수 있기 때문에, 기존 컴포넌트나 디자인 시스템을 바탕으로 시작할 수 있어 작업 속도와 일관성 모두 챙길 수 있어요.

특히 브레이크포인트에 맞춰 반응형 컴포넌트를 미리 제작해 두었다면, Figma Sites 내에서 별도 작업 없이도 자동으로 반응형 웹이 만들어지기 때문에 훨씬 생산적이에요.


Figma 하나로 이루어지는 일의 흐름_img_6.png *Figma Sites의 브레이크포인트 이름과, 라이브러리 내 명칭이 일치해야 적용됨 (예_Desktop/Tablet/Mobile)










Figma의 이번 업데이트는 프로덕트와 관련된 모든 사람들이 하나의 플랫폼 안에서 아이디어를 빠르게 공유하고, 함께 판단하고 실행할 수 있는 흐름을 만들어냈다는 점에서 의미가 크다고 생각해요. 역할 구분 없이 누구든 필요한 순간에 바로 만들고, 보여주고, 반응을 받을 수 있는 환경이 열렸죠.


앞으로는 정해진 역할만 수행하는 것이 아니라, 스스로 문제를 정의하고 해결까지 이끌어가는 주도성이 점점 더 중요한 역량이 될 것 같아요.





Property 1=강지현.png
작가의 이전글심층 인터뷰 빌런에 대처하는 4가지 방법