안녕하세요 선배님들! 학교 프로젝트에서 개발 전공 팀원이랑 협업하고 있는데요, 피그마로 디자인 넘겨줄 때 어디까지 정리해서 줘야 하는지 감이 안 잡혀요. 컴포넌트 네이밍이나 간격 수치 같은 거 하나하나 다 표기해야 하는 건지, 오토 레이아웃만 깔끔하게 잡아두면 알아서 보시는 건지… 실무에서 핸드오프하실 때 어느 정도 수준으로 정리하시는지 궁금합니다!
#협업#핸드오프#피그마#개발자소통#디자인시스템
8.10 10:32조회수 0댓글 9
채원스타트업 디자이너 · 3년차
혹시 개발 팀원분이 피그마 자체를 어느 정도 다룰 줄 아세요? 그거에 따라 정리 수준이 좀 달라지거든요. 저는 스타트업에서 프론트 개발자분이랑 바로 붙어서 일하는데, 처음엔 간격이랑 폰트 사이즈 하나하나 다 빨간 줄 긋고 표기했어요. 근데 솔직히 그거 정리하는 시간이 디자인하는 시간만큼 들더라고요. 지금은 오토 레이아웃 구조 깔끔하게 잡고, 컴포넌트 네이밍 규칙만 개발자분이랑 미리 맞춰두는 식으로 해요. 피그마 inspect 기능이 수치는 다 보여주니까 굳이 따로 안 적어도 되고, 대신 인터랙션이나 상태값 같은 건 메모로 꼭 남겨둬요. hover 했을 때 어떻게 바뀌는지, disabled 상태는 뭔지 이런 거요. 학교 프로젝트라면 한 번 넘겨보고 개발자분한테 뭐가 부족했는지 피드백 받는 게 제일 빨라요. 처음부터 완벽하게 정리하려고 하면 끝이 없어서요.
8.10 10:32
주아UX디자인 전공 · 대학생
근데 저는 좀 다른 생각인 게, 정리를 너무 완벽하게 해주는 것도 오히려 독이 될 수 있지 않나 싶어요. 저도 학교 팀플에서 개발 팀원이랑 작업하면서 처음엔 간격, 컬러값, 폰트 사이즈 전부 일일이 표기했거든요. 그랬더니 오히려 개발하시는 분이 피그마를 직접 뜯어보는 습관이 안 생겨서 사소한 것도 계속 저한테 물어보시더라고요ㅠㅠ 그 이후로는 오토 레이아웃이랑 컴포넌트 구조만 확실히 잡아두고, 나머지는 같이 피그마 화면 보면서 설명하는 시간을 따로 잡는 쪽으로 바꿨어요. 문서 정리보다 그 30분짜리 싱크 미팅이 훨씬 효율적이었어요! 규민님도 혼자 정리 고민하시기보다 팀원분이랑 어느 정도가 편한지 먼저 한번 얘기 나눠보시는 것도 괜찮을 것 같아요~
8.10 10:32
도윤BX 디자이너 · 7년차
핸드오프 정리의 핵심은 수치 하나하나 표기하는 게 아니라 의도를 전달하는 거예요. 저는 7년 동안 여러 개발자분들이랑 협업해봤는데, 결국 간격이 12px인지 16px인지는 피그마 인스펙트에서 다 확인 가능하거든요. 그걸 굳이 빨간 줄 그어가며 표기하는 건 시간 낭비에 가까워요. 대신 진짜 챙겨야 할 건 인터랙션 흐름이랑 상태값이에요. 버튼 hover 시 어떻게 바뀌는지, 에러 상태일 때 UI가 어떤 모습인지, 이런 건 피그마만 봐서는 절대 파악이 안 되거든요. 오토 레이아웃 잘 잡아두고 컴포넌트 구조 논리적으로 정리하되, 별도로 플로우 페이지 하나 만들어서 화면 간 연결이랑 예외 케이스 정리해주는 게 훨씬 효율적입니다. 그리고 학교 프로젝트라면 파일 넘기고 끝이 아니라 짧게라도 같이 화면 보면서 설명하는 시간 꼭 가지세요. 문서 열 장보다 10분 대화가 낫습니다.
8.10 10:33
예린주니어 UXUI 디자이너 · 신입
저번에 학교 텀프로젝트에서 간격 수치를 8px 단위로 전부 빨간 선 그어가면서 표기했거든요. 근데 개발 팀원분이 그거 안 보고 피그마 인스펙트 모드에서 직접 확인하시더라고요… 그때 좀 허탈했어요. 저도 규민님이랑 비슷한 상황이라 요즘 계속 고민 중인데, 궁금한 게 있어요. 혹시 컴포넌트 네이밍 규칙을 개발 팀원분이랑 미리 맞추고 시작하셨나요? 저는 그걸 안 해서 나중에 btn-primary랑 MainButton이랑 서로 다른 이름으로 부르면서 혼선이 왔었거든요. 정리 수준도 중요한데 그 전에 용어부터 통일하는 게 먼저인 것 같기도 하고… 선배님들은 협업 초반에 네이밍 컨벤션 회의 같은 거 따로 하시는지도 궁금하네요!
8.10 10:33
태현에이전시 디자이너 · 8년차
에이전시에서 8년 넘게 다양한 개발팀이랑 붙어봤는데요, 결론부터 말하면 피그마 파일 정리보다 10분짜리 화면 공유 한 번이 훨씬 효율 좋습니다. 저도 초반엔 간격이고 컬러코드고 전부 표기했거든요. 근데 개발자분들 대부분 피그마 인스펙트 모드에서 직접 찍어보는 걸 더 신뢰하더라고요. 제가 지금 꼭 챙기는 건 딱 세 가지예요. 컴포넌트 상태값 정리, 예외 케이스 화면, 그리고 인터랙션 흐름. 네이밍이나 수치는 오토 레이아웃 제대로 잡혀 있으면 개발 쪽에서 알아서 뽑아갑니다. 학교 프로젝트면 특히 문서 만드느라 시간 쓰지 말고 옆에 앉아서 같이 화면 보면서 의도 설명해주는 게 제일 빠르고 정확해요.
8.10 10:33
진아브랜드 디자이너 · 12년차
솔직히 말할게요. 핸드오프 정리를 어디까지 해야 하는지 고민하는 건, 본인 디자인 구조가 아직 안 잡혀 있다는 뜻이에요. 디자인 자체가 논리적으로 설계돼 있으면 정리할 게 별로 없거든요. 제가 3년차 때 화장품 브랜드 앱 프로젝트에서 간격 표기, 컬러값 표기 빼곡하게 해서 넘긴 적 있는데, 개발자가 첫마디로 한 말이 "레이어 구조가 엉망이라 표기 봐도 모르겠다"였어요. 그때 깨달은 게, 수치 표기는 디자이너 자기만족이고 진짜 중요한 건 레이어 네이밍이랑 오토 레이아웃 구조가 코드 구조랑 대응되게 짜는 거예요. 학교 프로젝트면 개발 팀원한테 컴포넌트 트리 한번 보여달라고 하세요. 그 구조에 맞춰서 피그마 정리하는 게 정답이지, 디자이너 혼자 완벽하게 정리하겠다는 발상 자체가 협업이 아니에요.
8.10 10:34
지원프로덕트 디자이너 · 5년차
아 이 질문 너무 반갑네요, 저도 처음 실무 시작했을 때 똑같은 고민이었거든요. 근데 5년 하면서 느낀 건, 간격 수치나 컴포넌트 네이밍보다 진짜 개발자분이 막히는 건 빠진 화면이에요. 버튼 누르면 로딩 중일 때 어떻게 보이는지, 데이터가 하나도 없을 때 빈 화면은 뭘 보여줄지, 입력값 틀렸을 때 에러 상태는 어떤 건지. 이런 케이스가 정리 안 되어 있으면 개발자분이 매번 물어보거나, 더 안 좋은 건 본인 판단으로 대충 만들어버려요. 수치 표기는 요즘 피그마 Dev Mode가 알아서 잡아주니까 크게 신경 안 써도 되고요. 규민님 학교 프로젝트라면 메인 플로우 기준으로 정상 상태, 빈 상태, 에러 상태 이 세 가지만 확실히 챙겨도 협업 퀄리티가 확 달라질 거예요.
8.10 10:34
준호산업디자이너 · 6년차
혹시 개발 팀원분이랑 파일 넘기고 나서 추가 질문 주고받는 루틴은 잡아두셨어요? 저는 산업디자인 쪽이라 피그마 핸드오프 자체는 잘 모르는데, 금형 업체나 설계 엔지니어한테 도면 넘길 때 비슷한 고민을 6년째 하고 있어서 끼어들어봅니다. 경험상 치수를 아무리 꼼꼼하게 찍어줘도 받는 쪽에서 해석이 갈리는 부분은 반드시 생깁니다. 그래서 저는 어느 순간부터 문서 정리 퀄리티보다 넘긴 직후 15분 통화 한 번 하는 걸 루틴으로 잡았는데, 그게 훨씬 사고가 적었어요. 분야는 다르지만 결국 핸드오프라는 행위 자체가 정보 손실이 생기는 구조라서, 정리 수준을 올리는 것보다 손실을 빠르게 메울 수 있는 소통 구조를 먼저 만드는 게 낫지 않나 싶습니다.
8.10 10:35
서연웹디자이너 · 4년차
규민 님이 놓치기 쉬운 부분 하나 말씀드리면, 간격 수치나 컴포넌트 네이밍보다 상태값 정리가 훨씬 중요해요. 버튼 hover, disabled, 인풋 에러 상태 같은 것들이요. 저도 웹디자이너 4년 차인데 처음엔 화면 레이아웃 깔끔하게 넘기는 데만 신경 썼거든요. 근데 막상 개발자분들이 제일 많이 물어보시는 건 "이거 누르면 어떻게 바뀌어요?" "값 없을 때는요?" 이런 인터랙션 케이스였어요. 수치는 솔직히 피그마 인스펙트 모드에서 다 뽑아가세요. 대신 각 화면별로 일어날 수 있는 상태 변화를 한 프레임에 나란히 모아두시면 질문이 확 줄어들어요. 학교 프로젝트시라면 완벽한 정리보다 "왜 이 구조로 했는지" 한 줄 메모가 더 통하더라고요. 그게 결국 정리의 본질인 것 같아요.
혹시 개발 팀원분이 피그마 자체를 어느 정도 다룰 줄 아세요? 그거에 따라 정리 수준이 좀 달라지거든요. 저는 스타트업에서 프론트 개발자분이랑 바로 붙어서 일하는데, 처음엔 간격이랑 폰트 사이즈 하나하나 다 빨간 줄 긋고 표기했어요. 근데 솔직히 그거 정리하는 시간이 디자인하는 시간만큼 들더라고요. 지금은 오토 레이아웃 구조 깔끔하게 잡고, 컴포넌트 네이밍 규칙만 개발자분이랑 미리 맞춰두는 식으로 해요. 피그마 inspect 기능이 수치는 다 보여주니까 굳이 따로 안 적어도 되고, 대신 인터랙션이나 상태값 같은 건 메모로 꼭 남겨둬요. hover 했을 때 어떻게 바뀌는지, disabled 상태는 뭔지 이런 거요. 학교 프로젝트라면 한 번 넘겨보고 개발자분한테 뭐가 부족했는지 피드백 받는 게 제일 빨라요. 처음부터 완벽하게 정리하려고 하면 끝이 없어서요.
근데 저는 좀 다른 생각인 게, 정리를 너무 완벽하게 해주는 것도 오히려 독이 될 수 있지 않나 싶어요. 저도 학교 팀플에서 개발 팀원이랑 작업하면서 처음엔 간격, 컬러값, 폰트 사이즈 전부 일일이 표기했거든요. 그랬더니 오히려 개발하시는 분이 피그마를 직접 뜯어보는 습관이 안 생겨서 사소한 것도 계속 저한테 물어보시더라고요ㅠㅠ 그 이후로는 오토 레이아웃이랑 컴포넌트 구조만 확실히 잡아두고, 나머지는 같이 피그마 화면 보면서 설명하는 시간을 따로 잡는 쪽으로 바꿨어요. 문서 정리보다 그 30분짜리 싱크 미팅이 훨씬 효율적이었어요! 규민님도 혼자 정리 고민하시기보다 팀원분이랑 어느 정도가 편한지 먼저 한번 얘기 나눠보시는 것도 괜찮을 것 같아요~
핸드오프 정리의 핵심은 수치 하나하나 표기하는 게 아니라 의도를 전달하는 거예요. 저는 7년 동안 여러 개발자분들이랑 협업해봤는데, 결국 간격이 12px인지 16px인지는 피그마 인스펙트에서 다 확인 가능하거든요. 그걸 굳이 빨간 줄 그어가며 표기하는 건 시간 낭비에 가까워요. 대신 진짜 챙겨야 할 건 인터랙션 흐름이랑 상태값이에요. 버튼 hover 시 어떻게 바뀌는지, 에러 상태일 때 UI가 어떤 모습인지, 이런 건 피그마만 봐서는 절대 파악이 안 되거든요. 오토 레이아웃 잘 잡아두고 컴포넌트 구조 논리적으로 정리하되, 별도로 플로우 페이지 하나 만들어서 화면 간 연결이랑 예외 케이스 정리해주는 게 훨씬 효율적입니다. 그리고 학교 프로젝트라면 파일 넘기고 끝이 아니라 짧게라도 같이 화면 보면서 설명하는 시간 꼭 가지세요. 문서 열 장보다 10분 대화가 낫습니다.
저번에 학교 텀프로젝트에서 간격 수치를 8px 단위로 전부 빨간 선 그어가면서 표기했거든요. 근데 개발 팀원분이 그거 안 보고 피그마 인스펙트 모드에서 직접 확인하시더라고요… 그때 좀 허탈했어요. 저도 규민님이랑 비슷한 상황이라 요즘 계속 고민 중인데, 궁금한 게 있어요. 혹시 컴포넌트 네이밍 규칙을 개발 팀원분이랑 미리 맞추고 시작하셨나요? 저는 그걸 안 해서 나중에 btn-primary랑 MainButton이랑 서로 다른 이름으로 부르면서 혼선이 왔었거든요. 정리 수준도 중요한데 그 전에 용어부터 통일하는 게 먼저인 것 같기도 하고… 선배님들은 협업 초반에 네이밍 컨벤션 회의 같은 거 따로 하시는지도 궁금하네요!
에이전시에서 8년 넘게 다양한 개발팀이랑 붙어봤는데요, 결론부터 말하면 피그마 파일 정리보다 10분짜리 화면 공유 한 번이 훨씬 효율 좋습니다. 저도 초반엔 간격이고 컬러코드고 전부 표기했거든요. 근데 개발자분들 대부분 피그마 인스펙트 모드에서 직접 찍어보는 걸 더 신뢰하더라고요. 제가 지금 꼭 챙기는 건 딱 세 가지예요. 컴포넌트 상태값 정리, 예외 케이스 화면, 그리고 인터랙션 흐름. 네이밍이나 수치는 오토 레이아웃 제대로 잡혀 있으면 개발 쪽에서 알아서 뽑아갑니다. 학교 프로젝트면 특히 문서 만드느라 시간 쓰지 말고 옆에 앉아서 같이 화면 보면서 의도 설명해주는 게 제일 빠르고 정확해요.
솔직히 말할게요. 핸드오프 정리를 어디까지 해야 하는지 고민하는 건, 본인 디자인 구조가 아직 안 잡혀 있다는 뜻이에요. 디자인 자체가 논리적으로 설계돼 있으면 정리할 게 별로 없거든요. 제가 3년차 때 화장품 브랜드 앱 프로젝트에서 간격 표기, 컬러값 표기 빼곡하게 해서 넘긴 적 있는데, 개발자가 첫마디로 한 말이 "레이어 구조가 엉망이라 표기 봐도 모르겠다"였어요. 그때 깨달은 게, 수치 표기는 디자이너 자기만족이고 진짜 중요한 건 레이어 네이밍이랑 오토 레이아웃 구조가 코드 구조랑 대응되게 짜는 거예요. 학교 프로젝트면 개발 팀원한테 컴포넌트 트리 한번 보여달라고 하세요. 그 구조에 맞춰서 피그마 정리하는 게 정답이지, 디자이너 혼자 완벽하게 정리하겠다는 발상 자체가 협업이 아니에요.
아 이 질문 너무 반갑네요, 저도 처음 실무 시작했을 때 똑같은 고민이었거든요. 근데 5년 하면서 느낀 건, 간격 수치나 컴포넌트 네이밍보다 진짜 개발자분이 막히는 건 빠진 화면이에요. 버튼 누르면 로딩 중일 때 어떻게 보이는지, 데이터가 하나도 없을 때 빈 화면은 뭘 보여줄지, 입력값 틀렸을 때 에러 상태는 어떤 건지. 이런 케이스가 정리 안 되어 있으면 개발자분이 매번 물어보거나, 더 안 좋은 건 본인 판단으로 대충 만들어버려요. 수치 표기는 요즘 피그마 Dev Mode가 알아서 잡아주니까 크게 신경 안 써도 되고요. 규민님 학교 프로젝트라면 메인 플로우 기준으로 정상 상태, 빈 상태, 에러 상태 이 세 가지만 확실히 챙겨도 협업 퀄리티가 확 달라질 거예요.
혹시 개발 팀원분이랑 파일 넘기고 나서 추가 질문 주고받는 루틴은 잡아두셨어요? 저는 산업디자인 쪽이라 피그마 핸드오프 자체는 잘 모르는데, 금형 업체나 설계 엔지니어한테 도면 넘길 때 비슷한 고민을 6년째 하고 있어서 끼어들어봅니다. 경험상 치수를 아무리 꼼꼼하게 찍어줘도 받는 쪽에서 해석이 갈리는 부분은 반드시 생깁니다. 그래서 저는 어느 순간부터 문서 정리 퀄리티보다 넘긴 직후 15분 통화 한 번 하는 걸 루틴으로 잡았는데, 그게 훨씬 사고가 적었어요. 분야는 다르지만 결국 핸드오프라는 행위 자체가 정보 손실이 생기는 구조라서, 정리 수준을 올리는 것보다 손실을 빠르게 메울 수 있는 소통 구조를 먼저 만드는 게 낫지 않나 싶습니다.
규민 님이 놓치기 쉬운 부분 하나 말씀드리면, 간격 수치나 컴포넌트 네이밍보다 상태값 정리가 훨씬 중요해요. 버튼 hover, disabled, 인풋 에러 상태 같은 것들이요. 저도 웹디자이너 4년 차인데 처음엔 화면 레이아웃 깔끔하게 넘기는 데만 신경 썼거든요. 근데 막상 개발자분들이 제일 많이 물어보시는 건 "이거 누르면 어떻게 바뀌어요?" "값 없을 때는요?" 이런 인터랙션 케이스였어요. 수치는 솔직히 피그마 인스펙트 모드에서 다 뽑아가세요. 대신 각 화면별로 일어날 수 있는 상태 변화를 한 프레임에 나란히 모아두시면 질문이 확 줄어들어요. 학교 프로젝트시라면 완벽한 정리보다 "왜 이 구조로 했는지" 한 줄 메모가 더 통하더라고요. 그게 결국 정리의 본질인 것 같아요.