Figma

532 개의 포스트

figma4분 읽기큐레이션 요약

2025년 직장에

2025년 업무에서 중요한 것은 정답이나 규칙을 따르는 것이 아니라, 경험을 바탕으로 자신만의 원칙을 세우고 상황에 맞게 적용하는 것이다. 글은 디자인 영감, AI 자동화, 사용자 온보딩, 회의 운영, 꾸준한 실행에 관한 업계 리더들의 조언을 소개한다. 공통적으로 반복되는 메시지는 핵심 가치에 집중하고, 불필요한 마찰을 줄이며, 실제 성과와 사용자 가치로 이어지는 활동에 힘을 쏟으라는 것이다. ## 디자인 밖에서 영감 찾기 Ableton의 수석 디자이너 Pablo Sánchez는 창작의 출발점을 디자인 영역에만 한정하지 말라고 조언한다. - 감정, 기억, 과학적 발견, 자연 등 다양한 분야에서 영감을 얻는다. - 다른 영역을 참고하면 창작 과정이 더 확장적이고 예측하기 어려우며 개인적인 방향으로 발전한다. - 디자이너 자신이 먼저 매력을 느끼는 방식으로 설계해야 최종 결과물에도 열정이 전달된다. - Ableton의 Note 앱은 기존 MIDI 편집기나 음악 제작 앱의 관습 대신 브루탈리즘 건축의 미니멀한 표현을 참고했다. - 그 결과 음악을 즉각적으로 만들 수 있는 단순하고 직관적인 UX를 구현했다. ## 업무를 방해하는 일을 자동화하기 Meta, Reddit, Twitch, X 등에서 제품 업무를 담당했던 Peter Yang은 제품 관리자의 핵심 역할이 문서 자체를 만드는 데 있지 않다고 말한다. - OKR, 내부 문서, 제품 리뷰는 필요하지만 제품 관리자의 본질적인 책임은 고객을 공감하고 고객 가치를 전달하는 것이다. - 중간 산출물 작성에 실제 제품 개발만큼의 시간이 든다면 업무 방식을 재검토해야 한다. - 반복적인 작업은 다른 사람에게 위임하거나 AI로 자동화할 수 있다. - Peter Yang은 AI를 활용해 다음 업무를 처리한다. - 브레인스토밍 결과 종합 - 고객 피드백 요약 - 제품 요구사항 문서 정리 - 자동화의 목적은 업무를 줄이는 것 자체가 아니라, 고객 문제를 이해하고 중요한 의사결정을 내리는 데 더 많은 시간을 쓰는 것이다. ## 사용자가 빠르게 ‘마법의 순간’에 도달하게 하기 Snapchat Lens Studio의 Charmaine Lee는 처음부터 많은 튜토리얼과 도움말을 제공하기보다 사용자가 직접 만들기 시작하는 순간을 앞당겨야 한다고 강조한다. - 신규 사용자가 교육 과정을 모두 이수하는 것보다 도구를 실제로 사용하고 창작하는 것이 중요하다. - 사용자가 “아하”라고 느끼는 순간은 단순한 사용자를 창작자로 전환시키는 계기가 된다. - 좋은 온보딩은 사용자가 스스로 배울 수 있을 때까지 필요한 최소한의 발판만 제공한다. - Lens Studio 팀은 FigJam에서 사용자 여정을 시각화했다. - 앱 다운로드부터 첫 프로젝트 제출까지 19단계였던 과정을 4개의 핵심 마일스톤으로 줄였다. - 온보딩을 개선할 때는 기능과 설명을 추가하기보다 첫 번째 성공 경험까지의 단계를 줄이는 것이 효과적이다. ## 목적에 맞는 회의 유형 조합하기 Coda의 공동 창업자이자 CEO인 Shishir Mehrotra는 모든 회의를 같은 방식으로 운영해서는 안 된다고 설명한다. 회의는 목적에 따라 세 유형으로 나눌 수 있다. - **Cadence 회의** - 스탠드업, 정기 팀 회의, 프로젝트 동기화 회의 등이 해당한다. - 목표를 설정하고 실행한 뒤 결과를 돌아보는 일정한 리듬을 만든다. - 핵심 질문은 “설정한 목표대로 진행되고 있는가?”이다. - **Catalyst 회의** - 의사결정 회의, 제품 리뷰, 디자인 크리틱 등이 해당한다. - 방향을 바꾸고 진전을 만들어내는 데 목적이 있다. - 핵심 질문은 “논의한 질문에 대한 답을 얻었는가?”이다. - 지나치게 많으면 구성원의 피로와 소진을 유발할 수 있다. - **Context 회의** - 전사회의, 오프사이트, 오리엔테이션 등이 해당한다. - 정보와 통찰을 공유하고 팀 간 연결을 강화한다. - 핵심 질문은 “업무를 더 잘할 수 있는 맥락과 준비를 얻었는가?”이다. - 효과적인 조직은 세 가지 회의를 균형 있게 운영하며, 각 회의의 목적을 명확히 해야 한다. ## 어려워도 계속 전진하기 Design System University의 창립자 Dan Mall은 목표가 가치 있더라도 목표에 도달하는 과정은 지루하고 고통스러울 수 있다고 말한다. - 결과만 짧게 보여주는 영화 속 훈련 장면과 달리, 실제 성장은 반복적이고 긴 시간을 요구한다. - 지루한 과정을 견디려면 스스로 추진력을 만들어야 한다. - 큰 목표를 한 번에 해결하려 하기보다 작업의 각 부분을 시작해 진행감을 쌓는 방식이 도움이 된다. - 완벽한 동기나 이상적인 조건을 기다리기보다 작은 진전을 반복해 momentum을 유지해야 한다. 결국 2025년의 업무 방식은 더 많은 일을 하는 것이 아니라, 중요한 일에 집중하는 방향이어야 한다. 불필요한 문서와 절차는 자동화하고, 사용자의 첫 성공 경험을 앞당기며, 회의 목적을 구분하고, 디자인과 업무의 경계를 넘어 새로운 영감을 찾는 것이 실용적인 출발점이다.

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

교실에서 창의력을 자극

Figma의 글은 FigJam을 활용해 교실의 참여도와 협업을 높일 수 있는 27가지 활동을 소개한다. 활동은 학생 간 관계 형성, 언어·역사 학습, STEM 개념 시각화, 창의적 휴식, 공동 이해 점검의 다섯 영역으로 구성된다. 핵심은 스티키 노트·그리기·음성 녹음·사진 부스 등 FigJam의 상호작용 기능으로 모든 학생이 부담 없이 의견을 표현하도록 만드는 것이다. ## 교실 공동체 형성 - 새 학기나 팀 프로젝트 시작 전에 학생들이 서로를 알아갈 수 있는 활동을 제안한다. - **‘나를 소개합니다’** 활동에서는 스티키 노트, 스티커, 스케치로 관심사와 개성을 표현한다. - **‘All About Me’** 활동은 성격, 취미, 꿈, 좋아하는 과목 등을 공유하도록 한다. - **FigJam 보물찾기**에서는 “책 읽기를 좋아하는 사람”, “다른 주 출신인 사람”처럼 조건에 맞는 친구를 찾으며 새로운 관계를 만든다. - **가상 신발장 아이스브레이커**는 학생을 신발 이미지나 개성 있는 시각 요소로 표현하게 한다. - 이러한 활동은 단순한 자기소개보다 창의적인 표현과 공통 관심사 발견을 촉진하며, 긍정적인 교실 문화를 형성한다. ## 언어와 역사 수업을 생생하게 만들기 - FigJam의 넓은 캔버스를 활용해 문학 작품과 역사 주제를 공동으로 분석한다. - 학생들은 등장인물 간 관계를 시각화하고, 줄거리 전개를 추적하며, 작품의 주제와 의미를 함께 토론할 수 있다. - 독서 활동을 개인 과제에 그치지 않고 그룹별 발견과 토론의 과정으로 전환한다. - 역사 수업에서는 여러 역사적 관점이나 해석을 한 화면에 배치해 비교·토론할 수 있다. - 글에서 소개하는 **‘Book chats’** 템플릿처럼 독서 대화 구조를 시각화하면 학생들이 작품에 대한 생각을 공유하고 서로의 해석을 발전시키기 쉽다. ## STEM 개념 시각화 - 수학·과학 등 STEM 과목의 개념을 도식, 메모, 그림으로 표현하는 활동을 제공한다. - 추상적인 문제나 복잡한 관계를 시각적으로 정리해 학생들이 풀이 과정과 사고방식을 공유하도록 돕는다. - 공동 캔버스에서 문제를 해결하면 정답뿐 아니라 접근 방법, 질문, 오류까지 함께 검토할 수 있다. ## 창의적인 두뇌 휴식 - 수업 중간에 짧은 창작 활동을 넣어 집중력을 회복하고 학생들의 긴장을 완화한다. - 그림 그리기, 자유로운 아이디어 발상, 시각적 표현처럼 학습 주제와 직접 관련이 없어도 참여할 수 있는 활동을 활용한다. - 짧고 부담 없는 활동으로 학생들이 자연스럽게 창의성을 발휘하고 다시 수업에 집중하게 한다. ## 함께 이해도 점검하기 - 수업이 끝난 뒤 학생들이 배운 내용과 궁금한 점을 공동으로 정리하도록 한다. - 모든 학생이 동시에 의견을 남길 수 있어, 말하기에 소극적인 학생의 이해도도 확인할 수 있다. - 교사는 학생들의 응답을 바탕으로 오개념이나 추가 설명이 필요한 부분을 빠르게 파악할 수 있다. - 개인 평가가 아니라 서로의 생각을 확인하고 학습 내용을 함께 정리하는 과정으로 활용할 수 있다. ## 활용을 위한 제안 FigJam 활동은 특정 과목에 고정되지 않고 질문과 템플릿만 바꾸어 다양한 수업에 적용할 수 있다. 처음에는 자기소개나 간단한 이해도 점검처럼 참여 장벽이 낮은 활동부터 시작하고, 이후 문학 분석·문제 해결·그룹 프로젝트로 확장하는 것이 실용적이다.

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

