# 프로덕트 디자인이 변하고 있다 > Clean Markdown view of GeekNews topic #27120. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27120](https://news.hada.io/topic?id=27120) - GeekNews Markdown: [https://news.hada.io/topic/27120.md](https://news.hada.io/topic/27120.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-03-02T12:47:29+09:00 - Updated: 2026-03-02T12:47:29+09:00 - Original source: [rogerwong.me](https://rogerwong.me/2026/02/product-design-is-changing) - Points: 30 - Comments: 0 ## Summary AI가 **디자인 시스템을 직접 활용해 UI를 생성**하면서, 디자이너의 역할이 시각적 산출보다 **전략과 오케스트레이션** 중심으로 이동하고 있습니다. 자동화가 빠르게 확산되는 가운데, 진짜 변화는 인력 축소가 아니라 **프로세스 재편**에 있으며, 디자이너가 코드 환경에서 직접 디자인하면 핸드오프 낭비가 사라집니다. 이제 경쟁력의 핵심은 픽셀 정교함이 아니라, 무엇을 만들지 판단하고 AI 출력을 비판적으로 조율하는 능력에 있습니다. ## Topic Body - **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를 배포 - 팀에 이 방식을 가르치고 있으며, 직업이 사라지기 때문이 아니라 **취향, 판단력, 작업 지휘 능력**이 그림을 그리는 능력보다 중요한 직업으로 변하고 있기 때문 ## Comments _No public comments on this page._