Techlist.io - 한국 테크 블로그 큐레이터

figma4분 읽기큐레이션 요약

디자인의 뉴딜 | Figma 블

Brian Chesky의 Airbnb 사례는 제품 관리자(PM) 중심의 조직보다 디자인이 제품과 비즈니스를 함께 이끄는 방식이 강력할 수 있음을 보여준다. 그러나 이 글은 PM의 종말을 선언하기보다, 디자인·제품·비즈니스의 역할과 협업 방식을 다시 정의해야 한다고 논의한다. 다섯 명의 디자인·제품 리더는 각자의 경험을 바탕으로 디자인 리더십의 가능성과 한계를 살펴본다. ## Airbnb 사례와 ‘디자인 중심 리더십’ - Brian Chesky는 Airbnb가 위기에 처했을 때 디자인을 단순한 시각적 개선이 아니라 회사 전략과 제품 방향을 결정하는 핵심 수단으로 활용했다고 설명했다. - 그의 발언에 따르면 새로운 세대의 디자이너는 엔지니어의 지시를 따르거나 PM에게만 의존하지 않고, 엔지니어와 동등한 위치에서 제품을 주도하게 된다. - 일부 디자이너는 제품을 넘어 회사 전체를 이끄는 역할까지 맡을 수 있다. - 궁극적인 목표는 직함이나 조직 구조가 아니라 사람들이 사랑하는 제품을 만드는 것이다. - 다만 현장에서 “Airbnb가 PM 조직을 없앴다”는 말이 과장되거나 단순화되어 퍼졌고, 글은 이 해석을 여러 리더의 관점으로 다시 검토한다. ## Julie Zhuo: 자신의 도메인을 깊이 이해하기 - 디자인 리더가 제품을 주도하려면 먼저 자신이 맡은 도메인과 사용자 문제를 깊이 이해해야 한다. - 디자인 역량만으로는 충분하지 않으며, 시장·비즈니스 모델·기술적 제약·조직의 목표까지 파악해야 한다. - 디자인이 영향력을 가지려면 결과물을 만드는 역할을 넘어 문제를 정의하고 우선순위를 정하는 역할로 확장되어야 한다. - 이는 PM의 역할을 단순히 제거하는 것보다, 각 직군이 제품 의사결정에 더 넓게 참여하도록 만드는 변화에 가깝다. ## Steve Johnson: 비즈니스 없는 디자인은 장식에 불과하다 - 디자인은 사용하기 좋은 인터페이스를 만드는 데 그치지 않고, 비즈니스 성과와 연결되어야 한다. - 제품의 성공을 위해서는 사용자 경험뿐 아니라 수익성, 성장, 운영 가능성, 회사의 전략적 목표를 함께 고려해야 한다. - 디자인이 비즈니스 맥락을 이해하지 못하면 아름답지만 실제 문제를 해결하지 못하는 결과물이 될 수 있다. - 따라서 디자인 리더는 비즈니스 언어로 자신의 판단을 설명하고, 제품 전략과 성과 지표에 책임을 져야 한다. ## Sho Kuwamoto: 중간 관리보다 창작과 제품에 집중하기 - 조직이 커질수록 관리 계층과 조정 업무가 늘어나지만, 이것이 반드시 더 나은 제품으로 이어지는 것은 아니다. - Kuwamoto는 불필요한 중간 관리와 복잡한 역할 구분을 줄이고, 사람들이 직접 제품을 만들고 판단하는 환경을 강조한다. - 디자이너와 제품 담당자가 문서와 승인 절차에만 매몰되지 않고 창의적 문제 해결에 집중해야 한다. - 중요한 것은 특정 직군의 권한을 확대하는 것이 아니라, 의사결정이 실제 제품을 만드는 사람과 가까워지는 것이다. ## Lenny Rachitsky: 좋은 PM이 어려운 이유 - PM은 일정 관리자가 아니라 사용자 문제, 비즈니스 목표, 기술적 가능성을 종합해 올바른 문제를 선택하는 역할을 해야 한다. - 좋은 PM은 팀 구성원에게 업무를 배분하는 데 그치지 않고, 모호한 상황에서 방향을 정하고 여러 직군의 관점을 통합한다. - 따라서 Airbnb의 변화가 모든 PM의 필요성을 부정하는 것은 아니다. - 문제는 PM이라는 직함 자체보다, PM이 불필요한 승인 단계나 조정 역할로 축소되는 조직 구조일 수 있다. - 뛰어난 PM은 디자인·엔지니어링·비즈니스가 함께 제품을 주도하도록 돕는 촉진자 역할을 한다. ## Yuhki Yamashita: 진행 중인 상태를 받아들이기 - 제품 개발은 처음부터 완성된 전략을 실행하는 과정이 아니라, 만들고 실험하고 배우며 방향을 조정하는 과정이다. - 리더는 모든 답을 미리 정하려 하기보다 현재 진행 중인 작업과 불확실성을 받아들여야 한다. - 디자인과 제품 전략 역시 고정된 문서가 아니라 실제 사용자의 반응과 팀의 학습을 통해 계속 진화한다. - 이를 위해서는 직군 간 신뢰, 빠른 피드백, 실패를 허용하는 문화가 필요하다. ## 역할보다 중요한 제품 중심의 협업 - 글이 제기하는 핵심 질문은 “PM이 필요한가”보다 “누가 제품 결정을 내리고, 그 결정이 사용자와 비즈니스에 어떤 결과를 만드는가”에 가깝다. - 디자인이 제품 전략을 이끌 수 있지만, 비즈니스와 기술을 이해하지 못하면 영향력은 제한된다. - PM 역시 디자인과 엔지니어링을 통제하는 역할이 아니라, 좋은 판단이 나오도록 팀을 연결하는 역할로 재정의될 수 있다. - 조직마다 제품의 성격과 성장 단계가 다르므로 Airbnb의 구조를 그대로 복제하기보다, 의사결정 권한과 책임을 팀에 맞게 설계해야 한다. 실무적으로는 PM 조직을 무조건 없애기보다, 디자이너·엔지니어·PM이 문제 정의부터 성과 측정까지 공동 책임을 지도록 하는 것이 현실적인 접근이다. 직함보다 중요한 것은 사용자와 비즈니스를 함께 이해하고, 빠르게 만들고 배우며, 제품에 대한 명확한 책임을 갖는 구조다.

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

디자인과 비즈니스의 접점 탐색하기: 에어비앤비 브라이언 체스키와의 대담 | 피그마 블로그

Airbnb의 브라이언 체스키는 디자인을 단순한 시각 작업이 아니라 사업 전략과 의사결정의 중심에 두어야 한다고 주장합니다. 그러나 회사가 성장하면서 Airbnb는 제품 관리자, 조직 분화, A/B 테스트 중심의 관습적인 운영 방식에 묻혀 초기의 창의성과 고객 중심성을 잃어갔습니다. 체스키는 2019년 위기를 자각한 뒤 애플의 디자인 중심 경영에서 회복의 실마리를 찾기 시작했습니다. ### 디자인을 기반으로 시작한 Airbnb - 체스키와 공동창업자 조 게비아는 RISD에서 만난 디자이너였고, 엔지니어 네이선 블레차르지크와 함께 회사를 세웠습니다. - “낯선 사람끼리 서로의 집에 머물 리 없다”는 통념과 “디자이너는 회사를 창업하지 않는다”는 편견을 동시에 깨야 했습니다. - Airbnb의 출발점은 디자인을 회사의 의사결정 테이블로 가져오는 것이었습니다. - 고객이 사랑하는 특별하고 매력적인 제품을 만드는 것이 회사의 핵심 철학이었습니다. ### 성장 과정에서 사라진 창의성 - 2019년 체스키는 회사가 처음의 비전과 달라지고 있다는 위기감을 느꼈습니다. - 회사는 약 10개의 큰 부문과 각 부문별 세부 조직으로 복잡하게 나뉘었습니다. - 제품 관리자 중심으로 운영되며 프로젝트가 지나치게 많아졌고, A/B 테스트가 풍부하게 실행됐습니다. - 인력이 늘고 프로젝트가 증가했지만 오히려 앱의 변화는 줄어들고 비용은 커졌습니다. - 체스키는 디자인의 창의적 과정에는 용기와 직관이 필요한데, 과학적 방법론과 효율 중심의 조직 구조 속에서 자신 역시 그 용기를 잃었다고 회고합니다. ### 디자이너가 경영에서 소외되는 이유 - 체스키는 엔지니어, 마케터, 재무·운영 전문가에 비해 디자이너가 CEO가 되는 경우가 드물다고 지적합니다. - 기업은 대체로 측정과 검증을 중시하는 과학적 방법론에 맞춰 조직됩니다. - 반면 디자인은 불확실성을 감수하고 새로운 방향을 선택해야 하므로 더 취약하고 용기가 필요한 영역입니다. - 디자인 리더가 경영에 참여하지 않으면 회사는 점차 기존 업계의 업무 방식과 조직 관행을 답습하게 될 수 있습니다. ### IPO를 앞둔 조직 개편의 딜레마 - 체스키가 문제를 인식한 시점은 Airbnb가 기업공개를 준비하던 2019년 말이었습니다. - 상장을 앞두고 회사를 근본적으로 재편하는 것은 위험했기 때문에, 문제를 알면서도 즉시 해결하기 어려웠습니다. - 그는 공동창업자들과 상황을 논의했지만 구체적으로 무엇을 바꿔야 할지 알지 못했습니다. - 이 시기에 애플 출신 크리에이티브 디렉터 히로키 아사이와 애플 디자인을 이끌었던 조너선 아이브를 만나며 새로운 전환점을 맞게 됩니다. ### 애플의 디자인 중심 경영에서 얻은 자극 - 체스키는 스티브 잡스가 애플에서 만들어낸 디자인 르네상스를 잊고 있었다고 말합니다. - 아사이와 아이브는 디자인을 제품의 한 기능이 아니라 회사를 운영하는 방식으로 설명했습니다. - 이 만남은 Airbnb가 다시 초기의 “마법”과 디자인 중심 철학을 회복하는 계기가 되었습니다. - 글의 핵심 문제의식은 디자인이 사업 실행 이후의 장식이 아니라, 제품 방향과 조직 운영을 함께 결정해야 한다는 데 있습니다. 회사가 커질수록 조직 세분화와 실험 지표만으로는 고객이 느끼는 제품의 가치와 독창성을 지키기 어렵습니다. 따라서 창업자와 경영진은 디자이너를 실행 조직의 구성원이 아니라 사업 전략을 함께 만드는 의사결정자로 참여시키고, 필요할 때는 성장 과정에서 굳어진 관행을 과감히 재검토해야 합니다.

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