요금제, 시트 및 결

Figma는 2025년 3월 11일부터 가격, 좌석 유형, 결제 승인 방식을 전면 개편한다. Figma Design의 Full 좌석 가격은 인상되며, 모든 유료 좌석에는 FigJam과 Figma Slides 이용 권한이 포함된다. 또한 사용자가 임의로 유료 좌석을 늘리던 방식에서 벗어나, 관리자가 사전에 좌석 추가를 승인하는 구조로 변경된다. ## 가격 및 좌석 체계 개편 - 기존 요금제는 **Full, Dev, Collab, View** 좌석 체계로 이전된다. - **Figma Design의 가격이 인상**되며, 특히 Full 좌석 가격이 변경된다. - 모든 유료 좌석에서 **FigJam과 Figma Slides**를 사용할 수 있게 된다. - 무료 **Starter 플랜은 계속 제공**된다. - 구체적인 가격은 Professional, Organization, Enterprise 등 요금제별 표로 제시되며, 금액은 미국 달러 기준이다. ## 관리자 중심의 좌석 승인 방식 - 기존에는 사용자의 행동으로 좌석이 자동 업그레이드되고, 관리자가 이후 청구 전에 검토했다. - 새 모델에서는 추가 비용이 발생하는 좌석 요청을 **관리자가 사전에 승인**해야 한다. - 관리자는 제품별로 여러 좌석을 관리하는 대신, 사용자당 **하나의 좌석만 관리**하면 된다. - 이를 통해 예상하지 못한 좌석 증가와 청구를 줄이고, 관리자가 비용을 더 명확하게 통제할 수 있다. ## 3일간의 임시 사용 권한 - 관리자가 요청을 검토하는 동안 사용자가 협업을 중단하지 않도록, 요청한 좌석의 기능을 **최대 3일간 임시로 사용할 수 있다**. - 임시 기간에는: - 새 파일을 생성할 수 있다. - 팀원이 편집 권한을 부여한 파일을 수정할 수 있다. - 관리자가 승인한 좌석은 다음 청구서에 반영된다. - 좌석 비용은 승인일부터 구독 기간 종료일까지 **일할 계산(proration)** 된다. - 이 변경 사항은 모든 유료 플랜에 적용된다. ## 변경 적용 일정 - **2025년 3월 11일**부터 기존 플랜이 새 좌석 유형과 승인 흐름으로 이전된다. - Full 좌석 가격 인상과 새로운 일할 계산 방식은 **3월 11일 이후 첫 갱신 시점**부터 적용된다. - 기존 고객에게는 이메일로 개인별 변경 내용이 안내된다. ## Connected Projects와 향후 계획 - 이번 결제 모델 개편은 2025년 후반 출시 예정인 **Connected Projects**의 기반이 된다. - 프리랜서와 에이전시는 현재 고객과 협업하기 위해 여러 플랜에서 라이선스를 구매해야 하는 경우가 있었다. - Connected Projects에서는 기존 Figma 좌석을 활용해 고객과 파일을 생성하고 공동 편집할 수 있게 된다. - 이를 통해 외부 협업을 위해 여러 라이선스를 중복 구매해야 하는 문제가 줄어들 전망이다. 실무적으로는 조직 관리자가 2025년 3월 11일 전후의 요금과 좌석 매핑을 확인하고, 좌석 승인 담당자와 내부 승인 절차를 미리 정해두는 것이 좋다. 특히 자동 좌석 증가에 의존하던 팀은 사용자의 요청이 승인되지 않을 경우를 고려해 검토 기준과 대응 시간을 마련해야 한다.

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

요점 정리: 제

피그마의 2024년 업데이트는 사용자 커뮤니티와의 상호작용을 바탕으로 제품과 브랜드를 함께 확장한 과정이었다. 180개의 신규 릴리스, 1만 명이 참석한 Config, 전 세계 220개 이상의 Friends of Figma 그룹을 통해 피그마는 디자인뿐 아니라 개발·마케팅·제품팀 전체를 위한 도구로 영역을 넓혔다. 글은 주요 제품 출시와 브랜드 개편, 커뮤니티 콘텐츠를 되돌아보며 “피그마가 만들고 사용자가 완성한다”는 메시지를 강조한다. ## 제품 기능과 워크플로 확장 - UI3를 개선해 사용자가 인터페이스를 더 세밀하게 제어할 수 있도록 했다. - AI 도구를 재정비해 기능을 무작정 늘리기보다 의도와 활용성을 중심으로 발전시켰다. - Dev Mode를 강화해 디자인과 코드 사이의 연결을 원활하게 만들었다. - 프레젠테이션 제작 도구인 Figma Slides를 출시해 디자인 결과물을 발표하고 공유하는 단계까지 지원했다. - 2024년에는 대규모 기능 출시뿐 아니라 사용성을 높이는 작은 업데이트까지 총 180개의 릴리스를 진행했다. ## Config를 통한 커뮤니티 확장 - 2024년 Config에는 1만 명 이상이 샌프란시스코에 모여 제품 개발의 미래를 논의했다. - 피그마는 Config 2025의 얼리버드 티켓을 소개하며 행사를 지속적으로 확대하고 있다. - 발표자들의 강연에서 영감을 얻는 방법과 기억에 남는 세션을 만드는 방식을 공유했다. - 전 세계 220개 이상의 Friends of Figma 그룹이 커뮤니티 기반 학습과 교류를 뒷받침했다. ## 새로운 도구에 맞춘 브랜드 개편 - 개발자, 마케터, 제품팀 등 더 넓은 사용자를 지원하게 되면서 브랜드 정체성도 함께 개편했다. - 새로운 시각적 아이덴티티와 서체를 도입했다. - 피그마 자체 도구를 사용해 웹 시스템을 재설계했다. - 컴포넌트를 점검하고 정리해 일관성을 높였으며, 변수·색상·타이포그래피 스타일을 활용해 향후 확장 가능한 디자인 시스템을 구축했다. - 웹 제작 워크플로를 간소화하고 팀 간 협업 효율을 높이는 데 초점을 맞췄다. ## 커뮤니티가 만든 활용 방식 - Figma Slides에서는 커뮤니티 템플릿을 활용해 발표의 완성도와 표현력을 높이는 사례를 소개했다. - Ableton Note 앱 디자이너 Pablo Sánchez는 예상 밖의 경험을 만드는 7가지 디자인 원칙을 공유했다. - 핵심은 사용자를 놀라게 하는 요소를 설계하기 전에 디자이너 스스로 작업 과정에서 즐거움과 호기심을 느끼는 것이다. - One North의 Nick Villapiano는 개발자도 디자인 과정에 적극 참여해야 한다고 주장했다. - Dev Mode를 단순한 개발 전달 도구가 아니라 개발자가 디자인 의사결정에 기여하는 협업 공간으로 바라본다. ## 사용자 피드백을 통한 제품 발전 - 피그마의 업데이트는 커뮤니티의 작업 방식과 제작 결과물에 대한 관찰에서 출발한다. - 새로운 기능은 출시 자체보다 사용자가 실제 프로젝트에서 어떻게 활용하고 변형하는지가 중요하다고 설명한다. - 제품, 행사, 브랜드 시스템, 교육 콘텐츠를 함께 발전시키며 피그마 생태계를 확장하는 전략을 보여준다. 피그마를 사용하는 팀이라면 2024년 기능을 단순히 추가된 도구로 보기보다, UI3·AI·Dev Mode·Slides를 현재 협업 프로세스에 어떻게 연결할지 점검하는 것이 유용하다. 특히 개발자를 초기 디자인 논의에 참여시키고, 디자인 시스템을 실제 제품과 웹 경험에 일관되게 적용하는 방식이 실질적인 개선으로 이어질 수 있다.

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

