developer-tooling

1 개의 포스트

figma

Dev Mode에 대해 알아 (새 탭에서 열림)

Figma는 디자이너와 개발자가 하나의 파일과 협업 공간에서 더 효율적으로 제품을 만들 수 있도록 Dev Mode를 개발했고, 2024년 1월 베타를 종료했습니다. Dev Mode는 개발자에게 필요한 정보와 도구를 별도 워크스페이스로 제공하면서도 디자인 맥락과 협업은 유지하는 것이 핵심입니다. Figma는 사용자 피드백을 바탕으로 주석, 변경점 비교 등 핸드오프와 구현을 지원하는 기능을 강화했습니다. ## 개발자 중심의 작업 공간이 필요한 이유 - 개발자는 Figma 주간 활성 사용자의 약 3분의 1을 차지했습니다. - 하지만 기존 Figma는 디자인 작업에 최적화되어 있어 개발자의 워크플로, 도구 체계, 선호 사항을 충분히 지원하지 못했습니다. - Figma는 프런트엔드 개발자, 디자인 시스템 엔지니어, 콘텐츠 레이아웃 및 에셋을 다루는 개발자 등 다양한 역할을 고려해 개발자 전용 경험을 만들고자 했습니다. - 핵심 방향은 개발자가 디자인 모드의 모든 상호작용을 학습하지 않아도 되도록, 개발자에게 필요한 방식으로 Figma를 맞추는 것이었습니다. ## Visly 인수와 개발자 직관 확보 - Figma는 2021년 React UI 컴포넌트 개발 도구를 만들던 Visly 팀을 인수했습니다. - 8명의 디자이너와 엔지니어로 구성된 Visly 팀은 개발자 도구에 대한 실무 경험과 연구 결과를 보유하고 있었습니다. - Figma는 개발자와 대화하는 것만으로는 부족하며, 실제 개발 환경에 몰입해 얻는 ‘개발자 직관’이 필요하다고 판단했습니다. - Visly 팀은 개발자가 Figma를 사용하는 실제 방식과 다양한 개발 환경에 대한 관점을 제공했습니다. ## 디자인과 개발을 연결하는 통합 모드 - Dev Mode의 형태를 결정하는 과정에서 디자인 파일과 개발 파일을 완전히 분리할지, 하나로 통합할지 오랜 기간 검토했습니다. - 최종적으로 Dev Mode를 Figma 안의 별도 공간으로 구현했습니다. - 개발자는 개발에 최적화된 인터페이스를 사용하면서도 디자인 파일, 변경사항, 디자이너의 의도 같은 중요한 맥락을 그대로 확인할 수 있습니다. - 별도 도구나 파일로 전환하지 않고 디자인 공간과 개발 공간을 오갈 수 있다는 점이 핵심입니다. ## 오픈 베타와 사용자 피드백 - Dev Mode는 Config 2023에서 오픈 베타로 공개되었습니다. - 베타 기간 동안 고객 요청을 적극적으로 수집했고, 처음 두 달 동안 가장 많이 요청된 업데이트와 수정 사항 200개 이상을 배포했습니다. - 사용자 피드백은 Dev Mode의 기능 우선순위와 제품 결정에 직접 반영되었습니다. - 이후 Dev Mode는 베타를 종료하고 정식 제품 단계로 이동했습니다. ## 디자인 의도를 명확히 전달하는 주석 - 기존에는 디자이너가 개발자에게 필요한 치수와 설명을 수동으로 만들고 디자인을 별도로 정리해야 했습니다. - Dev Mode의 주석 기능은 디자인에 직접 연결된 설명, 사양, 측정값을 제공합니다. - 디자인이 변경되면 주석도 실시간으로 업데이트되어 최신 상태를 유지할 수 있습니다. - 캔버스를 복잡하게 만들지 않으면서 중요한 세부사항을 강조할 수 있습니다. - 플러그인을 이용해 주석을 자동화하거나 사용자 지정할 수 있습니다. - 클릭하고 드래그하는 방식으로 요소 간 거리를 측정할 수 있습니다. ## 개발 준비 상태와 변경점 비교 - 디자이너는 섹션을 “개발 준비 완료(ready for development)”로 표시하고 별도의 페이지나 파일 없이 개발자에게 전달할 수 있습니다. - 변경점 비교(diff) 기능을 사용하면 서로 다른 버전의 프레임을 비교할 수 있습니다. - 이를 통해 디자인 변경 사항을 확인하고, 개발자가 최신 디자인을 기준으로 작업하도록 지원합니다. - 목적은 디자인 핸드오프 과정에서 누락되는 설명이나 변경사항을 줄이고 구현 정확도를 높이는 것입니다. Dev Mode를 효과적으로 활용하려면 디자인과 개발을 별도 도구로 분리하기보다, 디자인 파일 안에서 주석·측정값·준비 상태·변경 이력을 일관되게 관리하는 것이 좋습니다. 특히 개발 전달 전에 “개발 준비 완료” 상태와 변경점을 명확히 표시하면 커뮤니케이션 비용을 줄일 수 있습니다.