Figma와 Production 사이의 격차: Handoff가 실패하는 이유와 Design Systems가 해결하는 방법

Source: Dev.to

위에 제공된 소스 링크 아래에 번역할 텍스트를 알려주시면, 해당 내용을 한국어로 번역해 드리겠습니다.

디자이너‑개발자 격차

그 느낌을 아시죠. 지난 2주 동안 Figma에서 새로운 기능을 다듬어 왔습니다:

• 자동 레이아웃이 완벽합니다.
• 컴포넌트 상태가 꼼꼼히 정리되어 있습니다.
• 마이크로 인터랙션까지 프로토타이핑해서 드롭다운이 정확히 어떻게 열릴지 보여줍니다.

자부심과 약간의 흥분을 안고 이를 엔지니어링 팀에 넘깁니다.

현실

두 스프린트가 지난 뒤, 스테이징 환경에서 구현된 모습을 보게 됩니다:

• 폰트 굵기가 잘못되었습니다.
• 패딩이 일관되지 않습니다.
• 한 시간 동안 완벽히 다듬은 호버 상태가 전혀 없습니다.
• 그 드롭다운? 애니메이션 없이 바로 나타납니다.

티켓을 올리거나 스크린샷에 빨간 원을 그려 슬랙으로 보냅니다. 개발자는 이렇게 답합니다:

“아, 우리가 쓰는 라이브러리에서는 그 애니메이션을 지원하지 않아요,”
“파일에서 그 상태를 못 봤어요.”

당신의 작업이 벽을 넘어 던져지고, 전송 과정에서 뒤섞이며, 원본 디자인을 흐릿한 팩스로 본 누군가에 의해 다시 만들어진 느낌이 듭니다.

양쪽이 모두 좌절하는 이유

• 디자이너는 “픽셀 경찰”이 된 듯한 느낌을 받습니다. 간격과 색상에 대해 끊임없이 지적하고, 기술적인 어휘—또는 직접 고칠 수 있는 능력—이 있으면 좋겠다고 생각합니다.
• 개발자는 동적인 인터페이스의 정적인 그림만 받습니다. 레이아웃이 다양한 화면 크기에 어떻게 반응하는지, 데이터가 로드되지 않을 때는 어떻게 되는지 추측해야 합니다. 디자인 파일마다 약간씩 달라서, 티켓을 마무리하기 위해 해킹적인 오버라이드를 작성해야 합니다.

문제는 디자이너가 코딩을 못하거나 개발자가 디자인 감각이 부족해서가 아니라, 우리가 서로 다른 언어를 사용하고 있기 때문입니다.

격차 메우기

이 글은 핸드오프 모델을 넘어 디자인과 코드가 단일 진실의 원천을 공유하는 워크플로우를 수용하는 방법에 대해 다룹니다. 우리는 Figma 스티커 시트에 불과하지 않고 엔지니어가 실제로 신뢰할 수 있는 프로덕션‑레디 라이브러리인 디자인 시스템을 어떻게 구축할 수 있는지 살펴볼 것입니다.

전통적인 선형 워크플로우

1. 디자인이 진행 → 멈춤.
2. 개발이 시작 → 배포.
3. 핸드오프가 배턴을 넘기는 순간.

현대 웹 개발에서는 이 모델이 근본적으로 깨져 있습니다.

왜일까요? Figma 파일은 진실이 아니라 진실의 그림이기 때문입니다.

Figma에서는 다음을 할 수 있습니다:

• 인스턴스를 분리한다.
• 16진수 코드를 수동으로 조정한다.
• 버튼을 오른쪽으로 두 픽셀 이동한다.

이 모든 작업이 기본 시스템을 변경하지는 않습니다. 하지만 브라우저는 관대하지 않습니다. 논리, 구조, 체계적인 규칙을 요구합니다.

디자인 시스템을 순수히 디자인 산출물로만 취급하면 드리프트가 발생합니다—실제 제품이 디자인 파일과 점점 달라지는 이유는:

• 개발자가 문서화되지 않은 결정을 내린다.
• 디자이너가 코드를 저장소에 반영하지 않은 변경을 가한다.

