Figma와 협업하면서 생긴 프론트엔드 개발자의 고충

Figma 협업 프론트엔드 고충 ⏱ 읽는 시간 약 9분

"hover 색상은 느낌으로요"
Figma 협업의 현실

디자이너는 완성됐다고 했다. 개발자 입장에서 완성이 아닌 이유를 여섯 가지로 정리했다

입사 초기에는 Figma가 신세계였다. 디자인 시안이 한눈에 보이고, 스펙 수치도 클릭 한 번이면 확인됐다. "이제 개발이 쉬워지겠다"는 생각을 했다. 그게 얼마나 순진한 생각이었는지는 첫 번째 기능 개발을 하면서 바로 알았다.

Figma 파일을 열었다. 모바일 화면이 없었다. hover 상태가 없었다. 컴포넌트마다 간격 수치가 달랐다. 색상은 디자인 토큰이 아니라 전부 HEX 하드코딩이었다. 그리고 가장 인상적인 건 — 디자이너 슬랙 메시지: "나머지는 개발자분이 알아서요 😊"

Figma 자체가 나쁜 게 아니다. 협업 방식이 문제였다. 2년 동안 다양한 디자이너와 일하면서 쌓인 고충들을 솔직하게 정리했다.

Figma와 협업하면서 생긴 프론트엔드 개발자의 고충

6가지

가장 자주 겪은
Figma 협업 고충

3배

스펙 불명확 시
개발 시간 증가 체감

47%

개발 중 디자이너에게
재확인이 필요했던 비율

0개

현 팀 합의 후
재확인 발생 횟수/월

 

고충 6가지 — 실제 슬랙 대화와 함께

01

PAIN 01

모바일 시안이 없다 — "알아서 줄이면 되죠"

데스크톱 시안은 완벽하게 나왔다. 그런데 모바일 화면이 없었다. 슬랙으로 물어보니 돌아온 대답이 "그냥 줄이면 되지 않아요?"였다. 반응형 레이아웃은 단순히 줄이는 게 아니다. 네비게이션이 햄버거 메뉴로 바뀌고, 카드 그리드가 1열로 재구성되고, 폰트 사이즈 체계가 달라진다. 이 결정들을 개발자가 임의로 하면 나중에 "이거 제가 생각한 거랑 달라요"가 된다.

📐 Figma (받은 것)

데스크톱 1440px 1개
모바일 없음
태블릿 없음
브레이크포인트 미정의

💻 개발에 필요한 것

모바일 375px 시안
태블릿 768px (선택)
브레이크포인트 명시
변경되는 레이아웃 명시

결과: 개발자가 임의 판단 → 나중에 수정 요청

02

PAIN 02

인터랙션 스펙이 없다 — "느낌으로 해주세요"

버튼의 hover 색상, 클릭 시 애니메이션, 포커스 상태, 로딩 스피너 속도. Figma 기본 플랜에서는 프로토타입이 제한적이라 정적 화면만 나오는 경우가 많았다. "hover는 어둡게 해주시면 될 것 같아요"는 스펙이 아니다. 얼마나 어둡게? transition은 몇 ms? ease-in인지 ease-out인지? 이 결정들이 전부 개발자한테 내려왔다.

📐 실제로 받은 슬랙

"hover 시 좀 어둡게요"
"클릭하면 튀어나오는 느낌"
"로딩은 자연스럽게요"
"포커스는 브라우저 기본으로"

💻 실제로 필요한 스펙

hover: #6d28d9, 200ms ease
active: scale(0.97), 100ms
loading: 1.2s linear spin
focus: 2px solid #a855f7

결과: 구현하고 "이거 제 생각이랑 달라요" 반복

03

PAIN 03

디자인 토큰이 없다 — 컬러가 37가지

