[30호] 디자이너 채용 공고가 바뀌었다.

안녕하세요, 구독자 님. 여의도에 서식 중인 몽글c입니다.

메이커스노트 20호에서 ‘요즘 PM공고가 이상합니다’라는 글을 clover님이 올려주셨었는데요. 이번에는 AI시대의 PM이 아닌 PD(Product Designer)공고를 살펴보려고 합니다.

PM 뿐만 아니라, 요즘 디자이너 채용 공고도 이상합니다. 우대조건에 vibe coding이 들어가고, AI에게 디자인을 가르쳐야 하며, 디자인 엔지니어를 뽑고 있기도 합니다.

이전 IT 회사의 시니어 프로덕트 디자이너 JD를 살펴보면 예전엔 아래와 같은 문구들이 대부분이었습니다.

그런데 최근 JD를 보면 이런 표현들이 자연스럽게 등장합니다.

"음.. 이거 디자이너 채용 공고 맞나..?"

다시 뜯어 보니, 단순히 AI 관련 문구가 몇 줄 추가된 게 아니예요. 회사가 디자이너에게 기대하는 역할 자체가 달라지고 있습니다.

지난 20호에서 PM 채용 공고의 변화를 함께 살펴봤듯이, 이번에는 디자이너 채용 공고를 나란히 놓고 읽어보려 합니다. PM 쪽에서 "프로덕트 빌더"라는 용어가 등장했듯이, 디자이너 쪽에서는 어떤 변화가 일어나고 있을까요?

메이커스노트 2호 에서도 "앞으로도 프로덕트 디자이너라는 직함은 유효할까?"라는 질문을 던진 적이 있습니다. 그 질문에 대한 답을, 지금의 채용 시장이 조금씩 보여주고 있는 것 같습니다.

디자이너분들은 물론이고, 디자이너와 함께 제품을 만드는 PM과 기획자분들에게도 "앞으로 내 옆의 디자이너는 어떤 사람이 될까"를 가늠해볼 수 있는 이야기를 해보려 합니다.

🔥 1. Meta,  지원공고에 "Vibecoding"이 들어갔다

직군: Product Designer, Meta Superintelligence Labs

Product Designer, Meta Superintelligence Labs

Meta의 초지능 연구소(Superintelligence Labs) 소속 프로덕트 디자이너 공고입니다. 이 공고의 우대사항을 보면 눈을 의심하게 됩니다.

대기업 디자이너 채용 공고에 "Vibecoding"이 우대사항이긴 하지만 공식 자격요건으로 들어간 건 아마 이 공고가 처음일 겁니다. "prompt/context engineering"과 "agent orchestration"도 엔지니어가 아닌 디자이너에게 요구하고 있습니다.

20호에서 PM 공고에 "AI 코딩 툴 활용 경험"이 등장하기 시작했다고 언급된 바와 같이, 디자이너 쪽에서도 같은 흐름이 시작된 셈입니다. 다만 PM이 "Builder"로 확장되고 있다면, 디자이너에게는 "Vibecoding"이라는 더 구체적인 키워드가 붙었다는 점이 흥미롭습니다.

🎨 2. Figma, "AI 모델에게 디자인을 가르치는 디자이너"

직군: Product Designer, AI Models

Job Application for Product Designer, AI Models at Figma

Figma에서 완전히 새로운 유형의 디자이너를 찾고 있습니다.

"AI Model Designer to join our team and become the bridge connecting our AI research innovations with world-class design principles"

"Help us teach our models how to be better copilots for designers"

"As an arbiter of craft and taste, you'll help raise the ceiling for what designers can create with AI"

이 디자이너의 임무는 AI 모델에게 디자인을 가르치는 것입니다. 디자이너가 도구를 사용하는 게 아니라, 도구의 지능 자체를 만드는 쪽으로 역할이 이동한 거예요.

