Dev Mode와 개발 핸드오프

디자인이 끝났다고 일이 끝난 것은 아니다

피그마에서 화면을 예쁘게 만드는 일은 중요합니다. 하지만 실무에서는 그다음 단계가 더 중요할 때가 많습니다. 바로 개발자가 그 화면을 보고 실제 제품으로 구현할 수 있게 만드는 일입니다.

디자인 파일이 아무리 멋져도 개발자가 버튼의 높이, 글자 크기, 여백, 색상 값, 아이콘 파일, 예외 상태를 매번 물어봐야 한다면 그 파일은 아직 실무용으로 완성된 것이 아닙니다. 반대로 디자인이 아주 화려하지 않더라도 개발자가 필요한 정보를 바로 찾을 수 있다면 팀의 속도는 훨씬 빨라집니다.

이 장에서는 피그마의 Dev Mode를 중심으로 개발자에게 디자인을 전달하는 방법을 배웁니다. Dev Mode는 개발자가 디자인 파일을 읽기 쉽게 도와주는 모드입니다. 간격, 크기, 색상, 폰트, 코드에 가까운 속성 값, 에셋 추출 정보 등을 한곳에서 확인할 수 있습니다.

핵심은 단순합니다. 좋은 디자인 파일은 개발자가 추측하지 않게 합니다. 수치를 찾을 수 있고, 상태를 이해할 수 있고, 필요한 에셋을 바로 내려받을 수 있어야 합니다.

Dev Mode는 개발자를 위한 번역기다

디자이너와 개발자는 같은 화면을 보지만 서로 다른 것을 봅니다. 디자이너는 균형, 흐름, 시각적 우선순위를 봅니다. 개발자는 구조, 값, 조건, 재사용 가능성을 봅니다.

예를 들어 로그인 버튼 하나를 보더라도 디자이너는 "버튼이 충분히 눈에 띄는가?"를 먼저 생각할 수 있습니다. 개발자는 "높이가 몇 px인지, 배경색 값은 무엇인지, 비활성화 상태는 있는지, 텍스트는 가운데 정렬인지, 모바일 화면에서 너비가 어떻게 변하는지"를 확인해야 합니다.

Dev Mode는 이 두 관점을 연결합니다. 디자인 화면을 개발 언어에 가까운 정보로 풀어 보여주기 때문입니다. 선택한 레이어의 크기, 좌표, 간격, 컬러, 타이포그래피, 그림자, 테두리, Auto Layout 속성, CSS-like 코드 값을 확인할 수 있습니다.

여기서 CSS-like 코드란 실제 코드와 완전히 같다는 뜻은 아닙니다. 피그마가 디자인 속성을 웹 CSS와 비슷한 형태로 보여준다는 뜻입니다. 개발자는 이 값을 참고해 실제 프로젝트의 코드 규칙에 맞게 변환합니다. 즉, Dev Mode의 코드는 "복사해서 끝"이라기보다 "구현을 위한 정확한 힌트"에 가깝습니다.

Dev Mode에 들어가는 기본 흐름

피그마 파일을 열고 상단 툴바에서 Dev Mode 또는 </> 아이콘을 선택하면 개발 확인용 화면으로 전환됩니다. 일반 디자인 모드에서는 레이어를 만들고 수정하는 데 초점이 있다면, Dev Mode에서는 이미 만들어진 디자인을 읽고 확인하는 데 초점이 있습니다.

개발자가 가장 자주 하는 흐름은 다음과 같습니다.

• 구현할 화면 프레임을 선택한다.

• 버튼, 입력창, 카드, 아이콘 같은 개별 요소를 클릭한다.

• 오른쪽 패널에서 크기, 간격, 색상, 폰트, 코드 정보를 확인한다.

• 필요한 아이콘이나 이미지를 Export 또는 Assets 영역에서 내려받는다.

• 이해가 어려운 부분은 코멘트나 주석을 확인한다.

디자인을 전달하기 전에 디자이너나 기획자도 이 흐름을 직접 한 번 해보는 것이 좋습니다. "내가 개발자라면 이 화면을 보고 구현할 수 있을까?"라는 질문으로 파일을 열어보면, 빠진 정보가 금방 보입니다.

