figma2024년 11월 18일

개발자가 디자인에 적극적으로 참여 (새 탭에서 열림)

Figma의 Dev Mode는 개발자를 디자인의 수동적 구현자가 아니라 제품 설계에 참여하는 협업자로 바라보게 한다. 개발자가 디자인 도구를 적극적으로 사용하고 필요한 개선을 직접 제안하면, 디자인 파일 탐색의 불안과 반복적인 탭 전환을 줄이고 디자이너와의 공통 언어를 만들 수 있다. 글은 Dev Mode 도입을 조직에 요구하는 일이 개발자 경험과 생산성, 협업 품질을 개선하는 실질적인 방법이라고 결론짓는다. ## 개발자는 디자인 과정의 참여자다 - 기존에는 디자인 도구를 디자이너만 사용하는 것으로 여겨 개발자가 파일을 조심스럽게 열어보거나 여러 브라우저 탭을 오가며 사양을 확인했다. - 이런 역할 분리는 디자인과 구현 사이의 소통 비용을 키우고, 개발자가 제품 결정에 기여할 기회를 줄인다. - Dev Mode는 개발자에게 별도의 작업 공간과 기능을 제공해 기획부터 출시까지 디자인 과정에 참여할 수 있게 한다. - 개발자가 Dev Mode의 필요성을 조직에 설명하고 도입을 주도해야 더 나은 협업 환경을 만들 수 있다. ## 공유 도구가 만드는 공통 언어 - Dev Mode는 개발자가 디자인을 단순히 구현하는 사람이 아니라 적극적인 협업자라는 전제를 바탕으로 한다. - Figma의 오토 레이아웃은 개발자에게 CSS Flexbox와 유사하게 느껴져 디자인의 레이아웃 동작을 웹 구현 방식과 연결해 주었다. - 이러한 공통 개념은 디자이너와 개발자가 서로의 작업 방식을 이해하는 접점이 된다. - Dev Mode는 특정 기능 하나를 넘어, 양쪽 직군이 같은 파일과 개념을 바탕으로 소통하는 협업 프레임워크를 제공한다. ## 개발자가 직접 도입을 제안해야 하는 이유 - 관리자는 실제 작업에서 한 단계 떨어져 있어 개발자가 겪는 불편과 생산성 저하를 놓칠 수 있다. - 개발자는 GitHub 이슈, 풀 리퀘스트 의견, Stack Overflow 답변처럼 필요한 개선을 직접 제안하는 데 익숙하다. - 같은 방식으로 1:1 미팅, 스프린트 회고, 팀 회의에서 디자인 도구와 개발자 경험의 문제를 구체적으로 제기할 수 있다. - 단순히 “새 도구가 필요하다”고 말하기보다, 현재의 반복 작업과 협업 비용을 어떤 기능이 어떻게 줄이는지 설명해야 설득력이 높아진다. ## 두려움 없이 디자인 파일 탐색하기 - Dev Mode는 기본적으로 읽기 전용이므로 개발자가 실수로 디자인 파일을 수정하거나 다른 사람의 작업을 덮어쓸 위험을 줄인다. - 개발자는 여백, 컴포넌트, 레이아웃 등을 자유롭게 클릭하며 파일 구조를 탐색할 수 있다. - 이는 Git의 `main` 브랜치 보호와 비슷한 안전장치로, 파일을 망칠까 봐 지나치게 조심하는 상황을 없앤다. - 결과적으로 디자인 파일을 이해하는 데 필요한 탐색 시간이 줄고, 개발자의 사용 자신감이 높아진다. ## 변경 사항을 명확하게 비교하기 - Dev Mode의 버전 기록과 변경 사항 비교 기능은 GitHub의 커밋 기록이나 풀 리퀘스트와 유사한 방식으로 동작한다. - 디자인의 여러 버전을 시각적으로 비교해 무엇이 언제, 누구에 의해 변경되었는지 확인할 수 있다. - 문구 변경, 여백 수정, 컴포넌트 변형 추가처럼 변경 항목을 구체적인 작업 목록으로 파악할 수 있다. - 이를 통해 개발자는 최신 디자인을 빠르게 이해하고, 구현 과정에서 누락된 변경 사항을 줄일 수 있다. ## 디자인 사양과 코드 사이의 탭 전환 줄이기 - 기존 개발자는 디자인 사양, 문서, 코드 저장소를 오가며 정보를 확인해야 했고, 이 과정에서 많은 시간이 소모됐다. - Dev Mode와 Code Connect 같은 기능은 디자인 정보와 실제 코드 구현 사이의 거리를 줄이는 방향으로 설계됐다. - 디자인 확인과 개발에 필요한 정보를 한 작업 흐름 안에서 연결하면 반복적인 검색과 컨텍스트 전환을 줄일 수 있다. - 이는 단순한 편의 기능을 넘어 개발자의 집중력과 전체 개발 속도에도 영향을 준다. ## 실용적인 적용 방향 - 현재 디자인 파일을 확인할 때 발생하는 실수, 정보 탐색, 탭 전환 시간을 구체적으로 기록한다. - Dev Mode의 읽기 전용 탐색, 버전 비교, 코드 연결 기능이 각각 어떤 문제를 해결하는지 사례로 제시한다. - 디자인 시스템 개편이나 원격·하이브리드 협업처럼 여러 직군의 긴밀한 조율이 필요한 프로젝트에서 먼저 적용한다. - 도구 도입 자체보다 디자이너와 개발자가 공유할 수 있는 언어와 작업 방식을 만드는 데 초점을 둔다.