그 결과? 매직 넘버(임의의 픽셀 값)로 가득 찬 코드베이스와 자신의 작업이 무시당한다고 느끼는 디자인 팀이 생깁니다.

디자인 시스템 재고

디자인 시스템을 제품으로 생각하세요. 두 가지 고객을 위한 서비스입니다:

1. 디자이너 – 프로토타입 제작에 사용.
2. 개발자 – 기능을 배포하는 데 사용.

디자인 엔지니어링 소개

전체 스택 엔지니어일 필요는 없지만 UI가 브라우저에 어떻게 전달되는지는 이해해야 합니다.

정적 라이브러리를 기능 시스템으로 전환하기 위한 청사진

1. 공유 어휘 만들기

• 현재 상태:

  • 색상은 단순히 헥스 코드일 뿐입니다.
  • #0052CC = “Primary Blue”(디자이너) vs. 문자열(개발자).

• 문제:

  • 다음 달에 그 파란색을 어둡게 하면, 개발자는 모든 헥스 코드를 찾아‑바꿔야 합니다—놓치기 쉬워서 일관성이 깨집니다.

• 해결책 – 디자인 토큰:

  • 값에 시맨틱 이름을 부여합니다.
  • 예시: color-action-primary, spacing-md.

결과: Figma에서 값을 수정하면 → 스크립트가 자동으로 코드 저장소의 CSS 변수나 JSON 파일을 업데이트합니다.
전환: 원시 값을 사용해 디자인하지 말고 의도에 맞게 디자인합니다(예: “16 px 패딩” 대신 “표준 컨테이너 간격”).

2. 디자인과 코드 구조 정렬

• 마찰 지점: 디자이너는 “스크린”으로 생각하고, 개발자는 “컴포넌트”로 생각합니다.

• 예시:

  • 디자이너가 User Profile Card를 만든다.
  • 개발자는 Avatar, Typography, Button variant, Container를 본다.

• 문제:

  • Figma 버튼 컴포넌트에 “Type”( Primary/Secondary ) 속성이 있다.
  • React 컴포넌트는 variant( filled/outlined ) prop을 기대한다.

• 해결책: API(Application Programming Interface)를 정렬한다.

  • 디자이너는 변형을 React prop과 맞추어 구조화한다.
  • 개발자는 디자이너 의도를 오버라이드 없이 처리할 수 있도록 컴포넌트를 유연하게 만든다.

전환: 디자이너는 코드 명명을 반영하도록 배우고, 개발자는 명확하고 일관된 prop을 제공한다.

3. 개발자가 작업하는 곳에 문서화

대부분의 디자인 시스템 문서는 무덤(PDF나 오래된 Confluence 페이지)으로 전락합니다.
좋은 문서는 개발자가 작업하는 곳에 존재합니다—예: Storybook.

• 격리된 상태에서 코드 컴포넌트를 확인합니다.
• 브라우저에서 실제로 컴포넌트가 어떻게 동작하는지에 대한 단일 진실 소스가 됩니다.
• 코드에서 생성된 문서는 거짓말을 할 수 없으며, 더 이상 사용되지 않는 prop은 자동으로 사라집니다.

디자이너를 위해: 컴포넌트 스토리와 함께 Markdown(또는 MDX)으로 문서에 기여합니다.

모두 합치기

1. Figma → 코드를 동기화하는 토큰 파이프라인을 생성합니다.
2. 코드베이스에서 사용되는 컴포넌트 계층 구조와 명명 규칙을 반영하도록 Figma 파일을 구조화합니다.
3. 디자인 노트, 사용 가이드라인, 시각적 예시를 위해 Markdown/MDX를 사용하여 Storybook에 컴포넌트를 문서화합니다.
4. 협업적으로 반복합니다: 디자이너가 Figma에서 토큰을 조정하고, 개발자는 실시간 컴포넌트 라이브러리에서 즉시 변경 사항을 확인합니다.

디자인과 코드가 동일한 진실의 원천을 공유할 때, “핸드오프”는 핸드온 협업으로 바뀌며 디자이너와 개발자 간의 격차가 크게 좁혀집니다.

MDX가 슈퍼 파워인 이유

