AI 부정성 설명
Explain AI Negativity
배경 및 소개
최근 PM들이 Claude 같은 AI로 화면을 뚝딱 만들어 MVP 검증에 쓰려는 시도가 늘고 있는데요. 이에 대해 UX 실무자들은 design system을 깨뜨리거나 팀 프로세스를 건너뛰는 관행에 문제를 제기하고 있습니다. 게시글의 PM은 “모든 시안이 design system의 폰트·컬러·토큰을 꼭 지켜야 하느냐”, “개발도 system 밖 구현이 가능한가”, “이왕이면 AI 시안도 사용자에게 같이 피칭해보자”는 질문을 던졌는데요. 한편 커뮤니티는 “AI 자체가 아니라, UX 판단과 일관성, 장기 유지보수 가능성을 무시하는 태도”를 우려했습니다. 결국 이 논의는 AI 시대에 디자인 소유권과 역할 경계가 어떻게 재정의되어야 하는지, 그리고 MVP 단계의 속도와 조직 차원의 품질 거버넌스 사이 균형을 어떻게 잡을지에 관한 문제라고 볼 수 있습니다. 이는 AI로 인한 개발·디자인 워크플로 재편이 현실화되는 지금, 팀 간 신뢰와 규칙을 다시 세팅해야 한다는 점에서 의미가 있습니다.
주요 내용
원글의 핵심은 간단합니다. MVP를 빨리 만들 목적이라면 AI가 만든 디자인도 충분히 후보가 될 수 있는데요. 이해관계자가 좋아하고 PM이 같은 기준으로 검토했다면, 왜 굳이 버리느냐는 주장입니다. 더 나아가 AI 산출물과 UX 실무자의 산출물을 나란히 테스트해 ‘AI slop’이 실제로 있는지 확인하자는 제안도 있습니다. 이에 대한 상위 댓글들은 방향이 달랐습니다. 문제는 AI 사용 그 자체가 아니라, PM이 디자인팀을 우회해 독자적으로 의사결정을 내리고, UX의 가치와 design system의 중요성을 깎아내리며, “디자인은 예쁜 UI”라는 오해로 비현실적 마감일을 밀어붙이는 태도라는 지적인데요. 또한 AI prototype이 보기엔 그럴듯해도 깨진 pattern을 프로덕션에 밀어 넣는 위험을 경고했습니다. 스타트업 초기에 리소스가 턱없이 부족하다면 AI에 기대는 게 실용적일 수 있는데요. 다만 조직에 design system과 팀이 이미 자리 잡았다면, AI 열풍을 이유로 best practice를 건너뛰면 안 된다는 의견이 힘을 얻습니다. 개발에서 best practice를 무시하지 않듯, 디자인에서도 동일한 원칙이 적용된다는 비유가 설득력을 줍니다. ‘PM이 design approver’라는 표현에 거부감이 있다는 댓글도 나왔는데요. 권한 구조가 한쪽으로 기울수록 “디자인을 생략해도 된다”는 신호로 읽히기 쉽다는 문제의식입니다. 핵심 반론은 일관성과 장기 사용성입니다. design system은 규모가 커질수록 제품이 난장판이 되지 않게 붙잡아 주는 장치인데요. AI 산출물은 아이디어 발화나 MVP 초안으론 유용하지만, alignment 없이 가면 나중에 해결할 문제를 더 키울 수 있다는 지적입니다. 흥미로운 사례도 공유되었는데요. PM과 이해관계자가 Claude로 만든 UI를 UX 없이 빠르게 POC로 검증했더니, 메인 타깃이 아닌 세그먼트에선 꽤 잘 작동했습니다. 팀은 이를 “실험”으로 명시하고 프로덕션으로 밀지 않았으며, 초기 데이터 이후 UX를 합류시켜 검증과 정제를 진행했다는군요. 이 경험은 AI 주도 탐색이 역할과 책임이 명확할 때 효과적일 수 있음을 보여줍니다. 종합하면, 가장 좋은 경로는 AI를 빠른 아이디어 탐색에 쓰고, 실제로 빌드할 땐 UX가 문제정의, 행동 이해, edge case, accessibility, system consistency를 책임지는 구조인데요. 개인적으로는 프로덕션에서는 design system 준수가 기본이고, 실험 단계에서의 이탈은 명시적 허용 범위와 되돌림 계획을 갖춘 ‘관리된 일탈’이어야 한다고 봅니다. 그 사이를 잇는 방법으로는 dual-track discovery 운영, heuristic review·accessibility 체크·consistency 리뷰 같은 경량 게이트, design token 기반의 조화 전략, 실험을 timebox하고 retrofit 비용을 추적하는 거버넌스가 유효한데요. 이는 속도를 유지하면서도 장기 유지보수성과 브랜드 일관성을 지키는 현실적 타협이라고 생각합니다.
결론 및 시사점
이 토론의 결론은 “AI 금지”가 아니라 “프로세스와 장기 품질을 해치지 않는 방식의 AI 활용”인데요. MVP 맥락에서 AI 시안을 쓰는 건 충분히 타당하지만, 그것이 실험임을 명확히 하고, 역할과 책임, review 게이트, design system과의 정합 계획이 함께 가야 합니다. 반대로 설계팀을 병목으로 낙인찍거나 PM이 독단적으로 ‘승인자’로 군림하면, 단기 속도는 얻어도 유지보수 비용과 사용자 경험의 분절이라는 더 큰 대가를 치르게 됩니다. 특히 AI가 만든 그럴듯한 화면은 affordance나 accessibility, edge case를 가리기 쉬운데요. 이는 나중에 usability testing에서 드러나거나 프로덕션에서 장애로 증폭될 수 있다는 점에서 위험합니다. 개인적으로는 “실험은 빠르게, 출시는 일관되게”라는 원칙이 유효하다고 보는데요. AI 탐색 결과가 유의미하면, design system을 업데이트하거나 컴포넌트화를 통해 시스템 안으로 흡수하는 루트까지 포함해야 선순환이 됩니다. 장점은 속도와 학습이고, 한계는 거버넌스 부재 시 품질 하락과 조직 신뢰 악화입니다. 결국 AI와 UX의 협업을 운영모델로 제도화하는 팀이 장기적으로 제품 경쟁력을 지킬 가능성이 높다는 점에서 이번 논의는 의미가 있습니다.
💡 AI로 아이데이션과 빠른 POC를 하되, 프로덕션에는 design system 준수와 UX review·accessibility 체크·일관성 검토·debt 로깅 같은 경량 게이트를 의무화하는 운영 규칙을 두는 것이 좋습니다. 실험 단계의 이탈은 명시하고, 이후 시스템 내 흡수 계획까지 세팅하면 속도와 품질을 동시에 확보할 수 있습니다.
뉴스레터 구독
매주 금요일, 주간 HCI 하이라이트를 이메일로 받아보세요.