figma·2024년 6월 25일·3분 읽기큐레이션 요약

아무도 당신을 판단

Perplexity는 링크 목록을 보여주는 검색엔진이 아니라, 웹의 정보를 종합해 출처와 함께 답을 제공하는 ‘답변 엔진’을 지향한다. 목표는 사용자가 남의 시선을 의식하지 않고 무엇이든 질문하게 하며, 짧은 시간에 핵심을 이해한 뒤 더 깊은 호기심으로 나아가도록 돕는 것이다. 이를 위해 최신 웹 정보, 간결한 요약, 투명한 출처, 대화형 인터페이스를 결합한다. ## 호기심을 위한 지식 앱 - 공동 창업자 아라빈드 스리니바스는 어린 시절 위키피디아 링크를 따라가며 지식을 탐색하던 경험에서 Perplexity의 아이디어를 얻었다. - 백과사전이 종이책, CD·DVD, 위키피디아를 거쳐 Perplexity로 발전했다고 본다. - 사람들의 참여를 유도하는 방식이 반드시 짧은 영상이나 자극적인 콘텐츠일 필요는 없으며, 호기심 자체를 자극할 수 있다고 주장한다. - 누구나 판단받을 걱정 없이 질문할 수 있게 하는 것이 제품의 중요한 목표다. ## 두려움을 넘어선 창업 - 창업자들은 처음에 자신들의 질문에 답하기 위해 Slack 봇을 만들었다. - 투자 유치 방식 - 직원 건강보험 설정 등 실무적인 질문 - 제품이 유용했지만, 구글과 경쟁한다고 사람들이 비웃을까 봐 공개를 망설였다. - 투자자 냇 프리드먼은 “잃을 것이 없고, 최악의 결과도 현재보다 나은 진전”이라는 비대칭적 베팅의 관점을 제시했다. - 이 조언을 계기로 Perplexity는 ChatGPT 출시 직후 서비스를 공개했다. ## ChatGPT 이후의 차별화 - ChatGPT가 지식의 기준 시점과 환각 문제를 널리 인식시킨 상황에서, Perplexity는 답변뿐 아니라 근거 출처도 함께 제공하는 방향을 택했다. - 핵심 구성 요소는 다음과 같다. - 자연어 질문 이해 - 웹 검색 및 색인 - 대규모 언어 모델 - 여러 웹페이지의 정보 종합 - 답변별 출처와 각주 제공 - Perplexity는 “위키피디아와 대화형 채팅을 결합한 서비스”로 설명되며, 정보의 범위는 전체 인터넷으로 확장된다. ## 정보를 쉽게 전달하는 80/20 접근법 - 사용자가 모든 자료를 처음부터 끝까지 읽지 않아도 핵심적인 이해를 얻도록 하는 것이 목표다. - 책의 서론과 첫 장을 읽어 전체 가치의 상당 부분을 파악하는 방식처럼, Perplexity도 여러 웹페이지에서 중요한 내용을 추려 간결한 답변을 만든다. - 예를 들어 LLM을 이해할 때 전체 세부사항을 다 알기보다, 핵심 개념의 약 20%를 통해 전체 이해의 80%를 얻도록 돕는다. - 단순화하되 내용을 지나치게 축약하지 않고, 원문 출처를 확인할 수 있게 해 정보의 신뢰성과 깊이를 유지한다. ## 답변에서 새로운 질문으로 - 질문에 답한 뒤 관련 질문 세 가지를 제시해 사용자가 다음 탐색 단계로 자연스럽게 이동하도록 한다. - 창업자는 모든 사람이 본질적으로 호기심이 많지만 다음과 같은 이유로 질문을 충분히 발전시키지 못한다고 본다. - 호기심을 탐구할 동기가 부족함 - 무엇이 궁금한지 정확히 표현하기 어려움 - 좋은 질문을 만드는 능력이나 배경지식이 부족함 - 좋은 질문은 사용자의 지식 수준과 목적에 따라 달라진다. 같은 블랙홀 주제라도 일반 사용자와 물리학 박사에게 필요한 설명의 깊이는 다르다. - 따라서 제품은 사용자가 질문을 정확히 만들지 못했다고 탓하기보다, 사용자의 의도와 이해 수준에 맞춰 질문을 구체화하고 탐색을 지원해야 한다. ## 실용적인 시사점 Perplexity의 사례는 AI 검색 서비스가 단순히 더 많은 정보를 제공하는 것보다, **검증 가능한 답변을 적절한 깊이로 전달하고 다음 질문까지 설계하는 것**이 중요하다는 점을 보여준다. 지식 탐색 제품을 만들 때는 정확한 출처, 사용자 수준에 맞는 설명, 판단받지 않는 질문 환경, 후속 호기심을 유도하는 인터페이스를 함께 고려하는 것이 효과적이다.

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

AI대규모 언어 모델자연어 처리conversational-ai+2

figma·2024년 6월 17일·4분 읽기큐레이션 요약

AI의 가능성과 위험 요소를

AI는 제품과 디자인의 생산성을 높일 가능성이 크지만, 현재의 변화는 개인 업무에 집중되어 있으며 협업 방식까지 근본적으로 바꾸지는 못했다. 개발자는 코드 생성과 언어 변환처럼 AI와 잘 맞는 업무 덕분에 디자이너보다 더 큰 변화를 경험하고 있다. 따라서 기업은 유행에 맞춰 기능을 빠르게 출시하기보다, 실험과 연구를 반복하며 실제 사용자와 협업에 가치를 만드는 AI 제품을 찾아야 한다. ## 조사 배경과 접근 방식 - Figma는 2024년 2월 26일부터 3월 3일까지 7개국의 Figma 사용자 1,800명 이상을 조사했다. - 응답자는 디자이너, 경영진, 개발자로 구성됐다. - 조사 대상 국가는 미국, 캐나다, 호주, 영국, 일본, 프랑스, 독일이다. - 연구의 핵심 전제는 AI 제품의 영향력이 LLM의 성능뿐 아니라 제품이 어떻게 설계되는지에 따라 달라진다는 것이다. - AI의 가능성이 아직 확정되지 않은 만큼, 제품팀은 빠른 출시 압박 속에서도 실험·놀이·사용자 연구를 지속해야 한다. ## 업무 흐름 전반의 AI 전환 - 생성형 AI는 프롬프트에 반응해 텍스트, 이미지, 코드 등 데이터를 생성하는 기술이다. - 개발자는 디자이너보다 AI가 자신의 제품을 변화시켰다고 답할 가능성이 60% 높았다. - 개발 업무는 다음과 같이 AI가 직접 지원하기 쉬운 작업을 많이 포함한다. - 코드의 출발점 생성 - 프로그래밍 언어 간 변환 - 반복적인 구현 작업 보조 - 반면 디자인의 핵심 업무는 사용자 요구와 문제 공간을 깊이 이해하고, 비선형적으로 탐색하며 학습하는 과정이다. - AI는 목업을 코드로 변환하는 데 도움을 줄 수 있지만, 아직 디자인의 근본적인 문제 정의와 탐색 과정에는 상대적으로 큰 영향을 주지 못하고 있다. - AI 프로젝트 아이디어가 디자이너뿐 아니라 프로그래머, 분야별 전문가, 이해관계자로부터도 나오면서 조직 전체가 AI 제품 개발에 참여하고 있다. ## 개인 생산성에서 협업으로 확장해야 하는 이유 - 응답자의 85%는 AI가 개인 생산성이나 업무 흐름에 영향을 주었다고 답했다. - 가장 흔한 활용 방식은 다음과 같다. - 텍스트와 이미지 생성 - 아이디어를 점검하는 사고 파트너 - 초안 작성과 브레인스토밍 지원 - 응답자는 AI가 개인 업무를 크게 변화시켰다고 답할 가능성이 협업 업무보다 세 배 높았다. - 그러나 AI가 팀의 다음 활동을 크게 바꾸었다는 인식은 상대적으로 낮았다. - 의견 조율 - 회의 진행 - 공동 작업 방식 - AI와 대화하는 개인 작업도 넓은 의미에서는 협업으로 볼 수 있지만, 현재 AI 제품은 주로 개인의 생산성 향상에 머물러 있다. - 진정한 변화를 만들려면 제품팀은 개별 작업 자동화를 넘어 팀의 의사결정과 공동 창작을 어떻게 개선할지 고민해야 한다. ## 산업과 일상생활에 미칠 영향 - 기술 산업 종사자의 41%, 전문·비즈니스 서비스 종사자의 40%, 유통업 종사자의 39%가 AI로 제품과 서비스가 크게 바뀔 것으로 예상했다. - 반면 의료, 에너지·공공서비스, 통신 분야는 향후 12개월 동안 AI의 영향이 상대적으로 작을 것으로 전망됐다. - AI의 잠재력을 실현하려면 소프트웨어 기업뿐 아니라 의료·에너지·통신처럼 일상생활의 기반이 되는 산업도 변화해야 한다. - AI의 영향은 화면이나 기능 추가에만 국한되지 않고, 사람들이 서비스를 이용하고 조직이 운영되는 방식 자체를 바꿀 수 있다. ## 실험과 반복을 통한 유용성 검증 - AI 기술에 대한 기대와 실제 유용성 사이에는 여전히 차이가 있다. - 새로운 앱, 기능, 연구 논문이 빠르게 등장하면서 기업은 AI 기능을 서둘러 출시하라는 압박을 받고 있다. - 하지만 무엇이 실제로 사용자에게 도움이 되는지는 아직 충분히 검증되지 않았다. - 제품과 디자인 리더는 다음과 같은 태도를 취해야 한다. - 불확실성을 받아들이기 - 다양한 아이디어를 빠르게 실험하기 - 사용자 반응과 실제 사용 맥락을 관찰하기 - 효과가 없는 기능은 반복적으로 수정하거나 폐기하기 - AI 제품 개발은 아직 단순한 출시 경쟁이라기보다, 어떤 사용 경험과 협업 방식이 지속될지 찾아가는 단계에 가깝다. AI를 도입할 때는 “AI 기능을 추가했는가”보다 “사용자와 팀의 문제를 실제로 해결했는가”를 기준으로 평가하는 것이 좋다. 개인 생산성 도구에서 시작하되, 사용자 이해·협업·산업별 맥락을 반영한 실험을 반복해야 장기적으로 유용한 AI 제품에 도달할 수 있다.

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

