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

figma4분 읽기큐레이션 요약

핸드메이드 웹을 위한 자리

작은 개인 웹사이트가 획일화·상업화된 인터넷에 새로운 가능성을 열고 있다. 저자는 웹사이트를 이력서나 포트폴리오처럼 완성된 목적지로 만들기보다, 개인의 취향과 상상력이 담긴 변화하는 공간으로 바라보자고 주장한다. 직접 웹사이트를 만드는 행위 자체가 더 개인적이고 표현적인 인터넷을 되살리는 방법이라는 결론이다. ### 상업화 이전의 개인적인 웹 - 1990년대 웹은 개인이 자신만의 디지털 공간을 소유하고 가꾸는 문화가 강했다. - GeoCities는 1994년 누구나 2MB 규모의 웹 공간을 만들 수 있게 했고, 한때 약 3,800만 개의 웹페이지를 호스팅했다. - 사이트들은 와인·음식, 기술 등 관심사별 “동네”로 묶였으며, 세련되지 않아도 개인의 개성과 공동체성이 드러났다. - 웹사이트는 단순한 정보 전달 수단이 아니라 자신을 표현하고 다른 사람과 연결하는 공간이었다. ### 효율성과 플랫폼이 만든 획일화 - 오늘날 웹사이트 수는 크게 늘었지만, 인터넷은 오히려 더 제한적이고 비슷해졌다. - 웹 제작 도구의 대중화는 접근성을 높였지만, 효율성과 표준화 중심의 디자인으로 손으로 만든 듯한 불완전함을 약화시켰다. - 소셜 미디어 플랫폼이 개인 홈페이지를 대신하면서 사용자는 정해진 형식과 알고리즘에 맞춰 자신을 표현하게 됐다. - 공개적인 자기표현에 대한 평가와 검열의 두려움 때문에 진솔한 표현이 사라지는 ‘인터넷의 어두운 숲’ 현상도 나타난다. ### 핸드메이드 웹의 부활 - Neocities는 GeoCities의 웹사이트를 보존하기 위해 시작했으며, 현재는 약 100만 개의 사이트를 호스팅하는 플랫폼으로 성장했다. - Rhizome, Center for Net Art, School for Poetic Computation 등은 인터넷 예술 전시와 워크숍을 지원한다. - DWeb 운동은 Internet Archive 등의 지원을 받아 더 분산되고 이용자가 소유하는 인터넷을 추구한다. - 이처럼 개인적이고 실험적인 웹은 사라진 것이 아니라 특정 커뮤니티와 프로젝트 안에서 계속 이어지고 있다. ### 웹사이트는 ‘홈페이지’가 아니라 변화하는 공간 - 웹사이트가 이력서, 포트폴리오, 블로그처럼 여러 기능을 동시에 수행해야 한다고 생각하면 제작 자체가 부담스러워진다. - 사이트는 반드시 실용적이거나 완성된 자기소개서일 필요가 없으며, 만든 사람의 소유와 취향을 담는 것만으로 충분하다. - 고정된 ‘집’이나 목적지보다 시간이 지나며 변하고 성장하는 공간으로 웹사이트를 바라볼 수 있다. - 짧은 기간 운영하거나, 한 가지 주제만 다루거나, 특정 한 사람에게만 공개하는 등 형식과 목적은 자유롭다. ### 시간의 제약을 가진 웹사이트 - 온라인 공간도 현실의 장소처럼 특정 시간에만 열리거나 사라질 수 있다. - B&H 카메라 매장은 종교적 휴일에 오프라인 매장과 웹사이트를 함께 닫는다. - `Cloudwatching`과 `Stargazing`은 각각 낮과 밤에만 접근할 수 있다. - `Internet Stoop`처럼 12시간만 존재하는 사이트나, 5일 만에 종료된 Reddit의 `The Button`처럼 일시적인 웹 경험도 가능하다. - 도메인 갱신과 유지보수에는 한계가 있으므로, 모든 웹사이트가 영원히 존재해야 한다는 생각도 재고할 수 있다. ### 찾기 어려운 웹사이트 - 검색엔진과 소셜 플랫폼의 최적화 경쟁에 반대해, 일부러 발견하기 어렵게 만드는 방식도 하나의 배포 전략이 된다. - `Black Room`은 알아보기 어려운 URL을 사용하고, `Default Filename TV`는 파일명을 바꾸지 않은 홈비디오를 모아 보여준다. - 이런 사이트는 검색 결과보다 링크를 따라 이동하는 ‘웹 서핑’ 과정에서 우연히 발견된다. - 쉽게 소비되는 콘텐츠가 아니라, 적절한 방문자가 직접 찾아냈을 때 의미가 생기는 인터넷 경험을 제공한다. ### 소유자와 작가가 사라진 웹 - 웹사이트를 만든 사람이나 원래 목적에서 분리해, 방문자가 의미를 투영하도록 만들 수도 있다. - JODI의 웹사이트는 ASCII 이미지와 미로 같은 구조를 통해 방문자가 오랫동안 탐험하게 한다. - SCP Foundation은 수천 명이 공동으로 fictional 세계관을 작성하며, 실제 조직처럼 보이는 허구의 웹사이트를 구축한다. - 웹사이트가 명확한 저자나 기능을 갖지 않아도, 미스터리와 상상력을 유발하는 도구가 될 수 있다. ### 직접 만드는 행위의 의미 - 핸드메이드 웹에 참여하는 가장 간단한 방법은 자신의 웹사이트를 직접 만드는 것이다. - 사이트의 규모나 완성도보다 개인적인 관점, 실험성, 지속 방식이 중요하다. - 수십 년 동안 가꿀 수도 있고 며칠 만에 끝낼 수도 있으며, 기술적·시적·공동체적 목적 모두 가능하다. - 하나의 플랫폼이 수많은 사람에게 맞춰지는 대신, 각자가 만든 수많은 웹사이트가 공존하는 인터넷을 상상할 수 있다. 자신만의 작은 웹 공간을 만들 때는 완벽한 홈페이지를 목표로 하기보다, 한 가지 관심사나 실험에서 시작하는 것이 좋다. 운영 시간, 접근 방식, 수명, 디자인을 일부러 제한하면 더 독창적이고 개인적인 웹 경험을 만들 수 있다.

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

