책에 포함된 노트Cursor로 일하는 법: 에이전트 시대의 솔로 메이커 워크플로우

UI 작업: Design Mode와 Figma MCP

2026-05-06Views 12약 6분생성형 AI 활용

Summary

UI 작업은 이미지 복사가 아니라 상태 구현이다

Cursor로 UI를 만들 때 가장 흔한 실수는 스크린샷 하나를 붙여 놓고 "이렇게 만들어줘"라고 요청하는 것이다. 결과는 빠르게 나온다. 하지만 대개 어딘가 어긋난다. 간격이 미묘하게 다르고, 모바일에서 깨지고, 버튼 hover 상태가 없고, 로딩 중에는 레이아웃이 흔들린다. 겉으로는 비슷하지만 제품으로 쓰기에는 부족한 UI가 된다.

프론트엔드 작업에서 목표는 "대충 비슷한 화면"이 아니다. 목표는 디자인 의도와 동작 조건을 만족하는 화면이다. 그러려면 UI를 하나의 이미지가 아니라 여러 상태의 묶음으로 봐야 한다.

예를 들어 로그인 카드 하나를 만든다고 해도 필요한 상태는 많다.

기본 상태
입력 중 상태
유효성 오류 상태
제출 중 loading 상태
서버 오류 상태
disabled 상태
모바일 폭 상태
키보드 focus 상태
스크린리더가 읽을 label 상태

Agent나 Design Mode는 이런 상태를 자동으로 완벽히 추측하지 못한다. 그러므로 UI 작업을 맡길 때는 "화면을 만들어줘"가 아니라 "이 조건을 만족하는 컴포넌트를 만들어줘"라고 요청해야 한다.

UI 작업: Design Mode와 Figma MCP AI 생성 이미지

스크린샷을 줄 때 함께 줘야 하는 것

스크린샷, 목업, 현재 화면 이미지는 좋은 컨텍스트다. 하지만 이미지만으로는 부족하다. 이미지에는 의도가 없다. Agent는 보이는 픽셀을 바탕으로 추측할 뿐이다.

따라서 스크린샷을 줄 때는 다음 정보를 함께 적는다.

기준 브라우저 크기: 예를 들어 1440x900, 1024x768, 390x844
레이아웃 구조: 상단 바, 사이드바, 콘텐츠 영역, 카드, 버튼 그룹
간격 기준: 카드 간격, 내부 padding, 섹션 margin
색상 기준: 프로젝트 토큰 사용 여부, 하드코딩 금지 여부
타이포그래피: 제목, 본문, 보조 텍스트의 크기와 굵기
상태: hover, focus, disabled, loading, error, empty
반응형 기준: 어느 breakpoint에서 몇 열이 몇 열로 바뀌는지
접근성 기준: label, aria, 키보드 이동 순서

좋은 요청은 이런 식이다.

첨부한 스크린샷을 기준으로 대시보드 카드 목록 UI를 구현해줘.

조건:
- 기준 viewport는 1024x768이야.
- 기존 Button, Card, Badge 컴포넌트를 먼저 찾아서 재사용해.
- 색상과 spacing은 globals.css의 design token을 사용하고 임의 hex 값은 추가하지 마.
- 카드 hover 시 shadow만 한 단계 올리고 layout shift는 없어야 해.
- 데이터가 없을 때 empty state를 보여줘.
- API 로딩 중에는 skeleton을 보여줘.
- 모바일 640px 이하에서는 1열로 쌓이게 해.
- 키보드 tab 이동과 focus ring이 보여야 해.
- 구현 후 브라우저에서 console error가 없는지 확인해.

이 정도로 적으면 Agent가 해야 할 일이 분명해진다. 단순한 시각 복제에서 제품 UI 구현으로 작업 수준이 올라간다.

Design Mode는 초안 생성 도구로 다룬다