당신의 업무 스타일, 별자

점성술은 개인의 운세를 보는 도구를 넘어, 자신을 이해하고 타인과 연결되는 사회적·협업적 경험으로 확장되고 있다. Figma의 FigStrology는 FigJam 파일의 스티키와 활동, 현재의 ‘우주적 조건’을 머신러닝으로 분석해 협업자의 점성술적 페르소나와 운세를 보여준다. 이 위젯은 점성술을 진지한 예언보다는 팀活动을 마무리하고 서로의 성향을 재미있게 돌아보는 장치로 활용한다. ## 점성술이 다시 주목받는 이유 - 점성술은 4,000년 이상 이어져 왔지만 전통적으로는 사랑, 진로, 삶의 방향을 개인적으로 상담하는 경험에 가까웠다. - 최근에는 점성술을 함께 소비하고 공유하는 문화가 성장했다. - 미국인의 29%가 점성술을 믿는다는 조사 결과가 소개되며, 이는 2022년 미국 Snapchat 이용자 비율보다 높다고 설명된다. - CHANI, Co–Star 같은 앱을 통해 수백만 명이 자신의 별자리와 운세를 확인한다. - 점성술은 사용자가 내용을 그대로 믿지 않더라도 자신을 돌아보고, “이 설명이 나와 맞는가?”를 생각하게 하는 가벼운 자기 탐색 도구가 될 수 있다. ## 인정받고 연결되고 싶은 욕구 - Jacky Huang은 코로나19 시기에 유튜브의 타로 리딩 영상을 보며 점성술과 타로에 관심을 갖게 됐다. - 운세와 별자리 해석은 자신도 미처 인식하지 못했던 면을 누군가가 말해주는 경험을 제공한다. - 사람들은 타인에게 인정받고, 자신의 이야기를 들어주며, 이해받고 싶어 한다. - 해석이 실제로 맞는다고 느껴질 때는 공감과 재미를 얻고, 맞지 않으면 가볍게 넘길 수 있다는 점도 점성술의 매력으로 제시된다. - Willy Wu는 불확실한 세상에서 같은 별자리를 가진 사람들이 있다는 사실이 소속감과 연결감을 준다고 설명한다. - 운세는 유머러스하면서도 현명한 조언처럼 느껴져, 믿음의 정도와 관계없이 심리적 안내 역할을 할 수 있다. ## Figma 커뮤니티에서의 점성술 활용 - Figma 사용자들은 점성술과 타로 같은 전통적 점술 도구를 협업 경험과 결합하고 있다. - Product Designer Danielle Baskin은 Figma로 사회적 타로 참여 공간인 **Moonlight**를 만들었다. - Moonlight는 타로를 예언의 수단이라기보다 성찰을 위한 새로운 사회적 의식으로 제안한다. - Figma가 2022년 말 공개한 페르소나 퀴즈에는 26,000명 이상이 참여했다. - 이러한 사례들은 Figma가 디자인·협업 도구를 넘어 자기 표현과 관계 형성을 위한 공간으로도 활용될 수 있음을 보여준다. ## FigStrology의 작동 방식 - FigStrology는 FigJam에서 사용할 수 있는 협업 위젯이다. - FigJam 파일 안의 스티키와 사용자의 활동을 분석해 고유한 점성술적 페르소나와 운세를 생성한다. - 현재의 ‘우주적 조건’도 결과에 반영해, 파일과 시점에 따라 다른 해석을 제공한다. - 머신러닝을 활용하지만 목적은 과학적 예측이나 실제 운명 판정이 아니라, 협업 과정에서 재미와 대화를 유도하는 것이다. - Jacky는 사용자의 행동과 활동을 분석해 결과를 보여주는 Photo Booth 위젯에서 아이디어를 얻었다. - 즉, FigStrology는 “이 FigJam 파일에서 우리가 어떻게 행동했는가”를 별자리와 페르소나라는 친숙한 형식으로 변환한다. ## 협업을 위한 가벼운 성찰 도구 - FigStrology는 협업 세션을 마무리하며 팀원들이 자신의 작업 방식과 팀의 분위기를 돌아보게 하는 용도로 제안된다. - 서로의 강점과 약점이 다르다는 점을 점성술적 언어로 재미있게 표현할 수 있다. - 결과를 절대적인 성격 진단으로 받아들이기보다, 팀원 간 대화를 시작하는 계기로 활용하는 것이 적절하다. - 개인의 행동 데이터를 바탕으로 결과를 만든다는 점에서, 일반적인 별자리 운세보다 해당 협업 상황에 맞춘 개인화된 경험을 제공한다. - 글의 후반부는 각 FigStrology 별자리에 반영되는 요소와 다양성을 강조하려는 제작 의도를 설명하는 부분에서 끝나 있어, 세부 기준 전체는 확인되지 않는다. 실용적으로는 FigStrology 같은 도구를 팀 평가나 의사결정에 사용하기보다, 워크숍 종료 후 아이스브레이킹·회고·친목 활동에 활용하는 것이 좋다. 결과를 정답이 아닌 대화의 출발점으로 삼을 때 협업 분위기와 자기 성찰을 함께 높일 수 있다.

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

존 마에다가 말하는 창의