이제 디자인의 정의를 확장할 때

디자인은 디자이너라는 직함을 가진 사람만의 업무가 아니라, 마케팅·제품·영업 등 다양한 직군이 시각적으로 문제를 해결하고 소통하는 과정이라는 것이 글의 핵심 주장이다. Figma는 전문 디자이너를 위한 도구라는 정체성을 유지하면서도, 모든 협업자가 자신 있게 디자인에 참여할 수 있도록 도구와 조직 문화를 확장해야 한다. 이를 위해 템플릿, 단순화된 기능, 브랜드 자산 관리와 승인 지원 같은 장치가 필요하다. ## 디자인의 경계를 넓혀야 하는 이유 - 오늘날 더 많은 사람이 일상 업무에서 디자인을 활용하고 있다. - 마케터, 제품 관리자, 개발자, 운영 담당자 등은 썸네일, 전단, 초대장, 소개 카드, 원페이저 등을 직접 제작한다. - 이들은 공식적인 디자이너는 아니지만, 정보를 시각적으로 전달하고 사용자의 관심을 끌며 협업의 품질을 높이는 역할을 한다. - 따라서 디자인은 직함이나 소속보다 실제로 문제를 시각적으로 해결하는 활동을 기준으로 정의해야 한다. ## 비디자이너가 느끼는 진입 장벽 - 비디자이너에게 Figma 파일은 전문 예술가의 갤러리처럼 느껴질 수 있다. - 무엇을 어떻게 만져야 할지 모르고 - 실수로 작업물을 망칠까 걱정하며 - 자신의 결과물을 전문 디자이너가 평가할까 부담을 느낀다. - 실제로 많은 비디자이너가 디자인 요청이 밀리는 상황을 해결하기 위해 직접 결과물을 만들지만, 자신이 도구를 “제대로” 사용하고 있는지 확신하지 못한다. - 도구 사용법의 문제뿐 아니라 “디자인은 전문가의 영역”이라는 조직 내 인식도 참여를 어렵게 만든다. ## 협업 도구가 만드는 소속감 - 회의나 팀 활동뿐 아니라 도구 자체도 조직 내 소속감을 형성할 수 있다. - Figma는 원래 디자이너를 위해 만들어졌지만, 협업자가 참여할 때 더 큰 가치가 발생한다. - FigJam, Dev Mode, Figma Slides 등은 마케팅 담당자, 개발자, 기타 협업자가 디자인 과정에 더 자신 있게 참여하도록 돕는다. - 다만 기능을 제공하는 것만으로는 충분하지 않으며, 누구나 디자인에 기여할 수 있다는 개인적·조직적 관점의 변화가 필요하다. ## 일상적 디자이너를 지원하는 방법 - 디자이너는 팀원이 쉽게 시작할 수 있도록 목적별 템플릿을 제공할 수 있다. - 더 많은 사용자가 접근할 수 있도록 복잡한 기능과 작업 흐름을 단순화해야 한다. - 비디자이너가 자주 겪는 문제를 제품 차원에서 해결할 필요가 있다. - 브랜드 가이드에 맞는 결과물 만들기 - 적절한 이미지와 디자인 자산 찾기 - 카피 문구를 수정하거나 발전시키기 - 검토와 승인 요청하기 - 새로운 사용자의 실력을 교육하고, 시도 자체를 인정하며, 성장한 결과를 적극적으로 격려해야 한다. ## 2025년의 디자인과 협업 - 업무 속도가 빨라지고 여러 업무 흐름이 동시에 진행되면서 협업 접점은 더욱 중요해지고 있다. - 마케팅과 제품 분야의 구성원도 자신의 업무가 디자인의 일부라는 점을 인식해야 한다. - 디자인 품질은 전문 디자이너의 결과물뿐 아니라, 조직 구성원 모두가 만드는 다양한 커뮤니케이션 자료에 의해 결정된다. - Figma는 전문성을 유지하면서도 더 넓은 사람들이 디자인에 참여할 수 있는 환경을 만들고자 한다. 실무적으로는 비디자이너에게 작업을 맡길 때 빈 파일보다 템플릿과 명확한 브랜드 규칙을 제공하고, 검토·승인 절차를 간소화하는 것이 효과적이다. 디자인을 특정 직군의 전유물이 아닌 조직 전체의 협업 역량으로 바라볼 때 더 빠르고 포용적인 결과를 만들 수 있다.

