디자이너: "여기 간격 이상해요. 디자인이랑 달라요."
개발자: "최대한 비슷하게 했어요."
이 대화, 몇 번이나 해보셨어요? 폰트가 미묘하게 틀리고, 패딩이 2px 어긋나고, 컴포넌트 구조가 슬쩍 바뀝니다. 디자이너는 "이거랑 달라요"라 하고 개발자는 "최대한 맞췄어요"라 답하죠. 그리고 다음 화면에서 또 반복돼요. 92%의 디자이너와 91%의 개발자가 이 핸드오프 과정을 고쳐야 한다고 말합니다.
여기서 멈춰서 생각해볼 게 있어요. 우리는 지금까지 이 문제를 "번역을 더 잘하는 법"으로만 풀려고 했어요. Figma 플러그인, 디자인 토큰, 자동 코드 생성 — 전부 "디자인 파일을 코드로 더 정확하게 옮기자"는 시도였죠. 그런데 번역이라는 단계 자체가 오류의 근원이라면요?
Paper Desktop은 그 발상을 뒤집은 도구예요. 번역을 잘하는 게 아니라, 번역할 일 자체를 없애버리는 캔버스입니다.
번역을 없앤다는 건, 캔버스가 곧 코드라는 뜻
Figma는 자체 렌더링 엔진 위에서 돌아가요. 디자이너가 그린 화면은 Figma만 아는 독자 포맷이고, 개발자는 그걸 눈으로 보면서 HTML/CSS로 "재현"해야 하죠. 보는 것과 만드는 것이 다른 언어인 거예요. 그 사이 어딘가에서 간격이 달라지고 폰트가 틀려집니다.
Paper는 다릅니다. Figma처럼 생긴 무한 캔버스인데, 그 위에 놓는 모든 요소가 진짜 HTML 엘리먼트와 진짜 CSS 속성으로 렌더링돼요. 진짜 flexbox, 진짜 CSS 프로퍼티, 진짜 폰트 렌더링. 캔버스에서 보이는 픽셀과 브라우저가 그리는 픽셀이 애초에 같은 엔진의 같은 결과물이에요. 내보낼 때 번역할 게 없어요.
창업자 Stephen Haney가 내건 한 문장이 이걸 정확히 요약해요 — "Nothing gets lost in translation." 번역 단계가 없으니, 사라질 것도 없다는 거죠.
그리고 여기서 안 보이던 보너스가 하나 터집니다. LLM은 Figma 독자 포맷보다 DOM을 압도적으로 잘 읽어요. 즉 캔버스가 HTML 트리이기 때문에, AI 에이전트가 디자인을 "해석"하는 게 아니라 그냥 읽으면 됩니다. 이게 Paper의 두 번째 무기예요.
그래서 실제로 뭘 할 수 있냐면
이 "캔버스=코드 + 에이전트가 DOM을 읽음"이라는 두 축에서 네 가지 기능이 나와요.
1. HTML/CSS 네이티브 캔버스. 프레임, 텍스트, 이미지를 Figma처럼 배치하지만 내부는 HTML/CSS예요. 마음에 드는 요소를 골라 Copy as React나 Copy as Tailwind로 즉시 코드를 가져갈 수 있어요. 핸드오프 문서 따로 만들 필요가 없죠.
2. MCP 서버로 AI 에이전트 직결. Paper Desktop 앱을 켜면 MCP 서버가 자동으로 떠요. Cursor, Claude Code, Codex, GitHub Copilot, OpenCode 어디서든 붙여서 에이전트가 캔버스를 읽고 직접 그립니다. "이 히어로 섹션 디자인해줘" 하면 캔버스에 HTML 요소가 생겨요.
3. 실제 데이터 연동. Notion, Spotify API, CMS, 내부 DB — 에이전트에게 "이 프레임을 실제 데이터로 채워줘"라고 시키면 돼요. 더미 텍스트로 예쁘게 만들었다가 실제 콘텐츠 넣으니 레이아웃 박살 나는 그 사고가 사라집니다.
4. 셰이더 라이브러리. 메시 그래디언트, 리퀴드 메탈, 하프톤, 유리 효과 같은 GPU 가속 비주얼을 캔버스에 바로 얹어요. 영상으로 내보내기도 됩니다.
이미 비슷한 도구 많지 않나요?
맞아요, 디자인-투-코드 도구는 넘쳐요. 핵심 질문은 "캔버스가 진짜 웹 표준이냐, 아니면 또 다른 번역 레이어냐"입니다. 이 기준으로 줄을 세워볼게요.
| 기존 (Figma → 개발) | Paper Desktop | |
|---|---|---|
| 캔버스 엔진 | 독자 렌더링 엔진 (Figma 포맷) | HTML/CSS (웹 표준) |
| 코드 변환 | Figma → HTML 번역 필요 (핸드오프) | 번역 불필요, 캔버스 = 코드 |
| AI 에이전트 정확도 | 독자 포맷 해석 필요 | DOM 직접 읽기 (LLM 친화적) |
| 디자인↔코드 동기화 | 일방향 or 수동 업데이트 | 양방향 실시간 동기화 |
| 실제 데이터 | 더미 텍스트 후 나중에 교체 | API/DB에서 실제 데이터 바로 연결 |
| 버전 관리 | Figma 자체 히스토리 | Git 브랜치/머지 |
경쟁 도구들과도 나란히 놓아볼게요.
| 도구 | 초점 | 강점 | 약점 |
|---|---|---|---|
| Paper | HTML/CSS 캔버스 + MCP | 캔버스=코드, 에이전트 양방향 연결, 셰이더 | 오픈 알파, 컴포넌트 시스템 미완성 |
| Figma + MCP | 디자인→코드 + Code to Canvas | 성숙한 생태계, 대규모 팀 지원 | 독자 포맷 → 번역 필요 |
| MagicPath | AI 디자인 생성 → 코드 | 텍스트/이미지로 UI 생성, Figma 임포트 | 캔버스가 코드 네이티브가 아님 |
| Subframe | 캔버스 → React 코드 | 프로덕션급 React 코드, CLI 동기화 | React 전용, 범용성 부족 |
Figma도 Code to Canvas, Figma Make 같은 AI 기능을 빠르게 붙이고 있어요. 하지만 그건 여전히 독자 포맷 위에 번역 레이어를 한 겹 더 쌓는 방식이에요. Paper는 번역 레이어 자체가 없습니다. 디자이너가 캔버스에서 카피를 고치면 에이전트가 코드베이스로 돌려보내고, 개발자가 코드를 고치면 캔버스에 반영돼요. 소스 오브 트루스가 하나예요.
철학적으로도 한 발 더 나가요. 반응형 레이아웃, 스타일 변형, 일관성 체크 같은 반복 노동은 에이전트에게 넘기고, 사람은 에이전트가 판단 못 하는 결정에만 집중하자는 거죠. Paper는 이걸 "anti-slop"이라 부릅니다 — 보일러플레이트는 기계에게, 창의적 결정은 사람에게.
솔직히, 지금 당장 메인 도구로 쓰긴 이르다
Paper는 현재 오픈 알파예요. 컴포넌트 시스템(슬롯·프롭스)은 개발 중이고 CSS Grid는 아직 계획 단계입니다. Figma만큼 성숙하지 않아요. 다만 거의 매일 프로덕션에 배포하고 있고, Tailwind 팀과 네이티브 통합도 준비 중이에요. "디자인↔코드 왕복"이라는 새 워크플로우를 남보다 먼저 손에 익히고 싶다면, 지금이 가장 싸게(무료) 배울 타이밍이에요.
10분이면 첫 화면이 나옵니다
- Paper Desktop 다운로드
download.paper.design에서 데스크톱 앱을 설치해요. 무료 오픈 알파라 카드 등록 필요 없어요. 웹 버전(app.paper.design)도 있지만 MCP 서버는 데스크톱 앱에서만 돌아갑니다. - AI 에이전트 연결
Claude Code면 터미널에서 한 줄이면 끝이에요.claude mcp add paper --transport http http://127.0.0.1:29979/mcp --scope user
Cursor 사용자는 Paper 문서 페이지의 원클릭 설치 버튼을 누르면 됩니다. - 에이전트에게 첫 화면 시키기
파일을 열고 "Paper MCP 서버로 랜딩 페이지 히어로 섹션을 디자인해줘"라고 요청해요. 에이전트가 캔버스에 직접 HTML 요소를 그립니다. - 캔버스에서 직접 다듬기
프레임·텍스트·색상·레이아웃을 Figma처럼 시각적으로 수정해요. flexbox 컨테이너를 만들고 gap을 조절하고, 셰이더도 얹어보세요. 바꾼 내용은 에이전트가 코드에 반영합니다. - 코드로 내보내고 머지
"선택한 디자인을 React + Tailwind로 만들어줘"라고 하면 Paper MCP가 캔버스를 읽어 코드를 생성해요. 그대로 Git 커밋 → 브랜치 → 머지. 핸드오프 문서는 한 장도 안 만들었습니다.
