atomic-design

8 개의 포스트

figma3분 읽기큐레이션 요약

AI: 디자인의 새로운

AI는 디자인 도구의 한 기능이 아니라 제품 개발 전반을 바꾸는 플랫폼이라는 것이 글의 핵심 주장이다. Figma는 Diagram을 인수하고 AI 역량을 강화해 아이디어 발굴부터 디자인, 개발 코드 생성까지 팀의 작업을 가속하려 한다. AI가 디자이너를 대체하기보다는 반복 작업을 줄이고 문제 해결과 창의적 판단에 더 집중하게 만들 것이라는 전망을 제시한다. ## Figma의 Diagram 인수와 AI 전략 - Figma는 GPT-3 기반 디자인 생성 플러그인 **Designer**를 만든 Jordan Singer의 팀 Diagram을 인수했다. - Diagram의 Jordan Singer, Siddarth, Andrew, Marco, Vincent가 Figma에 합류했다. - Figma는 이미 머신러닝 전담 팀을 운영하고 AI 플랫폼 개발에 투자해 왔다. - Figma의 오픈 API를 활용해 커뮤니티가 만든 AI 플러그인도 약 100개에 이른다. - AI를 단일 기능이 아니라 제품 개발 프로세스 전체를 지원하는 핵심 플랫폼으로 보고 있다. ## 제품 개발 전 과정의 AI 활용 - **발견 단계** - 간단한 프롬프트로 초기 아이디어를 생성한다. - 여러 아이디어를 요약하고 종합한다. - **디자인 단계** - 기존 디자인과 디자인 시스템을 분석한다. - 적절한 컴포넌트나 디자인 방향을 추천한다. - 더 빠르게 첫 시안을 만들 수 있도록 지원한다. - **개발 단계** - 디자인의 맥락을 개발자에게 더 빠르게 전달한다. - 제품 요구사항과 디자인을 바탕으로 더 나은 프로덕션 코드를 생성한다. - 결과적으로 AI는 반복 작업을 줄이고 팀이 더 빠르게 문제 해결과 제품 완성도 향상에 집중하도록 돕는다. ## 기술 발전과 디자인의 변화 - 인쇄기, 스마트폰, 협업 도구, 하이브리드 근무처럼 디자인은 기술 변화에 따라 계속 진화해 왔다. - 새로운 기술이 등장해도 사려 깊은 디자인의 필요성이 사라진 것은 아니었다. - AI 역시 디자인을 없애기보다 디자이너의 작업 방식과 역할을 변화시킬 것으로 본다. ## 픽셀에서 패턴으로: 더 높은 수준의 설계 - 디자인 시스템은 모서리 반경이나 버튼 같은 반복적인 세부 작업을 줄이고, 디자이너가 콘셉트와 방향성에 집중하게 했다. - 원자적 요소인 픽셀이 컴포넌트와 같은 더 큰 구조로 결합되면서 작업 속도와 일관성이 향상됐다. - AI는 디자인 시스템보다 더 높은 수준의 구조와 패턴을 제안할 수 있다. - 예를 들어 로그인 화면의 이메일 입력창과 비밀번호 입력창을 만드는 데 그치지 않고, 이메일·전화번호·Touch ID를 대체할 새로운 로그인 방식을 제안할 수 있다. - 프로젝트의 감정적 분위기나 주제에 맞는 색상 팔레트를 자동으로 추천하는 것도 가능하다. - 디자인은 개별 픽셀을 조정하는 작업에서 벗어나 더 직관적이고 인간적인 경험을 설계하는 방향으로 이동한다. ## 새로운 디지털 경험의 등장 - ChatGPT와 같은 AI는 웹사이트와 앱을 탐색하는 기존 방식에서 벗어나 질문하고 답을 받는 인터페이스를 강화한다. - AI는 사용자의 의도와 실제 행동 사이의 간극을 줄일 수 있다. - 예를 들어 사용자가 차량 호출 앱에서 위치와 옵션을 여러 단계로 입력하는 대신, “JFK 공항으로 데려다줘”라고 말하면 AI가 필요한 절차를 처리할 수 있다. - 제품 설계자는 기능과 화면 수를 늘리는 대신, 사용자의 목적을 더 적은 클릭과 판단으로 달성하게 할 방법을 고민해야 한다. ## 디자이너와 제품 역할의 변화 - 글은 AI 시대에 제품 역할과 협업 방식도 변화할 것이라고 예고한다. - 반복적인 제작 업무가 자동화되면 디자이너는 결과물을 직접 만드는 일뿐 아니라 AI가 제안한 결과를 선택하고 다듬는 큐레이터 역할을 더 많이 맡게 될 가능성이 있다. - 디자인의 핵심 가치는 여전히 문제를 정의하고, 적절한 방향을 판단하며, 사람에게 의미 있는 경험을 만드는 데 있다. AI를 도입할 때는 단순히 디자인 산출물을 자동 생성하는 데 그치지 말고, 아이디어 정리·패턴 탐색·프로토타이핑·개발 전달 등 전체 흐름에서 반복 작업을 줄이는 방향을 고려하는 것이 실용적이다. 최종 품질과 사용자 경험을 결정하는 문제 정의와 판단은 여전히 사람의 중요한 역할로 남는다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

