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

figma·2021년 11월 29일·2분 읽기큐레이션 요약

Figma의 새로운 소식:

2021년 11월 Figma 업데이트는 팀이 작업 흐름을 끊지 않고 더 빠르게 협업하도록 돕는 데 초점을 맞췄다. 특히 피드백을 남기고 관리하는 댓글 기능을 개선했으며, Figma와 FigJam 안에서 음성 대화와 오디오 피드백을 더 많은 사용자가 이용할 수 있도록 자막 기능을 베타로 도입했다. 핵심 방향은 아이디어를 공유하고 논의하는 과정을 디자인 파일 안에서 더욱 직관적이고 포용적으로 만드는 것이다. ## 댓글 기능 개편으로 피드백 처리 개선 - Figma와 FigJam의 댓글이 더 눈에 잘 띄도록 시각적으로 강화됐다. - 댓글을 추가하고 답변하는 과정이 직관적으로 바뀌어 협업자의 의견을 더 쉽게 수집할 수 있다. - 디자이너는 피드백을 확인하고 관리하며, 작업물에 반영하는 과정을 보다 효율적으로 진행할 수 있다. - 다양한 직군의 구성원이 디자인 과정에 참여하는 상황을 고려해, 피드백을 공유하고 실행하는 흐름을 단순화했다. - 목표는 아이디어 구상부터 구체적인 결과물 제작까지, 피드백 때문에 작업 흐름이 끊기지 않도록 하는 것이다. ## Figma·FigJam 내 커뮤니케이션 확장 - 몇 달 전 도입된 오디오 기능을 통해 같은 파일 안에서 팀원과 음성으로 대화할 수 있게 했다. - 커서 채팅을 사용하면 별도의 창으로 이동하지 않고 현재 커서 위치를 통해 질문이나 짧은 메시지를 전달할 수 있다. - FigJam에서는 협업 중 하이파이브와 같은 반응을 보내며 보다 가볍고 즉각적으로 소통할 수 있다. - 디자인 작업, 아이디어 회의, 피드백 논의를 하나의 파일 안에서 이어갈 수 있도록 커뮤니케이션 수단을 확장했다. ## 오디오 자막으로 접근성 강화 - 청각장애인 및 난청 사용자를 위해 Figma 데스크톱 앱에서 실시간 폐쇄 자막 기능을 베타로 제공했다. - 오디오 통화 중 누가 말하고 있는지, 어떤 내용을 말하는지 더 명확하게 확인할 수 있다. - 음성 기반 피드백에 참여하기 어려운 사용자도 팀의 논의와 의사결정을 따라갈 수 있도록 지원한다. - 협업 파일에 참여한 모든 사람이 중요한 논의에 접근할 수 있게 해, Figma의 실시간 협업 기능을 더욱 포용적으로 만들었다. 실무에서는 댓글을 단순한 메모가 아니라 작업 항목으로 활용하고, 음성 피드백이 중요한 팀이라면 오디오 자막 베타 기능을 함께 사용해 구성원 모두가 논의 내용을 확인할 수 있도록 하는 것이 좋다.

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

Figmafigjam접근성collaborative-design+2

figma·2021년 11월 15일·2분 읽기큐레이션 요약

개편된 댓글 기능으로 작업 흐

Figma는 댓글 기능을 개선해 팀이 피드백을 더 쉽게 남기고, 이해하고, 반영할 수 있도록 했다. 댓글 접근성을 높이고, 짧고 구체적인 피드백을 유도하며, 디자이너가 작업 흐름을 유지한 채 댓글을 관리할 수 있게 만든 것이 핵심이다. 이를 통해 더 많은 협업자가 디자인 과정에 참여하면서도 피드백 과부하를 줄이는 것이 목표다. ## 댓글 접근성 향상 - 파일을 열어 보는 사람과 프로토타입 프레젠테이션 모드의 사용자가 댓글 사이드바를 쉽게 찾을 수 있도록 개선했다. - Figma에 익숙하지 않은 협업자도 댓글을 남기고 기존 피드백을 확인할 위치를 명확히 알 수 있게 했다. - 별도 도구를 사용하거나 피드백 자체를 생략하는 문제를 줄이고, 더 많은 구성원의 의견을 디자인 맥락 안에서 받을 수 있도록 했다. ## 더 구체적이고 이해하기 쉬운 피드백 - 댓글 작성창을 작게 만들어 한 댓글에 여러 질문을 섞기보다 짧고 명확한 의견을 남기도록 유도했다. - 리액션 기능을 추가해 간단한 동의나 감정을 빠르게 표현할 수 있게 했다. - 리액션은 댓글 스레드를 불필요하게 길게 만들지 않고, 다른 사람도 부담 없이 의견을 보탤 수 있도록 돕는다. - 여러 디자인이나 스티키 그룹처럼 넓은 범위에 대한 개념적 피드백은 캔버스 영역을 지정해 댓글로 남길 수 있다. - 특정 디자인 세부 사항부터 넓은 영역에 대한 의견까지, 피드백을 관련된 위치와 함께 확인할 수 있다. ## 작업 흐름을 유지하는 댓글 관리 - 댓글 핀이 기본적으로 표시되어 중요한 피드백을 놓치기 어렵게 했다. - 디자인을 수정하는 동안에도 관련 댓글을 열어 둔 채 작업할 수 있도록 개선했다. - 댓글 핀에는 작성자의 아바타와 댓글 미리보기가 표시되어, 누가 어떤 의견을 남겼는지 빠르게 파악할 수 있다. - 같은 영역에 댓글이 여러 개 있으면 클러스터로 묶어 캔버스가 댓글로 과도하게 복잡해지는 것을 방지한다. - 단순화된 화면 구성을 통해 피드백이 집중된 영역을 한눈에 확인할 수 있다. ## 많은 댓글을 빠르게 정리하는 기능 - 키워드나 작성자 이름으로 댓글을 검색할 수 있다. - 날짜를 기준으로 댓글을 정렬할 수 있다. - 즉시 답변하기 어려운 댓글은 ‘읽지 않음’으로 표시해 나중에 다시 확인할 수 있다. - 이러한 기능은 사일런트 크리틱, 디자인 스프린트 등 댓글이 많이 발생하는 협업 상황에서 피드백을 체계적으로 처리하도록 돕는다. 실무에서는 한 댓글에 여러 요청을 몰아넣기보다 질문과 요구사항을 나누고, 가능한 경우 관련 캔버스 영역에 댓글을 남기는 것이 좋다. 디자이너는 검색·정렬·읽지 않음 표시를 활용해 피드백을 우선순위별로 처리하면 작업 흐름을 유지하면서도 협업 의견을 놓치지 않을 수 있다.

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

Figma사용자 경험프로토타이핑figjam+2

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

제작 비하인드: 개발