원문 읽기(새 탭에서 열림)
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년의 업무 방식은 더 많은 일을 하는 것이 아니라, 중요한 일에 집중하는 방향이어야 한다. 불필요한 문서와 절차는 자동화하고, 사용자의 첫 성공 경험을 앞당기며, 회의 목적을 구분하고, 디자인과 업무의 경계를 넘어 새로운 영감을 찾는 것이 실용적인 출발점이다.

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

원격 근무자의 효과적인 습관 (새 탭에서 열림)

사무실 출근이 주를 이루는 기업 환경에서 원격 근무자가 성공하기 위해서는 단순히 업무를 수행하는 것을 넘어, 의도적으로 자신의 존재감을 드러내고 팀과의 연결성을 유지하려는 노력이 필수적입니다. 10년 차 원격 근무 전문가인 저자는 물리적 거리감을 극복하기 위한 전략으로 '과잉 소통(Overcommunication)'과 화상 회의에서의 '실재감(Presence)' 구현을 핵심으로 꼽습니다. 이를 통해 원격 근무자는 보이지 않는 곳에서도 신뢰를 쌓고 팀의 핵심 구성원으로서 영향력을 발휘할 수 있습니다. **거리감을 극복하는 전략적 과잉 소통** * **빈번한 업데이트**: 공식적인 회의를 기다리지 말고 프로젝트 진행 상황, 주요 마일스톤, 업무 장애물(Blockers) 등을 메신저나 협업 도구를 통해 선제적으로 공유해야 합니다. * **공개적인 질문**: 물리적 사무실에서 동료에게 가볍게 묻는 것처럼 온라인에서도 질문을 망설이지 말아야 하며, 공개적인 채널에서 '단순한' 질문을 던지는 것을 두려워하지 않는 자세가 필요합니다. * **명확한 가용성 표시**: 업무 시간 내에는 메시지에 신속하게 응답하고, 캘린더에 식사 시간, 개인 용무, 집중 업무 시간 등을 상세히 기록하여 동료들이 언제 협업이 가능한지 즉각 알 수 있게 해야 합니다. * **글쓰기를 통한 목소리 전달**: 원격 근무자에게 글은 곧 자신의 인격과 목소리를 대신합니다. 명확하고 잦은 기록을 통해 자신이 팀에 몰입하고 있음을 보여주어야 합니다. **디지털 공간에서의 실재감(Presence) 구현** * **화상 회의 시 카메라 활용**: 비언어적 표현인 표정과 몸짓은 신뢰 구축의 핵심입니다. 고화질 카메라와 마이크를 사용하여 대화의 밀도를 높이고, 가상 배경보다는 실제 업무 공간을 보여줌으로써 전문성과 개성을 동시에 전달하는 것이 좋습니다. * **시선 처리와 태도**: 회의 중 다른 화면을 보지 않고 카메라를 응시하며 몰입하는 모습을 보여야 합니다. 이는 대면 대화에서 상대의 눈을 맞추는 것과 같은 중요한 예절입니다. * **능동적인 발언과 참여**: 회의를 주도하지 않더라도 의견을 적극적으로 공유하거나 질문을 던져야 합니다. 특히 사무실에 모여 있는 사람들 사이에서 목소리를 내기 위해 필요하다면 말을 가로채는 용기도 필요하며, 회의 노트를 요약하는 등의 역할에 자원하는 것도 좋은 방법입니다. * **전문적인 업무 환경 유지**: 카메라에 비치는 배경은 동료들이 나를 인식하는 물리적 지표가 됩니다. 가상 흐림 효과보다는 정리된 실제 벽이나 공간을 보여주는 것이 훨씬 더 자연스럽고 신뢰감을 줍니다. **관계 구축을 위한 선제적 접근** * 사무실에서는 복도나 카페에서 자연스럽게 이루어지는 유대감 형성이 원격 근무 환경에서는 불가능합니다. 따라서 동료들과의 관계를 쌓기 위해 더 사교적이고 외향적인 자세로 먼저 다가가는 노력이 필요합니다. 원격 근무의 성패는 '보이지 않는 곳에서도 팀과 얼마나 동기화되어 있는가'에 달려 있습니다. 사무실 출근자와 동일한 수준의 유대감을 형성하기 위해 더 자주 소통하고, 화상 회의라는 제한된 창구를 최대한 활용하여 자신의 존재감을 각인시키는 노력을 기울여 보시기 바랍니다.