단축키 & 팁: Dev Mode 확인 습관

• 상단의 Dev Mode / </> 아이콘으로 디자인 확인 모드에 들어갑니다.

• 레이어를 선택한 뒤 오른쪽 패널에서 크기, 색상, 폰트, 간격 정보를 확인합니다.

• 디자인 모드에서 Alt 또는 Option을 누른 채 다른 레이어에 마우스를 올리면 요소 간 거리 확인에 도움이 됩니다.

• 개발 전달 전에는 반드시 본인이 Dev Mode에서 주요 화면을 클릭해 보며 정보가 잘 보이는지 점검합니다.

개발자가 가장 먼저 보는 것: 프레임 이름

개발 핸드오프에서 가장 기본이지만 가장 자주 무너지는 것이 이름입니다. 프레임 이름이 Frame 123, Untitled, Copy of Copy처럼 되어 있으면 개발자는 어디서부터 봐야 할지 알 수 없습니다.

프레임 이름은 화면의 역할과 상태를 함께 담아야 합니다. 예를 들어 로그인 화면이라면 Login / Default, Login / Error, Login / Loading, Login / Success처럼 이름을 붙일 수 있습니다. 결제 화면이라면 Payment / Empty, Payment / Filled, Payment / Failed처럼 상태를 나누면 좋습니다.

화면 이름은 멋있을 필요가 없습니다. 오히려 평범하고 명확해야 합니다. 개발자는 시적인 이름보다 예측 가능한 이름을 좋아합니다. 특히 같은 화면의 여러 상태가 있을 때는 이름 규칙이 중요합니다. 이름만 봐도 어느 화면의 어떤 상태인지 이해되어야 합니다.

컴포넌트 이름도 마찬가지입니다. Button, Input, Modal, Navigation Item처럼 역할 중심으로 시작하고, 필요하다면 속성을 뒤에 붙입니다. 예를 들어 Button / Primary / Default, Button / Primary / Disabled, Input / Text / Error처럼 구성하면 개발자가 상태를 비교하기 쉽습니다.

간격과 크기 확인하기

개발자가 화면을 구현할 때 가장 많이 확인하는 값은 여백입니다. 디자인을 처음 공부하는 사람은 색상이나 이미지가 가장 중요하다고 생각하기 쉽지만, 실제 UI의 완성도는 간격에서 크게 갈립니다.

Dev Mode에서 프레임이나 레이어를 선택하면 해당 요소의 가로·세로 크기, 위치, 부모 프레임과의 관계를 확인할 수 있습니다. Auto Layout이 적용된 요소라면 내부 여백, 아이템 사이 간격, 정렬 방식도 확인할 수 있습니다.

여기서 중요한 점은 개발자가 모든 요소를 절대 좌표로 구현하지 않는다는 것입니다. 예를 들어 모바일 화면에서 버튼이 아래에서 24px 떨어져 있다고 해서, 모든 기기에서 y 좌표를 고정하는 것은 좋은 구현이 아닐 수 있습니다. 실제 구현에서는 "하단 안전 영역 위에 24px 여백", "좌우 20px 고정", "너비는 부모에 맞춤" 같은 규칙으로 바꿔야 합니다.

그래서 디자인 파일은 단순한 숫자뿐 아니라 의도를 보여주어야 합니다. Auto Layout과 Constraints를 제대로 사용하면 이 의도가 훨씬 잘 전달됩니다. 버튼이 부모 너비에 맞춰 늘어나야 하는지, 콘텐츠 길이에 따라 높이가 바뀌어야 하는지, 아이콘과 텍스트 사이 간격이 고정인지 등을 개발자가 읽을 수 있기 때문입니다.

색상과 폰트는 값보다 이름이 중요하다

Dev Mode에서는 선택한 요소의 색상 값과 폰트 정보를 확인할 수 있습니다. 예를 들어 배경색이 #2563EB인지, 텍스트 크기가 16px인지, 줄 높이가 24px인지 같은 정보를 볼 수 있습니다.

