2026년 7월 8일 • ☕️ 5 min read
2026-08 갱신. 이 글에 나오는 html2figma는 이름이 html2design으로 바뀌었다. Figma 플러그인 심사에서 제품명에 “figma”를 넣을 수 없다는 이유로 반려됐고, 가이드라인을 읽어보니 맞는 얘기여서 개명했다. 같은 기간에 캡처 결과를 넘기는 경로도 정리돼서 해당 문단을 고쳤다. 세 도구를 비교한 내용 자체는 7월에 돌려본 그대로 둔다.
리디자인 킥오프 미팅에서 디자이너가 물었다. “지금 화면들 Figma로 받을 수 있어요?” 스크린샷 말고, 수정할 수 있는 상태로.
과거였다면 누군가 스크린샷을 깔아놓고 사각형을 트레이싱했을 것이다. 지금은 웹페이지의 DOM과 computed style을 읽어서 실제 Figma 노드로 재구성해 주는 도구들이 있다. 마침 옮겨야 할 화면 중에 로그인 뒤에 있는 어드민 대시보드가 섞여 있어서, 되는지 안 되는지 직접 확인할 겸 세 가지를 돌려봤다.
먼저 고백 하나. 셋 중 하나인 html2design은 내가 만든 도구다. 그래서 이 글에서는 그 도구의 자랑보다 한계를 더 적으려고 신경 썼다. 걸러 읽을 사람은 걸러 읽으면 된다.
돌려본 페이지는 세 종류다. 프론트엔드 개발자라면 각각 뭐가 문제가 될지 감이 올 것이다.
::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 테스트로 나한테만 보이는 변형까지 보이는 그대로 캡처된다. 페이지를 대신 렌더해 줄 서버가 필요 없다는 게 이 방식의 핵심이다.
그런데 여기서 위에 내가 써놓은 말이 나에게 돌아온다. 캡처한 걸 Figma로 넘기는 경로가 지금은 하나뿐이고, 그게 릴레이를 지나간다. 익스텐션에 6자리 코드를 넣으면 공개 릴레이가 플러그인 쪽으로 중계한다. 저장하지 않고 코드로 짝지어진 상대에게만 넘긴 뒤 버리지만, DOM이 외부 서버를 통과한다는 사실 자체는 html.to.design 익스텐션과 다르지 않다. 7월에 이 글을 쓸 때는 .h2f 파일과 클립보드 경로가 있어서 이 얘기를 꺼낼 필요가 없었는데, 그 두 경로를 걷어내면서 사정이 달라졌다.
릴레이를 직접 띄우면 이 문제는 사라진다. Node용과 Cloudflare Workers용이 리포지토리에 같이 들어 있다. 다만 릴레이 주소가 코드에 상수로 박혀 있어서, 지금은 익스텐션과 플러그인을 소스에서 다시 빌드해야 한다. 설정 화면에서 주소를 바꾸는 건 아직 안 된다. 사내 대시보드를 옮겨야 하는 팀이라면 그 정도 수고는 할 만하겠지만, 클릭 몇 번으로 끝나는 일은 아니라고 적어둔다.
디테일 처리에 공을 들였는데, ::before/::after로 그린 아이콘, 비대칭 보더, iframe과 shadow DOM 병합, 인라인 SVG의 벡터 변환까지 재현한다. 큰 페이지는 청크로 나눠 전송한다. Figma 쪽 플러그인은 flex와 grid를 읽어 Auto Layout으로 구성해 준다. 색과 텍스트를 Local Styles로 자동 생성하는 기능도 한동안 붙어 있었지만 지금은 빠졌다.
아쉬운 점도 그대로 적는다. 첫째, 캡처하는 동안 크롬 상단에 “디버깅 중” 배너가 뜬다. CDP를 쓰는 대가라 피할 수 없는데, 처음 보면 당황스럽다. 둘째, html.to.design의 멀티 뷰포트 동시 임포트 같은 건 없다. 뷰포트별로 창 크기를 바꿔가며 각각 캡처해야 한다. 셋째, 무료가 매달 5회라 html.to.design 무료(30일당 10회)보다 횟수는 적다. 대신 무료에도 기능 제한은 없고 가입 없이 바로 쓴다. Pro는 $5/월.
배포는 크롬 웹스토어에 있다.
Builder.io가 공개한 오픈소스 플러그인. 완전 무료라는 것만으로 시도해 볼 가치가 있고, 코드가 공개돼 있어서 변환 로직이 궁금하면 직접 읽어볼 수 있다. 이 카테고리 도구들이 내부에서 뭘 하는지 공부하기에도 좋다.
다만 결과물 품질은 페이지를 탄다. 단순한 레이아웃은 무난한데, 복잡한 페이지에서는 요소 위치가 어긋나거나 스타일이 유실되는 경우가 있었다. Local Styles 생성이나 정교한 Auto Layout 재구성 같은 후처리도 없다. Builder.io의 본업(Visual Copilot)에 딸린 사이드 도구 성격이라 개선 속도도 빠르지 않아 보인다.
한 번씩 가볍게 옮길 거면 충분하다. 업무 파이프라인에 넣기엔 편차가 부담스럽다.
세 도구의 결과물 차이는 결국 DOM을 읽는 방식의 차이에서 온다.
getComputedStyle 방식(Builder.io)은 구현이 단순하지만 pseudo-element나 shadow DOM 같은 영역에서 누락이 생기기 쉽다.변환 도구를 고를 때 “어떤 방식으로 읽는가”를 먼저 확인하면 자기 상황에 맞는 걸 빨리 거를 수 있다.
| 상황 | 선택 |
|---|---|
| 멀티 뷰포트, 수십 페이지 배치 임포트 | html.to.design |
| 로그인 뒤 화면, localhost | html2design |
| DOM이 외부 서버를 지나가면 안 되는 경우 | html2design + 릴레이 자체 호스팅(소스 빌드 필요) |
| 무료로 가끔, 단순한 페이지 | Builder.io |
| 어차피 전부 새로 그리는 풀 리디자인 | 도구 없이 스크린샷 참고가 더 빠를 수 있다 |
마지막 줄은 진심이다. 변환 도구가 만들어 준 레이어 구조는 “기존 화면을 유지하며 고칠 때” 값어치를 한다. 전부 갈아엎을 거면 참고용 스크린샷 한 장이 더 나을 때도 많다. 자주 옮기는 페이지 하나로 셋 다 돌려보고 레이어 트리를 비교해 보는 게 제일 확실하다. 셋 다 무료로 시작할 수 있다.