flexboxfigmadesign-systemsgithub+3

figma2024년 8월 20일

개발 모드와 함께한 (새 탭에서 열림)

Figma Dev Mode를 1년간 도입한 Decathlon의 경험에 따르면, 이 도구는 디자인과 개발 사이의 협업을 크게 개선할 수 있다. 특히 Code Connect를 활용하면 Figma 컴포넌트와 실제 코드 간의 속성, 명명 규칙, 상태를 직접 연결할 수 있어 디자인 시스템 운영이 정교해진다. 다만 기존 업무 방식을 한 번에 바꾸기보다 작은 성공 사례부터 시작하고, 명확한 문서화와 완료 기준을 마련하는 것이 중요하다. ## 디자인과 코드의 연결: Code Connect - Dev Mode의 가장 큰 효과는 Figma 컴포넌트를 실제 컴포넌트 코드와 연결하는 **Code Connect**에서 나타났다. - 디자인과 코드에서 컴포넌트 구조가 다르더라도 다음 문제를 조정하는 데 도움이 된다. - 속성 및 프로퍼티 정렬 - 컴포넌트 이름 규칙 통일 - 상태 관리 방식 일치 - 디자인 토큰을 Figma에서 명확히 표현하면 개발자가 시각적 의사결정을 코드 수준에서 이해하기 쉬워진다. - 색상 값과 토큰 이름을 연결하면 디자인 토큰 변경 사항이 대응하는 코드 변경으로 즉시 이어진다. ## 작게 시작하고 확장하기 - 개발자에게 새로운 도구는 기존 업무 흐름을 방해할 수 있으므로, Dev Mode를 전면 도입하기보다 작은 범위에서 시작했다. - 초기에는 Figma Variables를 활용한 디자인 토큰 관리처럼 빠르게 효과를 확인할 수 있는 영역에 집중했다. - **변수 별칭(variable aliasing)**을 사용하면 원시 토큰과 의미론적 토큰 사이에 계층을 만들 수 있다. - 테마 구현이 쉬워진다. - 팀원이 토큰 체계를 이해하고 적용하기 쉬워진다. - 변수 스코핑을 설정하면 특정 변수가 적용될 수 있는 속성을 제한할 수 있다. - 배경색을 텍스트 색상에 사용하는 실수 방지 - 간격 값을 테두리 반경에 사용하는 잘못된 적용 방지 - 변수의 코드 표기법을 플랫폼별 개발자 명명 규칙에 맞게 사용자 지정할 수 있다. ## 고급 검사 기능으로 레이아웃 확인 - Dev Mode는 복잡한 UI 레이아웃과 Flexbox 기반 구조를 검사하고 구현 가능한 코드로 확인하는 데 유용하다. - 개발자는 다음 플랫폼의 구현 속성을 직접 살펴볼 수 있다. - 웹 CSS - iOS의 SwiftUI와 UIKit - Android의 XML과 Compose - 디자이너와 디자인 시스템 담당자는 컴포넌트가 요구사항에 맞게 구현될 수 있는지 구체적으로 검증할 수 있다. - Figma VS Code 확장을 이용하면 CSS, Compose, SwiftUI 코드 탐색과 자동완성을 IDE 안에서 처리할 수 있다. - 결과적으로 디자인 파일을 별도로 해석해 코드를 작성하는 부담이 줄어든다. ## 완료 기준과 문서화 통일 - 디자인 시스템 문서는 지속적으로 최신 상태를 유지하기 어렵고, 디자인 의도나 세부 요구사항이 개발 과정에서 누락되기 쉽다. - Dev Mode의 문서화 및 주석 기능을 사용하면 디자인 파일 안에 필요한 정보를 직접 남길 수 있다. - 주석에는 다음 내용을 포함할 수 있다. - 자유로운 설명 문장 - 정렬 및 크기 같은 명시적 값 - 간격과 치수를 보여주는 측정 정보 - 디자이너는 개발자에게 특정 주석을 직접 연결해 의도와 구현 조건을 명확히 전달할 수 있다. - 팀에서는 각 컴포넌트에 다음 자료를 함께 연결하는 문서화 체계를 구축했다. - GitHub 소스 코드 - README - 관련 플레이그라운드 - 이를 통해 “디자인 완료”와 “개발 완료”의 기준을 팀 전체가 같은 방식으로 이해할 수 있다. ## 적용 시 권장 방식 - Dev Mode를 도입할 때는 기존 개발 프로세스를 즉시 대체하기보다 디자인 토큰이나 변수처럼 효과가 명확한 영역부터 시작하는 것이 좋다. - 토큰 계층, 변수 스코핑, 코드 명명 규칙을 먼저 정리하면 이후 Code Connect와 컴포넌트 문서화의 효과가 커진다. - 검사 기능만 사용하는 데 그치지 말고, 주석·소스 코드·README·플레이그라운드를 연결해 디자인 시스템의 단일한 참고 지점을 만들어야 한다.