Design Mode는 화면 초안을 빠르게 만드는 데 유용하다. 새 랜딩 페이지, 빈 상태 화면, 설정 페이지, 카드형 목록처럼 시각 구조가 중요한 작업에서 특히 빠르다. 하지만 Design Mode의 결과물을 최종본으로 보면 안 된다.

Design Mode가 잘하는 일은 첫 번째 형태를 만드는 것이다. 사람이 빈 파일에서 시작하지 않게 해 준다. 반대로 Design Mode가 놓치기 쉬운 것은 기존 코드베이스의 관습, 실제 데이터 흐름, 접근성, 예외 상태, 테스트 기준이다.

그래서 Design Mode를 쓸 때도 바로 "구현해줘"보다 먼저 분석을 시킨다.

이 디자인을 바로 구현하지 말고 먼저 분석해줘.

1. 화면을 어떤 컴포넌트로 나눌지
2. 기존 코드에서 재사용할 컴포넌트가 있는지
3. 필요한 상태값이 무엇인지
4. 반응형에서 깨질 수 있는 지점은 어디인지
5. 구현 전에 확인해야 할 모호한 점은 무엇인지

그다음 구현 범위를 작게 나눈다. 예를 들어 "전체 결제 화면"을 한 번에 맡기지 말고, 요금제 카드 → 결제 요약 → 쿠폰 입력 → 결제 버튼 상태 → 오류 상태처럼 나눈다. UI는 눈에 보이는 작업이라 크게 맡기고 싶지만, 실제로는 상태가 많아서 작게 나눌수록 안전하다.

Figma MCP로 디자인 맥락 가져오기

Figma MCP는 Cursor가 Figma 파일의 구조, 컴포넌트, 변수, 레이아웃 데이터 같은 디자인 정보를 읽을 수 있게 해 준다. Figma는 대부분의 사용자에게 원격 MCP 서버 사용을 권장하며, Cursor에서는 Figma 플러그인을 설치하고 Tools & MCP에서 인증을 완료하는 방식으로 연결할 수 있다.¹

연결이 끝나면 프롬프트에 Figma 링크를 넣거나, Figma에서 선택한 영역을 기준으로 작업을 요청할 수 있다. 예를 들어 다음처럼 쓴다.

이 Figma 프레임을 기준으로 PricingCard 컴포넌트를 만들어줘.
[figma-link]

단, 새 디자인 시스템을 만들지 말고 기존 components/ui의 Card, Button, Badge를 사용해.
Figma의 색상 값은 프로젝트 token에 매핑하고, 없는 token이 있으면 먼저 알려줘.

또는 이렇게 요청할 수 있다.

Figma의 현재 선택 영역을 참고해서 기존 SettingsPanel의 헤더 영역만 수정해줘.
코드 수정 전에 어떤 컴포넌트를 바꿀지 먼저 설명해줘.

Figma MCP는 디자인 소스를 코드 쪽으로 가져오는 통역사에 가깝다. Figma의 레이어 구조를 그대로 React 컴포넌트 구조로 옮기라는 뜻은 아니다. 디자이너가 보기 좋게 정리한 레이어와 개발자가 유지보수하기 좋은 컴포넌트 구조는 다를 수 있다.

또한 Figma MCP로 생성한 코드는 대개 초안에 가깝다. 새 컴포넌트를 만드는 데는 유용하지만, 이미 복잡하게 진화한 기존 코드에 정확히 녹여 넣는 작업은 추가 지시와 수동 검토가 필요하다. 여러 프레임이 연결된 플로우도 한 번에 완성된 제품 흐름으로 나오기보다, 프레임별 생성 후 상태 관리와 전환 로직을 따로 연결해야 하는 경우가 많다.²

따라서 Figma MCP를 쓸 때는 항상 다음 후속 요청을 붙인다.

생성된 코드를 프로젝트 기준에 맞게 리팩터링해줘.

- 기존 컴포넌트 재사용
- design token 사용
- 중복 CSS 제거
- 접근성 속성 추가
- loading/error/empty 상태 보강
- 모바일 breakpoint 확인
- console error 없는지 브라우저에서 검증

