The product owner uses AI for designing flows, 그리고 그의 말은 다음과 같았다: “That took me one evening, what took you a month to make”
The product owner uses AI for designing flows, and his statement was: “That took me one evening, what took you a month to make”
HCI Today가 핵심 내용을 정리했어요
- •이 글은 Claude 같은 AI 도구로 만든 화면이 기존 디자인 시스템과 맞지 않아 팀과 제품 책임자 사이에 갈등이 생긴 사례에 대한 글입니다.
- •작성자는 폰트, 색상, 변수, UI 키트가 갖춰진 디자인 시스템이 있는데도 Claude가 이를 무시하고 임의의 디자인만 생성한다고 지적합니다.
- •개발자들은 이를 수정하는 것보다 처음부터 다시 만드는 편이 더 빠르다고 보고, 제품 책임자는 AI가 한 번 저녁이면 가능하다며 같은 생산성을 요구합니다.
- •커뮤니티는 AI 사용 원칙과 역할 분담, 디자인 전략을 명확히 하고, 개발·디자인·관리 측면에서 근거를 수치로 보여주라고 조언합니다.
- •전체적으로 이 문제는 AI 활용 자체보다 조직의 기준 부재와 책임 불분명에서 비롯된 갈등이며, 경력 관리까지 고민해야 한다는 시사점을 줍니다.
HCI 전문가들의 생각을 바탕으로 AI 에디터가 생성한 요약입니다.
HCI 관점에서 읽을 만한 이유
이 글은 HCI와 UX 실무에서 AI 도구가 ‘생성 능력’만으로는 제품 품질을 보장하지 못한다는 점을 잘 보여줍니다. 특히 디자인 시스템, 구현 라이브러리, 조직 내 역할 분담이 어긋날 때 어떤 마찰이 생기는지 드러내는데요. 단순히 도구 사용법의 문제가 아니라, 사람-도구-조직의 정렬(alignment) 문제로 읽을 수 있어서 실무자와 연구자 모두에게 의미가 있습니다.
CIT의 코멘트
CIT 관점에서는 이 사례를 ‘Claude가 못한다’로 끝내기보다, AI가 조직의 설계 원칙을 대신 이해해주지 못하는 상황으로 봅니다. 생성형 AI는 빠른 초안을 만들 수 있지만, 디자인 시스템의 일관성, 컴포넌트 재사용 규칙, 구현 가능성 같은 맥락을 스스로 책임지지는 못하는데요. 그래서 문제의 핵심은 모델 성능보다도 사용 범위와 책임 경계의 정의입니다. HCI적으로는 AI를 개인 생산성 도구로 둘지, 협업 워크플로의 일부로 둘지에 따라 평가 기준이 완전히 달라집니다. 결국 필요한 것은 더 강한 모델보다도, 디자인 리더십과 운영 규칙, 그리고 개발·디자인·제품 간 의사결정 구조입니다.
원문을 읽으면서 던질만한 질문
- Q.AI가 디자인 시스템을 참고해도 결과가 일관되지 않는다면, 어떤 맥락 정보와 제약 조건을 함께 제공해야 실무적으로 유효한가요?
- Q.생성형 AI를 제품 팀의 일부로 도입할 때, 디자인 품질과 협업 책임을 어떻게 측정하고 합의해야 할까요?
- Q.제품 오너가 속도만 기준으로 판단할 때, HCI/UX 팀은 어떤 근거와 지표로 의사결정 구조를 설계해야 하나요?
HCI 전문가들의 생각을 바탕으로 AI 에디터가 생성한 코멘터리입니다.
정확한 내용은 반드시 원문을 참고해주세요.
뉴스레터 구독
매주 금요일, 주간 HCI 하이라이트를 이메일로 받아보세요.