12호에서 "기계가 이해할 수 있는 디자인 시스템"에 대해 이야기한 적이 있었는데요. 시맨틱한 네이밍, 계층 구조, DESIGN_SYSTEM.md 같은 것들이요. Figma의 이 공고는 그 이야기의 연장선에 있습니다. 디자인 시스템을 AI가 읽을 수 있게 정리하는 것을 넘어서, AI 모델 자체가 디자인의 맥락과 품질 기준을 이해하도록 가르치는 단계로 나아가고 있는 겁니다.

자격요건에도 "Experience using AI models for design tasks, either coding or image models"이 포함되어 있습니다. AI 모델을 써본 경험이 아니라, AI 모델을 디자인 관점에서 평가하고 개선할 수 있는 경험을 묻고 있는 거죠.

🖥️ 3. Cursor, 디자이너를 안 뽑는다, "Design Engineer"를 뽑는다

직군: Design Engineer

Cursor · Design Engineer

AI 코드 에디터 Cursor를 만드는 회사(Anysphere)의 채용 공고입니다. (얼마 전 SpaceX에 인수되어 화제가 되기도 했었죠) 이 회사의 약 100개의 채용 공고 중 디자인 관련은 딱 1개. 그것도 Product Designer가 아니라 Design Engineer입니다.

"A design engineer who lives at the intersection of design and code"

"Thinks like a designer but builds like an engineer — or vice versa"

자격요건을 보면 더 명확합니다.

20호에서 Cursor가 "전통적인 PM을 뽑지 않는다"고 했던 것, 기억하시나요? 디자이너도 마찬가지입니다. Cursor에게 디자이너는 시안을 만드는 사람이 아니라, 디자인 감각으로 코드를 짜는 사람입니다.

🛠️ 4. Vercel, Figma 옆에 v0, Cursor, Claude Code가 나란히 있다

직군: Senior Product Designer, Growth

Senior Product Designer, Growth

이 공고에서 가장 눈에 띄는 건 프로토타입 도구 목록입니다.

"Build and test working prototypes using the right tools for the question, including Figma, v0, Cursor, and Claude Code"

Figma와 v0, Cursor, Claude Code가 나란히 디자인 도구로 명시되어 있습니다. 1년 전만 해도 디자이너 JD에서 Figma외에 Cursor나 Claude Code를 볼 일은 없었어요.

더 흥미로운 건 이 문장입니다.

"The work spans people, agents, and the handoffs between them"

디자이너가 설계해야 하는 사용자가 '사람'만이 아니라 'AI 에이전트'까지 포함된다는 뜻입니다. 사람을 위한 화면만 설계하는 게 아니라, 에이전트가 작동하는 방식과 사람-에이전트 사이의 핸드오프까지 디자인해야 한다는 거죠.

17호에서 "도구는 빨라졌는데 실무는 왜 안 빨라지나"라는 이야기를 했었는데, 그 다음 단계가 바로 이것일 수 있습니다. 도구 자체가 바뀌면, 결국 무엇을 디자인하는지도 바뀌게 됩니다.

🥕 5. 당근, "AI 시대의 디자인 시스템"이 JD에 등장한 국내 사례

직군: Design Engineer - 디자인 시스템

Design Engineer - 디자인 시스템 | 당근 채용

국내에서 가장 눈에 띄는 디자이너 채용 공고는 당근의 Design Engineer 공고였어요.

이 공고에는 "AI시대의 디자인 시스템"이라는 별도 섹션이 존재합니다. 여기서 언급되는 것이 "Kraft", 프롬프트로 SEED(당근 디자인 시스템) 기반 화면을 생성하는 디자인 에이전트입니다.

이 Design Engineer의 핵심 역할은 AI가 생성한 결과물의 품질 기준을 유지하기 위한 컴포넌트, 토큰, 인터랙션 표준을 설계하는 것입니다.

우대사항에는 HTML/CSS, React, TypeScript, 직접 컴포넌트 구현 경험이 포함되어 있습니다.

12호에서 "기계가 이해할 수 있는 디자인 시스템"을 이야기하며, 시맨틱한 네이밍과 계층 구조, DESIGN_SYSTEM.md의 중요성을 다뤘었는데요. 그때 이야기했던 것들이 실제 채용 요건으로 나타나고 있는 국내 사례입니다.