브라우저를 Agent의 눈으로 만든다

UI 구현은 코드만 봐서는 끝나지 않는다. 브라우저에서 실제로 열어 봐야 한다. Cursor의 내장 브라우저나 BrowserToolsMCP, Playwright MCP를 연결하면 Agent가 화면 상태를 더 구체적으로 관찰할 수 있다.

특히 BrowserToolsMCP는 console logs, console errors, XHR network logs, XHR network errors, screenshot, 선택한 DOM 요소 정보를 가져오는 도구를 제공한다.³ 이 정보는 UI 디버깅에서 매우 중요하다. 화면이 깨졌을 때 원인이 CSS인지, API 실패인지, hydration error인지, 잘못된 props인지 구분할 수 있기 때문이다.

UI 작업의 기본 루프는 다음과 같다.

로컬 앱 실행
브라우저에서 대상 페이지 열기
console error 확인
network 실패 확인
스크린샷 캡처
DOM 또는 선택 요소 확인
코드 수정
같은 조건으로 다시 확인

프롬프트는 이렇게 쓸 수 있다.

로컬 앱의 /dashboard 페이지를 브라우저에서 열어줘.

확인할 것:
- console error가 있는지
- 실패한 network 요청이 있는지
- 카드 목록이 1024x768 viewport에서 overflow 없이 보이는지
- empty state에서 버튼 focus가 가능한지

문제가 있으면 바로 수정하지 말고,
원인 후보와 수정할 파일을 먼저 정리해줘.

중요한 점은 "보고 고쳐줘"가 아니라 "무엇을 보고 어떤 기준으로 판단할지"를 알려 주는 것이다. 브라우저는 Agent에게 눈을 달아 주지만, 판단 기준은 사람이 줘야 한다.

매번 같은 조건에서 시각 검증하기

UI 검증은 같은 조건에서 반복해야 의미가 있다. 어제는 1440px 화면에서 보고, 오늘은 1280px 화면에서 보면 변경 때문인지 viewport 때문인지 알 수 없다.

Playwright MCP를 쓰면 browser_navigate, browser_resize, browser_take_screenshot 같은 도구로 페이지 이동, 브라우저 크기 조정, 스크린샷 저장을 자동화할 수 있다. 한 예로 1024x768 같은 고정 viewport에서 PNG 스크린샷을 남기고, baseline과 current 이미지를 비교하는 방식이 가능하다.⁴

프로젝트에 다음 폴더를 두면 관리하기 쉽다.

/screenshots
  dashboard-baseline.png
  dashboard-current.png

/diffs
  dashboard-2026-05-22.png

그리고 Agent에게 이렇게 요청한다.

Playwright MCP로 다음 순서대로 UI를 검증해줘.

1. /dashboard로 이동
2. viewport를 1024x768로 설정
3. screenshots/dashboard-current.png로 스크린샷 저장
4. baseline과 비교해서 차이가 큰 영역을 설명
5. overflow, 정렬, spacing, 반응형 깨짐을 우선 확인
6. 수정이 필요하면 변경 계획을 먼저 제안

픽셀 차이를 0으로 만드는 것이 목적은 아니다. 실제 제품에서는 폰트 렌더링, OS, 브라우저 차이로 완벽한 일치는 어렵다. 목적은 의도하지 않은 변화, 정렬 깨짐, 간격 불일치, overflow, 모바일 붕괴를 빨리 발견하는 것이다.

시각 diff는 "뭔가 이상한데?"라는 감각을 구체적인 피드백으로 바꿔 준다. 솔로 메이커에게 이 과정은 디자이너, QA, 프론트엔드 리뷰어의 일부 역할을 대신한다.

Acceptance Criteria에 보이는 것과 동작하는 것을 함께 넣기