개빈 맥팔랜드는 사용자들이 겪는 불편에서 아이디어를 얻어 Figma 플러그인과 FigJam 위젯을 개발해 왔다. 대표작인 Table Creator와 테이블 위젯은 FigJam을 떠나지 않고 표 데이터를 생성·관리하도록 돕는다. 그는 단순한 API 실험에서 출발했지만, 실시간 협업과 대규모 데이터 처리 같은 문제로 관심을 확장하며 도구가 팀의 생산성과 협업을 높여야 한다고 강조한다. ## 사용자 문제에서 출발한 개발 - 개빈은 사용자 중심 디자인을 바탕으로 기업의 디지털 전환을 돕는 프리랜서 디자인 컨설턴트다. - 친구와 가족의 웹사이트를 제작하던 경험에서 시작해, 새로운 기술과 작업 방식을 꾸준히 시도해 왔다. - 트위터에서 “Figma에서 표를 더 쉽게 만들고 싶다”는 요청을 본 것이 플러그인 개발의 계기가 됐다. - Figma의 `Rectangle Creator` 예제를 수정해 표 생성 기능을 만들었고, 이를 **Table Creator**라는 첫 플러그인으로 출시했다. - 해당 플러그인은 수만 명이 사용할 정도로 확산됐다. ## FigJam용 테이블 위젯 - 첫 플러그인 개발 경험을 바탕으로 FigJam용 테이블 위젯을 제작했다. - 위젯의 주요 기능은 다음과 같다. - 행과 열 추가 - 데이터 가져오기 - 열 기준 정렬 - 표의 디자인과 구조 조정 - 별도의 도구로 이동하지 않고 FigJam 작업 공간에서 표 데이터를 바로 확인하고 활용할 수 있도록 설계됐다. - 디자인 작업, 협업 회의, 데이터 정리 등 표 형식의 정보를 사용하는 다양한 팀을 대상으로 한다. ## 예제 코드로 시작한 개발 방식 - 처음에는 FigJam 위젯의 `notepad` 예제를 수정하며 API 동작을 단계적으로 익혔다. - 간단한 변경을 반복하면서 위젯의 구조와 동작 방식을 파악했다. - 기존에 익숙하지 않았던 JSX 코드도 개발 과정에서 학습했다. - 기본적인 사용법을 이해한 뒤 행과 열을 표시하고, 여러 레이아웃과 디자인을 실험했다. - 완성된 설계에서 시작하기보다 작은 프로토타입을 빠르게 수정하는 방식으로 기능을 발전시켰다. ## 단순한 기능에서 협업 문제로 확장 - 처음에는 위젯 API를 익히기 위한 연습 프로젝트였지만, 팀 협업을 개선할 수 있는 도구로 발전했다. - 여러 사용자가 같은 표를 동시에 편집할 때 발생하는 문제에 관심을 갖게 됐다. - 특히 다음과 같은 과제가 중요하다고 보았다. - 다른 사용자가 같은 표를 편집 중임을 어떻게 표시할 것인가 - 실시간 멀티플레이어 상호작용을 어떻게 설계할 것인가 - 대량의 데이터를 다루면서도 인터페이스가 느려지지 않게 하려면 어떻게 해야 하는가 - 시각적 디자인과 기술적 구현을 함께 고민해야 한다는 점이 개발의 매력으로 작용했다. ## 영감과 개발자 커뮤니티 - 영감은 사람들이 디자인 과정에서 어떤 부분을 어렵게 느끼는지 관찰하는 데서 얻는다. - Friends of Figma Slack 그룹에서 사용자들의 요구와 작업상의 불편을 파악한다. - 플러그인 개발자 커뮤니티에도 적극적으로 참여하며 다른 제작자들과 아이디어와 개선 방법을 공유한다. - 사용자 피드백과 개발자 간 협업을 통해 실제 업무 문제를 해결하는 기능을 찾으려 한다. ## 생산성과 협업을 위한 도구 - 위젯을 사용하는 사람들이 더 생산적으로 일하고, 중요한 문제에 집중하기를 기대한다. - 개인의 작업 속도 향상뿐 아니라 팀원 간 협업을 더욱 긴밀하게 만드는 것이 목표다. - 개빈에게 좋은 도구란 기능을 추가하는 데 그치지 않고, 사람들이 일상적으로 겪는 문제를 함께 해결하도록 돕는 도구다. - 이후에도 Figma 플러그인인 **Node Decoder**를 만드는 등 새로운 개발 작업을 이어가고 있다. 사용자들이 반복적으로 겪는 불편을 관찰하고, 작은 예제에서 출발해 실제 협업 환경에 필요한 기능으로 확장한 점이 이 사례의 핵심이다. Figma·FigJam 플러그인을 개발할 때도 기능 자체보다 사용자의 작업 흐름, 실시간 협업, 데이터 규모와 성능을 함께 고려하는 것이 중요하다.

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

Figmafigjamreal-time-collaborationAPI+3

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

지원자 인터뷰부터 개발자 크

Figma Engineering은 원격·하이브리드 환경에서 FigJam을 협업의 중심 도구로 활용해 팀 규모 확장과 구성원 간 연결을 동시에 해결하고 있다. 스탠드업, 채용 인터뷰, 기술 논의처럼 기존에는 물리적 화이트보드나 회의에 의존하던 활동을 디지털 캔버스로 옮겨 비동기 협업과 참여를 강화했다. FigJam은 업무 도구를 넘어 팀 문화를 유지하고 새로운 구성원의 적응을 돕는 공간으로도 사용된다. ## 원격 환경에서 팀 문화 유지 - Zoom 기반 스탠드업은 팀 규모가 커지면서 형식적이고 시간이 오래 걸리는 회의가 되었다. - Figma는 FigJam 보드에 각자 업무 업데이트를 비동기적으로 작성하는 방식으로 스탠드업을 운영한다. - 구성원은 스티키 노트, 사진, 댓글, 리액션 등을 활용해 업무뿐 아니라 주말 활동 같은 개인적인 이야기도 공유한다. - 모두가 순서대로 발언하지 않아도 다른 사람의 게시물에 반응하고 대화할 수 있어 자연스러운 교류가 가능하다. - 회의가 끝난 뒤에도 보드에서 팀 게임을 진행한다. 예를 들어 ‘20초 동물 그리기’처럼 짧은 활동으로 회의를 즐겁게 마무리한다. ## 빠르게 성장하는 엔지니어링 조직의 과제 - FigJam 팀의 엔지니어링 매니저는 새로운 기능을 협력적으로 개발하도록 돕는 동시에 원격 근무 중 팀 연결을 유지하는 역할을 맡는다. - 모바일 팀은 20명 이상으로 성장하면서 팀 프로세스를 확장하고, 신규 구성원이 인프라와 기술 스택을 빠르게 익히도록 하는 일이 중요해졌다. - Android 엔지니어링 팀은 신규 앱의 베타 테스트와 버그 피드백 수집을 진행하는 한편, 급증하는 채용 수요에도 대응하고 있다. - 팀이 커질수록 단순히 인원을 늘리는 것보다 지식 공유, 온보딩, 협업 방식의 표준화가 필요하다는 점을 보여준다. ## FigJam을 활용한 원격 기술 면접 - Figma는 아키텍처나 시스템 설계 면접에서 지원자가 문제를 어떻게 사고하고 협업하는지 확인하기 위해 화이트보드 방식을 선호한다. - 원격 근무 전환 이후 물리적인 화이트보드를 FigJam의 디지털 캔버스로 대체했다. - 면접관은 문제를 제시하고, 지원자가 설계를 시각화하며 해결 과정을 설명하도록 한다. - 지원자가 FigJam을 처음 사용하는 경우를 고려해 면접 시작 전에 1~2분 정도 사용법을 안내한다. - 계정 생성 없이 참여할 수 있는 ‘오픈 세션’을 활용해 지원자가 쉽게 면접 보드에 들어오도록 했다. - 이를 통해 대면 면접의 화이트보드 협업 경험을 원격 환경에서도 유지하면서, 면접 과정 자체를 기록하고 공유하기 쉬워졌다. ## 협업 도구를 통한 개발 프로세스 확장 - FigJam은 단순한 회의용 메모장이 아니라 아이디어 정리, 시스템 설계, 피드백 수집을 한 공간에서 수행하는 협업 환경으로 활용된다. - 비동기 작성과 실시간 대화를 함께 지원해 회의 시간을 줄이고 구성원의 참여 방식을 다양화한다. - 시각적 자료를 남길 수 있어 팀의 논의 내용과 의사결정을 이후에도 참고하기 쉽다. - 채용, 온보딩, 팀 문화 활동까지 동일한 도구를 사용함으로써 조직이 커져도 일관된 협업 경험을 제공한다. 조직이 원격 또는 하이브리드 방식으로 확장될 때는 회의 도구만 도입하기보다, 스탠드업·채용·기술 리뷰·팀 친목 활동을 연결하는 공용 협업 공간을 마련하는 것이 효과적이다. FigJam 사례처럼 비동기 업데이트와 짧은 실시간 활동을 조합하면 생산성과 팀 소속감을 함께 높일 수 있다.

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

FigmafigjamAndroidmobile-development+2

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

빌드 비하인드: 개발