datadog원문

리모트 워커의 효과 (새 탭에서 열림)

사무실 출근이 중심인 기업 환경에서 원격 근무자가 성공하기 위해서는 단순히 업무를 잘하는 것을 넘어, 의도적으로 자신의 존재감을 드러내고 연결성을 유지하는 노력이 필수적입니다. 물리적 거리를 극복하기 위해 평소보다 더 자주 소통하는 '과잉 소통(Over-communication)'을 실천하고, 가상 공간에서도 동료들이 본인의 존재를 실시간으로 느낄 수 있도록 전략적으로 행동해야 합니다. 결국 원격 근무의 한계를 극복하는 핵심은 기술적인 도구 활용을 넘어, 능동적인 관계 구축과 신뢰 형성을 향한 의도적인 태도에 있습니다. ## 거리감을 극복하는 과잉 소통 전략 * **수시 업데이트 및 투명성 확보**: 프로젝트의 진행 상황, 주요 마일스톤, 업무 차단 요소(blockers)를 공식 회의 전이라도 수시로 공유하여 팀원들이 본인의 업무 상태를 항상 인지하게 합니다. * **공개적인 질문과 답변**: 모르는 것이 있다면 공개 채널에서 질문하기를 주저하지 말아야 하며, 기록된 텍스트가 곧 본인의 목소리와 인격임을 인식하고 명확하게 글을 작성합니다. * **가용성 증명**: 근무 시간과 캘린더(점심시간, 집중 업무 시간 등)를 최신으로 유지하여 동료들이 언제 본인에게 연락할 수 있는지 알 수 있게 하고, 업무 시간 내에는 신속하게 응답하여 신뢰를 쌓습니다. ## 가상 회의에서의 존재감(Presence) 극대화 * **카메라 사용과 시선 처리**: 비언어적 소통을 위해 카메라를 항상 켜고, 상대방이 눈을 맞추고 있다고 느낄 수 있도록 카메라 렌즈를 응시하며 몰입하는 모습을 보입니다. * **적극적인 발언과 참여**: 회의 중 의견을 적극적으로 개진하거나 회의록 요약을 자처하는 등 참여 의지를 보이며, 사무실 근무자가 많은 회의에서는 소외되지 않도록 적절한 타이밍에 말을 끊고 들어가는 용기도 필요합니다. * **업무 공간의 전문성**: 본인의 업무 공간이나 가상 배경을 깔끔하게 관리하여 화면을 통해 전달되는 본인의 이미지를 의도적으로 관리합니다. ## 능동적인 관계 구축과 소통의 완급 조절 * **가상 커피 타임 활용**: 업무 외적인 유대감을 쌓기 위해 정기적인 1:1 가상 티타임을 제안하고, 팀 내 비업무용 메시지 스레드나 이벤트에 적극적으로 참여하여 본인의 성격을 드러냅니다. * **효율적이고 간결한 메시지**: 소통의 빈도는 높이되, 각 동료의 선호 방식을 존중하고 메시지는 명확하고 간결하게 작성하여 상대방에게 피로감을 주지 않도록 주의합니다. * **일관성을 통한 신뢰 형성**: 마감 기한 준수와 정기적인 체크인 등 예측 가능한 업무 습관을 유지함으로써 동료들이 '보이지 않아도 잘하고 있다'는 확신을 갖게 합니다. ## 정기적인 대면 만남의 전략적 활용 * **대면 활동의 우선순위 설정**: 분기별로 한 번은 사무실을 방문하여 팀원들과 직접 만나며, 이 기간에는 원격으로도 할 수 있는 회의보다는 면대면 토론과 대화에 집중합니다. * **비공식적 교류 기회 포착**: 방문 시에는 함께 커피를 마시거나 저녁 식사를 하는 등 비업무적인 대화를 나누는 시간을 확보하여 깊은 라포(Rapport)를 형성합니다. 원격 근무는 단순히 장소의 변화가 아니라 소통 방식의 완전한 전환을 의미합니다. '보이지 않으면 잊히기 쉽다'는 사실을 늘 염두에 두고, 본인의 업무 성과와 존재감이 사무실 구석구석까지 전달될 수 있도록 더 외향적이고 주도적인 태도로 협업에 임하시길 권장합니다.