Figma on Figma: Figma

Figma는 제품 디자인뿐 아니라 마케팅 웹사이트에도 디자인 시스템이 필요하다고 판단하고, 기존 페이지의 시각 요소와 제작 방식을 체계화했다. 반복되는 요소를 통합하고 재사용 가능한 컴포넌트와 조합형 섹션을 구축한 결과, 일관성을 유지하면서도 코드 작성 없이 아이디어에서 출시까지 하루, 실제 사례에서는 48시간 이내에 웹페이지를 만들 수 있게 되었다. ## 기존 웹사이트의 불일치와 유지보수 문제 - 페이지마다 디자이너와 개발자가 각자 새로운 해결책을 만들고 있었다. - 비슷하지만 조금씩 다른 컴포넌트가 반복되어 사용자 경험과 브랜드 인상이 일관되지 않았다. - 페이지를 수정하거나 업데이트하기 어렵고, 새로운 페이지를 만들 때마다 작업 방식이 달라졌다. - 제품 디자인 분야에서 활용되던 디자인 시스템의 장점을 마케팅·웹 디자인에도 적용할 필요가 있었다. ## 전체 요소를 조사하고 패턴을 통합 - 먼저 폰트, 글자 크기, 색상, 컬럼 너비, 레이아웃 등 기존 사이트의 시각 요소를 Figma 파일에 모았다. - 조사 과정에서 다음을 구분했다. - 여러 페이지에서 반복되는 패턴 - 한 번만 사용되어 스타일 가이드에 포함하기 어려운 예외 요소 - 서로 유사하지만 세부 스타일이 다른 요소 - 큰 UI 요소는 더 작은 단위로 분해해 조합 가능한 구조로 만들었다. - 서로 다른 제목 스타일 12개를 H1~H3, 본문, 기술 문서용 텍스트 등으로 단순화했다. - 블로그와 긴 형식의 콘텐츠에는 풀 쿼트, 블록 쿼트 같은 전용 텍스트 스타일도 추가했다. ## 원자적 요소와 유연한 컴포넌트 - 작은 요소를 조합해 다양한 페이지 구조를 만들 수 있도록 디자인 시스템을 구성했다. - 핵심 목표는 특정 페이지에만 맞는 고정된 디자인이 아니라, 여러 콘텐츠와 레이아웃에 대응하는 유연한 빌딩 블록을 만드는 것이었다. - 정리된 시각 언어를 공유 라이브러리로 제공해 Figma 브랜드에 익숙하지 않은 사람도 일관된 결과물을 만들 수 있게 했다. - 타이포그래피, 간격, 패딩, 행간, 색상, 그리드 등을 하나의 기준으로 통일했다. ## FLEGOs: 조합 가능한 대형 섹션 - Figma는 컴포넌트를 조합해 자주 함께 사용되는 요소와 완성된 섹션도 미리 만들었다. - 이러한 대형 조합 단위를 “Figma + LEGO”라는 의미의 **FLEGOs**라고 불렀다. - 디자이너는 개별 텍스트나 버튼뿐 아니라 페이지의 주요 섹션을 FLEGOs로 빠르게 구성할 수 있었다. - 작은 요소부터 완성된 섹션까지 단계적으로 재사용할 수 있어 페이지 제작의 속도와 일관성을 함께 확보했다. ## Contentful 기반의 제작 workflow - 약 한 달 동안 소규모 팀이 스타일 가이드와 컴포넌트 라이브러리를 구축했다. - 시스템은 Figma 파일에만 머무르지 않고 CMS인 Contentful에도 반영했다. - 디자인팀은 Figma에서 FLEGO를 사용해 와이어프레임을 만들고, 같은 파일에서 콘텐츠를 협업한 뒤 CMS의 컴포넌트로 실제 페이지를 구성했다. - 대부분의 핵심 마케팅 사이트가 이 프레임워크를 기반으로 제작되었다. - 새로운 페이지를 만들 때 별도의 코드 작성 없이 기존 컴포넌트를 활용할 수 있었다. ## 출시 속도 향상 - 디자인 시스템 도입 후 콘셉트에서 출시까지 하루 안에 진행할 수 있게 되었다. - ‘What’s New’ 페이지는 제품 마케터와 웹 제작자가 FLEGOs로 빠르게 와이어프레임을 만들고 콘텐츠를 작성한 사례다. - 아이디어에서 실제 웹페이지 공개까지 48시간 이내에 완료했다. - 재사용 가능한 시스템 덕분에 속도를 높이면서도 브랜드의 시각적 일관성을 유지할 수 있었다. 디자인 시스템은 제품 UI에만 필요한 도구가 아니라, 마케팅 페이지와 콘텐츠 제작에도 효과적이다. 기존 결과물을 먼저 조사하고, 반복 패턴을 통합한 뒤, 작은 요소부터 조합형 섹션까지 단계적으로 라이브러리화하면 개발 부담을 줄이면서 빠르고 일관된 웹사이트 운영이 가능하다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