Tekeste Kidanu는 디자이너의 생산성을 높이는 Figma·FigJam 플러그인과 위젯을 개발하며, 커뮤니티의 요구에서 제품 아이디어를 얻는 개발자다. 대표작인 SPELLL은 문서의 맞춤법과 문법 오류를 찾아 수정하도록 돕고, FigJam용 Notes·색상 선택기·투표 위젯 등으로 영역을 확장하고 있다. 그는 Figma 플러그인 API가 기존 JavaScript·웹 개발 지식만으로도 접근하기 쉽고, 공개 플랫폼 전환이 더욱 다양한 창작물을 이끌 것이라고 기대한다. ## 개발자 배경과 디자인 학습 - Tekeste Kidanu는 `tkmadeit`이라는 이름으로 활동하는 프론트엔드 개발자다. - 2016년 미국으로 이주해 컴퓨터 과학을 공부했으며, 웹 기술에 관심이 많다. - Figma 플러그인을 만들면서 디자인 자체에도 흥미를 느끼게 됐다. - 좋은 UI를 구별하는 것에서 나아가 직접 디자인하기 위해 색채 이론과 타이포그래피 같은 UI 디자인 기초를 학습하고 있다. ## SPELLL: Figma·FigJam용 맞춤법 검사기 - 대표 플러그인인 SPELLL은 Figma와 FigJam 문서의 철자 및 문법 오류를 검사한다. - Grammarly와 유사하게 오류를 찾아내고 사용자가 쉽게 수정할 수 있게 한다. - 디자이너가 파일을 수동으로 검토하는 시간을 줄이고, 발표나 공유 과정에서 오탈자로 곤란을 겪는 일을 방지하는 것이 목표다. - Figma뿐 아니라 FigJam에서도 사용할 수 있도록 확장됐다. ## 커뮤니티에서 얻는 아이디어 - 플러그인 아이디어는 Figma Forum, Designer News, Twitter 등 디자인 커뮤니티에서 주로 얻는다. - 사용자들이 요청하는 기능과 반복적으로 제기되는 불편을 관찰해 실제 수요가 있는 문제를 찾는다. - Figma 공식 계정의 트윗이나 디자이너들의 기능 요청도 중요한 영감의 원천이다. - Friends of Figma와 같은 Slack 커뮤니티에서는 실제 Figma 사용자를 만나고 요구사항을 파악할 수 있다. - 새 플러그인을 구상할 때 Twitter나 포럼에서 기능 요청을 검색해보는 방법을 추천한다. ## Figma 플러그인 API로 시작하기 - 먼저 플러그인이 어떤 방식으로 동작해야 하는지 조사한 뒤 개발에 착수했다. - Figma 플러그인 API 공식 문서를 읽으며 기능과 구조를 익혔다. - Figma Plugins Slack 워크스페이스에서 질문하고 다른 개발자들의 도움을 받았다. - 디자인 플러그인을 처음 만들었지만, 기존 JavaScript와 웹 개발 경험만으로도 시작할 수 있었다. - API가 직관적이고 진입 장벽이 낮았다는 점을 개발 과정에서 가장 놀라운 부분으로 꼽았다. ## FigJam으로의 확장 - FigJam이 플러그인을 지원한다는 소식을 듣고 기존 Figma 플러그인을 FigJam으로 이전하기 시작했다. - Figma와 FigJam의 API 및 개발 절차가 거의 비슷해 확장이 수월했다. - 이를 통해 하나의 플러그인 개발 경험을 두 협업 도구로 넓힐 수 있었다. - Figma가 기본 기능으로 제공하지 않는 기능도 플러그인 API를 통해 먼저 구현할 수 있다는 점을 활용했다. ## Notes와 색상 선택기 위젯 - Notes는 FigJam 보드 안에서 상세한 메모를 작성할 수 있는 위젯이다. - 일반 텍스트와 Markdown 형식을 지원한다. - 보드 위에 메모를 직접 배치해 화면을 복잡하게 만들지 않고 별도로 정리할 수 있도록 설계됐다. - FigJam용 색상 선택기는 사용자가 원하는 색상의 스티키와 도형을 만들도록 돕는다. ## 투표 위젯과 향후 계획 - Tekeste는 FigJam용 투표 위젯의 첫 버전을 공개했다. - 익명 투표와 실명 투표를 모두 지원한다. - 기존 기능을 계속 개선해 최고의 투표 위젯으로 발전시키는 것이 목표다. - 앞으로는 FigJam 파일 참여자들이 현재 듣고 있는 음악을 보여주는 위젯도 만들어보고 싶다고 밝혔다. ## 공개 플랫폼에 대한 기대 - Figma는 내부에서 몇 주간 위젯을 개발한 뒤 외부 개발자 커뮤니티에도 API를 개방했다. - Tekeste는 FigJam 플러그인과 위젯의 공개 출시가 다양한 실험과 창작을 촉진할 것으로 기대한다. - 특히 장난스럽고 생동감 있는 인터페이스가 인기를 얻는 흐름에 관심을 보였다. - Apple Maps의 3D 랜드마크 표현과 Honk의 playful한 iOS UI를 인상적인 사례로 언급했다. 새로운 Figma·FigJam 기능을 만들고 싶다면 사용자가 반복해서 제기하는 불편을 커뮤니티에서 찾고, 공식 API 문서와 개발자 커뮤니티를 활용해 작은 프로토타입부터 시작하는 접근이 효과적이다. Figma와 FigJam의 유사한 API 덕분에 하나의 아이디어를 두 환경으로 확장하기도 쉽다.

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

사용자 인터페이스JavaScript웹 개발markdown+2

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

빌드 비하인드:

Figma는 FigJam의 플러그인·위젯 생태계를 외부 개발자에게 개방하며 새로운 협업과 창작 가능성을 넓히고 있다. 개발자 Tru Narla는 위젯 제작 경험을 바탕으로 사운드보드 위젯을 만들었고, 작은 아이디어를 실제로 출시하는 과정에서 커뮤니티와 스트리밍의 도움을 얻었다. 그녀는 앞으로 인터랙티브 피아노와 멀티플레이어 게임 등으로 FigJam의 상호작용성을 확장하고자 한다. ## Soundboard 위젯의 목적 - Tru Narla는 Square의 소프트웨어 엔지니어로 일하며, 개인 프로젝트와 프로토타이핑에도 Figma를 자주 사용한다. - 그녀가 만든 **Soundboard**는 FigJam 보드에 재미있는 소리를 추가하는 위젯이다. - 향후 사용자가 직접 오디오를 녹음하거나 미리 준비된 소리를 선택하는 기능을 추가하고 싶어 한다. - 기존에 오디오 중심의 FigJam 위젯이 거의 없다는 점에서 아이디어를 얻었다. ## 문서와 커뮤니티를 통한 개발 - 공식 문서를 읽고 데모 프로젝트를 따라 하면서 개발을 시작했다. - 초기에는 시행착오를 반복하며 기능을 구현했다. - 위젯 API의 제약으로 오디오 녹음 기능을 넣을 수 없어 프로젝트 범위를 축소했다. - 비공개 Slack 채널에서 다른 위젯 개발자들과 코드를 공유하고 버그를 함께 해결한 것이 큰 도움이 됐다. - 위젯 개발은 예상보다 쉽고 재미있었으며, 제한적인 부분이 있어도 현재 제공되는 기능만으로 다양한 프로젝트를 만들 수 있다고 평가했다. ## 아이디어를 실행하고 출시한 계기 - Tru는 이전에도 사이드 프로젝트를 자주 시작했지만 완성하거나 출시하지 못한 경우가 많았다. - 비공개 위젯 개발자 커뮤니티에서 다른 사람들의 작업을 보며 동기를 얻었다. - 자신이 직접 사용할 만한 것을 만들고 싶다는 생각으로 사운드 관련 프로젝트를 시작했다. - 개발 과정을 Twitch에서 스트리밍한 것이 프로젝트를 끝까지 완성하는 데 도움이 됐다. - 아이디어가 떠오르면 바로 메모하고, Twitter와 일상생활에서 영감을 얻는다고 설명했다. ## FigJam에서 확장되는 상호작용 - 다음 프로젝트로 사용자가 건반을 클릭해 소리를 내거나, 키보드 단축키로 특정 음을 연주할 수 있는 **인터랙티브 피아노**를 개발 중이다. - 장기적으로는 구현 난도가 높은 멀티플레이어 게임도 만들고 싶어 한다. - FigJam의 플러그인과 위젯이 협업 보드에 재미와 상호작용을 더하는 방식에 주목한다. - 개발·시스템 설계를 위한 코드 임베드 기능에도 관심이 있으며, 코드 설명이나 튜토리얼을 FigJam에 작성하는 활용을 기대한다. - 실행 가능한 코드를 샌드박스에서 직접 보여주는 기능도 있으면 유용할 것이라고 제안한다. ## 개방형 플랫폼의 가능성 - FigJam이 외부 개발자에게 API를 공개하면서 개인 개발자도 새로운 도구를 제작하고 배포할 수 있게 됐다. - 다른 개발자들의 플러그인과 위젯이 다시 새로운 아이디어를 자극하는 선순환이 형성되고 있다. - Tru는 Figma와 FigJam에 아직 개발되지 않은 가능성이 많다는 점을 가장 기대되는 부분으로 꼽는다. - Figma Community를 통해 다양한 위젯과 플러그인을 공유하고 탐색할 수 있다. 작은 기능의 프로토타입이라도 직접 사용해 보고 싶은 문제에서 출발해 빠르게 만들고 공개하는 것이 좋은 출발점이다. 공식 문서뿐 아니라 개발자 커뮤니티와 공개 과정을 활용하면 기술적 제약을 줄이고 프로젝트를 완성할 가능성을 높일 수 있다.

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