figma3분 읽기큐레이션 요약

교실에서 창의력을 자극

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

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

Dev Box 즉시 코 (새 탭에서 열림)

마이크로소프트는 개발 환경 설정 및 유지보수 시간을 단축하여 개발자 생산성을 높이기 위한 Microsoft Dev Box의 팀 맞춤화(Team Customizations) 및 이미지 생성 기능을 발표했습니다. 이 기능은 마이크로소프트 내부의 1ES(One Engineering System) 팀이 구축한 'Ready to Code' 환경을 기반으로 하며, 현재 3만 5천 명 이상의 내부 개발자들이 이를 통해 표준화된 고성능 개발 환경을 사용하고 있습니다. 결과적으로 복잡한 설정 과정을 자동화하고 팀별 요구사항에 맞춘 유연한 환경 구축이 가능해짐에 따라 기업 전반의 엔지니어링 효율성이 크게 향상될 것으로 기대됩니다. **Ready to Code 환경의 구현과 기술적 이점** * **보안 강화**: Azure 관리 ID(Managed Identity)를 활용하여 이미지 생성 과정에서 필요한 자산에 안전하게 접근하며, 승인된 소스의 아티팩트만을 사용하여 검증된 환경을 구축합니다. * **성능 최적화**: Dev Drive를 사전 구성하고, 보안을 유지하면서도 개발 성능에 최적화된 Windows Defender 설정을 적용하여 빌드 및 작업 속도를 높입니다. * **일관성 및 신뢰성**: 스마트 기본값(Smart Defaults)을 제공하는 템플릿을 통해 팀 간 환경 편차를 줄이고, "내 PC에서는 잘 된다"와 같은 파편화 문제를 해결합니다. * **유지보수 편의성**: Azure Bicep을 사용하여 이미지 정의를 코드화함으로써 복잡한 로직을 모듈화하고, Azure Pipelines를 통해 이미지 업데이트 및 트러블슈팅을 간소화합니다. **1ES 팀의 이미지 관리 및 배포 전략** * **엄격한 테스트**: 템플릿 업데이트 시 PR 완료 전 테스트 이미지를 빌드하고, 실제 고객 환경을 모방한 대규모 이미지 세트를 생성하여 안정성을 검증합니다. * **단계적 출시**: 내부 도그푸딩(Dogfooding)을 시작으로 단계별 릴리스를 진행하며, Bicep 모듈 레지스트리의 경로 태그를 활용해 릴리스 단계를 구분하고 긴급 패치를 신속하게 배포합니다. * **중앙 집중식 개선**: 1ES와 같은 중앙 엔지니어링 팀이 템플릿을 관리함으로써, 회사 전체의 'Ready to Code' 환경에 개선 사항을 일괄적으로 적용할 수 있습니다. **외부 확산 및 실용적인 활용 예시** * **샘플 템플릿 제공**: 마이크로소프트는 내부 템플릿의 핵심 기능을 오픈 소스 저장소(MSBuildSdks, eShop, Axios 등)에 적용해 볼 수 있는 샘플과 가이드를 공유했습니다. * **자동화된 워크플로우**: Git 저장소 복제, 패키지 복원, 빌드, 데스크톱 바로가기 생성 등을 선언적으로 정의할 수 있으며, MSBuild 및 dotnet 프로젝트를 기본적으로 지원합니다. * **이미지 체이닝**: 기본 이미지를 기반으로 파생 이미지를 만드는 '이미지 체이닝' 기능을 통해 반복적인 빌드 시간을 줄이고 효율적인 이미지 계층 구조를 설계할 수 있습니다. * **스마트 환경 설정**: 윈도우 OS 최적화, 긴 경로(Long Path) 활성화, 불필요한 저장소 기능 비활성화 등을 통해 개발 시나리오에 최적화된 환경을 자동으로 구성합니다. 개발 팀은 제공된 Azure Bicep 모듈과 샘플 파이프라인을 활용하여 자신만의 'Ready to Code' 환경을 구축하는 것을 권장합니다. 이를 통해 인프라 설정에 소요되는 리소스를 최소화하고 코드 작성에 더 집중할 수 있는 환경을 마련할 수 있습니다.

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의 변경된 패널 시스템에 익숙해진다면 더 넓은 작업 영역에서 창의적인 업무에 몰입할 수 있을 것입니다.

figma3분 읽기큐레이션 요약

파블로 산체스의 예기