피그마 2024 (새 탭에서 열림)

2024년 피그마(Figma)는 전 세계 커뮤니티의 피드백을 바탕으로 180회 이상의 업데이트를 진행하며 디자인 도구를 넘어 협업 플랫폼으로서의 완성도를 높였습니다. UI3로 불리는 대대적인 인터페이스 개편부터 AI를 활용한 워크플로우 효율화, 그리고 새로운 프레젠테이션 도구인 '피그마 슬라이즈(Figma Slides)' 도입까지, 사용자의 제작 과정을 더 빠르고 정교하게 만드는 데 집중했습니다. 결과적으로 피그마는 단순히 화면을 그리는 도구에서 아이디어 구상부터 개발 전달까지 전 과정을 아우르는 에코시스템으로 진화했습니다. **사용자 피드백으로 완성된 UI3와 인터페이스 혁신** * 2019년 이후 가장 큰 규모의 디자인 개편인 UI3를 출시했으며, 베타 기간 중 접수된 피드백을 반영해 플로팅 패널 대신 고정 및 크기 조절이 가능한 패널 시스템으로 최종 조정했습니다. * 디자인 캔버스의 공간 확보를 위해 레이어 패널을 숨길 수 있게 개선하고, 타이포그래피 및 아이콘 시스템을 현대적으로 일신했습니다. * 스포이드 도구를 개선하여 스타일과 변수(Variables)를 쉽게 재사용하고 여러 컬러 포맷을 탭으로 전환하며 빠르게 관리할 수 있도록 했습니다. **핵심 기능 고도화 및 성능 최적화** * **멀티 에디트(Multi-edit):** 여러 프레임에 걸친 디자인 요소를 한 번에 편집할 수 있는 기능을 도입하여 반복 작업 시간을 획기적으로 단축했습니다. * **고급 타이포그래피:** 텍스트 스타일 내에서 기울임꼴, 굵게, 밑줄 등을 개별적으로 재정의(Override)할 수 있으며, 단일 텍스트 노드 내에서 혼합 단락 간격을 설정할 수 있습니다. * **성능 향상:** 대규모 파일을 효율적으로 관리하기 위해 동적 페이지 로딩(Dynamic page loading)과 메모리 최적화 시스템을 도입했으며, 유럽 지역 로컬 파일 호스팅을 통해 인프라 안정성을 강화했습니다. * **오토 레이아웃 제안:** 복잡한 디자인을 반응형으로 더 쉽게 변환할 수 있도록 오토 레이아웃 추천 기능을 강화했습니다. **워크플로우의 마찰을 줄이는 AI 기능** * **비주얼 및 에셋 검색:** 이미지 업로드나 영역 선택을 통해 필요한 컴포넌트를 찾고, 이름이 일치하지 않아도 맥락에 맞는 에셋을 찾아주는 AI 검색 기능을 도입했습니다. * **콘텐츠 생성 및 편집:** 더미 데이터를 채워주는 텍스트 생성, 다국어 번역, 이미지 배경 제거 기능을 캔버스 내에서 즉시 실행할 수 있습니다. * **First Draft:** 기존의 'Make Designs'를 개선한 기능으로, 아이디어를 시각화하는 첫 단계에서 디자인 초안을 빠르게 생성하여 디자이너의 초기 탐색 과정을 돕습니다. * **레이어 정리:** AI가 레이어 이름을 자동으로 정리해주는 기능을 통해 파일 관리의 번거로움을 줄였습니다. **협업의 확장: 개발 생산성과 프레젠테이션** * **데브 모드(Dev Mode):** 코드 커넥트(Code Connect)를 통해 디자인 시스템의 컴포넌트를 실제 코드와 연결하여 개발자가 문맥 전환 없이 디자인을 구현할 수 있도록 지원합니다. * **피그마 슬라이즈(Figma Slides):** 디자인과 프레젠테이션의 경계를 허물어, 피그마의 정교한 디자인 툴을 그대로 활용하면서 고품질의 발표 자료를 제작하고 공유할 수 있게 했습니다. 실무 디자이너와 팀은 새롭게 도입된 AI 기반 검색과 레이어 정리 기능을 활용해 관리 리소스를 줄이고, 코드 커넥트를 도입해 개발자와의 협업 효율을 극대화하는 것을 권장합니다. 특히 UI3의 변경된 패널 시스템에 익숙해진다면 더 넓은 작업 영역에서 창의적인 업무에 몰입할 수 있을 것입니다.

figma4분 읽기큐레이션 요약

피그마 패턴 라이브

UI3 개편은 Figma 내부 디자인 시스템이 오랜 성장 과정에서 파편화되었다는 문제를 드러냈고, 이를 해결하기 위해 Figma Pattern Library(FPL)를 처음부터 다시 구축하게 만들었습니다. 디자이너와 엔지니어가 페어 프로그래밍에 가까운 방식으로 협업해 디자인 의도와 코드 구현을 연결하고, 변수·REST API·테마 모드를 기반으로 일관되고 접근성 높은 제품 개발의 기반을 마련했습니다. FPL은 단순한 컴포넌트 모음이 아니라 조직 전체의 공통 언어이자 UI3를 확장하기 위한 단일 진실 공급원으로 설계되었습니다. ## UI3가 드러낸 내부 디자인 시스템의 문제 - Figma는 다른 팀의 디자인 시스템 구축을 돕는 제품을 만들고 있었지만, 내부 시스템은 오랜 기간의 급속한 성장과 제품 확장으로 분리되어 있었습니다. - 동일해야 할 컴포넌트가 서로 조금씩 달랐고, 연결이 끊긴 컴포넌트 인스턴스가 누적되었습니다. - UI3를 모든 Figma 제품에 적용하려면 새로운 화면 디자인만으로는 부족했습니다. - 여러 팀이 일관되고 효율적으로 작업할 수 있는 견고한 기반 시스템이 필요했습니다. ## 디자이너와 엔지니어의 페어 협업 - Wayne Sun과 Tom Williams는 디자이너와 엔지니어로 구성된 5명의 소규모 팀을 만들었습니다. - 개발에서 한 사람이 코드를 작성하고 다른 사람이 실시간 검토하는 페어 프로그래밍처럼, 디자이너와 엔지니어가 긴밀하게 짝을 이루어 작업했습니다. - 디자이너는 시각적·사용자 경험 의도를 전달하고, 엔지니어는 이를 실제 컴포넌트와 토큰 시스템으로 구현했습니다. - 이 방식은 디자인 파일과 제품 코드 사이의 간극을 줄이고, 양쪽이 공유할 수 있는 시스템 언어를 만드는 데 목적이 있었습니다. - 그 결과 새로운 내부 디자인 시스템인 Figma Pattern Library(FPL)가 탄생했습니다. ## 스타일과 스프레드시트에서 변수 중심 구조로 전환 - 기존 시스템은 Figma의 변수 기능이 등장하기 전에 만들어졌습니다. - 디자이너는 Figma 스타일을 사용했지만, 엔지니어는 별도의 Google Sheets에서 색상 토큰을 관리했습니다. - 스프레드시트가 제품 변경 사항을 즉시 반영하지 못하면서 디자인 파일과 실제 코드의 색상이 달라지는 문제가 발생했습니다. - 팀은 Figma 변수와 REST API를 활용해 디자인과 코드가 자동으로 동기화될 수 있는 구조를 만들었습니다. - 타이포그래피 변수를 새로 만들고, 기존 타이포그래피 스타일이 이 변수들을 별칭으로 참조하도록 구성했습니다. - 색상 스타일은 중앙 관리가 가능한 색상 변수로 마이그레이션했습니다. - 색상 변수에 CSS 정의도 추가해 Dev Mode의 검사 패널에서 개발자가 올바른 변수명과 코드 표현을 확인할 수 있게 했습니다. ## Primitive와 Semantic 변수로 색상 체계 정리 - 색상은 밝기와 어두움이 체계적으로 이어지는 **color ramp**를 기반으로 구성했습니다. - 기본 색상 단위인 **Primitive 변수**는 색상 계열별로 정리하고, 100부터 1000까지 단계적으로 구분했습니다. - 실제 UI 용도를 나타내는 **Semantic 변수**는 Primitive 변수를 별칭으로 참조합니다. - 예를 들어 특정 색상값을 직접 사용하는 대신 배경, 텍스트, 테두리 같은 의미 기반 변수로 연결할 수 있습니다. - Semantic 변수는 다음과 같은 테마와 제품별 모드를 지원하도록 설계되었습니다. - 라이트 모드와 다크 모드 - Figma Design - FigJam - Slides - Dev Mode - 이 구조 덕분에 하나의 공통 컴포넌트가 제품이나 테마에 따라 색상만 자연스럽게 바꿀 수 있습니다. - Primitive 변수의 값을 수정하면 이를 참조하는 Semantic 변수와 컴포넌트에 변경 사항을 일괄 적용할 수 있습니다. ## FPL의 역할 - FPL은 UI3의 시각적 스타일을 정의하는 동시에, 이를 실제 제품에 일관되게 구현하기 위한 기술적 기반입니다. - 디자인과 엔지니어링을 분리된 단계로 처리하지 않고, 초기 설계부터 함께 검증하는 협업 모델을 채택했습니다. - 변수와 모드 기반의 구조는 여러 제품과 테마를 지원하면서도 공통된 사용자 경험을 유지하도록 돕습니다. - 중앙화된 토큰과 컴포넌트는 중복 구현과 미세한 시각적 차이를 줄이고, 향후 변경 사항을 더 빠르게 확산시킬 수 있습니다. FPL 사례는 디자인 시스템을 단순한 UI 컴포넌트 저장소가 아니라 디자인 토큰, 테마, 코드 연동, 협업 방식까지 포함하는 조직의 공통 인프라로 다뤄야 한다는 점을 보여줍니다. 특히 디자인 파일과 코드가 서로 다른 토큰을 관리하지 않도록 변수와 자동 동기화를 도입하는 것이 규모가 큰 제품 조직에 실용적인 출발점입니다.

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