UI 기능의 acceptance criteria는 픽셀 유사도만으로 끝나면 안 된다. 예쁜데 동작하지 않는 화면은 실패한 UI다. 반대로 동작은 하지만 사용자가 이해하기 어려운 화면도 실패한 UI다.

다음 항목을 함께 넣는다.

Acceptance Criteria

- 1024x768 viewport에서 기준 목업과 주요 정렬, 간격, 계층이 일치한다.
- 640px 이하에서는 카드가 1열로 표시되고 가로 스크롤이 생기지 않는다.
- loading 상태에서 skeleton 또는 명확한 로딩 표시가 보인다.
- 데이터가 없으면 empty state와 다음 행동 버튼이 보인다.
- API 실패 시 error state가 보이고 재시도할 수 있다.
- 모든 form input에는 label 또는 aria-label이 있다.
- 키보드 Tab으로 주요 액션에 접근할 수 있다.
- focus ring이 시각적으로 보인다.
- disabled 버튼은 클릭되지 않고 이유를 알 수 있다.
- 브라우저 console error가 없다.
- 실패한 network 요청이 예상된 테스트 상황 외에는 없다.

이 기준을 먼저 적으면 Agent는 CSS만 만지지 않는다. 필요한 경우 상태 모델, API 에러 처리, 컴포넌트 props, 접근성 속성까지 함께 본다.

UI 작업 프롬프트 패턴

실전에서는 다음 패턴을 반복하면 된다.

목표:
첨부한 Figma 프레임을 기준으로 BillingSettings UI를 구현한다.

컨텍스트:
- Figma 링크: [link]
- 기준 viewport: 1024x768
- 관련 파일: @app/settings/billing/page.tsx @components/billing
- 기존 UI 컴포넌트는 @components/ui를 우선 사용

제약:
- 새 디자인 토큰을 임의로 만들지 말 것
- 결제 로직은 수정하지 말 것
- UI와 상태 표시만 수정할 것
- console error가 없어야 함

상태:
- 기본 상태
- loading 상태
- 결제수단 없음 empty state
- API 실패 error state
- disabled 상태

진행 방식:
1. 먼저 구현 계획을 작성
2. 모호한 점 질문
3. 승인 후 작은 단위로 구현
4. 브라우저에서 1024x768 스크린샷 캡처
5. console/network 오류 확인
6. 결과와 남은 차이를 요약

이 프롬프트의 핵심은 네 가지다. 무엇을 만들지, 무엇을 건드리지 말아야 하는지, 어떤 상태를 포함해야 하는지, 어떻게 검증할지를 모두 포함한다.

마무리 체크리스트

UI 작업을 끝내기 전에 다음을 확인한다.

스크린샷이나 Figma 링크만 던지지 않고 구현 기준을 함께 적었는가?
기준 viewport와 breakpoint를 명시했는가?
hover, focus, disabled, loading, error, empty 상태를 확인했는가?
기존 컴포넌트와 design token을 재사용했는가?
Figma MCP 결과물을 초안으로 보고 리팩터링했는가?
브라우저에서 console error와 network error를 확인했는가?
같은 viewport에서 변경 전후 스크린샷을 비교했는가?
키보드 접근성과 label/aria를 확인했는가?
모바일에서 overflow가 없는가?

Cursor로 UI를 만든다는 것은 AI에게 화면을 그리게 하는 일이 아니다. 디자인, 코드, 브라우저, 로그, 스크린샷을 하나의 루프로 묶는 일이다. 이 루프가 있으면 솔로 메이커도 "대충 비슷한 UI"에서 멈추지 않고, 실제 사용자가 만질 수 있는 화면까지 밀고 갈 수 있다.

참고

¹Cursor and Figma: Set up the MCP server

²Cursor + Figma MCP Server

³Quickstart - AgentDesk - BrowserToolsMCP

⁴AI-Driven Design Workflow: Playwright MCP Screenshots, Visual Diffs, and Cursor Rules

책 목록

Cursor로 일하는 법: 에이전트 시대의 솔로 메이커 워크플로우

전체 목차 보기