하지만 실무에서는 값 자체보다 그 값이 어떤 의미인지가 더 중요합니다. 파란색 하나를 예로 들어보겠습니다. 이 색상이 단순히 #2563EB라면 개발자는 그 값을 그대로 입력할 수는 있습니다. 그러나 이 색상이 color/brand/primary라는 변수나 스타일로 연결되어 있다면 훨씬 좋습니다. 개발자는 "아, 이건 브랜드의 대표 색상이구나"라고 이해할 수 있습니다.

폰트도 마찬가지입니다. 단순히 16px, Medium, 24px 줄 높이라고 적혀 있는 것보다 text/body/medium 또는 typography/body/md 같은 스타일 이름이 함께 보이면 시스템으로 관리하기 좋습니다.

디자인 시스템이 없는 팀이라도 최소한 자주 쓰는 색상과 텍스트는 Styles나 Variables로 연결해 두는 것이 좋습니다. 개발자에게는 이것이 토큰의 출발점이 됩니다. 토큰은 디자인 값을 이름 붙여 관리하는 단위입니다. 예를 들어 spacing/16, color/text/primary, radius/button처럼 이름을 붙이면 디자인과 코드가 같은 언어를 사용할 수 있습니다.

CSS-like 코드 정보 읽기

Dev Mode의 오른쪽 패널에서는 선택한 요소에 대한 코드 형태의 정보를 확인할 수 있습니다. 웹 프로젝트라면 CSS와 비슷한 속성으로 보일 수 있고, iOS나 Android 환경에 맞는 값이 표시될 수도 있습니다.

초보자는 여기서 "이 코드를 그대로 개발자가 붙여 넣으면 되는 건가?"라고 생각하기 쉽습니다. 경우에 따라 일부 값은 바로 참고할 수 있지만, 대부분의 실무 프로젝트에서는 그대로 복사해서 끝나지 않습니다. 실제 코드에는 팀의 컴포넌트 구조, 프레임워크, 디자인 토큰, 반응형 규칙, 접근성 기준이 있기 때문입니다.

그래도 Dev Mode의 코드 정보는 매우 유용합니다. 개발자가 요소의 핵심 속성을 빠르게 파악할 수 있기 때문입니다. 예를 들어 버튼을 선택했을 때 다음과 같은 정보를 확인할 수 있습니다.

• 배경색, 텍스트 색상, 테두리, 모서리 둥글기

• 너비, 높이, 내부 패딩, 아이템 사이 간격

• 폰트 크기, 굵기, 줄 높이, 정렬 방식

• 그림자, 투명도, 블렌드 같은 시각 효과

이 정보가 정확하려면 디자인 파일 자체가 정리되어 있어야 합니다. 겉으로는 버튼처럼 보이지만 실제로는 사각형과 텍스트가 따로 떨어져 있고 Auto Layout도 없다면, Dev Mode에서 보이는 정보도 구현 의도를 충분히 설명하지 못합니다.

개발 전달 전 프레임 점검하기

개발자에게 링크를 보내기 전에 가장 먼저 확인할 것은 전달할 프레임입니다. 실무 파일에는 실험 중인 화면, 폐기된 시안, 중간 버전, 참고 이미지가 함께 섞여 있는 경우가 많습니다. 이 상태로 파일을 공유하면 개발자는 어떤 화면을 구현해야 하는지 헷갈립니다.

따라서 개발 전달용 영역을 별도로 만드는 것이 좋습니다. 예를 들어 페이지 안에 Ready for Dev 섹션을 만들고, 실제 구현 대상 화면만 모아둡니다. 이미 이전 장에서 협업과 버전 관리를 다뤘다면, 여기서는 그 정리의 목적이 더욱 분명해집니다. 개발자가 볼 화면과 논의 중인 화면을 분리하는 것입니다.

개발 전달용 프레임에는 다음 정보가 명확해야 합니다.

• 화면 이름과 상태가 프레임 이름에 드러난다.

• 최종 구현 대상 화면만 Ready for Dev 영역에 있다.

• 같은 화면의 기본, 오류, 로딩, 빈 상태가 함께 정리되어 있다.