🍵 (보너스) 토스, "JD엔 없는데, 블로그엔 있다"

토스의 디자인 채용 공고를 보면, Product Designer JD에 AI나 코딩 관련 요건은 보이지 않습니다. 사용자 경험에 대한 최종 책임, 데이터 기반 문제 정의, 픽셀 단위의 UI 디테일 — 전통적인 프로덕트 디자이너의 역량을 요구하고 있어요. 하지만 토스 테크 블로그에 올라온 글들을 보면, 실무에서는 이미 AI를 적극적으로 활용하고 있다는 걸 느낄 수 있습니다. 

"디자이너가 시안 대신 앱을 만든 이유" 

Figma 목업 대신 Xcode + SwiftUI를 선택했던 사례를 소개하고 있습니다. AI를 "코딩 파트너"로 활용하면서, Metal shader 코드까지 직접 작성해 시각 효과를 구현했어요. 개발팀에 전달한 건 디자인 시안이 아니라 코드 레포지토리였습니다.

"매일 하던 업무를 디자인하기" 

한 디자이너는 Claude Code로 Slack 연동 업무 관리 위젯을 직접 만들었다고 합니다. UX 라이팅 가이드라인을 AI에게 학습시키고, 자신의 커뮤니케이션 스타일에 맞는 봇까지 만들었어요. 결과적으로 개발자들이 디자이너에게 버그를 리포트하는 상황도 발생했다 점이 매우 흥미로웠습니다.

"디자이너에게 AI로 뭐든 만들어보라고 한다면" 

토스 디자인 챕터에서 내부 AI 콘테스트를 열었는데, 122개 프로젝트가 제출되었습니다. 자동 색상 추출 시스템, 개인화된 Slack 봇, 증권 거래 인터페이스 프로토타입, AI 생성 모션 그래픽까지 — 디자이너들이 도구의 사용자가 아니라 도구의 제작자로 움직이고 있었습니다.

20호에서 Duolingo의 사례가 기억나시나요? "JD에 AI가 한 번도 안 나오는데, 지원서에서 AI 활용 경험을 필수로 묻는" 패턴이요. 토스는 그 한국판처럼 느껴졌어요. 공고에는 아직 반영되지 않았지만, 실무에서는 이미 디자이너의 역할이 바뀌고 있습니다.

그래서, JD들이 말해주는 변화의 방향은?

이 공고들을 나란히 놓으면 하나의 흐름이 보입니다.

PM 쪽에서는 "전통적 PM → Product Builder"라는 하나의 큰 방향이 보였습니다. 디자이너 쪽은 어떨까요?

처음에는 디자이너 역할이 여러 갈래로 분화되고 있다고 생각했습니다. 하지만 공고들을 하나씩 뜯어보니, 오히려 반대였습니다. 수렴하고 있습니다.

이 흐름은 해외 JD에서만 읽히는 게 아닙니다. 토스는 올해 4월, 기존 6개였던 디자인 직무(Product Designer, Tools Product Designer, Platform Designer, Interaction Designer, Graphic Designer, Brand Designer)를 프로덕트 디자이너와 비주얼 디자이너, 2개로 통합했습니다.

토스가 밝힌 이유는 명확합니다. AI 등 기술 발전으로 도구 습득 시간이 줄면서 디자이너들이 이미 전문 영역을 넘나들고 있었고, "어떤 도구를 다루느냐", "어떤 화면을 만드느냐"로 직군을 나누는 것이 현실과 맞지 않게 되었다는 것입니다. 결국 중요해진 건 "좋은 경험을 판단하는 감각"이었어요.

정리하면, 디자이너의 직군은 수렴하되 역할은 확장되고 있습니다. 프로덕트 디자이너는 기획 쪽으로, 비주얼 디자이너는 시스템·엔지니어링 쪽으로. "손에서 판단으로"의 '판단'이 시각적 판단에 그치는 게 아니라, "이 문제를 풀어야 하는가", "이 방향이 맞는가"라는 제품 판단까지 포함되는 시대가 되고 있는 겁니다.

