디자이너가 피그마에 화면을 잘 만들어두면 개발자는 그대로 구현하면 된다고 생각한 적이 있습니다. 하지만 실제 협업에서는 “그대로”라는 말이 생각보다 애매했습니다. 버튼 간격이 몇 px인지, 회색이 어떤 토큰인지, 아이콘을 SVG로 받을지 PNG 2x로 받을지 정하지 않으면 같은 화면을 보고도 서로 다르게 해석했습니다.
이번 글은 피그마 개발자 모드 사용법을 설명하는 글이 아니라, 2026년 2월 1일부터 2026년 2월 28일까지 4주 동안 실제 React 프로젝트에서 디자인 전달 오류를 줄여본 협업 후기입니다. 협업 환경은 Figma, Chrome, Slack, Notion, React 프로젝트였고, 참여 인원은 디자이너 1명, 프론트엔드 개발자 2명, 기획자 1명이었습니다.
처음에는 디자인 수치를 눈대중으로 맞췄다
작업한 화면 수는 24개, 컴포넌트 수는 68개, 확인한 디자인 프레임 수는 132개였습니다. 개발자 모드로 확인한 속성은 간격, 색상, 폰트, radius, shadow, asset export까지 총 6종이었습니다.
초반에는 개발자 모드를 열어보긴 했지만 모든 값을 꼼꼼히 확인하지 않았습니다. 버튼은 비슷해 보이면 구현했고, 카드 간격은 화면을 보며 맞췄고, 색상은 기존 CSS 변수 중 비슷한 값을 골랐습니다. 이렇게 하니 빠르게 만드는 것처럼 느껴졌지만 QA 단계에서 문제가 쌓였습니다.
초기 디자인 전달 오류는 22건이었습니다. 색상 값 불일치 오류는 7건, 간격 오류는 9건, 이미지 export 오류는 4건이었습니다. 나머지는 폰트 굵기, radius, shadow 차이였습니다.
가장 큰 실패: 버튼 padding 8px 차이로 6개 화면을 다시 수정했다
가장 크게 기억나는 실패는 버튼 padding이었습니다. 공통 버튼 컴포넌트를 만들면서 개발자 모드에서 정확한 spacing을 확인하지 않고 기존 버튼 스타일을 복사해 구현했습니다. 그런데 QA에서 실제 피그마 디자인과 비교하니 좌우 padding이 8px 차이가 났습니다.
문제는 이 버튼이 이미 6개 화면에 들어간 뒤였다는 점입니다. 버튼 하나만 고치면 끝날 줄 알았지만, 카드 안 버튼은 줄바꿈이 달라졌고, 하단 고정 버튼은 좌우 정렬이 틀어졌고, 모달 버튼은 폭이 어색해졌습니다. 결국 6개 화면을 다시 확인하면서 버튼 폭, 텍스트 위치, 주변 간격을 수정했습니다.
이후부터는 버튼, 카드, 입력창, 탭처럼 반복되는 UI는 구현 전에 반드시 개발자 모드에서 spacing, typography, radius를 먼저 확인했습니다. 애매한 값은 Slack으로 흘려보내지 않고 Figma 코멘트에 남겼습니다.
아이콘 export 기준이 없어 1x, 2x 파일이 섞였다
또 다른 실패는 아이콘 export였습니다. 초반에는 필요한 아이콘을 각자 내려받았습니다. 어떤 개발자는 1x PNG를 사용했고, 다른 개발자는 2x 파일을 받았습니다. 일부 아이콘은 SVG였고, 일부는 PNG였습니다. 화면에서는 비슷해 보여도 실제 구현 후에는 선명도와 크기가 조금씩 달랐습니다.
이 문제 때문에 이미지 export 오류가 4건 발생했습니다. 개선 후에는 1건으로 줄었습니다. 아이콘은 기본적으로 SVG를 우선 사용하고, 불가피하게 이미지 파일을 쓸 때는 배율과 파일명 규칙을 Notion에 남겼습니다. 피그마 개발자 모드에서 asset export 기준을 먼저 확인한 뒤 내려받는 방식으로 바꿨습니다.
디자인 전달 오류 개선표
| 오류 유형 | 개선 전 발생 횟수 | 원인 | 바꾼 소통 방식 | 개선 후 발생 횟수 | 실제 효과 |
|---|---|---|---|---|---|
| 색상 값 불일치 | 7건 | 비슷한 회색과 브랜드 컬러를 눈으로 구분 | color token을 개발자 모드에서 확인하고 Notion에 기록 | 2건 | 버튼, 배지, 경고 문구 색상 차이가 줄어듦 |
| 간격 오류 | 9건 | padding과 margin을 눈대중으로 구현 | spacing 값을 먼저 확인하고 애매한 부분은 Figma 코멘트로 질문 | 3건 | 카드, 버튼, 리스트 정렬 재작업이 줄어듦 |
| 이미지 export 오류 | 4건 | 1x, 2x, SVG, PNG 기준이 섞임 | asset export 기준을 정하고 아이콘은 SVG 우선 사용 | 1건 | 아이콘 선명도와 크기 차이가 줄어듦 |
| 폰트 적용 오류 | 3건 | 제목, 본문, 캡션 스타일을 개별 판단 | typography 기준을 컴포넌트별로 정리 | 0건 | 텍스트 계층 구조가 안정됨 |
| radius·shadow 차이 | 2건 | 카드 그림자와 모서리값을 임의 조정 | radius, shadow 값을 개발자 모드에서 확인 | 0건 | 카드 UI의 일관성이 좋아짐 |
QA 재작업 시간이 주 3시간 20분에서 1시간 05분으로 줄었다
개선 전 QA 재작업 시간은 주당 평균 3시간 20분이었습니다. 기능 버그보다 디자인 수치를 다시 맞추는 시간이 많았습니다. 버튼 간격, 카드 여백, 아이콘 export, 텍스트 줄 높이 같은 작은 차이가 쌓였습니다.
개발자 모드 확인 기준을 정한 뒤 QA 재작업 시간은 주당 평균 1시간 05분으로 줄었습니다. 완전히 사라진 것은 아니지만, 재작업 내용이 훨씬 구체적으로 바뀌었습니다. 예전에는 “뭔가 달라 보여요”라는 피드백이 많았다면, 이후에는 “이 카드 하단 간격만 16px이 아니라 20px로 맞추면 됩니다”처럼 바로 수정 가능한 피드백이 늘었습니다.
Slack 질문을 줄이고 Figma 코멘트를 늘렸다
초반에는 Slack 질문이 많았습니다. “이 색상 맞나요?”, “이 간격 몇 px인가요?”, “아이콘 어떤 파일로 받을까요?” 같은 질문이 계속 올라왔습니다. 문제는 Slack 대화는 시간이 지나면 찾기 어렵다는 점입니다.
개선 후에는 애매한 부분을 Figma 코멘트로 남겼습니다. 프레임 위에 바로 질문을 남기니 디자이너도 어떤 요소를 말하는지 바로 알 수 있었습니다. 결정된 기준은 Notion에 정리했습니다. Slack은 빠른 확인용, Figma는 화면별 질문용, Notion은 최종 기준 저장용으로 나눴습니다.
컴포넌트 재사용성도 좋아졌다
이번 프로젝트에서 다룬 컴포넌트 수는 68개였습니다. 초반에는 화면별로 버튼과 카드가 조금씩 달라졌습니다. 빠르게 구현한 것처럼 보였지만, 나중에 수정할 때는 오히려 시간이 더 걸렸습니다.
이후 버튼, 입력창, 카드, 리스트 아이템, 탭, 모달, 배지처럼 반복되는 요소는 먼저 개발자 모드에서 spacing, color token, typography, radius, shadow를 확인했습니다. 그다음 React 공통 컴포넌트로 묶었습니다. 덕분에 같은 스타일을 여러 화면에서 재사용하기 쉬워졌습니다.
비교 기준별 실제 체감
전달 오류 수
초기 디자인 전달 오류는 22건이었고, 개선 후에는 6건으로 줄었습니다. 특히 색상, 간격, export 오류 감소가 컸습니다.
QA 재작업 시간
주당 평균 3시간 20분이던 QA 재작업 시간이 1시간 05분으로 줄었습니다. 개발 전 확인 시간이 조금 늘었지만 전체 일정은 더 안정됐습니다.
컴포넌트 재사용성
68개 컴포넌트를 정리하면서 공통화할 요소가 더 잘 보였습니다. 개발자 모드의 수치를 기준으로 삼으니 재사용 컴포넌트 품질이 좋아졌습니다.
질문 횟수와 소통 방식
질문이 완전히 없어지지는 않았지만, 질문이 더 구체적으로 바뀌었습니다. 단순 확인보다 예외 여부를 확인하는 방식이 많아졌습니다.
구현 속도
초반에는 개발자 모드를 확인하는 시간이 추가되어 느려 보였습니다. 하지만 QA와 재수정을 포함하면 구현 속도는 오히려 빨라졌습니다.
결론: 피그마 개발자 모드는 협업 기준표로 써야 했다
2026년 2월 1일부터 2월 28일까지 4주 동안 피그마 개발자 모드를 실제 협업에 적용해본 결론은 분명합니다. 피그마 개발자 모드는 개발자가 디자인을 베껴 보는 도구가 아니라, 서로 다른 해석을 줄이는 협업 기준표로 써야 합니다.
이번 협업에서는 디자이너 1명, 프론트엔드 개발자 2명, 기획자 1명이 참여했고, 작업한 화면 수는 24개, 컴포넌트 수는 68개, 확인한 디자인 프레임 수는 132개였습니다. 개발자 모드로 확인한 속성은 간격, 색상, 폰트, radius, shadow, asset export까지 총 6종이었습니다.
초기 전달 오류는 22건이었지만, 개선 후에는 6건으로 줄었습니다. 색상 값 불일치 오류는 7건에서 2건, 간격 오류는 9건에서 3건, 이미지 export 오류는 4건에서 1건으로 감소했습니다. QA 재작업 시간도 주당 평균 3시간 20분에서 1시간 05분으로 줄었습니다.
가장 큰 실패는 버튼 padding을 눈대중으로 구현했다가 실제 디자인과 8px 차이가 나서 6개 화면을 다시 수정한 일이었습니다. 또 아이콘 export 기준을 정하지 않아 1x, 2x 파일이 섞인 경험도 있었습니다. 이 실수들이 반복된 뒤에야 spacing, color token, typography, asset export 기준을 먼저 확인하는 습관이 생겼습니다.
디자인 협업에서 중요한 것은 감각이 아니라 기준이었습니다. 같은 화면을 보고도 다르게 해석할 수 있기 때문에, 수치와 결정 내용을 남기는 방식이 필요했습니다.
피그마 개발자 모드로 전달하기 전 확인해야 할 체크리스트
- 개발자가 확인할 프레임이 최신 버전인지 확인했는가?
- 작업할 화면 수와 우선순위를 정했는가?
- spacing 값을 눈대중이 아니라 개발자 모드에서 확인했는가?
- color token 이름과 실제 색상값이 일치하는가?
- typography 기준이 제목, 본문, 캡션별로 정리되어 있는가?
- 버튼 padding, height, radius 기준이 공통 컴포넌트에 반영되어 있는가?
- shadow 값이 화면마다 다르게 적용되지 않았는가?
- 아이콘 export 기준이 SVG, PNG, 1x, 2x 중 무엇인지 정해져 있는가?
- 이미지 asset 파일명이 개발자가 알아보기 쉽게 정리되어 있는가?
- 애매한 디자인 판단을 Slack에만 남기지 않았는가?
- 화면별 질문은 Figma 코멘트에 남겼는가?
- 결정된 기준은 Notion 같은 문서에 다시 정리했는가?
- React 컴포넌트로 재사용할 요소와 화면별 예외 요소를 구분했는가?
- QA 전에 디자이너와 개발자가 같은 기준표로 화면을 확인했는가?
피그마 개발자 모드는 디자인을 자동으로 구현해주는 도구는 아니었습니다. 하지만 4주 동안 실제로 써보니, 디자이너와 개발자가 같은 숫자를 보고 이야기하게 만드는 데 큰 도움이 됐습니다. 결국 전달 오류를 줄이는 핵심은 더 많은 설명이 아니라, 같은 기준을 어디에 남기느냐였습니다.