피그마로 작업한 디자인, 개발자에게 깔끔하게 전달하는 방법

 

안녕하세요. 오늘은 피그마(Figma)로 작업한 디자인을 개발자에게 깔끔하게 전달하는 방법에 대해 정리해보려고 합니다.

디자인 자체는 잘 나왔는데, 막상 개발 전달 단계에서 커뮤니케이션이 꼬여서 수정이 반복되는 경험… 한 번쯤은 다들 있으셨을 거예요. 이 글에서는 실무에서 바로 써먹을 수 있는 기준 위주로 정리해볼게요.

---

1. “디자인 전달”은 파일 공유가 아니라 의도 전달

많은 디자이너들이 링크 하나 던져주고 “피그마 보시면 됩니다”로 끝내는 경우가 많아요. 하지만 개발자 입장에서는

• 이 화면이 최종인지
• 어떤 컴포넌트가 재사용 대상인지
• 예외 케이스는 어디까지 고려됐는지
• 를 알기 어렵습니다.

👉 핵심은 ‘왜 이렇게 디자인했는지’까지 전달하는 것이에요.

---

2. 페이지 구조 정리하기

개발 전달용 피그마 파일에는 최소한 아래 구조를 추천해요.

• 📁 00_Guide
  • 컬러, 타이포, 그리드, 공통 규칙
• 📁 01_Components
  • 버튼, 인풋, 카드 등 재사용 컴포넌트
• 📁 02_Screens_Web / Mobile
  • 실제 구현 화면
• 📁 99_Archive (또는 Draft)
  • 이전 시안, 폐기안

이렇게만 나눠도 “이게 최신인가요?”라는 질문이 거의 사라집니다.

---

3. 컴포넌트는 반드시 Component + Variant로

개발자가 가장 좋아하는 피그마 파일 특징 중 하나가 컴포넌트 정리입니다.

• 버튼: default / hover / disabled / loading
• 인풋: empty / focus / error / success
• 카드: type A / B / C

👉 상태별로 Variant를 만들어두면

개발자는 “이 상태를 조건문으로 처리하면 되겠구나” 하고 바로 이해해요.

이름 규칙도 중요

• ❌ Button1, Button2
• ⭕ Button / Primary / Disabled
•  

---

4. Auto Layout은 선택이 아니라 필수

Auto Layout 없이 만든 디자인은 개발자에게 거의 “참고 이미지” 수준입니다.

• padding 값이 명확한가?
• 콘텐츠 길이에 따라 늘어나는 구조인가?
• 좌우 정렬 기준이 일관적인가?

👉 Auto Layout을 잘 써두면 개발자는

CSS Flex / Grid 구조를 거의 그대로 가져갈 수 있어요.

---

5. Inspect 패널 기준으로 다시 한 번 체크

전달 전에 꼭 Inspect 모드로 본인 디자인을 다시 보기 추천합니다.

체크리스트:

• 폰트 사이즈, line-height 값이 이상하지 않은지
• color가 임의값(#111111, #121212 등)으로 섞여 있지 않은지
• 간격이 7px, 13px 같은 애매한 값은 없는지

👉 이 단계에서 한 번만 정리해도 개발 QA 시간이 확 줄어요.

---

6. 주석은 “친절할수록 좋다”

피그마 코멘트나 텍스트로 이런 내용은 꼭 남겨주세요.

• “이 영역은 스크롤”
• “모바일에서는 숨김 처리”
• “데이터 없을 때 empty state”
• “텍스트 최대 n줄, 이후 말줄임”

개발자는 디자인을 추측하면서 구현하는 직업이 아닙니다.

명확할수록 결과물이 좋아져요.

---

7. 인터랙션은 Prototype으로 최소한만

모든 애니메이션을 다 만들 필요는 없지만,

• 모달 열림/닫힘
• 탭 전환
• 버튼 클릭 흐름

이 정도는 Prototype으로 보여주면 충분합니다.

👉 “이건 말로 설명해야 하나?” 싶으면

그냥 프로토타입으로 한 번 만들어두는 게 제일 빠릅니다.

 

---

8. 최종 전달 체크리스트

전달 전에 아래만 체크해보세요.

☐ 최신 시안이 명확한가
☐ 컴포넌트/Variant 정리됐는가
☐ Auto Layout 적용됐는가
☐ 컬러/폰트 토큰 통일됐는가
☐ 주석으로 예외 케이스 설명했는가
☐ “이대로 개발하면 된다”는 확신이 드는가

 

개발자가 좋아하는 피그마 파일의 핵심

“어디를 보면 되는지, 어디는 안 봐도 되는지가 명확한 파일”

그래서 포인트는 딱 3가지예요.

1. 최신 화면이 한눈에 보일 것
2. 재사용 단위가 분리돼 있을 것
3. 구현 기준을 추측하지 않아도 될 것

---

✅ 실제로 많이 쓰이는 피그마 파일 구조 예시

📁 Pages 구조 (왼쪽 패널)

🟢 00_Guide
🟢 01_Components
🟢 02_Screens_Web
🟢 03_Screens_Mobile
⚪ 99_Archive

개발자 기준으로 보면

02, 03만 보면 되고 / 99는 무시 / 00, 01은 참고 구조입니다.

 

---

1️⃣ 00_Guide (설계 기준 페이지)

👉 “이 프로젝트의 디자인 규칙 설명서”

여기에는 화면을 만들지 않습니다.

기준만 모아두는 페이지예요.

포함하면 좋은 것

• Color Token
  • Primary / Secondary / Gray scale
• Typography
  • Font / Size / Line-height / Weight
• Spacing 기준
  • 8px rule / 주요 padding 값
• 공통 규칙
  • Radius, Shadow, Divider 사용 기준

💡 개발자는 여기서

변수 / 토큰 / 스타일 시스템을 뽑아갑니다.

 

---

2️⃣ 01_Components (개발자가 제일 좋아함)

구성 예시

• Button (Component + Variant)
  • Primary / Secondary
  • Default / Hover / Disabled / Loading
• Input
  • Empty / Focus / Error / Success
• Card / Modal / Toast / Tab

중요 포인트

• 전부 Component로 만들 것
• 상태는 Variant로만 표현할 것
• Auto Layout 필수

개발자 입장에서는

“아, 이건 컴포넌트화해서 재사용하면 되는구나”

라고 바로 판단됩니다

---

3️⃣ 02_Screens_Web (실제 구현 화면 – 웹)

👉 개발자가 가장 많이 보는 페이지

구성 방식 추천

• 한 화면 = 한 프레임
• 화면 이름에 상태 명시

예시

Home_Default
Home_Empty
Home_Error

Login
Login_Error

MyPage_Default

꼭 지켜야 할 것

• 최종 화면만 배치
• 설명용 주석은 텍스트 or 코멘트로
• 컴포넌트는 여기서 분해하지 않기

💡 개발자는

Inspect 보면서 CSS / 레이아웃 그대로 옮깁니다.

---

4️⃣ 03_Screens_Mobile (모바일은 분리)

👉 웹/모바일 섞여 있으면 바로 불편해짐

• 웹과 동일한 네이밍 유지
• 모바일 전용 예외 케이스 명확히 표시

예시

Home_Mobile
Home_Mobile_Scroll
Home_Mobile_Empty

주석 예시

• “모바일에서만 노출”
• “웹에서는 숨김”

---

5️⃣ 99_Archive

👉 “이전 시안 여기 있습니다” 용도

• 폐기안
• 과거 버전
• 테스트 시안

중요

• 회색 프레임 사용
• “ARCHIVE” 텍스트 크게 표시

개발자가 실수로 옛날 시안 보고 구현하는 사고를 막아줍니다.

---

🔎 개발자가 특히 좋아하는 디테일

✔ Inspect 기준 값이 깔끔함

• 폰트 사이즈 정돈
• 컬러 값 통일
• 간격 값 규칙적

✔ Auto Layout 구조가 논리적

• padding / gap 명확
• 콘텐츠 늘어나도 깨지지 않음

✔ 주석이 현실적

• “이건 스크롤”
• “데이터 없을 때”
• “n줄 이후 말줄임”

---

📌 개발자 입장에서 이 파일을 보면 드는 생각

“이 디자이너는

내가 뭘 헷갈릴지 알고 미리 막아놨다”

이 느낌이 들면

👉 협업 만족도, 결과물 퀄리티가 확 올라갑니다.