개발자가 디자인에 적극적으로 참여

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의 읽기 전용 탐색, 버전 비교, 코드 연결 기능이 각각 어떤 문제를 해결하는지 사례로 제시한다. - 디자인 시스템 개편이나 원격·하이브리드 협업처럼 여러 직군의 긴밀한 조율이 필요한 프로젝트에서 먼저 적용한다. - 도구 도입 자체보다 디자이너와 개발자가 공유할 수 있는 언어와 작업 방식을 만드는 데 초점을 둔다.

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

잊지 못할 Config 발표를 준비

인상적인 컨퍼런스 발표는 정보를 전달하는 데 그치지 않고, 청중의 통념을 뒤집으며 오래 기억될 관점과 이야기를 제공해야 한다. Figma의 Config 발표 사례들은 위험을 감수한 선택, 사용자에 대한 깊은 관심, 단순하고 창의적인 문제 해결이 훌륭한 발표와 제품을 만든다는 점을 보여준다. 특히 발표자는 성공 결과보다 그 과정에서의 의외의 판단과 배움을 설득력 있게 전달해야 한다. ## 발표의 목적: 정보 전달을 넘어 기억에 남는 경험 만들기 - 좋은 발표는 단순히 지식을 나열하지 않고 청중의 기존 가정에 도전한다. - 발표 주제뿐 아니라 발표자가 어떤 문제를 발견했고, 어떤 선택을 했으며, 무엇을 배웠는지가 중요한 콘텐츠가 된다. - 글은 Config 2024 발표자들이 인상 깊게 본 세션을 소개하며, 향후 발표 제안서를 준비하는 사람에게 하나의 기준을 제시한다. - 발표의 영감은 제품 디자인, 공간 컴퓨팅, 새로운 하드웨어 등 다양한 분야에서 얻을 수 있지만, 공통적으로 강한 서사와 분명한 관점이 존재한다. ## 통념을 거스른 위험한 선택 - Josh Wardle의 발표 **“Opting for the opposite”**는 일반적인 게임 업계의 성공 공식과 반대되는 선택을 다룬다. - Wordle은 다음과 같은 방식으로 성장과 참여를 극대화하는 관행을 따르지 않았다. - 하루에 한 번만 플레이할 수 있도록 제한 - 공유된 결과에서 게임으로 바로 연결되는 링크를 제공하지 않음 - 모바일 게임처럼 반복 사용과 바이럴 확산을 적극적으로 유도하지 않음 - Wardle은 처음부터 바이럴 히트작을 만들려 한 것이 아니라, 파트너를 위한 애정 어린 선물로 게임을 제작했다. - 이 사례의 핵심은 “성공하려면 반드시 업계의 모범 사례를 따라야 한다”는 생각을 뒤집은 데 있다. - 발표에서 위험을 감수한 선택을 보여주려면 단순히 결과를 자랑하기보다 다음을 설명해야 한다. - 당시 업계의 일반적인 접근법은 무엇이었는가 - 왜 그 반대의 선택을 했는가 - 그 선택이 사용자 경험에 어떤 영향을 미쳤는가 - 예상하지 못한 결과와 배움은 무엇이었는가 ## 지표보다 사용자를 우선한 제품 철학 - Apple의 디자인 에반젤리스트 Linda Dong은 Wordle 사례가 “많은 사람이 사랑하는 제품을 만들기 위해 항상 관습을 따를 필요는 없다”는 점을 상기시킨다고 평가한다. - 수치와 성장 지표가 중심이 된 산업에서도 단순함과 창의성만으로 강력한 제품을 만들 수 있다. - Humane의 리드 프로덕트 디자이너 George Kedenburg III 역시 Wordle의 과정이 “틀린 방식”처럼 보이는 선택을 통해 훌륭한 결과를 만든 이야기라고 강조한다. - 중요한 것은 규칙을 어기는 행위 자체가 아니라, 만들고자 하는 사용자를 깊이 이해하고 그 사용자에게 필요한 경험을 끝까지 고민하는 태도다. ## 구체적인 사례와 시각적·서사적 구성 - Linda Dong과 Mike Stern의 **“An Infinite Canvas”**는 공간 컴퓨팅 디자인의 가능성을 다룬다. - George Kedenburg III와 Humane 공동창업자 Imran Chaudhri의 발표는 Ai Pin의 개발 과정과 제품 비전을 소개한다. - 발표 주제가 복잡하거나 미래지향적일수록 다음 요소가 이해를 돕는다. - 제품이 해결하려는 사용자 문제 - 개발 과정에서의 핵심 결정 - 기술이 사용자 경험을 어떻게 바꾸는지 보여주는 실제 사례 - 아름답거나 유머러스한 시각 자료 - 청중의 기억에 남는 발표는 새로운 기술을 설명하는 데서 끝나지 않고, 그 기술이 왜 필요한지와 어떤 인간적 동기에서 출발했는지까지 전달한다. ## 실용적인 발표 준비 방법 - 업계의 정답을 그대로 따르기보다, 자신이 의도적으로 다르게 선택한 지점을 찾는다. - 성공한 결과보다 실패, 망설임, 예상 밖의 전환점을 이야기의 중심에 둔다. - “무엇을 만들었는가”뿐 아니라 “누구를 위해 만들었고 왜 그렇게 만들었는가”를 설명한다. - 데이터와 성과 지표는 보조 자료로 활용하고, 사용자의 실제 경험과 제작자의 판단을 중심에 둔다. - 발표를 준비할 때 다음 질문을 점검하면 좋다. - 청중의 기존 생각을 바꿀 만한 지점이 있는가? - 나만 들려줄 수 있는 구체적인 제작 경험이 있는가? - 발표가 끝난 뒤 청중이 기억할 한 문장은 무엇인가? - 제품이나 프로젝트에 담긴 사용자에 대한 관심이 드러나는가? 결국 인상적인 발표는 완벽한 성공 공식을 제시하는 자리가 아니라, 사용자에 대한 진정성 있는 관심과 과감한 선택이 어떻게 결과로 이어졌는지를 보여주는 자리다. 발표를 준비한다면 자신의 프로젝트에서 가장 의외였던 결정과 그 이유를 중심으로 이야기를 구성하는 것이 효과적이다.

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

새로운 시대를 위한 웹

