지금 프론트엔드 현장에서 가장 조용하게, 그러나 빠르게 바뀌고 있는 것은 '누가 무엇을 만드는가'라는 경계선이다. 디자이너가 코드를 생성하고, 1인 개발자가 27개 언어를 지원하는 번역 도구를 예산 없이 출시하는 시대가 됐다. 이 변화의 중심에 Claude Design, Llama 기반 코드 트랜스파일러 같은 AI 도구들이 있다. 그런데 이 도구들을 실무에 붙여 본 사람들의 후기를 들여다보면, 공통된 패턴 하나가 선명하게 드러난다. 도구의 성능보다 '얼마나 빨리 틀리느냐'가 결과를 가른다는 것이다.
Claude Design이 실제로 없앤 것들
8년 차 UX/UI 디자이너인 '지밍리'가 브런치에 남긴 Claude Design 사용 후기는 도구 리뷰를 넘어 워크플로우 해부에 가깝다. 핵심은 시간이다. 포스트잇 러프를 피그마로 옮기는 데 걸리던 한 시간이 사라졌고, 클라이언트 미팅 전 러프 시안을 뽑는 반나절이 20분으로 줄었다. Claude Opus 4.7 비전 모델 기반이라 손으로 그린 와이어프레임 사진을 올리면 정돈된 목업이 바로 나오고, 전략 메모 docx를 통째로 넣으면 피치 덱 슬라이드가 정보 위계를 맞춰 생성된다.
특히 주목할 만한 지점은 디자인 시스템 연동이다. 팀의 토큰이 정리된 디자인 시스템 파일을 읽히면, 두 번째 생성부터 브랜드 컬러와 타이포를 자동으로 맞춰준다. 이건 단순한 스타일 자동화가 아니다. 디자인 시스템이 탄탄할수록 AI의 출력 품질이 높아진다는 의미이고, 역설적으로 시스템을 잘 구축한 팀이 AI 도구로 더 많은 이득을 본다는 뜻이기도 하다. 그리고 Canva·PDF·PPTX·HTML 네 포맷 동시 내보내기와 Claude Code 직접 핸드오프는, 디자인과 개발 사이에 있던 스펙 문서 작성이라는 마찰을 구조적으로 제거한다.
하지만 이 후기가 진짜 가치 있는 이유는 한계를 솔직하게 짚었기 때문이다. 마이크로 인터랙션, 포커스 링, aria-label 같은 접근성 디테일은 여전히 사람 손이 필요하다. 컴포넌트 코드가 반복되는 경향이 있어 대규모 프로덕트에 그대로 붙이기엔 이르다. Claude Design은 아이데이션과 러프 단계의 도구이지, 프로덕션 완성의 도구가 아니다. 이 구분을 명확히 할 때 도구는 비로소 제대로 작동한다.
'완벽한 준비'가 프로젝트를 죽인다
dev.to에 올라온 한 글은 이 문제의 다른 면을 건드린다. 저자는 3년간 40개의 프로젝트를 죽였다—시장이나 경쟁자가 아니라, 자기 자신이 생각을 너무 많이 해서. 러스트 비동기 런타임을 4단계 깊이까지 파고들었지만 UI 플로우 한 장을 그리지 않았고, 벡터 데이터베이스 레이턴시를 비교했지만 사용자가 벡터 검색을 원하는지조차 몰랐다. 바 차트 하나가 필요했는데 오픈소스 애널리틱스 플랫폼을 기획하다가 둘 다 만들지 못했다.
그가 도달한 결론은 단순하다. '가장 작은 것을 만들고, 나쁜 것을 배포하고, 사용자가 좋은 것을 알려주게 하라.' 그가 실제로 출시에 성공한 제품들—theSVG, Stacklit, Glin-Profanity—은 모두 출시 시점에 그를 민망하게 만들었다. 아이콘 400개로 시작했고, 단일 압축 알고리즘만 지원했고, 언어 하나만 커버했다. 그 민망함이 다음에 무엇을 만들어야 하는지 알려줬다. 이 패턴은 Claude Design 사용 후기의 '아이데이션·러프 단계 집중'과 정확히 겹친다.
솔로 빌드가 증명하는 워크플로우
dev.to의 또 다른 사례는 이 원칙이 실전에서 어떻게 작동하는지 보여준다. 1인 개발자가 예산 없이 27개 언어 간 코드 번역 도구 transpiler.us를 만들었다. 스택은 단순하다—React + Vite + TailwindCSS, Express + TypeScript, Together AI API로 Llama 3.3 70B를 연결했다. 그가 시간을 가장 많이 쏟은 곳은 모델 선택이나 아키텍처 설계가 아니라 프롬프트 엔지니어링이었다. '이걸 번역해줘'와 이디엄·에러 핸들링·NOTES/WARNINGS 구조화를 명시한 시스템 프롬프트 사이의 출력 품질 차이는 '그냥 작동하는 코드'와 '실제로 커밋할 수 있는 코드'의 차이였다.
그가 돌아봐서 아쉬운 결정은 단 하나—처음부터 27개 언어를 지원한 것이다. Python → TypeScript 하나로도 검증은 충분했다. 그리고 CLI를 더 일찍 배포했어야 했다. 개발자들은 브라우저보다 터미널을 신뢰하기 때문이다. 이 두 가지 후회는 '과도한 사전 설계'라는 함정의 변형이다. 다만 그는 그 함정에 빠지기 전에 일단 출시했고, 그래서 배울 수 있었다.
세 사례가 가리키는 하나의 워크플로우
세 가지 사례를 겹쳐 보면 하나의 흐름이 선명해진다. Claude Design은 러프와 아이데이션을 20분으로 압축하고, 솔로 빌더는 주말 하나로 v0.1을 배포하며, 프롬프트 설계에 집중하는 것이 아키텍처 고민보다 결과에 직접 영향을 준다. 핵심은 '완성하기 전에 검증하는' 구조를 AI 도구가 더 저렴하고 빠르게 만들어준다는 것이다.
디자인-개발 경계를 지운다는 건 디자이너가 개발자가 되거나, 개발자가 디자이너가 되는 것이 아니다. 아이데이션에서 러프 시안, 핸드오프, 코드 생성까지 이어지는 각 단계의 마찰 비용이 낮아지면서, 한 사람이 더 많은 단계를 빠르게 반복할 수 있게 되는 것이다. Claude Design이 스펙 문서 작성 시간을 없애고 Claude Code로 핸드오프를 연결하는 방식이 그 구체적인 예다.
그러나 이 흐름에서 AI가 아직 대체하지 못하는 영역은 명확하다. 접근성 표준 대응, 컴포넌트 재사용 설계, 성능 최적화, 사용자 인증과 결제 연동—이것들은 여전히 깊은 판단과 경험을 요구한다. AI 도구는 '발산' 단계를 가속하지만, '수렴'과 '프로덕션 안정화'는 여전히 사람의 영역이다. 이 경계를 정확히 아는 것이 도구를 잘 쓰는 첫 번째 조건이다.
지금 당장 바꿀 수 있는 것
AI 디자인 툴을 아직 워크플로우에 붙이지 않은 이유가 '완벽한 사용법을 모르기 때문'이라면, 그 자체가 오버씽킹이다. Claude Design을 쓰는 가장 좋은 시작점은 다음 클라이언트 미팅 전 러프 시안을 피그마 대신 Claude Design으로 20분 안에 뽑아보는 것이다. 코드 번역 도구를 만드는 가장 좋은 시작은 27개 언어가 아니라 자신이 가장 자주 마주치는 언어 조합 하나로 주말 안에 배포해보는 것이다. 민망한 v0.1이 완벽한 기획서보다 항상 더 많은 것을 가르쳐준다.