flexboxdesign-systemsdesign-tokensswiftui+4

figma2020년 11월 18일

기능 비하인드: 새로운 (새 탭에서 열림)

Figma의 새 Auto Layout은 수동으로 요소 크기와 간격을 조정하던 작업을 자동화하면서도, CSS Flexbox의 강력함을 그대로 복잡하게 노출하지 않는 방향으로 설계됐다. 핵심 원칙은 “Flexbox의 신중한 부분집합”으로, 코드와 디자인의 정렬을 돕되 누구나 쉽게 이해하고 사용할 수 있게 만드는 것이었다. 새 버전은 사용자 피드백을 바탕으로 유연성과 기능을 확장한 결과다. ## 수동 리사이징 문제에서 출발한 Auto Layout - Auto Layout 출시 전에는 버튼의 텍스트가 길어지면 다음 작업을 직접 해야 했다. - 버튼 크기 조정 - 주변 버튼 위치 이동 - 대화상자 컨테이너 크기 조정 - 패딩과 간격 재조정 - 이런 수작업은 단순히 번거로운 것을 넘어 반응형 디자인 시스템 구축의 장애물이 됐다. - Figma 초기 설계에도 프레임 내부 객체를 자동으로 배치하는 아이디어가 있었지만, 제품 출시 당시에는 구현되지 않았다. - 2018년 Maker Week에서 제품 디렉터 Sho가 초기 아이디어를 다시 프로토타입으로 발전시켰고, 이후 전담 팀이 Auto Layout을 실제 기능으로 구현하기 시작했다. ## Flexbox를 참고하되 단순하게 설계 - 팀은 웹 기술인 CSS Flexbox의 강력함과 범용성에서 영감을 얻었다. - 디자인과 코드 사이의 개념적 일치를 높이려면 Flexbox와 유사한 모델이 유리했다. - 그러나 사용자가 브라우저와 CSS를 깊이 이해해야 한다면 Figma의 접근성이 떨어질 수 있었다. - 이에 따라 “Auto Layout은 Flexbox의 신중한 부분집합이어야 한다”는 설계 원칙을 세웠다. - 이 원칙은 기능을 추가하면서도 설정 항목과 동작 규칙을 불필요하게 복잡하게 만들지 않도록 팀의 의사결정을 이끌었다. ## 첫 번째 Auto Layout의 핵심 개념 - 프레임에 Auto Layout을 적용하면 내부 요소를 수직 또는 수평으로 배치할 수 있다. - 요소 사이의 수직·수평 간격을 지정할 수 있다. - Auto Layout 프레임은 기본적으로 주축 방향에서 내부 컴포넌트 크기에 맞춰 늘어나거나 줄어든다. - 반대축 방향도 고정 너비 또는 내부 콘텐츠에 맞추는 방식으로 설정할 수 있다. - 프레임 내부의 각 컴포넌트는 컨테이너 기준으로 개별 정렬할 수 있다. - 수직 레이아웃에서는 좌·중앙·우 정렬 - 수평 레이아웃에서는 상·중앙·하 정렬 ## HTML 프로토타입과 초기 검증 - Auto Layout 디자이너 Marcin은 처음부터 HTML로 프로토타입을 제작했다. - 실제 웹 환경과 유사한 프로토타입을 통해 기능의 사용감과 동작을 조기에 확인할 수 있었다. - 이 과정에서 다음과 같은 세부 동작을 구체화했다. - 프레임 핸들의 시각적 장식 - 객체를 드래그할 때의 동작 - Auto Layout 프레임의 외곽선 표시 - 초기 프로토타입은 기능 목록을 정하는 데 그치지 않고, 편집기에서 사용자가 기능을 어떻게 인식하고 조작할지 검증하는 역할을 했다. ## 기능 확장과 사용성 사이의 균형 - 초기 Auto Layout은 접근성과 직관성을 우선해 설계됐다. - 이후 사용자 피드백을 반영하면서 더 강력하고 유연한 레이아웃 기능을 추가했다. - 다만 유연성을 높일수록 설정과 예외 상황이 늘어나 사용성이 떨어질 수 있으므로, 기능의 범위를 의도적으로 제한했다. - 새 버전은 단순한 UI 변경이 아니라, 초기의 단순한 모델을 유지하면서 더 다양한 반응형 레이아웃 요구를 수용하려는 설계 개선이다. Auto Layout을 설계할 때는 Flexbox처럼 검증된 레이아웃 모델을 참고하되, 사용자가 모든 내부 규칙을 학습하지 않아도 되도록 핵심 개념만 제공하는 것이 중요하다. 또한 실제 편집 환경을 반영한 프로토타입과 사용자 피드백을 통해 기능의 유연성과 조작의 직관성을 함께 검증해야 한다.