디자인 시스템 현황

디자인 시스템은 아직 초기 단계지만, 반응형 디자인처럼 조직의 표준적인 업무 방식으로 자리 잡고 있다. 499명 설문 결과, 전담 팀이나 공개 문서를 갖춘 조직은 많지 않았지만 대부분은 더 성숙한 시스템을 원했다. 디자인 시스템은 단순한 컴포넌트 모음이 아니라 원칙·가이드·문서·운영 프로세스를 포함하는 지속적인 설계 방식이라는 것이 글의 핵심 결론이다. ## 1. 디자인 시스템은 아직 초기 단계 - 응답자의 약 3분의 2가 디자인 시스템의 초기 단계인 1~2단계에 해당했다. - 1단계: 시스템이 문서화되지 않음 - 2단계: 전담 팀이 없음 - 반면 86%는 전담 인력이 유지·관리하고 외부에도 공개된 3~4단계의 시스템을 원했다. - 브래드 프로스트의 아토믹 디자인과 2014년 구글 머티리얼 디자인 이후 관련 방법론이 확산됐지만, 많은 기업에서는 여전히 정착 과정에 있다. - 디자인 시스템은 일시적인 유행이 아니라 “조직이 일하는 방식”으로 자리 잡을 가능성이 높다고 평가된다. ## 2. 전담 팀이 없어도 시작할 수 있다 - 응답자의 절반은 디자인 시스템을 관리하는 전담 팀이 있는 회사에 근무했다. - 그러나 전담 팀이 반드시 필요하다고 생각한 사람은 약 3분의 1에 불과했다. - 특히 1인 디자이너나 소규모 팀도 시스템의 일부를 먼저 구축할 수 있다. - 전체 시스템을 한 번에 만들기보다 다음과 같이 작은 단위로 시작하는 접근이 권장된다. - 줄 간격(line height) 정의 - 색상과 타이포그래피 표준화 - 반복적으로 사용하는 버튼·입력창 등 컴포넌트 정리 - 중요한 것은 완벽한 시스템을 계획하는 것보다 작게 시작해 실제 제품에 적용하고 개선하는 것이다. ## 3. 디자인 시스템은 제품 이후에 만들어지는 경우가 많다 - 이상적으로는 제품 개발과 디자인 시스템 구축을 동시에 진행할 수 있지만, 실제로 그렇게 한 응답자는 41%였다. - 52%는 이미 존재하는 제품을 바탕으로 디자인 시스템을 만들었다. - 7%는 신규 제품과 기존 제품 모두를 지원하는 방식으로 구축했거나, 여러 회사에서 서로 다른 경험을 가진 경우였다. - 기존 제품에서 출발하면 실제 사용 사례와 문제를 기반으로 컴포넌트를 설계할 수 있다. - 처음부터 추상적인 컴포넌트를 무작정 만드는 것보다, 레거시 화면에서 반복되는 패턴을 찾아 체계화하는 방식이 현실적일 수 있다. ## 4. 컴포넌트 라이브러리와 스타일 가이드가 대표적인 산출물이다 - 디자인 시스템에 포함된 요소로 가장 많이 언급된 것은 다음과 같다. - 컴포넌트 라이브러리: 90% - 스타일 가이드: 83% - 디자인 원칙: 57% - 콘텐츠 가이드라인: 47% - 일부 응답자는 다음과 같은 코드 기반 요소도 디자인 시스템에 포함한다고 답했다. - React 컴포넌트 - 믹스인 라이브러리 - 디자인 토큰 저장소 - iOS·Android 개발 리소스 - 코드 관련 응답이 별도 선택지 없이 자유 응답으로 제시됐다는 점은 디자인 시스템의 범위가 시각 디자인을 넘어 개발 구현까지 확장되고 있음을 보여준다. - 당시 설문은 이러한 다양성을 충분히 측정하지 못했으며, 향후에는 더 폭넓은 항목이 필요하다고 지적한다. ## 5. 산출물만으로는 디자인 시스템이 될 수 없다 - 가장 큰 오해는 디자인 시스템을 정적인 패턴 라이브러리나 컴포넌트 모음으로만 보는 것이다. - 디자인 시스템은 다음을 포함하는 지속적인 프로세스에 가깝다. - 디자인 원칙 - 사용 지침 - 의사결정 기준 - 조직의 디자인 철학 - 산출물의 유지·개선 방식 - 컴포넌트 라이브러리와 스타일 가이드는 시스템의 결과물이자 살아 있는 산출물일 뿐, 시스템 전체와 동일하지 않다. - 문서화가 중요한 이유는 구성원들이 단순히 컴포넌트를 복사하는 데 그치지 않고, 언제·왜·어떻게 사용해야 하는지 이해해야 하기 때문이다. - 아무리 훌륭한 컴포넌트라도 올바른 문서와 사용 맥락이 없으면 실제 조직에서 제대로 활용되기 어렵다. 작은 반복 문제부터 실제 제품에 적용해 디자인 시스템을 시작하고, 컴포넌트뿐 아니라 원칙과 사용 지침까지 함께 문서화하는 것이 현실적인 접근이다. 전담 팀이 없더라도 점진적으로 운영 체계를 만들며 확장할 수 있다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

