Figma → Code, 디자이너가 직접 옮길 때 알아야 할 것들 #2

1편에서 실패를 정리했다면 이번 편은 그 실패에서 뽑아낸 패턴과 실전 노하우입니다.

클로드가 자주 놓친 것들

Figma MCP는 값을 읽긴 했지만 간격·색상·반응형 기준을 자주 다르게 해석했습니다.

특히 이미지 위치가 단순화되면서 문제가 발생했습니다. 디자인 균형을 위해 의도적으로 이미지 위치를 오른쪽으로 29px 조정했는데 해당 설정이 사라지면서 디자인 의도가 사라졌습니다.

같은 값을 세 번 다르게 가져오는 일도 잦았어요. 한 번 읽어서는 믿을 수 없었습니다. 그래서 노드 ID를 직접 찍어주는 방식이 가장 안전했어요. “이 프레임 안의 오른쪽 섹션”처럼 말로 설명하면 엉뚱한 곳을 보지만 레이어 우클릭 후 Copy link로 얻은 node-id 값을 전달하면 훨씬 정확하게 읽어옵니다.

# 잘못된 프롬프트 (자주 틀림)
"이 페이지 오른쪽 위 섹션의 카드 디자인 가져와"

# 정확한 프롬프트
"node-id=66:34264 노드의 디자인 컨텍스트를 가져와"

수정이 잦은 데는 몇 가지 패턴이 있었어요.

그러다 보니 나름의 원칙이 6개 생겼습니다.

6가지 원칙

원칙 1. 피그마를 먼저 정리하세요

클로드에게 던지기 전에 피그마 파일부터 정돈이 필요합니다. 레이어 이름 제대로(group4 같은 이름 금지), 오토레이아웃 꼼꼼하게, 디자인 토큰(컬러/타이포) 일관되게, 브레이크포인트별 프레임 분리 등.

정리되지 않은 피그마를 던지면 AI는 추측에 기반하여 작업합니다.

TIP

Figma 변수(Variables)는 CSS Variable로 export됐을 때 깨지는 경우가 있습니다. 색상 변수만 export하고 간격/타이포 변수는 직접 코드에 박는 방식이 안전했습니다.

원칙 2. 전체 말고 조각으로 만드세요

“전체 랜딩페이지 만들어줘”라고 하면 결과가 엉망입니다. 섹션 단위로 쪼개서 하나씩 눈으로 확인하며 진행해야 합니다.

TIP

“섹션 단위”의 정의가 핵심입니다. 시각적 단위(히어로/카드/푸터)가 아니라 상태/로직 단위로 쪼개야 합니다. 예: 리뷰 캐러셀은 시각적으론 한 섹션이지만 “자동 슬라이드 + 호버 일시정지 + 인디케이터 호버 전환” 3개 로직이 들어가서 따로 만들고 합치는 게 안전했습니다.

원칙 3. 감각 말고 숫자로 말하세요

“조금 더 왼쪽으로”보다 “20px 왼쪽으로”가 백 배 정확합니다. AI는 모호한 표현을 잘 해석하지 못합니다. 디자이너가 좋아하는 “여백이 좀 답답해”나 “톤이 애매해” 같은 표현은 클로드가 알아듣지 못합니다.

TIP

포지셔닝은 left-[Xpx]가 아니라 right-[Xpx]로 명시해야 합니다. 화면이 좁아질 때 우측 일러스트가 좌측으로 밀려들어가는 사고를 막을 수 있어요!

원칙 4. 디자이너의 눈으로 검증하기

코드가 정상적으로 동작한다고 해서 디자인이 정확하게 구현된 것은 아닙니다. 모든 브레이크포인트에서 실제 화면을 확인하고 피그마와 나란히 비교하며 디테일을 점검해야 합니다. 결국 마지막 디테일은 디자이너가 직접 눈으로 잡아야 합니다.

TIP

viewport별 캡처를 매번 손으로 안 찍고 Playwright로 자동화하면 작업이 훨씬 빨라집니다.

원칙 5. 수정 전에 원인을 먼저 물어보세요

AI가 만든 코드가 이상하게 동작할 때 바로 “다시 만들어줘”라고 하지 말고 먼저 원인을 묻는 게 더 빠릅니다. 모바일에서 요소가 안 보이면 “왜 안 보여?”라고 물어보면 AI가 원인을 분석해줍니다. 원인을 알아야 제대로 고칠 수 있습니다.

원칙 6. 한글 폰트 확인하기

AI는 영문 타이포에 비해 한글 처리가 약합니다. 자간(tracking), 행간(leading), 폰트 패밀리 fallback 등을 디자이너가 직접 지정해줘야 합니다.

TIP