Figma는 2024년 브랜드 리프레시를 계기로 figma.com의 웹 디자인 시스템을 전면 점검했다. 기존 시스템은 유사한 컴포넌트가 지나치게 많고, 색상과 타이포그래피가 확장된 브랜드와 다양한 콘텐츠를 충분히 지원하지 못했다. 사용 현황을 데이터로 분석해 컴포넌트를 단순화하고, 일관된 디자인 원칙과 재사용 가능한 템플릿을 마련함으로써 더 유연하고 미래 지향적인 웹 시스템을 구축했다. ## 브랜드와 웹 시스템을 함께 재정비한 배경 - 2020년의 figma.com은 새로운 디자인 도구를 소개하는 데 초점이 맞춰져 있었다. - 2024년의 Figma는 여러 제품 팀을 위한 플랫폼으로 확장되었고, 웹사이트 역시 제품 생태계와 다양한 사용자 요구를 보여줘야 했다. - 기존 시스템에는 다음과 같은 문제가 있었다. - 서로 조금씩만 다른 컴포넌트가 많아 적절한 컴포넌트를 선택하기 어려움 - 변화하는 브랜드 색상 팔레트를 수용할 만큼 색상 체계가 유연하지 않음 - 다양한 콘텐츠 유형을 지원하기에 타이포그래피 체계가 충분히 최적화되지 않음 - Figma Sans와 새로운 색상·일러스트레이션 스타일을 도입한 브랜드 리프레시는 웹 디자인 시스템을 재설계하는 계기가 되었다. ## 컴포넌트 사용 현황을 데이터로 감사 - Web Experience 팀은 스크립트를 작성해 컴포넌트가 다음과 같이 어떻게 사용되는지 분석했다. - 어떤 컴포넌트가 사용되는가 - 각 컴포넌트가 얼마나 자주 사용되는가 - 어떤 페이지에서 사용되는가 - 이 분석을 통해 실제 사용량과 필요성을 기준으로 컴포넌트 구조를 단순화할 수 있었다. - 디자인 시스템을 직관이나 선호만으로 관리하지 않고, 실제 페이지와 팀의 사용 패턴을 근거로 개선한 점이 핵심이다. ## Flex 컴포넌트의 48개 변형을 24개로 축소 - 가장 널리 사용되던 기본 구성 요소인 ‘Flex’ 컴포넌트는 옵션이 추가되면서 48개 변형까지 늘어나 있었다. - 사용 사례를 조사한 결과, 기능을 유지하면서도 변형 수를 24개로 줄일 수 있었다. - 중복되거나 활용도가 낮은 선택지를 제거해 속성 패널을 더 집중된 형태로 만들었다. - 예를 들어 가운데 정렬 텍스트 옵션을 없애고, 웹 시스템 전체에서 왼쪽 정렬을 기본값으로 정했다. - 그 결과: - 디자이너와 콘텐츠 제작자가 선택해야 할 옵션이 줄어듦 - 컴포넌트 사용법이 쉬워짐 - 웹페이지 전반의 시각적 일관성이 높아짐 - 새로운 브랜드 언어와도 더 잘 맞게 됨 ## 템플릿과 조합 가능한 빌딩 블록 - 단순히 기존 컴포넌트를 줄이는 데 그치지 않고, 자주 쓰는 페이지 레이아웃을 템플릿으로 만들었다. - 여러 방식으로 조합할 수 있는 “building block” 컴포넌트 세트도 구축했다. - 이를 통해 팀은: - 일반적인 페이지 구조를 더 빠르게 만들고 - 필요한 구성 요소를 조합해 다양한 페이지를 제작하며 - 별도의 커스텀 작업 없이도 Figma 브랜드에 맞는 결과물을 만들 수 있게 되었다. - 컴포넌트 선택지를 무작정 늘리는 대신, 검증된 핵심 요소와 조합 방식을 제공하는 접근이다. ## 실용적인 시사점 - 디자인 시스템을 정기적으로 감사하고 실제 사용 데이터를 확인해야 한다. - 유사한 변형이 계속 늘어난다면 기능을 유지하면서 옵션을 통합할 수 있는지 검토할 필요가 있다. - 명확한 기본값과 일관된 원칙을 정하면 사용자의 선택 부담을 줄일 수 있다. - 공통 레이아웃 템플릿과 조합형 컴포넌트를 함께 제공하면 확장성과 제작 속도를 모두 높일 수 있다.

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

Made in Figma: 국립공

미국 국립공원관리청(NPS)은 431개 국립공원과 기념지를 하나의 앱에서 다루기 위해, 과거의 인쇄 브로슈어 디자인 시스템인 매시모 비넬리의 ‘유니그리드(Unigrid)’를 디지털 인터페이스에 적용했다. GuideOne과 Twohy Design Works는 각 공원의 다양한 데이터와 서사를 수용하면서도 일관된 사용자 경험을 제공하는 앱을 만들었다. 이 사례는 오래 지속될 공공 서비스일수록 확장 가능한 디자인 시스템, 접근성, 협업 가능한 제작 환경이 중요하다는 점을 보여준다. ## 431개 공원을 하나의 앱으로 통합하기 - NPS는 요세미티 같은 대형 국립공원부터 펜실베이니아의 한 칸짜리 기념관까지 규모와 성격이 매우 다른 431개 시설을 관리한다. - 과거에는 방문객 안내를 위해 각 공원별 인쇄 브로슈어를 제작했다. - 2016년 GuideOne이 공원별 개별 앱을 개발하기 시작했지만, 이후 하나의 통합 NPS 앱으로 방향을 전환했다. - 통합 과정에서는 다음과 같은 문제가 발생했다. - 각 공원이 자체적으로 데이터를 관리하고 콘텐츠를 작성함 - 공원마다 역사, 시설, 방문 정보, 내러티브가 다름 - 서로 다른 데이터를 하나의 구조와 시스템으로 통합해야 함 - 장기간 유지될 정부 서비스이므로 내구성과 유지보수성이 필요함 - 다양한 장애와 접근성 요구를 가진 사용자를 지원해야 함 ## 인쇄 브로슈어에서 찾은 디자인의 출발점 - NPS 브로슈어는 오랫동안 공원마다 형식과 스타일이 제각각이었다. - 1977년 NPS는 디자이너 매시모 비넬리에게 모든 인쇄물의 그래픽 요소와 제작 방식을 표준화하는 시스템을 의뢰했다. - 이때 만들어진 유니그리드는 다음을 체계화했다. - 페이지 구성과 그리드 - 이미지와 텍스트의 배치 - 타이포그래피와 시각적 위계 - 브로슈어 제작 규격과 일관된 브랜드 표현 - GuideOne과 Twohy Design Works는 이 역사적 시스템을 그대로 복제하지 않고, 디지털 제품에 적합한 원칙으로 재해석했다. ## 유니그리드를 디지털 인터페이스로 확장 - 앱은 공원별 개성을 유지하면서도 전체 서비스가 하나의 제품처럼 보이도록 설계됐다. - 브로슈어에서 사용하던 구조적 일관성을 앱의 화면과 콘텐츠 구성에 적용했다. - 공식 NPS 앱은 다음 기능을 제공한다. - 공원과 시설을 탐색하는 인터랙티브 지도 - 방문객을 위한 핵심 정보 - 셀프 가이드 투어 - 공원별 장소, 활동, 안내 콘텐츠 - 디자인 시스템은 각 공원이 독자적인 콘텐츠를 제공하더라도 공통된 사용자 경험을 유지하도록 돕는다. - 즉, 유니그리드는 특정 화면의 시각적 스타일이 아니라 다양한 콘텐츠를 하나의 체계 안에 담는 운영 방식으로 활용됐다. ## 데이터와 엔지니어링을 함께 고려한 협업 - NPS 앱은 단순한 시각 디자인 프로젝트가 아니라 콘텐츠와 데이터 통합 프로젝트이기도 했다. - NPS, GuideOne의 개발팀, 디자인팀이 Figma를 통해 작업물을 공유하고 피드백을 주고받았다. - 디자인 단계에서 다음 사항을 함께 검토할 수 있었다. - 실제 NPS 데이터로 구현 가능한 화면인지 - 공원별 콘텐츠 차이를 시스템이 수용할 수 있는지 - 개발팀이 재사용 가능한 컴포넌트로 구현할 수 있는지 - 사용자의 탐색 흐름이 복잡한 공원 구조를 잘 반영하는지 - Figma는 디자인 시안을 전달하는 도구를 넘어, 기관 담당자와 디자이너, 개발자가 제약 조건을 조율하는 공동 작업 공간으로 사용됐다. ## 공공 서비스에 필요한 접근성과 지속성 - 정부용 소프트웨어는 일반적인 단기 제품보다 훨씬 긴 수명을 전제로 한다. - 따라서 유행하는 시각 효과보다 안정적인 구조와 유지 가능한 시스템이 중요하다. - 서로 다른 접근성 요구를 가진 많은 사용자가 이용하므로 정보의 명확한 위계와 예측 가능한 인터페이스가 필요하다. - 공원별 콘텐츠가 계속 추가·변경되더라도 전체 앱의 품질이 흔들리지 않도록 공통 디자인 규칙과 컴포넌트 체계가 기반이 됐다. ## 이 사례가 보여주는 디자인 시스템의 역할 - 디자인 시스템은 브랜드를 일관되게 보이게 하는 규칙에 그치지 않고, 대규모 조직의 다양한 콘텐츠를 운영하는 기반이 될 수 있다. - 역사적 디자인 자산을 디지털 환경에 적용할 때는 외형보다 그 안의 원칙을 계승하는 것이 중요하다. - 통합 서비스에서는 모든 콘텐츠를 똑같이 만드는 것보다, 차이를 수용할 수 있는 공통 구조를 만드는 것이 효과적이다. - NPS 앱은 종이 브로슈어의 시각 언어를 지도, 검색, 투어, 방문 정보가 결합된 디지털 경험으로 전환한 사례다. 장기적으로 운영될 공공 앱을 만든다면, 먼저 조직의 기존 콘텐츠와 디자인 자산에서 검증된 원칙을 찾고, 이를 재사용 가능한 컴포넌트와 명확한 데이터 구조로 변환하는 것이 좋다. 여기에 초기 단계부터 접근성과 개발 가능성을 함께 검토해야 일관되면서도 실제 운영에 강한 제품을 만들 수 있다.

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