AI대규모 언어 모델머신러닝생성형 AI+2

figma·2024년 6월 11일·3분 읽기큐레이션 요약

요점 정리: 제5호

아이디어를 현실로 만드는 여정에는 동료, 멘토, 커뮤니티와의 연결이 필수적이라는 글이다. Figma는 Config 2024를 앞두고 창작 도구, 제품의 완성도, AI, 커뮤니티가 서로 영향을 주는 사례들을 소개한다. 온라인과 오프라인을 막론하고 함께 배우고 교류하는 것이 창작과 혁신을 지속시키는 힘이라고 강조한다. ## 사람과 커뮤니티가 만드는 진전 - 예상치 못한 이메일, 멘토의 조언, 동료와의 대화가 아이디어를 구체화하고 다음 단계로 나아가게 한다. - 개인의 성취처럼 보이는 결과도 실제로는 주변 사람들과의 연결과 협업에서 비롯되는 경우가 많다. - Figma는 Config를 통해 창작자, 개발자, 제품 담당자, 디자이너가 서로의 경험을 공유하도록 장려한다. - 직접 만나는 방식뿐 아니라 온라인 커뮤니티와 URL을 통한 연결도 중요한 관계 형성 수단으로 본다. ## 개발자 도구를 ‘마법처럼’ 만드는 제품 설계 - Snap AR의 Lens Studio를 만든 제품 관리자 Charmaine Lee의 경험을 소개한다. - 좋은 창작 도구는 기획자나 관리자만 설계하는 것이 아니라, 팀 전체가 실제 파일과 제품을 직접 사용하며 만들어야 한다. - 개발자와 창작자의 작업 방식에 깊이 참여하는 ‘all-hands-on-deck’ 접근이 도구의 사용성과 즐거움을 높인다. - 사용자가 도구를 배우는 데 드는 부담을 줄이고, 아이디어를 즉시 실험할 수 있게 하는 것이 핵심이다. ## 형태와 기능을 결합하는 완성도 - Stripe의 Katie Dill, Linear의 Karri Saarinen, Figma의 Yukhi Yamashita가 제품의 ‘craft and beauty’를 논의한다. - 아름다운 시각적 표현은 기능과 분리된 장식이 아니라 제품 경험의 일부다. - 완성도와 품질은 단순한 미적 평가를 넘어 사용자 만족도, 신뢰, 제품 성장과 연결된다. - 형태와 기능을 함께 다듬는 투자가 장기적으로 비즈니스 성과와 제품 경쟁력에 영향을 준다고 설명한다. ## Figma를 활용한 퀼트 제작 - 전직 제품 디자이너 Nicole Boettcher는 익숙한 디자인 도구인 Figma로 퀼트를 설계하고 제작한다. - Figma에서 도형을 배치하고 패턴을 계획하는 방식이 실제 천 조각의 구성과 배치에도 활용된다. - 디지털 디자인 도구는 화면 속 UI 제작을 넘어 공예와 물리적 제작 과정에도 적용될 수 있다. - “사각형을 움직이는 일”이라는 디자이너의 작업 방식이 새로운 창작 분야에서도 이어진다는 점을 보여준다. ## AI 시대에 필요한 학습과 협업 - Replit의 David Hoang은 AI가 창작 도구와 제품 설계·개발 workflow를 크게 바꿀 것으로 전망한다. - AI의 변화에 대응하려면 개인이 혼자 학습하기보다 동료 집단과 함께 실험하고 배우는 환경이 필요하다. - 구성원 간의 책임감과 즐거움이 공존하는 커뮤니티가 지속적인 학습 동기를 만든다. - 기술 변화가 클수록 서로의 경험을 공유하고 함께 적응하는 코호트와 커뮤니티의 역할이 커진다. ## Config 2024와 참여 방법 - 2024년 Config의 현장 티켓은 매진됐지만 온라인 참가와 지역별 watch party 참여가 가능하다고 안내한다. - 행사 기간에는 라이브 블로그를 통해 발표 내용, 연사 하이라이트, 참가자 관련 소식을 확인할 수 있다. - 이번 호의 일러스트와 Config 관련 굿즈는 일러스트레이터 Thomas Colligan이 제작했다. - 뉴스레터 구독을 통해 관련 콘텐츠를 지속적으로 받아볼 수 있다. 창작 도구와 기술의 발전을 따라가려면 도구 자체뿐 아니라 이를 사용하는 사람들과 적극적으로 연결하는 것이 좋다. 특히 새로운 AI 도구를 학습하거나 제품을 개선할 때는 혼자 완성하려 하기보다 동료와 실험하고 피드백을 나누는 환경을 만드는 것이 실용적인 접근이다.

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

FigmaAI프로덕트 디자인developer-tools+3

figma·2024년 6월 10일·3분 읽기큐레이션 요약

Config 202

Config 2024는 전 세계 제품 제작자들이 모여 디자인, 기술, 창의성에 대해 공유한 Figma의 연례 콘퍼런스다. 글은 현장 분위기와 주요 세션을 실시간으로 전하며, 창작자가 외부 세계의 영향과 자신의 경험을 제품에 반영해야 한다는 메시지를 강조한다. 행사 이후에는 세션 영상과 출시 요약을 제공하고, 아시아·태평양 지역을 위한 Config APAC 개최 소식도 안내한다. ## Config 2024의 규모와 현장 분위기 - 전 세계 참석자, 발표자, 자원봉사자, Figma 직원이 행사를 함께 만들었다. - 샌프란시스코 Moscone 행사장과 온라인 무대에서 세션이 진행됐다. - 주요 프로그램에는 다음과 같은 세션이 포함됐다. - `Design of Everything` - 신규 기능 요약 및 Friends of Figma - Figma EDU - `Figma like the pros` - Config 2024 회고 - 참석자들은 전시장, 전시물, 굿즈 매장, Maker Space에서 교류했다. - 행사 영상은 YouTube 플레이리스트에서 다시 볼 수 있으며, 별도의 출시 요약 글도 제공됐다. ## 외부 세계에서 영감을 얻는 디자인 - The Browser Company의 Karla Mickens Cole과 Nashilu “Nash” Mouen이 `Designing for Everything` 키노트를 진행했다. - 두 발표자는 직선적이고 예측 가능한 디자인 관습을 깨고 새로운 기대를 만들어내는 방법을 이야기했다. - 제품에 창작자의 진정한 경험과 개성을 흔적으로 남기는 것을 중요한 원칙으로 제시했다. - Nash는 기술 내부의 관습만 참고해서는 새로운 제품을 만들기 어렵고, 기술 외부의 문화·이야기·브랜드에서 영감을 얻어야 한다고 강조했다. - 이는 제품 디자인이 기능 구현을 넘어 창작자의 배경과 다양한 세계관을 반영해야 한다는 메시지로 이어진다. ## AI와 디지털 아트의 가능성 - 디지털 아티스트 Refik Anadol은 Figma의 DesignOps 디렉터 Meredith Black과 대담했다. - 그의 작품 `Unsupervised`는 MoMA의 아카이브를 AI로 해석하고 변형하는 디지털 아트 작품이다. - Anadol은 이를 통해 “기계가 꿀 수 있는 가능한 꿈”을 계산했다고 설명했다. - AI가 데이터를 단순화한다는 비판에 대해서는 비평자의 관점과 의도를 함께 살펴봐야 한다고 답했다. - 대담은 AI가 예술과 데이터 해석의 방식을 바꾸는 동시에, 디지털 아트에 대한 기존 미술계의 인식에도 질문을 던진다는 점을 보여준다. ## 실패와 놀이에서 출발하는 창의성 - 발명가이자 유튜버인 Simone Giertz는 양치질 헬멧, 사람을 깨우는 알람시계, 수프를 먹여주는 로봇 등 유쾌한 발명품을 소개했다. - 스타트업을 그만둔 뒤 스스로 놀 수 있는 여유를 허용하면서 창의성이 다시 살아났다고 설명했다. - 지나치게 탁월해야 한다는 압박보다 실험과 놀이가 더 효과적일 수 있다고 말했다. - “어렵다고 해서 중요한 것은 아니다”라는 관점으로 일의 우선순위를 재고했다. - 자신의 자기비하적 태도가 능력을 약화시킬 수 있다는 점을 깨닫고, 2019년 제품 디자인 회사 Yetch를 설립했다. - 참가자들에게 벽돌 하나의 용도를 2분 동안 최대한 많이 생각하게 하는 브레인스토밍을 진행해, 엉뚱한 아이디어를 의도적으로 끌어냈다. - 그녀는 자신의 직업을 직접 발명한 것이 가장 좋아하는 발명이라고 표현했다. ## 커뮤니티와 브랜드 경험 - Figma Store에는 후디, 티셔츠 등 독특한 디자인의 굿즈를 구매하려는 긴 줄이 이어졌다. - 참가자들은 Figma의 굿즈가 브랜드의 개성과 유머를 잘 보여준다고 평가했다. - Maker Space의 Customization Station에서는 참가자가 토트백에 패치를 붙여 직접 꾸밀 수 있었다. - Aura portrait 같은 체험형 프로그램도 운영되어, 단순한 강연을 넘어 참가자가 행사 콘텐츠를 직접 만들고 공유하도록 했다. - 이러한 활동은 Figma가 소프트웨어뿐 아니라 커뮤니티와 물리적 브랜드 경험까지 함께 구축하고 있음을 보여준다. 행사의 메시지를 실무에 적용한다면, 익숙한 업계 사례만 반복해서 참고하기보다 예술·문화·개인 경험 등 다양한 외부 자극을 제품에 연결하는 것이 좋다. 또한 초기 아이디어 단계에서는 완성도보다 놀이와 실험을 우선하고, 실패하거나 엉뚱해 보이는 발상도 충분히 탐색하는 접근이 유용하다.

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