Figma에서 페이지를

Figma의 Pages는 하나의 파일 안에서 작업을 목적별로 나누어 정리하는 유연한 구조다. 글은 플랫폼, 기능, 디자인 단계, 원자적 디자인 방법론에 따라 Pages를 구성하는 네 가지 방식을 소개하며, 팀 규모와 프로젝트 특성에 맞는 체계를 선택하라고 제안한다. 적절히 나누면 협업, 프로토타이핑, 검색, 개발자 전달이 쉬워진다. ## Pages를 활용한 파일 구조화 - Figma 파일의 왼쪽 탭에 여러 Pages를 만들어 디자인을 분류할 수 있다. - 조직 방식에는 정답이 없으며 회사, 팀, 개인의 작업 방식에 따라 달라진다. - 디자인 파일을 무작정 한 곳에 쌓기보다 작업 목적에 맞게 구분하면 정리보다 디자인 자체에 집중할 수 있다. ## 플랫폼 또는 화면 크기별 구성 - Android, iOS, 데스크톱처럼 여러 플랫폼을 지원하는 제품에 적합하다. - 플랫폼별로 Page를 나누면 각 환경의 프레임 프리셋과 제약 조건을 적용하기 쉽다. - 각 Page에 독립적인 프로토타입을 구성할 수 있어 플랫폼별 사용자 테스트가 간편하다. - 반응형 디자인을 플랫폼별로 비교하고 관리하기에도 유리하다. ## 앱 기능별 구성 - 여러 디자이너가 다양한 기능을 동시에 개발하는 대규모 앱에 적합하다. - 프로필, 홈 화면 등 제품의 주요 기능을 각각 별도의 Page로 분리한다. - 담당 디자이너는 특정 기능에 집중하면서도 다른 Page를 참고해 전체 제품과의 일관성을 유지할 수 있다. - 기능별로 별도의 프로토타입을 만들어 특정 사용자 흐름만 독립적으로 테스트할 수 있다. ## 디자인 프로세스 단계별 구성 - 아이디어부터 최종 결과물까지 작업 진행 상태를 명확히 보여줄 수 있다. - 예를 들어 다음과 같이 Page를 구성할 수 있다. - 썸네일 → 와이어프레임 → 디자인 → 아카이브 - 문서·리서치 → 작업 중인 시안 → 리뷰 준비 - 사이트맵 → 와이어프레임 → 목업 → QA → 마케팅용 스크린샷 - `Done` Page에 완료된 디자인을 모으면 개발자는 실제로 구현해야 할 결과물을 쉽게 확인할 수 있다. - 초기 아이디어와 브레인스토밍을 별도 Page에 두면 완성도 높은 화면이 작업 중인 시안에 묻히지 않는다. - 팀이 복잡한 체계를 원하지 않는다면 단순히 “진행 중”과 “완료” 정도로 나누는 방식도 가능하다. ## Atomic Design 방법론에 따른 구성 - 디자인 시스템을 원자적 디자인 방식으로 운영할 때 적합하다. - 구성 요소의 계층에 따라 Page를 분리한다. - Atoms: 타이포그래피, 아이콘 등 기본 요소 - Molecules: 버튼 등 조합된 컴포넌트 - Organisms: 전체 페이지처럼 복잡한 구성 - Team Library에서 Page 이름을 기준으로 컴포넌트를 찾기 쉬워진다. - 레이어 이름에 컴포넌트 유형을 반복해서 넣지 않아도 된다. - 예: `button-selected`, `button-hovered` 대신 `selected`, `hovered`처럼 상태만 이름에 표시 - 결과적으로 레이어 패널이 단순해지고 컴포넌트 검색과 관리가 쉬워진다. 프로젝트의 핵심 기준을 먼저 정한 뒤 Pages를 구성하는 것이 좋다. 여러 플랫폼을 지원하면 플랫폼별로, 협업 규모가 크면 기능별로, 개발 전달이 중요하면 프로세스 단계별로 나누고, 디자인 시스템 중심이라면 Atomic Design 구조를 적용하면 된다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

Figma에서 아토믹 디자인 시스템