그리고 어쩌면 이 흐름의 끝에는 PM, 디자이너, 엔지니어라는 직군의 경계 자체가 무의미해지는 시점이 올 수도 있습니다. 모두가 빌더로서 문제를 정의하고, 설계하고, 직접 만드는 시대. 지금의 JD 변화는 그 방향으로 가는 과정의 한 단면일 수 있습니다.

지금 시작해볼 수 있는 세 가지

이 공고들을 "지금 당장 되어야 하는 기준"으로 읽을 필요는 없습니다. 디자이너의 역할이 어디를 향해 가고 있는지를 보여주는 흐름일 뿐입니다.

2호에서 디자이너의 역할이 '손에서 판단으로' 이동할 것이라고 이야기한 적이 있습니다. 그때의 예측이 지금 채용 시장에서 실제로 나타나고 있습니다. 그 방향으로 가보는 첫 발은 세 가지면 충분합니다.

① AI 도구로 직접 만들어본 경험 한 가지 

대부분의 JD에 공통으로 들어간 내용은 "프로토타입 직접 빌드"입니다. 완성도가 아니라 방향이 중요합니다. 본인 업무의 불편한 점 하나를 AI로 실제로 해결해보는 것, 작은 것부터 시작하면 됩니다. Claude Design으로 화면을 만들어보거나, v0로 컴포넌트를 생성해보거나, Cursor로 인터랙션을 구현해보는 것도 좋습니다. 회사에서 망분리나 보안 이슈로 이런 도구를 쓰기 어렵더라도, 퇴근 후 개인 프로젝트 하나로 충분합니다.

② 디자인 시스템을 "AI가 읽을 수 있는 언어"로의 정리해본 경험

시맨틱한 네이밍, 토큰 구조화, DESIGN_SYSTEM.md 작성 등, 개인 프로젝트에서도 디자인시스템과 AI를 활용한 디자인 자동화 역시 시도해볼 수 있습니다. Figma의 Variables를 JSON으로 변환하고, 그걸 Claude Code에 적용해보는 것만으로도 시작이 됩니다. 사실 이건 외부 AI 도구 접근이 어려운 환경에서도 할 수 있는 일입니다. 지금 쓰고 있는 디자인 시스템의 네이밍을 Btn → Button, Pri → Primary로 바꾸고, 토큰에 시맨틱한 역할을 부여하는 것부터 시잘해보아요.

③ AI 산출물에 대해 "왜 이걸 골랐는지" 설명할 수 있는 판단의 언어

AI가 만든 시안 10개 중 왜 이걸 선택했는지를 설명할 수 있어야 합니다. "예쁘니까"가 아니라, 어떤 사용자 문제를 해결하는지, 왜 이 구조가 더 적합한지, 비즈니스 목표와 어떻게 연결되는지를 말할 수 있는 것. AI가 평균 이상의 결과물을 빠르게 만들어내는 시대에, "내가 더 예쁘게 만들 수 있다"는 논리는 설득력을 얻기 쉽지 않습니다. 대신 "이것이 왜 맞는 선택인지" 판단하고 설명하는 능력이 디자이너의 새로운 핵심 역량이 됩니다.

변화의 방향이 보이기 시작했다면, 이미 첫 발은 이미 내딛은 거예요. 🙂

📮 다음 호 예고

[31호] 기획·디자인 의도를 개발의 언어로 옮기기

“PG사마다 오류 메시지가 다르니 중간에서 통일해달라.” 요청을 받았습니다. AI에게 몇 달치 실패 로그를 넘겼더니 유형 분류에 우선순위까지 정리해줬고, 저는 이제 기획만 하면 되겠다고 생각했어요. 그런데 개발 검토 자리에서 개발자가 문서를 읽다가 이렇게 묻더라고요. “어? 플랫폼에서 왠지 분기하는 로직이 있을 것 같은데요.” 확인해보러 갔다가 알았습니다. 제가 볼 수 없는 코드가 있었다는 걸요. 그 한 문장이 기획을 어떻게 바꿨는지 이야기해봅니다.

✉️ 다음 호가 궁금하신 분들은 아래 [구독하기] 버튼을 눌러주세요.