FigmaAI사용자 경험프로덕트 디자인+2

figma·2024년 6월 6일·3분 읽기큐레이션 요약

샤메인 리의 개발자

개발자 도구가 ‘마법처럼’ 느껴지려면 세련된 UI보다 사용자가 가치를 깨닫고 스스로 창작할 수 있게 되는 과정이 중요하다. 특히 첫 사용 경험(FTUE)에 과도하게 집중하기보다, 사용자가 ‘아하’ 순간 이후 빠르게 독립적인 제작자가 되도록 돕고 개발자 커뮤니티와 진정성 있게 소통해야 한다. 글에서 소개된 원칙은 제공된 내용 기준으로 네 가지다. ## 첫 사용 경험보다 지속적인 사용에 집중 - FTUE에 제품의 모든 기능과 복잡성을 한꺼번에 담으면 사용자가 실제로 제품을 이해하고 활용하기 어려워진다. - 중요한 것은 가입이나 온보딩 완료가 아니라, 사용자가 ‘아하’ 순간 이후에도 계속 제품을 사용할 수 있게 하는 것이다. - Lens Studio 5.0 공개 베타에서는 별도의 FTUE를 제공하지 않고, 안내 없이도 직관적으로 사용할 수 있는 제품을 만드는 데 집중했다. - 전환율보다 사용자의 실질적인 이해와 자립을 목표로 삼아야 한다. ## 사용자가 ‘마법’을 경험하는 시간 단축 - 사용자가 도움말이나 안내에 의존하지 않고 직접 결과물을 만드는 순간까지의 시간을 줄여야 한다. - 팀은 FigJam에서 다운로드부터 첫 프로젝트 제출까지의 사용자 여정을 시각화하고, 총 19단계를 분석했다. - 사용자 테스트를 통해 이미 직관적인 단계는 별도의 개선 대상에서 제외하고, 불필요한 단계를 제거했다. - 그 결과 최초 경험을 핵심적인 네 단계로 축소해 사용자가 더 빠르게 제작자가 되도록 했다. - 여정 설계에서는 사용자의 즐거움을 유발하는 요소, 개선이 필요한 부분, 누락된 지원 요소를 함께 찾아야 한다. ## 사용자가 있는 곳에서 직접 소통하기 - 개발자는 컨퍼런스, 밋업, 라이브 스트리밍, 해커톤 등 다양한 커뮤니티 활동을 활발히 한다. - 제품 관리자는 이런 현장에 직접 참여하고, 관련 소셜미디어의 대화까지 꾸준히 관찰해야 한다. - 실제 사용자의 언어와 맥락을 이해하면 제품 아이디어에 대한 솔직하고 즉각적인 피드백을 얻을 수 있다. - PM의 역할은 개별 인터뷰 몇 건에 의존하는 것이 아니라, 제품과 관련된 대화와 맥락을 지속적으로 축적해 의사결정에 활용하는 것이다. ## 전통적인 마케팅 대신 개발자 관계(DevRel) 강화 - 개발자는 일반적인 광고나 과장된 마케팅보다 자신의 경험에 공감하는 진정성 있는 목소리를 선호한다. - 효과적인 커뮤니케이션에는 다음이 포함된다. - 제품을 만드는 과정에 대한 구체적인 이야기 - 실수와 한계를 인정하는 투명성 - 초보자도 이해할 수 있는 접근성과 필요한 기술 용어의 균형 - DevRel은 전담 조직만의 업무가 아니라 제품, 엔지니어링, PM을 포함한 전 구성원의 책임이어야 한다. - 팀 전체가 제품을 알리고 사용자의 요구를 대변할 때 장기적이고 충성도 높은 개발자 커뮤니티를 만들 수 있다. 개발자 도구를 설계할 때는 첫 화면의 인상이나 온보딩 전환율보다 사용자가 첫 결과물을 만들고 독립적으로 활용하기까지의 흐름을 측정하는 것이 실용적이다. 또한 개발자 커뮤니티에 직접 참여해 얻은 피드백을 제품 개선과 DevRel 활동에 지속적으로 반영해야 한다.

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

사용자 경험developer-toolsaugmented-realityunity+3

figma·2024년 6월 2일·3분 읽기큐레이션 요약

초안 작동 방식 업데이트 | Figma

Figma는 Starter·Professional 플랜의 Drafts를 팀과 분리된 개인 공간에서 팀 내부의 전용 Drafts 공간으로 이전한다. 이를 통해 파일 소유권과 권한을 명확히 하고, 팀 플랜 기능과 향후 결제·라이선스 관리 개선의 기반을 마련하려는 것이다. Drafts는 계속 비공개로 유지되며 무료로 생성·편집할 수 있지만, 팀으로 이동할 때 일부 협업자의 편집 권한이 변경될 수 있다. ## Drafts 이전의 배경 - 기존 Drafts는 팀에 속하지 않아 파일 소유권과 팀 연계가 불명확했다. - Starter·Professional과 Organization·Enterprise의 Drafts 구조가 달라 제품 개선이 복잡했다. - 팀과 연결되지 않은 Drafts에서는 고급 프로토타이핑, 비밀번호 보호, Dev Mode 같은 유료 기능을 사용할 수 없었다. - 개인 작업과 업무용 작업이 분리되지 않아 파일 권한, 보안, 지식재산권 관리에 문제가 생길 가능성이 있었다. ## Drafts의 새로운 구조 - 모든 Drafts는 이제 하나의 팀에 연결되어야 한다. - 사용자는 자신이 속한 각 팀 안에 개인 전용 Drafts 공간을 갖는다. - Professional 팀의 Drafts에서는 편집자에게 Professional 기능이 제공된다. - Starter 팀이 하나뿐인 사용자는 Drafts가 해당 팀의 새 Drafts 공간으로 자동 이전될 수 있다. - 팀 목록은 새 드롭다운 메뉴를 통해 확인하고 선택할 수 있다. ## 협업 권한과 요금 변화 - 팀으로 Draft를 옮겨도 파일은 기본적으로 계속 비공개다. - Draft의 기존 편집자가 해당 팀의 정식 멤버가 아니면, 예상치 못한 유료 좌석 발생을 막기 위해 자동으로 뷰어로 변경된다. - 필요한 경우 사용자 또는 관리자가 다시 편집 권한을 부여해야 한다. - Starter 팀에서는 무제한 뷰어를 초대할 수 있고, 최대 3개의 협업 파일에는 무제한 편집자를 둘 수 있다. - 개인 Drafts를 팀에 소속시키더라도 자신의 Draft를 계속 무료로 생성·편집할 수 있다. ## Drafts를 팀으로 이동하는 방법 - “Drafts to move” 공간으로 이동하면 원하는 팀의 Drafts 공간을 선택해 파일을 옮길 수 있다. - 특정 팀과 관련 없는 개인 작업은 무료 Starter 팀을 만든 뒤 그 팀으로 이동할 수 있다. - 이전 작업이 진행 중인 동안에도 기존 협업자와 Draft를 계속 편집할 수 있다. - 다만 새로운 협업자를 초대하려면 먼저 파일을 팀으로 이동해야 한다. - 현재 고정된 마감일은 없으며, 향후 이동하지 않은 Drafts는 무료 Starter 플랜으로 이전될 예정이다. 이전 전에는 별도 안내가 제공된다. ## 앞으로의 개선 방향 - 사용자가 유료 편집자 좌석으로 전환되는 시점을 더 명확히 안내할 예정이다. - 프리랜서의 프로젝트 인계와 여러 팀에 속한 사용자의 업무를 지원할 계획이다. - 관리자 대시보드와 게스트 관리 등 라이선스 관리 기능을 개선할 예정이다. - Figma의 결제 관련 사용자 경험도 전반적으로 재설계하고 있다. ## 실용적인 대응 현재 Drafts를 검토해 업무용·개인용 파일을 적절한 팀으로 분류하고, 이동 후 편집 권한이 필요한 협업자가 해당 팀의 정식 멤버인지 확인하는 것이 좋다. 어느 팀에도 속하지 않는 개인 작업은 별도의 무료 Starter 팀으로 분리하면 관리와 권한 설정이 수월하다.

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