Figma 파일에서 색상을 확인하다가 보라색이 몇 개인지 세어봤다. #7c3aed, #7b38ec, #7d3bee… 비슷하게 생긴 보라색이 다섯 개였다. 디자이너가 작업하다 조금씩 다르게 쓴 것들이었다. CSS 변수 체계가 없으면 개발자는 이 중 어느 게 "공식 primary"인지 모른다. 나중에 컬러 변경이 생기면 하드코딩된 HEX를 전체 검색해서 바꿔야 한다.

 

 

 

실제 Figma에서 추출한 색상들 — 어느 게 primary?

/* Figma에서 아이드롭퍼로 찍은 색상들 */
const purples = [
  '#7c3aed', // 버튼
  '#7b38ec', // 카드 테두리
  '#7d3bee', // 헤더 배경 (1px 차이...)
  '#7c3bec', // 링크 색
  '#7e3aed', // 아이콘 fill
];

/* 디자인 토큰이 있었다면 */
/* --color-primary: #7c3aed; 끝 */

결과: 컬러 변경 요청 시 전수 검색, 누락 발생

04

PAIN 04

스펙 단위가 px 고정 — rem이 뭔지 모른다

Figma는 기본적으로 px 단위다. 그런데 웹 접근성과 사용자 폰트 크기 설정을 위해 폰트는 rem을, 레이아웃 간격은 상황에 따라 em이나 %를 쓰는 경우가 많다. "폰트 16px"를 그대로 받아서 font-size: 16px로 구현하면 사용자가 브라우저 기본 폰트 크기를 바꿔도 반응이 없다. 디자이너 입장에서 px와 rem의 차이를 알아야 할 이유가 없지만, 이걸 개발자가 혼자 판단하면 추후 의견 충돌이 생긴다.

📐 Figma 스펙

font-size: 16px
padding: 24px 16px
gap: 12px
border-radius: 8px

💻 개발자가 변환한 것

font-size: 1rem (16px)
padding: 1.5rem 1rem
gap: 0.75rem
border-radius: 0.5rem

결과: 변환 기준 합의 없이 개발자마다 달라짐

05

PAIN 05

개발 중에 시안이 바뀐다 — "조금 수정했어요"

개발 착수 후 3일 뒤, Figma 링크를 열었더니 시안이 바뀌어 있었다. 버튼 위치가 이동했고, 카드 레이아웃이 달라졌다. 슬랙엔 "UI 조금 다듬었어요 😊"라는 메시지 하나. "조금"의 범위가 개발자와 디자이너 사이에 전혀 다르다. 개발자 입장에선 이미 짠 코드를 상당 부분 다시 짜야 하는데, 디자이너 입장에선 Figma에서 드래그 몇 번이었을 것이다. 변경 사항 히스토리가 없으면 무엇이 달라졌는지 전수 비교해야 한다.

해결책: Figma 변경 시 반드시 변경 내역을 슬랙에 명시 → 팀 합의

06

PAIN 06

에러 / 빈 상태 / 로딩 화면이 없다

Figma에는 "정상적인 데이터가 있는 상태"만 설계돼 있었다. 그런데 실제 서비스에는 데이터가 없는 빈 상태(Empty State), API 에러 상태, 스켈레톤 로딩 화면이 전부 필요하다. 이 화면들을 개발자가 임의로 만들면 나중에 "이거 디자인이 있어야 하는데 왜 마음대로 만들었어요?"가 된다. 반대로 묻지 않고 기다리면 일정이 밀린다. 진퇴양난.

🚨

Figma 시안에 없는데 개발에 필요한 상태들
로딩 스켈레톤 · API 에러 화면 · 데이터 없음(Empty State) · 입력값 유효성 오류 · 권한 없음(403) · 네트워크 끊김 · 이미지 로드 실패 · 무한 스크롤 끝

결과: 개발자가 임의 구현 → 디자인 일관성 붕괴

 

디자이너 탓이 아니다 — 프로세스 문제였다

여기까지 읽으면 "디자이너가 문제네"라고 생각할 수 있다. 실제로 함께 일한 디자이너들은 전부 실력 있는 분들이었다. 문제는 디자인-개발 사이에 명확한 협업 프로세스가 없었다는 것이었다.