Ableton Note의 디자이너 Pablo Sánchez는 예상 가능한 관행을 따르기보다 개인적 확신과 다양한 분야의 영감을 바탕으로 낯선 경험을 설계해야 한다고 주장한다. 좋은 디자인은 객관적 분석만으로 만들어지는 것이 아니라, 디자이너의 취향과 경험이 사용자에게 진정성 있게 전달될 때 힘을 얻는다. Note는 복잡한 음악 제작 도구 대신 손으로 소리를 만지고 즉시 실험하는 경험을 제공함으로써 이러한 철학을 구현했다. ## 1. 자신을 위해 디자인하라 - 디자이너가 실제로 가장 잘 아는 사용자는 자기 자신이므로, 개인적 확신에서 출발해야 한다. - 모든 사용자의 요구를 객관적으로 맞추려다 보면 제품의 독창성과 방향성이 약해질 수 있다. - Pablo는 Note에 기존 음악 앱에서 흔히 볼 수 있는 MIDI 편집기를 넣는 대신, 모바일의 즉각적이고 촉각적인 특성에 맞춘 악기 인터페이스를 제안했다. - 사용자 테스트를 통해 이 방향이 검증되었고, Note는 MIDI 편집기 없이 출시되었다. - 16개 패드로 리듬을 두드리고, 멜로디와 코드 진행을 연주하며, Session View에서 변주를 만들 수 있다. ## 2. 브레인스토밍 단계에서는 레퍼런스를 배제하라 - 처음부터 다른 제품이나 디자인 사례를 참고하면 이미 존재하는 해결책의 틀 안에서 사고하게 된다. - 외부 레퍼런스 없이 자신의 경험과 기억에서 출발하면 더 독특한 아이디어를 만들 수 있다. - 과거에 접한 여러 요소가 무의식적으로 결합되는 ‘집단적 의식(plural consciousness)’을 신뢰해야 한다. - Pablo는 Samplr와 Borderlands Granular 같은 음악 앱의 영향을 받았지만, 이를 직접 모방하지 않고 본질적인 감각만 Note에 녹였다. - 브레인스토밍 단계에서는 모호함을 허용하고, 구체적인 결과물을 너무 일찍 확정하지 않는 것이 중요하다. ## 3. 디자인 바깥에서 영감을 찾아라 - 디자인 사례만 보는 대신 문학, 춤, 자연, 과학, 동물, 개인적 기억 등 다양한 영역에서 영감을 얻어야 한다. - 다른 분야의 감정과 구조를 디자인 문제에 적용하면 예측하기 어려운 새로운 관점이 생긴다. - Note는 기타를 집어 들고 즉흥적으로 연주하는 듯한 즉각성을 모바일 UX의 목표로 삼았다. - 장식을 덜어내고 재료 자체를 강조하는 브루탈리즘 건축의 시각 언어도 참고했다. - 그 결과 Note는 복잡한 음악 제작 기능을 숨기고, 사용자가 소리를 직접 만지고 조작할 수 있는 단순한 인터페이스를 제공한다. - 휴대폰 마이크로 소리를 녹음하고 시각화하는 샘플러 역시 이러한 직접성과 탐구성을 강화한다. ## 4. 내일을 위해 디자인하라 - Anthony Dunne과 Fiona Raby는 디자인을 ‘긍정적 디자인(affirmative design)’과 ‘비판적 디자인(critical design)’으로 구분한다. - 긍정적 디자인: - 현재 세계의 문제를 해결한다. - 현실에 대한 답을 제시하고 소비를 촉진한다. - 비판적 디자인: - 아직 드러나지 않은 문제를 제기한다. - 현재와 다른 세계가 어떻게 가능할지 질문하게 만든다. - 예상 밖의 디자인은 두 접근법 사이에 위치한다. - 새로운 가능성을 상상하게 한다. - 사용자가 기존 현실을 당연하게 받아들이지 않고 탐구하도록 자극한다. - 현재의 조건을 반복하기보다, “세상이 달라질 수 있다면 무엇이 가능한가”를 질문해야 한다. - 글에서 소개한 제노페미니즘의 “자연이 부당하다면 자연을 바꿔라”라는 주장은 현재의 한계를 넘어 미래를 상상하는 태도를 상징한다. 제공된 글은 4번째 규칙의 중간에서 끝나 있어 나머지 5~7번째 규칙은 확인할 수 없다. 다만 실무적으로는 익숙한 레퍼런스를 모방하기 전에 자신의 경험에서 출발하고, 디자인 외부의 분야를 탐구하며, 현재의 문제 해결을 넘어 미래의 가능성까지 상상하는 접근이 유용하다.

원문 읽기(새 탭에서 열림)
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 컴포넌트 저장소가 아니라 디자인 토큰, 테마, 코드 연동, 협업 방식까지 포함하는 조직의 공통 인프라로 다뤄야 한다는 점을 보여줍니다. 특히 디자인 파일과 코드가 서로 다른 토큰을 관리하지 않도록 변수와 자동 동기화를 도입하는 것이 규모가 큰 제품 조직에 실용적인 출발점입니다.

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