Figma프로토타이핑dev-modeaccess-control+2

figma·2024년 5월 28일·3분 읽기큐레이션 요약

리니어 방식: 주

Linear는 모든 사용자가 각자 업무 방식을 설계하도록 방치하기보다, 특정 목적에 최적화된 “의견이 분명한 소프트웨어”를 제공해야 한다고 주장한다. 명확한 기본값과 단순한 개념으로 사용자의 학습 부담을 줄이고, 프로세스 논쟁보다 실제 제품 개발에 집중하게 만드는 것이 목표다. 다만 모든 결정을 고정하는 것은 아니며, 작은 단위에는 강한 원칙을 적용하고 큰 구조에는 고객 피드백을 반영하면서 의견을 계속 발전시킨다. ## 의견이 분명한 소프트웨어란 무엇인가 - 특정 사용 사례를 위해 설계된 소프트웨어로, 여러 분야에 두루 적용되는 범용 도구와 구별된다. - Linear의 목적은 팀이 더 나은 제품을 만들도록 돕는 협업형 이슈 추적·프로젝트 관리다. - 사용자가 각자 워크플로를 만들도록 유연성만 제공하면 조직이 성장할수록 방식이 제각각이 되어 혼란이 생길 수 있다. - 따라서 “무엇이든 가능한 도구”보다 “가장 좋은 기본 방식”을 제시하는 것을 중시한다. ## 원자적 단위에서 강한 기본값 만들기 - 프로젝트, 팀처럼 누구나 이해할 수 있는 일반적인 용어를 사용해 학습 곡선과 전문 용어 부담을 낮춘다. - 사용자가 매뉴얼을 읽지 않아도 바로 시작할 수 있도록 설계한다. - 반드시 하나의 정답만 강제하는 것이 아니라, 사용자가 자연스럽게 따를 수 있는 기본값을 제공한다. - 라벨과 마감일을 이슈의 속성으로 두는 것처럼, 세부적인 기능·구조에서는 강한 제품 의견을 적용한다. - 반면 프로젝트와 같은 상위 개념은 회사마다 조직 구조가 다르므로 고객 피드백을 더 적극적으로 반영한다. - 핵심 목표는 프로세스의 세부 사항을 끝없이 조정하는 시간을 줄이고, 실제 구축 작업에 빨리 진입하게 하는 것이다. ## 제품 부채를 전략적으로 감수하기 - 제품 부채는 단순히 잘못 작성된 코드인 기술 부채와 다르다. - 기능 범위나 완성도를 의도적으로 줄여 단기 목표를 달성하고, 나중에 사용자 피드백이나 추가 리소스라는 비용을 치르는 선택으로 본다. - 모든 기능을 처음부터 완벽하게 만들기보다, 사용자 경험에 미치는 영향과 “이자율”을 따져 부채를 선택적으로 감수한다. - Linear의 설정 화면은 기능, 환경설정, 섹션을 계속 추가해 왔지만 전체 경험을 재설계하지는 않은 사례다. - 설정 화면은 핵심 업무 흐름을 좌우하는 영역이 아니므로, 당장 전면 개편하지 않아도 비용이 비교적 낮다고 판단했다. - 여기서 말하는 지름길은 품질을 무조건 낮추는 것이 아니라, 초기 구현의 범위를 줄이는 방식에 가깝다. ## 강한 원칙도 계속 발전시키기 - 스타트업의 제품 개발은 고정된 레시피를 따르는 일이 아니라 실험과 반복의 과정이다. - 사용자의 반발이 두려워 기존 경험을 영원히 유지하면 제품이 변화할 수 없게 된다. - 사용자의 업무 흐름에 큰 영향을 주는 변경은 신중해야 하지만, 모든 기능을 절대 바꿀 수 없도록 만드는 것은 바람직하지 않다. - 강한 의견은 처음부터 완벽한 규칙으로 고정하는 것이 아니라, 실제 사용과 피드백을 통해 수정할 수 있어야 한다. - 즉, 원칙은 강하게 유지하되 구현과 사용자 경험은 필요에 따라 실험하고 바꿀 수 있어야 한다. 팀이 제품을 설계할 때는 모든 것을 자유롭게 설정하게 하기보다, 핵심 사용 사례에 맞는 명확한 기본값을 먼저 제공하는 것이 효과적이다. 다만 세부 기능에는 일관된 의견을 적용하되 조직 구조나 업무 방식처럼 회사마다 다른 영역은 고객 피드백에 열어 두고, 감수한 제품 부채는 장기적으로 상환할 계획을 함께 세우는 것이 좋다.

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

product-developmentproject-managementlinearissue-tracking+2

figma·2024년 5월 21일·3분 읽기큐레이션 요약

Code Connect의 잠재력 활용

디자인과 개발의 간극을 줄이려면 두 팀이 공유할 수 있는 언어와 단일한 작업 흐름이 필요하다. Figma의 Code Connect는 디자인 시스템의 컴포넌트 구현 정보와 문서를 Dev Mode에서 직접 제공해 개발자가 맥락을 바꾸지 않고 올바른 코드를 사용할 수 있도록 돕는다. 패널 참가자들은 작은 컴포넌트부터 시작해 점진적으로 도입하고, 디자이너와 개발자의 전문성을 서로 존중해야 한다고 강조한다. ## 디자인과 개발이 함께 쓰는 언어 만들기 - 디자이너와 개발자는 컴포넌트 이름, 속성, 구현 방식에 대해 서로 다른 용어와 기대를 가질 수 있다. - 이 차이는 다음과 같은 문제로 이어진다. - 일관되지 않은 네이밍 - 디자인과 코드의 속성 불일치 - 팀 간 요구사항과 구현 결과의 불일치 - 디자인 시스템은 공통 컴포넌트, 패턴, 용어를 정의해 두 분야를 연결하는 “제3의 언어” 역할을 한다. - 단순히 규칙을 문서화하는 것뿐 아니라, 구성원이 쉽게 찾고 실제로 적용할 수 있게 만드는 것도 중요하다. ## 단일한 기준과 개발자 워크플로 연결 - Bumble의 Raul Menezes는 디자인과 코드에서 서로 다른 기준 문서가 사용되는 것이 일관성 저하의 주요 원인이라고 설명한다. - 같은 UI 패턴을 반복해서 직접 구현하면 다음 문제가 발생한다. - 중복 코드 증가 - 커스텀 구현 확산 - 유지보수 어려움 - 디자인 시스템과 실제 제품 간의 불일치 - 디자이너는 디자인 시스템 문서를 참고하지만, 개발자는 별도의 코드 저장소나 문서를 기준으로 삼는 경우가 많다. - Code Connect는 디자인 시스템의 코드 예시와 구현 정보를 Dev Mode 안에서 제공해 개발자가 기존 코드 편집 및 개발 흐름에서 바로 참고하도록 설계됐다. ## 도입 장벽을 낮추고 작은 규모로 시작하기 - 디자인 시스템을 구축했다고 해서 자동으로 팀 전체가 사용하는 것은 아니다. 개발자가 기존 작업 방식을 크게 바꿔야 한다면 adoption이 느려질 수 있다. - 기존에는 개발자가 디자인 구현 방식을 확인하기 위해 별도의 디자인 시스템 웹사이트로 이동해야 했다. - Code Connect를 사용하면 Dev Mode에서 특정 디자인이 코드로 구현되어 있는지, 어떤 방식으로 구현하는지 확인할 수 있어 컨텍스트 전환을 줄인다. - 처음부터 모든 컴포넌트를 연결하기보다 영향도가 높고 구조가 단순한 컴포넌트부터 시작하는 것이 권장된다. - 예: 토글 같은 작은 컴포넌트 - 디자인 속성과 코드 속성을 어떻게 매핑하는지 먼저 검증 - 팀이 도구의 효과와 운영 방식을 익힌 뒤 범위 확대 - Code Connect는 완성된 최종 해법이라기보다 더 큰 디자인-코드 통합을 위한 첫 단계로 제시된다. ## 서로의 전문성 존중하기 - 디자인과 개발의 간극을 줄인다는 것은 한쪽의 방식을 다른 쪽에 강요하는 것이 아니다. - 디자이너는 사용자 경험, 시각적 일관성, 패턴 설계에 강점을 가진다. - 개발자는 컴포넌트 구조, 재사용성, 기술적 제약, 유지보수성에 전문성이 있다. - 효과적인 디자인 시스템 운영을 위해서는 두 팀이 각자의 전문성을 인정하고, 공통 언어와 도구를 통해 협업해야 한다. - Code Connect는 디자인 시스템의 의도와 실제 코드 구현을 연결해 양쪽의 지식을 공유하는 매개 역할을 한다. ## 실용적인 적용 방법 - 디자인 시스템에서 자주 사용되고 영향도가 큰 컴포넌트를 우선 선정한다. - 디자인의 컴포넌트 속성과 코드의 props·API가 어떻게 대응하는지 정의한다. - Dev Mode에서 개발자가 별도 문서 검색 없이 구현 예시를 확인할 수 있도록 연결한다. - 초기 도입 후 다음을 점검한다. - 개발자가 실제로 재사용 컴포넌트를 선택하는지 - 중복·커스텀 구현이 줄었는지 - 디자인과 코드의 명명 및 속성이 일치하는지 - 검증된 운영 방식을 바탕으로 점차 복잡한 컴포넌트와 더 넓은 제품 영역으로 확대하는 것이 바람직하다.

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