AI는 창작자의 효율성과 가능성을 크게 높이지만, 동시에 누구나 비슷한 결과물을 빠르게 복제하게 만들어 창의적 직업을 위협할 수 있다. John Maeda는 AI가 반복적이고 지루한 작업을 대신하도록 활용하되, 인간은 효율적인 지름길이 아닌 더 어렵고 의미 있는 ‘오르막 사고(uphill thinking)’에 집중해야 한다고 주장한다. 창의성의 미래는 AI와 경쟁하는 데 있지 않고, AI가 잘하지 못하는 문제 정의·맥락 이해·새로운 방향 제시에 인간의 시간을 투자하는 데 있다. ## AI 시대의 창의성이 맞닥뜨린 역설 - AI는 창작자에게 전례 없는 효율성과 무한한 가능성을 제공한다. - 반대로 AI가 만든 결과물은 쉽게 반복·복제될 수 있어, 개성 없는 ‘규격화된 디자인’이 확산될 위험이 있다. - AI가 창작자의 작업을 대신할지, 창작자를 더 강력하게 만들지는 아직 양면적이다. - ChatGPT의 등장 이후 디자이너들은 AI와 협업하기 위해 프롬프트와 데이터셋, 모델 미세 조정 등 ‘기계의 언어’를 배우고 있다. - 그러나 AI를 활용해 만든 창작 방식은 창작자 본인이 없어도 재현될 수 있다는 점에서 기존의 창작자 중심 가치관을 흔든다. ## 기술을 독점하기보다 창작 도구로 공유하기 - Maeda는 1990년대 알고리즘으로 이미지를 만드는 독특한 방식을 개발했다. - 그는 자신의 비법을 독점하는 대신 MIT에서 오픈소스로 공개해 다른 사람들이 이를 바탕으로 새로운 창작을 하도록 했다. - MIT Scratch와 Processing 같은 프로젝트에도 참여하며, 코딩을 단순한 기술이 아니라 창의적 실천으로 바라보았다. - 이 관점에서는 창작자의 가치는 특정 기법을 숨기는 데만 있지 않고, 새로운 도구와 가능성을 만들어 공동체에 확산하는 데 있다. ## AI가 대신해야 할 일과 인간이 맡아야 할 일 - 컴퓨터가 잘하는 일은 대체로 다음과 같은 반복 작업이다. - 슬라이드와 목업의 다양한 버전 제작 - 이미지 리터칭 - 정형화된 결과물의 대량 생성 - 이런 업무를 AI가 맡으면 디자이너는 단순 실행보다 문제의 본질과 미래의 가능성에 집중할 수 있다. - Jessie Shefrin의 말처럼, 완벽한 해결책에 도달했을 때는 이미 문제가 바뀌어 있을 수 있다. - 따라서 현재의 문제를 더 빠르게 해결하는 것만큼, 앞으로 어떤 문제가 등장할지 탐색할 시간을 확보하는 것이 중요하다. ## 효율적인 지름길과 ‘오르막 사고’ - AI는 가장 짧고 효율적인 경로를 찾도록 설계되어 있다. - 수천, 수백만 개의 가능성을 빠르게 평가해 비용과 시간을 최소화하는 것이 AI의 강점이다. - 하지만 가장 효율적인 해답이 항상 가장 창의적이거나 영향력 있는 해답은 아니다. - 지나치게 효율적인 경로는 예상 밖의 발견, 실험, 우연한 영감을 제거할 수 있다. - 인간의 창의성은 때로 더 어렵고 느린 길을 선택하는 데서 나온다. 즉, 목적지에 곧바로 도달하기보다 일부러 ‘오르막길’을 택하며 새로운 의미와 가능성을 발견해야 한다. ## 디자이너가 AI 시대에 취할 태도 - AI를 인간의 창의성을 대체하는 경쟁자로만 보지 말고 협업 도구로 활용해야 한다. - 반복 작업을 자동화해 창작자가 더 높은 수준의 판단과 실험에 시간을 쓰도록 해야 한다. - AI가 만들어낸 결과를 그대로 받아들이기보다, 맥락·문화·사용자 경험에 맞게 비판적으로 해석해야 한다. - 기계가 쉽게 복제할 수 있는 산출물보다 문제를 새롭게 정의하고 방향을 제시하는 능력이 중요해진다. - 효율성만을 목표로 삼지 말고, 의도적으로 비효율적인 탐색과 실험을 허용해야 한다. AI는 디자인의 종말이라기보다 디자인 업무의 중심을 바꾸는 기술이다. 반복 작업은 AI에 맡기되, 인간은 문제 정의와 의미 부여, 예측할 수 없는 아이디어를 탐색하는 ‘오르막길’에 집중하는 것이 바람직하다.

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

디자인 시스템의 미래

디자인 시스템의 미래는 단순히 색상·간격 같은 값을 표준화하는 데서 나아가, 그 값의 의미와 사용 목적을 중심으로 설계하는 시맨틱 방식에 있다. 디자인 토큰과 Figma 변수는 디자인 결정을 여러 플랫폼과 코드에 일관되게 전달하고, 테마 변경과 동적 프로토타이핑까지 가능하게 한다. 따라서 변수는 디자인 시스템을 기록하는 도구를 넘어 디자인과 개발을 연결하는 핵심 기반으로 발전하고 있다. ## 디자인 시스템의 복잡성과 토큰의 필요성 - 시간이 지나면 제품 안에 동일한 목적의 색상·간격·타이포그래피 값이 중복되면서 디자인 시스템이 복잡해진다. - Google Maps는 제품에 700개가 넘는 색상이 사용되고 있음을 발견한 뒤, 이를 25개의 색조로 정리했다. - 축소된 색상 체계가 다시 무질서하게 늘어나지 않도록 디자인 토큰을 사용해 색상 팔레트를 문서화하고 배포했다. - 토큰은 색상, 숫자, 문자열, 테두리 반경, 크기, 글꼴 등 반복되는 디자인 결정을 표현하는 데이터다. - 특정 컴포넌트나 구현 방식에서 디자인 속성을 분리하므로 플랫폼에 종속되지 않고 여러 제품과 환경에서 재사용할 수 있다. - 예를 들어 모든 “나무” 요소의 색상을 변경해야 한다면, 개별 요소를 수정하지 않고 하나의 토큰만 바꿔 전체에 반영할 수 있다. ## 디자인 토큰에서 시맨틱 시스템으로 - 토큰은 디자인 결정을 코드나 특정 컴포넌트가 아닌 독립적인 값으로 관리해 일관성과 유지보수성을 높인다. - Salesforce는 2014년부터 여러 플랫폼과 소프트웨어에 동일한 디자인 원칙을 적용하기 위해 토큰을 활용한 사례로 자주 언급된다. - 토큰의 진정한 가치는 값 자체보다 값이 제품 안에서 어떤 역할을 하는지 표현하는 데 있다. - 예를 들어 단순히 `blue-500`처럼 색상 자체를 지정하기보다, `button-background-primary`처럼 사용 목적과 의미를 나타내면 테마나 브랜드가 바뀌어도 구조를 유지하기 쉽다. - 이런 시맨틱 접근은 디자인 시스템을 시각적 스타일 모음이 아니라 제품의 의도와 규칙을 표현하는 체계로 확장한다. ## Figma 변수의 역할 - Figma 변수는 디자인 속성과 프로토타이핑 동작에 재사용 가능한 값을 저장한다. - 색상, 숫자, 문자열 등 다양한 값을 한 곳에서 관리하고 여러 디자인 요소에 적용할 수 있다. - 기존 토큰의 사용 사례를 충족하면서도 값이 실제로 “변할 수 있다”는 점을 강조한다. - 변수는 디자인 시스템의 값을 중앙에서 관리해 반복 작업을 줄이고, 변경 사항을 여러 화면에 일관되게 적용한다. - 단순한 디자인 결정의 기록을 넘어 다음과 같은 기능을 지원한다. - 라이트·다크 모드와 같은 디자인 테마 전환 - 조건에 따른 프로토타이핑 로직 - 여러 플랫폼에 공유할 수 있는 재사용 가능한 값 관리 - 디자인과 코드 사이의 연결 강화 ## 디자인과 개발을 연결하는 기반 - Config 2023에서 Figma는 Dev Mode, 변수, 고급 프로토타이핑 기능 등을 공개하며 디자인에서 구현으로 이어지는 흐름을 강화했다. - 변수는 디자인 시스템이 디자인 파일 안에만 머무르지 않고 코드와 동일한 개념과 값을 공유하도록 돕는다. - 이후 공개된 Code Connect는 개발자가 실제 코드 컴포넌트와 디자인 컴포넌트를 연결하는 방향을 더욱 강화한다. - typography 및 gradient 변수, Library Analytics API 같은 기능은 디자인 시스템의 적용 범위를 넓히고 조직 전체의 사용 현황과 도입을 관리할 수 있게 한다. - 결과적으로 디자인 시스템은 디자이너만 관리하는 라이브러리가 아니라 디자인·개발·제품팀이 함께 사용하는 공통 언어가 된다. ## 실용적인 적용 방향 - 색상이나 간격 값을 무작정 늘리기보다 먼저 제품에서 각 값이 수행하는 역할을 정의한다. - 원시 값과 의미 기반 값을 구분해 관리한다. 예를 들어 `blue-500`과 `text-color-error`를 별도 계층으로 둘 수 있다. - 테마 변경 가능성을 고려해 컴포넌트에 구체적인 색상값을 직접 넣지 않는다. - 디자인 토큰을 코드와 공유할 수 있는 형식으로 관리하고, Figma 변수와 실제 구현 값의 동기화 방식을 마련한다. - 디자인 시스템의 성공 여부를 라이브러리의 크기보다 재사용성, 일관성, 코드와의 연결성, 조직 내 adoption으로 평가하는 것이 바람직하다.

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

쇼피파이가 앞서

