정의
AI를 디자인 병목 해소 도구로 도입해 시안·UT·정책 커뮤니케이션을 자동화한 뒤에도 여전히 사람이 감당해야 하는 미해결 병목 3가지. 오늘의집 프로덕트 디자이너 Gongdee가 병목 중심 워크플로우를 실무에 반복 적용한 뒤 정리한 한계 목록이다.
핵심 속성
- ODS 자동 적용의 한계: AI 결과물에 디자인시스템(ODS) 컴포넌트가 자동으로 입혀지지 않음. 핸드오프용 컴포넌트 교체·디테일 마감은 여전히 디자이너의 몫
- 프롬프트 의존성: Figma Make든 Claude Code든 결과물 퀄리티가 프롬프트 작성 능력에 좌우되며, 그 기반은 디자이너의 도메인 이해도
- 두 벌 관리(이중 소스): 피그마 파일과 AI 프로토타입이 별도로 존재해, 디자인 수정 시 양쪽을 모두 갱신해야 하는 동기화 비용 발생
- 전제 조건: 이 한계들은 “디자인시스템이 코드 기반으로 구축되어 있지 않은 환경”이라는 조건에서 도출됨 — 코드 기반 DS가 있으면 상당 부분 해소 가능한 구조적 병목
- 능력 격차: AI가 컴포넌트를 ‘불러오는 것’과 맥락에 맞게 ‘배치하는 것’은 별개의 능력 — 후자가 미해결 영역
관계
- 20260512-bottleneck-driven-ai-design-workflow — 연장 (해당 워크플로우의 미해결 잔여 병목 목록)
- 20260623-code-based-design-system-caps-ai-design-automation — 하위개념 (근본 원인 진단)
- 20260623-designer-domain-knowledge-determines-prompt-quality — 하위개념 (프롬프트 의존성의 함의)
- 20260512-figma-make — 대조 (도구 자체의 한계 맥락)
- 20260606-claude-code — 대조 (도구 자체의 한계 맥락)
인용
“AI 결과물에 ODS 컴포넌트가 자동으로 입혀지진 않아요. 핸드오프를 위해 컴포넌트를 교체하고 디테일을 잡는 건 여전히 디자이너의 몫입니다.”
“디자인시스템이 코드 기반으로 구축되어 있지 않은 환경에서는, AI가 디자인을 완성해 주길 기대하기보다 디자이너의 판단을 더 빠르게 검증하는 도구로 쓸 때 가장 잘 맞았어요.”
출처
- 📎 클리핑: 20260623-ai