• 사용하지 않는 과거 시안과 테스트용 레이어가 제거되거나 별도 영역으로 분리되어 있다.

프레임 하나가 개발의 출발점입니다. 출발점이 흐리면 이후 질문이 계속 늘어납니다.

컴포넌트와 상태 점검하기

개발자가 가장 곤란해하는 순간은 "상태가 없는 디자인"을 받을 때입니다. 버튼의 기본 상태는 있는데 비활성화 상태가 없고, 입력창의 기본 상태는 있는데 오류 상태가 없으며, 리스트는 데이터가 있을 때만 있고 비어 있을 때 화면이 없습니다. 이러면 개발자는 구현 중에 판단해야 합니다.

피그마에서 Components와 Variants를 잘 만들어두면 이런 문제가 줄어듭니다. 버튼 컴포넌트에 Default, Hover, Pressed, Disabled, Loading 상태가 있다면 개발자는 상태별 구현을 예상할 수 있습니다. 입력창 컴포넌트에 Default, Focus, Filled, Error, Disabled가 있다면 폼 화면을 훨씬 안정적으로 만들 수 있습니다.

다만 모든 상태를 무작정 만들 필요는 없습니다. 실제 제품에서 필요한 상태를 우선 정리해야 합니다. 예를 들어 모바일 앱에서는 Hover 상태가 필요 없을 수 있고, 웹 관리자 페이지에서는 Hover와 Focus가 중요할 수 있습니다. 중요한 것은 "어떤 상태가 존재하는지"와 "언제 그 상태가 되는지"가 명확한 것입니다.

개발 전달 전에 컴포넌트를 하나씩 확인해 보세요. 메인 컴포넌트가 살아 있는지, 인스턴스가 임의로 깨져 있지 않은지, Variant 속성 이름이 이해 가능한지 살피는 것이 좋습니다. Property 1 = Variant2 같은 이름은 개발자에게 아무 정보도 주지 못합니다. state = error, type = primary, size = large처럼 속성의 의미가 드러나야 합니다.

Variables와 Styles 연결 확인하기

이전 장에서 Variables와 Styles를 배웠다면, 이제 그 효과가 개발 핸드오프에서 드러납니다. 색상, 간격, 반경, 텍스트 스타일이 변수나 스타일에 연결되어 있으면 개발자는 디자인 값을 개별 숫자로만 보지 않고 시스템의 일부로 이해할 수 있습니다.

예를 들어 화면 안에 똑같아 보이는 회색 텍스트가 여러 개 있다고 가정해 보겠습니다. 하나는 본문 보조 텍스트이고, 하나는 비활성화 텍스트이며, 하나는 플레이스홀더입니다. 겉으로 비슷해 보여도 의미는 다릅니다. 이 값들이 각각 text/secondary, text/disabled, text/placeholder로 연결되어 있다면 개발자는 역할을 구분할 수 있습니다.

Variables는 특히 다크 모드나 브랜드 테마가 있는 프로젝트에서 중요합니다. 같은 컴포넌트라도 라이트 모드와 다크 모드에서 다른 색을 사용해야 한다면, 색상 값을 직접 바꾸는 방식보다 변수 모드를 활용하는 편이 안정적입니다. 개발자도 같은 구조로 테마 토큰을 설계할 수 있습니다.

전달 전에 다음을 점검해 보세요.

• 주요 색상과 텍스트가 Styles 또는 Variables에 연결되어 있는가?

• 같은 의미의 값이 화면마다 다른 숫자로 흩어져 있지 않은가?

• 변수 이름이 개발자가 이해할 수 있는 의미 단위로 되어 있는가?

• 임시 색상, 임시 폰트, 테스트용 값이 최종 화면에 남아 있지 않은가?

값은 숫자이고, 이름은 약속입니다. 개발 핸드오프에서는 숫자보다 약속이 더 오래 살아남습니다.

화면 상태를 빠뜨리지 않기

실제 서비스 화면은 항상 예쁜 기본 상태로만 존재하지 않습니다. 데이터가 없을 수도 있고, 네트워크가 느릴 수도 있고, 사용자가 잘못 입력할 수도 있습니다. 개발자는 이런 상황까지 구현해야 합니다.