요점만 말하자면:

Figma의 「Building better」는 개발자 경험(DX)이 특정 팀이나 도구만의 문제가 아니라, 조직 전체의 문화·원칙·프로세스에서 결정된다고 주장한다. 글은 VS Code, Atlassian, Linear 등의 사례를 통해 개발자의 몰입을 보호하고, 개발자 만족을 측정하며, 명확한 제품 철학과 디자인·개발 협업 체계를 구축하는 방법을 소개한다. 결론적으로 더 나은 개발 환경은 도구 도입보다 조직 차원의 일관된 운영 방식에서 출발한다. ## 개발자의 몰입을 지키는 ‘이너 루프’ VS Code는 개발자가 코드 작성에 집중하는 시간을 “이너 루프”, 버그 관리·티켓 응답·회의 같은 협업 활동을 “아우터 루프”로 구분한다. - 생산성을 가장 크게 떨어뜨리는 요인은 작업 자체보다 잦은 컨텍스트 스위칭이다. - 코드 편집과 디버깅처럼 집중력이 필요한 작업을 보호해야 한다. - 협업 활동을 완전히 제거하기보다, 이너 루프와 아우터 루프 사이의 전환 횟수를 줄이는 것이 핵심이다. - 개발 도구는 개발자가 여러 업무 시스템을 오가며 흐름을 잃지 않도록 지원해야 한다. ## 개발자 경험을 넘어선 ‘개발자 기쁨’ Atlassian은 개발자 경험을 넘어 “developer joy”를 조직의 중요한 기준으로 삼는다. - 개발자 기쁨은 단순한 편의성이나 만족도보다, 좋은 소프트웨어를 만드는 과정의 완성도와 장인정신에 초점을 둔다. - 이를 추상적인 구호로 남기지 않고 조직의 가치와 업무 방식에 반영한다. - 개발자 경험 개선이 생산성, 업무 만족도, 비즈니스 성과에 어떤 영향을 주는지 측정하려 한다. - 특정 팀의 활동에 그치지 않고 조직 전체로 확장하려면 공통된 원칙과 운영 체계가 필요하다. ## 강한 의견을 반영한 소프트웨어 Linear는 모든 사용자의 요구를 수용하기보다, 제품이 지향하는 명확한 관점을 바탕으로 기본적인 업무 흐름을 설계한다. - 좋은 도구는 기능을 무작정 늘리기보다 사용자가 따라갈 수 있는 강한 기본값을 제공한다. - 제품의 철학은 인터페이스뿐 아니라 우선순위 설정, 협업 방식, 내부 프로세스에도 반영된다. - 일반적인 관행과 다르더라도 일관된 원칙이 사용자 경험을 단순하고 예측 가능하게 만들 수 있다. - 다만 독단적인 설계가 아니라, 어떤 문제를 해결하려는지에 대한 분명한 판단이 전제되어야 한다. ## Dev Mode 도입에서 얻은 10가지 교훈 Decathlon의 엔지니어링 매니저는 1년간 Dev Mode를 디자인 시스템과 개발 workflow에 적용한 경험을 공유한다. - 처음부터 조직 전체에 도입하기보다 작은 범위에서 시작하는 것이 좋다. - 빠르게 효과를 확인할 수 있는 작은 개선부터 추진한다. - 디자인과 개발 사이의 전달 과정에서 반복되는 혼선을 찾아 해결한다. - Dev Mode를 단순한 기능 도입이 아니라 디자인 시스템 운영 방식의 일부로 활용한다. - 실제 사용 경험을 바탕으로 팀에 맞는 규칙과 협업 방식을 점진적으로 정립한다. ## 대규모 제품의 복잡성 관리 Crunchyroll은 웹, 모바일, 게임 콘솔 등 15개 플랫폼과 12개 언어를 지원하기 위해 Universal Design System을 활용한다. - 플랫폼과 언어가 늘어날수록 디자인 일관성과 개발 전달 과정이 복잡해진다. - 공통 컴포넌트와 디자인 시스템을 통해 여러 접점에서 동일한 사용자 경험을 유지한다. - Dev Mode는 디자인 사양을 확인하고 개발에 필요한 정보를 전달하는 과정을 간소화한다. - 디자인 시스템의 채택률을 높이려면 문서화뿐 아니라 실제 workflow 안에서 쉽게 사용할 수 있어야 한다. - 복잡성을 줄이는 핵심은 개별 화면을 관리하는 것이 아니라 재사용 가능한 시스템을 구축하는 데 있다. ## 디자인과 코드 사이의 연결 글의 ‘Rabbit hole’에서는 Figma의 Code Connect와 Simple Design System 사례를 통해 디자인과 실제 코드의 연결을 다룬다. - Simple Design System은 실제 코드 기반을 갖춘 UI 키트로, 디자인 결과물과 구현 결과 사이의 간극을 줄이는 것을 목표로 한다. - 디자인 시스템은 시각적 컴포넌트 모음에 그치지 않고 코드에서 어떻게 사용되는지까지 연결되어야 한다. - Code Connect 같은 접근은 디자인 컴포넌트와 실제 코드 컴포넌트의 관계를 명확히 하는 데 도움을 준다. - 디자인과 개발의 연결은 단순히 협업 편의성을 높이는 것뿐 아니라 구현 품질과 일관성을 관리하는 수단이기도 하다. 조직은 새로운 도구를 도입하는 데 그치지 말고, 집중 업무 보호, 명확한 제품 원칙, 측정 가능한 개발자 만족도, 디자인 시스템과 코드의 연결을 함께 설계해야 한다. 작은 workflow 개선부터 시작해 실제 효과를 검증하고, 검증된 방식을 조직 전체의 문화와 프로세스로 확장하는 접근이 현실적이다.

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

Figma on Figma:

Figma UI3는 작업물을 화면의 중심에 두고 사용자의 작업 흐름을 방해하지 않는 것을 목표로 2년 넘게 설계·개선된 인터페이스다. 초기에는 탐색·속성 패널을 플로팅 방식으로 바꿨지만, 실제 사용 데이터와 피드백을 통해 캔버스 공간과 작업 속도를 해친다는 점을 확인하고 고정 패널로 되돌렸다. Figma는 명확한 미래 비전을 세우되, 사용자 피드백과 성능 지표에 따라 과감하게 설계를 수정하는 접근을 강조한다. ## 작업 중심 인터페이스를 위한 UI3 - UI3의 핵심 목표는 캔버스와 디자이너의 작업을 중심에 두고 불필요한 방해 요소를 줄이는 것이다. - 팀은 2년 이상 다양한 인터페이스를 반복적으로 실험했으며, 출시 이후에도 기존의 핵심 설계 결정을 되돌렸다. - “완성도와 작업 흐름”처럼 직접 측정하기 어려운 요소는 정량 지표만으로 판단하기 어렵기 때문에 사용자 의견을 수집하고 신중하게 해석했다. - UI3는 2024년 10월 10일 모든 사용자에게 제공될 예정이었다. ## 도킹 패널과 플로팅 패널 실험 - 탐색 패널과 속성 패널은 Figma 인터페이스의 핵심 요소였기 때문에 다양한 실험이 진행됐다. - 마우스를 올릴 때만 나타나는 패널 - 캔버스 위에 떠 있는 패널 - 제품 전반에 일관되게 적용되는 플로팅 UI - 최종적으로 초기 UI3에서는 패널을 플로팅 방식으로 제공했다. - 플로팅 패널의 장점은 단순하고 친근한 인터페이스를 만들며, 제품 생태계 전체에 일관된 경험을 제공할 수 있다는 점이었다. - 그러나 오픈 베타 이후 실제 사용 데이터를 분석한 결과 다음 문제가 드러났다. - 작은 화면에서 캔버스 공간을 과도하게 차지함 - 디자인이 패널 뒤에서 일부 가려져 시각적으로 산만함 - 눈금자가 디자인에서 멀어져 활용성이 떨어짐 - 장시간 Figma를 사용하는 사용자들의 작업 속도를 저하시킴 - Figma는 “속도는 기능”이라는 판단 아래, 정식 출시에서는 탐색·속성 패널을 다시 고정했다. - 다만 패널 크기는 조절할 수 있도록 해 사용자가 작업 환경에 맞게 유연하게 배치할 수 있게 했다. - 플로팅 UI 자체가 완전히 사라지는 것은 아니다. - Figma Design의 Minimize UI 상태 - Figma Slides의 그리드 보기 - FigJam의 기본 인터페이스 - 모든 Figma 제품의 하단 툴바 에서는 플로팅 요소가 유지된다. ## Minimize UI와 작업 집중 - 기존의 Hide UI 기능은 작업물을 전면에 보여주지만, UI를 숨기거나 다시 표시하는 방식이 다소 극단적이고 제한적이었다. - UI3의 Minimize UI는 측면 패널을 접어 캔버스를 넓히면서도 필요할 때 도구에 쉽게 접근할 수 있도록 설계됐다. - 특히 다음 환경에서 유용하도록 개선됐다. - 작은 화면 - 분할 화면 - 원격·하이브리드 근무 환경 - Figma는 UI가 항상 많이 표시되어야 한다는 전제 대신, “작업이 캔버스의 중심이어야 한다”는 원칙을 장기적인 기준으로 삼았다. ## 확장성을 고려한 정보 구조 - UI3에서는 기능을 단순히 재배치하는 데 그치지 않고, 앞으로 추가될 기능을 수용할 수 있는 구조를 만들려 했다. - 기존 인터페이스는 새로운 기능을 넣을 때마다 화면에 요소를 억지로 끼워 넣는 방식에 가까웠다. - 새 탐색 패널은 다음과 같은 논리적 순서로 정보를 배치한다. - 파일 이름 - 브랜치 이름 - 프로젝트 이름 - 페이지 - 레이어 - 향후 파일 이동이나 탐색 방식이 추가되더라도 기존 구조를 크게 훼손하지 않고 확장할 수 있도록 설계했다. - 이는 현재의 편의성뿐 아니라 아직 구현되지 않은 미래의 기능까지 고려한 정보 구조다. ## 변화하는 인터페이스 관습과 블렌드 모드 - Figma는 UI3에서 과거 인터페이스의 일부 관습을 그대로 유지하기보다, 현재 사용자가 익숙하게 받아들이는 패턴을 재검토했다. - 예를 들어 다음과 같은 방식은 기술적으로는 다소 비직관적일 수 있지만 널리 정착됐다. - Shift 키를 사용하는 명령 단축키 - 화면에 거의 드러나지 않는 스크롤바 - 블렌드 모드 역시 과거의 사용 방식과 새로운 인터페이스 관습 사이의 균형을 맞추는 대상으로 다뤄졌다. - 제공된 글 내용은 블렌드 모드 섹션 초반에서 끝나므로, 구체적인 변경 사항은 확인할 수 없다. UI3의 가장 실용적인 교훈은 큰 폭의 redesign도 가설로 시작하되 실제 사용성 검증을 거쳐 수정해야 한다는 점이다. 새로운 UI를 도입할 때는 시각적 새로움보다 캔버스 공간, 작업 속도, 화면 크기별 사용성, 장시간 사용자의 효율을 우선적으로 측정하는 것이 바람직하다.

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

