2026년 7월 8일 • ☕️ 4 min read
리디자인 킥오프 미팅에서 디자이너가 물었다. “지금 화면들 Figma로 받을 수 있어요?” 스크린샷 말고, 수정할 수 있는 상태로.
과거였다면 누군가 스크린샷을 깔아놓고 사각형을 트레이싱했을 것이다. 지금은 웹페이지의 DOM과 computed style을 읽어서 실제 Figma 노드로 재구성해 주는 도구들이 있다. 마침 옮겨야 할 화면 중에 로그인 뒤에 있는 어드민 대시보드가 섞여 있어서, 되는지 안 되는지 직접 확인할 겸 세 가지를 돌려봤다.
먼저 고백 하나. 셋 중 하나인 html2figma는 내가 만든 도구다. 그래서 이 글에서는 그 도구의 자랑보다 한계를 더 적으려고 신경 썼다. 걸러 읽을 사람은 걸러 읽으면 된다.
돌려본 페이지는 세 종류다. 프론트엔드 개발자라면 각각 뭐가 문제가 될지 감이 올 것이다.
::before로 그린 장식 요소가 많은 페이지localhost:3000, 아직 배포 전확인한 항목은 네 가지. 텍스트가 이미지가 아닌 진짜 텍스트 노드로 오는가, SVG가 벡터로 변환되는가, Auto Layout 구조가 잡히는가, 그리고 레이어 트리가 사람이 읽을 만한가.
이 분야에서 가장 유명한 도구고, 써보면 왜 유명한지 안다.
인상적인 건 워크플로다. Figma 플러그인 안에서 URL을 입력하면 자기네 서버가 페이지를 렌더링해서 결과를 꽂아준다. 브라우저 탭을 열 필요도 없다. 데스크톱·태블릿·모바일 뷰포트를 한 번에 가져오는 기능은 반응형 리디자인 시작점으로 이만한 게 없다. 랜딩 페이지 변환 품질도 안정적이었다. 텍스트, 그라디언트, SVG 모두 무난하게 넘어왔다.
문제는 2번과 3번 페이지에서 시작된다. URL 임포트는 서버 렌더 방식이라 로그인 뒤 화면과 localhost는 당연히 못 본다. 이 경우 크롬 익스텐션 경로를 쓰면 되긴 하는데, 회사 어드민 화면의 DOM이 외부 서버를 경유한다는 점은 보안 검토가 있는 조직이라면 걸릴 수 있는 부분이다. 나라면 사내 대시보드에는 안 쓴다.
가격은 개인 기준 연결제 $12/월(연 $144), 월결제 $18/월. 무료는 30일당 10회다. 팀 단위로 수십 페이지를 배치 임포트해야 하는 에이전시라면 이 가격이 아깝지 않을 것이다. 혼자 쓰기엔 좀 나간다.
내가 만든 쪽이다. 만들게 된 이유가 위에서 걸린 지점 그대로라서, 접근 방식이 다르다.
크롬 익스텐션이 Chrome DevTools Protocol의 DOMSnapshot으로 지금 탭에 떠 있는 화면을 읽는다. 서버 렌더가 아니라 실제 브라우저 상태를 읽기 때문에 로그인 세션, localhost, 심지어 A/B 테스트로 나한테만 보이는 변형까지 보이는 그대로 캡처된다. 캡처 결과는 .h2f 파일(JSON)이나 클립보드로 나가고 서버에 저장되지 않는다. 어드민 대시보드를 옮길 때 이 부분 때문에 마음이 편했다 — 애초에 이게 필요해서 만들었다.
디테일 처리에 공을 들였는데, ::before/::after로 그린 아이콘, 비대칭 보더, iframe과 shadow DOM 병합, 인라인 SVG의 벡터 변환까지 재현한다. 큰 페이지는 청크로 나눠 전송한다. Figma 쪽 플러그인에서 Auto Layout과 Local Styles(색·텍스트 스타일)를 자동 생성해 주는 것도 후속 작업 시간을 꽤 줄여준다.
아쉬운 점도 그대로 적는다. 첫째, 캡처하는 동안 크롬 상단에 “디버깅 중” 배너가 뜬다. CDP를 쓰는 대가라 피할 수 없는데, 처음 보면 당황스럽다. 둘째, html.to.design의 멀티 뷰포트 동시 임포트 같은 건 없다. 뷰포트별로 창 크기를 바꿔가며 각각 캡처해야 한다. 셋째, 무료가 매달 5회라 html.to.design 무료(30일당 10회)보다 횟수는 적다. 대신 무료에도 기능 제한은 없고 가입 없이 바로 쓴다. Pro는 $9/월.
배포는 크롬 웹스토어에 있다.
Builder.io가 공개한 오픈소스 플러그인. 완전 무료라는 것만으로 시도해 볼 가치가 있고, 코드가 공개돼 있어서 변환 로직이 궁금하면 직접 읽어볼 수 있다. 이 카테고리 도구들이 내부에서 뭘 하는지 공부하기에도 좋다.
다만 결과물 품질은 페이지를 탄다. 단순한 레이아웃은 무난한데, 복잡한 페이지에서는 요소 위치가 어긋나거나 스타일이 유실되는 경우가 있었다. Local Styles 생성이나 정교한 Auto Layout 재구성 같은 후처리도 없다. Builder.io의 본업(Visual Copilot)에 딸린 사이드 도구 성격이라 개선 속도도 빠르지 않아 보인다.
한 번씩 가볍게 옮길 거면 충분하다. 업무 파이프라인에 넣기엔 편차가 부담스럽다.
세 도구의 결과물 차이는 결국 DOM을 읽는 방식의 차이에서 온다.
getComputedStyle 방식(Builder.io)은 구현이 단순하지만 pseudo-element나 shadow DOM 같은 영역에서 누락이 생기기 쉽다.변환 도구를 고를 때 “어떤 방식으로 읽는가”를 먼저 확인하면 자기 상황에 맞는 걸 빨리 거를 수 있다.
| 상황 | 선택 |
|---|---|
| 멀티 뷰포트, 수십 페이지 배치 임포트 | html.to.design |
| 로그인 뒤 화면, localhost, 외부 서버 경유가 곤란한 경우 | html2figma |
| 무료로 가끔, 단순한 페이지 | Builder.io |
| 어차피 전부 새로 그리는 풀 리디자인 | 도구 없이 스크린샷 참고가 더 빠를 수 있다 |
마지막 줄은 진심이다. 변환 도구가 만들어 준 레이어 구조는 “기존 화면을 유지하며 고칠 때” 값어치를 한다. 전부 갈아엎을 거면 참고용 스크린샷 한 장이 더 나을 때도 많다. 자주 옮기는 페이지 하나로 셋 다 돌려보고 레이어 트리를 비교해 보는 게 제일 확실하다 — 셋 다 무료로 시작할 수 있다.