Shopify는 점진적 개선보다 과감한 시도를 장려하며, 기존의 문서·회의·계획 방식을 의도적으로 흔들어 새로운 아이디어를 만든다. 핵심은 문제를 선형적으로 정리하기보다 시각적 도구와 협업 템플릿을 활용해 관점을 확장하고, 다양한 구성원이 전략적 의사결정에 참여하도록 하는 것이다. 이 방식은 제품 로드맵 수립부터 연간 계획, 대규모 브레인스토밍까지 적용된다. ## 문서 중심 사고에서 벗어나기 - 일반적인 로드맵 작성은 문서에 문제와 질문을 적고 동료에게 검토를 요청하는 방식이다. - Shopify의 Katarina Batina는 이런 방식이 습관에 머무를 뿐, 실제 문제나 더 큰 기회를 놓치게 할 수 있다고 지적한다. - 추상적인 비전 문구만으로는 해결하려는 문제와 기회를 명확히 파악하기 어렵고, 독창적인 아이디어가 나올 여지도 줄어든다. - FigJam 같은 시각적 협업 도구와 템플릿은 문제를 다양한 관점에서 바라보게 하며, 사고의 선형성을 깨뜨린다. - 로드맵 검토 과정에서 다음 요소를 명시적으로 정리할 수 있다. - 핵심 지표 - 주요 문제 - 제안하는 해결책 - 의사결정 원칙 - 핵심 가정 - 의존성 ## 계획하는 방식부터 설계하기 - 템플릿은 기존 프로세스를 바꾸는 데 그치지 않고, 프로세스가 부족한 영역에 구조를 제공할 수도 있다. - Shopify의 원격 중심 조직은 대면 모임에서 무엇을 논의해야 할지 정하기 어려웠기 때문에 연간 계획용 FigJam 템플릿을 도입했다. - 참석자들은 모임 전에 템플릿을 작성해 공통의 출발점을 만들고, 현장에서 논의한 내용을 실시간으로 업데이트했다. - 전략적 결정이 협업 보드에 바로 기록되므로, 회의 후 스티키 노트를 촬영하거나 별도로 정리할 필요가 줄었다. - 노트북을 사용하면서도 실제로 함께 토론하는 환경을 만들 수 있었고, 팀은 이를 가장 효과적인 계획 세션으로 평가했다. ## 시각적 언어로 의사결정 민주화하기 - Shopify에서는 디자인이 전략적 제품 결정을 논의하는 형식이며, Figma가 그 과정을 지원하는 핵심 도구로 활용된다. - 글쓰기 능력에 따라 아이디어 표현력이 좌우되는 문서 중심 회의의 한계를 보완할 수 있다. - 모든 사람이 자신의 비전을 긴 문서로 설명하기는 어렵지만, 이미지·링크·스크린샷·다이어그램을 활용하면 생각을 더 빠르고 명확하게 공유할 수 있다. - 특히 20명 안팎이 참여하는 대규모 회의에서는 시각 자료가 참여 장벽을 낮춘다. - 시각적 협업은 디자이너뿐 아니라 다양한 방식으로 사고하는 구성원도 아이디어를 제시하게 해 인재와 관점의 다양성을 확대한다. ## 도구보다 중요한 것은 기존 관습에 대한 질문 - Shopify의 접근법은 특정 도구를 도입하는 데만 초점을 두지 않는다. - “항상 문서로 시작해야 하는가”, “회의에서 누가 어떻게 발언해야 하는가”, “계획 결과를 어떤 방식으로 기록할 것인가” 같은 기본 가정을 다시 검토한다. - 익숙한 방식은 효율적으로 보일 수 있지만, 새로운 문제를 발견하거나 큰 아이디어를 발전시키는 데는 한계가 있을 수 있다. - 따라서 목적에 따라 문서, 시각 보드, 템플릿, 실시간 협업 방식을 조합해야 한다. 팀의 창의성을 높이려면 문서 작성 절차를 그대로 따르기보다 문제·기회·가정·지표를 시각적으로 펼쳐 놓고 논의하는 것이 유용하다. 또한 회의 전 사전 작성, 회의 중 실시간 편집, 이미지와 링크를 활용한 표현을 결합하면 원격·대규모 팀에서도 더 포괄적이고 실행 가능한 결정을 만들 수 있다.

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

피그마 오픈 베타 출시의

Figma의 Dev Mode 오픈 베타 사례는 출시일을 끝이 아니라 제품 생애의 첫날로 보고, 이후 2주를 집중적인 사용자 조사 기간으로 활용해야 한다고 주장합니다. 제품·마케팅·지원팀이 역할을 나누되 긴밀히 협업하면서 사용 데이터, 여론, 버그 및 개선 요청을 종합해야 합니다. 성공 여부는 사전에 정의한 핵심 지표와 기준선으로 판단하고, 얻은 피드백을 우선순위와 제품 개선으로 연결하는 것이 결론입니다. ## 출시 후 2주는 집중적인 사용자 조사 기간 - Dev Mode는 Figma 안에서 개발자를 위해 설계된 별도 작업 공간입니다. - 브라우저 인스펙터처럼 캔버스 위 요소를 확인하며 치수, 스펙, 에셋 등의 정보를 얻을 수 있습니다. - 오픈 베타 기간에는 2023년 말까지 모든 Figma 사용자가 무료로 이용할 수 있도록 해 대규모 사용 데이터를 확보했습니다. - 출시 후 2주 동안 다음을 확인하는 것이 목표였습니다. - 사용자가 실제로 Dev Mode를 사용하는가 - 어떤 기능이 유용하게 받아들여지는가 - 어떤 버그와 불편이 즉시 해결되어야 하는가 - 제품이 개발자 커뮤니티의 요구를 충족하는가 ## 제품·마케팅·지원팀의 역할 분담 - **제품팀** - 기능별 사용량과 사용자 행동을 추적했습니다. - 어떤 기능이 실제 워크플로에 사용되는지 분석했습니다. - **마케팅팀** - 소셜 미디어와 공개 반응을 통해 제품에 대한 전반적인 여론을 파악했습니다. - **지원팀** - 버그 신고, 개선 요청, 고객 문의를 집중적으로 수집했습니다. - 각 팀은 담당 영역을 나누었지만, 중요한 트윗이나 반복적으로 발생하는 문제를 공유하며 지속적으로 소통했습니다. - 제품 관리자는 여러 출처의 정보를 종합하고, 실행 항목의 우선순위를 정하며, 후속 조치를 조율하는 역할을 맡았습니다. ## 사전에 정의한 성공 지표 - Dev Mode의 **북극성 지표(north star metric)** 는 개발자 역할을 가진 주간 활성 사용자 중 Dev Mode를 사용하는 비율이었습니다. - 출시 전에 측정 기준과 대시보드를 준비해, 출시 전후의 변화를 비교할 수 있도록 했습니다. - 기준선이 없으면 수치가 좋은지 나쁜지 판단하기 어렵기 때문에, 베타 결과를 해석하려면 사전 벤치마크가 중요합니다. ## 기능 채택과 사용자 반응 측정 - **기능 채택** - Inspect 패널 - 변경 사항 비교(Compare changes) - 관련 링크(Related links) - 그 밖의 Dev Mode 기능별 사용률 - 기능별 사용량을 비교해 사용자가 가장 매력적으로 느끼는 기능과 활용도가 낮은 기능을 구분했습니다. - **도달률과 반응** - 소셜 미디어 게시물 노출 수 - 이메일 오픈율 - 제품 내부 메시지 노출 수 - 소셜 미디어의 긍정·부정 분위기 - Config 행사 중 실시간 청중 반응 - 단순히 사용자에게 도달했는지뿐 아니라, 어떤 기능이 관심과 기대를 유발했는지도 함께 살폈습니다. ## 버그와 개선 요청 수집 - 사용자가 겪는 문제를 파악하기 위해 다양한 접점을 활용했습니다. - Help Center 문서 조회 수 - 제품 내 피드백 버튼 제출 내용 - 고객 지원 티켓 - 여러 채널에서 들어오는 요청을 한곳에 모아 반복되는 문제와 우선적으로 해결해야 할 개선 사항을 파악했습니다. - 비공개 베타 기간에 개발자와 디자이너의 워크플로 및 고충을 인터뷰한 결과도 출시 후 분석의 기반으로 활용했습니다. - 이러한 사전 학습을 통해 핵심 기능을 수정하고, 협업 방식에 맞게 기능을 조정하며, 처음에는 예상하지 못했던 요구도 반영할 수 있었습니다. 출시를 성공시키려면 발표 당일의 화제성보다 이후 데이터를 어떻게 측정하고 피드백을 어떻게 실행으로 전환하는지가 중요합니다. 오픈 베타를 진행할 때는 담당 팀과 지표를 미리 정하고, 출시 전 기준선을 확보한 뒤, 사용량·여론·지원 요청을 통합해 빠르게 우선순위를 결정하는 것이 좋습니다.

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

프롭스의 공유 언어 |