따라서 개발 전달용 화면에는 주요 상태가 함께 있어야 합니다. 특히 기획자와 디자이너, 개발자가 함께 확인해야 하는 화면에서는 상태 누락이 곧 일정 지연으로 이어질 수 있습니다.

대표적으로 확인해야 할 상태는 다음과 같습니다.

• 기본 상태: 사용자가 처음 화면에 들어왔을 때 보이는 모습

• 입력 상태: 사용자가 값을 입력했거나 선택을 완료한 모습

• 오류 상태: 잘못된 입력, 실패한 요청, 권한 문제 등이 발생한 모습

• 로딩 상태: 데이터를 불러오거나 작업이 진행 중인 모습

• 빈 상태: 아직 데이터가 없거나 검색 결과가 없는 모습

• 완료 상태: 저장, 결제, 제출 등 주요 행동이 끝난 모습

모든 화면에 모든 상태가 필요한 것은 아닙니다. 하지만 사용자가 행동하는 화면이라면 적어도 오류와 로딩, 빈 상태를 한 번은 의심해 보아야 합니다. "이 상태가 없으면 개발자가 알아서 만들겠지"라는 생각은 위험합니다. 개발자가 알아서 만들면 제품의 경험이 화면마다 달라질 수 있습니다.

Export 설정으로 에셋 전달하기

개발자가 디자인 파일에서 직접 구현할 수 없는 요소도 있습니다. 대표적으로 로고 이미지, 사진, 일러스트, 일부 아이콘, 문서용 PDF 등이 그렇습니다. 이런 요소는 Export 설정을 통해 내려받을 수 있게 준비해야 합니다.

피그마에서는 레이어나 프레임을 선택한 뒤 오른쪽 패널의 Export 영역에서 내보내기 형식을 지정할 수 있습니다. 자주 쓰는 형식은 PNG, SVG, PDF입니다. 각각의 용도가 다릅니다.

PNG는 배경이 투명한 비트맵 이미지에 자주 사용됩니다. 앱 화면 안에 들어가는 작은 이미지, 그림자가 포함된 그래픽, 복잡한 일러스트를 전달할 때 적합합니다. 모바일 앱에서는 해상도 대응을 위해 1x, 2x, 3x처럼 배율을 나누어 내보내기도 합니다.

SVG는 벡터 기반 형식입니다. 아이콘처럼 크기가 바뀌어도 선명해야 하는 요소에 적합합니다. 단순한 선 아이콘이나 면 아이콘은 가능하면 SVG로 전달하는 것이 좋습니다. 다만 SVG 안에 불필요한 그룹, 마스크, 숨겨진 레이어가 많으면 개발자가 다루기 어려울 수 있으므로 내보내기 전 정리해야 합니다.

PDF는 문서나 인쇄에 가까운 자료를 전달할 때 유용합니다. 화면 UI의 개별 아이콘보다는 제안서, 가이드, 시안 검토용 문서, 출력용 자료에 더 잘 맞습니다.

에셋 내보내기 팁

• 아이콘은 가능하면 SVG로 전달하고, 크기 기준을 24x24, 20x20처럼 명확히 맞춥니다.

• 사진이나 복잡한 그래픽은 PNG 또는 JPG 계열로 전달하되, 실제 사용 크기보다 지나치게 큰 파일은 피합니다.

• 로고는 배경색 버전, 흰색 버전, 심볼 단독 버전처럼 필요한 사용 조건을 함께 정리합니다.

• 버튼, 카드, 입력창처럼 코드로 구현해야 하는 UI는 이미지로 내보내지 않습니다.

마지막 문장이 특히 중요합니다. 초보자는 화면을 그대로 이미지로 잘라 전달하면 편하다고 생각할 수 있습니다. 하지만 버튼이나 카드 같은 UI를 이미지로 만들면 텍스트 수정, 반응형 대응, 접근성, 다국어 처리가 어려워집니다. 개발자가 코드로 구현해야 하는 요소와 이미지로 전달해야 하는 요소를 구분해야 합니다.