Figma디자인 시스템design-to-codedev-mode+2

figma·2024년 5월 21일·3분 읽기큐레이션 요약

파일 로드 속도 개선:

Figma는 파일 전체를 한꺼번에 불러오는 대신 사용자가 현재 보고 있는 페이지만 동적으로 로드해 파일 로딩 속도를 개선했다. 파일이 커져도 실제 사용자가 접근하는 콘텐츠의 복잡도에 비례해 로드하도록 설계한 결과, 가장 느린 5%의 페이지 로드 시간이 33% 감소했다. 핵심 과제는 페이지 간 컴포넌트·스타일·변수 참조 같은 의존성을 정확히 추적하면서 필요한 데이터만 전송하는 것이었다. ## 사용자 체감 복잡도에 맞춘 로딩 - Figma 파일은 여러 페이지, 컴포넌트, 라이브러리, 프로토타입 화면을 포함해 매우 커질 수 있다. - 하지만 사용자는 한 세션에서 파일의 모든 페이지를 탐색하지 않는 경우가 많다. - 따라서 파일 크기 전체가 아니라 현재 열어 본 페이지의 복잡도에 따라 로딩 시간이 결정되어야 한다. - 선택한 페이지만 먼저 표시하고, 다른 페이지는 사용자가 접근할 때 불러오면 초기 로딩 시간과 메모리 사용량을 줄일 수 있다. - Figma는 파일이 계속 커지더라도 로딩 성능은 지속적으로 개선되는 것을 목표로 삼았다. ## 페이지 간 읽기 의존성 - Figma 파일은 각 레이어와 속성을 가진 노드들의 트리 구조로 구성된다. - 노드는 다른 페이지에 있는 노드를 참조할 수 있으며, 이를 **읽기 의존성(read dependency)**이라고 부른다. - 예를 들어 인스턴스는 다른 페이지에 있는 원본 컴포넌트를 가리키므로, 올바르게 렌더링하려면 해당 컴포넌트 노드도 먼저 받아야 한다. - 스타일 역시 내부적으로 노드로 구현된다. - 특정 프레임이 `BrandPrimary` 색상 스타일을 사용하면 해당 스타일 노드를 로드해야 실제 색상값을 해석할 수 있다. - 변수도 같은 방식으로 동작한다. - 텍스트 크기에 `text-subheader` 변수를 적용했다면, 클라이언트는 변수 노드를 조회해 실제 값인 `16` 같은 원시 값을 확인해야 한다. - 따라서 단순히 현재 페이지만 로드해서는 부족하며, 렌더링에 필요한 다른 페이지의 참조 데이터까지 함께 찾아야 한다. ## QueryGraph 기반 동적 로딩 - Figma는 읽기 의존성을 메모리 내 그래프로 관리하는 **QueryGraph**를 구축했다. - QueryGraph는 의존 노드 간 연결을 추적하고, Figma의 멀티플레이어 시스템이 클라이언트에 어떤 데이터를 전송할지 결정하는 기반이 됐다. - 이 구조는 기존에 보기 전용 파일과 프로토타입의 동적 로딩을 구현하는 데 활용됐다. - 동적으로 불러오는 단위는 콘텐츠 유형에 따라 달라진다. - **Figma 캔버스:** 선택한 페이지를 먼저 로드하고, 추가 페이지는 필요할 때 요청한다. - **프로토타입 뷰어:** 한 번에 하나의 프레임을 표시하고, 사용자가 이동할 가능성이 있는 인접 프레임을 미리 로드한다. - 페이지를 로드할 때는 해당 페이지 자체뿐 아니라 다른 페이지에 존재하는 필수 컴포넌트·스타일·변수 노드도 QueryGraph를 통해 함께 전송한다. ## 동적 로딩의 효과 - 모든 페이지와 노드를 초기화하는 방식보다 불필요한 데이터 전송을 줄일 수 있다. - 사용자가 실제로 접근하지 않는 페이지를 메모리에 올리지 않아 메모리 사용량도 감소한다. - 큰 파일이라도 현재 작업 중인 페이지가 단순하다면 빠르게 캔버스를 표시할 수 있다. - 가장 느린 5%의 페이지 로드 시간이 33% 줄어드는 성과를 거뒀다. ## 실용적인 시사점 대규모 웹 애플리케이션에서는 전체 데이터를 일괄 로드하기보다 사용자의 현재 화면과 실제 접근 경로를 기준으로 로딩 단위를 정하는 것이 효과적이다. 다만 페이지 단위 지연 로딩을 적용할 때는 컴포넌트, 스타일, 변수처럼 화면 밖에 존재하는 참조 데이터까지 의존성 그래프로 추적해야 하며, 필요한 의존성만 정확히 함께 로드하는 설계가 중요하다.

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

Figma성능 최적화dependency-graphdynamic-loading+1

figma·2024년 5월 16일·3분 읽기큐레이션 요약

대규모 실시간 데이터를