컴포넌트와 props는 디자인과 코드 양쪽에서 사용되지만, 환경에 따라 의미와 목적이 달라질 수 있다. 같은 이름의 컴포넌트라도 디자이너는 시각적 일관성과 표현 방식을, 개발자는 렌더링·상호작용·데이터 처리를 중심으로 생각한다. 따라서 디자인과 개발의 협업을 개선하려면 용어를 단순히 통일하기보다 각 환경의 맥락과 차이를 함께 이해해야 한다. ## 디자인과 개발에서 달라지는 언어 - 컴포넌트는 재사용 가능한 요소이며, props는 컴포넌트가 표현될 수 있는 방식과 규칙을 정의한다. - 컴포넌트의 인스턴스는 원본 컴포넌트를 실제로 사용한 결과이며, props 값을 변경해 다양한 상태와 모양을 표현한다. - 디자인과 개발 모두 `boolean` 같은 개념을 사용하지만, 디자이너는 이를 주로 시각적 차이를 표현하는 수단으로 접한다. - Figma의 대표적인 prop 유형은 다음과 같다. - Variant: 컴포넌트의 변형 - Boolean: 표시 여부나 켜짐/꺼짐 상태 - Instance swap: 내부 인스턴스 교체 - Text: 텍스트 값 변경 - 개발자는 이러한 시각적 props 외에도 이벤트 핸들러, 데이터, 동작 제어 등 비시각적 속성을 함께 다룬다. - 같은 단어를 사용하더라도 서로 다른 의미를 떠올릴 수 있으므로, 용어의 일치만으로 공통 이해가 형성되지는 않는다. ## 버튼 사례에서 드러나는 차이 - Figma의 버튼은 시각적 일관성과 디자인 파일 안에서의 구현 방식이 중요하다. - 코드의 버튼은 시각적 표현뿐 아니라 렌더링 방식, 사용자 상호작용, 접근성, 이벤트 처리까지 포함한다. - 따라서 Figma의 `Button`과 코드베이스의 `Button`은 이름과 기본 개념은 같아도 실제 책임과 props 구성이 다를 수 있다. - 글의 사례에서는 Figma에 `Button`과 `IconButton` 두 컴포넌트가 있었지만, 코드베이스에는 버튼 관련 컴포넌트가 다섯 개 존재했다. - Figma의 두 컴포넌트는 코드베이스처럼 공통 primitive를 상속하지 않았다. - Figma에서는 코드와 같은 방식의 컴포넌트 상속이 존재하지 않는다. - 디자인 관점에서 모델링하기에 두 컴포넌트를 분리하는 편이 더 적절했다. - 크기와 색상 같은 props가 중복되었지만, 동기화가 어렵지 않고 일관성을 해치지 않아 허용할 수 있었다. - 반면 코드베이스의 버튼 컴포넌트는 더 많은 props와 기능을 제공했으며, Figma 컴포넌트에는 그중 일부만 반영되어 있었다. - 이는 디자이너와 개발자가 컴포넌트를 최적화하는 기준이 다르다는 점을 보여준다. - 디자이너: 시각적 표현, 디자인 시스템 내 일관성, 파일에서의 사용성 - 개발자: 구현 편의성, 재사용 구조, 상호작용, 데이터와 접근성 ## 공통 어휘를 만들 때 필요한 관점 - 디자인과 코드의 컴포넌트를 무조건 동일한 구조로 맞추기보다, 각각의 환경에서 컴포넌트가 수행하는 역할을 먼저 구분해야 한다. - 같은 이름을 사용하는 컴포넌트라도 실제 목적과 지원하는 props가 다르면 그 차이를 명시적으로 설명해야 한다. - 협업에서는 “이 prop이 존재하는가”보다 다음 질문이 중요하다. - 어떤 시각적 또는 기능적 문제를 해결하는가? - 디자인에서의 변화가 코드에서는 어떤 prop이나 상태에 대응하는가? - 코드의 비시각적 기능을 디자인 시스템에서는 어떻게 표현하거나 문서화할 것인가? - 서로 다른 용어를 사용하는 사실 자체는 문제가 아니다. 문제는 동일한 의미라고 가정한 채 대화하는 것이다. 디자인 시스템을 운영할 때는 Figma와 코드 컴포넌트의 이름을 가능한 한 연결하되, props 목록과 의미가 완전히 같다고 가정하지 않는 것이 좋다. 각 prop의 목적과 대응 관계를 문서화하고, 시각적 속성과 동작·데이터 속성을 구분하면 디자이너와 개발자 사이의 오해를 줄일 수 있다.

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

폴라 셰어의 놀

Paula Scher는 창의성이 완전히 새로운 아이디어를 발명하는 능력이라기보다, 기존의 생각과 영향들을 자유롭게 연결하고 재조합하는 ‘놀이 상태’에서 나온다고 말한다. 이를 위해서는 일상적인 활동으로 사고를 비우고, 디자인 역사와 다른 분야를 탐색하며, 실험할 수 있는 관계와 환경을 만들어야 한다. 또한 유행을 모방하기보다 스스로 새로운 흐름을 시작하는 태도가 중요하다. ### 1. 사고를 비우고 우연한 연결 만들기 - **의뢰인이나 협업자를 만나고 브리프를 읽은 뒤**, 곧바로 결과물을 만들려 하지 않는다. - 옷장 정리나 청소처럼 반복적이고 단순한 일을 하며 의식을 비우면 자유로운 연상이 가능해진다. - 창의성은 억지로 짜내기보다, 기존 개념 사이에서 새로운 조합을 발견하는 과정이다. ### 2. 디자인 역사를 폭넓게 흡수하기 - 디자인 역사책을 한 권씩 분석하기보다, 여러 권을 한꺼번에 펼쳐 전체 흐름을 본다. - 특정 이미지를 표시하거나 그대로 모방하려 하지 않고, 다양한 시대와 스타일을 직관적으로 경험한다. - 자료를 본 직후가 아니라 하루 정도 지난 뒤 작업을 시작하면 무의식적인 연상이 새로운 아이디어로 이어질 수 있다. ### 3. 제약적인 환경에서 스케치하기 - 병원 대기실, 교통 체증, 와이파이가 없는 비행기처럼 할 일이 없는 공간을 활용한다. - 작은 줄공책이나 냅킨에 좋은 펜으로 간단히 스케치한다. - 환경이 불편하고 자극이 제한될수록 생각이 자유롭게 방황하며 예상 밖의 아이디어가 나올 수 있다. ### 4. 자유롭게 실험할 수 있는 관계 만들기 - 디자이너의 창의성을 허용하는 클라이언트와 장기적인 관계를 유지한다. - Paula Scher는 뉴욕 퍼블릭 시어터와 29번째 시즌까지 협업하며 계속 새로운 시도를 이어갔다. - 신뢰가 쌓인 관계에서는 팀이 실패를 두려워하지 않고 놀이와 발명을 시도할 수 있다. ### 5. 팀의 작업 균형과 기대 수준 관리하기 - 팀원들이 다양한 프로젝트를 경험하도록 업무 구성을 조정한다. - 팀을 격려하고, 기존 아이디어에 의문을 제기하도록 유도한다. - 좋은 디자인의 기준을 높이는 것이 디자이너의 역할이며, 더 나은 작업은 다시 더 나은 작업을 만들어낸다. ### 6. 실험의 기회를 직접 확보하기 - 상업 프로젝트에서는 일정과 요구사항 때문에 자유로운 실험이 제한될 수 있다. - 프로보노 또는 거의 무보수에 가까운 프로젝트를 통해 새로운 표현 방식을 연습한다. - Scher는 이런 작업에서 오히려 가장 많은 발견을 했다고 말한다. ### 7. 도구와 관점을 바꾸기 - 컴퓨터 작업만 고집하지 말고 손으로 만들거나 다른 매체를 사용한다. - 서점, 박물관, 갤러리, 상점 등을 방문해 프로젝트와 직접 관련 없는 분야를 관찰한다. - 다른 분야의 시각적 언어와 물성을 접하면 익숙한 디자인 접근에서 벗어날 수 있다. ### 8. 영향받는다는 사실을 받아들이기 - 어떤 디자인도 완전히 독창적이거나 무에서 창조된 것은 아니다. - 자신의 작업이 다른 사람, 시대, 문화의 영향을 받았다는 점을 인정해야 한다. - 중요한 것은 영향을 숨기는 것이 아니라, 이를 자신만의 방식으로 결합하고 변형하는 것이다. ### 9. 무드보드와 유행의 모방 피하기 - 시장에 이미 존재하는 사례만 모은 무드보드는 결과물을 기존 제품과 조금 다른 수준에 머물게 할 수 있다. - 트렌드를 따라가기보다 장기간 유지할 수 있는 자신만의 작업 방식을 발전시킨다. - Scher는 기술과 유행이 바뀌어도 50년 동안 비슷한 창작 원칙을 유지해왔다. ### 10. 새로운 흐름의 출발점 되기 - 디자인 변화는 한 브랜드나 팀이 먼저 대담한 시도를 하면서 시작된다. - 다른 사람들이 뒤따르면 처음에는 혁신적이던 방식도 곧 평범해진다. - 기존 흐름을 따르기보다 스스로 새로운 ‘클러스터’를 시작하는 것이 창의적인 리더십이다. 실무에서는 프로젝트 시작 전 짧은 산책이나 반복 작업으로 사고를 비우고, 손 스케치와 다른 분야의 자료 탐색을 병행하는 것이 유용하다. 특히 팀이 안전하게 실험할 수 있는 관계와 별도의 실험 프로젝트를 마련하면 ‘놀이 상태’를 업무 속에서도 지속할 수 있다.

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