아이콘 전달 기준 세우기

아이콘은 작지만 핸드오프에서 자주 문제를 일으킵니다. 어떤 아이콘은 24px 프레임 안에 들어 있고, 어떤 아이콘은 23.7px 크기이며, 어떤 아이콘은 선 두께가 다르고, 어떤 아이콘은 그룹 이름이 엉망인 경우가 많습니다.

개발자에게 아이콘을 전달할 때는 시각적으로만 맞추지 말고 규격을 맞추어야 합니다. 보통 모바일과 웹 UI에서는 16px, 20px, 24px 같은 기준 크기를 많이 사용합니다. 아이콘 프레임은 기준 크기에 맞추고, 실제 도형은 그 안에서 시각적으로 균형 있게 배치합니다.

또 하나 중요한 것은 색상입니다. 아이콘 자체에 고정 색상을 박아두면 개발자가 상태별 색상을 바꾸기 어렵습니다. 가능하다면 아이콘은 현재 색상을 따라가거나, 디자인 토큰에 맞춰 색상을 적용할 수 있도록 구조를 단순하게 유지하는 편이 좋습니다.

아이콘 이름도 구현에 영향을 줍니다. Vector 47보다 icon/search, icon/chevron-right, icon/close처럼 이름을 붙이면 에셋 관리가 쉬워집니다. 이름만 잘 붙여도 개발자의 질문이 줄어듭니다.

개발자 질문을 줄이는 주석 쓰기

좋은 주석은 디자인을 설명하는 것이 아니라 판단 기준을 남기는 것입니다. "이 버튼은 파란색입니다"라는 주석은 거의 필요 없습니다. 색상 값은 Dev Mode에서 볼 수 있기 때문입니다. 대신 "입력값이 하나라도 비어 있으면 Disabled 상태를 유지합니다" 같은 주석은 매우 유용합니다.

주석은 화면 위에 너무 많이 붙이면 오히려 방해가 됩니다. 중요한 조건, 예외, 정책만 남겨야 합니다. 특히 기획서에 있지만 화면만 보고는 알 수 없는 정보를 적으면 좋습니다.

예를 들어 회원가입 화면이라면 비밀번호 조건, 오류 문구 노출 시점, 인증번호 재전송 제한 시간이 중요합니다. 결제 화면이라면 쿠폰 적용 실패, 포인트 부족, 결제 수단 선택 조건이 중요합니다. 리스트 화면이라면 데이터가 없을 때, 1개일 때, 아주 많을 때의 처리가 중요합니다.

주석 작성 팁

• 눈에 보이는 모양보다 눈에 보이지 않는 조건을 적습니다.

• "언제 이 상태가 되는지"를 중심으로 설명합니다.

• 오류 문구, 빈 상태 문구, 로딩 조건처럼 개발자가 임의로 만들기 어려운 정보를 남깁니다.

• 확정되지 않은 내용은 검토 중, 기획 확인 필요처럼 상태를 표시합니다.

주석은 친절해야 하지만 장황할 필요는 없습니다. 개발자가 구현 중에 멈추지 않도록 딱 필요한 만큼만 안내하는 것이 좋습니다.

Inspect 셀프 체크: 개발자 눈으로 다시 보기

개발 전달 직전에는 디자이너 모드가 아니라 개발자 모드로 파일을 봐야 합니다. 이때는 예쁜지보다 구현 가능한지를 확인합니다.

가장 좋은 방법은 실제로 Dev Mode에 들어가서 주요 화면을 하나씩 클릭해 보는 것입니다. 프레임 이름이 보이는지, 요소 이름이 이상하지 않은지, 색상과 텍스트가 스타일에 연결되어 있는지, Export 가능한 에셋이 제대로 지정되어 있는지 확인합니다.

Inspect 셀프 체크 박스

• 프레임 이름만 보고 화면과 상태를 이해할 수 있는가?

• 버튼, 입력창, 카드, 모달 같은 반복 UI가 컴포넌트로 정리되어 있는가?

• 기본, 오류, 로딩, 비활성화, 빈 상태가 필요한 만큼 준비되어 있는가?