Figma의 실시간 데이터 서비스 LiveGraph는 사용자와 쿼리 증가, 데이터베이스 샤딩으로 기존 구조의 한계에 도달했다. Figma는 초기 로컬 캐시와 단일 PostgreSQL의 전역 변경 스트림에 의존하던 아키텍처를 100배 규모까지 확장할 수 있도록 근본적으로 재설계하려 했다. 새 설계의 목표는 성능과 안정성을 유지하면서 데이터베이스 샤드와 읽기·업데이트 부하를 독립적으로 확장하고, 사용자 영향 없이 점진적으로 마이그레이션하는 것이다. ## LiveGraph의 역할 - LiveGraph는 GraphQL과 유사한 쿼리를 구독하는 웹 API를 제공한다. - 쿼리 결과를 JSON 트리로 반환하며, 객체와 관계를 정의한 스키마와 특정 그래프 일부를 조회하는 뷰를 사용한다. - Figma의 커스텀 React Hook을 통해 데이터가 변경되면 프런트엔드가 자동으로 다시 렌더링된다. - 캔버스 공동 편집, 댓글, FigJam 투표 등 여러 협업 기능에서 최신 데이터를 유지하는 기반 역할을 한다. ## 규모 증가로 드러난 문제 - 2021년 이후 LiveGraph 세션 수가 3배 증가했다. - 최근 1년 동안 뷰 요청 수는 5배 늘어났고, 세션 하나의 처리 비용도 점점 커졌다. - 데이터베이스 역시 단일 PostgreSQL 인스턴스에서 여러 수직·수평 샤드 구조로 변화하고 있었다. - 따라서 문제는 단순히 각 LiveGraph 서버가 데이터베이스 변경 사항을 모두 수집하는 데 그치지 않고, 클라이언트 세션·읽기 요청·데이터베이스 업데이트가 동시에 증가하는 복합적인 확장성 문제였다. ## LiveGraph 100x의 설계 목표 Figma는 현재의 읽기 및 데이터베이스 업데이트 부하를 장기적으로 100배까지 처리하기 위한 “LiveGraph 100x” 계획을 시작했다. - **서비스 속도 유지** - 초기 로드 시간과 실시간 업데이트에 대한 SLO를 유지하거나 개선해야 했다. - **데이터베이스 확장 지원** - 수직 확장뿐 아니라 수평 샤딩도 기본적으로 지원해야 했다. - 샤드가 늘어나도 신뢰성과 성능이 저하되지 않아야 했다. - **독립적인 확장 수단 확보** - 클라이언트 읽기량이 증가할 때와 쿼리 업데이트량이 증가할 때 서로 다른 구성 요소를 확장할 수 있어야 했다. - **안전한 점진적 마이그레이션** - 기존 LiveGraph 사용자를 중단시키지 않고 단계적으로 구조를 개선해야 했다. ## 초기 아키텍처와 변경 스트림 초기 LiveGraph는 단일 PostgreSQL과 하나의 서버를 중심으로 구성됐다. - PostgreSQL의 논리적 복제 스트림은 WAL에 기록된 행 단위 변경 사항을 전달한다. - 각 변경에는 행의 변경 전·후 이미지와 단조 증가하는 시퀀스 번호가 포함된다. - LiveGraph는 이 스트림을 추적해 데이터 변경을 실시간 업데이트로 재사용했다. - 모든 LiveGraph 쿼리는 기본 데이터베이스인 primary를 조회했다. - 서버 내부에는 인메모리 쿼리 캐시가 있었고, PostgreSQL의 각 행 변경이 발생할 때마다 관련 쿼리 결과를 직접 수정했다. - 즉, 캐시는 전체 결과를 다시 계산하기보다 개별 mutation을 결과에 반영하는 방식이었다. ## 단일 데이터베이스 구조의 한계 초기 구조에서는 데이터베이스가 하나였기 때문에 변경 스트림의 전역 순서를 가정할 수 있었다. - 모든 변경 사항이 하나의 PostgreSQL 인스턴스에서 생성됐다. - 따라서 LiveGraph는 하나의 전역적으로 정렬된 업데이트 스트림을 처리하면 됐다. - 하지만 단일 PostgreSQL 인스턴스가 용량 한계에 도달하면서 데이터베이스를 여러 수직 샤드로 나누게 됐다. - 여러 샤드가 동시에 변경 사항을 생성하면서 업데이트의 전역 순서가 더 이상 보장되지 않았다. - 기존의 “하나의 전역 순서 스트림”이라는 가정은 샤딩된 데이터베이스 환경에서 유지될 수 없었다. ## 재설계가 필요해진 이유 - LiveGraph는 데이터베이스 확장에 맞춰 변경 사항 수집과 캐시 갱신 방식을 바꿔야 했다. - 수직·수평 샤딩 환경에서는 여러 변경 스트림을 안정적으로 처리해야 한다. - 읽기 요청과 실시간 업데이트가 서로 다른 속도로 증가하므로, 전체 시스템을 한 방식으로만 확장해서는 효율적이지 않다. - Figma는 데이터베이스 용량 문제에 신속히 대응하면서도 기존 서비스의 성능과 안정성을 유지할 수 있는 전략적 변경이 필요했다. 실무적으로는 단일 데이터베이스의 전역 순서와 중앙 캐시에 의존하는 실시간 시스템이 초기에는 단순하고 효율적이지만, 샤딩 단계에서는 변경 순서·캐시 일관성·부하 분리 문제를 별도로 설계해야 한다는 점을 보여준다.

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

PostgreSQL분산 시스템GraphQLreal-time-data+4

figma·2024년 5월 8일·3분 읽기큐레이션 요약

장인정신과 아름다움

아름다움과 세밀한 완성도는 단순한 장식이 아니라 사용성, 전환율, 매출을 높이는 제품 경쟁력이다. Stripe, Linear, Figma의 리더들은 품질을 제품의 모든 접점에贯穿하는 문화로 정착해야 하며, 이를 위해 성능·명확성·직관성까지 포함한 전방위적인 노력이 필요하다고 말한다. 실제로 Stripe의 결제 제품은 평균 11.9%의 매출 증가를, 이메일 개편은 전환율 20% 향상을 이끌었다. ### 아름다움은 사용성과 전환율을 높인다 - 미적인 요소는 표면적인 꾸밈이 아니라 제품을 더 쉽게 이해하고 사용하게 만드는 기능적 요소다. - 사용자는 아름답고 명확한 제품을 더 잘 작동한다고 인식하는 경향이 있다. 이를 **미적 사용성 효과(aesthetic usability effect)**라고 한다. - 매력적이고 이해하기 쉬운 인터페이스는 사용자의 관심을 끌고, 다음 행동을 명확하게 하며, 성공적인 사용 경험으로 이어진다. - Stripe는 이메일의 문구, 시각적 계층 구조, 전체적인 사용 흐름을 개선했다. - 그 결과 해당 이메일 시리즈의 제품 전환율이 **20% 증가**했다. - Stripe Optimized Checkout Suite를 사용한 기업들은 평균적으로 **11.9% 더 높은 매출**을 기록했다. - 따라서 제품 여정의 모든 접점은 가치를 더하거나 빼는 요소가 될 수 있으며, 모든 단계에서 완성도를 관리해야 한다. ### 크래프트는 태도이고 아름다움은 결과다 - Linear의 Karri Saarinen은 두 개념을 구분한다. - **크래프트(craft)**: 결과물의 품질을 중요하게 여기는 작업 방식과 태도 - **아름다움(beauty)**: 그러한 태도가 만들어낸 사용자가 경험하는 품질과 결과 - 크래프트는 단순히 요구사항을 빨리 끝내는 것이 아니라, 결과가 충분히 좋은지 지속적으로 고민하는 자세다. - 아름다움은 외형만을 뜻하지 않는다. - 창문이 실제로 잘 열리는가 - 소음이 적은가 - 사용 과정이 자연스러운가 - 따라서 디자인의 가치는 시각적 매력뿐 아니라 기능성과 전반적인 품질을 포함한다. ### 성능과 완성도는 제품의 기본 조건이다 - Figma는 웹에서도 네이티브 애플리케이션과 같은 경험을 제공하는 것을 목표로 출발했다. - 이를 위해 프레임 레이트와 상호작용 성능 같은 기초 요소를 중요하게 다룬다. - 초당 60프레임 수준의 부드러운 상호작용이 무너지면, 그 위에 쌓이는 다른 디자인 요소도 제대로 경험할 수 없다. - 제품 품질에는 위계가 있다. - 먼저 성능과 안정성 같은 기반이 갖춰져야 한다. - 그 위에 직관성, 세심한 인터랙션, 시각적 아름다움을 쌓을 수 있다. - 최고의 완성도는 사용자가 특별히 의식하지 않아도 “모든 것이 자연스럽게 작동한다”고 느끼게 만든다. ### 크래프트는 조직 문화에서 시작된다 - 완성도는 특정 디자인팀이나 QA팀만의 책임이 아니라 회사 전체의 문화적 책임이다. - 구성원들이 품질을 중요하게 여기도록 별도의 목표나 OKR로 강제하기보다, 처음부터 품질에 관심이 있는 사람을 채용하고 육성해야 한다. - 크래프트는 사용자가 세부 사항을 자세히 보지 않더라도 경험 전반에 영향을 준다. - 성능, 문구, 시각 디자인, 인터랙션, 제품 흐름 등 여러 직군의 판단이 합쳐져 최종 품질을 만든다. ### 처음부터 끝까지 제품을 직접 점검하라 - Stripe는 문제를 발견하기 위해 **프릭션 로깅(friction logging)** 방식을 활용한다. - 엔지니어, 제품 관리자, 디자이너 등 여러 직군이 함께 실제 사용자처럼 제품을 처음부터 끝까지 사용한다. - 이러한 “매장 둘러보기(walking the store)” 방식으로 다양한 화면과 접점에서 불편함을 직접 찾는다. - 특정 팀의 화면만 개선하는 것이 아니라, 전체 사용자 여정에서 마찰과 품질 저하 지점을 확인하는 접근이다. - 제품의 모든 접점이 브랜드와 비즈니스 성과에 영향을 주므로, 엔드투엔드 관점의 검토가 필요하다. 제품의 아름다움은 장식이 아니라 성능, 명확성, 사용성, 세심함이 결합된 결과다. 따라서 기업은 단기적인 기능 출시보다 모든 팀이 품질을 당연하게 여기는 문화를 만들고, 실제 사용자 여정을 반복적으로 점검하는 방식을 도입하는 것이 좋다.

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

Figma사용자 경험프로덕트 디자인stripe+2

figma·2024년 4월 30일원문

피그마의 TypeScript (새 탭에서 열림)

