안녕하세요, 커뮤니케이션디자인 전공 대학생입니다. 인턴하면서 처음으로 피그마 Dev Mode로 핸드오프를 해봤는데, 개발자분이 결국 스크린샷 찍어서 쓰시더라고요... 혹시 Dev Mode 잘 활용하고 계신 팀 있으신가요? 디자인 파일을 어떻게 정리해야 개발팀이 편하게 쓸 수 있는지 팁이 있다면 꼭 알려주시면 감사하겠습니다.
#피그마#Dev Mode#핸드오프#개발협업#디자인시스템
8.24 04:57조회수 0댓글 10
우재프로덕트 디자이너 · 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 자체를 어려워하신 건지, 아니면 파일 구조에서 필요한 정보를 못 찾으신 건지 여쭤보셨나요? 그 원인에 따라 접근이 달라질 것 같아서요.
저도 나중에 실무 가면 꼭 부딪힐 문제일 것 같아서 이 글 답변들 계속 챙겨보려고요.
8.24 05:02
도현프로덕트 디자이너 · 3년차
핸드오프 파일에 개발자용 프레임을 따로 하나 만들어두는 게 저희 팀에선 제일 효과가 좋았어요. 디자인 작업용 캔버스는 어차피 시안이 여러 개 널려있어서 개발자 입장에선 뭐가 최종인지 판단이 안 되거든요.
그래서 확정된 화면만 복사해서 별도 페이지로 빼고, 거기서만 Dev Mode를 켜도록 했습니다. Ready for dev 상태 표시도 그 페이지에서만 씁니다. 그리고 스크린샷으로 도망가시는 건 대부분 인터랙션이나 상태 변화 정보가 파일에 없어서일 확률이 높아요. 호버, 비활성, 로딩 같은 상태를 베리언트로 안 만들어두면 결국 말로 물어봐야 하니까 차라리 이미지 캡처가 빠른 거죠.
상태별 케이스를 채워넣은 뒤부터는 질문이 확실히 줄었습니다.
9.6 22:18
지안프로덕트 디자이너 · 5년차
저는 핸드오프 넘기고 나면 QA 검수에 반나절씩 드는데, 그 시간이 줄어든 건 Dev Mode를 켜서가 아니라 "이 프레임은 확정"이라는 표시를 붙이고 나서였거든요. 개발자분이 스크린샷을 찍으셨다면, 도구가 안 읽힌 게 아니라 파일 안에 뭐가 최종인지가 안 보였을 가능성이 커요.
캔버스에 시안 A·B·수정본이 같이 떠 있으면 Dev Mode에서 아무리 값이 정확하게 나와도, 그 값이 지금 만들 화면 값인지를 확신할 수가 없으니까요. 그래서 저는 레이어 이름 정리보다 Ready 표시랑 확정 안 된 프레임 치우는 걸 먼저 합니다. 이름이 사각형12여도 확정된 프레임이면 개발자분이 클릭은 하시더라고요.
혹시 그 개발자분이 스크린샷을 쓰신 게 값을 못 찾아서였나요, 아니면 어느 게 최신인지 몰라서였나요? 둘은 고칠 데가 완전히 다른 문제라서요.
9.22 02:12
이서작성자커뮤니케이션디자인 전공 · 대학생
둘 중에 어느 쪽이었냐고 물어보시니까 좀 뜨끔했는데요, 다시 생각해보면 후자였던 것 같아요. 그때 제 캔버스에 시안 A랑 팀장님 피드백 반영한 수정본이 나란히 떠 있었고, 심지어 수정본이 오른쪽이 아니라 아래에 붙어 있었거든요. 개발자분이 물어보신 것도 "이 값 얼마예요"가 아니라 "이거 최신 맞죠?"였어요.
값은 보이는데 그 값을 믿어도 되는지는 파일만 봐서는 알 수 없었던 거네요... 확정 표시부터 해볼게요.
9.22 02:12
지안프로덕트 디자이너 · 5년차
저도 비슷한 걸 QA 검수 때 겪었는데, 결국 값이 아니라 상태가 안 보이는 문제인 것 같아요. 저희도 수정본을 원본 옆이나 아래에 그냥 붙여두다 보니 개발자분이 매번 "이게 맞나요"를 물으셨거든요. 확정 표시 붙이실 때 표시 자체보다 "표시 없는 건 안 봐도 된다"를 같이 못 박는 게 효과가 컸어요. 확정 딱지만 늘면 다시 다 확인하시더라고요.
9.22 02:13
태현에이전시 디자이너 · 8년차
스크린샷 찍어서 쓰시더라고요, 이 문장이 제일 눈에 들어오네요. 저도 개발사가 매번 바뀌는 에이전시라 Dev Mode를 정착시켜 본 팀은 없는데요, 반대로 왜 스크린샷으로 가는지는 몇 번 물어봤습니다. 돌아온 답이 대체로 같았어요. Dev Mode는 지금 이 프레임이 최종인지를 안 알려준다는 거였거든요. 값은 다 보이는데 이게 승인된 안인지 어제 만진 실험인지는 파일 밖의 정보라서요.
그래서 저는 파일 정리보다 전달 문장에 힘을 실었어요. 핸드오프할 때 "이 페이지 확정, 나머지 수정 예정"을 메일로 같이 적어 보냅니다. 구두로 말하면 안 남거든요. 다만 이건 파일 잘 짜는 요령은 아니라서, 인하우스에서 Dev Mode로 계속 굴리시는 분들 답이 저도 궁금합니다.
혹시 개발자분께 스크린샷 쓰는 이유를 직접 여쭤보신 적 있으세요?
10.1 06:45
이서작성자커뮤니케이션디자인 전공 · 대학생
저도 그게 제일 궁금해서 인턴 끝나기 전에 딱 한 번 여쭤봤는데요, 돌아온 말이 비슷했어요. 값은 보이는데 지금 보고 있는 게 확정인지 모르겠다고요. 저는 그때 캔버스에 시안 A랑 팀장님 피드백 반영본이 나란히 떠 있었고, 하필 수정본이 오른쪽이었거든요.
그러니까 스크린샷이 파일을 못 믿어서가 아니라 확정 표시가 파일 안에 없어서였던 것 같아요. 메일로 "이 페이지 확정" 적어 보내신다는 말씀이 그래서 와닿았습니다. 파일 정리 요령이 아니라고 하셨지만, 저 같은 학생한테는 그게 먼저 필요한 순서인 것 같아 배우고 갑니다.
저도 처음 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 자체를 어려워하신 건지, 아니면 파일 구조에서 필요한 정보를 못 찾으신 건지 여쭤보셨나요? 그 원인에 따라 접근이 달라질 것 같아서요. 저도 나중에 실무 가면 꼭 부딪힐 문제일 것 같아서 이 글 답변들 계속 챙겨보려고요.
핸드오프 파일에 개발자용 프레임을 따로 하나 만들어두는 게 저희 팀에선 제일 효과가 좋았어요. 디자인 작업용 캔버스는 어차피 시안이 여러 개 널려있어서 개발자 입장에선 뭐가 최종인지 판단이 안 되거든요. 그래서 확정된 화면만 복사해서 별도 페이지로 빼고, 거기서만 Dev Mode를 켜도록 했습니다. Ready for dev 상태 표시도 그 페이지에서만 씁니다. 그리고 스크린샷으로 도망가시는 건 대부분 인터랙션이나 상태 변화 정보가 파일에 없어서일 확률이 높아요. 호버, 비활성, 로딩 같은 상태를 베리언트로 안 만들어두면 결국 말로 물어봐야 하니까 차라리 이미지 캡처가 빠른 거죠. 상태별 케이스를 채워넣은 뒤부터는 질문이 확실히 줄었습니다.
저는 핸드오프 넘기고 나면 QA 검수에 반나절씩 드는데, 그 시간이 줄어든 건 Dev Mode를 켜서가 아니라 "이 프레임은 확정"이라는 표시를 붙이고 나서였거든요. 개발자분이 스크린샷을 찍으셨다면, 도구가 안 읽힌 게 아니라 파일 안에 뭐가 최종인지가 안 보였을 가능성이 커요. 캔버스에 시안 A·B·수정본이 같이 떠 있으면 Dev Mode에서 아무리 값이 정확하게 나와도, 그 값이 지금 만들 화면 값인지를 확신할 수가 없으니까요. 그래서 저는 레이어 이름 정리보다 Ready 표시랑 확정 안 된 프레임 치우는 걸 먼저 합니다. 이름이 사각형12여도 확정된 프레임이면 개발자분이 클릭은 하시더라고요. 혹시 그 개발자분이 스크린샷을 쓰신 게 값을 못 찾아서였나요, 아니면 어느 게 최신인지 몰라서였나요? 둘은 고칠 데가 완전히 다른 문제라서요.
둘 중에 어느 쪽이었냐고 물어보시니까 좀 뜨끔했는데요, 다시 생각해보면 후자였던 것 같아요. 그때 제 캔버스에 시안 A랑 팀장님 피드백 반영한 수정본이 나란히 떠 있었고, 심지어 수정본이 오른쪽이 아니라 아래에 붙어 있었거든요. 개발자분이 물어보신 것도 "이 값 얼마예요"가 아니라 "이거 최신 맞죠?"였어요. 값은 보이는데 그 값을 믿어도 되는지는 파일만 봐서는 알 수 없었던 거네요... 확정 표시부터 해볼게요.
저도 비슷한 걸 QA 검수 때 겪었는데, 결국 값이 아니라 상태가 안 보이는 문제인 것 같아요. 저희도 수정본을 원본 옆이나 아래에 그냥 붙여두다 보니 개발자분이 매번 "이게 맞나요"를 물으셨거든요. 확정 표시 붙이실 때 표시 자체보다 "표시 없는 건 안 봐도 된다"를 같이 못 박는 게 효과가 컸어요. 확정 딱지만 늘면 다시 다 확인하시더라고요.
스크린샷 찍어서 쓰시더라고요, 이 문장이 제일 눈에 들어오네요. 저도 개발사가 매번 바뀌는 에이전시라 Dev Mode를 정착시켜 본 팀은 없는데요, 반대로 왜 스크린샷으로 가는지는 몇 번 물어봤습니다. 돌아온 답이 대체로 같았어요. Dev Mode는 지금 이 프레임이 최종인지를 안 알려준다는 거였거든요. 값은 다 보이는데 이게 승인된 안인지 어제 만진 실험인지는 파일 밖의 정보라서요. 그래서 저는 파일 정리보다 전달 문장에 힘을 실었어요. 핸드오프할 때 "이 페이지 확정, 나머지 수정 예정"을 메일로 같이 적어 보냅니다. 구두로 말하면 안 남거든요. 다만 이건 파일 잘 짜는 요령은 아니라서, 인하우스에서 Dev Mode로 계속 굴리시는 분들 답이 저도 궁금합니다. 혹시 개발자분께 스크린샷 쓰는 이유를 직접 여쭤보신 적 있으세요?
저도 그게 제일 궁금해서 인턴 끝나기 전에 딱 한 번 여쭤봤는데요, 돌아온 말이 비슷했어요. 값은 보이는데 지금 보고 있는 게 확정인지 모르겠다고요. 저는 그때 캔버스에 시안 A랑 팀장님 피드백 반영본이 나란히 떠 있었고, 하필 수정본이 오른쪽이었거든요. 그러니까 스크린샷이 파일을 못 믿어서가 아니라 확정 표시가 파일 안에 없어서였던 것 같아요. 메일로 "이 페이지 확정" 적어 보내신다는 말씀이 그래서 와닿았습니다. 파일 정리 요령이 아니라고 하셨지만, 저 같은 학생한테는 그게 먼저 필요한 순서인 것 같아 배우고 갑니다.