• 색상, 폰트, 간격, 반경 값이 Styles 또는 Variables와 연결되어 있는가?

• 아이콘과 이미지는 Export 설정이 되어 있고 파일 이름이 명확한가?

• 개발자가 물어볼 만한 조건은 주석이나 별도 설명으로 남겨져 있는가?

이 체크를 한 번만 해도 개발자와의 대화가 달라집니다. "이건 몇 px인가요?"라는 질문보다 "이 상태는 어떤 조건에서 노출되나요?"처럼 더 중요한 질문으로 넘어갈 수 있습니다.

개발 핸드오프용 페이지 구성 예시

실무에서는 파일 하나에 많은 내용이 들어갑니다. 그래서 개발 전달용 구조를 따로 잡아두면 좋습니다. 초보자라면 다음과 같은 방식으로 페이지나 섹션을 구성해 볼 수 있습니다.

• Cover: 프로젝트 이름, 담당자, 최근 업데이트 날짜를 적는 표지

• Ready for Dev: 실제 개발 대상 화면을 모아둔 영역

• Flow: 사용자가 이동하는 순서를 보여주는 프로토타입 흐름

• Components: 버튼, 입력창, 카드, 모달 같은 주요 컴포넌트

• States: 오류, 빈 상태, 로딩, 완료 등 화면 상태 모음

• Assets: 로고, 아이콘, 이미지, 일러스트 등 내보내기 대상

• Notes: 정책, 예외 조건, 개발자와 합의한 사항

이 구조를 반드시 그대로 따라야 하는 것은 아닙니다. 중요한 것은 개발자가 길을 잃지 않는 것입니다. 파일을 열었을 때 "어디를 보면 되는지"가 10초 안에 보여야 합니다.

특히 Ready for Dev 영역은 깨끗해야 합니다. 검토 중인 시안, 버려진 버전, 연습용 레이어가 섞이면 안 됩니다. 고민의 흔적은 작업 영역에 남겨도 되지만, 전달 영역은 결정된 내용만 담는 것이 좋습니다.

개발자에게 링크를 보낼 때 함께 적을 내용

피그마 링크만 던지는 것은 친절한 핸드오프가 아닙니다. 개발자가 파일을 열기 전에 무엇을 보면 되는지 알려주면 훨씬 빠르게 시작할 수 있습니다.

공유 메시지에는 구현 대상, 확인해야 할 영역, 주의할 상태, 미확정 사항을 간단히 적습니다. 예를 들어 다음과 같은 식입니다.

로그인/회원가입 1차 화면 전달드립니다. Figma 파일의 Ready for Dev 섹션을 기준으로 봐주세요. Login / Default, Login / Error, Login / Loading 상태가 구현 대상입니다. 아이콘은 Assets 섹션에서 SVG로 Export 가능하게 설정했습니다. 비밀번호 정책 문구는 기획 확인 중이라 Notes에 표시해 두었습니다.

이런 메시지는 길지 않지만 강력합니다. 개발자는 파일을 열기 전부터 범위를 이해하고, 미확정 사항을 구분할 수 있습니다.

핸드오프는 끝이 아니라 대화의 시작이다

개발 핸드오프를 "디자인을 넘기고 끝내는 일"로 생각하면 문제가 생깁니다. 실제 구현 과정에서는 예상하지 못한 제약이 드러납니다. 특정 효과가 성능에 부담을 줄 수도 있고, 텍스트가 다국어에서 훨씬 길어질 수도 있으며, 운영 데이터가 디자인보다 복잡할 수도 있습니다.

좋은 핸드오프는 개발자가 질문하지 않게 만드는 것이 아니라, 불필요한 질문을 줄이고 중요한 질문을 빠르게 하게 만드는 것입니다. 색상 값이나 간격 같은 단순 확인에 시간을 쓰지 않고, 상태 정책과 구현 방식 같은 중요한 논의에 집중하게 만드는 것이 목표입니다.

디자인 파일은 팀의 약속을 담는 문서입니다. Dev Mode는 그 약속을 개발자가 읽을 수 있게 해주는 도구입니다. 파일을 정리하는 일은 귀찮은 마무리 작업이 아니라, 제품이 실제로 만들어지는 속도를 높이는 실무 능력입니다.