VS Code 방식: 개발자의 이너

개발자의 생산성을 높이려면 코드 작성 자체보다 코드와 디버깅에 몰입하는 ‘이너 루프(inner loop)’를 최대한 끊기지 않게 해야 한다. VS Code는 외부 도구로 이동하는 횟수를 줄이고, 협업·프로젝트 관리·AI 지원 기능을 편집기 안으로 통합해 몰입과 협업을 함께 달성하려 한다. 궁극적으로 도구를 오가는 마찰을 줄이는 것이 코드 품질뿐 아니라 개발자의 만족도와 에너지에도 영향을 준다는 주장이다. ## 이너 루프와 아우터 루프의 구분 - **이너 루프**는 코드 작성, 컴파일, 디버깅을 코드 에디터 안에서 반복하는 집중 작업 과정이다. - **아우터 루프**는 버그 트래커 확인, 티켓 업데이트, 동료와의 Slack·Teams 대화, 문서 검색, 프로젝트 관리 등 에디터 밖의 활동을 의미한다. - 여러 프로젝트를 동시에 진행하면 브라우저, API 문서, 터미널, 데스크톱을 계속 오가게 되며 집중력이 분산된다. - 몰입 상태가 유지되면 코드의 엣지 케이스와 향후 확장 계획 같은 맥락을 머릿속에 유지할 수 있다. - 반대로 컨텍스트 스위칭이 발생하면 이러한 맥락이 사라져 생산성과 코드 품질이 떨어진다. ## 편집기 안에서 집중력 유지하기 - VS Code의 **Zen Mode**는 사이드바 등 불필요한 UI를 숨겨 방해 요소를 줄인다. - 화면 구성이 바뀔 때마다 뇌가 새로운 UI에 적응해야 하므로, 작은 UI 변화도 누적되면 집중을 방해할 수 있다. - 개발자는 필요한 확장 기능을 선택해 자신의 작업 방식에 맞게 편집기를 구성할 수 있다. - 단일 도구의 사용성을 개선하는 것만으로는 충분하지 않으며, 도구 사이를 오가는 행위 자체를 줄여야 한다. ## 아우터 루프를 이너 루프로 가져오기 - GitHub에서 풀 리퀘스트를 확인한 뒤 다시 에디터로 돌아오는 과정처럼, 작업 중 도구를 전환하면 흐름이 끊긴다. - 가능한 경우 다음 기능을 코드 에디터에 직접 통합해야 한다. - 협업자와의 커뮤니케이션 - 코드 리뷰와 풀 리퀘스트 처리 - 프로젝트 관리와 티켓 확인 - 디자인 및 API 문서 참조 - Figma for VS Code 확장 기능을 사용하면 VS Code에서 디자인을 직접 확인하고 검사할 수 있다. - 필요한 협업이나 프로젝트 관리 작업을 현재 작업 공간에서 처리하면 불필요한 브라우저 전환을 줄일 수 있다. ## AI를 활용한 작업 흐름 보완 - 생성형 AI는 개발자가 작성 중인 코드를 분석해 다음에 필요할 가능성이 높은 코드를 미리 제안할 수 있다. - 제안이 작업 흐름을 방해하지 않는 방식으로 제공되면 코드 작성 속도와 집중력을 동시에 높일 수 있다. - 글에서는 GitHub Copilot 사용 시 코딩 속도가 55% 향상되었다는 GitHub의 보고와, AI 사용 개발자의 75%가 더 큰 성취감을 느꼈다는 조사 결과를 소개한다. - AI의 가치는 단순한 속도 향상뿐 아니라 개발자가 반복 작업에서 벗어나 더 만족스럽게 일하도록 돕는 데 있다. ## 협업도 몰입을 깨지 않는 방식으로 - 협업은 필수지만 회의와 실시간 채팅, 메시지 왕복은 개발자의 집중을 끊을 수 있다. - 이상적인 협업은 한 사람이 다른 사람의 작업을 중단시키는 방식이 아니라, 서로 각자의 이너 루프를 유지하며 진행하는 것이다. - VS Code는 GitHub 기능을 편집기에 통합해 다음 작업을 에디터를 떠나지 않고 수행하도록 지원한다. - 이슈 작업 - 코드 리뷰 - 풀 리퀘스트 작성 및 제출 - 모든 협업이 실시간이어야 하는 것은 아니며, 비동기 댓글과 리뷰를 활용하면 집중과 협업을 함께 유지할 수 있다. ## 개발자 행복으로 이어지는 선순환 - 도구 간 전환이 줄어들면 작업의 마찰과 반복적인 불편이 감소한다. - 몰입 상태가 길어질수록 생산성뿐 아니라 개발자의 에너지와 만족도도 높아진다. - 개발자 도구를 만드는 팀은 기능을 추가하는 것뿐 아니라, 개발자의 흐름을 방해하는 요소를 지속적으로 제거해야 한다. - 장기적으로는 코드 에디터가 개발에 필요한 모든 도구를 연결하는 통합 작업 공간이 되는 것이 이상적인 방향이다. 개발팀은 자주 발생하는 도구 전환 지점을 먼저 파악하고, GitHub·디자인 도구·문서·프로젝트 관리 기능을 에디터와 연동하는 것부터 시작하는 것이 좋다. 또한 알림을 줄이고 비동기 협업을 기본값으로 삼으면 집중력을 보존하면서도 협업 품질을 유지할 수 있다.

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

Figma on Figma: 최신