littleBits 팀은 약 6개월 안에 iOS·Android용 모바일·태블릿 앱 네 개를 출시해야 했고, 이를 위해 Figma에서 Atomic Design 기반의 디자인 시스템을 구축했다. 핵심은 재사용 빈도와 실제 개발 구조를 기준으로 원자·컴포넌트를 정의하고, 의미론적 색상과 텍스트 스타일을 조합해 유연성을 확보하는 것이었다. 결과적으로 Figma의 컴포넌트 구조가 React Native 컴포넌트와 자연스럽게 대응했고, 이후 반응형 레이아웃 템플릿으로 확장할 수 있는 기반이 마련됐다. ## 원자 수준의 디자인 토큰 - 텍스트 스타일과 색상은 Figma Styles로 정의했다. - 아이콘은 외부 아이콘 세트를 가져온 뒤 Figma 컴포넌트로 변환했다. - 색상 이름은 Bootstrap의 명명 방식을 참고하되, 테마 변경을 고려해 의미론적으로 지정했다. - 예: `bg-light`는 배경용 색상 - 예: `ui-dark`는 기본 전경 요소용 색상 - 기본 UI·그레이스케일 색상 외에 브랜드 색상, 배경, 오버레이, 외곽선용 색상 팔레트를 추가했다. - 색상값 자체보다 사용 목적을 이름에 반영하면 전체 디자인에서 색상을 일괄 수정하기 쉽고, 변경으로 인한 오류도 줄일 수 있다. ## 복잡한 계층 대신 ‘컴포넌트’로 단순화 - Atomic Design의 ‘분자’와 ‘유기체’가 여러 템플릿에서 반복 사용되는 경우가 많지 않다는 점을 발견했다. - 따라서 해당 계층을 세분화하지 않고 모두 `Components`로 통합했다. - 이 구조는 다음과 같은 React Native 컴포넌트 구조와도 잘 맞았다. - 카드 - 툴팁 - 버튼 - 기타 반복 UI 요소 - 이론적인 Atomic Design 분류보다 실제 재사용 패턴과 개발 구조에 맞춘 단순한 분류를 선택한 것이다. ## 스타일 조합으로 불필요한 컴포넌트 줄이기 - 텍스트 스타일과 색상 스와치를 자유롭게 조합할 수 있으므로, 색상·텍스트 스타일 조합마다 별도의 컴포넌트를 만들지 않았다. - 대신 스타일 가이드를 제공하고, 실제 템플릿에서 필요한 조합을 직접 적용했다. - 하나의 텍스트 상자 안에서도 여러 텍스트 스타일을 섞을 수 있게 해 가변적인 문구 길이에 대응했다. - Figma Styles 도입으로 컴포넌트 내부의 레이어 구조가 단순해졌고, 문서 사용성과 성능도 개선됐다. ## 버튼은 중첩 컴포넌트로 관리 - 버튼은 디자인에서 반복적으로 사용되고, 외곽선 등 중앙 관리가 어려운 속성을 포함하므로 별도의 중첩 컴포넌트로 만들었다. - 주요 버튼 유형을 다음과 같이 분리했다. - Primary - Secondary - Tertiary - 반복 사용될 가능성이 높은 특수 버튼도 별도 컴포넌트로 정의했다. - 모든 요소를 무조건 조합형 스타일로 처리하지 않고, 반복성과 관리 필요성이 높은 UI만 컴포넌트화한 것이 특징이다. ## 디자인 시스템과 개발 시스템의 연결 - Figma에서 정의한 컴포넌트 체계가 React Native에서 구현할 컴포넌트와 직접 대응하도록 설계됐다. - 디자인과 코드 사이의 구조적 차이를 줄여 협업과 구현을 쉽게 만들었다. - 완성된 컴포넌트 기반은 이후 모바일·태블릿 화면을 위한 반응형 레이아웃 템플릿 구축의 출발점이 됐다. 실무에서는 Atomic Design의 계층을 그대로 적용하기보다, 실제 재사용 빈도와 개발 컴포넌트 구조를 기준으로 단순화하는 것이 효과적이다. 색상과 텍스트는 의미론적 스타일로 관리하고, 반복성과 변경 가능성이 높은 요소만 컴포넌트로 만들면 유지보수성과 확장성을 함께 확보할 수 있다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

월풀을 담당하는 에이전

