Figma 시안을 코드로 옮길 때, 에이전트에게 이미지를 한 장 보여 주는 방법과 Figma MCP를 연결하는 방법은 겉보기보다 다른 입력을 제공한다.
첫 번째 방법에서 에이전트는 완성된 픽셀을 본다. 두 번째 방법에서는 픽셀과 함께 레이어·치수·변수·컴포넌트·원본 에셋을 읽을 수 있다. 그렇다면 어느 쪽이 더 정확할까?
이 글은 특정 모델의 감각을 평가하지 않는다. 대신 Codex·Claude Code 같은 코딩 에이전트가 두 조건에서 실제로 접근할 수 있는 정보의 차이와, 브라우저 검증을 더했을 때 정확도를 어떻게 측정할지를 정리한다.
결론부터 말하면, 단일 기준 화면의 분위기를 빠르게 옮기는 데는 스크린샷도 쓸 수 있다. 그러나 반응형·컴포넌트 재사용·원본 에셋·상태까지 포함한 UI 구현에서는 Figma MCP를 구현의 기준 입력으로 두고, 스크린샷과 브라우저를 검증 수단으로 함께 쓰는 조합이 가장 검증 가능하다.
배경
졸업전시 웹을 구현하면서 “Figma를 봤는데도 실제 화면이 다르다”는 문제를 반복해서 만났다. 한 화면의 배경색은 맞아 보여도, 다른 페이지에서는 전역 스타일에 덮였다. 카드의 여백은 특정 폭에서만 어긋났고, hover 프레임은 이미지 크기에 맞지 않았다.
이런 문제는 에이전트가 코드를 작성하지 못해서만 생기지 않는다. 디자인의 의도와 실제 브라우저 결과 사이에 검증 단계가 빠졌기 때문이다.
이 글에서는 다음 두 입력 조건을 같은 과제로 비교한다.
- A. 스크린샷 기반 구현: Figma 프레임 이미지를 프롬프트에 넣고 UI를 구현한다.
- B. Figma MCP 기반 구현: Figma의 구조화된 컨텍스트와 원본 에셋을 가져와 UI를 구현한다.
그리고 두 결과 모두에 브라우저 캡처·오버레이·Playwright 시각 비교를 적용한다.
먼저 구분할 것: 에이전트의 내부 설계가 아니라 입력 계약
“Codex는 스크린샷을 어떻게 이해하고, Claude는 MCP를 어떻게 생각하는가?”라는 질문에 모델 내부 동작을 추측해 답하면 검증할 수 없다. 대신 공개 문서로 확인할 수 있는 입력 계약만 비교한다.
| 구분 | 스크린샷 기반 | Figma MCP 기반 |
|---|---|---|
| 에이전트가 직접 받는 것 | 렌더링된 픽셀과 프롬프트 | 프레임 구조, 레이아웃, 변수, 컴포넌트, 에셋, 스크린샷 |
| 치수·간격의 출처 | 이미지에서 추정하거나 사용자가 별도 전달 | Figma 노드의 구조화된 데이터 |
| 원본 에셋 | 이미지 안에서 추정하거나 별도 파일 필요 | Figma에서 다운로드 가능한 원본 에셋 |
| 반응형 의도 | 여러 화면을 따로 보고 추론 | 각 반응형 프레임·Auto Layout·변수에서 확인 |
| 기존 코드 재사용 | 저장소를 읽고 에이전트가 판단 | Code Connect가 있으면 실제 컴포넌트 사용 정보까지 제공 가능 |
| 최종 보장 | 둘 다 브라우저 검증 없이는 보장하지 못함 | 둘 다 브라우저 검증 없이는 보장하지 못함 |
Figma는 `get_design_context`가 시각적 충실도를 보존하는 구조화된 컨텍스트를 에이전트가 해석하기 쉬운 형태로 전달한다고 설명한다. 동시에 이 컨텍스트는 프로젝트별 프레임워크와 코드 패턴에 맞춘 생산용 코드를 직접 반환하는 기능은 아니라고 밝힌다.
Codex 역시 Figma에서 디자인 컨텍스트·에셋·스크린샷을 가져와 UI 코드로 번역하는 스킬 흐름을 제공한다. Claude Code도 MCP를 통해 Figma 디자인과 에셋에 접근하는 연결 방식을 문서화한다. 즉 두 에이전트 모두 MCP를 연결했을 때 “이미지를 더 잘 보는 모델”이 되는 것이 아니라, 이미지 밖에 있던 명세를 도구 호출로 가져올 수 있게 된다.
A. 스크린샷만 제공했을 때: 픽셀에서 구조를 추정한다
스크린샷 기반 구현은 가장 빠르게 시작할 수 있다. 파일 하나만 있으면 되고, 시안의 색상·질감·대략적인 비율을 바로 공유할 수 있다.
에이전트가 수행하게 되는 흐름은 대체로 다음과 같다.
스크린샷 + 자연어 요청
↓
보이는 영역에서 제목·카드·버튼·이미지의 관계 추정
↓
HTML/React 구조와 CSS 값 제안
↓
로컬 브라우저에서 렌더링
↓
새 스크린샷을 보고 차이를 수정이 방식은 다음 상황에서 실용적이다.
- Figma 원본에 접근할 수 없고 이미지밖에 없는 경우
- 한 장의 프로모션 화면이나 빠른 프로토타입
- 디자인 시스템보다 시각적 분위기 재현이 우선인 경우
하지만 정보 손실도 명확하다.
- 24px 간격이 토큰인지, 우연한 한 번의 값인지 알 수 없다.
- 모바일에서 두 열이 한 열로 바뀌는 규칙은 별도 화면이 없으면 추정해야 한다.
- 이미지의 원본 해상도·crop 기준·SVG 여부를 알기 어렵다.
- 기본·hover·open 같은 보이지 않는 상태는 캡처에 없으면 구현 대상에서 빠진다.
- 비슷해 보이는 전용 컴포넌트를 새로 만들기 쉬워, 기존 코드베이스의 일관성이 깨질 수 있다.
따라서 스크린샷은 좋은 시각 참조지만, 그것만으로는 디자인 명세 전체가 되지 않는다.
B. Figma MCP를 사용했을 때: 픽셀에 구조를 더한다
Figma MCP를 연결하면 에이전트는 특정 프레임의 디자인 컨텍스트를 호출해 레이어·레이아웃·컴포넌트·변수·에셋 정보를 함께 확인할 수 있다. 여기서 핵심은 “MCP가 마법처럼 완성도를 보장한다”가 아니라, 사람이 이미지에서 추정하던 부분을 검사 가능한 데이터로 바꾼다는 점이다.
Figma URL 또는 node-id
↓
get_design_context / 변수 / 원본 에셋 확인
↓
기존 코드 컴포넌트와 매핑해 구현
↓
같은 viewport에서 실제 브라우저 렌더링
↓
Figma 캡처와 오버레이·diff 비교그림 1. Figma Dev Mode의 Inspect 패널은 에이전트가 이미지 바깥의 레이아웃·상호작용·에셋 정보를 읽는 명세 층이다. 출처: Figma Dev Mode 가이드
MCP 기반 구현에서 확인해야 할 항목은 다음과 같다.
- 프레임과 하위 레이어의 정확한 크기·간격
- 색상·타이포그래피 변수
- Auto Layout, 숨김 상태, 컴포넌트 variant
- 내보낼 이미지·SVG의 원본 에셋
- 반응형 프레임에서 달라지는 열 수·패딩·텍스트 크기
- Code Connect가 있다면 기존 코드 컴포넌트의 실제 사용 방식
Figma는 컴포넌트·변수·의미 있는 레이어 이름·Auto Layout·annotation을 함께 쓸수록 코드 생성 컨텍스트가 명확해진다고 권장한다. 반대로 구조가 없는 Figma 파일에서는 MCP를 사용해도 에이전트의 추론 비중이 커진다.
MCP만으로 끝낼 수 없는 이유
MCP는 디자인의 기준을 전달하지만, 실제 브라우저의 결과를 대신 렌더링하지는 않는다. 전역 CSS, 상속, 실제 폰트, 이미지 로딩, 스크롤바, 부모 컨테이너의 제약은 코드베이스와 브라우저에서 결정된다.
그래서 MCP를 쓴 뒤에도 “배경색이 틀렸다”, “카드 프레임이 2px 작다”, “특정 폭에서 텍스트가 옆으로 넘친다” 같은 문제가 생길 수 있다. 이 차이는 스펙을 다시 읽는 일과 실제 화면을 비교하는 일을 함께 해야 잡을 수 있다.
같은 과제에서 공정하게 비교하는 방법
정확도라는 말을 쓰려면 구현 조건을 고정해야 한다. 아래 표는 이후 실험에서 실제 숫자를 채우기 위한 기준이다.
| 항목 | 고정 방법 |
|---|---|
| 대상 | 같은 Figma 프레임, 데이터, 원본 에셋 |
| 구현 조건 A | 스크린샷과 동일한 자연어 요청만 제공 |
| 구현 조건 B | 같은 요청 + Figma MCP 컨텍스트 + 에셋 제공 |
| 에이전트 | 동일 모델·동일 저장소·동일 시작 커밋으로 분리 실행 |
| 뷰포트 | Figma 프레임과 같은 CSS width × height |
| 브라우저 | 동일 Chromium 버전·OS·폰트·DPR |
| 상태 | 기본, hover, 메뉴 열림 등 비교할 UI 상태를 사전 정의 |
| 수정 횟수 | 최초 구현과 검증 후 수정 횟수를 분리 기록 |
측정값도 미리 고정한다.
| 지표 | 계산 방식 | 확인하는 오류 |
|---|---|---|
| 픽셀 차이 비율 | 다른 픽셀 수 ÷ 전체 픽셀 수 | 색·레이아웃의 전체 시각 오차 |
| 랜드마크 박스 오차 | Figma bounds와 DOM bounds의 평균 절대 오차 | 컨테이너·카드·버튼의 위치와 크기 |
| 타이포그래피 불일치 | font-size·weight·line-height·letter-spacing 중 불일치 수 | 겉보기만 비슷한 텍스트 오류 |
| breakpoint 통과율 | 문제 없는 viewport 수 ÷ 전체 viewport 수 | 가로 넘침·겹침·의도치 않은 줄바꿈 |
| 상태 커버리지 | 비교한 상태 수 ÷ 정의한 상태 수 | hover·open 상태 누락 |
아직 이 조건으로 두 구현을 여러 번 실행해 수치를 모으지는 않았다. 그래서 이 글은 “MCP가 몇 % 더 정확하다”는 결과를 주장하지 않는다. 대신 다음 실험에서 그 수치를 재현 가능하게 얻기 위한 비교 설계다.
C. 어느 한쪽을 고르는 대신, 브라우저 검증을 붙인다
여기서 agent-browser, Chrome DevTools, Chrome 확장 프로그램은 MCP의 경쟁자가 아니다. 이들은 결과를 실제로 확인하는 실행·검수 층이다.
- Chrome DevTools는 폭을 연속적으로 바꾸며 breakpoint 사이의 깨짐을 찾는다.
- agent-browser는 지정한 viewport와 hover 같은 상태를 재현해 캡처한다.
- Playwright는 기대 이미지·실제 이미지·diff를 저장해 다음 변경에서 회귀를 감시한다.
그림 2. Chrome Device Mode는 중간 폭에서 발생하는 줄바꿈·가로 넘침을 찾는 데 유용하지만, 실제 기기를 완전히 재현하지는 않는다. 출처: Chrome DevTools 문서
Chrome 문서가 설명하듯 Device Mode는 모바일 화면을 확인하기 위한 근사치다. 실기기 차이가 중요한 화면은 실제 기기 또는 원격 디버깅을 별도로 기록해야 한다.
그림 3. Playwright Trace Viewer는 기대 이미지·실제 이미지·diff를 나란히 확인해 수정해야 할 시각적 차이를 추적하는 검증 층이다. 출처: Playwright Trace Viewer 문서
Playwright의 `toHaveScreenshot()`은 현재 화면과 기준 스크린샷을 비교하고, `maxDiffPixels`·`maxDiffPixelRatio` 같은 허용 기준을 설정할 수 있다. 다만 브라우저 렌더링은 OS·브라우저 버전·폰트·환경에 따라 달라질 수 있으므로, 기준 이미지는 비교 이미지와 같은 환경에서 생성해야 한다.
그래서 어떤 조합이 가장 좋은가
현재 공개 문서와 실제 구현에서 확인할 수 있는 범위의 답은 다음과 같다.
| 단계 | 가장 적합한 입력·도구 | 이유 |
|---|---|---|
| 디자인 의도 읽기 | Figma MCP | 픽셀뿐 아니라 구조·변수·컴포넌트·에셋을 읽는다. |
| 빠른 시각 참조 | Figma 스크린샷 | 전체 분위기와 최종 구성을 빠르게 확인한다. |
| 코드 구현 | Codex 또는 Claude Code | 저장소의 기존 컴포넌트와 규칙을 적용한다. |
| 상태·반응형 확인 | agent-browser 또는 Chrome DevTools | 실제 브라우저에서 각 viewport와 상호작용을 재현한다. |
| 변경 후 회귀 감시 | Playwright | 기준·실제·diff를 반복 비교한다. |
정리하면, 스크린샷만 제공하는 방법은 빠른 초기 구현, Figma MCP는 정보 손실을 줄인 구현 기준, 브라우저와 Playwright는 실제 결과의 검증에 적합하다.
따라서 정확도를 높이는 방법은 둘 중 하나를 버리는 것이 아니다.
Figma MCP로 구조·토큰·에셋 확인
+ Figma 스크린샷으로 최종 시각 참조
+ Codex/Claude Code로 기존 코드베이스에 구현
+ agent-browser/Chrome으로 상태·반응형 캡처
+ Playwright로 diff와 회귀 검증다음 실험
다음 글에서는 이 설계를 실제 결과로 채우려 한다.
- 같은 Figma 화면을 스크린샷만으로 구현한다.
- 같은 화면을 Figma MCP 컨텍스트와 에셋으로 구현한다.
- 정해진 desktop·tablet·mobile viewport와 hover 상태에서 캡처한다.
- 픽셀 차이 비율, 박스 오차, breakpoint 통과율, 수정 횟수를 표로 비교한다.
- Figma MCP만 사용한 경우와 “MCP + 브라우저 검증”을 다시 분리해, 검증 단계가 줄이는 오류도 기록한다.
그 결과가 쌓이면 “어느 에이전트가 더 그럴듯했는가”가 아니라, 어떤 입력과 검증 조합이 어떤 오류를 얼마나 줄였는가를 근거로 말할 수 있다.
TODO: 실제 비교가 끝난 뒤, Figma 기준 이미지·스크린샷 기반 구현·MCP 기반 구현·diff 이미지와 측정 표를 추가한다.
References
- OpenAI — Introducing the Codex app — Codex의 Figma 디자인 컨텍스트·에셋·스크린샷 기반 UI 구현 스킬 설명을 참고했다.
- OpenAI — Codex and Figma launch seamless code-to-design experience — Codex와 Figma MCP의 코드↔캔버스 왕복 흐름을 참고했다.
- Anthropic — Connect Claude Code to tools via MCP — Claude Code가 MCP를 통해 Figma 디자인·에셋에 접근하는 방식을 참고했다.
- Figma MCP Server — Introduction — Figma MCP가 제공하는 디자인 컨텍스트의 범위를 참고했다.
- Figma MCP Server — The server keeps returning web/react code — MCP 컨텍스트가 생산용 코드를 직접 보장하지 않는다는 점을 확인했다.
- Figma MCP Server — Structure your Figma file for better code — 컴포넌트·변수·Auto Layout·annotation이 구현 컨텍스트에 미치는 영향을 참고했다.
- Playwright — Visual comparisons — 스크린샷 비교, 허용 오차, 실행 환경 고정의 근거로 참고했다.
- Playwright — Trace viewer — expected·actual·diff 이미지 확인 방식을 참고했다.
- Chrome DevTools — Simulate mobile devices with device mode — Device Mode의 용도와 실기기 대비 한계를 참고했다.