Figma는 디자이너 중심 도구에서 개발자·PM·제품팀 전체가 사용하는 생태계로 확장한 현실을 반영해 브랜드의 시각 언어를 재정비했다. 정적인 커서와 굵은 검은 윤곽선 중심의 기존 표현 대신, 공동 창작과 다양한 역할을 상징하는 프리미티브·색상·타이포그래피·모션을 도입했다. 새 브랜드는 누구나 아이디어를 현실로 만들 수 있는 협업 공간으로서의 Figma를 표현한다. ### 디자이너 도구에서 제품 개발 생태계로 - 지난 10년 동안 Figma는 순수한 디자인 도구에서 개발자, 제품 관리자, 전체 제품팀을 지원하는 플랫폼으로 성장했다. - 기존 브랜드는 벡터 그래픽의 문법에 가까웠다. - 정적인 마우스 커서 - 굵은 검은 외곽선 - 디자인 작업 자체에 초점을 둔 시각 표현 - 새로운 정체성은 아이디어 구상부터 개발, 협업, 완성까지 여러 사람이 참여하는 제품 제작 과정을 담는 데 초점을 맞췄다. ### 새 시각 언어를 구성하는 네 가지 기반 - **다목적 프리미티브** - 공동 창작에 참여하는 다양한 사람과 역할을 상징한다. - 특정 직군이나 작업 단계에 종속되지 않는 기본 형태로 활용된다. - **동적인 구성** - 만들고, 조정하고, 협업하는 다양한 작업 방식을 표현한다. - 정적인 결과물보다 제작 과정의 움직임과 상호작용을 강조한다. - **확장된 색상 팔레트** - 더 생생하고 폭넓은 색을 사용한다. - 색상 변수를 활용해 다양한 매체와 상황에 쉽게 적용할 수 있도록 설계했다. - **통합된 모션 원칙** - 창작 과정에서 발생하는 행동과 흐름을 애니메이션으로 표현한다. - 브랜드의 움직임이 단순 장식이 아니라 작업 과정과 연결되도록 했다. ### Figma 전용 서체 체계 - Figma는 Grilli Type과 협업해 독자적인 그로테스크 서체인 **Figma Sans**를 제작했다. - 브랜드에는 다음 네 가지 서체가 포함된다. - **Figma Sans**: 일반적인 브랜드 커뮤니케이션과 본문 - **Figma Sans Condensed**: 더 압축된 인상과 공간 효율이 필요한 표현 - **Figma Mono**: 개발, 코드, 정밀한 제작 작업을 연상시키는 표현 - **Figma Hand**: 브레인스토밍과 팀 협업처럼 인간적인 분위기를 전달 - 서로 다른 서체를 조합해 디자인, 엔지니어링, 협업 등 다양한 역할과 작업 방식을 표현한다. ### 샌드박스에서 시작한 탐색 - Figma Brand Studio는 사람들이 Figma를 사용하는 전 과정을 살펴보며 탐색을 시작했다. - 브레인스토밍 - 초기 아이디어 구상 - 요소 검사 - 최종 결과물의 세부 조정 - 팀은 여러 활동이 하나의 공유 공간에서 동시에 이루어지는 모습에 주목했다. - 이 개념은 사람들이 같은 공간에서 각자 놀고 만들며 상호작용하는 **parallel play**와 연결됐다. - Figma 캔버스를 사람들이 함께 만들고 실험하는 장소로 보고, 놀이터에서 시각적 영감을 얻었다. - Isamu Noguchi의 놀이터와 조경 작품 - Mitsuru Senda의 다채로운 패널형 놀이터 - 정교한 타일 작업과 인프라 구조 - 초기에는 놀이터의 형태를 직접적으로 차용했지만, 최종적으로는 이를 단순한 모방이 아니라 공동 창작과 실험을 상징하는 추상적 시각 언어로 발전시켰다. ### 실용적인 시사점 브랜드 리뉴얼은 로고나 색상만 바꾸는 작업이 아니라, 사용자의 역할과 제품이 지원하는 행동 범위를 다시 정의하는 과정이다. 특히 제품이 여러 직군의 협업 도구로 성장했다면, 시각 체계도 결과물뿐 아니라 아이디어 구상·소통·개발·수정 같은 전체 제작 흐름을 표현하도록 확장하는 것이 효과적이다.

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

우리만의 서체: Figma Sans 제작

Figma는 제품과 사용자층이 확장되면서 기존 브랜드와 서체를 함께 재정비했고, 그 결과 Grilli Type과 협업해 맞춤 서체인 Figma Sans를 만들었다. Figma Sans는 디스플레이와 본문 모두에서 잘 작동하고, 디자이너뿐 아니라 개발자·제품 관리자·초보 사용자까지 아우르는 유연성과 가독성을 목표로 했다. 제작 과정에서는 유행을 따르기보다 Figma만의 “주관 있는(opinionated)” 성격을 서체에 담는 데 집중했다. ## 브랜드 확장에 맞춘 서체 재설계 - 기존 서체인 **Whyte**는 2019년부터 Figma의 브랜드를 대표했으며, 특유의 인트랩(inktrap) 스타일을 갖고 있었다. - Figma가 다양한 제품 제작 도구를 제공하고 커뮤니티도 확장되면서, 기존 서체만으로는 새로운 브랜드 방향을 충분히 표현하기 어려워졌다. - 색상 팔레트, 일러스트레이션, 패턴, 모션 등 시각 아이덴티티 전반을 바꾸는 과정에서 서체도 핵심 요소로 재검토됐다. - 새로운 브랜드는 강렬한 색상과 더 복잡하고 추상화된 형태를 사용했기 때문에, 이를 보완하면서도 과도하게 튀지 않는 서체가 필요했다. ## 현대적 그로테스크 서체를 선택한 이유 - Figma 팀은 여러 스타일을 검토한 끝에 **현대적인 그로테스크 계열 산세리프**를 적합한 방향으로 판단했다. - 그로테스크는 19세기 초부터 등장한 산세리프 서체 양식으로, 장식이 적고 구조가 명확한 것이 특징이다. - Figma Sans에는 다음과 같은 조건이 요구됐다. - 다양한 굵기와 옵티컬 사이즈 지원 - 마케팅용 대형 제목과 본문 텍스트 모두에서 높은 성능 - Help Center 같은 긴 글을 읽는 화면에서도 가독성 확보 - 디자이너뿐 아니라 개발자, 제품 관리자, 신규 사용자도 편하게 사용할 수 있는 폭넓은 인상 - 단순히 개성적인 서체가 아니라, 여러 제품과 사용 환경에 적용할 수 있는 실용성이 중요했다. ## 기성 서체 대신 맞춤 서체를 선택 - Figma 팀은 Commercial Type의 **Marr Sans**, RP Digital Type Foundry의 **Agipo** 등 다양한 기성 서체를 검토했다. - 그러나 브랜드의 개성과 기능적 요구를 동시에 충족하는 서체를 찾기 어려웠다. - 이에 따라 Figma는 외부 서체를 선택하는 대신, 요구사항을 함께 정리하고 브랜드에 맞게 설계할 수 있는 맞춤 서체 제작을 결정했다. - 협업 파트너로는 그래픽 디자인과 서체 제작에서 강한 개성을 보여온 스위스·미국 기반의 **Grilli Type**을 선택했다. - Grilli Type은 일반적인 유행이나 역사적 서체의 복제보다, 흥미로운 개념적 틀을 바탕으로 독자적인 서체를 만드는 접근을 중시했다. ## “주관 있는” 서체라는 방향 설정 - Grilli Type은 Figma의 요구사항을 정리하기 위해 무드보드를 만들고, 다양한 시각적 아이디어가 어떻게 연결되는지 탐색했다. - 프로젝트의 중심 질문은 브랜드 설명에서 말하는 핵심 긴장감이 무엇인지 찾는 것이었다. - 그 과정에서 **“opinionated”**, 즉 자신이 누구인지와 무엇을 원하는지 분명히 아는 태도가 중요한 키워드로 자리 잡았다. - Figma Sans는 장식이나 불필요한 요소를 덧붙이기보다, 단순하고 명확하지만 확실한 인상을 주는 방향으로 발전했다. ## 두 가지 초기 방향을 결합한 설계 - Grilli Type은 초기 단계에서 서로 다른 두 가지 디자인 방향을 제시했다. - 하나는 보다 직관적이고 단순한 방향 - 다른 하나는 훨씬 실험적이고 과감한 방향 - 두 안 중 하나를 그대로 선택하기보다, 각각이 어떤 가능성을 열어주는지 논의하는 데 초점을 맞췄다. - 최종적으로는 첫 번째 방향의 단순화된 형태를 기본으로 삼고, 두 번째 방향의 독특한 특징을 일부 결합했다. - 참고 자료로는 다음과 같은 역사적 사례가 활용됐다. - 1925년 『Typographische Mitteilungen』의 타이포그래피 - 1960년대 Karl Gerstner의 프로그램적 디자인 - 전화번호부용으로 설계된 Matthew Carter의 **Bell Centennial** - 이를 통해 Figma Sans는 읽기 쉬운 구조와 브랜드 고유의 개성을 동시에 추구했다. ## 실용적인 결론 Figma Sans의 제작 과정은 브랜드용 서체가 단순히 새로운 글꼴을 만드는 작업이 아니라, 브랜드의 사용자·제품·시각 언어를 하나의 시스템으로 정리하는 과정임을 보여준다. 특히 여러 화면과 사용자층을 고려해야 한다면, 개성만 강조하기보다 본문 가독성, 다양한 굵기, 적용 범위까지 함께 설계하는 것이 중요하다.

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