프로덕트 디자인이 변하고 있다

코멘트

Figma는 최근 벡터를 자동 생성하는 도구, 이미지 빈 영역을 생성형 AI로 채우거나 배경을 제거하는 기능 등 Adobe와 유사한 방향으로 기능을 확장하고 있다. 컴포넌트의 페이지 요소를 관리하는 Slot도 3월 베타 출시 예정이다. Figma 역시 코드에서 디자인으로의 연결을 본격적으로 이야기하기 시작했다.

전통적으로 인터랙션, 비주얼, 모션 같은 UX 디자인 유형은 캐스케이딩 방식—순차적으로 단계를 거치며—진행되었다. 지금은 이 과정이 동시에 이루어지고, 반복적으로 파인 튜닝하는 흐름으로 바뀌고 있다.

![[1 Jobs in the field of user experience#UX 디자인의 유형]]

요약

• AI 도구가 디자인 시스템을 직접 활용해 UI를 생성하면서, 디자이너의 역할이 단순 시각 설계에서 전략과 오케스트레이션 중심으로 이동
• Figma 목업을 코드로 번역하는 핸드오프 과정이 가장 큰 병목이었으나, 디자이너가 코드 환경에서 직접 디자인하면 이 낭비를 완전히 제거 가능
• 소규모 임파워드 팀과 머신 리더블 디자인 시스템에 투자하는 기업이 대규모 피처 팩토리 조직을 압도할 것이며, “AI를 오케스트레이션하는 디자이너”와 “픽셀을 미는 디자이너” 간 격차가 12개월 내 급격히 벌어질 전망

본문

• AI 도구가 디자인 시스템을 직접 활용해 UI를 생성하면서, 디자이너의 역할이 단순 시각 설계에서 전략과 조율 중심으로 이동
• 이제 “누가 누구의 일을 뺏나” 가 아니라, 프로세스가 어떻게 바뀌나가 핵심 질문
• 코드·PRD·요약 같은 보이지 않는 작업은 자동화가 쉬우나, 사용자가 직접 보고 만지는 UI·플로우 같은 보이는 작업은 품질 격차가 커서 디자인 자동화 속도는 아직 엔지니어링을 따라가지 못함
• Figma 목업을 코드로 번역하는 과정이 가장 큰 병목이었으나, 디자이너가 코드 환경에서 직접 디자인하면 이 핸드오프 낭비를 완전히 제거 가능
• AI 시대 디자이너의 핵심 가치는 픽셀 작업이 아니라 오케스트레이션 능력 : 무엇을 만들지 판단하고, AI 출력을 비판적으로 평가하며, 작업을 지휘하는 역량
• 소규모 임파워드 팀과 머신 리더블 디자인 시스템에 투자하는 기업이, 대규모 피처 팩토리 조직을 압도하게 될 것

제품 디자인의 변화 배경

• 1999년 Dreamweaver로 첫 웹사이트를 제작한 이후, 저자는 Photoshop·Sketch·Figma 등으로 디자인하고 개발자에게 전달하는 방식으로 일해 왔음
• 최근 Claude Code를 자사 디자인 시스템에 연결해 세 번의 프롬프트만으로 실제 작동하는 UI를 생성, 기존의 시각 설계 단계를 건너뜀
• 이 경험을 통해 디자이너의 가치가 실행 능력에서 ‘취향과 전략적 판단’으로 이동하고 있음을 확인
• AI가 디자인 시스템을 기반으로 ‘프롬프트 → 생성 → 배포’ 흐름을 구현하면서, 제품 디자인의 근본적 변화가 진행 중임

잘못된 논쟁: 인원 수가 아닌 프로세스의 변화

• AI와 프로덕트 직무에 대한 현재 담론은 “디자이너가 일자리를 잃을 것인가”, “엔지니어가 대체될 것인가” 같은 인원 수 중심의 영역 다툼에 머물러 있음
• 진짜 질문은 프로세스에 관한 것으로, AI가 이런 기능들을 없애는 게 아니라 누가, 얼마나 빠르게 수행하고, 병목이 어디로 이동하는지가 핵심
• 코딩, PRD 작성, 데이터 분석 같은 보이지 않는 작업(invisible work)은 UI 뒤에 품질 격차가 숨겨지므로 자동화가 용이
  • 코드가 지저분해도 앱이 작동하면 아무도 신경 쓰지 않고, PRD가 AI로 생성되어도 문제 정의가 올바르면 상관없음
• 반면 사용자 인터페이스, 플로우, 경험 같은 보이는 작업(visible work)은 품질 격차가 즉시 드러나며 사용자가 바로 인지함
• 빌드가 빠르고 저렴해지면 “어떻게 만들 것인가”가 아니라 “무엇이 만들 가치가 있는가” 가 가장 어려운 문제가 됨
• AI 지원 디자인의 속도 향상은 엔지니어링에 비해 뒤처질 수밖에 없으며, 이 비대칭성이 전체 프로덕트 개발 프로세스와 팀 구성 방식을 재편할 것

보이는 작업: 디자인은 벽 뒤가 아닌 벽 자체

• 엔지니어링은 배관에 비유 가능 — 벽 뒤에 숨어 있고, 수도꼭지에서 물이 나오면 내부 구조는 중요하지 않음
  • Boris Cherny는 4~5개의 코딩 에이전트를 동시에 운영하며 400% 이상의 속도 향상을 달성, Silicon Valley 엔지니어들이 코드를 직접 작성하기보다 에이전트 팀을 오케스트레이션하는 방식으로 전환 중
• 소프트웨어 디자인은 벽 자체이자 수도꼭지이자 손잡이이므로, AI가 만들었더라도 사용자는 외형과 사용감에 민감하게 반응
• AI는 학습 데이터에 있는 표준과 패턴은 따를 수 있지만, 수십 건의 사용자 인터뷰, 설문 결과, 사용 분석, 경쟁 감사 등 방대한 사용자 리서치 기반의 의사결정은 컨텍스트가 너무 커서 처리하기 어려움
• 수용 문제(ingestion problem)라는 병목 존재 — AI가 방대한 코드나 회의 요약을 생성해도, 인간이 이를 읽고 내재화하고 비판적으로 평가해야 지적인 대화와 판단이 가능
  • 코드 리뷰가 실질적 병목이 되고 있으며, 이는 인간 속도의 제약으로 어떤 모델도 우회 불가
• AI는 콘텐츠 생성과 요약에 뛰어나지만, 새로운 것을 창조하거나 취향(taste)을 갖는 역량은 아직 입증되지 않음

Figma가 아닌 코드에서 디자인하기

• 프로덕트 개발의 가장 큰 병목은 Figma 목업을 프로덕션 코드로 번역하는 디자이너-개발자 핸드오프 과정
  • 소프트웨어의 그림을 그리고, 픽셀을 다듬고, 엔지니어에게 넘기면, QA가 목업 대비 코드를 확인하며, 타이포그래피나 간격 불일치로 PR을 반려하는 엄청난 비효율이 존재
• AI는 이 병목을 해소하지만, 디자이너가 코드 환경에서 직접 디자인할 때만 가능
• 일부 디자이너들이 Figma 구독을 실제로 해지하고 AI 도구로 전환 중이며, 목업은 제품이 아닌 번역·검토·조정이 필요한 병렬 산출물이라는 점이 핵심 논거
  • Figma에서 밀어내는 모든 픽셀은 엔지니어가 완전히 다른 매체에서 지켜야 할 약속이며, 디자인 도구가 프로덕션 코드에서 멀수록 핸드오프에서 발생하는 낭비가 증가
• Claude Code로 디자인 시스템 레포를 가리켜 세 번의 프롬프트로 작동하는 UI를 생성한 실험이 이를 확인
  • 규모 있는 신뢰성을 위해서는 견고한 문서화, 명시적 규칙, 에이전트 오케스트레이션이 필요하지만 기반은 이미 마련됨
• Monday.com 엔지니어링 팀의 사례: Figma 링크를 Cursor에 붙여넣는 첫 시도에서 생성된 코드가 디자인 시스템 컴포넌트를 사용하지 않고, 색상이 하드코딩되고, 타이포그래피가 시스템 기본값을 덮어쓰는 문제 발생
  • 해결책으로 디자인 시스템 MCP(Model Context Protocol)를 구축 — 컴포넌트, 토큰, 접근성 규칙, 사용 패턴을 머신 리더블하게 만들고, 11개 노드의 에이전틱 워크플로우로 모델에 구조화된 컨텍스트를 구성
  • 에이전트가 코드를 직접 작성하는 것이 아니라 코드가 어때야 하는지에 대한 이해를 구축한 뒤 개발자의 코딩 에이전트에 넘기는 “오케스트레이션, 마법이 아닌” 접근
• Anthropic의 디자이너가 Claude Code와 콘솔 제품에 직접 풀 리퀘스트를 제출하고 프로덕션에 배포 중 — 2026년 2월 현재 이미 현실

인간에게 남는 것: 오케스트레이션과 판단

• AI가 코드 생성, PRD 작성, 리서치 요약, 인터페이스 프로토타이핑을 모두 수행할 수 있다면, 인간에게 남는 것은 오케스트레이션
  • 모델은 충분히 유능하며, 병목은 키보드 앞의 사람 — 무엇을 요청할지, 작업을 어떻게 분할할지, 모델의 결과를 언제 거부할지를 아는 능력이 핵심
• Kyle Zantos는 업무 시간의 70%를 터미널에서 보내는 디자이너로, 4개월 전 추천도 이미 구식이 되므로 구체적 도구 설정보다 철학과 접근법을 배우는 것이 중요하다고 강조
• SAP의 Chief Design Officer Arin Bhowmick: 시각적으로 세련된 인터페이스가 신뢰할 수 없는 출력, 불투명한 의사결정, 엣지 케이스의 취약한 동작 같은 심층 문제를 가릴 수 있음
  • 디자인 리더는 표면적 품질이 아닌 신뢰, 명확성, 신뢰성을 일급 디자인 결과물로 다뤄야 함
• Vlad Derdeicea에 따르면 디자인 리드의 약 80%의 시간이 커뮤니케이션, 정렬, 정당화에 소비되며, 실제 핸즈온 디자인 작업에는 20%만 사용
  • 모든 디자인 결정에는 “정당화 세금(justification tax)” — 다른 분야에서는 짧은 대화로 처리할 선택을 설명하고 문서화하고 방어하는 데 드는 시간 — 이 존재
  • AI는 목업 작업이 아닌 이 80%를 타겟해야 함: 회의록 종합, 이해관계자 커뮤니케이션 초안, 리서치 요약, 의견 대신 데이터로 논쟁을 해결할 빠른 프로토타입
• Jan Tegze의 프레이밍: 현재 업무를 더 잘하려 하지 말고, 인간의 한계 때문에 존재하는 도메인의 제약을 찾아서 에이전트로 제거할 것 — 현재 작업을 가속하는 것이 아니라 이전에 불가능했던 것을 수행하는 방향
  • “에이전트와 경쟁하는 것이 아니라, 자신과 에이전트 모두를 필요로 하는 새로운 역량을 창출하는 것”
• 경력 5년 이하의 주니어 디자이너가 더 큰 위험에 처해 있음 — AI 출력을 평가할 판단력과 모델의 오류를 감지할 경험이 부족하기 때문이며, 스킬 플로어가 상승 중

소규모 팀, 큰 레버리지

• 대부분의 소프트웨어 기업이 현재 상황에 맞지 않는 구조 — 전담 디자인 지원 여부와 관계없이 각 스쿼드에 PM을 배치하는 PM 과잉 피처 팩토리
  • PM이 ZIRP 시대에 급증한 이유는 매출에 가깝고 조직 복잡성에 따라 인원이 확대되기 때문
  • Marty Cagan은 이를 “프로덕트 매니지먼트 극장” 이라 부름 — 로드맵을 만들고 스탠드업을 진행하는 과잉 급여 프로젝트 매니저와 다름없는 비효과적 PM의 과잉
• Andrew Ng는 다보스에서 AI가 엔지니어링 생산성을 폭발시키면 PM 대 엔지니어 비율이 1:8에서 1:1 방향으로 뒤집힐 것으로 예측
  • AI 에이전트가 대부분의 프로덕션 코드를 작성하면 넓은 엔지니어링 베이스가 축소되고, 명세와 판단이 희소 자원이 됨
• Airbnb는 프로덕트 매니지먼트와 프로덕트 마케팅을 하나의 “풀스택” 역할로 통합
  • Brian Chesky: “제품에 대해 이야기하는 방법을 모르면 제품을 개발할 수 없다” — 스토리텔링과 대외 커뮤니케이션을 PM 직무의 일급 요소로 격상
  • 디자이너를 엔지니어와 함께 제품을 이끄는 “아키텍트” 로 격상, 티켓을 받아 처리하는 하위 서비스가 아닌 역할
  • 기존 PM 인원을 부풀리던 조정 업무는 전담 프로그램 매니저에게 이관
• Apple의 기능 조직 모델과 유사: 전문가가 전문가를 리드하고, CEO가 통합 포인트이며, 사업부를 운영하는 “미니 CEO” 역할의 PM이 없음
• AI 시대 이상적 팀은 엔지니어 2~3명, PM 1명, 디자이너 1명의 소규모 임파워드 팀
  • 디자인 시스템이 핵심 인프라가 되며, 코드 내 디자인 시스템과 문서화 없이는 AI가 UI와 구현에 대해 잘못된 결정을 내림
  • 머신 리더블 디자인 시스템과 소규모 임파워드 팀에 투자하는 기업이, 15명 스쿼드와 3단계 승인을 유지하는 기업을 압도할 것

복리 효과: 오케스트레이터와 픽셀 푸셔의 격차

• Claude Code로 디자인 시스템에서 작동하는 화면을 생성한 실험 이후, 더 나은 문서화, 엄격한 컴포넌트 규칙, 명확한 조합 지침으로 지속적 개선 중
  • 매 라운드마다 더 빨라지고 프로덕션 레디에 가까워지며, 모델 향상·스킬 정제·지휘 능력 향상이 모두 복리로 축적
• “AI를 오케스트레이션하는 디자이너” 와 “Figma에서 픽셀을 미는 디자이너” 간의 격차가 12개월 내 막대해질 전망
  • 픽셀 푸셔가 역량이 부족해서가 아니라, 오케스트레이터가 근본적으로 다른 속도와 범위에서 작동하기 때문 — 다른 이들이 핸드오프 미팅용 목업을 내보내는 동안 작동하는 UI를 배포
• 팀에 이 방식을 가르치고 있으며, 직업이 사라지기 때문이 아니라 취향, 판단력, 작업 지휘 능력이 그림을 그리는 능력보다 중요한 직업으로 변하고 있기 때문