Figma MCP agent에게 Figma URL 하나를 던지고 “반응형으로 해줘”라고 하면 자주 깨진다. 문제는 구현력이 아니라 읽기 기준이 비어 있다는 점이다. 에이전트가 어떤 프레임을 기준으로 읽었는지, 모바일·태블릿·데스크톱 중 무엇을 source of truth로 삼았는지, 토큰과 raw value를 어떻게 구분했는지 알 수 없으면 결과도 검수할 수 없다.

이 글은 Figma MCP agent를 반응형 디자인 작업에 붙이며, Figma URL을 통째로 넘기는 대신 구간별 UI 변화와 적용 기준을 어떻게 정리했는지에 대한 회고다.

핵심은 Figma를 “전부 알아서 읽어라”로 던지는 게 아니라, 구간별 UI 변화 관찰 → 적용 기준 정리 → agent 전달 문장 순서로 좁혀 주는 것이다.

왜 “반응형으로 해줘”가 실패하는가

처음에는 모바일 시안만 있고, 나중에 태블릿·데스크톱 시안이 추가되는 경우가 많다. 이때 지시가 모호하면 agent는 세 가지를 추측한다.

  • 모바일 구조를 유지할지, 데스크톱 기준으로 다시 짤지
  • 태블릿부터 레이아웃이 바뀌는지, 단순히 max-width만 바뀌는지
  • Figma의 픽셀 값을 그대로 쓸지, 디자인 토큰으로 치환할지

이 추측이 틀리면 “대충 반응형은 됐는데 QA에서 다르게 보이는” 결과가 나온다. 그래서 먼저 구현 지시가 아니라 읽는 방법을 고정해야 한다.

1단계: Figma를 구간별로 읽는다

Figma MCP agent에게 파일 전체를 한 번에 맡기면 어느 프레임을 기준으로 삼았는지 흐려진다. 그래서 모바일·태블릿·데스크톱에서 UI가 어떻게 변하는지 먼저 구간별로 나눠 읽는다.

Figma 읽기 기준:
- URL을 통째로 넘기기보다 구현 대상 frame/node 또는 구간별 프레임을 좁혀 전달한다.
- 모바일 / 태블릿 / 데스크톱에서 같은 UI가 어떻게 달라지는지 먼저 비교한다.
- 먼저 frame hierarchy를 읽고, 그다음 스타일 값을 읽는다. 보이는 픽셀보다 구조가 우선이다.
- component instance면 원본 컴포넌트명과 override된 값만 구분해서 기록한다.
- auto layout, constraints, grid, max-width, padding, gap, hidden layer를 구간별로 비교한다.
- 색/폰트/간격은 raw value를 그대로 하드코딩하지 말고 token 매핑 가능성을 먼저 확인한다.
- 이미지·아이콘·카피처럼 구현에 필요한 asset은 누락 여부를 별도 목록으로 남긴다.
- 읽지 못한 값은 추측하지 말고 "확인 필요"로 남긴다.

여기서 중요한 건 순서다. agent가 먼저 구조를 읽고, 그다음 구간별 차이를 읽어야 한다. 픽셀 값부터 줍기 시작하면 프레임 간 공통 구조를 놓치고, 컴포넌트를 viewport별로 복붙하기 쉽다.

2단계: 구간별 UI 변화 적용 기준을 쓴다

읽기 결과가 나오면 구현 지시를 viewport matrix로 바꾼다. “반응형 처리” 같은 말은 금지한다. 유지할 것과 바뀔 것을 분리해야 한다.

목표:
기존 모바일 구현을 유지하면서 태블릿·데스크톱 시안을 추가 반영한다.

고정 계약:
- 모바일 360px 레이아웃은 회귀시키지 않는다.
- 컴포넌트 분리는 유지한다. viewport별 파일 복붙 금지.
- 색/간격/타이포는 디자인 토큰만 사용한다.
- Figma에서 확인하지 못한 값은 임의 추정하지 않고 확인 필요로 남긴다.

viewport matrix:
- 모바일: 1 column, full-width CTA, horizontal padding 20
- 태블릿: 2 column 가능, content max-width 지정, CTA는 카드 하단 유지
- 데스크톱: centered container, max-width 1200, CTA는 우측 summary 영역 고정

출력:
- 수정 파일 목록
- viewport별 변경 요약
- 확인한 화면 폭
- 남은 불확실성

이 계약의 목적은 agent에게 “예쁘게 맞춰라”가 아니라 무엇을 보존하고 무엇만 바꿀지를 주는 것이다. 그러면 agent는 새 화면을 다시 만드는 대신, 모바일 기준 구현 위에 태블릿·데스크톱 차이를 얹는다.

3단계: 티켓이 아니라 agent 전달 메모를 구체화한다

나는 티켓 자체를 breakpoint 단위로 쪼갠 적은 없다. 대신 agent에게 넘기는 메모에서 구간별 UI 변화와 적용 방식을 최대한 구체적으로 적었다. 티켓은 작업의 입구고, 실제로 agent 결과를 좌우한 건 그 안에 붙인 전달 메모였다.

나쁜 전달:

Figma 보고 상담신청 카드 반응형 처리해줘.

좋은 전달:

상담신청 카드에서 모바일은 CTA가 하단 full-width이고,
태블릿부터는 카드 폭이 제한되며,
데스크톱에서는 summary 영역 오른쪽에 CTA가 붙는다.

모바일 구조와 데이터 바인딩은 유지하고,
구간별로 바뀌는 max-width / column / CTA 위치만 반영한다.

전달 메모에는 네 가지를 반드시 넣는다.

  • 기준 구간: 모바일이 기준인지, 데스크톱 시안이 최종 기준인지
  • 구간별 UI 변화: 레이아웃·간격·노출 정보·CTA 위치
  • 유지해야 할 것: 이미 맞춘 모바일 동작, 접근성, 데이터 바인딩
  • 적용 방식: 새 컴포넌트 복붙인지, 기존 컴포넌트에 스타일 축만 추가하는지

이렇게 쓰면 리뷰도 감각 싸움이 아니라 변화 기준 확인이 된다. “느낌이 다르다”가 아니라 “태블릿 구간에서 CTA 위치 변화가 전달 메모와 다르다”처럼 말할 수 있다.

정리

Figma MCP agent 작업에서 병목은 “코드를 못 짠다”가 아니라 “무엇을 기준으로 읽고 구현해야 하는지 모른다”에 가깝다. 그래서 Figma URL 하나로는 부족하다.

필요한 건 세 가지다.

  1. 구간별 읽기 기준 — 어떤 프레임과 값을 어떤 순서로 읽을지
  2. 구현 적용 기준 — 모바일·태블릿·데스크톱에서 무엇을 유지하고 바꿀지
  3. agent 전달 메모 — 티켓보다 더 구체적인 UI 변화와 적용 방식

“반응형으로 해줘”를 “이 구간에서는 이렇게 UI가 변한다”로 바꾸는 순간, agent 결과물도 리뷰 가능한 작업물이 된다.