핵심 요약

• Dev Mode는 개발자가 디자인의 크기, 간격, 색상, 폰트, 코드형 속성, 에셋 정보를 확인할 수 있게 도와주는 모드입니다.

• 개발 전달 전에는 프레임 이름, 컴포넌트 상태, Styles, Variables, 화면 상태를 반드시 점검해야 합니다.

• Auto Layout과 Constraints가 잘 적용된 파일은 개발자가 구현 의도를 이해하기 쉽습니다.

• PNG, SVG, PDF는 용도가 다르며, 아이콘은 가능한 한 규격화된 SVG로 전달하는 것이 좋습니다.

• 좋은 주석은 보이는 모양을 반복 설명하지 않고, 상태가 발생하는 조건과 예외 정책을 알려줍니다.

• 핸드오프의 목표는 완벽한 설명서가 아니라 개발자가 바로 구현을 시작할 수 있는 명확한 기준을 제공하는 것입니다.

실습 과제: 완성된 화면을 개발 전달용으로 정리하기

이번 실습에서는 이전 장에서 만든 화면 중 하나를 골라 개발자에게 전달 가능한 상태로 정리합니다. 로그인 화면, 회원가입 화면, 상품 상세 화면, 대시보드 화면 중 어떤 것이든 좋습니다.

1단계: Ready for Dev 영역 만들기

피그마 파일 안에 Ready for Dev라는 섹션을 만듭니다. 그 안에 실제 구현할 최종 화면만 복사해 넣습니다. 작업 중인 시안이나 버려진 버전은 넣지 않습니다.

프레임 이름은 다음처럼 화면과 상태가 보이게 수정합니다.

• Login / Default

• Login / Error

• Login / Loading

• Login / Success

2단계: 컴포넌트 상태 확인하기

화면 안에 있는 버튼, 입력창, 체크박스, 카드 같은 반복 요소를 확인합니다. 컴포넌트로 만들 수 있는 요소는 컴포넌트로 정리하고, 상태가 필요한 요소는 Variant로 나눕니다.

최소한 버튼은 기본 상태와 비활성화 상태를 준비해 보세요. 입력창이 있다면 기본, 포커스, 오류 상태를 만들어 봅니다.

3단계: Styles와 Variables 확인하기

주요 색상과 텍스트가 스타일 또는 변수에 연결되어 있는지 확인합니다. 임시로 직접 찍은 색상 값이 남아 있다면 의미 있는 이름의 스타일이나 변수로 바꿉니다.

예를 들어 버튼 배경은 color/brand/primary, 본문 텍스트는 color/text/primary, 보조 텍스트는 color/text/secondary처럼 정리해 봅니다.

4단계: Export 설정하기

화면에 아이콘, 로고, 이미지가 있다면 Export 설정을 추가합니다. 아이콘은 SVG, 복잡한 이미지는 PNG로 설정해 봅니다. 파일 이름도 icon-search, logo-main, image-profile-empty처럼 알아보기 쉽게 바꿉니다.

단, 버튼이나 입력창처럼 코드로 구현해야 하는 UI는 이미지로 내보내지 않습니다.

5단계: Dev Mode에서 셀프 점검하기

Dev Mode로 전환한 뒤 개발자 입장에서 화면을 클릭해 봅니다. 버튼의 높이, 내부 여백, 텍스트 스타일, 색상, 아이콘 Export가 제대로 보이는지 확인합니다.

마지막으로 화면 옆에 짧은 주석을 남깁니다. 오류 상태가 언제 나타나는지, 로딩 상태가 언제 필요한지, 아직 미확정인 내용이 무엇인지 적어 보세요.

실습이 끝났다면 스스로에게 질문해 봅니다. "이 파일을 처음 보는 개발자가 10분 안에 구현 범위와 필요한 값을 이해할 수 있을까?" 이 질문에 "그렇다"라고 답할 수 있다면, 이제 여러분의 디자인은 단순한 그림이 아니라 개발 가능한 설계에 가까워진 것입니다.