flexboxfigmadesign-systemscss+3

figma2020년 9월 16일

코드와 디자인 사이의 긴 (새 탭에서 열림)

Figma는 디자인의 자유로운 탐색과 코드의 구조적·재사용 가능한 접근 사이의 긴장을 없애기보다 생산적인 협업 방식으로 받아들여야 한다고 주장한다. 이를 위해 디자인 시스템을 코드의 컴포넌트 구조와 가깝게 만들고, 디자이너와 개발자가 같은 시스템을 더 효율적으로 이해하고 활용할 수 있도록 Variants, Interactive Components, 개선된 Auto Layout, Inspect Tab 등을 발표했다. 궁극적으로 Figma는 디자인과 코드를 분리된 작업이 아니라 제품을 함께 만드는 연결된 과정으로 발전시키려 한다. ## 디자인과 코드 사이의 긴장 - 디자이너는 무엇을 만들지 결정하며 자유로운 시각적 탐색과 빠른 반복을 중시한다. - 개발자는 정해진 구조 안에서 실제 제품을 구현하며 재사용성, 일관성, 규칙을 중시한다. - 개발자에게 컴포넌트를 “깨는” 행위가 디자이너에게는 창의적인 실험일 수 있고, 개발자의 구조가 디자이너에게는 제약처럼 느껴질 수 있다. - Figma는 코드의 엄격성과 재사용성을 디자인에 적용하되, 디자인의 빠른 반복과 자유로운 탐색은 유지해야 한다고 본다. ## Variants로 코드와 디자인 컴포넌트 연결 - 프런트엔드의 하나의 컴포넌트는 상태와 맥락에 따라 여러 형태로 표현된다. - 예: 버튼의 기본형·보조형 - 작은 크기·큰 크기 - iOS·Android별 스타일 - 기존 Figma에서는 이런 변형을 각각 별도의 컴포넌트로 관리해야 해 코드 구조와 디자인 구조가 달라졌다. - **Variants**는 같은 컴포넌트의 여러 변형을 하나의 논리적 컴포넌트로 그룹화한다. - 이를 통해 에셋 패널을 단순화하고, 디자인 컴포넌트를 코드의 컴포넌트 모델에 더 가깝게 표현할 수 있다. - 발표 당시 2020년 11월 출시 예정으로 소개됐다. ## Interactive Components로 프로토타이핑 간소화 - Variants를 사용하면 버튼이나 입력 필드의 여러 상태를 하나로 묶을 수 있다. - 기존에는 상태 간 전환을 표현하려면 여러 프레임과 오버레이를 수동으로 연결해야 했다. - **Interactive Components**는 Variants 사이에 프로토타이핑 상호작용을 직접 설정할 수 있게 한다. - 컴포넌트 인스턴스를 프로토타이핑 모드에서 즉시 동작하는 요소처럼 사용할 수 있어, 반복적인 프레임 연결 작업을 줄인다. - 당시 2021년 1월 출시 예정으로 발표됐다. ## 코드처럼 설계하는 Auto Layout - Auto Layout은 텍스트가 바뀌어도 버튼이나 프레임 크기가 자동으로 조정되도록 해 반응형 UI 제작을 돕는다. - Figma는 Auto Layout을 웹의 CSS 박스 모델과 Flexbox에 더 가깝게 발전시키려 했다. - 개선 사항에는 다음이 포함된다. - 더 단순해진 사용자 인터페이스 - 가로·세로 양축에서 요소를 늘리는 기능 - 방향별로 독립적인 패딩 설정 - 내비게이션 아이콘처럼 자주 쓰이는 UI 패턴에 맞춘 간격 설정 - 디자이너가 수동으로 위치와 크기를 조정하는 대신, 코드의 레이아웃 규칙에 가까운 방식으로 디자인할 수 있게 하는 것이 목표다. ## 대규모 디자인 시스템을 위한 컴포넌트 탐색 - 수천 개의 컴포넌트를 사용하는 대규모 라이브러리에서는 정확한 이름을 기억하거나 긴 목록을 직접 찾아야 하는 불편이 있었다. - **Instance Swap Menu**가 개선되어 다음 기능을 제공한다. - 컴포넌트 썸네일 - 검색 - 키보드 단축키 - Variants와 함께 사용하면 여러 컴포넌트를 일일이 찾는 부담을 줄이고, 대규모 디자인 시스템에서도 적절한 인스턴스를 빠르게 교체할 수 있다. - 이 기능은 글 작성 당시 바로 사용할 수 있는 기능으로 소개됐다. ## Inspect Tab으로 개발자 전달 정보 강화 - 기존 Code 패널을 대체하는 **Inspect Tab**은 개발자가 구현에 필요한 정보를 더 쉽게 확인하도록 설계됐다. - 선택한 레이어의 이름을 상단에 표시해 디자이너와 개발자가 어떤 요소를 구현하는지 명확히 확인할 수 있다. - 다음과 같은 디자인 속성을 구분해 보여준다. - Variants - 색상 - 그림자 - 콘텐츠 - 타이포그래피 - 테두리 - 개별 값을 클릭해 클립보드로 복사할 수 있으며, 여러 `key:value` 값으로 구성된 코드 조각도 한 번에 복사할 수 있다. - 디자인 명세를 별도로 정리하거나 개발자가 값을 수동으로 옮기는 과정을 줄여 구현 전환을 효율화한다. Figma의 방향은 디자인을 코드처럼 획일화하는 것이 아니라, 코드의 구조성과 재사용성을 디자인 시스템에 도입하면서도 디자이너의 창의적 탐색을 보존하는 것이다. 실무에서는 Variants로 상태와 스타일을 체계화하고, Auto Layout으로 레이아웃 규칙을 정의하며, Inspect Tab을 통해 개발자에게 구현 정보를 명확히 전달하는 방식이 효과적이다.

flexboxfigmadesign-systemsprototyping+4