여는 글. 왜 지금 다시 피그마인가
몇 해 전만 해도 피그마는 분명한 도구였다. 화면을 설계하고, 팀과 코멘트를 주고받고, 개발자에게 넘기는 곳. 디자이너의 일은 대체로 이 흐름을 따라갔다. 문제를 정의하고, 와이어프레임을 만들고, 시안을 다듬고, 프로토타입을 연결하고, 개발 핸드오프를 준비하는 식이었다. 그 과정에서 속도를 높여주는 플러그인은 많았지만, 일하는 방식 자체를 바꾸지는 못했다.
하지만 2026년의 피그마는 더 이상 "화면을 그리는 앱"이라고만 부르기 어렵다. 이제 피그마는 디자인 파일, 디자인 시스템, AI 생성, 코드 핸드오프, 그리고 AI 에이전트 협업이 한데 모이는 작업 환경이 되었다. 어떤 팀은 피그마 안에서 초안을 만들고, 어떤 팀은 코드에서 캔버스로 가져오고, 또 어떤 팀은 에이전트에게 피그마 파일을 직접 수정하게 한다. 중요한 변화는 기능이 많아진 것이 아니라, 제품을 만드는 흐름의 중심이 다시 피그마 쪽으로 모이고 있다는 점이다.12
그래서 이 책은 피그마를 "배우는 책"이면서 동시에 "다시 보는 책"이다. 이미 피그마를 오래 써온 사람에게는 익숙한 도구가 어떻게 새로운 운영체제가 되었는지를 설명하고, 이제 막 시작하는 사람에게는 2026년 기준으로 무엇부터 익혀야 하는지를 가장 짧고 단단한 동선으로 안내하려 한다.
2026년 디자이너의 하루는 어떻게 바뀌었는가
예전의 디자이너는 빈 프레임 앞에서 시작했다. 오늘의 디자이너는 빈 프롬프트 앞에서 시작하는 경우가 많다.
아침 회의가 끝나면 디자이너는 먼저 화면을 그리기보다 문제를 문장으로 정리한다. "신규 사용자가 3분 안에 가입을 마치게 도와주는 온보딩 흐름", "모바일 결제 실패를 줄이는 체크아웃 화면", "다크 모드와 다국어를 고려한 설정 페이지" 같은 식이다. 이 설명은 더 이상 메모로만 남지 않는다. First Draft 같은 기능은 이런 문장을 바탕으로 초기 UI를 빠르게 제안하고, Replace content는 더미 텍스트를 사람 말처럼 바꾸고, Add interactions는 여러 프레임 사이의 연결을 자동으로 돕는다.2
점심 전에는 "만들기"보다 "고르기"가 중요해진다. AI가 몇 가지 초안을 가져오면 디자이너는 그중 무엇이 우리 제품의 맥락에 맞는지 판단한다. 브랜드 톤에 맞는지, 접근성은 괜찮은지, 사용자의 기대와 어긋나지 않는지, 개발 가능한 구조인지 따진다. 즉, 손의 반복 작업은 줄고, 눈과 판단의 비중은 커진다.
오후에는 개발과의 경계도 흐려진다. Dev Mode는 레이어를 코드 관점에서 더 구조적으로 보여주고, Code Connect는 피그마 컴포넌트와 실제 코드 컴포넌트를 연결해 준다. 덕분에 "이 버튼은 대충 이런 느낌입니다"가 아니라 "이 버튼은 실제 코드의 이 컴포넌트와 연결됩니다"라고 말할 수 있게 됐다.2
그리고 이제는 한 단계 더 나아간다. MCP 서버와 use_figma를 통해 Claude Code, Codex, Cursor 같은 AI 에이전트가 피그마 캔버스에 직접 접근해 프레임을 만들고, 컴포넌트를 배치하고, 변수와 오토 레이아웃을 활용할 수 있게 되었다. 다시 말해 AI는 피그마 바깥에서 조언만 하는 존재가 아니라, 피그마 안에서 함께 일하는 동료가 되기 시작했다.13
이 변화는 디자이너를 덜 중요하게 만들지 않는다. 오히려 반대다. 초안을 만드는 사람보다, 기준을 세우는 사람이 더 중요해졌다. 무엇을 만들지보다 무엇을 반복 가능하게 만들지가 더 중요해졌다. 예쁜 화면보다 해석 가능한 구조가 더 중요해졌다.
왜 하필 "다시" 피그마인가
"새로운 AI 디자인 도구가 이렇게 많은데, 왜 다시 피그마인가?"라는 질문은 아주 자연스럽다. 답은 간단하다. 제품 팀의 현실은 여전히 협업과 수정, 재사용, 연결의 문제이기 때문이다.
생성형 도구는 처음 한 장면을 만드는 데는 강하다. 하지만 실제 제품은 한 장면으로 끝나지 않는다. 수십 개의 화면이 연결되고, 브랜드 규칙이 유지되어야 하며, 라이트와 다크 모드가 갈라지고, 로컬라이징이 들어가고, 컴포넌트가 버전업되고, 개발 코드와 다시 만나야 한다. 바로 이 지점에서 피그마의 힘이 드러난다. 피그마는 아이디어를 예쁘게 뽑아내는 도구를 넘어, 시스템과 협업의 문맥을 유지하는 공간이기 때문이다.2
게다가 2026년의 피그마는 이 장점을 AI와 결합했다. AI가 초안을 만들 수는 있지만, 그 초안이 팀의 컴포넌트와 변수, 라이브러리, 코드 연결 위에서 작동하게 만드는 일은 또 다른 차원의 문제다. Figma MCP 서버와 Skills는 바로 이 차이를 메운다. 에이전트에게 "버튼을 하나 만들어"가 아니라 "우리 팀의 규칙대로, 우리 라이브러리의 버튼을 써서, 우리 변수 체계에 맞게 화면을 만들어"라고 말할 수 있게 해준다.145
이제 피그마를 다시 배워야 하는 이유는 새 버튼 위치를 외우기 위해서가 아니다. 디자인이 파일 중심에서 시스템 중심으로, 다시 시스템 중심에서 에이전트 협업 중심으로 이동했기 때문이다. 이 변화를 이해하지 못하면 최신 기능을 알아도 실무에서는 계속 엇박자가 난다.
이제 디자이너는 화면이 아니라 구조를 설계한다
과거의 좋은 파일은 사람이 보기 좋은 파일이었다. 레이어가 정리되어 있고, 정렬이 잘 되어 있고, 컴포넌트가 적당히 재사용된 파일 말이다. 물론 지금도 그것은 중요하다. 하지만 이제는 한 가지 조건이 더 붙었다. AI가 읽기 좋은 파일이어야 한다.
AI가 피그마 파일을 읽는다는 것은 마법 같은 일이 아니다. 결국 이름, 계층, 자동 레이아웃, 변수 바인딩, 컴포넌트 관계처럼 구조화된 단서를 해석한다는 뜻이다. 버튼이 "Rectangle 245"와 "Text 91"의 조합으로 흩어져 있으면 사람도 힘들고 AI도 힘들다. 반대로 버튼이 명확한 컴포넌트이고, 텍스트 속성과 상태가 정의되어 있고, 색과 간격이 변수에 묶여 있다면 사람과 AI 모두 훨씬 정확하게 다룰 수 있다.
그래서 이 책은 단순히 "피그마에 AI 기능이 생겼다"라고 말하지 않는다. 더 정확히 말하면 "AI 시대의 피그마 파일은 읽히는 설계 문서가 되어야 한다"라고 말한다. 디자인 시스템을 잘 만드는 일은 더 이상 협업 효율만의 문제가 아니다. 에이전트가 실수하지 않도록 만드는 안전장치이기도 하다.
이 책이 다루는 새 워크플로우의 지도
이 책의 부제는 "Figma Make · MCP · Skills로 일하는 새 디자인 워크플로우"다. 이 순서는 우연이 아니다. 지금의 피그마는 크게 세 층으로 이해해야 가장 잘 보인다.
첫째, 기본 캔버스 층이 있다. Design, FigJam, Slides, Buzz, Make처럼 피그마의 표면을 이루는 작업 공간과 UI3 인터페이스, 프레임, 오토 레이아웃, 변수, 컴포넌트가 여기에 속한다. 이것은 여전히 가장 중요한 바닥이다. 바닥이 흔들리면 AI를 붙여도 결과는 금세 무너진다.
둘째, 시스템 층이 있다. 토큰, 변수, 모드, 라이브러리, 코드 연결이 여기에 속한다. 이 층은 팀의 디자인 판단을 구조로 저장하는 곳이다. 예전에는 "통일감"을 위해 필요했다면, 이제는 "기계가 오해하지 않기 위해"서도 필요하다.
셋째, 에이전트 층이 있다. Figma AI, Figma Make, MCP, use_figma, Skills가 여기에 있다. 이 층에서는 사람이 일일이 조작하던 일부 작업을 프롬프트와 규칙으로 위임한다. 중요한 것은 위임이지 포기가 아니다. 좋은 팀은 일을 덜 하는 팀이 아니라, 사람만 해야 할 판단과 기계에게 맡겨도 되는 반복을 구분하는 팀이다.
이 책은 바로 이 세 층을 순서대로 밟는다. 먼저 피그마의 바닥을 다시 단단히 다지고, 그 위에 AI가 읽을 수 있는 디자인 시스템을 세운 다음, 캔버스 안의 생성형 도구를 익히고, 마지막으로 Make와 MCP, Skills까지 연결한다. 즉, 기능 소개의 나열이 아니라 한 팀의 작업 방식이 진화하는 순서를 따라간다.
이 책의 핵심 관점: 도구 설명보다 일하는 방식의 변화
피그마의 새 기능만 따로 떼어 보면 모두 그럴듯하다. 텍스트를 바꿔주고, 이미지를 늘려주고, 레이어 이름을 정리해주고, 화면 초안을 만들어준다. 그런데 이런 기능을 하나씩만 배우면 실무에서는 금방 한계에 부딪힌다. 왜냐하면 팀은 기능 단위로 일하지 않고 흐름 단위로 일하기 때문이다.
예를 들어 텍스트 생성 기능은 혼자 보면 사소해 보일 수 있다. 하지만 실제로는 리서치용 프로토타입의 현실감을 높이고, 이해관계자 피드백의 질을 바꾸며, 다국어 검토 속도를 올린다. 오토 레이아웃은 정렬 기능처럼 보이지만, 실은 반응형 구조와 AI 해석 가능성을 동시에 높이는 기반이다. 변수는 테마 관리 도구 같지만, 실제로는 디자인 시스템과 코드, 그리고 에이전트 작업을 이어주는 공용 언어가 된다.
이 책은 바로 이런 연결을 보여주려 한다. "무엇이 있나"보다 "어떻게 이어지나"를 설명한다. 그래서 책을 덮고 나면 기능 목록이 아니라 작업 방식의 지도가 머릿속에 남도록 구성했다.
이 책을 가장 잘 읽는 방법
이 책은 세 부류의 독자를 동시에 염두에 두고 있다.
피그마를 오래 썼지만 최근 변화가 너무 빨라 감을 다시 잡고 싶은 디자이너
피그마를 처음 배우지만 2026년 기준의 실무 흐름으로 바로 들어가고 싶은 입문자
디자인 시스템, 코드 핸드오프, AI 에이전트 협업까지 하나의 흐름으로 이해하고 싶은 팀 리드와 메이커
읽는 방법은 단순하다. 입문자라면 1부부터 차근차근 읽는 편이 가장 좋다. 특히 프레임, 오토 레이아웃, 변수, 컴포넌트는 뒤로 갈수록 계속 등장하는 공통 문법이므로 건너뛰지 않는 편이 좋다. 이미 실무 경험이 있다면 2부부터 읽어도 괜찮지만, UI3와 변수 체계가 낯설다면 1부를 빠르게 훑고 올라오는 편이 훨씬 수월하다. Make나 MCP에 바로 눈이 가더라도, 실제로 가장 큰 차이를 만드는 것은 앞단의 파일 구조와 시스템 설계라는 점을 기억해두면 좋겠다.
특히 이 책은 "당장 멋진 결과 만들기"보다 "계속 좋은 결과가 나오게 만드는 법"에 더 큰 비중을 둔다. 한 번의 성공적인 프롬프트보다, 팀이 반복해서 안정적인 결과를 얻는 구조가 더 중요하기 때문이다. 그 구조가 바로 변수, 토큰, 라이브러리, 코드 연결, 그리고 Skills다.
앞으로 펼쳐질 것들
1부에서는 2026년의 피그마를 다시 익힌다. 어디서 무엇을 해야 하는지 헷갈리지 않도록 피그마의 다섯 얼굴을 정리하고, UI3 인터페이스를 빠르게 익히며, 반응형의 핵심 문법인 프레임·오토 레이아웃·변수를 묶어 이해한다. 그리고 컴포넌트와 변형으로 재사용 가능한 설계의 출발점을 다진다.
2부에서는 이 책의 중요한 분기점이 나온다. 디자인 시스템을 "팀 문서"가 아니라 "AI가 해석할 수 있는 구조"로 다시 본다. 토큰 아키텍처, 모드 설계, 라이브러리 운영, 레이어 명명과 구조화가 왜 이제 더 중요해졌는지를 실전 중심으로 다룬다.
3부에서는 피그마 안에 들어온 생성형 AI 도구들을 정리한다. 어디까지 믿어도 되는지, 어디서 사람이 개입해야 하는지, 어떤 기능은 시간을 아껴주고 어떤 기능은 아직 참고용에 가까운지를 현실적으로 살핀다.2
4부는 하이라이트다. Figma Make를 통해 프롬프트에서 앱으로 이어지는 흐름을 다룬다. 좋은 프롬프트의 구성, Figma에서 Make로 가져가는 방식, 게시와 보안 검토까지 한 번에 본다. 이 부분은 단순히 "코드가 나온다"가 아니라 "디자인 시스템 위에서 어떻게 더 나은 결과를 얻는가"에 초점을 맞춘다.
5부에서는 2026년의 가장 흥미로운 변화, 즉 AI 에이전트와의 협업을 다룬다. MCP 서버와 use_figma, 그리고 Skills를 이용해 팀의 판단을 AI에게 가르치는 법을 익힌다. 이쯤 오면 피그마는 더 이상 그림판이 아니다. 팀의 의도와 규칙, 코드와 설계가 만나는 운영 환경이 된다.134
다시, 피그마를 중심으로
좋은 도구는 손을 빠르게 한다. 하지만 위대한 도구는 팀의 대화를 바꾼다.
2026년의 피그마가 중요한 이유는 버튼을 더 빨리 그리게 해줘서가 아니다. 디자이너, 개발자, PM, 그리고 AI 에이전트가 같은 구조를 보고 같은 기준으로 일하게 만들기 때문이다. 예전에는 시안을 공유하는 것이 협업이었다면, 이제는 구조와 규칙을 공유하는 것이 협업이다. 그리고 그 구조가 가장 선명하게 모이는 곳이 다시 피그마다.
그러니 이 책은 기능을 익히는 여행이라기보다, 제품을 만드는 방식을 업데이트하는 여정에 가깝다. 화면 하나를 잘 만드는 법에서 출발해, 시스템을 세우고, AI와 협업하고, 디자인으로 출시까지 이어지는 흐름을 차례로 밟아갈 것이다.
다시 피그마를 배운다는 것은, 사실 다시 일하는 법을 배우는 일이다.
참고
1Agents, meet the Figma canvas
2Figma AI in 2026: Everything it can do — and what it still can't
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.