Figma AI 에이전트, 디자이너 일자리 진짜 위협받나 — 채용 공고가 먼저 바뀌었다

디자이너 커뮤니티에 조용한 지각변동이 일어나고 있어요. Figma Design Agent가 2026년 5월 베타 출시된 지 다섯 달이 지났고, 지금 채용 공고는 완전히 다른 언어로 쓰이고 있거든요.
“Vibecoding”, “agent orchestration”, “Design Engineer” — 불과 2년 전만 해도 디자이너 JD(채용 공고)에 없던 단어들이에요. Figma AI 에이전트, 디자이너 일자리 진짜 위협받나라는 질문은 이제 단순한 공포가 아니라, 데이터로 답해야 할 현실적인 질문이 됐어요.
핵심은 이거예요. 일자리가 없어지는 게 아니라, 일자리의 모양이 바뀌고 있다는 것.
핵심 요약
- Figma의 State of the Designer 2026 보고서에 따르면, 디자이너의 72%가 이미 생성형 AI를 업무에 쓰고 있고, 91%는 속도와 품질이 모두 개선됐다고 답했어요.
- Figma Design Agent는 아이콘 컴포넌트 18개 변수 재정렬을 2분 40초 만에 처리했어요. 숙련 디자이너도 30분 이상 걸리던 반복 작업이에요.
- Meta, Cursor, Vercel, 당근 등 글로벌·국내 주요 기업 채용 공고에서 디자이너 요구 역량이 “도구 숙련도"에서 “판단력과 코드 이해력"으로 이동하고 있어요.
- 토스는 2024년 4월 기존 6개 디자인 직군을 2개로 통합했어요. AI가 직군 간 경계 자체를 무의미하게 만들었기 때문이에요.
Figma Design Agent, 실제로 뭘 할 수 있나
2026년 5월 20일 출시된 Figma Design Agent는 기존 AI 도구와 다른 방식으로 작동해요. ChatGPT나 Claude처럼 스크린샷을 붙여넣거나 맥락을 설명할 필요가 없어요. 에이전트가 파일을 직접 읽거든요.
폰트, 색상 변수, 컴포넌트 구조를 스스로 파악하고 자연어 명령을 실행해요. brunch 리뷰에서 측정된 실제 수치를 보면:
- 아이콘 컴포넌트 18개, 크기 변수(20→24→28) 재정렬: 2분 40초
- 14개 컴포넌트 세트를 1×6에서 2×3 그리드로 재구성, 프레임 크기를 56×272px에서 144×104px로 일괄 변경: 단일 명령
- 복잡한 Boolean 중첩 인스턴스 변형 해결, 더미 텍스트 자동 생성, 디자인 시스템 문서화까지 처리
이 작업들의 공통점이 뭔지 아세요? 정답이 정해진 반복 작업이에요. 규칙이 있고, 패턴이 있고, 판단이 필요 없는 일들.
그러면 디자이너가 이런 작업에 쏟던 시간은 어디로 가냐면 — UX 의사결정, 플로우 로직, 사용자 경험 구조 설계로 가요. Figma Head of Design Loredana Crisan이 출시 당일 한 말이 정확해요. “소프트웨어 빌드가 쉬워질수록, 방향을 잡는 능력이 더 중요해진다.”
지금 당장 완벽하진 않아요. 에이전트 채팅 스레드에 검색 기능이 없고, 사이드바 접기 버튼도 없어서 캔버스 작업 공간이 좁아져요. 그리고 에이전트가 수정 과정을 설명해주지 않아서, 결과물이 왜 그렇게 나왔는지는 직접 역추적해야 해요.
채용 공고가 바뀌었다 — 이게 진짜 신호예요
추상적인 이야기 말고, 실제 JD를 볼까요.
모비인사이드 분석에 따르면 2026년 글로벌·국내 주요 기업의 디자이너 채용 공고가 근본적으로 달라졌어요:
- Meta(Superintelligence Labs): 우대사항에 “Vibecoding”, “prompt engineering”, “agent orchestration” 명시. 대기업 디자이너 JD에 Vibecoding이 공식 요건으로 들어간 첫 사례예요.
- Figma 자체: “AI 모델에게 디자인을 가르치는 디자이너(Product Designer, AI Models)” 직군을 신설했어요. 도구 사용자가 아니라, 도구의 지능 자체를 설계하는 역할이죠.
- Cursor(Anysphere): Product Designer 직군을 없애고 Design Engineer 단독 채용으로 전환. TypeScript·React·SolidJS·CSS가 필수 요건이에요. “Figma와 코드 에디터를 동등하게 다루는 사람"을 원해요.
- 당근: “AI시대의 디자인 시스템” 섹션 신설. 자사 AI 디자인 에이전트 “Kraft"의 품질 기준 설계가 핵심 업무예요.
그리고 토스. 2024년 4월, 기존 6개 디자인 직군을 프로덕트 디자이너·비주얼 디자이너 2개로 통합했어요. AI 때문에 도구 습득 시간이 줄어서, 직군 간 경계가 무의미해졌기 때문이에요. 내부 AI 콘테스트에서 디자이너들이 Claude Code로 Slack 연동 위젯, UX 봇을 직접 개발한 프로젝트가 122개 나왔고요.
이건 “디자이너가 줄어든다"는 이야기가 아니에요. “디자이너가 더 많은 걸 해야 한다"는 이야기예요.
Figma Agent vs. 경쟁 도구: 뭐가 다른가
Figma Design Agent가 유일한 선택지는 아니에요. Anima 블로그가 비교한 데이터를 정리하면 이렇게 돼요:
| 비교 항목 | Figma Design Agent | Buddy by Anima |
|---|---|---|
| 출시 상태 | 2026년 5월 베타 | 이미 정식 출시 |
| 가용 플랜 | Professional·Org·Enterprise 전용 | Free 포함 전체 플랜 |
| 파일 컨텍스트 인식 | ✅ 자체 파일 직접 읽음 | 제한적 |
| URL → Figma 레이어 변환 | ❌ 불가 | ✅ 가능 |
| HTML → Figma 임포트 | ❌ 불가 | ✅ 가능 |
| 코드 내보내기 | Figma Make로 이동 필요 | React·Vue·HTML 직접 |
| 최적 사용 상황 | Figma 내부 작업 팀 | 외부 소스 → Figma 워크플로우 |
두 도구가 노리는 시나리오가 달라요. Figma Agent는 이미 Figma 안에서 일하는 팀에게 강점이 있어요. 웹사이트나 AI 생성 HTML을 Figma로 가져와서 정제하는 워크플로우라면, Buddy가 더 실용적일 수 있어요.
어떤 도구를 쓰느냐보다, 외부 소스를 어떻게 가져오고 코드로 어떻게 내보내는지가 팀 선택의 기준이 돼요.
그래서 지금 디자이너는 뭘 해야 하나
신입·주니어 디자이너라면, 반복 작업 숙련도보다 판단력 훈련에 시간을 쓰는 게 맞아요. 컴포넌트 변수 정렬은 에이전트가 해요. 어떤 컴포넌트 구조가 확장성 있는지 판단하는 건 아직 사람의 몫이에요.
시니어·리드 디자이너라면, 지금 당장 JD 변화를 트래킹하세요. “Vibecoding 우대"가 Meta에서 나왔다면, 6개월 뒤 중견기업에 퍼지는 건 시간문제예요. TypeScript까지 안 해도 되지만, AI 에이전트에게 맥락을 잘 주는 프롬프트 설계 능력은 필요해질 거예요.
팀 리더·매니저라면, 직군 통합을 준비할 시점이에요. 토스처럼 6개를 2개로 합치는 게 답이 아닐 수 있지만, 지금 구조가 AI 시대에도 유효한지는 점검해볼 만해요.
앞으로 6-12개월 사이 주시할 신호는 세 가지예요:
- Figma Design Agent의 정식 출시 플랜 확대 여부 (현재 Starter·Education 제외)
- “Design Engineer” 직군이 한국 기업 JD에 본격 등장하는 시점
- Figma Make와 Agent의 통합 깊이 — 코드 내보내기까지 원스톱이 되면 워크플로우가 또 달라져요
정리하면
Figma AI 에이전트, 디자이너 일자리 진짜 위협받나라는 질문의 답은 이렇게 요약돼요:
- 반복 작업 기반의 역할은 실질적으로 축소되고 있어요
- 판단·방향 설정·코드 이해 기반의 역할은 확장되고 있어요
- 직군은 줄어들지만, 남은 직군이 더 많은 역할을 맡는 구조예요
2026년 10월 현재, 이미 채용 공고가 바뀌었어요. 다음 신호는 연봉 밴드가 바뀌는 시점이에요. “AI를 잘 다루는 디자이너"와 “그냥 디자이너"의 보상 격차가 가시화되면, 그때가 진짜 변곡점이에요.
당신의 JD는 지금 어떤 언어로 쓰여 있나요?
참고자료
- Will AI Make Designers Obsolete? The ‘New Era Designer’ as Envisioned by LayerX’s Design Organizatio
- Figma AI Agents: Limits, Cost And The WordPress Gap
- [CHORE] Figma 기반 데이터 요구와 기존 API 재사용 협의 · Issue #6 · Han-Spoon/frontend-app


