"디자인 프로세스는 죽었습니다." Anthropic Claude의 디자인 총괄을 지낸 Jenny Wen이 Lenny's Podcast에서 던진 이 한 마디가 요즘 머릿속을 떠나질 않습니다. 솔직히 처음엔 '또 AI 과장 아냐?' 싶었어요. 그런데 실제로 피그마 열어서 컴포넌트 구조 잡고, Cursor로 코드 뽑고, 검토까지 AI한테 넘기는 저 자신을 보면서 — 아, 이게 진짜구나 싶더라고요.
문제는 속도입니다. AI는 '기획 → 리서치 → 목업 → 개발'이라는 순차적 프로세스를 기다려주지 않아요. 버튼 하나, 폼 하나를 코드로 뽑는 건 이제 몇 초짜리 일이 됐습니다. 그러면 우리는 무엇을 해야 할까요? 저는 이 질문에 대한 실마리를 세 가지 서로 다른 맥락에서 찾았습니다.
AI가 CSS Modules에서도 틀리는 이유
dev.to에 올라온 'CSS Modules에서 AI가 못 하는 5가지' 글을 읽으면서 무릎을 탁 쳤습니다. AI 툴이 CSS Modules 코드를 꽤 그럴듯하게 뽑아내는 건 맞아요. 파일이 짧고, 컴포넌트 옆에 붙어 있고, 예제도 인터넷에 넘쳐나니까요. 근데 '빠르게 동작하는 코드'랑 '올바르고, 지속 가능하고, 접근성까지 챙긴 코드'는 완전히 다른 얘기입니다.
제가 실제로 제일 자주 목격하는 AI의 실수 — 부모 컴포넌트의 .module.css에서 자식 컴포넌트의 로컬 클래스를 글로벌로 잡으려는 패턴입니다. styles.childP는 컴파일 후 해시된 클래스명이 되는데, AI는 이걸 그냥 .childP처럼 취급해서 selector가 아무것도 못 잡는 상황을 만들어냅니다. CSS는 에러 없이 조용히 적용 안 되고요. 이거 px 단위로 봐야 해요 — 실제로 Lighthouse로 접근성 점수 찍어보기 전까지는 안 보이는 문제들이 이런 데서 쌓입니다.
더 심각한 건 접근성입니다. CSS Modules가 클래스 충돌을 막아줘도, focus-visible, prefers-reduced-motion, 고대비 모드 대응은 자동으로 딸려오지 않아요. AI는 평균적인 웹 미학을 복사할 뿐, 제품의 브랜드 언어와 WCAG 가이드라인을 함께 녹여내지 못합니다. 스케일드 아키텍처 — @layer 캐스케이드 전략, 모노레포 번들러 세팅, route-based code splitting과 CSS 로딩 순서 — 이런 결정은 여전히 인간이 해야 합니다.
프레임워크 선택과 번들 사이즈: '편함'이 기술 부채가 되는 순간
Next.js 15 + App Router 기반의 i18n 스타터 템플릿 소개 글(dev.to)을 보면서 또 한 번 생각이 많아졌습니다. 15개 언어, SSR 번역, CDN 관리형 번역 키 — 기능 목록만 보면 완벽해 보여요. 근데 실제로 도입하면 better-i18n CDN에 대한 의존성이 생기고, 번역 키 관리가 외부 대시보드로 넘어갑니다. 팀 규모나 서비스 특성에 따라 이게 오히려 독이 될 수 있어요.
반대편에는 BlokJS가 있습니다(dev.to). 9KB gzipped, 빌드 스텝 없음, 제로 디펜던시. 라우터, 스토어, 비동기 추적까지 내장했는데 9KB라니 — 솔직히 Lighthouse 성능 점수 올리기엔 매력적입니다. 그런데 SSR 없음, 가상 DOM 없음, 생태계 없음. '프로토타입이나 내부 툴에 적합하다'는 제작자의 솔직한 고백처럼, 이 프레임워크가 맞는 상황과 맞지 않는 상황을 구분하는 판단력이 필요합니다. AI는 'BlokJS 쓰면 번들 사이즈 줄어든다'는 사실은 알려줘도, '지금 이 프로젝트에 BlokJS가 맞냐'는 맥락 판단은 못 해요.
Jenny Wen이 진짜 말하려 했던 것
다시 Jenny Wen의 이야기로 돌아오면 — 그녀가 '디자인 프로세스가 죽었다'고 할 때, 이건 디자이너나 개발자의 역할이 사라진다는 말이 아닙니다. 완벽한 목업을 6주 동안 다듬다가 개발에 넘기는 순차적 워터폴 방식이 죽었다는 거예요. AI 속도에 맞추려면 기획-디자인-개발이 동시에 실험하고, 빠르게 검증하고, 반복해야 합니다.
사용자 입장에서는 이게 사실 더 좋은 방향입니다. 6주 뒤 완성된 목업보다 3일 만에 나온 인터랙티브 프로토타입이 실제 피드백을 훨씬 잘 끌어내니까요. 문제는 이 속도에 끌려다니다 보면 스타일 아키텍처의 일관성, 접근성, 성능 최적화 같은 게 뒷전이 된다는 점입니다. AI가 로딩 스켈레톤 코드는 뚝딱 만들어줘도, 언제 스켈레톤을 쓰고 언제 스피너를 쓸지의 UX 판단은 여전히 우리 몫이에요.
그래서, 손에서 놓으면 안 되는 것들
결론적으로 AI 시대에 프론트엔드 개발자가 더 날카롭게 갈아야 할 역량은 오히려 더 인간적인 것들입니다. 컴파일 파이프라인 전반을 이해한 스타일 아키텍처 설계, WCAG 기준을 몸에 익힌 접근성 판단, 번들 사이즈와 DX 사이의 트레이드오프를 맥락에 맞게 고르는 프레임워크 선택, 그리고 Figma 시안과 실제 브라우저 렌더링 사이의 갭을 좁히는 디자인-개발 협업 감각. 이런 것들은 AI가 '빠르게 동작하는 코드'를 뽑아내는 속도가 빨라질수록, 오히려 더 희귀하고 더 귀해집니다.
AI가 CSS Modules에서 scope를 오해하고, i18n 라이브러리 선택의 트레이드오프를 모르고, 9KB 프레임워크가 어디에 맞는지 판단 못 하는 동안 — 우리는 그 판단을 하는 사람이어야 합니다. 1px이라도 어긋나면 밤을 새우는 이 성격, 사실 AI 시대에 꽤 쓸모 있습니다.