Pretendard에서 한글 weight는 영문과 시각적 무게가 다릅니다. font-medium(500)이 영문에서는 적당해 보여도 한글에서는 가늘게 보입니다. 데스크탑 헤딩은 semibold(600), 모바일은 medium(500) 식으로 브레이크포인트별로 weight를 다르게 잡아야 시각 균형이 맞았어요.

+1. Codex와 병행하기

Claude Code만 쓰면 토큰이 금방 바닥납니다. 한 페이지 작업 중 컨텍스트가 누적되면 세션을 새로 열어야 하고 그때마다 프로젝트 컨텍스트를 처음부터 다시 알려줘야 했어요. 그래서 중간부터 Codex와 병행해서 작업했습니다.

제법 개발자 같죠? Claude Code 사용량이 금방 닳아서 Codex도 같이 띄워두고 작업했습니다.

결국 하나만 고집하기보다 역할별로 나눠 쓰는 게 훨씬 빨랐습니다.

보너스: 모션도 만들 수 있을까?

원칙을 정리하다가 한 번 더 시험해보고 싶었어요. Claude Code가 CSS 모션도 잘 만들까?

간단한 프롬프트 한 줄을 던져봤습니다.

공이 무한 계단을 통통 튀면서 올라가는 모션 만들어줘.

결과가 한 번에 깔끔하게 나왔습니다. 단일 HTML 파일에 CSS keyframes + SVG만 써서 의도한 모션이 그대로 구현됐어요.

머릿속으로 그려지는 움직임이면 AI한테 시켜도 되겠다는 감이 왔어요.

자주 쓴 프롬프트 3가지

원칙은 외우기 어렵지만 실제로 매일 썼던 프롬프트는 몇 개 안 됐어요. 그중에서도 가장 자주 쓴 3개를 공유합니다. [대괄호] 안만 본인 상황에 맞게 채우면 됩니다.

1. 새 섹션 추가

랜딩페이지 [/landing/web]에 새 섹션을 추가할게.
섹션 이름: [이름]
피그마 노드 ID: [ID]
위치: 기존 [섹션명] 바로 아래

Figma MCP로 3번 읽어서 값을 교차 검증한 뒤,
반응형 3단계(모바일/태블릿/데스크탑)에 맞게 구현해줘.

색상은 Tailwind 기본 클래스 쓰지 말고 hex 값으로 지정해줘.
예: bg-white (X), bg-[#ffffff] (O)

2. 에러 디버깅 (“고쳐줘”가 아니라 “원인부터”)

[증상 설명] 현상이 발생해.
원인을 먼저 분석해서 알려줘. 수정은 원인 파악한 뒤에 할게.

예: “모바일에서 이 섹션이 아예 안 보여. 원인이 뭘까?”

가장 자주 쓰던 디버깅 프롬프트입니다. “고쳐줘”라고 하면 같은 실수를 반복하지만 “왜 안 돼?”라고 물으면 원인을 분석해줘서 제대로 고쳐집니다.

3. 텍스트만 수정 (스타일 안 건드리게)

[/landing/web] 페이지의 히어로 카피를 수정할게.

기존: "[기존 카피]"
변경: "[새 카피]"

해당 부분만 바꿔주고, 다른 스타일은 건들지 말아줘.

“카피만 바꿔줘”라고만 하면 옆에 있는 패딩이나 색상까지 손대는 경우가 잦았어요. 범위를 명시하는 게 안전합니다.

자주 만난 함정 2가지

함정 1. 모바일에서 요소가 안 보일 때

증상: framer-motion 애니메이션 섹션이 모바일에서 렌더링 안 됨

원인: 99%는 opacity: 0 초기값 + whileInView 조합 문제. 모바일에서 viewport 감지가 한 박자 늦으면 once: true 옵션 때문에 영영 활성화 안 돼서 opacity 0으로 멈춥니다.

해결:

framer-motion의 initial 값에서 opacity를 제거해줘.
whileInView의 viewport 옵션을 { once: true, amount: 0.1 }로 설정해줘.

함정 2. Next.js Image가 우측 정렬 안 될 때

증상: right-0, position: absolute 설정했는데 왼쪽에 붙음

원인: Next.js Image의 fill prop이 left: 0을 강제로 지정함

해결:

Next.js Image 컴포넌트에 !left-auto 클래스를 추가해줘.

마치며

만드는 법을 익히는 데는 1주일, 운영에 올리는 법을 배우는 데는 며칠이 더 걸렸습니다. 다음 글에서는 만든 결과물을 실제 서비스에 올리기까지 겪은 배포 기록을 정리합니다.

---

시리즈 전체 보기

01   디자이너가 Claude Code로 랜딩 페이지 직접 배포하기 #1
02   Figma → Code, 디자이너가 직접 옮길 때 알아야 할 것들 #2
03   Next.js 앱을 GCS에 올리기까지: 디자이너의 배포 회고 #3