Aisle Rocket Studios(ARS)는 여러 사무실과 원격 인력으로 구성된 환경에서 분산된 디자인 파일과 협업 단절 문제를 Figma로 해결했다. Whirlpool 계정 팀은 Figma를 단일 작업 공간이자 협업의 기준점으로 삼아 기획·카피·디자인·개발·고객 검토를 브라우저 안에서 진행했고, 결과적으로 더 빠르고 창의적인 프로세스를 구축했다. 이 방식은 이후 ARS 전체의 표준 협업 방식으로 확산됐다. ## 분산된 팀의 파일 관리 문제 - ARS는 Whirlpool, Maytag, Sears 등 25개 이상의 브랜드를 담당하며 4개 사무실과 원격 인력으로 운영됐다. - Whirlpool 프로젝트에 긴급 투입된 크리에이티브 디렉터 Matt Carson은 Sketch, Photoshop 등 서로 다른 형식의 파일을 전달받았다. - 파일이 여러 도구와 장소에 흩어져 있어 중앙화된 작업 방식이나 일관된 프로세스가 없었다. - ARS는 디자이너와 개발자를 분리된 역할이 아니라, 서로 다른 기술을 가진 하나의 크리에이티브 팀으로 보려 했다. ## Figma를 단일 협업 공간으로 도입 - Whirlpool 계정 팀은 Figma를 새로운 ‘단일 정보 출처(source of truth)’로 정하고 기존 작업 도구와 워크플로를 빠르게 통합했다. - 실시간 멀티플레이어 기능을 이용해 서로 다른 시간대와 지역의 구성원이 같은 파일에서 동시에 작업했다. - 팀 내부 회의, 아이디어 구상, 피드백 수집, 프로토타입 공유까지 하나의 파일 안에서 진행했다. - 고객도 별도 로그인이나 개발 작업 없이 작동이 시뮬레이션된 디지털 콘셉트를 확인하고 공유할 수 있었다. - 에이전시와 고객이 실시간으로 수정 사항을 확인하면서 검토와 승인 과정이 짧아졌다. ## 협업이 창의성을 높이는 방식 - 작가, 디자이너, 개발자가 서로 다른 프로그램과 공간에서 작업하지 않고 동일한 환경에서 의견을 주고받게 됐다. - 아이디어를 함께 브레인스토밍하고 즉시 수정할 수 있어 반복 작업의 속도와 창의성이 향상됐다. - Figma는 단순한 디자인 제작 도구가 아니라 기획부터 검토까지 연결하는 협업 플랫폼으로 활용됐다. - ARS는 크리에이티브 프로세스의 80%를 브라우저에서 수행한다는 원칙을 실현할 수 있었다. ## 카피라이터와 개발자를 포함한 포용적 디자인 - 카피라이터는 완성된 디자인에 문구를 나중에 삽입하는 대신, 초기 디자인 단계부터 직접 카피를 수정하고 논의했다. - 카피가 디자인의 부수적인 요소가 아니라 독립적인 디자인 요소로 다뤄졌다. - 개발자는 정적인 디자인 파일을 전달받은 뒤 뒤늦게 문제를 발견하는 대신, 초기 단계부터 파일을 열람할 수 있었다. - 개발 가능성을 초기에 검토할 수 있어 디자인과 코드 사이의 반복적인 수정과 커뮤니케이션이 줄었다. - 역할별 참여 장벽이 낮아지면서 디자인 프로세스가 더 민주적이고 포괄적으로 바뀌었다. ## 소규모 팀에서 전사 표준으로 확산 - Whirlpool 팀은 도구를 통합하고 복잡한 업무 흐름과 파일을 중앙화하면서 더 빠르고 효율적으로 일했다. - 고객 측에서도 협업으로 시간과 비용을 절감하면서 창의성을 유지할 수 있었다. - 성과를 본 다른 ARS 구성원들이 이 방식을 도입하기 시작했고, Figma는 조직 전체의 표준으로 자리 잡았다. - ARS는 개방적인 협업 디자인을 기본 방식으로 삼고 전 디자인팀의 Figma 전환을 추진했다. ## 디자인 시스템으로의 확장 - Whirlpool 팀은 디지털 브랜드 전반의 일관성을 높이기 위해 디자인 시스템 구축을 다음 과제로 삼았다. - 원자적 디자인(Atomic Design) 원칙에 따라 기본 구성 요소를 Figma에서 규격화할 계획이다. - 완성된 요소는 팀 라이브러리에 저장해 브랜드 디자인의 단일 기준으로 활용하려 했다. - 이를 통해 프로젝트마다 디자인 요소를 새로 만들지 않고 재사용성과 일관성을 높일 수 있다. 분산된 팀이라면 파일 형식과 도구를 먼저 통합하고, 기획자·카피라이터·디자이너·개발자가 초기 단계부터 같은 작업 공간에서 협업하도록 구성하는 것이 효과적이다. 이후 반복적으로 사용하는 UI 요소를 디자인 시스템과 공유 라이브러리로 관리하면 협업 속도와 결과물의 일관성을 함께 높일 수 있다.

원문 읽기(새 탭에서 열림)
figma4분 읽기큐레이션 요약

Figma에서 디자인 시스템을 구축