Thumbtack이 디자인

Thumbtack은 디자인 시스템 **Thumbprint**를 토큰, Atomic CSS, 컴포넌트의 3계층으로 구성해 유연성과 생산성을 함께 확보한다. 하위 계층일수록 세밀한 제어와 확장성이 높고, 상위 계층일수록 접근성·일관성·개발 생산성이 높아진다. 필요한 경우 각 계층 내부에도 추가 계층을 두어, 개발자가 일반적인 상황에서는 간편한 추상화를 사용하면서도 특수한 요구에는 더 낮은 계층으로 내려갈 수 있게 했다. ## 3단계 계층 구조 - **Thumbprint Tokens** - 시스템의 가장 낮은 추상화 계층이다. - 색상, 타이포그래피, 모서리 반경, 간격, 크기, 그림자 등 세부 디자인 속성을 변수로 정의한다. - 웹과 네이티브 클라이언트 모두에서 사용된다. - 가장 세밀하고 유연하지만, 이를 직접 조합해야 하므로 개발 생산성은 상대적으로 낮다. - **Thumbprint Atomic** - Thumbprint Tokens 위에 구축된 원자적 CSS 라이브러리다. - 개발자가 별도의 커스텀 CSS를 작성하지 않고도 UI를 구성할 수 있다. - 예를 들어 `aspect ratio` 클래스를 사용하면 YouTube나 Vimeo 같은 외부 미디어의 가로세로 비율을 일정하게 유지할 수 있다. - 토큰보다 생산성이 높지만, 완전히 자유롭게 스타일을 제어하는 것보다는 유연성이 낮다. - **Thumbprint Components** - 가장 높은 추상화 계층으로, 자주 사용하는 UI 패턴을 접근성까지 고려해 미리 구현한다. - 알림, 버튼, 날짜 선택기, 별점 등 공통 컴포넌트를 제공한다. - 개발자는 반복적인 UI 구현보다 핵심 제품 기능에 집중할 수 있다. - 제공되지 않는 컴포넌트가 필요하면 Atomic CSS를 사용해 직접 구성하고, 그보다 더 낮은 수준의 제어가 필요하거나 네이티브 환경이라면 디자인 토큰을 직접 사용할 수 있다. ## 계층에 따른 트레이드오프 - 하위 계층으로 내려갈수록: - 디자인 속성을 세밀하게 제어할 수 있다. - 새로운 제품 요구사항에 유연하게 대응할 수 있다. - 대신 구현과 유지보수에 더 많은 개발 노력이 필요하다. - 상위 계층으로 올라갈수록: - 접근성, 시각적 일관성, 개발 생산성이 높아진다. - 공통 UI를 빠르고 안정적으로 구현할 수 있다. - 대신 사전에 정해진 동작과 스타일이 많아져 특수한 요구에는 덜 유연할 수 있다. ## 계층 안의 계층 - 하나의 계층도 목적에 따라 여러 하위 계층으로 나눌 수 있다. - Thumbprint의 React 모달은 다음처럼 구성된다. - `ModalCurtain`: 시각적 스타일보다 사용성·기능에 집중한 낮은 계층 컴포넌트 - `Modal`: `ModalCurtain`을 기반으로 시각적 스타일과 일반적인 모달 사용 방식을 제공하는 상위 컴포넌트 - 대부분의 개발자는 바로 사용할 수 있는 `Modal`을 사용한다. - `Modal`이 지나치게 제한적일 때는 `ModalCurtain`으로 내려가 더 자유롭게 구성할 수 있다. - 이후 반복적으로 필요한 기능은 다시 상위 `Modal`에 추가해 시스템을 발전시킬 수 있다. ## 디자인 토큰의 다단계 추상화 - 디자인 토큰도 여러 단계로 상속·추상화할 수 있다. - Adobe Spectrum의 예처럼: - `button-cta-background-color` - `cta-background-color` - `blue-400` - 토큰이 구체적인 의미에서 일반적인 색상 값으로 이어지는 구조다. - 개발자는 자신의 상황에 적용 가능한 가장 높은 수준의 토큰을 사용하는 것이 일반적이다. - 이를 통해 제품별 요구에는 대응하면서도 디자인 언어의 일관성을 유지할 수 있다. ## 실용적인 적용 방향 Thumbprint의 방식은 모든 개발자가 가장 낮은 수준의 API를 직접 다루게 하는 대신, 기본적으로는 접근성과 생산성이 높은 컴포넌트를 제공하고 필요할 때만 Atomic CSS와 토큰으로 내려가도록 설계한다. 따라서 디자인 시스템을 만들 때는 단일 추상화 계층에 모든 요구를 담기보다, **일반적인 사용 사례를 위한 높은 계층과 예외적인 요구를 위한 낮은 계층을 함께 제공하는 구조**가 효과적이다.

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

새로운 진을 통해 놀이의

놀이와 호기심은 디자인 과정에서 새로운 아이디어와 해결 경로를 발견하게 하는 중요한 원동력이다. Figma와 It’s Nice That는 이러한 가치를 탐구하기 위해 디자인 에세이, 시각 작품, 참여형 활동을 담은 인쇄 잡지 **《The Playbook》**을 공동 제작했다. 이 잡지는 Config 2023에서 공개되어 반복, 협업, 실험적 사고를 실제로 경험하도록 구성되었다. ## 놀이를 디자인 과정에 활용하기 - 놀이(play)는 전시, 서체, 앱 등 다양한 디자인 작업에서 기존 접근법을 벗어나 새로운 가능성을 탐색하게 한다. - 정답을 빠르게 찾기보다 우연한 시도와 호기심을 통해 다음 아이디어로 이어지는 경로를 만든다. - Figma는 놀이를 학습과 연결하고, 협업 과정에서 서로 다른 생각을 연결해 새로운 아이디어를 얻는 방식으로 바라본다. ## 《The Playbook》의 구성 - 여러 편의 에세이와 시각 커미션을 묶어 놀이의 가치를 다양한 관점에서 보여준다. - Figma 최고제품책임자 Yuhki Yamashita는 끝없이 변화하는 작업 상태를 받아들이고 반복을 즐기는 방법을 다룬다. - 최고기술책임자 Kris Rasmussen은 엔지니어가 역할과 코드 경계를 넘어 협업하는 방식을 설명한다. - 창작자들의 인터뷰와 조언을 통해 무한한 가능성 속에서 “만약 이렇게 해보면 어떨까?”라는 질문을 시작점으로 삼는 방법을 제안한다. - 디자이너 Paula Scher는 오랜 경력을 바탕으로 스케치, 영향, 창작 습관 등에 관한 ‘놀이의 10가지 규칙’을 공유한다. ## 독자가 직접 참여하는 활동 - 잡지 자체에 독자로서 ‘온보딩’하는 활동이 포함되어 있다. - 퀴즈를 통해 자신의 회의 진행 스타일을 알아볼 수 있다. - “How might we?”라는 문구를 바탕으로 한 디자인 과제를 수행할 수 있다. - Shawna X는 ‘번뜩이는 아이디어’를 시각화했고, 해당 작품은 리소그래프 인쇄물로 제작되었다. - Manshen Lo는 Bruno Munari의 12단계 디자인 방법론을 자신만의 방식으로 해석했다. ## 인쇄물과 협업 방식 - 《The Playbook》은 A5 크기의 진(zine) 형태로 인쇄되었으며, 퇴비화 가능한 셀로판으로 포장되었다. - Yuhki Yamashita와 Kris Rasmussen의 글은 서로 마주 보는 A6 크기의 별도 진으로 구성되었다. - 디지털 콘텐츠가 아니라 물리적 인쇄물과 활동지를 결합해 독자가 직접 읽고, 보고, 기록하고, 실험하도록 설계했다. - Config 2023 참가자들은 행사 입장 시 잡지를 받아 현장에서 내용을 살펴볼 수 있었다. ## 실용적인 시사점 디자인 작업에서는 완성도와 효율만 추구하기보다 의도적인 실험과 반복의 시간을 확보하는 것이 좋다. 회의나 워크숍에 짧은 퀴즈, 제약이 있는 스케치, “How might we?” 질문 같은 놀이 요소를 도입하면 팀의 호기심과 협업을 촉진할 수 있다.

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

인수 테스트를 신세틱 모니터링으로 마이그레이션한 방법 (새 탭에서 열림)