FigmafigjamslackAPI+4

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

Figma의 새로운 소식:

Figma의 2021년 10월 업데이트는 협업 방식을 유연하게 만들고, 반복적인 작업을 자동화하며, 아이디어를 더 빠르게 실험하도록 돕는 데 초점을 맞췄다. FigJam에는 위젯·플러그인·오픈 세션이 추가됐고, Figma 프로토타이핑에는 인터랙티브 컴포넌트와 상호작용 관리 기능이 도입됐다. 또한 대규모 디자인 시스템을 지원하기 위한 브랜칭도 소개됐다. ## FigJam 협업 기능 확장 ### 위젯으로 협업 공간 사용자화 - FigJam 파일에 위젯을 클릭해 추가하고, 팀의 협업 방식에 맞게 보드를 구성할 수 있다. - **Photo Booth**를 사용하면 보드에 셀카를 추가할 수 있다. - **Alignment Scale**로 팀원들의 현재 상태나 의견을 확인할 수 있다. - **Org Chart**를 활용해 팀 구조를 시각화할 수 있다. ### 플러그인으로 작업 속도 향상 - 위젯이 협업 자체를 위한 기능이라면, 플러그인은 아이디어를 표현하고 정리하는 작업을 빠르게 해준다. - **Tour Guide**는 FigJam 보드를 슬라이드 쇼 형식의 프레젠테이션으로 변환한다. - **Color Picker**는 스티커와 도형에 사용할 색상 선택지를 확장한다. - **Unsplash** 플러그인으로 이미지 자료를 바로 검색하고 삽입할 수 있다. ### 툴바와 오픈 세션 - FigJam 파일의 툴바에서 플러그인과 위젯을 직접 탐색할 수 있다. - 브레인스토밍, 워크숍, 리서치 등 목적별 **FigJam 템플릿**을 제공한다. - 개발자 협업을 위해 **코드 블록**과 새로운 도형 및 고급 다이어그램 기능을 추가했다. - **Open sessions**를 사용하면 방문자가 계정을 만들지 않아도 FigJam 파일에 참여할 수 있다. ## 인터랙티브 컴포넌트로 프로토타이핑 개선 ### 재사용 가능한 인터랙티브 컴포넌트 - **인터랙티브 컴포넌트**를 사용하면 재사용 가능한 UI 요소에 상호작용을 정의할 수 있다. - 동일한 요소의 상태와 동작을 반복해서 연결하는 작업이 줄어든다. - 프로토타입 제작에 드는 시간을 줄이고, 팀이 디자인 실험과 반복 개선에 더 집중할 수 있다. ### 상속된 상호작용 숨기기 - 컴포넌트 인스턴스에서는 메인 컴포넌트로부터 상속된 상호작용을 기본적으로 숨길 수 있다. - 복잡한 프로토타입에서도 현재 인스턴스에 직접 설정된 동작을 쉽게 파악할 수 있다. - 결과적으로 프로토타입 편집과 개발자 핸드오프의 가독성이 개선된다. ### 기타 프로토타이핑 업데이트 - `Shift + E` 단축키로 디자인 탭과 프로토타입 탭을 전환할 수 있다. - 캔버스에서 모든 사용자가 프로토타입 상호작용을 확인하고 탐색할 수 있다. - 사용자 테스트 시 뷰어의 기본 키보드 탐색을 비활성화할 수 있다. - 프로토타입 상호작용을 복사하고 붙여넣어 반복 설정을 줄일 수 있다. ## 대규모 디자인 시스템 지원 - Figma는 디자인 시스템의 일관성을 유지하면서도 새로운 아이디어를 실험할 수 있는 환경을 제공하는 것을 목표로 한다. - 이번 업데이트에서는 여러 디자인 방향을 독립적으로 실험하고 관리할 수 있는 **브랜칭(Branching)** 기능을 소개했다. - 브랜칭에 대한 구체적인 동작과 활용 방법은 별도의 상세 글에서 설명한다. 이번 업데이트는 FigJam에서는 협업 진입 장벽을 낮추고, Figma에서는 프로토타이핑 반복 작업을 줄이는 방향으로 구성됐다. 팀 단위로 작업한다면 FigJam의 템플릿·위젯·오픈 세션을 활용하고, 디자인 시스템을 운영한다면 인터랙티브 컴포넌트와 브랜칭을 도입하는 것이 실용적이다.

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

Figma디자인 시스템프로토타이핑figjam+4

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

인터랙티브 컴포넌

Figma는 인터랙티브 컴포넌트를 통해 시각 디자인과 프로토타이핑 사이의 간극을 줄이고, 더 적은 작업으로 실제 동작에 가까운 디자인을 만들 수 있도록 했다. 컴포넌트의 여러 variant 사이에 상호작용과 애니메이션을 정의하면 인스턴스가 프로토타이핑 모드에서 바로 작동하며, 팀 단위의 공유와 반복 작업도 쉬워진다. 또한 단축키, 캔버스 정리, 인터랙션 복사·붙여넣기 등 프로토타이핑을 빠르게 만드는 기능도 함께 제공한다. ## 인터랙티브 컴포넌트의 목적 - 기존에는 시각 디자인과 인터랙션 설계를 위해 도구를 전환하거나 프레임을 수동으로 연결해야 했다. - 이런 번거로움 때문에 프로토타이핑을 생략하면 개발 단계에서 추가 작업이 발생하거나 사용자 경험 목표를 놓칠 수 있었다. - 인터랙티브 컴포넌트는 디자인 과정에서 시각적 형태와 동작을 함께 탐색하도록 지원한다. - 2021년 10월 기준 베타를 종료하고 모든 사용자가 이용할 수 있게 되었다. ## 컴포넌트 variant 기반 상호작용 - 컴포넌트 세트 안의 여러 variant 사이에 전환, 상호작용, 애니메이션을 정의할 수 있다. - 해당 컴포넌트의 인스턴스는 프로토타이핑 모드에서 별도의 연결 작업 없이 즉시 동작한다. - 체크박스 선택, 아코디언 메뉴 열기 등 여러 UI 상태를 하나의 컴포넌트 구조로 표현할 수 있다. ## 프로토타입 복잡성 감소 - 과거에는 상태별로 여러 프레임을 만들어야 했지만, 인터랙티브 컴포넌트를 사용하면 하나의 프레임 안에서 상태와 동작을 관리할 수 있다. - 프레임 수가 크게 줄어들어 프로토타입을 만들고 수정하기 쉬워진다. - AWS 사례에서는 일부 프로젝트의 프레임 수가 10분의 1 이하로 감소했다고 설명한다. ## 프로토타입 제작 속도 향상 - 사용된 위치 바로 옆에서 인터랙티브 컴포넌트의 모든 상태를 편집할 수 있다. - 기존 작업 흐름을 벗어나지 않고 컴포넌트를 복제해 새로운 버전을 실험할 수 있다. - 동일한 버튼 수십~수백 개에 hover 상태를 반복 설정하는 대신, 컴포넌트에 동작을 한 번 정의해 재사용할 수 있다. ## 디자인 시스템과 팀 협업 - 인터랙티브 컴포넌트는 라이브러리를 통해 팀 전체에 공유할 수 있다. - 팀원은 라이브러리에서 컴포넌트를 한 번의 클릭으로 가져와 프로토타입에 사용할 수 있다. - 인터랙션이 디자인 시스템에 내장되므로 Figma에 익숙하지 않은 구성원도 적은 도움으로 동작하는 프로토타입을 만들 수 있다. - 베타 기간 동안 성능, 로딩 시간, 안정성이 개선되었고 관찰 모드와 오토 레이아웃 지원도 추가되었다. ## 일상적인 작업을 빠르게 만드는 기능 - **디자인·프로토타이핑 탭 전환** - `Shift + E` 단축키로 디자인 탭과 프로토타이핑 탭을 빠르게 전환할 수 있다. - 오브젝트 편집과 사용자 경험에 대한 동작 설계를 자연스럽게 오갈 수 있다. - **캔버스 정리** - 프로토타입 연결을 나타내는 파란색 화살표인 “noodle”이 지나치게 많아지는 문제를 개선했다. - 메인 컴포넌트에서 상속된 인스턴스의 인터랙션은 캔버스에서 숨겨 복잡한 프로토타입을 더 쉽게 파악할 수 있다. - **인터랙션 복사·붙여넣기** - 프로토타입 인터랙션을 복사해 다른 프레임에 붙여넣을 수 있다. - 반복적인 연결 작업을 줄여 프로토타입 제작 속도를 높인다. 실무에서는 자주 재사용되는 버튼, 입력창, 메뉴, 토글 등의 상태와 전환을 인터랙티브 컴포넌트로 라이브러리화하는 것이 효과적이다. 그러면 디자이너는 화면별 연결보다 사용자 흐름과 인터랙션 검증에 집중할 수 있고, 팀 전체가 일관된 동작을 사용하게 된다.

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

