안녕하세요, 커뮤니케이션디자인 전공 대학생입니다. 인턴하면서 처음으로 피그마 Dev Mode로 핸드오프를 해봤는데, 개발자분이 결국 스크린샷 찍어서 쓰시더라고요... 혹시 Dev Mode 잘 활용하고 계신 팀 있으신가요? 디자인 파일을 어떻게 정리해야 개발팀이 편하게 쓸 수 있는지 팁이 있다면 꼭 알려주시면 감사하겠습니다.
#피그마#Dev Mode#핸드오프#개발협업#디자인시스템
8.24 04:57조회수 0댓글 4
우재프로덕트 디자이너 · 7년차
저도 처음 Dev Mode 도입했을 때 비슷한 경험 했었어요. 개발자분들이 익숙하지 않으니까 결국 스크린샷이랑 제플린 시절 습관으로 돌아가더라고요. 근데 핵심은 파일 정리보다 개발자랑 같이 앉아서 Dev Mode 한번 같이 써보는 시간을 만드는 거였어요. 저는 컴포넌트 네이밍을 개발 코드 컨벤션이랑 맞추고, 오토레이아웃을 철저하게 잡고, 섹션별로 페이지 나눠서 정리하니까 그때부터 개발팀이 직접 들어와서 값 뽑아가기 시작했습니다. 특히 spacing이랑 컬러를 변수로 등록해두면 Dev Mode에서 바로 토큰값으로 보여주니까 그게 제일 효과 큰 것 같아요. 인턴 때부터 이런 고민 하시는 거 보면 방향 잘 잡고 계신 거예요. 핸드오프는 결국 디자이너가 개발 언어를 얼마나 이해하느냐의 싸움이라 지금처럼 부딪혀보는 게 최고입니다.
8.24 04:58
지원프로덕트 디자이너 · 5년차
저는 5년차 프로덕트 디자이너인데, 한 2년 전쯤 Dev Mode 본격적으로 도입하면서 비슷한 시행착오를 꽤 겪었어요. 결론부터 말씀드리면, Dev Mode가 제대로 작동하려면 디자이너 쪽 파일 세팅이 생각보다 훨씬 중요하더라고요. 컴포넌트 네이밍을 개발 코드베이스랑 맞추고, 오토레이아웃을 빠짐없이 잡아두고, 스타일을 전부 토큰화해두니까 그때부터 개발자분들이 스크린샷 대신 직접 inspect을 쓰기 시작하셨어요. 그리고 하나 더, 처음에 개발팀이랑 30분짜리 온보딩 세션을 한 번 하는 게 엄청 효과적이었습니다. 어디를 봐야 하는지, 어떤 값을 가져다 쓸 수 있는지 같이 화면 보면서 알려드리면 그다음부터는 알아서 활용하시더라고요. 이서 님도 인턴 기간 중에 파일 정리 규칙부터 한번 잡아보시면 확실히 달라질 거예요.
8.24 04:58
성훈UI 설계 디자이너 · 7년차
저희 팀도 한 3년 전에 Dev Mode 처음 붙였을 때 프론트엔드 개발자분이 "이거 어디가 컴포넌트 경계인지 모르겠다"고 하셔서 결국 제플린으로 돌아간 적 있습니다. 근데 문제는 Dev Mode 자체가 아니라 파일 구조였어요. 이서님 케이스도 개발자분이 스크린샷을 찍으셨다는 건 아마 레이어 네이밍이나 오토레이아웃 구조가 코드 구조랑 매핑이 안 됐을 가능성이 높습니다. 제가 효과가 컸던 건 컴포넌트 네이밍을 개발 쪽 컨벤션이랑 맞추는 거였어요. Button/Primary/Large 이런 식으로 슬래시 구조를 코드의 props 체계랑 1:1로 대응시키니까 개발자분들이 알아서 Dev Mode 쓰기 시작하더라고요. 그리고 핸드오프 전에 개발자 한 분이랑 10분짜리 워크스루 한 번 하는 게 문서 열 장보다 낫습니다. 도구 탓보다 구조 설계가 먼저예요.
8.24 04:59
김지원프로덕트 디자이너 · 취준
피그마 파일 정리할 때 오토 레이아웃이랑 레이어 네이밍을 먼저 통일해두면 Dev Mode 쪽 코드 추출이 훨씬 깔끔해진다고 해서, 저도 사이드 프로젝트에서 그렇게 해봤거든요. 근데 솔직히 저는 아직 취준 중인 프로덕트 디자이너라 실무 핸드오프 경험이 깊지 않아서, 이서 님 글 읽으면서 오히려 걱정이 됐어요. 파일을 아무리 잘 정리해도 개발자분이 안 쓰시면 의미가 없는 건지... 혹시 그 개발자분이 Dev Mode 자체를 어려워하신 건지, 아니면 파일 구조에서 필요한 정보를 못 찾으신 건지 여쭤보셨나요? 그 원인에 따라 접근이 달라질 것 같아서요. 저도 나중에 실무 가면 꼭 부딪힐 문제일 것 같아서 이 글 답변들 계속 챙겨보려고요.
저도 처음 Dev Mode 도입했을 때 비슷한 경험 했었어요. 개발자분들이 익숙하지 않으니까 결국 스크린샷이랑 제플린 시절 습관으로 돌아가더라고요. 근데 핵심은 파일 정리보다 개발자랑 같이 앉아서 Dev Mode 한번 같이 써보는 시간을 만드는 거였어요. 저는 컴포넌트 네이밍을 개발 코드 컨벤션이랑 맞추고, 오토레이아웃을 철저하게 잡고, 섹션별로 페이지 나눠서 정리하니까 그때부터 개발팀이 직접 들어와서 값 뽑아가기 시작했습니다. 특히 spacing이랑 컬러를 변수로 등록해두면 Dev Mode에서 바로 토큰값으로 보여주니까 그게 제일 효과 큰 것 같아요. 인턴 때부터 이런 고민 하시는 거 보면 방향 잘 잡고 계신 거예요. 핸드오프는 결국 디자이너가 개발 언어를 얼마나 이해하느냐의 싸움이라 지금처럼 부딪혀보는 게 최고입니다.
저는 5년차 프로덕트 디자이너인데, 한 2년 전쯤 Dev Mode 본격적으로 도입하면서 비슷한 시행착오를 꽤 겪었어요. 결론부터 말씀드리면, Dev Mode가 제대로 작동하려면 디자이너 쪽 파일 세팅이 생각보다 훨씬 중요하더라고요. 컴포넌트 네이밍을 개발 코드베이스랑 맞추고, 오토레이아웃을 빠짐없이 잡아두고, 스타일을 전부 토큰화해두니까 그때부터 개발자분들이 스크린샷 대신 직접 inspect을 쓰기 시작하셨어요. 그리고 하나 더, 처음에 개발팀이랑 30분짜리 온보딩 세션을 한 번 하는 게 엄청 효과적이었습니다. 어디를 봐야 하는지, 어떤 값을 가져다 쓸 수 있는지 같이 화면 보면서 알려드리면 그다음부터는 알아서 활용하시더라고요. 이서 님도 인턴 기간 중에 파일 정리 규칙부터 한번 잡아보시면 확실히 달라질 거예요.
저희 팀도 한 3년 전에 Dev Mode 처음 붙였을 때 프론트엔드 개발자분이 "이거 어디가 컴포넌트 경계인지 모르겠다"고 하셔서 결국 제플린으로 돌아간 적 있습니다. 근데 문제는 Dev Mode 자체가 아니라 파일 구조였어요. 이서님 케이스도 개발자분이 스크린샷을 찍으셨다는 건 아마 레이어 네이밍이나 오토레이아웃 구조가 코드 구조랑 매핑이 안 됐을 가능성이 높습니다. 제가 효과가 컸던 건 컴포넌트 네이밍을 개발 쪽 컨벤션이랑 맞추는 거였어요. Button/Primary/Large 이런 식으로 슬래시 구조를 코드의 props 체계랑 1:1로 대응시키니까 개발자분들이 알아서 Dev Mode 쓰기 시작하더라고요. 그리고 핸드오프 전에 개발자 한 분이랑 10분짜리 워크스루 한 번 하는 게 문서 열 장보다 낫습니다. 도구 탓보다 구조 설계가 먼저예요.
피그마 파일 정리할 때 오토 레이아웃이랑 레이어 네이밍을 먼저 통일해두면 Dev Mode 쪽 코드 추출이 훨씬 깔끔해진다고 해서, 저도 사이드 프로젝트에서 그렇게 해봤거든요. 근데 솔직히 저는 아직 취준 중인 프로덕트 디자이너라 실무 핸드오프 경험이 깊지 않아서, 이서 님 글 읽으면서 오히려 걱정이 됐어요. 파일을 아무리 잘 정리해도 개발자분이 안 쓰시면 의미가 없는 건지... 혹시 그 개발자분이 Dev Mode 자체를 어려워하신 건지, 아니면 파일 구조에서 필요한 정보를 못 찾으신 건지 여쭤보셨나요? 그 원인에 따라 접근이 달라질 것 같아서요. 저도 나중에 실무 가면 꼭 부딪힐 문제일 것 같아서 이 글 답변들 계속 챙겨보려고요.