신뢰할 수 있는 분산 시스템

Datadog이 Gartner의 2026년 Observability Platforms 매직 쿼드런트에서 **Leader**로 선정되었다는 소식과 함께, Datadog의 관측성 및 운영 플랫폼 제품군을 소개하는 내용입니다. 플랫폼은 인프라·애플리케이션·로그·보안·디지털 경험·소프트웨어 제공·서비스 관리·AI까지 폭넓은 영역을 하나의 생태계로 다룹니다. 다만 제공된 본문에는 Gartner의 평가 기준이나 Datadog이 리더로 선정된 구체적인 근거는 포함되어 있지 않습니다. ### Gartner 매직 쿼드런트 리더 선정 - Datadog은 Gartner의 **Observability Platforms** 부문에서 Leader로 소개됩니다. - 이는 인프라, 애플리케이션, 로그, 사용자 경험 등 여러 관측성 데이터를 통합해 제공하는 플랫폼 역량을 강조하는 메시지입니다. - 제공된 내용만으로는 Gartner의 실행 능력·비전 평가 점수나 경쟁사 대비 세부 분석은 확인할 수 없습니다. ### 인프라와 클라우드 관측성 - 인프라 모니터링과 메트릭 수집을 통해 호스트 및 시스템 상태를 확인합니다. - 컨테이너와 Kubernetes 환경을 모니터링하고, Kubernetes Autoscaling으로 리소스 확장을 지원합니다. - 네트워크, 서버리스 애플리케이션, 스토리지, GPU를 별도 영역으로 관측할 수 있습니다. - Cloud Cost Management와 Cloudcraft를 통해 클라우드 비용 및 인프라 구조 시각화도 다룹니다. ### 애플리케이션 성능 모니터링 - APM으로 서비스 성능, 요청 흐름, 분산 트레이싱을 분석합니다. - Universal Service Monitoring은 서비스 간 의존성과 전체 서비스 토폴로지를 파악하는 데 사용됩니다. - Continuous Profiler는 코드 실행 중 CPU·메모리 사용량을 분석해 성능 병목을 찾습니다. - Dynamic Instrumentation은 코드를 다시 배포하지 않고 런타임 데이터를 수집하는 기능으로 소개됩니다. - AI 에이전트 관측성 기능을 통해 AI 기반 애플리케이션과 에이전트의 동작도 모니터링합니다. ### 로그와 데이터 관측성 - Log Management로 로그를 수집·검색·분석합니다. - Sensitive Data Scanner를 사용해 로그나 관측성 데이터에 포함된 민감정보를 탐지할 수 있습니다. - Observability Pipelines는 데이터 수집·필터링·라우팅을 담당합니다. - Database Monitoring과 Data Streams Monitoring을 통해 데이터베이스 및 서비스 간 데이터 흐름을 관찰합니다. - 데이터 품질과 배치·작업 실행 상태를 점검하는 Quality Monitoring, Jobs Monitoring도 제공합니다. ### 보안 플랫폼 통합 - 코드 보안, SAST, IAST, 소프트웨어 구성 분석(SCA), IaC 보안을 지원합니다. - Cloud Security와 CSPM을 통해 클라우드 설정 오류와 보안 상태를 점검합니다. - CIEM, 취약점 관리, 컴플라이언스, Cloud SIEM, 워크로드 보호 기능을 제공합니다. - 애플리케이션·API 보호와 시크릿 스캐닝까지 포함해 개발부터 운영 단계까지 보안을 통합하려는 구조입니다. ### 디지털 사용자 경험 분석 - Browser·Mobile RUM으로 실제 사용자의 웹·모바일 경험을 측정합니다. - Session Replay를 통해 사용자의 실제 세션을 재현할 수 있습니다. - Synthetic Monitoring은 가상 사용자의 테스트로 서비스 가용성과 응답성을 검증합니다. - Product Analytics, Experiments, Error Tracking을 통해 사용자 행동과 오류를 분석합니다. ### 소프트웨어 제공과 서비스 운영 - CI Visibility, Test Optimization, Continuous Testing으로 빌드와 테스트 파이프라인을 관측합니다. - 코드 커버리지, 기능 플래그, IDE 플러그인 등을 제공해 개발 프로세스와 운영 데이터를 연결합니다. - Software Catalog와 SLO를 통해 서비스 소유권과 신뢰성 목표를 관리합니다. - Event Management, Incident Response, Case Management, Workflow Automation으로 장애 대응 및 운영 절차를 지원합니다. ### AI 기반 운영 기능 - Bits AI Agents, Bits Chat, Bits Investigation 등 AI 기반 조사·대화·자동화 기능을 제공합니다. - Bits Security Analyst는 보안 분석을, Bits Code는 코드 관련 작업을 지원합니다. - MCP Server와 Agent Builder를 통해 외부 도구 및 사내 워크플로와 AI 에이전트를 연결할 수 있습니다. - Watchdog은 이상 징후 탐지와 운영 분석을 자동화하는 기능으로 제시됩니다. ### 실용적인 시사점 Datadog은 단순한 모니터링 도구라기보다 관측성, 보안, 사용자 경험, 개발·운영 자동화를 통합한 플랫폼으로 포지셔닝하고 있습니다. 도입을 검토한다면 필요한 기능 범위뿐 아니라 데이터 수집 비용, 제품 간 통합 수준, 기존 도구와의 중복, 조직의 운영 방식까지 함께 비교하는 것이 좋습니다.

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

