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

• 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를 배포
• 팀에 이 방식을 가르치고 있으며, 직업이 사라지기 때문이 아니라 취향, 판단력, 작업 지휘 능력이 그림을 그리는 능력보다 중요한 직업으로 변하고 있기 때문