Figma디자인 시스템프로토타이핑auto-layout+2

figma·2021년 10월 20일·2분 읽기큐레이션 요약

오픈 세션: 언제

FigJam의 **Open sessions**는 계정이 없는 사람도 초대 링크만으로 회의나 워크숍에 참여할 수 있게 하는 기능이다. 회원가입 절차를 없애 참여 장벽을 낮추고, 외부 파트너·고객·지원자 등 일회성 참가자도 즉시 협업할 수 있도록 설계됐다. 세션은 기본적으로 24시간 후 종료되고 방문자는 제거되므로, 편의성과 접근 제어를 함께 제공한다. ## 계정 없이 참여하는 협업 세션 - 방문자는 FigJam 계정을 만들거나 별도 설정을 하지 않고 파일에 참여할 수 있다. - 링크를 받은 참가자는 즉시 보드에 들어와 아이디어 작성, 피드백, 공동 작업을 시작할 수 있다. - 회원가입으로 인해 워크숍이나 인터뷰가 지연되는 문제를 줄이는 것이 주요 목적이다. - 팀 구성원뿐 아니라 외부 고객, 협력사, 지원자, 일회성 참가자까지 참여 대상으로 삼는다. ## 세션 수명과 접근 제어 - Open session은 기본적으로 방문자를 제거하며, 세션은 24시간 후 자동 종료된다. - 주최자는 필요에 따라 세션을 24시간 이전에 직접 닫을 수 있다. - 같은 FigJam 파일에 대해 새로운 Open session을 다시 시작할 수 있다. - 따라서 지속적인 프로젝트 협업보다는 특정 행사를 위한 일회성 협업에 적합하다. ## 워크숍과 사용자 리서치 - 고객 워크숍이나 원격 리서치 세션에서 참가자가 가입하지 않고 바로 참여할 수 있다. - 진행자는 사전에 FigJam 링크를 공유해 참가자가 별도 준비 없이 세션에 들어오도록 할 수 있다. - 대규모 그룹과 일대일 세션 모두에 활용할 수 있다. ## 인터뷰와 기술 평가 - 지원자에게 인터뷰 전에 FigJam 링크를 전달해 작업 공간과 진행 방식을 미리 확인하게 할 수 있다. - 지원자는 계정 생성 없이 자신의 작업물이나 아이디어를 보여줄 수 있다. - 기술 인터뷰에서는 CoderPad 위젯을 함께 사용해 코딩 과제를 진행할 수 있다. ## 부서 간 회의와 브레인스토밍 - 여러 부서의 이해관계자를 회의에 쉽게 초대할 수 있다. - 우선순위 공유, 프로젝트 회고, 브레인스토밍, 리더 피드백 등에 활용할 수 있다. - 회사 내 누구나 간편하게 참여할 수 있어 부서 간 협업의 진입 장벽을 낮춘다. ## 제공 계획 - FigJam 베타 기간에는 모든 요금제에서 Open sessions를 사용할 수 있었다. - 2022년 2월 1일부터는 FigJam Professional 및 Organization 요금제의 기능으로 제공될 예정이었다. - Figma는 사용 방법을 익힐 수 있도록 워크숍, 회의, 인터뷰용 플레이그라운드 파일과 데모를 제공했다. 실용적으로는 고객 워크숍, 채용 인터뷰, 단발성 회의처럼 참가자가 반복적으로 서비스를 사용할 필요가 없는 상황에 Open sessions를 활용하는 것이 적합하다. 반대로 장기적인 협업이나 민감한 자료를 다루는 경우에는 계정 기반 접근과 별도의 권한 관리가 더 안전하다.

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

Figmafigjampluginswidgets+2

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

새로운 FigJam 요금제와

FigJam은 조직 전체가 쉽게 참여할 수 있는 협업 화이트보드로 확장하기 위해 가격 체계와 플랫폼 개방성을 함께 개편한다. 2022년 2월부터 무료 Starter 플랜과 에디터당 월 3~5달러의 유료 플랜을 제공하고, 로그인 없이 참여 가능한 Open sessions를 도입한다. 또한 위젯·플러그인·임베드·새 도형과 코드 블록 등을 통해 FigJam을 팀별 업무 방식에 맞게 확장하는 것이 핵심이다. ## 접근성을 높인 새로운 가격 정책 - 베타 종료일인 2022년 2월 1일부터 FigJam은 무료 및 유료 플랜으로 운영된다. - **Starter 플랜** - 개인 화이트보드 무제한 - 공유 화이트보드 3개 - 공유 보드에는 협업자 무제한 초대 가능 - **FigJam Professional**은 에디터당 월 3달러로 조직 전체에서 공유 화이트보드를 무제한 사용할 수 있다. - **FigJam Organization**은 에디터당 월 5달러이며, 조직 단위 사용을 위한 유료 옵션이다. - 팀 규모나 협업 방식이 서로 다른 만큼, 개인·소규모 팀부터 대규모 조직까지 선택할 수 있는 구조를 지향한다. ## 로그인 없이 참여하는 Open sessions - Open sessions를 이용하면 누구나 FigJam 세션에 초대할 수 있다. - 초대받은 사람은 로그인 없이 최대 24시간 동안 잼 세션에 참여할 수 있다. - 일회성 리서치 워크숍, 기획 회의, 고객 인터뷰처럼 외부 참가자가 많은 상황에서 진입 장벽을 낮춘다. - 기존 계정 중심 협업에서 벗어나 디지털 워크숍이나 대면 회의에 가까운 참여 경험을 제공한다. ## 위젯으로 협업 공간 맞춤화 위젯은 FigJam 보드 안에서 팀 활동과 협업 기능을 직접 제공하는 확장 요소다. - **팀 유대감 형성** - Donut은 아이스브레이커 질문, 그림 그리기 게임 등을 제공한다. - Rock Paper Scissors, Connect Four 같은 간단한 게임으로 팀 분위기를 환기할 수 있다. - **회의 진행 지원** - Simple Vote로 브레인스토밍 결과에 대한 투표와 피드백을 수집할 수 있다. - Alignment Scale로 참가자들이 같은 방향을 보고 있는지 확인할 수 있다. - **생산성 향상** - Table 위젯으로 Google Sheets 데이터를 가져와 표를 만들 수 있다. - Stark for FigJam은 접근성 체크리스트와 역할별 설명을 제공한다. - Org Chart로 현재 조직 구조를 시각화하거나 향후 인력 계획을 세울 수 있다. - 향후 칸반 보드, 타임라인, 인라인 텍스트 편집, 향상된 임베드 미디어 지원 등으로 위젯 생태계를 확장할 계획이다. ## 플러그인으로 작업 속도 향상 - 위젯이 협업과 상호작용에 초점을 둔다면, 플러그인은 아이디어를 더 빠르게 만들고 변환하는 데 사용된다. - 당시 40개 이상의 플러그인이 제공되며, FigJam의 제작 및 자동화 가능성을 넓혔다. - Vimeo는 화면 녹화와 음성 설명을 FigJam 파일에 직접 추가하는 Vimeo Record 플러그인을 개발 중이었다. - Tour Guide를 사용하면 애니메이션 프레젠테이션을 만들 수 있다. - Create Sticky from Text는 텍스트를 자동으로 스티키 노트로 변환한다. - Stamp Counter는 투표 수를 빠르게 집계한다. - 플러그인을 통해 다른 도구로 전환하지 않고도 기록, 변환, 발표, 집계 작업을 수행할 수 있다. ## 더 개방적인 FigJam 플랫폼 - Figma는 개발자 커뮤니티와 함께 FigJam 위젯·플러그인 생태계를 구축하려 한다. - 폐쇄적인 기본 기능만 제공하는 대신, 외부 개발자가 팀별 요구사항에 맞는 기능을 만들 수 있도록 플랫폼을 개방한다. - 사용자와 개발자가 함께 어떤 협업 방식이 필요한지 실험하고, 그 결과를 제품에 반영하는 방향이다. - 임베드, 동영상과 문서 추가, 새로운 도형과 코드 블록, FigJam 툴바에서 바로 접근하는 템플릿 등도 이러한 확장 전략의 일부다. ## 실용적인 결론 FigJam은 단순한 온라인 화이트보드가 아니라 회의 진행, 아이디어 정리, 조직 설계, 접근성 관리까지 한 공간에서 처리하는 협업 플랫폼으로 발전하려 한다. 소규모 팀은 무료 플랜과 Open sessions로 빠르게 시작하고, 반복적인 업무나 조직별 요구가 있다면 위젯과 플러그인을 활용하는 것이 효과적이다.

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