신뢰할 수 있는 분산 시스템을 설계하기 위해 형식 모델링, 경량 시뮬레이션, 카오스 테스트를 활용하는 방법 (새 탭에서 열림)

분산 시스템의 복잡성으로 인해 발생하는 시스템 수준의 설계 오류를 해결하기 위해, 데이터독(Datadog)은 차세대 메시지 큐 서비스인 'Courier'의 설계 과정에서 포멀 모델링(Formal Modeling)과 경량 시뮬레이션을 도입했습니다. 이 방식은 전통적인 단위 테스트나 카오스 테스트가 발견하기 어려운 고차원적인 설계 결함을 설계 단계에서 미리 검증하고, 시스템의 성능 특성을 통계적으로 예측할 수 있게 해줍니다. 결과적으로 이러한 접근법은 가용성과 신뢰성이 필수적인 핵심 인프라 서비스가 복잡한 실패 모드에서도 안정적으로 동작함을 확인하는 강력한 도구가 되었습니다. **포멀 모델링과 경량 시뮬레이션의 도입** - **포멀 모델링(Formal Modeling):** 고수준의 명세 언어를 사용해 시스템의 속성을 기술하고, 모델 체커를 통해 발생 가능한 모든 상태를 전수 조사함으로써 설계상의 논리적 결함이 없는지 검증합니다. - **경량 시뮬레이션(Lightweight Simulation):** 포멀 모델링이 확인하기 어려운 지연 시간(Latency), 비용, 확장성 등의 통계적 성능 지표를 실제 부하 환경과 유사한 조건에서 실행하여 분석합니다. - **도입 배경 및 트레이드오프:** 구현 자체를 검증하지는 못하고 모델 유지 보수의 오버헤드가 발생하지만, 대규모 장애(2023년 3월 사례)를 방지하고 설계의 정확성을 보장하기 위해 도입되었습니다. **차세대 메시지 큐 서비스: Courier** - **배경:** 기존 Redis 기반 시스템의 처리량 및 확장성 한계를 극복하기 위해 설계된 멀티테넌트 메시지 큐 서비스입니다. - **최소 1회 전달(At-least-once delivery):** 메시지 손실 없이 전송을 보장하며, 실패 시 데드 레터 큐(DLQ)로 이동하여 알림 누락을 방지합니다. - **점진적 성능 저하(Graceful Degradation):** 가용 컴퓨팅 자원이 줄어들더라도 처리량이 급격히 추락하지 않고 선형적으로 감소하도록 설계하여 전체 서비스 마비를 방지합니다. - **수평적 확장성:** 컴퓨팅 자원 추가에 따라 처리량이 선형적으로 증가하는 구조를 목표로 합니다. **멀티테넌시 및 고가용성을 위한 아키텍처** - **FoundationDB 기반 샤딩:** 여러 개의 FoundationDB 클러스터를 구축하고, 각 테넌트를 특정 클러스터 조합(예: 8개 중 4개 선택)에 샤딩하여 테넌트 간 간섭을 최소화합니다. - **폭발 반경(Blast Radius) 제어:** 특정 테넌트가 4개의 클러스터에 부하를 주더라도, 다른 테넌트는 최소 25% 이상의 가용 용량을 확보할 수 있도록 격리 수준을 높였습니다. - **브로커 레이어(Broker Layer):** gRPC API를 통해 샤딩 로직을 처리하고, 백엔드 클러스터의 상태 점검(Health Check)을 수행하며 3개의 가용 영역(AZ)에 분산 배치되어 고가용성을 유지합니다. 이러한 포멀 모델링과 시뮬레이션 기법은 복잡한 분산 시스템을 구축할 때 직관에 의존하는 대신 수학적·통계적 근거를 바탕으로 의사결정을 내릴 수 있게 합니다. 특히 Courier와 같이 신뢰성이 최우선인 기반 시스템을 설계할 때, 초기 단계에서의 철저한 검증은 추후 발생할 수 있는 막대한 수정 비용과 대규모 장애 위험을 줄이는 데 매우 효과적인 투자입니다.

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

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