한 장으로 끝내자: 개발 전달 스펙 체크리스트 PDF/이미지(간격·폰트·여백) 저장용 템플릿
한 장으로 끝내자: 개발 전달 스펙 체크리스트 PDF/이미지(간격·폰트·여백) 저장용 템플릿
안녕하세요! 지난 포스팅에서 🔎 개발자가 좋아하는 피그마 스펙 전달 가이드를 소개해 드렸는데, 다들 실무에 잘 적용해보고 계신가요?
가이드대로 정성껏 준비해서 전달했는데도, 막상 핸드오프를 마치고 나면 왠지 모르게 마음 한구석이 불안할 때가 있습니다. '혹시 뭐 하나 빠뜨린 건 없나?' 싶을 때쯤, 아니나 다를까 개발자분께 이런 DM이 날아오죠.
"이 화면 간격 8px 맞나요?" "여기 폰트가 14px인가요, 16px인가요?" "좌우 여백이 미묘하게 다른데 의도하신 건가요?"
질문 자체가 나쁜 건 아니지만, 문제는 이런 소소한 확인 과정이 반복되면서 내 소중한 집중력은 깨지고 전체 일정은 조금씩 밀리기 시작한다는 점입니다. 분명 가이드를 잘 만든 것 같은데 왜 이런 일이 생길까요? 그건 바로 스펙이 '개발자가 한눈에 훑어볼 수 있는 핵심 요약본' 형태로 정리되어 있지 않기 때문입니다.
그래서 이 글에서는 간격·폰트·여백처럼 가장 자주 엇갈리는 스펙을 한 장(PDF/이미지)으로 정리해 저장해두고, 개발 전달 전에 3분만 점검하면 질문 폭탄을 줄일 수 있는 저장용 체크리스트 템플릿을 제공합니다.
- 개발 전달 전 “빠뜨린 스펙”을 한 장으로 빠르게 점검할 수 있습니다
- 간격·폰트·여백 질문이 줄어들어 커뮤니케이션 시간이 단축됩니다
- 팀원에게 공유 가능한 PDF/이미지 체크리스트로 전달 품질이 일정해집니다
📚 목차
왜 “한 장 체크리스트”가 개발 전달을 바꾸는가
개발자는 “지금 화면에서 보이는 값”보다 규칙으로 구현 가능한 기준을 원합니다. 그런데 전달 내용이 흩어져 있으면, 개발자는 확신이 없어 다시 묻게 됩니다.
한 장 체크리스트는 스펙을 “찾는 작업”이 아니라 “확인 작업”으로 바꿉니다. 특히 간격·폰트·여백처럼 실수가 잦은 영역은 전달 전에 체크만 해도 질문이 확 줄어듭니다.
저장용 템플릿: 개발 전달 스펙 체크리스트(간격·폰트·여백)
✅ 개발 전달 전 3분 체크
아래 항목을 한 장에 담아 PDF/이미지로 저장해두고, 매번 전달 전에 체크하세요.
1) 간격(Spacing) 체크
- [ ] 핵심 간격 규칙(예: 4/8/12/16px 등)이 정해져 있다
- [ ] 같은 컴포넌트는 화면이 달라도 간격이 동일하다
- [ ] 오토 레이아웃으로 간격/패딩이 관리된다
- [ ] 예외 간격은 “왜 예외인지” 한 줄로 표시했다
2) 여백(Padding/Margin) 체크
- [ ] 좌/우 패딩이 동일한지(또는 의도적으로 다른지) 명확하다
- [ ] 컨테이너(카드/모달/섹션)의 기본 패딩이 통일되어 있다
- [ ] 리스트/그리드의 바깥 여백과 아이템 간격이 구분되어 있다
- [ ] 화면 크기가 바뀌어도 유지되는 여백 규칙이 있다
3) 폰트(Font) 체크
- [ ] 텍스트 스타일(Title/Body/Caption 등)이 정의되어 있다
- [ ] 폰트 크기(Font size)와 굵기(Weight)가 스타일로 통일되어 있다
- [ ] 행간(Line-height)이 기준(숫자/비율)으로 정리되어 있다
- [ ] 자간(Letter-spacing)이 “규칙”인지 “특수 케이스”인지 구분되어 있다
4) 상태(State) 최소 점검(권장)
- [ ] Disabled/Error/Loading 등 주요 상태의 텍스트/간격 변화가 정의되어 있다
- [ ] 같은 상태는 화면마다 동일한 표현 규칙을 가진다
한 줄 메모(선택): “예외는 왜 예외인지”만 적어도 질문이 크게 줄어듭니다.
PDF/이미지로 만드는 방법(가장 간단한 루틴)
- 이 체크리스트를 문서(또는 Figma 첫 페이지)에 붙여 넣습니다
- 프로젝트 기준으로 항목을 약간 수정해 “우리 팀 버전”으로 고정합니다
- 한 장으로 보이게 정리한 뒤 PDF로 내보내거나(저장), 이미지로 캡처해둡니다
- 개발 전달 전 체크 → 전달 자료에 함께 첨부하거나 링크로 공유합니다
실전 사용법: 개발자 질문을 줄이는 전달 방식
- 전달 메시지에 기준을 먼저 말하기: “기본 간격은 8px 규칙, 예외는 화면에 표시해두었습니다.”
- 폰트는 스타일 이름으로 전달: “Body/M(14, line-height 20) 기준으로 통일했습니다.”
- 예외는 한 줄로 이유를 남기기: “이 섹션만 상단 여백 24px(배너 영역 구분 목적)”
결론
개발 전달에서 질문이 반복되는 건 “설명 부족”보다 기준이 한 눈에 보이지 않아서 생기는 경우가 많습니다. 그래서 체크리스트를 한 장으로 만들고 PDF/이미지로 저장해두면, 전달 품질이 일정해지고 질문이 줄어듭니다.
여러분은 어떻게 생각하시나요? 이 글이 마음에 드시면 공감을 눌러 주세요.
FAQ
Q 체크리스트는 매번 다 작성해야 하나요?
A 아닙니다. 프로젝트 기준으로 한 번 정리해서 “우리 팀 버전”으로 고정해두고, 전달 전에는 체크만 하는 방식이 가장 효율적입니다.
Q 간격 규칙은 꼭 8px이어야 하나요?
A 꼭 그렇진 않습니다. 중요한 건 특정 숫자가 아니라 “규칙이 존재하고 일관되게 적용되는지”입니다. 팀 기준(4/8/12/16 등)을 정해두면 전달과 구현이 쉬워집니다.
Q 폰트에서 개발자가 가장 헷갈려하는 건 뭔가요?
A 폰트 크기보다 행간(Line-height)과 자간(Letter-spacing)이 더 혼동을 줍니다. 그래서 텍스트 스타일로 기준을 고정하는 게 좋습니다.
Q 이 체크리스트를 어디에 두는 게 좋나요?
A Figma 라이브러리 파일 첫 페이지(Overview) 또는 개발 전달 문서 첫 페이지에 두면 팀원 모두가 쉽게 찾아서 사용할 수 있습니다.