Figmafigjampluginswidgets+2

datadog·2021년 10월 15일원문

쿠버네티스 상태 메트 (새 탭에서 열림)

Datadog은 대규모 Kubernetes 환경에서 오픈소스 도구인 kube-state-metrics(KSM)를 운영하며 겪은 확장성 문제를 해결하기 위해 오픈소스 커뮤니티에 직접 기여하여 성능을 대폭 개선했습니다. 기존 KSM은 수천 개의 노드와 수만 개의 포드가 있는 환경에서 지표 수집 시간이 수십 초에 달하고 데이터 용량이 비대해지는 성능 저하 문제를 안고 있었습니다. 이를 해결하기 위해 KSM v2 개발 과정에 참여하여 지표 생성 프로세스를 최적화함으로써 수집 속도를 15배 향상하고 대규모 클러스터에서도 고해상도 데이터를 안정적으로 확보할 수 있게 되었습니다. **KSM의 작동 원리와 기존의 한계** * KSM은 Kubernetes API 서버를 리스닝하며 객체의 상태 지표를 생성하는 서비스로, 인포머(Informer) 패턴을 사용해 클러스터 수준의 메타데이터를 OpenMetrics 형식으로 노출합니다. * Datadog 에이전트는 15초마다 `/metrics` 엔드포인트를 크롤링하여 데이터를 수집하며, 필요에 따라 `label_joins` 설정을 통해 메타데이터를 결합해 지표의 가독성을 높입니다. * 하지만 기존 구조에서는 쿼리 시점에 대량의 데이터가 한꺼번에 덤프되고, 지표 생성 과정에 개입할 수 있는 훅(hook)이 부족하여 성능 확장에 제약이 있었습니다. **대규모 환경에서의 확장성 병목 현상** * 리소스당 지표 생성량을 분석한 결과 노드는 약 9개, 포드는 약 40개의 지표를 생성하며, 수만 개의 포드가 있는 환경에서는 매 수집 주기마다 수백만 개의 지표를 처리해야 합니다. * 이로 인해 네트워크 호출 시간이 수십 초로 늘어나고 데이터 크기가 수십 메가바이트에 달하게 되어, 지표의 정밀도를 낮추거나 수집 주기를 강제로 늦춰야 하는 상황이 발생했습니다. * Datadog은 이를 해결하기 위해 포드, 노드, 기타 리소스별로 KSM 배포를 물리적으로 분리하는 전략을 사용했으나 이는 임시방편에 불과했습니다. **오픈소스 기여를 통한 성능 최적화** * Datadog 팀은 내부적인 수정을 넘어 KSM v2.0.0의 메인 커뮤니티와 협력하여 지표 생성 로직과 빌더(Builder) 구조를 근본적으로 개선했습니다. * 결과적으로 지표 수집 프로세스 소요 시간을 기존 대비 15배 단축하는 성과를 거두었으며, 이는 대규모 인프라 운영의 핵심적인 전환점이 되었습니다. * 이러한 경험은 오픈소스 커뮤니티에 기여하는 것이 개별 기업의 인프라 문제를 해결함과 동시에 기술적 생태계 전체의 성능을 끌어올리는 가장 효과적인 방법임을 시사합니다. **실용적인 결론 및 추천** 대규모 Kubernetes 클러스터를 운영 중이라면 KSM v2 이상의 버전을 채택하여 최적화된 지표 수집 성능을 확보하는 것이 필수적입니다. 또한 단일 KSM 배포에서 성능 저하가 발생할 경우, 본문에서 언급된 것처럼 리소스 유형별(Collectors)로 배포를 분리하여 부하를 분산하는 전략을 검토해 보시기 바랍니다.

데이터베이스 설계쿠버네티스datadog옵저버빌리티+3

datadog·2021년 10월 15일원문

Kubernetes 상태 메트릭을 한 단계 끌어올린 우리의 여정 (새 탭에서 열림)

Datadog은 대규모 쿠버네티스 환경에서 `kube-state-metrics`(KSM)를 운영하며 발생한 성능 병목 현상을 해결하기 위해 오픈소스 커뮤니티에 직접 기여했습니다. 기존의 텍스트 기반 엔드포인트 스크래핑 방식은 수백만 개의 메트릭을 처리할 때 심각한 네트워크 부하와 지연 시간을 유발했으나, 이번 개선을 통해 메트릭 수집 속도를 기존 대비 15배 향상시키는 성과를 거두었습니다. 결과적으로 대규모 클러스터에서도 데이터의 정밀도를 유지하며 안정적인 관측성을 확보할 수 있게 되었습니다. ### KSM의 기본 작동 원리와 메트릭 수집 - KSM은 인포머(Informer) 패턴을 활용하여 쿠버네티스 API 서버의 객체 상태 변화를 관찰하고 이를 Openmetrics 형식의 텍스트로 노출합니다. - Datadog 에이전트는 15초 주기로 KSM의 `/metrics` 엔드포인트를 크롤링하여 데이터를 수집하며, 이 과정에서 `label_joins` 설정을 통해 메타데이터 레이블을 결합하여 분석 가치를 높입니다. - 예를 들어, 특정 배포(Deployment)의 레이블 정보를 다른 관련 메트릭에 태그로 추가하여 다각적인 모니터링이 가능하도록 지원합니다. ### 대규모 인프라에서의 확장성 병목 현상 - 클러스터 규모가 수천 개의 노드와 수만 개의 파드로 커지면, 한 번의 수집 주기마다 처리해야 할 메트릭이 수백만 개에 달하게 됩니다. - 파드 하나당 약 40개의 메트릭이 생성되는데, 이로 인해 네트워크 호출 시 전송되는 데이터 양이 수십 메가바이트에 달하고 크롤링 시간은 수십 초까지 늘어납니다. - 이러한 지연 시간 때문에 수집 주기를 억지로 늘려야 했고, 이는 데이터의 세밀함(granularity)을 떨어뜨려 내부 사용자들의 경험을 저해하는 결과를 초래했습니다. ### 오픈소스 기여를 통한 KSM 구조 개선 - Datadog 팀은 내부적인 임시방편을 만드는 대신 KSM v2.0 릴리스 시점에 맞춰 업스트림 소스 코드에 직접 기여하는 방식을 택했습니다. - 기존 KSM v1은 빌더(Builder)가 스토어를 관리하며 쿼리 시점에 데이터를 한꺼번에 덤프하는 구조였으나, 이를 개선하여 메트릭 생성 과정에 직접 개입(Hook)할 수 있는 유연성을 확보했습니다. - 리소스 유형별로 KSM 배포를 분리(Pods, Nodes, 기타 리소스 등)하는 전략과 함께, 메트릭 생성 로직 자체를 최적화하여 대규모 데이터 처리 효율을 극대화했습니다. 대규모 쿠버네티스 환경을 운영하는 조직이라면 KSM v2.0 이상의 개선된 구조를 적극적으로 도입하고, 리소스의 양에 따라 KSM 배포를 적절히 분할하여 메트릭 수집 지연 시간을 최소화할 것을 권장합니다.