피그마(Figma)는 자사의 모바일 렌더링 엔진의 핵심 언어였던 자체 개발 언어 'Skew'를 산업 표준인 TypeScript로 완전히 전환하는 데 성공했습니다. 과거 성능 최적화를 위해 도입했던 Skew가 팀 규모 확장에 따라 생산성 저해와 생태계 부재라는 한계에 부딪히자, 피그마는 일상적인 개발 흐름을 방해하지 않으면서도 자동화된 마이그레이션을 완수했습니다. 결과적으로 피그마는 성능 손실 없이 더 나은 개발 환경과 최신 JavaScript 생태계의 이점을 누릴 수 있게 되었습니다. ### 자체 개발 언어 Skew의 도입과 한계 * **성능 중심의 탄생:** 초기 피그마는 웹과 모바일 모두에서 프로토타입 뷰어를 구현하기 위해 Skew를 개발했습니다. 당시 Skew는 정적 타이핑과 더불어 상수 폴딩(constant folding), 가상 함수 호출 최적화(devirtualization) 등 고급 컴파일러 최적화를 통해 JavaScript보다 뛰어난 성능을 제공했습니다. * **확장의 걸림돌:** 하지만 팀이 커지면서 Skew는 신규 입사자의 적응을 어렵게 만들고, 린터(linter)나 정적 분석기 같은 현대적인 개발 도구 생태계를 활용할 수 없다는 단점이 부각되었습니다. * **기능의 부재:** async/await와 같은 현대적인 JavaScript 기능이 부족했고, 피그마 내부의 다른 코드베이스와 통합하는 데에도 높은 비용이 발생했습니다. ### TypeScript 전환이 가능해진 기술적 배경 * **WebAssembly(Wasm)의 보편화:** 2018년 이후 모바일 브라우저에서 WebAssembly 지원이 확대되었고, 2020년경에는 모바일에서도 안정적인 성능을 발휘하게 되었습니다. * **C++ 엔진으로의 교체:** Skew로 작성되었던 파일 로딩 등 핵심 성능 경로를 WebAssembly로 컴파일되는 C++ 엔진으로 대체함으로써, 나머지 로직을 TypeScript로 전환하더라도 전체 성능에 미치는 영향이 미미해졌습니다. * **팀 규모의 성장:** 개발 경험(DX) 개선에 전념할 수 있는 리소스를 확보할 만큼 팀이 성장하면서 자동화된 마이그레이션 도구 개발이 가능해졌습니다. ### 안전한 전환을 위한 3단계 자동화 프로세스 * **1단계 (Skew 작성, Skew 빌드):** 기존 빌드 프로세스를 유지하면서 Skew 코드를 TypeScript로 변환하는 트랜스파일러를 개발했습니다. 변환된 TypeScript 코드를 깃허브에 체크인하여 개발자들이 미래의 코드 모습을 확인할 수 있게 했습니다. * **2단계 (Skew 작성, TypeScript 빌드):** 개발자는 여전히 Skew로 코드를 짜지만, 실제 프로덕션 빌드는 트랜스파일러를 거친 TypeScript 코드로 진행했습니다. 이 과정에서 유닛 테스트를 통과시키고 타입 오류를 점진적으로 수정하며 안정성을 확보했습니다. * **3단계 (TypeScript 작성, TypeScript 빌드):** 특정 시점에 Skew 코드 생성을 중단하고 모든 Skew 소스 파일을 삭제했습니다. 이후 모든 개발자는 TypeScript를 직접 작성하게 되었으며, CI/CD 파이프라인도 TypeScript 기반으로 완전히 전환되었습니다. ### 실용적인 결론 및 시사점 피그마의 사례는 서비스 초기 성능을 위해 도입한 커스텀 기술이 성숙기에는 오히려 부채가 될 수 있음을 보여줍니다. 특히 대규모 코드베이스를 전환할 때는 **'점진적인 롤아웃'**과 **'자동화된 트랜스파일링'**이 핵심입니다. Skew와 TypeScript 간의 시맨틱 차이(예: 네임스페이스 초기화 순서 등)로 발생할 수 있는 런타임 오류를 방지하기 위해, 자체 컴파일러를 수정하여 제어권을 확보한 점은 기술적 난관을 극복한 훌륭한 전략으로 평가됩니다.

TypeScriptwebassemblymobile-developmentc-plus-plus+3

figma·2024년 4월 24일원문

C++ 빌드 시간 단축하기 (새 탭에서 열림)

피그마(Figma)는 C++ 코드베이스가 10% 증가할 때 빌드 시간이 50%나 급증하는 문제를 해결하기 위해, 컴파일러로 전송되는 데이터 양(바이트)을 줄이는 전략을 채택했습니다. 하드웨어 업그레이드나 캐싱만으로는 한계가 있음을 깨닫고, 불필요한 헤더 포함을 자동으로 찾아내고 방지하는 자체 도구인 'DIWYDU'와 'includes.py'를 개발하여 빌드 시간을 절반으로 단축했습니다. 결과적으로 빌드 시간의 핵심 지표가 전처리 후의 바이트 수에 비례한다는 점을 입증하며 대규모 개발 환경에서의 생산성을 확보했습니다. ### 헤더 포함 방식과 빌드 속도의 상관관계 * C++ 컴파일 과정에서 전처리기(Pre-processor)는 소스 파일에 포함된 모든 헤더 파일을 하나의 거대한 파일로 합치며, 이는 전이적 의존성(Transitive dependency)을 포함해 컴파일러가 처리해야 할 바이트 수를 기하급수적으로 늘립니다. * 피그마의 분석 결과, 실제 추가된 코드량보다 전처리 후 컴파일러로 전달되는 바이트 수의 증가 폭이 훨씬 컸으며, 이것이 빌드 시간 지연의 주요 원인으로 파악되었습니다. * 대형 파일에서 불필요한 헤더를 수동으로 제거하는 실험을 진행한 결과, 컴파일 바이트는 31%, 콜드 빌드 시간은 25% 감소하며 가설이 증명되었습니다. ### DIWYDU: 불필요한 헤더 제거 자동화 * 구글의 IWYU(Include What You Use)가 너무 엄격하여 적용이 어렵자, 피그마는 더 유연한 자체 도구인 DIWYDU(Don’t Include What You Don’t Use)를 개발했습니다. * 이 도구는 `libclang`의 파이썬 바인딩을 사용하여 추상 구문 트리(AST)를 분석하며, 특정 파일이 포함한 헤더에서 함수, 타입, 변수 등을 직접적으로 사용하는지 확인합니다. * 직접적인 의존성이 없는 헤더를 찾아내어 삭제하도록 플래그를 표시함으로써 모든 기능 브랜치에서 빌드 속도 저하를 방지합니다. * 다만, STL(표준 템플릿 라이브러리)의 프라이빗 헤더 구조나 `libclang` 파이썬 바인딩의 AST 노드 접근 제한(UNEXPOSED_EXPR 등)과 같은 기술적 한계는 존재합니다. ### includes.py를 통한 회귀 방지 및 측정 * 헤더를 실제로 사용하더라도 파일 크기가 너무 커서 빌드 속도를 늦추는 경우를 대비해, 전이적 바이트 수를 측정하는 `includes.py`를 구축했습니다. * Clang을 사용하지 않고 순수 파이썬으로 작성되어 실행 속도가 매우 빠르며(수 초 내외), CI(지속적 통합) 시스템에서 각 PR이 빌드 시간에 미치는 영향을 바이트 단위로 측정합니다. * 특정 PR이 컴파일 바이트 수를 과도하게 늘릴 경우 경고를 발생시켜 개발자가 전방 선언(Forward Declaration)을 사용하거나 헤더를 분리하도록 유도합니다. * 표준 라이브러리는 피그마 내부의 래퍼(Wrapper) 디렉토리를 통해 관리되므로, 표준 헤더의 바이트는 계산에서 제외하여 효율성을 높였습니다. C++ 프로젝트의 빌드 속도를 유지하기 위해서는 단순한 캐싱을 넘어 컴파일러가 처리하는 데이터의 총량을 관리해야 합니다. 불필요한 헤더 의존성을 제거하는 자동화 도구를 CI 파이프라인에 통합하고, '컴파일 바이트 수'를 성능 지표로 모니터링하는 것이 대규모 코드베이스의 개발 효율을 높이는 실질적인 방안이 될 수 있습니다.

CI/CDPythonc++static-analysis+4

figma·2024년 4월 17일·3분 읽기큐레이션 요약

The Long and Short of

