코드가 캔버스를 역습하는 순간
프론트엔드 개발자로서 가장 예민한 지점은 항상 '피그마 시안과 실제 구현 사이의 갭'이었습니다. Figma Dev Mode에서 간격 값을 복사해도, 실제 브라우저에서 렌더링하면 1~2px씩 밀리는 경험 — 다들 해보셨을 겁니다. 그런데 이제 그 갭을 AI가 양방향으로 메우겠다고 나섰습니다.
최근 Figma 공식 문서에 등장한 Claude Code to Figma 워크플로우가 화제입니다. 한 AI 엔지니어 지망 대학생이 velog에 공유한 실험기를 보면, Claude Code가 실제 운영 환경의 UI를 캡처해 Figma 캔버스의 편집 가능한 프레임으로 변환합니다. 기존의 html.to.design 플러그인이나 Figma Make가 비트맵 이미지 덩어리를 뱉어내던 것과는 결이 다릅니다. font, color, round, margin, padding 같은 속성이 벡터 기반으로 보존되니까, 생성 후에 실제로 편집이 됩니다.
사용자 입장에서는 혁명적이죠. 코드로 프로토타입을 구축하고, 그걸 그대로 디자인 캔버스에 끌어다 놓은 다음, 디자이너가 다듬고, 다시 코드로 내보내는 — 진짜 의미의 양방향 파이프라인이 열리는 겁니다. 디자인 시스템 토큰이 코드에서 시작해 캔버스에서 검증되고, 다시 코드로 돌아오는 순환. Figma에서 볼 때는 괜찮았는데 실제로 구현하면 달라지는 그 만성적 고통이 구조적으로 줄어들 수 있습니다.
그런데 진짜 문제는 시안 밖에 있습니다
여기서 솔직히 말해야 할 게 있습니다. AI가 아무리 레이아웃을 정확하게 피그마에 옮겨줘도, 프론트엔드 구현의 진짜 지뢰밭은 눈에 보이지 않는 곳에 있습니다. 디자인 캔버스에는 '로딩 실패 시 어떤 화면을 보여줄 것인가'가 그려져 있지 않고, 라우팅 전환 시 컴포넌트 언마운트 타이밍도 명세되어 있지 않습니다.
dev.to에 실린 JavaScript 비동기 에러 핸들링 아티클이 정확히 이 지점을 찌릅니다. fetch를 try/catch로 감싸 놓고 안심하는 개발자가 많지만, 비동기 호출은 콜스택이 비워진 뒤에 실패합니다. 저자의 비유를 빌리자면, "낙하산은 화요일에 펼쳤는데, 비행기는 목요일에 추락한" 셈입니다. AI가 생성한 대시보드 UI가 시각적으로 완벽해도, 네트워크 요청 실패 시 UnhandledPromiseRejection이 터지면 사용자가 보는 건 빈 화면뿐입니다.
이건 await을 빼먹는 수준의 이슈가 아닙니다. AI가 생성한 코드에서 .catch() 체인이 빠져 있는지, addEventListener 콜백 안에 에러 바운더리가 있는지, async/await 브릿지가 정확히 try/catch 스코프를 유지하고 있는지 — 이건 AI가 그려준 예쁜 프레임을 클릭해선 절대 확인할 수 없는 영역입니다.
라우팅도 마찬가지입니다. React Router의 BrowserRouter → Routes → Route 구조는 SPA의 뼈대인데, AI가 페이지 단위로 UI를 생성할 때 라우트 간 상태 유실, 레이지 로딩 청크 분리, 404 폴백 같은 설계를 제대로 잡아줄까요? 기획자가 이걸 의도한 건지 모르겠지만, 경로 전환 시 컴포넌트가 깜빡이는 문제는 Figma 캔버스에서는 재현 자체가 불가능합니다.
검수 체크리스트가 달라져야 합니다
정리하면, AI가 디자인-코드 변환을 자동화할수록 프론트엔드 개발자의 검수 포인트는 시각적 정합성에서 런타임 안정성 쪽으로 무게중심이 이동합니다. 제가 생각하는 새로운 검수 레이어는 이렇습니다:
- 에러 바운더리: 비동기 호출마다
.catch()또는await+try/catch가 빠짐없이 있는가 - 라우팅 견고성: 존재하지 않는 경로, 뒤로가기, 딥링크가 정상 동작하는가
- 로딩/에러 상태 UI: 스켈레톤, 에러 폴백, 빈 상태(empty state)가 모두 구현되어 있는가
- 접근성: AI가 생성한 마크업에 시맨틱 태그,
aria-label, 키보드 포커스 순서가 올바른가 - 성능: 번들 사이즈, Lighthouse 점수, Core Web Vitals — AI가 편의상 무거운 라이브러리를 끌어다 쓰진 않았는가
여기서 로딩 스켈레톤 넣으면 어떨까요? 같은 제안을 AI에게 직접 할 수 있는 시대가 됐다는 건 좋은 일입니다. 하지만 그 스켈레톤이 네트워크 타임아웃 시 무한 루프에 빠지지 않는지 확인하는 건 여전히 사람의 몫입니다.
도구가 바뀌면 역할도 바뀝니다
Claude Code to Figma는 분명 디자인-개발 워크플로우의 게임 체인저입니다. 비트맵 덩어리를 뱉던 기존 PPT 자동생성 AI와 달리, 편집 가능한 벡터 프레임을 만들어준다는 것만으로도 디자인 시스템 운영의 효율이 크게 올라갑니다. 하지만 사실 이건 flexbox로 해결되는 레이아웃 문제가 아닙니다. AI가 보이는 화면을 완벽하게 복제할수록, 개발자의 눈은 보이지 않는 곳 — 비동기 에러의 생존 범위, 라우트 전환의 엣지 케이스, 런타임 퍼포먼스 — 에 더 집중해야 합니다.
결국 프론트엔드 개발자의 가치는 '시안을 px 단위로 옮기는 기술'에서 'AI가 만든 코드에서 사용자가 절대 마주치면 안 되는 순간을 찾아내는 감각'으로 이동하고 있습니다. DevTools 열어서 Ctrl+Shift+C로 요소 찍어보는 습관은 여전히 필요하지만, 이제는 Network 탭과 Console 탭을 먼저 볼 차례입니다.