데이터베이스 설계쿠버네티스datadog옵저버빌리티+4

figma·2021년 10월 13일·4분 읽기큐레이션 요약

LiveGraph: Figma의 실시간

Figma는 실시간 협업 제품에 필요한 데이터를 안정적으로 제공하기 위해 Postgres 위에 GraphQL 기반의 실시간 데이터 계층인 LiveGraph를 구축했다. LiveGraph는 프론트엔드가 선언적으로 데이터를 구독하면 데이터베이스 복제 스트림을 읽어 밀리초 단위로 변경 사항을 반영한다. 이를 통해 수동 이벤트 메시지와 클라이언트 상태 동기화의 복잡성을 줄이고, 대규모 실시간 데이터 구독을 지원한다. ## Figma에서 실시간 데이터가 필요한 이유 - 협업자가 파일을 추가하거나 권한을 변경하면 다른 사용자 화면에도 새로고침 없이 즉시 반영되어야 한다. - 따라서 서버에서 데이터를 한 번 가져오는 것만으로는 부족하며, 클라이언트가 현재 관심 있는 데이터의 변경 사항을 계속 받아야 한다. - 인프라 팀의 목표는 제품 개발자가 데이터 전파 방식이나 WebSocket 세부 구현을 직접 관리하지 않고도 실시간 뷰를 만들 수 있게 하는 것이었다. ## 기존 방식의 한계 - 초기에는 React 프론트엔드가 Ruby HTTP 엔드포인트에서 필요한 데이터를 한 번에 받아 Redux 전역 상태에 저장했다. - 데이터 변경 시 백엔드 코드에서 관련 클라이언트에 보낼 이벤트 메시지를 직접 작성하고, 프론트엔드는 WebSocket으로 이벤트를 받아 상태를 갱신했다. - 사용자와 데이터 규모가 커지면서 모든 데이터를 한 번에 로드하기 어려워졌고, 데이터를 점진적으로 불러오면서 다음 문제가 발생했다. - 특정 데이터가 메모리에 항상 존재한다는 보장이 없어짐 - 여러 제품 영역이 같은 데이터를 사용할 때 데이터 로딩 책임이 불분명해짐 - 이벤트를 어느 시점에 보내고 받아야 하는지 관리하기 어려워짐 - 단순한 “새 파일 생성” 이벤트와 달리 권한 변경은 다른 리소스의 가시성까지 연쇄적으로 바꿀 수 있어 이벤트 설계가 복잡했다. - 데이터베이스 쓰기 순서와 실시간 메시지의 송수신 순서가 항상 일치한다는 보장도 없었다. - 그 결과 클라이언트 상태가 서버 상태의 올바른 부분집합을 반영하지 못하는 일관성 버그가 발생했다. ## GraphQL 기반 Live Query 선택 - Figma는 개발자가 실시간 데이터 구독을 선언적으로 정의할 수 있는 일반적인 프레임워크가 필요하다고 판단했다. - GraphQL을 인터페이스로 사용하면 필요한 데이터와 관계를 쿼리로 표현하고, 시스템이 해당 데이터를 자동으로 가져오고 최신 상태로 유지할 수 있다. - 여기서 말하는 GraphQL 구독은 일반적인 이벤트 스트림 구독과 다르다. - GraphQL의 전통적인 `subscription`은 이벤트 메시지를 전달하는 방식에 가깝다. - LiveGraph가 목표로 한 것은 쿼리 결과 자체를 계속 갱신하는 “Live Query” 방식이다. - 프론트엔드는 GraphQL과 유사한 쿼리를 보내고, 서버는 결과를 JSON 트리로 반환한다. - 서버에는 엔터티와 관계를 정의하는 스키마 및 그래프의 일부를 조회할 수 있는 뷰가 존재한다. ## 기존 실시간 데이터베이스 대신 자체 구축한 이유 - Figma는 이미 Postgres를 대규모로 운영하고 있었기 때문에 Firebase나 RethinkDB 같은 별도의 실시간 데이터베이스로 이전할 수 없었다. - LiveGraph는 새로운 저장소가 아니라 기존 Postgres 위에 동작하는 쿼리 엔진이 되어야 했다. - Figma의 Multiplayer 시스템은 파일 단위의 쓰기와 충돌 해결을 담당하지만, LiveGraph는 여러 데이터의 조회와 실시간 동기화를 담당한다. - Hasura, Prisma, PostGraphile 등 GraphQL 기술도 검토했지만, 대규모 동시 구독을 핵심 요구사항으로 설계된 것은 아니었다. - Figma는 실시간 구독 수가 많아질수록 데이터베이스 부하가 커지는 폴링 방식도 피하고자 했다. - 폴링은 쿼리마다 주기를 정해야 한다. - 구독 수가 늘어나면 동일한 쿼리가 반복 실행되어 데이터베이스 부하가 증가한다. - 폴링보다 변경 발생 시점에 가까운 낮은 지연 시간을 확보하기 어렵다. ## 데이터베이스 복제 스트림 기반 설계 - LiveGraph는 주기적으로 데이터를 다시 조회하는 대신 Postgres의 데이터베이스 복제 로그를 추적한다. - 복제 스트림에서 변경 사항을 읽으면 실제 데이터베이스 변경을 감지한 뒤 구독 중인 쿼리 결과를 갱신할 수 있다. - 이 방식은 폴링보다 빠른 업데이트 지연 시간을 제공한다. - 다만 LiveGraph가 데이터베이스의 전체 변경량을 읽어야 하므로, 대규모 환경에서는 확장성이 중요하다. - Figma는 여러 데이터베이스 샤드의 변경 사항을 여러 머신에 분산 처리할 수 있는 구조를 고려했다. - 최종적으로 LiveGraph를 자체 구축한 이유는 Figma의 협업 기능에서 실시간 데이터가 핵심 기능이며, 이러한 요구사항이 경쟁력으로 이어질 수 있다고 판단했기 때문이다. ## 실용적인 결론 실시간 UI를 구축할 때 클라이언트별 수동 이벤트와 전역 상태 갱신에 의존하면 데이터 규모와 기능 복잡도가 커질수록 일관성 문제가 발생하기 쉽다. 기존 Postgres를 유지해야 하고 대규모 구독이 필요하다면, GraphQL 기반 선언적 쿼리와 데이터베이스 변경 스트림을 결합하는 방식이 폴링이나 수동 이벤트보다 확장성과 유지보수성 측면에서 유리하다.

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

ReactPostgreSQLTypeScriptGraphQL+4

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

브랜칭을 만든 방법