Figma의 디자인 시스템은 팀의 규모나 목적에 따라 다양한 방식으로 구축할 수 있으며, 공통 컴포넌트와 라이브러리를 활용하면 디자인 일관성과 협업 효율을 높일 수 있다. 이 글은 Figma가 제공하는 기능과 실제 사용자 사례를 통해 디자인 시스템을 어디서 시작하고 어떻게 확장할지 보여준다. 핵심은 작은 단위에서 출발해 컴포넌트, 중첩 구조, 팀 라이브러리 등을 점진적으로 발전시키는 것이다. ## Figma가 디자인 시스템을 지원하는 방식 - Figma는 디자인 시스템을 구축하는 사용자를 지원하기 위해 **Constraints**, **Team Library**, **Components** 같은 기능을 발전시키고 있다. - 디자인 시스템은 단순한 UI 키트가 아니라 팀 내 디자이너, 개발자, 제품 관리자 간의 공통 언어로 활용될 수 있다. - Microsoft처럼 매우 복잡한 중첩 컴포넌트와 제약 조건을 활용하는 사례도 있으며, Figma는 사용자가 제품의 한계를 확장하는 다양한 방식을 공유하고자 했다. - 글에 소개된 사례들은 Figma가 비용을 지급하거나 후원한 콘텐츠가 아니라, 실제 사용자들이 작성한 경험 공유다. ## 작은 구성 요소부터 시작하기 — Gusto - Gusto는 급여·인사 관리 서비스를 제공하는 기업으로, 디자인 시스템을 처음 시작할 때의 막막함을 단순한 구성 요소로 해결했다. - 처음부터 완성된 시스템을 만들기보다, 재사용 가능한 기본 요소를 정의하는 방식으로 출발했다. - 디자인 시스템 구축의 첫 단계에서는 다음과 같은 작업이 유용하다. - 반복적으로 사용되는 UI 요소 찾기 - 기본 컴포넌트와 패턴 정리 - 프로젝트와 자산을 체계적으로 분류 - 팀이 실제로 자주 사용하는 요소부터 우선순위화 ## 마케팅·커뮤니케이션 자산 관리 — Square - Square의 마케팅 팀은 제품 UI뿐 아니라 커뮤니케이션 디자인을 위한 내부 디자인 시스템을 구축했다. - 시스템에는 다음과 같은 자산이 포함된다. - 색상 팔레트 - 로고 세트 - 마케팅 및 브랜드 관련 그래픽 자산 - 디자인 시스템을 제품 화면에만 한정하지 않고, 마케팅과 브랜드 업무에도 적용하면 여러 팀이 동일한 시각적 기준을 사용할 수 있다. - Figma 안에서 자산을 공유하면 최신 버전을 쉽게 찾고, 중복 제작이나 오래된 로고 사용을 줄일 수 있다. ## 비디자이너의 참여를 돕기 — Virta Health - Virta Health는 당뇨병 치료 서비스를 제공하는 기업으로, 디자인 시스템을 통해 디자이너가 아닌 구성원도 디자인 작업에 참여할 수 있도록 했다. - 구축 과정은 다음 단계로 진행됐다. - 기존 컴포넌트와 화면을 감사 - 반복되는 패턴과 문제점 파악 - 재사용 가능한 컴포넌트 제작 - 컴포넌트를 활용한 최종 목업 구성 - 비디자이너는 컴포넌트를 드래그 앤 드롭해 아이디어를 시각화할 수 있다. - 그 결과 엔지니어와 제품 관리자가 디자인 개념을 더 쉽게 이해하고, 아이디어를 논의하는 방식도 개선됐다. - 디자인 시스템은 제작 속도뿐 아니라 직군 간 커뮤니케이션을 개선하는 도구로도 기능한다. ## 중첩 컴포넌트로 유연성 높이기 — OpenText - OpenText는 중첩 컴포넌트를 사용해 더 강력하고 유연한 디자인 시스템을 구축했다. - 하나의 컴포넌트 안에 다른 컴포넌트를 조합하면 복잡한 UI 패턴도 일관되게 관리할 수 있다. - 대표적인 활용 예시는 다음과 같다. - 버튼 내부에 아이콘 컴포넌트 배치 - 버튼의 기본·호버·비활성 상태 구성 - 여러 요소를 조합한 복합 UI 패턴 제작 - 하위 컴포넌트를 수정하면 이를 사용하는 상위 컴포넌트에도 변경 사항을 반영할 수 있어 유지보수가 쉬워진다. - 다만 중첩 구조가 지나치게 복잡해지면 관리가 어려워질 수 있으므로, 컴포넌트의 책임과 조합 규칙을 명확히 해야 한다. ## 원자적 디자인 구조 적용하기 — SetProduct.com - SetProduct.com은 **Atomic Design** 원칙을 디자인 시스템의 기반으로 사용했다. - 디자인 요소를 작은 단위에서 큰 단위로 확장한다. - 원자: 텍스트, 아이콘, 색상 등 - 분자: 버튼처럼 여러 원자가 결합된 요소 - 유기체: 카드나 복합 UI 블록 - 템플릿·페이지: 여러 블록이 조합된 화면과 전체 레이아웃 - 이 접근 방식은 디자인 요소 간의 관계를 체계적으로 정리하고, 재사용성을 높이는 데 도움이 된다. - 작은 단위의 변경이 더 큰 화면에 일관되게 적용되므로, 대규모 UI를 관리하기에 적합하다. ## 실무 적용을 위한 접근법 - 처음부터 모든 화면과 컴포넌트를 표준화하려 하지 말고, 반복 사용 빈도가 높은 요소부터 시작한다. - 컴포넌트와 스타일을 팀 라이브러리로 공유해 모든 구성원이 동일한 자산을 사용하도록 한다. - 중첩 컴포넌트와 제약 조건은 반응형 화면과 복잡한 상태를 표현할 때 활용한다. - 디자인 시스템을 디자이너만의 도구로 만들지 말고 개발자와 제품 관리자도 쉽게 사용할 수 있게 구성한다. - 시스템을 한 번 완성하는 프로젝트로 보기보다, 실제 사용 데이터를 바탕으로 계속 개선하는 공용 기반으로 운영하는 것이 좋다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

Figma의 팀 라이