MDX를 사용하면 사용 지침(예: “페이지당 기본 버튼을 한 번 이상 사용하지 마세요”)을 개발자가 복사하는 코드 예제 바로 옆에 작성할 수 있습니다.

디자이너의 두려움: Git, 터미널, & 버전 관리

• Figma에는 버전 기록이 있지만, 종종 혼란스럽습니다.
• Git은 변경 사항을 제안하고, 검토하며, 병합하는 구조화된 방법을 제공합니다.

이 워크플로우를 상상해 보세요

1. 디자이너가 아이콘 세트를 업데이트하고 싶어합니다.
2. ZIP 파일을 보내는 대신 시스템에 branch를 생성합니다.
3. 자산을 업데이트하고 pull request를 제출합니다.
4. 개발자가 이를 검토하고, 자동 테스트가 실행된 뒤, 변경 사항이 병합됩니다.

이것이 거버넌스입니다. 다음 질문에 답합니다:

• 시스템을 변경할 수 있는 사람은 누구인가?
• 오래된 제품을 깨뜨리지 않도록 어떻게 버전 관리할까?
• 변경 사항을 어떻게 전달할까?

Source: …

The Shift

From “I updated the Figma file, hope you see it” → “I released v1.2.0 of the system.”

If you’re a designer thinking, “I signed up to design, not to write JSON and manage Git branches,” that’s a fair concern.

The Industry Is Moving

The most valuable designers today can bridge the gap between design and engineering. They’re often called:

• Design Engineers
• Design Systems Leads

When you understand how the frontend works, you stop designing things that are impossible or expensive to build. You start designing systems that scale, gaining engineers’ respect because you’re delivering solutions—not just pictures.

This expertise separates a mid‑level designer from a senior or staff designer.
It’s the difference between earning $85 k and $130 k+.

Front‑End 개발자를 위한

이 방면을 마스터하는 것도 똑같이 강력합니다:

• “티켓 테이커”가 되는 것을 멈춥니다.
• 제품 프로세스에서 파트너가 됩니다.
• 디자인 의도를 이해하므로 코드를 한 줄도 작성하기 전에 UX 문제를 잡을 수 있습니다.
• 디자이너들이 함께 일하고 싶어하는 엔지니어가 됩니다.

코스 소개

Figma에서 프로덕션까지: 개발자가 실제로 사용하는 디자인 시스템 구축

팀마다 같은 단절을 보면서 이 코스를 만들었습니다. 단순히 Figma에서 예쁜 컴포넌트를 만들거나 React 컴포넌트를 작성하는 것이 아니라, 그들을 연결하는 접착제에 관한 것입니다.

6주 동안 할 일

Outcome: 최종적으로 배포된 npm 패키지, 문서 사이트, 그리고 포트폴리오 작품을 갖게 되어 채용 담당자에게 “나는 단순히 목업을 디자인하지 않는다. 시스템을 배포한다.” 라고 말할 수 있습니다.

이 강의는 다음과 같은 분들을 위해

1. 불만을 가진 제품 디자이너 – 왜 결정이 내려지는지 이해하고, 직관적인 컴포넌트 API를 만들며, 디자인‑엔지니어 역할로 전환하고 싶어합니다.
2. 디자인에 관심 있는 프론트‑엔드 개발자 – 디자인 분야를 배우고, 디자이너와 같은 언어로 소통하며, 제품 개발의 진정한 파트너가 되고 싶어합니다.

왜 중요한가

디자인과 개발 사이의 격차는 다음과 같은 곳에서 발생합니다:

• 제품이 사라진다
• 버그가 생긴다
• 일정이 폭발한다
• 팀이 번아웃한다

하지만 이것은 가장 큰 커리어 기회이기도 합니다.

만약 당신이 다리를 놓는 사람—토큰, 거버넌스, 그리고 컴포넌트 아키텍처를 이해하는 사람—이 된다면, 필수적인 존재가 됩니다. 도구와 팀원과의 싸움을 멈추고, 의도한 대로 정확히 보이고 작동하는 것을 만들기 시작합니다.

디자인을 벽 너머로 던지는 일을 그만두고 싶나요?

함께 실제적인 무언가를 만들어봅시다.

지금 등록하세요:
From Figma to Production: Building Design Systems That Developers Actually Use → (link to enrollment)