Figma는 대규모 협업에서 실험적 변경과 승인된 디자인을 분리하기 위해 브랜칭을 구축했다. 메인 파일은 단일 진실 공급원으로 유지하고, 브랜치에서는 기존 디자인을 훼손하지 않으면서 아이디어를 탐색·검토·수정할 수 있도록 한 것이다. Figma는 소프트웨어 개발의 브랜치 개념을 그대로 복제하기보다, 클라우드 기반 멀티플레이어 협업에 맞춰 단순성과 일관성을 우선했다. ## 대규모 협업에서 자유와 구조의 균형 - 실시간 협업은 모든 사람이 같은 파일에서 작업할 수 있다는 장점이 있다. - 그러나 팀 규모가 커지면 다음과 같은 문제가 발생한다. - 승인되지 않은 변경 사항이 코드에 반영됨 - 작업 내용이 다른 사람에 의해 덮어써짐 - 진행 중인 작업(WIP)과 실제 배포 가능한 디자인을 구분하기 어려움 - 브랜치는 메인 파일을 직접 변경하지 않고 새로운 아이디어를 시도할 수 있는 탐색 공간이다. - 디자인 라이브러리에 기여하거나, 이해관계자에게 작업물을 미리 보여주거나, 실험적인 반복 작업을 진행할 때 특히 유용하다. - 충분히 검토·승인된 변경만 메인 파일에 반영함으로써 메인 파일의 무결성을 유지한다. ## 소프트웨어 브랜칭과 Figma의 차이 - 소프트웨어 개발의 브랜치는 일반적으로 변경 사항이 개발자의 로컬 컴퓨터에 저장되는 구조를 전제로 한다. - 반면 Figma 파일은 클라우드에 저장되며, 여러 사용자가 동시에 같은 파일에 접속해 변경한다. - 따라서 Figma는 다음과 같은 설계 문제를 검토해야 했다. - 메인 파일에서 여러 사용자의 동시 편집을 계속 허용할 것인가 - 브랜치에서도 여러 사람이 동시에 작업할 수 있게 할 것인가 - 기존 멀티플레이어 협업 경험에 복잡성을 얼마나 추가할 것인가 - 핵심 과제는 전통적인 버전 관리 방식을 그대로 적용하지 않고, 온라인 협업 환경에 맞는 브랜칭 모델을 만드는 것이었다. ## 단순성과 일관성을 우선한 설계 - Figma는 브랜칭과 멀티플레이어 편집을 하나의 일관된 버전 관리 방식으로 이해할 수 있도록 설계했다. - 메인 파일은 기존처럼 여러 사람이 동시에 편집할 수 있다. - 브랜치도 일반적인 Figma 파일과 동일한 방식으로 작동한다. - 편집자와 뷰어의 접근 권한 및 권한 관리 방식은 변경하지 않았다. - 사용자의 데이터가 어떤 상황에서도 안전하게 보존되도록 데이터 무결성을 우선했다. - 기능을 의도적으로 단순하게 유지하기 위해 브랜치에서 다시 브랜치를 만드는 기능은 제공하지 않았다. - 이는 기능을 많이 추가하기보다, 디자이너가 별도의 복잡한 개념을 학습하지 않고 사용할 수 있게 하려는 선택이다. ## 병합 과정에서 고려한 예외 상황 - 병합의 가장 어려운 문제는 단순히 충돌을 해결하는 것만이 아니다. - 실제 구현에서는 다음과 같은 상황도 처리해야 했다. - 사용자가 병합 내용을 검토하는 동안 원본 파일이 변경되는 경우 - 병합 작업 도중 네트워크 연결이 끊기는 경우 - 병합이 완료되기 전에 다른 사용자의 변경 사항이 추가되는 경우 - 따라서 병합 기능은 충돌 해결 알고리즘뿐 아니라, 검토 중인 상태의 일관성, 연결 손실, 동시 변경에도 사용자의 데이터가 안전하게 유지되도록 설계되어야 했다. - 제공된 글은 이러한 병합 문제를 설명하던 중 문장이 중단되어 있어, 구체적인 해결 방식 전체는 확인할 수 없다. 브랜칭은 메인 파일을 무분별한 실험의 공간으로 사용하는 대신, 승인된 결과와 진행 중인 작업을 분리하고 싶은 팀에 적합하다. 특히 디자인 시스템이나 제품 디자인을 여러 사람이 함께 관리한다면, 메인 파일은 안정적인 기준점으로 유지하고 브랜치에서 탐색·리뷰·협업한 뒤 승인된 변경만 병합하는 운영 방식을 추천할 수 있다.

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

Figmareal-time-collaboration클라우드 컴퓨팅version-control+2

datadog·2021년 9월 30일원문

Datadog의 Continuous Profil (새 탭에서 열림)

Datadog은 자바 기반 어플리케이션에서 Akka 프레임워크를 사용할 때 발생하는 예상치 못한 CPU 사용량 급증 문제를 조사하였으며, 그 원인이 `ForkJoinPool`의 비효율적인 스레드 관리임을 밝혀냈습니다. 불규칙한 작업 흐름을 가진 액터(Actor)가 과도한 스레드 활성화 및 비활성화를 유발하여 전체 CPU의 20~30%를 낭비하고 있었으나, 이를 안정적인 작업 부하를 가진 디스패처로 이동시킴으로써 문제를 해결했습니다. 이 사례는 추상화된 프레임워크 하부의 스레드 풀 동작 원리를 이해하고 프로파일링을 통해 실질적인 병목 지점을 찾는 것이 얼마나 중요한지 보여줍니다. ### 프로파일링을 통한 병목 지점 탐색 * 로그 파싱 알고리즘을 최적화했음에도 불구하고 CPU 사용량이 줄어들지 않거나 오히려 늘어나는 현상이 발생하여 Datadog Continuous Profiler를 통해 심층 분석을 수행했습니다. * 플레임 그래프(Flame Graph) 분석 결과, 실제 비즈니스 로직이 아닌 `ForkJoinPool.scan()` 및 `Unsafe.park()` 메서드에서 상당한 CPU 시간이 소비되고 있음을 확인했습니다. * 특정 스레드 풀의 상태를 조사한 결과, 별도의 설정 없이 기본 Akka 디스패처를 사용하는 `LatencyReportActor`가 이 현상의 주범으로 지목되었습니다. ### ForkJoinPool의 동작 원리와 병목 원인 * `ForkJoinPool`은 대기 중인 작업 수에 따라 내부 워커 스레드를 동적으로 생성, 중지(`park`), 재개(`unpark`)하며 활성 스레드 수를 관리합니다. * 작업 흐름이 불규칙할 경우 스레드를 빈번하게 깨우고 다시 재우는 과정에서 비용이 큰 네이티브 호출인 `Unsafe.park()`와 `unpark()`가 대량으로 발생하여 CPU를 낭비하게 됩니다. * 문제의 액터는 매초 짧은 시간 동안만 데이터를 처리하고 나머지 시간은 대기하는 특성을 가졌는데, 이때마다 CPU 코어 수만큼 설정된 32개의 스레드가 일시에 깨어났다가 다시 잠드는 현상이 반복되었습니다. ### 설정 변경을 통한 성능 최적화 * 불규칙한 작업을 수행하는 액터를 기본 디스패처에서 이미 안정적인 작업 흐름을 유지하고 있는 메인 'work' 디스패처로 이동시키는 단 한 줄의 설정 변경을 적용했습니다. * 이 변경을 통해 `ForkJoinPool.scan()`에서 소비되는 CPU 시간이 급격히 감소하였으며, 서비스 전체의 평균 CPU 사용량이 약 30% 줄어드는 성과를 거두었습니다. * 또한 32개까지 치솟았던 기본 디스패처의 스레드 풀 크기가 2개로 줄어들어 불필요한 컨텍스트 스위칭과 리소스 낭비가 해결되었음을 확인했습니다. ### 효율적인 ForkJoinPool 관리를 위한 권장 사항 `ForkJoinPool`이나 Akka를 사용하는 환경에서 성능을 유지하려면 `ForkJoinPool.scan()` 메서드의 CPU 점유율을 모니터링해야 합니다. 만약 이 수치가 10~15%를 초과한다면 다음과 같은 조치를 고려하십시오. * **액터 인스턴스 제한**: 불필요하게 많은 액터가 생성되지 않도록 조절합니다. * **스레드 풀 최대치 제한**: 워크로드에 맞춰 스레드 풀의 최대 크기를 적절히 제한합니다. * **스레드 풀 통합**: 여러 개의 풀을 사용하기보다 풀의 개수를 줄여 작업 부하가 골고루 분산되도록 유도합니다. * **태스크 큐 활용**: 급격한 작업 급증(Spike)을 완충할 수 있는 큐를 도입하여 스레드 풀이 급격하게 변동하는 것을 방지합니다.

datadogJavascalaakka+4