Datadog의 프론트엔드 개발자 경험(Developer Experience) 팀은 Puppeteer 기반의 불안정한 인수 테스트 시스템을 자사 제품인 'Synthetic Monitoring'으로 전환하여 300명 이상의 엔지니어가 겪던 개발 병목 현상을 해결했습니다. 기존의 수동 스크립팅 방식에서 벗어나 사용자 상호작용을 기록하는 방식으로 전환함으로써 테스트 유지보수 비용을 대폭 절감하고 CI/CD 파이프라인의 안정성을 확보했습니다. 이 과정은 단순한 도구 교체를 넘어, 데이터 기반의 문제 식별과 점진적인 신뢰 구축을 통해 대규모 코드베이스의 테스트 문화를 개선한 사례입니다. ## 기존 Puppeteer 기반 테스트의 문제점 * **높은 불안정성(Flakiness):** 브라우저, 가상 그래픽 엔진, 네트워크 등 제어할 수 없는 외부 요인으로 인해 테스트 결과가 수시로 변하여 개발자들에게 혼란을 주었습니다. * **복잡한 구현 방식:** 버튼 하나를 클릭하기 위해서도 요소의 존재 여부와 활성화 상태를 수동으로 확인하는 스크립트를 작성해야 했으며, 특히 커스텀 드롭다운 같은 복잡한 요소는 구현 난이도가 매우 높았습니다. * **인프라 및 유지보수 부담:** 테스트 코드를 포함한 관련 인프라 코드가 10만 줄에 달했으며, 제품 업데이트 시마다 수동으로 테스트를 수정해야 했습니다. * **긴 실행 시간:** 테스트가 정교해질수록 CI 실행 시간이 늘어나, 가장 긴 작업의 경우 완료까지 약 35분이 소요되는 등 배포 속도를 저해했습니다. ## Synthetic Monitoring을 활용한 솔루션 구축 * **레코딩 기반 테스트:** 코드를 직접 작성하는 대신 실제 페이지 상호작용을 기록하는 방식을 도입하여 스크립팅의 번거로움을 제거했습니다. * **전용 CLI 개발:** CI 환경에서 테스트를 실행하고 결과를 확인할 수 있도록 `synthetics-ci`(이후 `datadog-ci`로 확장)라는 명령줄 도구를 개발했습니다. * **자동화된 워크플로우:** 이 도구는 코드베이스 내의 `.synthetics.json` 파일을 찾아 테스트를 트리거하고, 결과 ID를 폴링(Polling)하여 성공 여부를 사용자에게 가독성 있게 출력합니다. ## 대규모 조직의 성공적인 마이그레이션 전략 * **신뢰 및 데이터 기반 설득:** 정기적인 엔지니어 설문조사를 통해 인수 테스트가 가장 큰 고통임을 데이터로 입증하고, 상세한 문서화와 내부 발표를 통해 새로운 시스템의 이점을 전파했습니다. * **점진적 도입과 비차단(Non-blocking) 모드:** 초기에는 테스트 실패가 전체 빌드를 멈추지 않도록 비차단 작업으로 설정하고 PR 댓글로만 결과를 알림으로써, 개발자들이 시스템에 적응할 시간을 제공했습니다. * **책임 분담과 추적:** Jira를 통해 각 팀에 테스트 소유권을 할당하고 마이그레이션 진행 상황을 추적했으며, 기존 플랫폼을 한 번에 삭제하는 대신 단계적으로 폐지하여 리스크를 최소화했습니다. 이러한 전환 과정은 기술적인 도구의 변화뿐만 아니라, 대규모 조직 내에서 엔지니어들의 신뢰를 얻으며 협업하는 방식의 중요성을 보여줍니다. 새로운 도구가 기존의 고통을 실질적으로 해결해 줄 수 있다는 확신을 주고, 안정적인 전환 프로세스를 제공함으로써 1년여에 걸친 대규모 마이그레이션을 성공적으로 완수할 수 있었습니다.

datadog원문

인수 테스트를 신세틱 (새 탭에서 열림)

데이터독(Datadog)은 기존에 사용하던 Puppeteer 기반의 불안정한 인수 테스트 시스템을 자사 제품인 'Synthetic Monitoring'으로 전환함으로써 개발자 경험과 배포 효율성을 대폭 개선했습니다. 1년여에 걸친 이 마이그레이션 과정은 단순한 도구 교체를 넘어, 300명 이상의 엔지니어가 참여하는 대규모 코드베이스의 테스트 신뢰도를 높이고 유지보수 비용을 절감하는 성과를 거두었습니다. 결과적으로 팀은 더 빠른 피드백 루프를 확보하고 안정적인 지속적 통합(CI) 환경을 구축할 수 있었습니다. ### 기존 인수 테스트의 문제점과 한계 * **높은 불안정성(Flakiness):** Puppeteer와 Chromium 헤드리스 브라우저를 기반으로 한 커스텀 러너는 가상 그래픽 엔진과 네트워크 등 제어할 수 없는 외부 요인으로 인해 예기치 않은 테스트 실패가 잦았습니다. * **복잡한 구현 및 유지보수:** 버튼의 활성화 상태를 확인하고 클릭하는 등의 단순한 상호작용조차도 수동 스크립트로 일일이 작성해야 했으며, 제품 업데이트 시마다 수백 개의 테스트 파일을 직접 수정해야 하는 번거로움이 있었습니다. * **인프라 부하 및 실행 시간:** 테스트 규모가 커짐에 따라 CI 작업 시간이 35분 이상으로 늘어났고, 10만 줄 이상의 테스트 관련 코드와 인프라를 유지하기 위해 많은 리소스가 소모되었습니다. ### Synthetic Monitoring 기반의 해결책 도입 * **노코드(No-code) 방식의 테스트 생성:** 직접 스크립트를 작성하는 대신 사용자의 페이지 상호작용을 기록하는 방식을 채택하여 테스트 작성 난이도를 낮추고 직관성을 높였습니다. * **CI/CD 통합 도구 개발:** CI 환경에서 테스트를 트리거하고 결과를 수집하기 위해 `synthetics-ci`(이후 `datadog-ci`로 범용화) CLI를 개발했습니다. 이를 통해 `.synthetics.json` 설정 파일을 기반으로 테스트를 자동 실행할 수 있게 되었습니다. * **유연한 구성 관리:** API를 통해 테스트 결과 ID를 폴링하고 휴먼 리더블(human-readable)한 출력을 제공하여, 개발자가 CI 단계에서 문제를 즉각 파악할 수 있도록 설계했습니다. ### 대규모 조직을 위한 마이그레이션 전략 * **점진적 신뢰 구축:** 초기에는 테스트 실패가 배포를 막지 않는 'Non-blocking' 단계를 도입하여, 엔지니어들이 새로운 시스템에 익숙해질 수 있는 여유를 제공하고 PR 댓글로 결과만 공지했습니다. * **데이터 기반의 설문과 지원:** 분기별 엔지니어 만족도 조사를 통해 고충을 파악하고, 테스트를 가장 많이 보유한 팀들을 대상으로 직접적인 마이그레이션 지원과 교육 세미나를 진행했습니다. * **체계적인 추적과 일몰(Sunset) 전략:** 모든 마이그레이션 과정을 Jira 티켓으로 관리하며 팀별 담당자를 지정했습니다. 기존 플랫폼을 한 번에 제거하는 대신, 개별 테스트가 안정화될 때마다 단계적으로 폐쇄하여 리스크를 최소화했습니다. E2E(End-to-End) 테스트의 유지보수 비용과 불안정성으로 인해 생산성이 저하되고 있다면, 코드 기반의 무거운 테스트 프레임워크 대신 사용자 시나리오 녹화 기능과 CI 통합이 강화된 'Synthetic Monitoring' 류의 도구 도입을 검토해야 합니다. 특히 대규모 조직일수록 기술적 전환뿐만 아니라 문서화, 비차단적(Non-blocking) 테스트 운영 등을 통한 문화적 접근이 마이그레이션 성공의 핵심입니다.

figma3분 읽기큐레이션 요약

피그마 & 크롬북

