"간격 8px 맞죠?" 질문 폭탄 끝! 개발자가 좋아하는 피그마 스펙 전달 가이드

"간격 8px 맞죠?" 질문 폭탄 끝! 개발자가 좋아하는 피그마 스펙 전달 가이드

"간격 8px 맞죠?" 질문 폭탄 끝! 개발자가 좋아하는 피그마 스펙 전달 가이드

기획서와 Figma 시안을 정성껏 정리해서 개발 전달을 마쳤는데, 며칠 뒤 슬랙이나 메신저로 이런 질문을 받아본 적 있으신가요?

“이 간격 8px 맞죠?” “폰트 사이즈가 14인가요, 16인가요?” “여기 패딩은 좌우가 다른 건가요?”

처음엔 친절하게 답을 하다가도 비슷한 질문이 반복되면 문득 이런 생각이 듭니다. “혹시 내 전달 방식에 문제가 있는 건 아닐까?”

사실 저도 그랬습니다. 반복되는 질문을 받을 때마다 제 소통 능력이나 꼼꼼함을 탓하며 스스로를 검열하곤 했죠. 하지만 수많은 프로젝트를 거치며 깨달은 사실이 있습니다. 이 문제는 개인의 소통 능력보다는 ‘Figma라는 도구를 활용한 스펙 전달 프로세스’의 문제인 경우가 훨씬 많다는 것입니다.

Figma로 작업했음에도 불구하고 간격, 여백, 폰트 같은 상세 스펙이 개발 환경에 맞춰 명확하게 전달되지 않으면, 커뮤니케이션 비용은 결코 줄어들지 않습니다.

그래서 이 글을 준비했습니다. 기획자이자 디자이너로서 제가 직접 겪은 시행착오를 바탕으로, 개발자가 다시 묻지 않게 만드는 오차 없는 Figma 스펙(폰트·여백) 추출 기준을 정리해 보겠습니다.

이 글을 읽으면 얻는 것
  • 왜 개발자가 간격·폰트를 다시 묻는지 구조적으로 이해할 수 있습니다
  • 개발자가 신뢰하는 스펙 전달 방식이 정리됩니다
  • 개발 전달 이후 질문과 수정 요청이 눈에 띄게 줄어듭니다
피그마 스펙 전달 가이드

1. 왜 개발자는 자꾸 “8px 맞냐”고 물어볼까?

디자이너와 기획자는 Figma 화면에서 보이는 숫자를 그대로 신뢰합니다. 하지만 개발자의 시선은 조금 다릅니다. 개발자에게 중요한 건 “지금 이 화면의 값”이 아니라 “코드로 구현할 때도 유지되는 규칙인가?”입니다.

예를 들어 Figma에서 두 요소 사이가 8px로 보일 때, 개발자는 속으로 이런 고민을 합니다.

  • 시스템인가?: 이 8px은 우리 서비스의 기본 그리드 시스템(8pt Grid)을 따르는 값인가?
  • 예외인가?: 디자인적 허용치로 이번에만 살짝 조정한 값인가?
  • 실수인가?: 마우스로 옮기다 1~2px 어긋난 오차인가?

의도(Intent)가 보이지 않으면, 개발자는 구현 단계에서 확신을 가질 수 없어 결국 “8px 맞나요?”라고 다시 물을 수밖에 없습니다.

피그마 8px 그리드 시스템과 측정선 예시

2. 폰트 스펙, ‘행간’과 ‘자간’이 개발자에게 암호인 이유

폰트 크기보다 더 헷갈리는 것이 바로 행간(Line-height)자간(Letter-spacing)입니다. Figma에서는 시각적으로 예뻐 보여도, 코드(CSS)로 옮겨지는 순간 전혀 다른 결과가 나올 수 있습니다.

  • 행간의 함정: Figma에서 px 단위로 고정된 행간은 폰트 사이즈가 바뀔 때마다 깨지기 쉽습니다. 개발자에게는 150%1.5 같은 비율(Unitless) 값이 훨씬 명확합니다.
  • 자간의 오해: 디자인을 위해 미세하게 조정한 자간이 시스템 규칙인지, 특정 문구에만 적용된 강조인지 구분되지 않으면 개발자는 일일이 코드를 수정해야 합니다.
  • 텍스트 박스의 높이: 폰트의 행간 때문에 생기는 상하 여백이 실제 요소 간격(Padding)에 영향을 주는지 명확히 해야 합니다.

이런 모호함이 쌓이면 개발자는 스펙을 '해석'해야 하고, 그 해석이 틀릴까 봐 질문을 던지게 됩니다.

3. 개발자가 사랑하는 Figma ‘오토 레이아웃’과 ‘여백’

개발자가 Figma를 신뢰하게 만드는 가장 강력한 무기는 오토 레이아웃(Auto Layout)입니다. 단순히 요소를 묶어주는 기능을 넘어, 오토 레이아웃은 다음 정보를 동시에 전달합니다.

  • 규칙의 박제: “이 요소들 사이는 항상 16px 간격을 유지한다”는 로직을 선언합니다.
  • 패딩의 명확화: 내부 여백을 눈대중이 아닌 수치로 고정하여 개발자가 CSS의 padding 값을 즉시 추출하게 돕습니다.
  • 가변성 대응: 텍스트 길이나 화면 크기가 변해도 구조가 유지된다는 확신을 줍니다.

반대로 오토 레이아웃 없이 좌표값으로만 배치된 여백은 개발자 입장에서 “참고용 그림”에 불과합니다. 코드로 옮길 때 일일이 계산기를 두드려야 하기 때문이죠.

4. 질문 폭탄을 멈추게 할 최종 체크리스트

  • 간격의 규칙: 모든 여백이 4나 8의 배수 등 정해진 시스템을 따르고 있는가?
  • 오토 레이아웃: 주요 컴포넌트가 좌표값이 아닌 오토 레이아웃으로 구성되었는가?
  • 폰트 스타일: 텍스트가 Figma 스타일(Local Styles)로 정의되어 있는가?
  • 행간/자간: 개발자가 복사하기 쉬운 비율 값이나 표준화된 수치를 사용했는가?
  • 상태별 정의: 버튼의 Hover, Disabled 등 상태별 디자인이 누락되지 않았는가?
Tip: "이 간격은 규칙입니다"라는 메모 한 줄보다, 오토 레이아웃 수치 하나가 개발자에게는 더 큰 확신을 줍니다.

마무리하며

개발자의 질문은 우리를 괴롭히려는 게 아니라, 완벽하게 구현하고 싶은 책임감에서 나옵니다.

Figma는 단순한 화판이 아니라, 디자인의 의도를 코드로 번역하기 전의 가이드북입니다. 그 의도가 수치와 시스템으로 보이기 시작하면 질문은 자연스럽게 줄어들고, 여러분의 협업 효율은 비약적으로 올라갈 것입니다.


여러분은 어떻게 생각하시나요?
이 글이 마음에 드시면 공감을 눌러 주세요.

📌 함께 보면 좋은 글
복붙 지옥 탈출
Figma 컴포넌트 라이브러리 ‘정리 규칙’ 7가지(실무 템플릿)
지금 바로 확인하기 →