디자이너 입장에서 Figma는 "시각적 완성도"를 위한 도구다. 모바일 시안이 없는 게 디자이너 잘못이 아니라, 핸드오프 기준에 "모바일 시안 필수"가 명시돼 있지 않아서였다. 인터랙션 스펙이 없는 건 디자이너가 게을러서가 아니라, 어디까지 스펙에 담아야 하는지 개발자와 한 번도 이야기한 적이 없어서였다.

"Figma 협업의 고충은 도구 문제가 아니라, 도구를 사용하기 전에 나눴어야 할 대화가 없었던 문제였다."

— 현 팀에서 협업 프로세스를 정비하면서 든 생각

 

현 팀에서 실제로 개선한 것들

이직 후 새 팀에서 디자이너와 처음 만났을 때, 협업 방식을 먼저 이야기했다. 개발자 입장에서 필요한 것들을 정리해서 공유했다. 이걸 계기로 팀 핸드오프 가이드라인을 만들었다. 그 이후로 재확인 슬랙 메시지가 80% 줄었다.

문제	이전	지금
반응형 시안	데스크톱만 제공	375px·1440px 필수 + 브레이크포인트 명시
인터랙션 스펙	"느낌으로요"	프로토타입 or 인터랙션 노트 필수 첨부
컬러 / 토큰	HEX 하드코딩	Figma Variables로 토큰 관리 + CSS 변수 매핑
단위 기준	전부 px, 개발자 임의 변환	px→rem 변환 기준표 팀 문서화
시안 변경 시	조용히 수정, 알림 없음	변경 항목 슬랙 명시 필수 (개발 착수 후)
빈/에러 상태	없음, 개발자 임의 구현	체크리스트 8개 상태 핸드오프 전 확인 필수

 

핸드오프 전 체크리스트 — 지금 팀에서 쓰는 것

📋

개발 착수 전 디자이너와 확인하는 체크리스트

레이아웃
☐ 모바일(375px) 시안 있음
☐ 브레이크포인트 명시됨
☐ 각 해상도별 레이아웃 변경 사항 설명됨

컴포넌트 상태
☐ Default / Hover / Focus / Disabled / Active 상태 있음
☐ 로딩 / 에러 / 빈 상태 화면 있음
☐ 입력 유효성 오류 상태 있음

스펙
☐ 인터랙션 (transition 속도, easing) 명시됨
☐ 색상이 Variables(토큰)로 관리됨
☐ 폰트 사이즈·weight 일관성 확인됨

프로세스
☐ 개발 중 시안 변경 시 슬랙 공지 동의됨

✅

개발자가 먼저 할 수 있는 것들
① 첫 협업 전에 "개발에서 필요한 스펙 목록"을 문서로 공유하기
② Figma Dev Mode 활용 — 자동으로 CSS 값 추출 가능한 것은 직접 확인
③ "이 부분 스펙이 없어서 임의로 구현했는데 확인해주세요"를 습관화 — 사후 보고가 사전 승인보다 낫다
④ 반복되는 재확인 슬랙이 있다면 → 프로세스 개선 이야기를 꺼낼 타이밍이다

Figma 협업 고충의 99%는 서로가 상대방의 작업 방식을 잘 몰라서 생긴다. 개발자가 디자인 도구의 한계를 이해하고, 디자이너가 CSS 구현의 필요 정보를 이해하면 — 그 교집합 지점에서 협업 프로세스가 만들어진다. 그게 도구보다 훨씬 중요하다는 걸, 2년 고생 후에야 알았다.

---

💬 Figma 협업에서 가장 힘들었던 경험은 뭔가요?

비슷한 고충을 겪고 계신 프론트엔드 개발자분들, 혹은 반대로 "개발자가 이런 걸 원하는지 몰랐다"는 디자이너분들의 이야기도 댓글로 들려주세요. 특히 팀에서 실제로 효과 있었던 협업 프로세스가 있다면 정말 궁금합니다. 🙏