HTML과 CSS 소스 코드, 즉 운영 중인 프로덕션 코드, 오픈소스 UI 라이브러리, 프론트엔드 프로토타입, 또는 정적 내보내기를 가지고 있다면 이를 바로 편집 가능한 Figma 파일로 변환할 수 있습니다. 이 워크플로는 Website-to-Figma보다 개발자 주도, 소스 우선의 친척 같은 방식입니다.
왜 라이브 URL이 아니라 소스 코드를 쓰느냐고요? 이유는 세 가지입니다. 최대 충실도(계산된 스타일이 픽셀이 아니라 CSS에서 직접 오기 때문), 캡처하기 어려운 페이지에도 동작함(빌드 타임 생성, 인증 뒤, 개발 중), 그리고 엔지니어링 중심 워크플로에서 코드-디자인 라운드트립에 이상적이라는 점입니다.
관련 Codia 제품: Codia HTML to Figma.
HTML to Figma를 언제 써야 하나
다음과 같은 상황에 잘 맞습니다.
- 페이지가 개발 환경에 있고 아직 배포되지 않았다.
- 정적 HTML/CSS 내보내기는 있지만 디자인 소스는 없다.
- 코드로 작성된 오픈소스 디자인 시스템이나 컴포넌트 라이브러리를 다루고 있다.
- 엔지니어링이 페이지를 소유하고 있고, 프로덕션 CSS에서 Figma 소스를 역생성해야 한다.
- 컴포넌트 라이브러리를 Figma로 다시 문서화해 디자인 정렬을 맞추고 있다.
- 디자인 시스템 팀이 프로덕션 CSS와 디자인 토큰의 차이를 감사하고 싶어 한다.
페이지에 URL로 접근할 수 있다면 보통은 Website-to-Figma가 더 간단합니다. HTML-to-Figma는 소스 코드 자체가 있을 때 쓰는 방식입니다.
HTML to Figma vs Website to Figma vs Screenshot to Figma
| 입력 | 워크플로 | 가장 적합한 경우 |
|---|---|---|
| Raw HTML/CSS 소스 | HTML to Figma | 개발자 주도 변환, 최대 충실도, 아직 배포되지 않은 페이지 |
| 라이브 URL | Website to Figma | 접근 가능한 페이지, 경쟁사와 프로덕션 포함 |
| PNG/JPG | Screenshot to Figma | 이미지밖에 없을 때 |
세 워크플로가 가는 목적지는 같습니다. 모두 편집 가능한 Figma 파일입니다. 차이는 무엇을 입력하느냐입니다.
워크플로
- 소스를 준비합니다. HTML이 독립적으로 깨끗하게 렌더링되는지 확인하세요. 누락된 CSS, 깨진 폰트, 실행 중이어야 하는 빌드 서버 의존성이 없어야 합니다.
- 변환합니다. Codia AI가 마크업을 파싱하고, 계산된 CSS 스타일을 적용하고, 이미지와 폰트를 해석하고, 시각 구조를 Figma 레이어로 다시 만듭니다.
- 결과를 Figma에서 엽니다. 각 변환 작업은 구조화된 레이어, 텍스트 스타일, 이미지 Fill이 있는 Frame으로 들어갑니다.
- 검토합니다. 아래 정리 섹션을 보세요.
- 반복 컴포넌트를 컴포넌트화해서 Figma 파일이 소스 코드와 같은 구조를 갖도록 만듭니다.
변환 후에도 유지되는 것
대체로 깨끗하게 유지되는 항목
- 의미 있는 HTML 구조 -
<section>,<article>,<header>,<footer>같은 중첩 레이아웃은 그룹화된 Figma Frame으로 옮겨집니다. - 텍스트 내용과 타이포그래피 -
font-family,font-size,font-weight,line-height가 보존된 실제 텍스트 레이어 - 색상 값 - 단색 배경과 텍스트 색상이 Figma Fill로 직접 변환됨
- Flexbox와 Grid 레이아웃 - 비유가 깔끔한 경우 Figma Auto Layout으로 바뀜
- 테두리, border-radius, 그림자 - Figma 효과로 적용됨
- 이미지 - 원본 자산 URL을 참조하는 이미지 Fill로 배치됨
검토가 필요한 항목
- CSS만으로 만든 복잡한 효과 -
backdrop-filter, 복잡한mask-image, 여러 단계의 그라데이션 블렌드. 가장 가까운 Figma 표현으로 근사됩니다. - 의사 요소 -
::before/::after내용은 별도 Frame으로 포착되며, 의사 클래스 상태(:hover)는 각 상태를 따로 캡처해야 합니다. - 커스텀 폰트 호스팅 - 커스텀 CDN으로 불러오는 폰트는 로컬 Figma 폰트와 수동 매핑이 필요할 수 있습니다.
- CSS 변수와 디자인 토큰 - 원시 값으로 보존됩니다. Figma 디자인 시스템으로 되돌리는 일은 수동 단계입니다.
- JS로 구동되는 레이아웃 - JavaScript가 크기나 위치를 정하는 요소는 변환 전에 최종 상태가 실행되어 있어야 합니다.
- 웹 애니메이션 - Figma는 CSS keyframes나 transition을 네이티브하게 표현하지 못합니다. 정지 상태를 변환하세요.
역할별 사용 사례
코드베이스를 넘겨받는 디자이너
회사에 들어왔는데 프로덕션 프론트엔드는 있고 Figma는 없습니다. HTML-to-Figma는 모든 화면을 손으로 다시 만들지 않고도 디자인 작업을 시작할 수 있게 해 줍니다.
디자인 시스템 팀
프로덕션 CSS에 실제로 들어 있는 것과 Figma 라이브러리에 들어 있는 것을 비교하세요. 코드베이스에서 대표 컴포넌트를 변환해 Figma 대응물 옆에 배치하면 드리프트가 보입니다.
컴포넌트를 문서화하는 엔지니어링 팀
컴포넌트 라이브러리는 코드에 있지만 디자인 팀은 Figma 문서를 원한다면, HTML-to-Figma가 다리 역할을 합니다. 각 컴포넌트의 Storybook이나 데모를 Figma Frame으로 변환하세요.
에이전시와 프리랜서
클라이언트가 정적 HTML 목업(보통 이전 벤더 작업)을 넘겼다고 합시다. HTML-to-Figma는 손으로 다시 만드는 것보다 빠르고, 리디자인을 위한 편집 가능한 베이스라인을 제공합니다.
무엇을 정리해야 하나
변환 후 다음을 집중적으로 정리하세요.
- 텍스트 스타일 - 인라인 스타일을 Figma 타이포그래피 토큰으로 교체
- 색상 토큰 - 복원된 hex 값을 디자인 시스템 색상 스타일과 매핑
- 아이콘 - 래스터 아이콘을 라이브러리의 SVG 컴포넌트로 교체
- Auto Layout - 반응형 섹션에서 제대로 변환되었는지 확인하고, 필요하면 다시 구성
- 컴포넌트 구조 - 반복 패턴(카드, 버튼, 목록 아이템)을 Figma 컴포넌트로 전환
- 네이밍 - 코드 클래스 이름은 보통 디자인 이름과 맞지 않습니다. 디자인에 맞게 다시 이름을 붙이세요
- 서드파티 위젯 - 분석, 채팅, 동의 오버레이는 디자인 영역에서 제거
흔한 함정
반쯤 깨진 소스. HTML이 브라우저에서 제대로 렌더링되지 않으면 변환도 없는 것을 복구할 수 없습니다. 먼저 소스가 깨끗하게 렌더링되는지 확인하세요.
누락된 CSS 또는 폰트. 같은 이야기입니다. 외부 CSS나 폰트가 로드되지 않으면 변환은 fallback을 캡처합니다. 변환용으로는 모든 것을 번들링하세요.
JS로 채워지는 콘텐츠를 잊는 것. 중요한 레이아웃이나 콘텐츠가 페이지 로드 후 JavaScript로 렌더링된다면, JS가 실행되고 페이지가 완전히 하이드레이션된 뒤에 캡처해야 합니다.
CSS 애니메이션이 그대로 옮겨지길 기대하는 것. Figma는 정적입니다. 정지 상태를 변환하고, 필요하면 이후에 상호작용 변형을 Figma에서 설계하세요.
코드 품질 검사로 착각하는 것. HTML-to-Figma는 코드를 리팩터링하지 않습니다. 있는 것을 변환할 뿐입니다. 코드 품질 관리는 코드 리뷰에서 해야 합니다.
Figma-to-Code와 함께 쓰기
엔지니어링 팀에 유용한 라운드트립 패턴은 이렇습니다. HTML → Figma(이 워크플로) → Figma에서 정리 → Figma to Code → 더 깔끔한 리팩터링된 프론트엔드. 이 방식은 일관성 없는 프로덕션 CSS를 깔끔한 디자인 시스템 정렬 구현으로 합치고 싶을 때 좋습니다.
API 접근
컴포넌트 라이브러리나 디자인 시스템 전체를 대량 변환하려면 Visual Struct API를 사용하세요. HTML 입력을 받아 구조화된 JSON을 반환하며, downstream 도구가 이를 Figma로 바꾸거나 디자인 운영 파이프라인으로 보낼 수 있습니다.
FAQ
정말 Raw HTML/CSS를 편집 가능한 Figma로 바꿀 수 있나요?
네. 변환은 HTML을 파싱하고 계산된 CSS를 적용한 뒤 시각 구조를 Figma 레이어로 다시 만듭니다. 텍스트는 실제 텍스트, 색상은 실제 Fill, 레이아웃은 비유가 맞는 곳에서는 실제 Auto Layout입니다.
페이지를 스크린샷으로 찍는 것과 뭐가 다른가요?
스크린샷은 계산된 CSS 맥락을 잃습니다. 폰트, 정확한 색상, 레이아웃 추론을 픽셀에서 다시 추정해야 합니다. HTML-to-Figma는 소스 값에서 시작하므로 충실도가 더 높고 검토 부담이 더 낮습니다.
React나 Vue 같은 프레임워크와도 동작하나요?
변환은 렌더링된 HTML을 기준으로 합니다. 프레임워크 소스가 아니라 렌더 결과입니다. 컴포넌트를 HTML/CSS로 렌더링한 뒤(Storybook, static export, browser DevTools의 "Copy outerHTML") 넣으세요.
Tailwind CSS 클래스는 어떻게 되나요?
Tailwind는 런타임에 표준 CSS로 컴파일되므로, 변환은 일반 CSS 규칙을 봅니다. 복원된 Figma 스타일은 클래스 이름이 아니라 시각적 출력과 일치합니다.
디자인 토큰도 보존되나요?
CSS custom properties(--brand-primary)는 원시 값으로 보존됩니다. Figma 디자인 시스템 토큰으로 되돌리는 일은 수동 정리 단계입니다. 다만 보고서는 서로 다른 토큰 값을 모두 표시하므로 체계적으로 매핑할 수 있습니다.
전체 웹사이트가 필요해야 하나요, 아니면 컴포넌트 하나만 처리할 수도 있나요?
둘 다 됩니다. 전체 페이지를 넣어도 되고, 단일 컴포넌트 스니펫만 넣어도 됩니다. 보통은 더 작고 초점이 분명한 입력이 더 깨끗한 결과를 만듭니다.
API가 컴포넌트 라이브러리 전체를 처리할 수 있나요?
네. 배치 엔드포인트는 Visual Struct API를 보세요.