Figma와 Google for Education은 Chromebook 기반 디자인·협업 도구를 미국과 일본의 K-12 교육 현장에 확대해 모든 학생이 디지털 창작 경험을 갖도록 하겠다고 밝혔다. 베타 프로그램을 통해 Figma와 FigJam이 문제 해결, 반복적 사고, 협업뿐 아니라 학생의 자신감과 소속감, 시각적 표현 능력을 높일 수 있음을 확인했다. 이에 따라 미국 전역의 K-12 학군에 무료 이용을 개방하고, Figma Enterprise 무료 제공과 글로벌 파트너십 확대를 추진한다. ## Chromebook 기반 교육 접근성 확대 - 기존에는 미국 내 50개 학군을 대상으로 베타 프로그램을 운영했다. - 포틀랜드처럼 규모가 큰 도시 학군부터 텍사스의 소규모 농촌 학군까지 포함했다. - 이제 미국의 모든 K-12 학군이 Figma를 무료로 이용할 수 있다. - 특정 연령대에 한정하지 않고 어린 학생까지 사용할 수 있도록 접근 범위를 넓혔다. - K-12 학군에는 학교 관리자와 교사가 학습 환경을 관리할 수 있는 무료 Figma Enterprise도 제공한다. - 관리자 제어 기능 - 사용 환경에 대한 가시성 - 수업 관리와 학생 안전 지원 - Chromebook 파트너십은 미국을 넘어 일본의 Google 학교를 시작으로 전 세계로 확대된다. ## Figma와 FigJam이 제공하는 학습 방식 - 학생들은 산업 현장에서 사용하는 디자인 도구를 활용하며 미래 역량을 기를 수 있다. - 문제 해결 - 반복적으로 개선하는 사고 - 협업 - 공감 능력 - Figma의 무한 캔버스에서는 다양한 자료를 한 공간에 결합할 수 있다. - 다이어그램 - 이미지 - 마인드맵 - 동영상 - 프로토타입 - 이를 통해 학생은 자신이 아는 내용을 글이나 시험만이 아니라 시각적 스토리텔링으로 표현할 수 있다. - 실제 수업에서는 비영리단체를 위한 디자인 콘셉트, 지방정부 서비스를 개선하는 앱 프로토타입 등을 제작했다. - FigJam은 수업 계획, 그룹 활동, 학습 가이드 등 교사와 학생이 함께 만드는 협업 공간으로 활용됐다. ## 학생의 목소리와 교실 공동체 강화 - 디지털 공간에서 스티커, 하이파이브, 이모트, 댓글 등을 활용해 학생들이 부담 없이 참여할 수 있었다. - 내성적이거나 말하기를 어려워하던 학생도 자신의 생각을 표현하며 수업에서 리더 역할을 맡게 된 사례가 소개됐다. - 원격 학습 이후 관계 형성을 갈망하던 학생들이 온라인 협업을 통해 실제 교우 관계를 발전시키기도 했다. - Figma와 FigJam은 단순한 제작 도구를 넘어 교실의 연결감과 소속감을 높이는 매개체로 작용했다. ## 신경다양성 학생을 위한 안전한 표현 공간 - 전통적인 발표나 글쓰기 방식이 불편한 학생도 자신의 아이디어를 시각적으로 드러낼 수 있다. - 특히 자폐 스펙트럼 학생에게 FigJam이 사회적 기술, 실행 기능, 자기 조절, 협업 능력 향상에 도움을 준 사례가 제시됐다. - 비언어적 학생도 디지털 작업을 통해 적극적으로 참여할 수 있었다. - 유연하고 접근성 높은 협업 환경이 학생의 다양한 표현 방식을 수용한다는 점이 강조됐다. ## 참여도와 미래 역량을 높이는 시각적 학습 - 시각 중심의 작업 방식은 학생들이 수업 내용을 더 현대적이고 흥미롭게 받아들이도록 돕는다. - 기존의 시험이나 서술형 평가 대신 다음과 같은 결과물로 학습 내용을 표현할 수 있다. - 인포그래픽 - 스토리보드 - 앱·서비스 프로토타입 - 학생은 Figma를 디지털 샌드박스처럼 활용해 자신의 방식으로 세상을 이해하고 결과물을 만들 수 있다. - 전통적인 수업에서 흥미를 잃었던 학생도 디자인 활동을 통해 학습 목적과 새로운 동기를 발견한 사례가 나타났다. - 일부 학생은 수업 밖에서도 자발적으로 Figma 프로젝트를 진행할 만큼 창작 활동에 몰입했다. 학교에서 Figma를 도입할 때는 단순히 디자인 기술을 가르치는 데 그치지 말고, 협업·발표·문제 해결·개별 표현을 결합한 프로젝트 기반 학습에 활용하는 것이 효과적이다. 또한 Enterprise의 관리 및 안전 기능을 함께 사용해 학생의 자유로운 창작과 학교 차원의 관리 체계를 균형 있게 운영하는 것이 바람직하다.

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

Config 2023 다시 보기 (새 탭에서 열림)

Figma는 Config 2023을 통해 단순한 디자인 도구를 넘어 디자인과 개발의 경계를 허물고 전체 제품 개발 팀이 함께 협업할 수 있는 통합 플랫폼으로의 진화를 선언했습니다. 이를 위해 개발자 전용 워크스페이스인 '개발 모드(Dev Mode)'와 코드의 논리를 디자인에 이식하는 '변수(Variables)', 그리고 실질적인 제품 작동 방식을 구현하는 '고급 프로토타이핑' 기능을 새롭게 도입했습니다. 이번 업데이트는 디자인 결과물이 실제 제품 코드로 전환되는 과정을 가속화하고, 팀 간의 소통 방식을 근본적으로 재정의하는 데 목적이 있습니다. ### 개발자 경험을 최적화하는 개발 모드(Dev Mode) * **개발자 전용 워크스페이스:** 무한한 캔버스 내에서 개발자가 작업에 필요한 구조와 기능을 직관적으로 파악할 수 있는 별도의 모드를 제공합니다. * **코드 번역 및 검사:** 디자인 요소를 코드로 더 빠르게 변환할 수 있으며, Jira, GitHub, Storybook과 같은 주요 개발 도구 및 코드베이스와 플러그인을 통해 직접 연결됩니다. * **VS Code 통합:** 'Figma in VS Code'를 통해 개발 환경을 벗어나지 않고도 에디터 바로 옆에서 디자인 파일을 검사하고 협업할 수 있습니다. * **배포 추적:** 어떤 디자인 요소가 프로덕션에 반영되어야 하는지 상태를 추적하여 디자인과 개발 간의 누락을 방지합니다. ### 디자인 시스템의 유연성을 극대화하는 변수(Variables) * **디자인 토큰의 코드화:** 색상, 숫자, 텍스트, 불리언(Boolean) 값을 변수로 저장하여 디자인 시스템을 코드의 언어와 일치시킵니다. * **모드(Modes) 지원:** 라이트 모드와 다크 모드, 혹은 다양한 테마 간의 전환을 변수 값을 통해 손쉽게 토글하며 테스트할 수 있습니다. * **확장성 있는 관리:** 에일리어싱(Aliasing) 및 스코핑(Scoping)을 지원하며, REST API와 플러그인을 통해 변수 생성 및 관리 프로세스를 자동화할 수 있습니다. ### 논리적 흐름을 구현하는 고급 프로토타이핑 * **조건부 로직 및 표현식:** "특정 변수가 X일 때 프레임 2로 이동"과 같은 조건문이나 수학적 표현식을 활용하여 실제 앱과 유사한 복잡한 상호작용을 구현할 수 있습니다. * **효율적인 프로토타입 제작:** 수많은 화면을 직접 연결할 필요 없이 변수를 활용해 동적인 변화를 줄 수 있어 프로토타입 제작 시간이 단축됩니다. * **인라인 프리뷰:** 디자인 편집 화면과 프로토타입 미리보기 화면을 동시에 띄워두고 수정한 내용을 즉각적으로 확인할 수 있어 반복 작업의 효율이 높아졌습니다. ### 워크플로우 개선을 위한 편의 기능(Quality of Life) * **오토 레이아웃 고도화:** 요소가 넘치면 다음 줄로 넘겨주는 '줄 바꿈(Wrap)' 기능과 최소/최대 너비 및 높이 설정 기능이 추가되었습니다. * **글꼴 선택기 업그레이드:** 글꼴 이름을 해당 서체로 미리 볼 수 있는 기능과 검색 및 필터링 기능이 강화되어 원하는 폰트를 더 빠르게 찾을 수 있습니다. * **파일 브라우저 업데이트:** 외부 팀과 공유된 프로젝트나 파일을 더 쉽게 찾을 수 있도록 인터페이스가 개선되었습니다. ### AI 기술을 통한 디자인의 미래 확장 * **Diagram 인수:** AI 기반 디자인 도구를 개발해온 Diagram을 인수하여 Figma 플랫폼 전반에 AI 기능을 통합할 계획입니다. * **창작 보조 및 가속:** AI가 시각적 표현을 돕고 워크플로우를 가속화하며, 누구나 수준 높은 초안을 만들 수 있도록 지원함으로써 디자인의 진입장벽을 낮추고자 합니다. Figma의 이번 업데이트는 디자이너와 개발자가 서로 다른 언어를 사용하는 문제를 해결하는 데 집중하고 있습니다. 개발 모드를 통해 개발자는 디자인 의도를 명확히 파악하고, 디자이너는 변수와 로직을 활용해 실제 제품에 가까운 설계를 할 수 있게 되었습니다. 팀의 생산성을 높이기 위해 현재 베타 버전으로 제공되는 개발 모드를 프로젝트에 적극적으로 도입하고, 기존 디자인 시스템을 변수(Variables) 기반으로 전환하여 다국어나 테마 대응 효율을 높여보시길 권장합니다.