Figma의 Team Libraries는 여러 파일과 팀원이 동일한 컴포넌트를 공유하고 동기화하도록 해 디자인 시스템 구축을 돕는 기능이다. 기존처럼 파일마다 심볼을 복사해 수동으로 교체하는 방식의 불일치 문제를 해결하고, 컴포넌트를 게시·삽입·업데이트하는 흐름으로 단일 진실 공급원을 유지한다. 이를 통해 디자인 시스템을 더 빠르고 일관되게 확장할 수 있다. ## 기존 디자인 도구의 한계 - 전통적인 디자인 도구는 사진 편집, 일러스트 제작, 정적인 화면 구성에 초점을 맞췄다. - 실제 애플리케이션의 반응형 동작이나 플랫폼의 제약 조건을 충분히 표현하지 못했다. - 디자인 시스템을 하나의 마스터 파일에서 관리하더라도 컴포넌트를 다른 파일로 복사하면 서로 다른 버전이 된다. - 작은 변경도 여러 문서를 찾아 각 심볼과 오버라이드를 수동으로 수정해야 했다. - Facebook, Google, Airbnb 같은 기업은 이러한 한계를 보완하기 위해 자체 디자인 시스템 도구와 전담 인력을 구축했다. ## Figma가 제시한 기반 - Figma는 시각 디자인과 동적인 사용자 인터페이스 설계를 연결하는 것을 목표로 했다. - 벡터 편집, 시스템 동작에 대응하는 제약 조건, 재사용 가능한 동적 컴포넌트를 제공해 디자인 시스템의 기반을 마련했다. - Team Libraries를 통해 이 컴포넌트를 여러 파일과 팀원 사이에서 공유할 수 있게 했다. - 웹 기반 구조 덕분에 파일 간 동기화 지연이 거의 없고, 여러 기기와 플랫폼을 위한 레이아웃을 일관된 규칙으로 설계할 수 있다. ## 엔지니어링 원칙을 반영한 디자인 시스템 - React 같은 프레임워크처럼 애플리케이션을 명확히 정의된 작은 단위로 구성하는 방식을 디자인에도 적용했다. - 재사용 가능하고 유지보수하기 쉬운 구조는 제품 개발 주기 전체의 효율을 높인다. - 다만 프로그래밍 개념을 그대로 가져오기보다 디자이너가 쉽게 사용할 수 있도록 인터페이스와 작업 흐름을 단순화했다. ## 게시(Publish): 단일 진실 공급원 만들기 - 파일에서 컴포넌트를 선택하고 Inspector의 **Add to Library**를 눌러 라이브러리에 추가한다. - 여러 컴포넌트를 선택한 뒤 변경 사항을 검토하고 팀 라이브러리에 게시한다. - 라이브러리와 원본 파일을 분리해 디자인 시스템의 변경 권한을 통제할 수 있다. - 원본 파일에 편집 권한이 있는 사람만 소스 컴포넌트를 수정할 수 있다. - 원본 파일을 볼 수 있는 사람은 게시된 컴포넌트를 사용할 수 있지만 규칙 자체를 변경할 수는 없다. - 예를 들어 프로덕션 디자이너는 아이콘을, 브랜드 디자이너는 색상 문서를 관리하고 다른 팀원은 이를 재사용할 수 있다. ## 삽입(Insert): 여러 파일에서 컴포넌트 재사용 - 라이브러리에 게시된 컴포넌트는 원본 파일을 볼 권한이 있는 팀원에게 제공된다. - 각 파일의 툴바에서 컴포넌트 도구를 선택해 공유 컴포넌트를 삽입한다. - 컴포넌트 안에 다른 컴포넌트를 중첩할 수 있다. - 개별 요소로 모듈을 구성한 뒤, 이를 더 복잡한 화면과 사용자 흐름에서 재사용할 수 있다. - 깊게 중첩된 컴포넌트도 원본과 연결되므로 단일 진실 공급원을 예측 가능하게 유지할 수 있다. ## 업데이트(Update): 변경 사항의 동기화 - 브랜드 가이드나 UI 자산을 변경할 때 기존 컴포넌트를 수정하고 다시 게시한다. - 재게시 전 확인 단계를 거치며, 이전 버전과 무엇이 달라졌는지 시각적 diff로 확인할 수 있다. - 원본 파일에서 컴포넌트를 삭제한 뒤 게시하면 팀 라이브러리에서도 해당 컴포넌트가 사라진다. - 따라서 팀에는 현재 유효한 디자인 시스템 요소만 공유된다. - 공유 컴포넌트의 변경이 여러 탐색 작업에 영향을 줄 수 있으므로, 작업 손실을 막기 위한 추가 확인 절차를 둔다. ## 실용적인 결론 Team Libraries는 디자인 시스템을 복사본이 아니라 연결된 컴포넌트 구조로 관리하게 해준다. 팀에서는 원본 파일의 편집 권한을 제한하고, 색상·아이콘·버튼·복합 모듈을 라이브러리로 게시한 뒤 변경 사항을 검토하며 재게시하는 운영 방식을 마련하는 것이 좋다.

원문 읽기(새 탭에서 열림)