피그마에서 Shift+A를 누르는 순간, 세상은 아름답습니다. 요소 세 개를 잡고 오토레이아웃을 걸면 간격 24, 좌우 패딩 36, 상하 패딩 8—숫자 몇 개만 넣으면 깔끔한 버튼이 뚝딱 만들어집니다. velog에 올라온 한 피그마 학습 글에서도 이 과정을 "재밌다!"라고 표현하더군요. 저도 동의합니다. 피그마 안에서는요.
문제는 이 버튼을 React 컴포넌트로 옮기는 순간 시작됩니다.
오토레이아웃 ≠ flexbox, 그 1px의 배신
피그마의 오토레이아웃은 CSS flexbox에서 영감을 받았다고 알려져 있지만, 사실 둘은 "사촌"이지 "쌍둥이"가 아닙니다. 구체적으로 깨지는 지점들을 짚어보면:
- 텍스트 렌더링 차이: 피그마의 Noto Sans KR Bold 20px과 브라우저의
font-size: 20px; font-weight: 700은 같은 숫자를 쓰지만 line-height, letter-spacing, 서브픽셀 렌더링이 다릅니다. 이게 상하 패딩 8px짜리 버튼에서는 1~2px 높이 차이로 바로 드러납니다. - 패딩 해석의 미묘한 갭: 피그마는 padding을 콘텐츠 바운딩 박스 기준으로 시각적으로 보여주지만, 브라우저는
box-sizing설정에 따라 border와 padding의 관계가 달라집니다.box-sizing: border-box를 빠뜨리는 순간 Corner Radius 20까지 같이 무너집니다. - 아이콘 정렬 문제: 피그마에서 아이콘-텍스트-이모지를 나란히 놓으면 오토레이아웃이
align-items: center처럼 동작하지만, 실제 SVG 아이콘의 viewBox 크기와 텍스트의 baseline이 만나면 시각적 중앙이 수학적 중앙과 어긋납니다. "Figma에서 볼 때는 괜찮았는데, 실제로 구현하면..." 하는 전형적인 케이스죠.
컴포넌트 등록까지 했는데, 왜 개발자는 다시 만드나
원문에서 버튼 사이즈 별로 컴포넌트를 등록하는 과정이 나옵니다. "컴포넌트는 다행히 무사히 등록 완"이라고 했지만, 사실 여기서 디자인-개발 핸드오프의 가장 큰 구조적 문제가 숨어 있습니다. 피그마 컴포넌트의 variant(사이즈별 S/M/L)가 프론트엔드 디자인 시스템의 variant와 1:1로 매핑되려면 Design Token이 필요합니다.
간격 24는 --spacing-6인가요, --spacing-lg인가요? 좌우 패딩 36은 시스템에 존재하는 토큰인가요, 아니면 디자이너가 즉흥적으로 넣은 값인가요? 이런 질문에 답이 없으면, 개발자는 피그마 Dev Mode에서 숫자를 하나하나 읽어 Tailwind 클래스(px-9? px-[36px]?)로 번역하는 수작업을 반복하게 됩니다.
AI가 이 갭을 줄일 수 있을까
dev.to에서 Jaideep Parashar가 쓴 AI 기반 래피드 프로토타이핑 글을 보면, "AI는 scaffolding을 생성하되, 핵심 아키텍처 결정은 내가 소유한다"는 원칙이 나옵니다. 이걸 디자인-개발 핸드오프에 대입하면 꽤 현실적인 워크플로우가 그려집니다.
- 피그마 오토레이아웃 → CSS 초안 생성: AI(Copilot, Claude 등)에게 피그마 Dev Mode의 JSON 속성을 던지고 flexbox 코드를 뽑게 합니다. 이건 "boring parts"에 해당하는 boilerplate 생성이니 AI가 잘하는 영역입니다.
- 시각적 회귀 검증은 사람이: 생성된 코드를 Storybook에 올리고, 피그마 시안과 1px 단위로 비교하는 건 여전히 사람의 눈—혹은 Chromatic 같은 비주얼 리그레션 도구—이 필요합니다.
- 토큰 불일치 탐지: AI에게 "이 padding 36px이 우리 디자인 토큰 시스템에 존재하는지 확인해줘"라고 질문하는 것만으로도, 시스템에 없는 임의 값이 코드에 스며드는 걸 막을 수 있습니다.
진짜 문제는 도구가 아니라 프로세스입니다
velog의 React+Express 학습 글에서 인상적이었던 문장이 있습니다. "처음부터 완벽하게 만들려고 하기보다, 작게 만들고 계속 다듬는 방식에 익숙해지는 게 더 중요하다." 이건 MVP 철학이지만, 디자인 시스템 구축에도 그대로 적용됩니다.
오토레이아웃으로 완벽한 피그마 컴포넌트를 먼저 100개 만들고 개발에 넘기는 "워터폴" 방식은 깨집니다. 대신:
- 버튼 하나를 피그마에서 만들고
- 즉시 CSS로 구현해서 차이를 확인하고
- 그 차이에서 토큰 규칙을 도출하고
- 다음 컴포넌트에 적용하는
이 "디자인-개발 피드백 루프"를 가능한 한 짧게 압축하는 게 핵심입니다. AI는 이 루프의 각 단계에서 시간을 단축해주는 가속기이지, 루프 자체를 없애주는 마법이 아닙니다.
시사점: Shift+A 이후가 진짜 시작입니다
피그마 오토레이아웃을 배우는 건 좋습니다. 하지만 사용자 입장에서 최종적으로 보는 건 피그마 화면이 아니라 브라우저입니다. font-size, line-height, box-sizing, align-items—이 CSS 속성 하나하나가 오토레이아웃의 시각적 약속을 지키거나 배신하는 지점입니다.
2026년 현재, Container Queries와 :has() 같은 새로운 CSS 기능이 브라우저에 안착하면서 피그마의 오토레이아웃이 표현하지 못하는 반응형 로직까지 CSS가 담당하는 영역은 오히려 넓어지고 있습니다. 디자인 도구와 브라우저의 갭은 줄어드는 게 아니라, 갭의 성격이 변하고 있는 것입니다.
Shift+A는 시작 버튼일 뿐입니다. 그 이후 1px을 잡는 건, 여전히 사람의 몫입니다.