AI가 와이어프레임을 뽑고, 컴포넌트를 생성하고, 코드를 커밋하는 시대다. 그런데 이상한 질문 하나가 계속 걸린다. 이 결과물의 주인은 누구인가? 디자이너인가, 개발자인가, 아니면 프롬프트를 입력한 사람인가. 소유권보다 더 실용적인 질문으로 바꾸면 이렇다. AI가 개입한 결과물을 우리는 어떻게 평가하고, 어떻게 설계하고, 어떻게 측정할 것인가.
최근 세 갈래의 흐름이 동시에 이 질문을 향해 수렴하고 있다. 디자이너 시각에서 본 AI 워크플로우의 현실, 개발자 시각에서 바라본 AI 시대의 컴포넌트 전략, 그리고 코드베이스 내 AI 기여 비율을 측정하려는 엔지니어링 도구. 각각을 따로 보면 단편적이지만, 함께 놓으면 디자인 사고 → 컴포넌트 전략 → 품질 측정이라는 프론트엔드 고유의 흐름이 선명하게 드러난다.
디자이너가 체감하는 AI의 진짜 속도
모비인사이드의 "AI와 함께하는 디자이너의 하루" 아티클은 현업 디자이너가 AI 도구를 실제로 어떻게 쓰는지를 솔직하게 다룬다. 결론부터 말하면, 초안 생성 속도 ≠ 최종 결과물 속도다. Figma First Draft로 와이어프레임을 5분 만에 뽑고, ChatGPT-Figma 연동으로 플로우차트를 즉시 만들 수 있게 됐지만, 정작 실무 체감 속도는 기대만큼 폭발적이지 않다.
왜 그럴까. 빨라진 영역은 분명 존재한다. 문제 정의 단계에서 Gstack(Y Combinator의 Garry Tan이 공개한 Claude Code 스킬 기반 워크플로우)이나 Superpowers 같은 도구를 쓰면, 복잡한 요구사항을 구조화하고 "진짜 문제인가?"를 검증하는 속도가 훨씬 빨라진다. 해결안 도출 단계에서도 Figma의 이미지 생성 도구나 곧 출시될 Figma Agent가 기존 레퍼런스 수집 → 구매 → 편집의 파이프라인을 프롬프트 → 생성 → 선택 → 수정으로 압축한다.
하지만 동시에 새로운 종류의 업무가 생겨난다. AI 생성물의 일관성 검수, 브랜드 정합성 체크, 세부 수정이 여전히 필요하다. 더 근본적인 문제는 일관성이다. 동일한 프롬프트를 넣어도 실행할 때마다 다른 결과물이 나온다. 이래서는 AI 디자인 결과물을 "잘 만들어진 컨셉안" 이상으로 쓰기 어렵다. 최근 디자인 시스템 기반의 일관성 있는 생성 시도들이 주목받는 것도 이 이유다. AI가 이미지를 만들어줄 수는 있지만, 어떤 스타일이 브랜드와 맞는지, 무엇이 과한지를 판단하는 것은 여전히 디자이너의 감각이 결정한다.
컴포넌트 라이브러리가 풍자가 될 때
GeekNews에서 화제가 된 Performative-UI는 표면적으로는 패러디 라이브러리다. "AI 스타트업 랜딩페이지용 React 컴포넌트 모음"이라는 설명 아래, StatusDot(그렇지 않을 때도 항상 초록색인 상태 점), LogoMarquee(서명하지 않은 대상까지 포함해 들어본 모든 대상이 신뢰한다는 로고 마키), WaitlistForm(직접 만들어낸 수요를 담는 대기자 명단 폼) 같은 컴포넌트 27개를 MIT 라이선스로 제공한다. 각 컴포넌트 설명은 AI 스타트업 랜딩페이지의 디자인 클리셰를 짧고 날카로운 문장으로 찌른다.
그런데 Hacker News 댓글이 흥미롭다. "웃기면서도 정말 잘 만들어졌다"는 반응과 함께, "이런 기법들이 한때는 고급 프론트엔드 개발자만 할 수 있다고 여겨지던 것들"이라는 관찰이 나온다. 한 댓글은 이렇게 정리한다. "예전에는 실력의 상징이던 것이 이제 풍자의 대상이 됐다. 결국 고급 수준이란 '남들이 못 하는 것'에서 나온다." Aurora 배경, 노드 그래프 애니메이션, 토큰 스트림 UI—이것들을 구현하는 기술적 난이도는 사라지지 않았지만, AI가 이를 몇 초 만에 생성하면서 희소성의 근거가 무너졌다.
이 라이브러리가 실제로 드러내는 것은 두 가지다. 첫째, 디자인 패턴은 빠르게 클리셰가 된다. 2017~18년 ICO 붐의 노드 그래프 배경이 당시에는 신선했듯, 지금의 AI 스타트업 랜딩 문법도 곧 진부해진다. 둘째, 그럼에도 효과는 있다. 댓글 중 한 명은 "단순하고 핵심만 있는 사이트를 보여줬더니, 진지하게 받아들이지 않는다는 말을 여러 프로젝트에서 직접 들었다"고 한다. 클리셰는 클리셰인데, 전환율에서는 작동한다. 컴포넌트 전략의 딜레마가 여기 있다—진부함을 알면서도 써야 하는가, 아니면 다른 신호 체계를 설계해야 하는가.
AI가 쓴 코드, 측정하지 않으면 모른다
세 번째 흐름은 가장 엔지니어링에 가깝다. dev.to에 공개된 aigit는 "팀에게 지난 분기 프로덕션 코드의 몇 %가 AI가 작성했냐고 물어보면 침묵이 흐른다"는 관찰에서 출발한다. 배포 빈도, 레이턴시, 에러율, 테스트 커버리지는 다 측정하면서 코드 출처는 측정하지 않는다. git blame은 여전히 모든 줄을 인간이 썼다고 가정한다.
aigit는 이를 세 단계로 해결한다. 먼저 Claude Code가 로컬에 저장하는 JSONL 세션 로그에서 실제 Write/Edit 툴 호출 내용을 추출한다. 그다음 댓글 제거·공백 정규화·소문자화 처리 후 SHA-256 정확 매칭(신뢰도 1.0), TLSH 퍼지 매칭 거리 30 미만(0.9), 100 미만(0.7)의 3단계 티어로 git diff 헝크와 대조한다. 마지막으로 git blame --porcelain 출력에 AI 기여 정보를 오버레이한다. 결과는 파일별 AI 기여 비율과 aigit stats 명령으로 레포 전체 수치를 확인할 수 있다.
흥미로운 것은 제작자 본인의 도그푸딩 결과다. aigit 자체 코드베이스를 분석하니 89.8% AI 기여였다. 나머지 10.2%는 AI가 도입한 버그를 직접 수정한 줄들이었다. AI가 만든 버그를 인간이 고친 코드만 남았다—이것 자체가 측정 지표로서 의미 있다.
세 흐름이 함께 가리키는 것
세 가지 사례를 겹쳐 보면 공통된 긴장이 보인다. AI는 생성 속도를 높이지만, 평가 기준을 제공하지 않는다. 디자이너는 AI가 만든 와이어프레임의 브랜드 정합성을 여전히 눈으로 판단해야 하고, 개발자는 AI가 생성한 컴포넌트가 클리셰인지 전략인지를 맥락 안에서 결정해야 하며, 팀은 AI가 기여한 코드가 장기적으로 건강한지를 측정할 도구를 직접 만들어야 한다.
이것은 결국 판단의 자리가 어디 있는가의 문제다. AI 도구가 프로세스 전반에 개입할수록, 사람이 해야 할 일은 줄어드는 게 아니라 더 명확한 판단이 요구되는 지점으로 압축된다. 문제가 진짜 문제인지 검증하는 것, 클리셰를 의도적으로 쓸 것인지 결정하는 것, AI 코드의 품질 추세를 해석하는 것—이 세 가지는 모두 생성이 아니라 평가의 영역이다.
Performative-UI의 댓글 중 한 문장이 이 시대를 가장 잘 요약한다. "카메라가 등장한 뒤 사실주의에서 인상주의로 옮겨간 흐름과 비슷하게 느껴진다." AI가 사실적 재현을 담당하기 시작한 지금, 디자이너와 개발자의 고유한 기여는 무엇인지—그 질문에 대한 답은 아직 실험 중이다. 다만 확실한 것은, 그 답을 찾는 사람이 만든 결과물이 AI가 만들어준 결과물보다 오래간다는 점이다.