product owner가 AI로 flows를 설계하며 한 말: "그건 나에겐 저녁 한 번이면 됐는데, 너는 한 달이나 걸려 만들었네"
The product owner uses AI for designing flows, and his statement was: “That took me one evening, what took you a month to make”
배경 및 소개
제품팀이 Figma의 design system과 developer library를 갖춘 상태에서 Claude 같은 AI로 이른바 vibe coding을 시도하면서 갈등이 불거졌다. 3명의 디자이너가 있는 팀에서 product owner는 AI가 하룻밤이면 화면을 만들 수 있으니 같은 생산성을 요구한다. 그러나 개발자들은 Claude가 뽑는 코드와 화면이 기존 library와 맞지 않아 차라리 처음부터 만드는 편이 낫다고 판단한다. 실제로 design tokens, 폰트, 컬러, UI kits를 명확히 정의하고 컴포넌트까지 제공했음에도, Claude는 이를 일관되게 따르지 못하고 임의 배치에 가까운 산출물을 낸다. 이 문제는 특정 팀만의 해프닝이 아니라, AI 도입 기대치와 실제 품질·재사용성 사이의 격차가 조직 안에서 어떻게 관리되어야 하는지라는 더 큰 맥락을 드러낸다. 커뮤니티 논의는 역할·책임, AI 활용 원칙, 디자인 리더십 부재가 이 충돌을 키운다고 지적하며, 기획·개발·디자인 간의 기준선과 검증 방식이 합의되지 않은 상태에서 LLM 기반 자동화가 오히려 재작업과 불신을 초래한다고 요약한다.
주요 내용
원글은 design system이 완비된 환경에서도 Claude가 해당 규칙을 무시한 채 랜덤한 화면과 코드, 즉 vibe code를 산출해 개발자들이 수용하지 못하는 상황을 묘사한다. 컴포넌트와 가이드를 공급해도 LLM이 구조적 제약을 안정적으로 준수하지 못했고, 결과물은 junior급 산출물처럼 논리 없이 프레임이 흩어져 있었다. 그럼에도 product owner는 AI의 속도를 근거로 같은 생산성을 요구하며, Figma 상의 UI kits와 developer library가 정렬된 기존 워크플로우 자체를 재고하려 든다. 이에 대한 커뮤니티의 공통 응답은 기술 문제가 아니라 조직 문제라는 진단이다. 누가 무엇을 책임지고, AI를 어디까지 어떤 품질 기준으로 쓸지, 그리고 디자인 전략을 누가 리드하는지 합의가 필요하다는 것이다. 일부는 즉각적인 커리어 리스크 관리까지 권고하며, 리더십이 근거 없이 속도만 추구하면 실무자와 개발자 모두 소모된다고 비판한다. 동시에 '측정'을 통해 논쟁을 종결하라는 실무적 조언이 제시된다. 사용자가 달성하려는 과업을 정의하고 usability testing으로 time on task, task success rate를 수집하고, 각 과업 뒤에 SEQ를 실시하며, 마지막에 SUS를 시행해 68 이상을 목표로 벤치마크하라는 것이다. 이렇게 정량 지표를 걸면 AI 생성안과 기존 프로세스의 품질 차이가 드러나며, 리더의 주장도 검증 가능해진다. 또 하나의 현실적 접근은 개발자에게 두 경로, 즉 product owner가 말하는 하룻밤짜리 플로우와 팀의 표준 플로우 각각의 구현 시간을 독립적으로 산정시키는 것이다. 이 비교는 재작업 비용과 라이브러리 정합성 문제를 수치로 드러낸다. 결과 미스얼라인을 문서화해 CYA하는 조언, 실제로 실패를 겪게 두어 학습하게 하라는 냉소적 제안, 심지어 AI로 product owner의 PRD를 써서 동일한 잣대를 대보라는 역설적 제안도 이어진다. 요지는 AI가 만능이 아니며, design system 준수와 재사용 가능한 코드 생성은 엄격한 가드레일, 컴포넌트 매핑, 토큰 일치, 그리고 종종 추가 tooling이나 fine-tuning 없이는 안정적으로 달성하기 어렵다는 사실이다. 무작정 속도를 근거로 프로세스를 대체하면 일관성 붕괴와 개발 낭비가 커진다.
결론 및 시사점
이 사례의 본질은 LLM이 만든 산출물의 속도와 조직이 요구하는 일관성·유지보수성 사이의 간극을 누가 어떻게 관리하느냐에 있다. Claude 같은 AI는 아이디어 발산과 초기 탐색에는 유용하지만, team-specific design system과 developer library를 엄격히 준수하는 생산 단계에는 한계가 두드러진다. 따라서 역할·책임, AI 사용 원칙, 품질 게이트를 명문화하고, design tokens와 컴포넌트 레벨의 제약을 모델과 툴체인에 체계적으로 주입하지 않으면, dev rework가 누적되어 총비용이 증가한다. 의견 대립을 해소하는 실용적 방법은 측정과 비교다. 동일한 요구사항으로 AI 생성안과 표준 플로우를 병행 평가하고, time on task, 성공률, SEQ, SUS 같은 UX 지표와 개발 소요, 버그율, 리팩터 비용을 함께 본다면, 어떤 접근이 제품과 팀에 장기적으로 유리한지 명백해진다. 동시에 리더십은 속도 서사를 절대화하기보다, 브랜드 일관성, 접근성, 유지보수성 같은 비기능 요구를 성과 정의에 포함시켜야 한다. 만약 이러한 거버넌스가 부재하고 근거 없는 압박만 지속된다면, 이는 도구의 문제가 아니라 조직의 성숙도 문제이며, 개인 차원에서는 리스크 관리와 경력 선택을 고려할 신호이기도 하다.
💡 AI는 아이데이션과 초안 생성에는 강하지만, design system 준수와 재사용 가능한 산출을 보장하려면 거버넌스, 제약 주입, 품질 게이트, 그리고 UX 지표 기반 검증이 필수다. 동일한 요구로 AI와 표준 프로세스를 병행 실험해 개발 비용과 UX 품질을 수치로 비교하면 조직적 합의를 이끌어내기 쉽다.
뉴스레터 구독
매주 금요일, 주간 HCI 하이라이트를 이메일로 받아보세요.