Figma의 뉴스레터 「Find your framework」는 디자인 시스템 구축과 확산에 도움이 되는 Framework 행사 발표와 관련 콘텐츠를 소개한다. 핵심 메시지는 디자인 시스템이 단순한 UI 산출물이 아니라, 조직 전체가 사용해야 가치를 발휘하는 제품이라는 점이다. 이를 위해 기능 개발뿐 아니라 내부 마케팅, 교육, 데이터 기반 adoption 전략이 필요하다. ## Framework 행사에서 발표한 기능 - Figma의 가상 디자인 시스템 행사인 **Framework**에서 제품 개발자와 디자인 시스템 담당자를 위한 기능을 공개했다. - 주요 발표 내용: - **Code Connect**: 디자인 시스템의 컴포넌트와 실제 코드 구현을 연결해 디자이너와 개발자 간 협업을 지원한다. - **Typography variables**: 글꼴, 크기, 행간 등 타이포그래피 속성을 변수로 관리할 수 있다. - **Gradient variables**: 그라디언트 관련 값을 변수화해 일관된 스타일 관리와 변경을 돕는다. - **Library Analytics API**: 조직 내 라이브러리 사용 현황을 분석해 디자인 시스템 adoption을 높이는 데 활용할 수 있다. - 행사에서 진행된 라운드테이블과 전문가 Q&A를 통해 디자인 시스템 운영 사례와 실무 관점도 공유했다. ## 디자인 시스템을 제품처럼 운영하기 - 디자인 시스템을 조직의 필수 도구로 만들려면 단순히 좋은 컴포넌트를 만드는 것만으로는 부족하다. - 제품처럼 다음 요소를 관리해야 한다. - 사용자의 요구와 문제 파악 - 명확한 가치 제안 - 지속적인 개선과 업데이트 - 사용 현황과 피드백 수집 - 사용자에게 변화와 이점을 알리는 커뮤니케이션 - 디자인 시스템의 성공은 완성도보다 **얼마나 많은 팀이 실제 업무에서 사용하는가**에 달려 있다. ## 내부 마케팅과 사용 확산 - 디자인 시스템은 일관성, 효율성, 확장성을 약속하지만, 실제 효과는 조직 전체의 사용이 전제되어야 나타난다. - 담당자는 “사용하라”고 지시하기보다 각 팀이 얻는 구체적인 이점을 설득해야 한다. - 디자인·개발 작업 시간 단축 - 중복 작업 감소 - 제품 간 시각적 일관성 향상 - 변경 사항을 여러 화면과 플랫폼에 빠르게 반영 - 내부 구성원을 대상으로 명확한 adoption 전략을 세우고, 교육·문서화·사례 공유를 통해 지속적인 참여를 유도해야 한다. ## 디자인 시스템 입문 - 아직 디자인 시스템을 시작하지 않은 팀을 위해 기본 개념과 구축 방법을 소개하는 입문 시리즈를 제공한다. - 디자인 시스템은 재사용 가능한 컴포넌트, 스타일, 규칙, 가이드라인을 모아 제품 제작 방식을 표준화하는 체계다. - 이를 활용하면: - 반복적인 디자인 결정을 줄일 수 있다. - 팀 간 협업 방식이 통일된다. - 제품이 성장해도 일관된 경험을 유지하기 쉽다. - 디자인과 개발 사이의 구현 차이를 줄일 수 있다. ## 성장과 확장을 지원한 Carvana 사례 - 온라인 중고차 거래 기업 **Carvana**는 급격한 고객 수요 증가와 사업 확장에 대응하기 위해 디자인 시스템을 활용했다. - 디자인 시스템과 변수를 사용해 제품 전반의 디자인 세부 사항을 일관되게 유지했다. - 특히 변수는 색상이나 기타 디자인 속성을 중앙에서 관리하고 변경할 수 있게 해, 여러 화면과 제품 영역에 일관된 수정 사항을 적용하는 데 도움을 줬다. - 이는 디자인 시스템이 시각적 통일성뿐 아니라 빠른 성장과 운영 효율성을 뒷받침하는 기반이 될 수 있음을 보여준다. 디자인 시스템을 도입할 때는 컴포넌트 제작에만 집중하기보다, 실제 사용자를 위한 제품으로 정의하는 것이 좋다. 명확한 사용 가치와 교육·홍보 전략을 마련하고, 사용 데이터를 분석하며 지속적으로 개선해야 조직 전체에서 정착시킬 수 있다.

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

Figma디자인 시스템디자인 토큰API+2

figma·2024년 4월 15일·3분 읽기큐레이션 요약

Framework 2024

Figma는 디자인 시스템 구축보다 더 어려운 과제인 조직 전체의 도입과 활용을 지원하기 위해 Framework 2024에서 세 가지 기능을 공개했다. Code Connect는 디자인과 실제 코드 사이의 간극을 줄이고, 타이포그래피·그라디언트 변수는 디자인 토큰의 범위를 확장하며, Library Analytics API는 디자인 시스템 사용 현황을 측정하도록 돕는다. 결론적으로 Figma는 디자인 시스템을 만드는 도구를 넘어, 개발자 adoption과 조직 내 확산까지 지원하는 방향으로 발전하고 있다. ### 디자인 시스템의 핵심 과제: 조직 전체의 도입 - 디자인 시스템은 일관성, 효율성, 확장성을 제공하지만 실제 효과는 팀 전체가 이를 사용할 때 발생한다. - 시스템이 강력하고 정교해질수록 복잡성도 커지며, 디자이너와 개발자의 적극적인 참여를 이끌어내는 일이 어려워진다. - Figma는 변수, 테마와 상태 관리, 고급 프로토타이핑, Dev Mode 등을 통해 디자인과 코드의 연결을 강화해 왔다. - 이번 발표의 중심 목표는 디자인 시스템을 “구축”하는 데서 나아가 조직 전반에서 “채택”되도록 만드는 것이다. ### Code Connect: 디자인과 코드의 연결 - Code Connect는 Dev Mode에서 디자인 시스템 컴포넌트에 대응하는 실제 코드 스니펫을 제공한다. - 개발자는 별도의 문서나 저장소를 검색하지 않고 Figma에서 필요한 코드를 확인하고 복사할 수 있다. - 이를 통해: - 구현 시간을 줄일 수 있다. - 디자인과 코드의 불일치를 완화할 수 있다. - 개발자가 디자인 시스템 컴포넌트를 사용하는 진입 장벽을 낮출 수 있다. - 임의로 유사한 컴포넌트를 새로 만드는 일을 줄일 수 있다. - Organization 및 Enterprise 요금제에서 베타로 제공되며, React·iOS·Storybook을 지원한다. - 향후 더 많은 프레임워크와 플랫폼으로 지원 범위가 확대될 예정이다. - Bumble, GitHub, HP 등의 팀은 디자인 시스템과 실제 프로덕션 코드 사이를 연결하는 문제와 Code Connect의 활용 가능성을 논의했다. ### 타이포그래피 변수: 디자인 토큰의 확장 - 기존 변수 기능만으로는 디자인 시스템의 중요한 영역인 타이포그래피를 충분히 표현하기 어려웠다. - 타이포그래피 변수를 사용하면 글꼴 크기, 행간, 글꼴 스타일 등 타이포그래피 속성을 변수와 토큰 체계 안에서 관리할 수 있다. - 주요 활용 방식: - 폰트 스케일을 한 번 정의하고 전체 시스템에 일관되게 적용 - 플랫폼별 타이포그래피 설정 조정 - 반응형 또는 테마별 텍스트 스타일 관리 - WCAG 기준을 고려한 접근성 높은 스케일 구성 - 디자인 시스템의 색상과 간격뿐 아니라 텍스트 표현까지 체계적으로 관리할 수 있게 된다. ### 그라디언트 변수: 더 풍부한 시각 스타일 관리 - 그라디언트도 변수로 정의하고 재사용할 수 있도록 지원한다. - 여러 화면과 컴포넌트에서 동일한 그라디언트 스타일을 일관되게 적용할 수 있다. - 브랜드 테마나 모드별로 그라디언트를 교체하기 쉬워진다. - 변수 기반 관리로 디자인 시스템이 단순한 색상 팔레트를 넘어 더 표현력 있는 시각 언어를 다룰 수 있다. ### Library Analytics API: 디자인 시스템 사용 현황 측정 - Library Analytics API는 조직 내 디자인 시스템 라이브러리와 컴포넌트의 사용 데이터를 분석할 수 있도록 제공된다. - 디자인 시스템 관리자는 다음과 같은 질문에 답할 수 있다. - 어떤 라이브러리와 컴포넌트가 실제로 사용되는가? - 어느 팀이나 프로젝트가 디자인 시스템을 적극적으로 채택하는가? - 사용되지 않거나 개선이 필요한 컴포넌트는 무엇인가? - 정량적인 사용 데이터를 바탕으로 문서화, 교육, 컴포넌트 개선, 도입 전략을 세울 수 있다. - 디자인 시스템의 성공을 단순히 “만들었는가”가 아니라 “얼마나 사용되는가”로 평가할 수 있게 한다. ### 실용적인 결론 디자인 시스템 팀은 컴포넌트와 토큰을 만드는 데 그치지 말고, 개발자가 실제 코드로 쉽게 사용할 수 있는 경로와 사용 현황을 측정할 방법까지 함께 마련해야 한다. Code Connect로 개발자 경험을 개선하고, 타이포그래피·그라디언트 변수로 토큰 범위를 확장하며, Analytics API로 채택률을 추적하는 접근이 효과적이다.

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

Figma디자인 시스템React디자인 토큰+3