techlist.io
KREN

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

figma3분 읽기큐레이션 요약

Variants로 디자인과 코드의

Figma의 Variants는 하나의 컴포넌트에 존재하는 여러 변형을 하나의 컴포넌트 세트로 묶어 디자인 시스템과 코드의 구조를 가깝게 연결한다. 디자이너는 관련 변형을 쉽게 탐색·관리하고, 개발자는 상태·스타일·크기 같은 속성을 코드의 컴포넌트처럼 이해할 수 있다. Figma는 사용자 관찰과 6주간 4차례의 사용성 테스트를 통해 기능 구조와 UI, 명칭을 다듬었다. ## 디자인과 코드의 사고방식 맞추기 - 개발은 재사용성과 확장성을 중시하고, 디자인은 자유로운 반복과 탐색을 중시한다. - 기존 Figma 컴포넌트는 관련 변형을 찾거나 전환하기 어려웠고, 인스턴스 교체 메뉴가 지나치게 복잡해지는 문제가 있었다. - 디자인 시스템이 커지면서 팀들은 `default/primary/large/icon` 같은 슬래시 기반 이름 규칙을 사용해 상태와 속성을 표현했다. - Variants는 이를 `state="hover"`, `style="secondary"`처럼 **속성명:값** 구조로 발전시킨다. - 상태뿐 아니라 `type`, `color`, `size` 등 여러 차원의 속성을 지원해 코드의 컴포넌트 모델과 더 유사하게 구성할 수 있다. ## 변형을 한곳에 모으는 컴포넌트 세트 - Figma는 디자인 시스템 관리자가 변형들을 그리드에 배치하고 나란히 비교한다는 점을 관찰했다. - 이에 따라 하나의 컴포넌트에 속한 여러 Variants를 캔버스에 side-by-side로 배치할 수 있도록 설계했다. - 이 방식은 다음 작업에 유용하다. - 변형 간 시각적 비교 - 디자인 반복 작업 - 라이브러리 유지보수 - 전체 디자인 시스템 구조 파악 - 기존 컴포넌트 변형들을 모두 선택한 뒤 **Combine Variants**를 클릭하면 하나의 컴포넌트 세트로 쉽게 전환할 수 있다. ## 사용성 테스트로 다듬은 UI - Figma는 작동하는 프로토타입을 제작하고 6주 동안 네 차례 사용성 테스트를 진행했다. - 초기 UI는 모든 속성값을 pill 형태로 표시했다. - 하지만 pill은 일반적으로 여러 태그를 동시에 표시하는 요소로 인식되기 때문에, 사용자는 특정 변형의 속성을 조정하는 UI로 이해하기 어려워했다. - 최종적으로는 다음과 같이 변경했다. - 특정 Variant를 선택했을 때는 각 속성을 간단한 입력 필드와 드롭다운으로 표시 - 전체 컴포넌트 세트의 속성과 값을 한눈에 볼 때는 pill UI 유지 - 기본 속성명도 `State`, `Style`처럼 미리 정해진 용어보다 `Property 1`, `Property 2`를 사용했다. - 사용자가 이를 `Type`, `Size` 등 자신의 디자인 시스템에 맞는 이름으로 직접 커스터마이즈하도록 한 것이다. ## 기능 이름을 ‘States’에서 ‘Variants’로 변경 - 초기에는 주요 사용 사례가 버튼의 hover, active, disabled 같은 인터랙션 상태였기 때문에 기능명을 **States**로 정했다. - 그러나 사용자들은 이 이름이 기능을 상태 관리에만 한정하는 것처럼 보인다고 지적했다. - Variants는 상태뿐 아니라 색상, 크기, 유형 등 다양한 속성 조합을 표현할 수 있다. - Fidelity Investments의 피드백을 계기로 기능의 전체 범위를 더 잘 드러내는 **Variants**라는 이름을 채택했다. - 이후 사용성 테스트에서도 Variants가 기능의 목적과 확장성을 더 직관적으로 전달하는 것으로 검증됐다. ## 디자인-개발 협업을 위한 확장 - Variants는 컴포넌트의 구조를 코드와 유사하게 만들어 디자이너와 개발자가 같은 개념으로 대화하도록 돕는다. - Auto Layout 업데이트와 Inspect 패널 개선도 함께 제공되어 디자인을 구현으로 전달하는 과정이 간결해진다. - 단순한 상태 관리부터 여러 속성을 조합한 복잡한 디자인 시스템까지 동일한 방식으로 관리할 수 있다. 실무에서는 버튼, 입력창, 카드처럼 상태·크기·스타일 변형이 많은 컴포넌트부터 Variants로 통합하는 것이 효과적이다. 속성명은 팀의 코드 규칙과 일치시키고, 변형을 체계적인 속성-값 조합으로 정의하면 디자인 시스템 유지보수와 개발 협업을 모두 개선할 수 있다.

원문 읽기(새 탭에서 열림)
Figma디자인 시스템사용자 경험auto-layout+2
figma4분 읽기큐레이션 요약

기능 비하인드:

Figma의 오토세이브는 단순히 파일 전체를 주기적으로 디스크에 저장하는 기능이 아니다. 브라우저 기반 실시간 협업 환경에서는 대용량 문서, 단일 스레드 실행, 동시 편집, 충돌 해결이 서로 얽히기 때문에 전체 파일 대신 오프라인 이후의 변경분(delta)을 저장하는 방식이 적합하다. Figma는 이 변경분을 IndexedDB에 보관했다가 문서를 다시 열 때 최신 문서에 적용하고 서버로 업로드한다. ## 오프라인 작업에서 발생하는 데이터 손실 - 온라인 상태에서는 Figma가 변경 사항을 서버로 즉시 전송한다. - 하지만 인터넷 연결이 끊기면 변경 사항을 서버와 동기화할 수 없다. - 기존에는 브라우저 탭이나 컴퓨터가 종료되면 오프라인 상태에서 작업한 내용이 사라질 위험이 있었다. - 확장된 오토세이브 시스템은 문서가 서버와 연결되지 않은 시점부터 변경 사항을 디스크에 저장한다. - 이후 문서를 새 탭에서 열면 저장된 변경 사항을 복원하고 서버에 업로드한다. ## 전체 파일 저장 방식의 한계 - 가장 단순한 방법은 메모리에 있는 scenegraph 전체를 직렬화해 백업 파일로 저장하는 것이다. - Figma 문서는 레이어 노드 트리인 **scenegraph**로 표현된다. - 큰 파일은 압축된 바이너리 기준 수십 MB, 메모리상에서는 수백 MB까지 커질 수 있다. - 전체 scenegraph를 직렬화하는 데 수 초가 걸릴 수 있으며, 저장할 때마다 사용자가 지연을 경험하게 된다. - 직렬화 시간을 10~20배 줄여 100ms 수준으로 만들어도 브라우저 환경에서는 충분하지 않다. - JavaScript와 WASM이 기본적으로 단일 스레드에서 실행되기 때문이다. - 사용자는 저장 시마다 약 100ms의 끊김을 느낄 수 있다. - 작업을 여러 프레임에 나누어 실행할 수 있지만, 직렬화 중 사용자가 문서를 수정하면 어떤 상태를 저장해야 하는지 문제가 발생한다. - 변경되지 않는 immutable scenegraph를 사용하면 해결할 수 있지만, 애플리케이션 전반의 대규모 구조 변경이 필요하고 메모리 사용량과 쓰기 성능 저하라는 비용도 따른다. ## 실시간 협업이 만드는 저장 문제 - Figma 파일은 클라우드에 저장되고 여러 사용자가 동시에 편집할 수 있다. - 오프라인 백업 파일 전체를 서버의 기존 파일로 덮어쓰면, 다른 사용자가 이후에 만든 최신 변경 사항을 잃을 수 있다. - 백업 파일을 별도 복사본으로 남기는 방법도 충분하지 않다. - 일부 파일은 디자인 시스템의 버튼이나 모달 같은 공유 컴포넌트의 원본이기 때문이다. - 복사본을 만드는 순간 공유 자산의 원본과 실제 작업 내용이 분리될 수 있다. - 따라서 오토세이브는 단순한 파일 복구가 아니라, 협업 시스템의 변경 병합 및 충돌 해결 방식과 함께 설계되어야 한다. ## 전체 문서가 아닌 변경분 저장 - Figma는 전체 파일 대신 사용자가 오프라인이 된 이후 발생한 변경 사항만 저장한다. - 이 변경분은 기존 멀티플레이어 편집 시스템에서 이미 서버 전송 및 확인을 위해 관리하던 데이터다. - 전형적인 흐름은 다음과 같다. - 사용자가 문서를 불러온다. - 서버 연결이 끊긴다. - 사용자의 변경 사항이 메모리의 pending changes buffer에 쌓인다. - 일정한 간격으로 버퍼의 내용이 디스크에 저장된다. - 문서나 브라우저 탭이 예기치 않게 종료된다. - 사용자가 문서를 다시 연다. - 저장된 변경분을 역직렬화한다. - 최신 문서 위에 변경분을 적용한다. - 복원된 변경 사항을 서버에 업로드한다. - 최신 문서에 변경분을 적용하므로, 오래된 전체 백업으로 최신 서버 상태를 덮어쓰는 문제를 피할 수 있다. ## IndexedDB를 활용한 브라우저 저장 - 브라우저에서 대용량 데이터를 저장하기 위해 IndexedDB를 사용한다. - IndexedDB는 다음 요구사항에 적합하다. - 많은 양의 데이터 저장 - 데이터를 작은 단위로 나누어 저장 - 인덱스를 통한 빠른 접근 - 트랜잭션을 통한 데이터 무결성 보장 - pending changes는 파일별, 노드 또는 레이어별 속성 변경 집합으로 저장된다. - 노드 단위의 세분화는 저장 공간과 불필요한 입출력 사이의 균형을 맞춘다. - 변경 사항을 지나치게 잘게 나누면 각 레코드의 관리 오버헤드가 커진다. - 반대로 모든 노드의 변경 사항을 하나의 객체에 넣으면 일부 변경만 발생해도 전체 변경 집합을 다시 기록해야 하므로 불필요한 I/O가 증가한다. ## 실용적인 결론 대용량 실시간 협업 애플리케이션의 오토세이브는 전체 상태를 반복 저장하기보다 변경 로그나 delta를 안정적으로 보관하는 방식이 효과적이다. 특히 저장 데이터의 단위, 트랜잭션 처리, 최신 서버 상태에 변경분을 재적용하는 복구 절차를 함께 설계해야 성능 저하와 협업 데이터 덮어쓰기를 모두 줄일 수 있다.

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

킴벌리클라크가 사랑

Kimberly-Clark은 변화하는 소비자 선호와 경쟁 심화에 대응하기 위해 디지털 경험과 디자인 업무 방식을 혁신했다. Figma를 단일 협업 플랫폼으로 도입하면서 디자이너, 마케팅, 브랜드, 개발자 간 협업이 빨라졌고, 실제로 한 웹사이트의 가입률을 71% 높였다. 이 사례는 디자인 도구 통합과 실시간 협업이 제품 출시 속도와 사용자 경험을 동시에 개선할 수 있음을 보여준다. ## 디지털 중심 성장 전략 - Kleenex, Scott, Huggies 등을 보유한 Kimberly-Clark은 전 세계 175개국에서 사업을 운영한다. - 400개 이상의 소비자 대상 웹사이트와 다양한 디지털 제품을 관리하고 있다. - 소비자 취향 변화, 경쟁 심화, 생산비 증가로 성장세가 둔화되자 2022년 창립 150주년을 목표로 성장 가속화 전략을 추진했다. - 가격 책정, 제조, 유통, 진열, 영업, 인사 등 거의 모든 업무 과정에 디지털 요소가 포함되어 있었다. - 코로나19 이후에는 수요 변화에 맞춰 생산량과 재고를 재배분했으며, 해당 분기 매출은 46억 1천만 달러를 기록했다. ## 기존 디자인 프로세스의 비효율 - 디자이너들이 독점적인 Mac 기반 애플리케이션에서 혼자 수주일 동안 작업했다. - 완성한 파일을 별도의 클라우드 프로토타이핑 도구에 업로드한 뒤 이해관계자의 피드백을 기다려야 했다. - 수정이 발생하면 같은 과정을 반복해야 했다. - 개발 단계에서는 Mac을 사용하지 않는 개발자에게 디자인 파일을 전달하는 과정에서 추가적인 문제가 생겼다. - 여러 브랜드와 국가에 맞춰 디자인을 현지화해야 했기 때문에, 이러한 단절이 제품 출시 속도를 더욱 늦췄다. ## Figma를 통한 실시간 협업 - Figma를 도입해 디자인, 프로토타이핑, 피드백 과정을 하나의 웹 기반 플랫폼으로 통합했다. - 파일을 로컬에 저장할 필요가 없고, 초대받은 사람이 쉽게 파일을 열어 보고 편집할 수 있었다. - Figma를 모든 팀이 참조하는 단일 정보원으로 활용하면서 파일 버전 관리와 전달 과정이 단순해졌다. - 피드백 회의가 일방적인 검토 자리가 아니라 브랜드·마케팅·디자인·기타 이해관계자가 함께 작업하는 실시간 협업 세션으로 바뀌었다. - 참여자들이 디자인 변경 사항을 즉시 확인하고 제작 과정에 직접 참여할 수 있게 되었다. ## 데이터로 검증한 디자인 개선 - 팀은 디자인 효율성뿐 아니라 실제 사용자 경험의 개선 여부도 측정했다. - 주요 지표로 이탈률, 재방문자, 사이트 체류 시간, 쿠폰·뉴스레터·보상 프로그램 가입률 등을 추적했다. - 한 웹사이트의 가입 양식에는 마케팅 목적으로 13개의 입력 필드가 포함되어 있었다. - 브랜드, 마케팅, 디자인 팀이 Figma에서 함께 논의해 입력 필드를 5개로 줄였다. - 양식 변경 후 가입률이 71% 증가했다. - 회의에서 장시간 논쟁하기보다 문제를 함께 시각화하고 즉시 수정한 것이 성과 향상에 기여했다. ## 다음 단계: 디자인 시스템과 개발 연계 - Kimberly-Clark은 Figma에서 Storybook과 코드 저장소까지 연결되는 새로운 디자인 시스템을 계획했다. - 이를 통해 디자인 요소와 개발 구현 사이의 일관성을 높이고, 여러 브랜드와 지역에 적용 가능한 재사용 체계를 구축하려 했다. - 디자인을 단순한 산출물 제작 과정이 아니라 비즈니스 성과와 제품 출시 속도를 높이는 핵심 업무로 자리매김하려는 방향이다. 실무적으로는 디자인 도구를 많이 사용하는 것보다, 하나의 공유 환경에서 관련 팀이 함께 문제를 해결하고 결과를 사용자 지표로 검증하는 것이 중요하다. 특히 입력 단계 축소처럼 작은 디자인 변경도 데이터로 효과를 확인하면 빠른 개선과 조직 내 합의를 동시에 이끌어낼 수 있다.

원문 읽기(새 탭에서 열림)
Figma디자인 시스템사용자 경험프로토타이핑+3
figma3분 읽기큐레이션 요약

팀으로 배우고 실패하기 |

Config Europe의 발표들은 더 나은 제품을 만드는 일과 더 나은 팀원이 되는 일이 서로 연결되어 있음을 보여준다. 핵심은 디자인·개발·기획 등 다양한 구성원을 과정에 참여시키고, 실패를 숨기기보다 함께 학습하고 개선하는 문화다. Figma의 Variants 사례처럼 반복적인 테스트와 피드백은 제품의 접근성과 완성도를 높인다. ## 팀의 경계를 넓히는 디자인 시스템 - UAL의 Declan Talbert는 디자인 시스템을 단순한 패턴 라이브러리나 디자이너 전용 도구가 아니라 **서비스**로 바라봐야 한다고 설명한다. - 디자인 시스템에는 UI 컴포넌트뿐 아니라 접근성, 데이터, 프로젝트 관리 등 다양한 요소가 포함될 수 있다. - 디자이너, 개발자, 제품 관리자 등 여러 직군이 기여하고 사용할 수 있어야 시스템이 더 포용적으로 작동한다. - 다양한 전문성과 관점을 가진 사람을 디자인 프로세스에 참여시키면 인간 중심적인 제품과 서비스로 이어진다. - 개방적인 프로세스는 도구의 공유를 넘어, 기존 디자인 조직 밖의 사람들도 의사결정과 제작 과정에 참여하도록 만드는 것을 의미한다. ## 실패를 함께 받아들이기 - Figma의 제품 관리자 Kelsey Whelan과 제품 디자이너 Nikolas Klein은 다양한 관점이 더 나은 제품을 만든다고 강조한다. - 이 과정에서는 서로 앞에서 아이디어가 실패하는 상황도 발생하지만, 실패를 공동의 학습 기회로 바라보는 태도가 중요하다. - Variants 초기 버전은 기능적으로 강력했지만 사용자에게 충분히 직관적이지 않았다. - 팀은 몇 주 동안 짧게 사용성 테스트를 진행하려 했지만, 실제로는 6주 동안 네 차례의 테스트가 필요했다. - 이를 통해 팀은 제품이 예상보다 훨씬 사용자에게서 멀리 떨어져 있다는 사실을 발견했다. ## 원격 환경에서 확장한 사용성 테스트 - Figma는 원격 근무 환경을 활용해 제품에 직접 관여한 사람뿐 아니라 회사 전체 구성원을 테스트에 참여시켰다. - 디자이너 애드보케이트, 제품 교육 담당자, 엔지니어링 매니저 등 다양한 직군이 Zoom을 통해 사용성 테스트에 참여했다. - 테스트 과정에서 버그도 발견했으며, 전용 Slack 채널에서 문제와 수정 방안을 즉시 논의했다. - 아이디어가 작동하지 않는 모습을 공개적으로 확인하는 일은 어렵지만, 피드백을 반영해 사용성이 개선되는 과정은 더 큰 보람으로 이어졌다. - 다양한 참여자는 사용자 경험을 개선하는 동시에 팀 내부의 개방성과 협업도 강화했다. ## 실패를 ‘앞으로 나아가는 과정’으로 만들기 - 실패는 비난의 근거가 아니라 개선과 반복을 위한 정보로 활용되어야 한다. - 여러 사람이 초기 결과물을 함께 검토하면 문제를 더 일찍 발견하고, 특정 직군의 편견이나 사각지대를 줄일 수 있다. - 중요한 것은 실패하지 않는 것이 아니라, 실패를 공유하고 피드백을 반영해 다음 단계로 발전하는 것이다. - 이러한 문화가 자리 잡으면 팀원들은 실험과 의견 제시에 더 적극적으로 참여할 수 있다. 제품 개발에서는 디자인 시스템과 테스트 과정을 특정 팀의 전유물로 두기보다 다양한 직군에 개방하는 것이 좋다. 초기 결과가 미흡하더라도 이를 숨기지 말고, 반복적인 사용성 테스트와 명확한 피드백 채널을 통해 팀 전체가 함께 개선하는 구조를 마련해야 한다.

원문 읽기(새 탭에서 열림)
Figma디자인 시스템접근성remote-collaboration+3
figma4분 읽기큐레이션 요약

피그마의 첫 번째 학생

팬데믹으로 학생들의 캠퍼스 활동이 어려워지자 Figma는 지역별 온캠퍼스 프로그램 대신, 온라인에서도 확장 가능한 학생 지원 모델을 실험했다. 학생들을 프로그램 설계와 실행에 직접 참여시킨 결과, 10주 만에 수업 템플릿·학생 콘텐츠·Virtual Campus 커뮤니티·온라인 메이커톤 등을 만들며 큰 성과를 거뒀다. 이 펠로십은 단기 결과물뿐 아니라 향후 학생 앰배서더 및 커뮤니티 프로그램의 기반도 마련했다. ## 팬데믹에 맞춘 프로그램 방향 전환 - 처음에는 학생들을 위한 캠퍼스 내 밋업을 핵심 활동으로 계획했다. - 그러나 가을 학기에 많은 학생이 캠퍼스로 돌아가지 못할 가능성이 커지면서 계획을 재검토했다. - 학생들과 대화하며 다음과 같은 문제를 파악했다. - 가을 학기의 학교 운영 방식은 어떻게 달라지는가? - 온라인 수업에서 협업적인 교실 분위기를 어떻게 재현할 수 있는가? - 학생들이 교외 프로젝트를 함께 진행하려면 어떤 환경이 필요한가? - 이를 바탕으로 다음 네 가지 영역에 집중했다. - 수업용 리소스 - 학생들의 경험과 관점을 담은 콘텐츠 - Virtual Campus Slack 커뮤니티 - 온라인 해커톤 및 메이커톤 ## 학생이 직접 설계한 펠로십 - Figma는 학생들이 실제로 유용하고 즐겁게 사용할 수 있는 것을 직접 만들도록 프로그램에 참여시켰다. - 목표는 단순히 콘텐츠를 출시하는 것이 아니라 학생 커뮤니티에 장기적으로 영향을 줄 수 있는 협업 방식을 구축하는 것이었다. - 학생 커뮤니티뿐 아니라 Figma 내부 구성원과 더 넓은 디자인 생태계까지 연결하는 것을 지향했다. - 결과물은 학생들이 쉽게 접근할 수 있으면서도 성장 의욕을 자극하는 수준을 목표로 했다. - 여러 작업 흐름으로 나뉘어 일했지만, 참가자들은 하나의 cohesive한 팀으로 협력했다. ## 교실용 템플릿과 학습 자료 - 10주 동안 온라인 및 오프라인 수업에서 활용할 수 있는 템플릿 6개를 제작했다. - 대표적인 자료는 다음과 같다. - 리서치 프로젝트를 운영하기 위한 툴박스 - Figma 에디터에 익숙해지기 위한 플레이그라운드 파일 - 수업 과제를 배포하기 위한 템플릿 - 커뮤니티 곳곳에 흩어진 Figma 교육 자료도 선별해 교사와 학생이 학습·제작에 활용할 수 있도록 정리했다. - 특정 학교나 지역에 한정되지 않고 다양한 교실에서 사용할 수 있도록 범용성을 고려했다. ## 학생들의 현실적인 고민을 다룬 콘텐츠 - 학생들과 대화하면서 많은 학생이 “갭 이어를 선택해야 하는가?”라는 고민을 공유하고 있음을 발견했다. - 이에 따라 ‘Back To School?’ 영상 시리즈를 제작했다. - Figma CEO 딜런 필드가 마크 앤드리슨, 메이리 코, 칼리 클로스, 존 마에다, 로라 데밍 등을 인터뷰했다. - 인터뷰에서는 갭 이어의 의미와 교육의 가치, 각자의 진로 경험을 다양한 관점에서 다뤘다. - 학생 펠로우 Abigail Africa는 청중 분석, 자신감 있는 발표, 스토리텔링을 중심으로 피칭과 프레젠테이션 방법을 소개했다. ## Virtual Campus와 온라인 커뮤니티 - 여름 동안 1,000명 이상의 학생이 Slack 기반 Virtual Campus에 새로 참여했다. - 커뮤니티의 목적은 학생들이 서로 연결되고, 가르치고, 배우며 함께 즐길 수 있는 공간을 제공하는 것이었다. - 물리적인 캠퍼스를 이용할 수 없는 상황에서 온라인 커뮤니티가 소속감과 협업을 보완하는 역할을 했다. - 다양한 시간대의 학생 수백 명이 참여한 2일간의 온라인 메이커톤 ‘Camp Figma’도 개최했다. - 참가자들은 함께 제작 활동을 진행했으며, FigmAdventure와 Slice 같은 프로젝트가 우수작으로 선정됐다. ## 프로그램의 성과와 확장 가능성 - 이 프로그램은 학생 대상 지원을 단순한 교육 자료 제공에서 커뮤니티·콘텐츠·협업 경험을 포함한 종합적인 모델로 확장했다. - 학생들이 수혜자에 머무르지 않고 직접 문제를 정의하고 해결책을 제작했다는 점이 특징이다. - Figma는 이번 실험을 바탕으로 향후 펠로십 프로그램을 발전시키고, 캠퍼스 앰배서더 및 Friends of Figma와 연계할 기반을 마련했다. - 지역적 오프라인 활동이 어려운 상황에서도 온라인 리소스와 커뮤니티를 통해 더 넓은 학생층에 도달할 수 있음을 보여줬다. 학생 대상 프로그램을 만들 때는 일방적으로 콘텐츠를 제공하기보다 대상 학생을 초기 기획 단계부터 참여시키는 것이 효과적이다. 특히 재사용 가능한 템플릿, 지속적인 커뮤니티, 실제 고민을 다루는 콘텐츠를 함께 설계하면 일회성 행사를 넘어 장기적인 참여와 확장성을 확보할 수 있다.

원문 읽기(새 탭에서 열림)
Figma프로토타이핑collaborative-designslack+2
figma3분 읽기큐레이션 요약

Figma의 에이전시 파

Figma는 디자인 시스템의 구축·이전·확장을 지원하기 위해 전문 디자인·디지털 에이전시들과 파트너십을 맺었다. 디자인 시스템은 단순한 UI 패턴 모음이 아니라 디자인과 코드가 공유하는 언어이자 조직의 단일 진실 공급원이며, 에이전시 파트너는 이를 실제 업무 프로세스와 브랜드 전략에 연결한다. 이를 통해 조직은 협업의 일관성, 효율성, 개발·디자인 간 소통을 강화할 수 있다. ## 디자인 시스템의 역할 - 디자인 시스템은 패턴 라이브러리나 스티커 시트에 그치지 않고, 디자인과 코드 양쪽을 아우르는 **공유 언어**다. - 자유로운 디자인 탐색과 코드의 구조·엄격성을 동시에 지원한다. - 팀 전체의 작업 속도와 효율성을 높이고, 일관된 결과물을 만들도록 돕는다. - 조직 내에서 디자인과 브랜드 관련 의사결정의 **단일 진실 공급원(single source of truth)** 역할을 한다. - 다만 기존 도구에서 시스템을 이전하거나, 구조를 설계하고, 규모에 맞게 운영하는 일은 복잡할 수 있다. ## Figma 에이전시 파트너가 제공하는 지원 파트너들은 다양한 규모와 산업의 조직을 대상으로 디자인 시스템의 도입부터 운영 확장까지 지원한다. ### 디자인 시스템 구축 및 이전 - 기존 디자인 도구 스택을 Figma로 이전할 수 있도록 지원한다. - 이미 Figma를 사용하는 팀에도 브랜드와 조직 특성에 맞는 파일·컴포넌트·라이브러리 구조를 제안한다. - 디자인 시스템을 처음 구축하거나 기존 시스템을 재정비할 때 실무적인 모범 사례를 제공한다. - 조직의 규모와 팀 구성에 맞춰 시스템의 기반을 설계한다. ### 프로세스와 워크플로 개선 - 디자인 시스템은 구축 이후의 유지·관리 방식도 중요하므로 운영 원칙과 프로세스를 수립한다. - 팀이 시스템을 어떻게 사용하고 업데이트할지에 대한 가이드라인을 제시한다. - 디자인과 개발 사이의 협업 프레임워크를 마련한다. - 도구나 팀 간 커뮤니케이션에서 발생하는 불일치와 비효율을 줄인다. - 디자인이 조직의 전략적 파트너로 기능할 수 있도록 업무 흐름을 개선한다. ### 브랜드 정의와 확장 - 디자인 시스템을 브랜드의 시각적·경험적 표현과 연결한다. - 컴포넌트 구조나 구현 방식뿐 아니라 브랜드를 제품과 서비스에 반영하는 전략도 지원한다. - 여러 브랜드나 제품군으로 확장할 때 일관성을 유지하도록 돕는다. - 디자인 시스템을 통해 조직 구성원이 브랜드를 동일한 방향으로 해석하고 실행하도록 한다. ## 파트너십이 강조하는 협업 방식 - Figma의 실시간 협업 환경을 활용해 에이전시와 고객이 같은 작업 공간에서 공동 제작할 수 있다. - BASIC®은 Figma가 고객과의 공동 창작을 빠르고 쉽게 만들며, 협업·효율성·조직화의 잠재력을 높였다고 평가했다. - Idean은 여러 도구와 팀 사이의 커뮤니케이션 단절이 불일치와 비효율을 만든다고 설명하며, Figma가 고객과 에이전시를 같은 화면에 연결한다고 강조했다. - 결과적으로 투명성, 협업 속도, 의사결정의 집중도가 높아진다. ## Figma의 초기 에이전시 파트너 Figma는 당시 세계적인 디자인·디지털 에이전시 8곳과 파트너십을 발표했다. - BASIC® - frog - HUGE - Idean - One North - R/GA - The(stylized agency logo in the article) - Work & Co BASIC®의 사례로는 Herman Miller와 함께 여러 브랜드에 걸쳐 확장 가능한 디자인 시스템을 구축한 프로젝트가 소개된다. 이들 파트너는 브랜딩, 디지털 제품, 전자상거래, 서비스 디자인 등 다양한 분야의 경험을 바탕으로 Figma 활용을 지원한다. 실무적으로는 디자인 시스템을 단순히 만들어 두는 것보다 구조, 운영 원칙, 디자인·개발 협업 방식, 브랜드 확장 전략을 함께 설계하는 것이 중요하다. 다만 글은 2020년 자료이므로, 현재 이용 가능한 파트너와 서비스 범위는 최신 Figma Service Partners 페이지에서 확인해야 한다.

원문 읽기(새 탭에서 열림)
Figma디자인 시스템design-toolsdesign-to-development+1
datadog3분 읽기큐레이션 요약

Python 프로파일러를 작성한

Datadog이 Gartner의 **2026년 Observability Platforms Magic Quadrant에서 Leader로 선정되었다**는 소식과 관련 링크를 소개하는 홍보성 페이지입니다. 제공된 내용에는 Datadog의 관측성·보안·애플리케이션 성능·디지털 경험·소프트웨어 개발 전반의 제품군이 나열되어 있지만, Gartner의 평가 기준이나 경쟁사 비교, 선정 근거는 포함되어 있지 않습니다. ### Gartner Magic Quadrant 리더 선정 - Datadog은 Gartner의 **Observability Platforms 부문 Magic Quadrant**에서 Leader로 소개됩니다. - 연결된 자료는 2026년 Gartner 보고서 다운로드 또는 안내 페이지로 보입니다. - 다만 제공된 본문만으로는 다음과 같은 구체적인 평가 내용은 확인할 수 없습니다. - Gartner의 평가 기준 - Datadog의 실행 능력 및 비전 점수 - 경쟁 업체와의 비교 - 강점과 개선점 - 보고서의 조사 대상 및 방법론 ### 인프라 및 애플리케이션 관측성 - 인프라 영역에서는 다음 기능을 제공합니다. - 인프라 모니터링 - 메트릭 수집 및 분석 - 컨테이너와 Kubernetes 모니터링 - 네트워크 및 서버리스 모니터링 - 클라우드 비용, 스토리지, GPU 모니터링 - 애플리케이션 영역에는 다음 기능이 포함됩니다. - APM(Application Performance Monitoring) - 서비스 간 동작을 분석하는 Universal Service Monitoring - Continuous Profiler를 통한 코드 실행 성능 분석 - Dynamic Instrumentation을 이용한 실행 중 애플리케이션 관찰 - AI 에이전트의 동작을 관찰하는 Agent Observability ### 로그·데이터 관측성 - 로그 관리와 보안 분석을 위한 기능을 제공합니다. - Log Management - Sensitive Data Scanner - Audit Trail - Observability Pipelines - 데이터 시스템을 대상으로 다음 정보를 관찰할 수 있습니다. - 데이터베이스 성능 - 데이터 스트림 지연 및 병목 - 데이터 품질 - 데이터 처리 작업과 배치 잡 상태 ### 보안 플랫폼 통합 - Datadog은 관측성 제품뿐 아니라 애플리케이션과 클라우드 보안 기능도 함께 제공합니다. - 주요 영역은 다음과 같습니다. - SAST, IAST, 소프트웨어 구성 분석(SCA) - IaC 및 클라우드 보안 - 취약점 관리와 권한 관리 - Cloud SIEM 및 워크로드 보호 - API·애플리케이션 보호 - 시크릿 스캐닝과 민감 데이터 탐지 - 관측성 데이터와 보안 데이터를 하나의 플랫폼에서 연계하려는 방향을 보여줍니다. ### 디지털 경험과 소프트웨어 전달 - 사용자 경험 분석 기능으로 다음 제품군이 제시됩니다. - 브라우저·모바일 RUM - 세션 리플레이 - Synthetic Monitoring - 에러 추적 - 제품 분석 및 실험 기능 - 소프트웨어 개발과 배포 영역에는 다음이 포함됩니다. - CI Visibility - 테스트 최적화 및 지속적 테스트 - 코드 커버리지 - 기능 플래그 - 내부 개발자 포털 - IDE 플러그인 ### AI와 운영 자동화 - AI 관련 기능으로 AI 에이전트 관측성, GPU 모니터링, AI 통합 기능이 소개됩니다. - Bits AI Agents, Bits Chat, Bits Investigation 등은 장애 분석과 운영 자동화를 지원하는 제품군으로 제시됩니다. - 서비스 관리 영역에서는 다음 기능을 제공합니다. - 이벤트 관리 - 인시던트 대응 - SLO 관리 - 워크플로 자동화 - 서비스 카탈로그 - Watchdog 기반 이상 탐지 ### 플랫폼 중심의 제품 전략 - 대시보드, 알림, 노트북, 접근 제어, 거버넌스 콘솔 등 공통 플랫폼 기능도 함께 제공됩니다. - 전체적으로 Datadog은 인프라·애플리케이션·로그·보안·사용자 경험·개발 프로세스를 단일 플랫폼으로 통합하는 전략을 강조합니다. - 제공된 자료는 독립적인 기술 분석보다는 Datadog의 광범위한 제품 포트폴리오와 Gartner 리더 선정 사실을 홍보하는 데 초점이 맞춰져 있습니다. Gartner 평가의 의미를 정확히 판단하려면 연결된 원문 보고서에서 평가 기준, 점수, 경쟁사 위치, Gartner의 강점·주의점 분석을 추가로 확인해야 합니다.

원문 읽기(새 탭에서 열림)
쿠버네티스datadog옵저버빌리티애플리케이션 성능 모니터링+3
datadog원문

우리가 Python 프로파일러를 작성한 방법 (새 탭에서 열림)

Datadog은 Java의 효율적인 상시 가동형 프로파일러에서 영감을 얻어, 서비스 성능 저하 없이 운영 환경에서 지속적으로 실행 가능한 Python용 통계적 프로파일러를 개발했습니다. 기존의 결정론적 프로파일러는 높은 오버헤드로 인해 실서비스 적용이 불가능했으나, 통계적 샘플링 기법과 모듈화된 설계를 통해 실제 사용자 부하가 걸리는 운영 환경의 성능 데이터를 정밀하게 분석할 수 있게 되었습니다. ## 결정론적 프로파일러의 한계와 실서비스 적용의 어려움 * Python의 표준 도구인 `cProfile`은 모든 함수 호출을 추적하는 결정론적(Deterministic) 방식을 사용하지만, 이는 운영 환경에 적합하지 않습니다. * 모든 함수 호출을 기록할 경우 오버헤드가 2~3배까지 증가하여 실제 서비스 성능을 심각하게 저하시킬 수 있습니다. * 반대로 함수 단위가 크고 단순한 코드에서는 추적할 데이터가 부족하여 프로그램의 동작을 제대로 이해하기 어렵다는 단점이 있습니다. * 결과적으로 운영 시스템에서 항상 켜놓고(Always-on) 사용할 수 있는 가벼운 프로파일링 도구가 Python 생태계에는 부족했습니다. ## 프로덕션 환경 프로파일링의 필요성 * 개발용 노트북과 실제 프로덕션 환경은 하드웨어, 데이터 타입, 동시성 수준 등 모든 면에서 다르기 때문에 운영 환경에서의 데이터 수집이 필수적입니다. * "우리가 무엇을 모르는지"를 파악하기 위해서는 실제 워크로드를 처리하는 애플리케이션의 동작을 직접 관찰해야 합니다. * 실제 데이터에 기반하지 않은 최적화는 오히려 성능을 해치는 "조기 최적화(Premature optimization)"의 함정에 빠질 위험이 큽니다. ## 통계적 프로파일링의 메커니즘과 장점 * 통계적 프로파일링은 모든 이벤트를 기록하는 대신, 수 밀리초 단위로 프로그램 상태를 간헐적으로 샘플링하여 관찰합니다. * 개별 함수 호출을 놓칠 수는 있지만, 장시간 수집된 데이터는 프로그램의 리소스 소비 현황을 매우 정확하고 신뢰성 있게 대변합니다. * 오버헤드가 극도로 낮기 때문에 프로파일링을 하지 않을 때와 거의 동일한 환경에서 애플리케이션의 실제 성능을 측정할 수 있습니다. ## Datadog Python 프로파일러의 구조와 특징 * **JDK Flight Recorder 기반 설계**: Recorder(데이터 저장), Collector(데이터 수집), Exporter(외부 전송), Scheduler(주기 관리)로 구성 요소를 모듈화했습니다. * **스택 컬렉터(Stack Collector)**: 핵심 컴포넌트로, 초당 100회씩 모든 Python 스레드의 실행 스택, CPU 사용 시간, 예외 처리 정보 등을 수집합니다. * **낮은 오버헤드 유지**: 프로파일러가 스스로의 성능 소비를 측정하여 시스템 부하를 능동적으로 조절함으로써 서비스 영향을 최소화합니다. * **확장성**: CPU 사용량뿐만 아니라 메모리 할당 등 다양한 데이터를 수집할 수 있도록 확장 가능한 수집기 구조를 채택했습니다. 최적화의 방향을 잡지 못해 고민 중이라면, 개발 환경의 짐작이 아닌 프로덕션 환경의 실제 데이터를 보여주는 통계적 프로파일러 도입을 권장합니다. 이는 서비스 성능 저하 없이 코드 수준의 병목 지점을 파악할 수 있는 가장 확실한 방법입니다.

datadogPythonJavaprofiling+4
figma3분 읽기큐레이션 요약

연결의 순간 만들기 | Figma

디자인은 기능과 완성도만 높이는 일이 아니라, 사람과 조직을 연결하고 의미 있는 경험을 만드는 일이다. Config Europe의 사례들은 사용자 여정을 전체적으로 바라보고, 개인의 성품과 진정성을 브랜드에 반영하며, 기술을 통해 소속감과 인간적 연결을 강화해야 한다고 말한다. 결국 전문성을 갈고닦는 동시에 인간다움을 함께 발전시키는 것이 중요하다. ## 조직 전체를 바꾸는 사용자 경험 - 핀란드 우편 기업 Posti Group은 디지털 청구서와 편지의 확산에 대응해 단순히 새 앱을 만드는 데 그치지 않고, 수백 년 된 조직의 고객 경험 전체를 현대화하려 했다. - 이를 위해 디자인을 중심에 두고 다음 네 가지 원칙을 세웠다. - **성장(Grow):** 변화하는 사용자의 요구에 맞춰 발전한다. - **감동(Delight):** 실망스러운 경험을 긍정적인 경험으로 전환한다. - **감소(Reduce):** 안정적이고 신뢰할 수 있는 서비스를 제공한다. - **경청(Listen):** 고객이 자신의 필요를 직접 표현할 수 있게 한다. - 특정 산출물이나 디지털 접점 하나가 아니라, 고객이 서비스를 이용하는 전체 여정을 통합적으로 바라보는 접근이다. - 우편 서비스는 효율적인 기능을 제공하지만, 실제로는 사랑의 편지, 세금 고지서, 신생아의 사회보장 카드처럼 사람들의 중요한 감정과 사건을 전달한다. - 따라서 디자인은 서비스의 기능뿐 아니라 그 서비스가 사람들의 삶에서 어떤 의미를 만들어내는지도 고려해야 한다. ## 기술보다 중요한 디자이너의 성품 - ConvertKit의 Charli Marie Prangley는 디자이너의 평판이 뛰어난 랜딩 페이지나 아름다운 로고를 만드는 능력만으로 결정되지 않는다고 설명한다. - 개인의 브랜드는 다음 두 요소로 구성된다. - 디자이너로서의 **기술과 전문성** - 어떤 사람인지 보여주는 **성품과 태도** - 고객을 확보하거나 좋은 직장을 얻고 커뮤니티에서 신뢰를 쌓으려면, 사람들이 자신을 어떤 사람으로 기억하길 원하는지 먼저 생각해야 한다. - 창의적이고 친절하며 재미있는 사람인지 등 자신의 가치와 성격을 정의하면, 온라인 활동과 작업물이 실제 자신을 제대로 반영하는지 점검할 수 있다. - 다른 사람을 모방하기보다 자신의 관점과 개성을 진정성 있게 드러내는 것이 중요하다. 진솔한 관점을 가치 있게 여기는 사람은 반드시 존재한다. ## 기능과 감정을 함께 설계하기 - Ueno의 Halli Thorleifsson은 웹사이트나 앱을 단순한 기능적 산출물로 보지 말고, 의미 있는 목적을 가진 작업으로 바라봐야 한다고 강조한다. - 중요한 것은 도구나 디자인 시스템 자체가 아니라, 그것을 사용해 무엇을 만들고 왜 만드는가이다. - 좋은 도구는 팀의 협업을 돕는 데서 끝나지 않고, 사람 사이의 연결과 공동체 의식을 가능하게 해야 한다. - 원격 근무가 확산된 상황에서는 기술이 사람들을 고립시키는 것이 아니라 서로 연결하고 소속감을 느끼게 하는 방향으로 사용되어야 한다. - 디자인의 결과물에는 기능뿐 아니라 감정, 의미, 인간적인 경험이 함께 담겨야 한다. ## Config Europe가 보여준 연결의 가치 - Figma의 첫 가상 사용자 콘퍼런스인 Config Europe에는 150개국에서 약 1만 명이 참여했다. - 참가자들은 온라인 네트워킹, 채팅, Friends of Figma 그룹 등을 통해 발표 내용을 배우는 것뿐 아니라 서로 관계를 형성했다. - 글은 콘퍼런스의 가장 중요한 성과가 새로운 디자인 지식보다 커뮤니티 안에서 만들어진 연결일 수 있다고 말한다. - Halli의 결론은 다음과 같다. - 자신의 전문 기술을 끊임없이 연마할 것 - 동시에 인간다움과 타인과의 관계를 발전시킬 것 일과 제품을 설계할 때 기능적 목표만 세우지 말고, 그것이 사용자와 팀, 커뮤니티에 어떤 감정과 연결을 만들어내는지 함께 정의하는 것이 좋다. 전문성은 신뢰를 만들지만, 진정성과 인간적인 태도는 사람들이 오래 기억하는 관계를 만든다.

원문 읽기(새 탭에서 열림)
Figma디자인 시스템사용자 경험remote-collaboration+1
figma3분 읽기큐레이션 요약

개방적이고 포용

프로세스는 팀의 협업 방식뿐 아니라 제품이 얼마나 개방적이고 포용적인지도 결정한다. 좋은 디자인은 핵심 사용자와 이상적인 사용 사례를 넘어 다양한 환경·능력·문화의 사용자를 고려하고, 디자인·개발·현지화 팀이 초기부터 함께 검토하는 구조를 갖춰야 한다. 특히 원격 근무 환경에서는 업무 현황과 가용 시간을 투명하게 공유하는 루틴이 중요하다. ## 이상적인 사용 사례를 넘어선 사용자 이해 - 대표 페르소나와 핵심 사용 사례만을 기준으로 삼으면 실제 사용 환경의 복잡성을 놓치기 쉽다. - 제품을 직접 사용하는 사람뿐 아니라 배달원처럼 제품의 결과물을 전달하거나 운영하는 사람의 상황도 체험해야 한다. - 예를 들어 배달 앱은 다음과 같은 현실적 제약을 고려해야 한다. - 고장 난 엘리베이터 대신 계단을 이용해야 하는 상황 - 외진 지역에서 GPS가 작동하지 않는 상황 - 사용자의 범위를 넓혀 바라보면 접근성 문제도 더 구체적으로 발견할 수 있다. - 문구를 단순화하고, 색상 대비·글자 크기·레이아웃을 개선하는 것부터 시작할 수 있다. - 접근성은 장애뿐 아니라 특정 상황에서 일시적으로 발생하는 제약도 포함한다. - 시끄러운 장소에서 소리를 듣기 어려운 경우 - 휴대폰 화면이 깨진 경우 - 조직 내에서 접근성 개선을 책임질 담당자를 명확히 정해야 지속적인 변화로 이어진다. - 특정 사용자에게 필수적인 기능은 결과적으로 모든 사용자에게도 유용할 수 있다. ## 현지화를 제품 개발의 일부로 만들기 - 현지화는 단순히 문구를 번역하는 작업이 아니라 다음 요소를 함께 고려하는 과정이다. - 언어별 문장 구조와 문법 - 문화적 뉘앙스 - 번역된 문구가 실제 화면에 들어갈 수 있는지 여부 - Deliveroo는 기존에 디자이너가 경험을 설계한 뒤 개발자에게 넘기고, 개발자가 번역 문구마다 화면을 수동으로 확인하는 방식으로 작업했다. - Phrase Figma 플러그인을 도입해 디자이너가 여러 언어의 디자인을 빠르게 만들고 공유할 수 있도록 개선했다. - 이 방식으로 현지화 팀은 개발 전에 다음 문제를 발견할 수 있었다. - 번역이 부정확한 문제 - 번역문이 화면 영역을 초과하는 문제 - 현지화 담당자는 전체 사용자 흐름을 한 번에 확인하고 초기 단계에서 피드백을 제공할 수 있다. - 결과적으로 현지화는 디자인팀과 현지화팀 사이의 일회성 인계가 아니라, 글로벌 사용자 여정을 함께 설계하는 제품 개발 과정으로 바뀌었다. ## 조직 전체의 긴밀한 협업 - 포용적인 제품을 만들려면 디자인팀 내부뿐 아니라 디자인·개발·현지화 등 관련 조직이 일찍부터 협력해야 한다. - 기존의 순차적 핸드오프 방식은 문제를 늦게 발견하게 만들고, 이미 구현된 화면을 다시 만드는 비용을 높인다. - 가벼운 프로토타입을 공유하면 각 팀이 자신의 전문성을 디자인 단계에서 반영할 수 있다. - 협업 과정에서 중요한 것은 단순히 시간을 절약하는 것뿐 아니라, 각 팀이 전체 사용자 경험과 제품 맥락을 이해하는 것이다. ## 원격 환경에서 투명한 팀 프로세스 만들기 - 원격 근무에서는 사무실에서 자연스럽게 얻던 공간적·시각적 정보가 사라지므로 업무 상황을 더 의도적으로 공유해야 한다. - 팀 구성원이 무엇을 하고 있는지, 회의에 얼마나 참여할 수 있는지 파악할 수 있도록 업무 시간을 시각화할 필요가 있다. - Team Capacity Template과 같은 도구를 활용하면 다음 정보를 공유할 수 있다. - 각자의 주간 업무 일정 - 회의 가능 시간 - 업무량의 공백이나 과부하 - 정기적인 회의와 짧은 스탠드업은 업무 진행 상황뿐 아니라 개인적인 안부를 확인하는 역할도 한다. - 사무실의 즉흥적인 대화와 브레인스토밍을 보완하기 위해 자유롭게 참여하고 나갈 수 있는 화상 작업 세션을 운영할 수 있다. - 원격 상황에서는 효율성만을 앞세우기보다 팀이 현재 상황을 견뎌내는 데 필요한 소통과 관계 형성에 충분한 시간을 배정해야 한다. 실무적으로는 프로젝트 초기에 다양한 사용자와 실제 사용 환경을 점검하고, 현지화·접근성 담당자를 디자인 리뷰에 참여시키는 것이 좋다. 또한 원격 팀이라면 업무 가시성과 정기적인 협업 시간을 명시적인 프로세스로 만들어야 포용적인 제품과 건강한 협업 문화를 함께 구축할 수 있다.

원문 읽기(새 탭에서 열림)
Figma접근성remote-collaborationuser-experience-design+2
figma3분 읽기큐레이션 요약

폰트가 깨질 때

폰트 폴백(font fallback)은 현재 글꼴에 필요한 글리프가 없을 때 다른 글꼴이나 대체 표시를 사용하는 컴퓨터 타이포그래피机制이다. 네모 상자, 깨진 이모지, 플랫폼마다 다르게 보이는 특수문자, 이모지 삽입 후 줄이 내려가는 현상 등은 대부분 이 메커니즘과 관련 있다. 이는 단순한 버그라기보다, 서로 다른 글꼴·문자 집합·운영체제가 텍스트를 처리하는 과정에서 발생하는 필연적인 결과다. ## 일상에서 나타나는 폰트 폴백 - 지원되지 않는 문자는 네모 상자, 물음표, 십자가가 들어간 상자 등으로 표시될 수 있다. - 발신자와 수신자의 환경에 설치된 글꼴이나 지원하는 문자 범위가 다르면 같은 이모지가 분해되거나 전혀 다른 모양으로 보인다. - 트위터 등에서 보이는 ‘특수 폰트’는 실제 글꼴을 바꾼 것이 아니라 유니코드의 다른 문자나 기호를 조합한 경우가 많다. - 이런 문자는 화면에서는 장식적으로 보일 수 있지만, 스크린 리더가 부자연스럽게 읽거나 다른 환경에서 빈 상자로 표시될 수 있다. - 이모지를 추가했을 때 줄 높이나 기준선이 변하는 것도 해당 글리프의 크기와 글꼴 메트릭이 기존 텍스트와 다르기 때문이다. - 카오모지나 결합 문자는 플랫폼·폰트별 지원 차이로 정렬과 모양이 달라질 수 있다. ## 글리프와 글꼴의 문자 범위 - 글리프는 글꼴이 실제로 그려내는 문자 모양을 뜻한다. 문자 자체와 글리프는 구분되지만, 글에서는 이해를 돕기 위해 대략적인 의미의 ‘문자’로 설명한다. - 서유럽권 글꼴도 대문자·소문자·숫자·문장 부호·악센트·기호 등을 포함해 수백 개의 글리프가 필요하다. - 중국어·일본어 글꼴은 수천 개의 한자를 포함해야 하므로 필요한 글리프 수가 훨씬 많다. - 합자(ligature), 숫자 스타일, 대체 글자 모양 같은 OpenType 기능을 지원하려면 기본 문자 외의 글리프도 추가해야 한다. - 라틴 문자만 지원하더라도 서유럽, 중부 유럽, 그리스어, 키릴 문자, 베트남어 등으로 범위를 넓히면 글리프 수가 계속 증가한다. - 모든 문자를 하나의 글꼴에 넣는 것은 현실적으로 어렵기 때문에 글꼴 제작자는 지원 범위를 선택해야 한다. ## `.notdef`: 글꼴이 모르는 문자의 표시 - 글꼴이 요청받은 문자를 포함하지 않을 때 사용하는 마지막 대체 글리프의 이름이 `.notdef`다. - 일반적으로 사각형, 십자가가 있는 상자, 물음표가 들어간 상자 등으로 표시된다. - `.notdef`는 특정 유니코드 문자가 아니라, 해당 글꼴 내부에서 “이 문자를 표현할 수 없다”는 사실을 나타내는 글리프다. - 화면에 네모가 표시되어도 내부의 텍스트 데이터가 네모 문자로 바뀌는 것은 아니다. - 따라서 텍스트를 복사하면 원래 문자가 유지되며, 나중에 해당 문자를 지원하는 글꼴로 바꾸면 제대로 표시될 수 있다. - 표시 모양과 크기는 글꼴 디자이너가 정하므로 글꼴마다 빈 사각형, 십자가, 장식된 상자 등 다양한 형태가 나타난다. ## 금속 활자와 디지털 글꼴의 차이 - 금속 활자 시대에는 글자와 글꼴의 활자가 물리적으로 결합되어 있어, 존재하지 않는 문자를 출력하려는 문제가 상대적으로 적었다. - 디지털 환경에서는 텍스트와 글꼴이 분리되어 있다. - 사용자는 다른 사람이 오래전에 작성한 텍스트나, 작성 당시 존재하지도 않았던 글꼴이 필요한 문자를 열 수 있다. - 이 때문에 글꼴은 자신이 표현할 수 없는 문자를 만났을 때 `.notdef` 같은 대체 수단으로 응답해야 한다. - 폰트 폴백은 이러한 디지털 텍스트 환경에서 서로 다른 문자 집합과 글꼴을 연결하는 핵심 장치다. ## 실용적인 결론 특수문자나 이모지를 사용할 때는 상대방의 운영체제와 글꼴 지원 여부가 다를 수 있음을 고려해야 한다. 장식용 유니코드 문자는 접근성과 호환성이 떨어질 수 있으므로 중요한 정보에는 일반 텍스트를 함께 제공하고, 디자인 작업에서는 여러 글꼴과 환경에서 폴백 결과를 확인하는 것이 좋다.

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

제품 팀의 Figma 협업

Figma는 개방형 API와 플러그인을 통해 제품 개발 전 과정의 협업 도구와 연결될 수 있다고 설명합니다. Confluence, GitLab, Avocode, Pendo, Bubble 등의 통합을 활용하면 문서화·개발 협업·디자인 핸드오프·고객 피드백·프로토타입 구현을 하나의 흐름으로 이어갈 수 있습니다. 결과적으로 최신 디자인을 여러 도구에 반복해서 옮기거나 정보를 찾기 위해 도구를 오가는 수고를 줄이고, 디자인에서 출시까지의 속도를 높일 수 있습니다. ## 개방형 디자인 플랫폼의 필요성 - 제품 디자인은 Figma에서 진행하더라도 실제 개발·테스트·출시는 개발자와 제품 관리자용 도구에서 이루어집니다. - Figma의 개방형 API와 통합 기능을 사용하면 팀이 기존 업무 도구 안에서 디자인을 활용할 수 있습니다. - 통합의 주요 목적은 다음과 같습니다. - 제품 문서에 최신 디자인 반영 - 개발 이슈와 디자인을 연결 - 개발자가 디자인 사양과 에셋을 쉽게 확인 - 실제 사용자에게 프로토타입을 테스트 - 코드 작성 없이 디자인을 웹 앱으로 구현 ## Confluence: 최신 디자인을 제품 문서에 삽입 - Figma 파일과 프로토타입을 Confluence 페이지에 라이브 임베드할 수 있습니다. - 제품 사양서와 요구사항 문서 안에서 디자인을 직접 확인할 수 있어 개발자가 별도 링크나 오래된 스크린샷을 찾을 필요가 없습니다. - Figma 파일이 변경되면 문서에 표시되는 디자인도 최신 상태로 유지됩니다. - 기능 기획, 프로젝트 현황 공유, 개발 문서화 등에서 디자인과 관련 설명을 한곳에 모을 수 있습니다. ## GitLab: 이슈와 디자인을 연결하는 개발 협업 - GitLab 플러그인을 사용하면 Figma 디자인을 GitLab 이슈에 직접 업로드할 수 있습니다. - 개발자는 작업 중인 이슈 안에서 관련 디자인을 확인하고 변경 사항을 검토할 수 있습니다. - 디자인을 이슈의 맥락에 맞춰 공유할 수 있어 요청 사항과 구현 결과를 비교하기 쉽습니다. - 스프린트 작업, 신규 요청, 버그 대응 과정에서 디자인 공유에 드는 시간을 줄여줍니다. ## Avocode: 개발자용 디자인 핸드오프 - Avocode 플러그인은 Figma 디자인을 Avocode 프로젝트와 동기화합니다. - 디자이너가 탐색적 시안을 계속 수정하는 동안에도 개발자는 확정된 디자인의 레이어와 상세 정보를 확인할 수 있습니다. - 개발자는 다음 정보를 직접 확인하거나 추출할 수 있습니다. - 디자인 치수 - 색상 코드 - 이미지 및 기타 에셋 - CSS, CSS-in-JS, React Native 등을 포함한 코드 스니펫 - 디자인 도구와 개발 핸드오프 도구를 반복해서 오갈 필요가 없어 디자인을 코드로 전환하는 과정이 단순해집니다. ## Pendo: 실제 사용자 대상 프로토타입 검증 - Pendo 통합은 Figma의 라이브 디자인을 제품 안에 삽입할 수 있게 합니다. - 제품 관리자는 특정 사용자 세그먼트가 실제 제품을 사용하는 맥락에서 새 기능이나 변경안을 보여줄 수 있습니다. - 사용자는 프로토타입을 직접 경험한 뒤 다음 방식으로 의견을 남길 수 있습니다. - 설문 응답 - 자유 형식의 텍스트 피드백 - 사용자 조사 인터뷰 예약 - 개발 전에 고객 반응을 수집하면 중요한 문제를 조기에 발견하고, 실제 요구에 맞지 않는 기능에 투자하는 위험을 줄일 수 있습니다. ## Bubble: Figma 디자인을 코드 없이 웹 앱으로 전환 - Bubble 통합을 사용하면 Figma 디자인을 기반으로 웹 앱을 만들 수 있습니다. - Figma에서 새 디자인을 만들거나 커뮤니티 파일을 활용한 뒤 Bubble로 직접 가져올 수 있습니다. - 가져오기 과정에서: - Figma의 각 프레임은 Bubble 앱의 새로운 페이지가 됩니다. - 벡터 요소는 이미지로 업로드됩니다. - 이를 통해 디자인 단계와 실제 구현 사이의 시간을 단축하고, 코드 작성 없이 초기 웹 앱을 빠르게 구성할 수 있습니다. ## 실용적인 활용 방향 팀은 모든 도구를 동시에 도입하기보다 업무 흐름에 맞는 통합부터 선택하는 것이 좋습니다. 문서 중심 조직은 Confluence, 개발 이슈 중심 조직은 GitLab, 정교한 핸드오프가 필요하면 Avocode, 출시 전 검증이 중요하면 Pendo, 빠른 프로토타입 구현이 목표라면 Bubble을 우선 검토할 수 있습니다. 제공된 글 내용은 Bubble 섹션 중간에서 끝나므로, 원문의 여섯 번째 통합에 대한 내용은 포함되어 있지 않습니다.

원문 읽기(새 탭에서 열림)
Figmagitlabdesign-collaborationReact Native+3
datadog3분 읽기큐레이션 요약

늙은 데이터독과

Datadog이 Gartner의 2026년 Observability Platforms 매직 쿼드런트에서 리더로 선정되었다는 내용을 홍보하는 페이지입니다. 제공된 내용에는 평가 근거와 세부 분석보다 Datadog의 인프라·애플리케이션·로그·보안·디지털 경험·소프트웨어 제공·서비스 관리·AI 기능 목록이 주로 포함되어 있습니다. ### Gartner 매직 쿼드런트 리더 선정 - Datadog은 Gartner® Magic Quadrant™ for Observability Platforms 2026에서 **Leader**로 소개됩니다. - 다만 제공된 본문에는 Gartner의 평가 기준, 경쟁사 비교, Datadog의 강점과 개선점에 대한 구체적인 설명은 포함되어 있지 않습니다. - 따라서 리더 선정 자체는 확인할 수 있지만, 그 배경과 객관적인 평가 내용까지 판단하기는 어렵습니다. ### 통합 인프라 모니터링 - 호스트, 컨테이너, Kubernetes, 서버리스 환경을 모니터링합니다. - 메트릭, 네트워크, 스토리지, GPU 상태를 수집하고 분석할 수 있습니다. - 클라우드 비용 관리와 Cloudcraft를 통해 인프라 구성과 비용까지 함께 관리하는 기능을 제공합니다. - Kubernetes Autoscaling을 통해 관측 데이터를 운영 자동화와 연결할 수 있습니다. ### 애플리케이션 성능과 데이터 관측 - APM(Application Performance Monitoring)으로 애플리케이션 성능과 서비스 간 의존성을 분석합니다. - Continuous Profiler와 Dynamic Instrumentation을 통해 실행 중인 코드의 성능 문제를 조사할 수 있습니다. - 데이터베이스, 데이터 스트림, 데이터 품질, 작업(Job) 모니터링 기능도 제공합니다. - Agent Observability를 통해 AI 에이전트의 동작과 성능을 관찰하는 기능도 포함합니다. ### 로그 관리와 보안 - Log Management와 Observability Pipelines로 로그 수집·처리·저장을 관리합니다. - Sensitive Data Scanner를 이용해 로그나 데이터에 포함된 민감 정보를 탐지할 수 있습니다. - Cloud SIEM, 취약점 관리, 클라우드 보안 형상 관리(CSPM), 권한 관리(CIEM) 등을 제공합니다. - SAST, IAST, IaC Security, Secret Scanning 등 개발 단계부터 실행 환경까지 아우르는 보안 기능을 포함합니다. ### 디지털 사용자 경험 분석 - Browser 및 Mobile RUM으로 실제 사용자의 웹·모바일 경험을 측정합니다. - Session Replay, Product Analytics, Experiments를 통해 사용자 행동과 제품 사용성을 분석합니다. - Synthetic Monitoring, Mobile App Testing, Error Tracking으로 실제 사용자가 문제를 겪기 전부터 오류를 검증할 수 있습니다. ### 소프트웨어 제공과 서비스 운영 - CI Visibility, Test Optimization, Continuous Testing, Code Coverage로 빌드와 테스트 과정을 관찰합니다. - Internal Developer Portal과 Software Catalog를 통해 서비스와 개발 자산을 관리합니다. - Event Management, Incident Response, SLO, Case Management, Workflow Automation을 지원합니다. - 장애 대응과 운영 업무를 하나의 플랫폼에서 연결하려는 구조입니다. ### AI 기반 운영 기능 - Watchdog, Bits AI Agents, Bits Investigation, Bits Chat 등 AI 기반 분석·조사 기능을 제공합니다. - GPU Monitoring과 AI Integrations는 AI 인프라와 외부 AI 서비스의 상태를 관찰하는 데 활용됩니다. - MCP Server, Agent Builder, Agent Directory 등을 통해 Datadog 기능을 AI 에이전트 및 자동화 흐름과 연결할 수 있습니다. 실제로 Datadog 도입을 검토한다면 ‘Leader’라는 홍보 문구만 보기보다 필요한 모니터링 범위, 데이터 보존 비용, 에이전트 설치 방식, 기존 도구와의 통합성, 보안·규정 준수 요구사항을 기준으로 Gartner 원문과 경쟁 제품을 함께 비교하는 것이 좋습니다.

원문 읽기(새 탭에서 열림)
쿠버네티스datadog옵저버빌리티애플리케이션 성능 모니터링+3
datadog원문

옛 데이터독과 바다 (새 탭에서 열림)

데이터 전문가인 저자가 자신의 요트 '세컨드 윈드(Second Wind)'를 스마트하게 개조하기 위해 파편화된 항해 기기들을 NMEA 2000 표준 프로토콜로 통합한 과정과 그 성과를 다룹니다. 저자는 데이터 분석을 통해 더 나은 항해사가 되겠다는 목표로, 기존의 아날로그 및 노후 기기들을 네트워크로 연결하여 선박의 상태와 환경 데이터를 한곳으로 모으는 데 성공했습니다. 결과적으로 이 프로젝트는 단순한 기기 설치를 넘어, 데이터 통합을 통해 항해 안전성과 선박 운영의 효율성을 동시에 확보하는 엔지니어링 사례를 보여줍니다. ## NMEA 2000 프로토콜을 이용한 네트워크 통합 * **표준 프로토콜 채택**: 자동차의 CAN 버스와 유사한 NMEA 2000 프로토콜을 기반으로 선박 내 데이터 백본(Backbone)을 구축했습니다. 이 표준은 하나의 케이블로 데이터와 전원을 동시에 공급하며 250 kbit/s의 속도로 기기 간 통신을 지원합니다. * **호환성 문제 해결**: 레이마린(RayMarine)사의 독자 규격인 'SeatalkNG'가 NMEA 2000과 물리적 커넥터만 다를 뿐 호환된다는 점을 이용해 어댑터로 연결했습니다. * **노후 장비 교체**: NMEA 0183이라는 구형 프로토콜을 사용하는 기존 수심계와 속도계는 컨버터를 쓰는 대신 최신 NMEA 2000 지원 장비로 교체하여 시스템의 단순함과 일관성을 유지했습니다. ## AIS 도입을 통한 항해 안전성 강화 * **AIS(자동 식별 장치) 설치**: VHF 라디오를 통해 주변 선박의 이름, ID, 속도, 방향, 좌표 데이터를 주고받는 AIS 트랜스폰더를 도입했습니다. * **충돌 방지 및 가시성 확보**: 레이더보다 저렴한 비용으로 시야 내의 다른 선박 정보를 차트플로터(지도 표시 장치)에 시각화하여 충돌 위험을 줄였습니다. * **데이터 독립성**: 내장 GPS 모듈이 포함된 AIS 장치를 설치함으로써, 외부 장치에 의존하지 않고도 정확한 위치 데이터를 NMEA 2000 버스에 공급할 수 있게 되었습니다. ## 풍향 및 풍속 데이터의 정밀 측정 * **아날로그에서 디지털로**: 단순히 돛대 끝의 풍향계를 눈으로 확인하던 방식에서 벗어나, 풍향과 풍속을 동시에 측정할 수 있는 풍향풍속 센서(Transducer)를 설치했습니다. * **데이터 기반 세일링**: 측정된 풍속 데이터를 콕핏(조종석) 디스플레이로 실시간 확인하고 네트워크에 공유함으로써, 바람의 세기에 맞춘 정밀한 돛 조절(Trim)이 가능해졌습니다. * **물리적 설치의 도전**: 센서 설치를 위해 돛대 꼭대기에 구멍을 뚫고 배 내부로 배선을 연결하는 하드웨어 작업 과정을 거쳐 시스템 통합을 완성했습니다. ## 실용적인 결론 이 글은 파편화된 하드웨어를 표준 프로토콜로 통합하는 것이 데이터 분석의 첫걸음임을 강조합니다. 선박과 같은 복잡한 환경에서도 표준 규격(NMEA 2000)을 준수하면 서로 다른 제조사의 장비들을 효과적으로 연결할 수 있으며, 이렇게 수집된 데이터는 안전 항행뿐만 아니라 향후 성능 최적화를 위한 귀중한 자산이 됩니다.

데이터베이스 설계data-analysiswireless-communicationnmea-2000+4
figma3분 읽기큐레이션 요약

피그마 내부 이야기: 신입

Josh Shi는 대학 졸업 후 Figma에 입사한 경험을 바탕으로, 취업을 “좋은 회사의 조건을 체크하는 일”이 아니라 자신과 일의 관계를 탐구하는 과정으로 바라보자고 말한다. 특히 일과 삶을 서로 상쇄되는 두 영역으로 보지 말고, 함께 삶을 구성하며 서로 영향을 주는 요소로 이해해야 한다고 강조한다. 신입 엔지니어에게는 회사의 명성보다 자신의 관심사·성장 방식·가치관이 실제 업무 환경과 맞는지를 질문하라고 조언한다. ## 정답이 아닌 질문으로 취업을 바라보기 - 저자는 대학 졸업 당시 Figma를 선택한 이유를 완벽하게 설명할 수 없었다고 고백한다. - 면접에서 만난 사람들이 친절하고 사려 깊으며, 자신을 한 사람으로 이해하려는 태도를 보였던 점이 인상적이었다. - “흥미로운 문제”, “똑똑한 동료”, “좋은 문화” 같은 일반적인 평가 기준만으로는 개인에게 의미 있는 직장을 판단하기 어렵다. - 회사 선택에서 중요한 것은 정해진 체크리스트보다 다음과 같은 자기 성찰이다. - 어떤 종류의 일에 관심이 있는가? - 회사가 그 관심사를 발전시킬 기회를 제공하는가? - 관심사가 바뀌었을 때 업무나 역할도 변화할 수 있는가? - 어떤 기술과 전문성을 쌓을 수 있는가? - 일이 직장 밖의 다른 관심사와 삶의 방향에도 어떤 영향을 주는가? ## ‘일과 삶의 균형’이라는 단순한 프레임의 한계 - 일과 삶을 시소의 양쪽처럼 보는 전통적인 “work-life balance” 개념은 지나치게 단순하다. - 일과 비업무 시간은 서로 독립된 영역이 아니라, 합쳐져 한 사람의 삶을 구성한다. - 업무 만족도는 개인 생활의 만족도에 영향을 주고, 반대로 삶의 상태도 업무 경험에 영향을 준다. - 단순히 근무 시간을 줄이거나 일정한 시간 비율을 맞춘다고 해서 올바른 균형이 만들어지는 것은 아니다. - 사람마다 일에 자신의 정체성을 얼마나 연결할지는 다르며, 어느 한 방식이 정답은 아니다. - 저자는 일과 삶을 어떻게 배치해야 자신이 원하는 방식으로 살 수 있는지 질문해야 한다고 말한다. - 다만 모든 사람이 업무 환경을 자유롭게 선택할 수 있는 것은 아니다. 생계와 고용 안정성이 우선인 상황에서는 일을 커리어의 일부로 바라볼 여유가 제한될 수 있다. ## 신입으로서 얻은 기술적·실무적 성장 - Figma에서 새로운 기술 경험을 쌓았다. - 풀스택 개발을 경험했다. - 웹 환경에서 C++를 사용하는 업무를 접했다. - 단순히 코드를 작성하는 것을 넘어 기능을 실제로 소유하고 제품 개발 과정에 참여했다. - 다음과 같은 제품 개발 역량을 배웠다. - 기능과 제품의 범위를 현실적으로 정하기 - 모호한 목표를 구체화하기 - 아이디어를 처음부터 출시까지 발전시키기 - 제품을 신중하게 설계하고 구현하기 - 신입 개발자에게 기술 스택보다 중요한 성장 요소는 기능의 전체 생명주기를 경험하고 결과에 책임지는 것이라고 볼 수 있다. ## 멘토와 조직 환경의 영향 - 저자의 성장에는 주변 동료들의 지원과 지도가 결정적인 역할을 했다. - 동료들은 의도적으로 멘토 역할을 하지 않았더라도, 도전할 기회와 업무 소유권을 제공하며 성장을 도왔다. - 면접 당시 함께 식사했던 동료들 중 상당수가 계속 Figma에 남아 있었고, 저자는 그들의 경험과 관대함으로부터 지속적으로 도움을 받았다. - 신입이 회사를 평가할 때는 공식적인 복지나 문화 설명뿐 아니라 다음 요소도 살펴볼 필요가 있다. - 질문하고 도움을 요청하기 쉬운가 - 신입에게 실제 책임과 소유권을 주는가 - 동료들이 지식을 공유하는가 - 새로운 역할이나 기술을 시도할 수 있는가 ## 회사와 역할은 계속 변한다 - 저자가 입사한 뒤 Figma는 회사와 제품 모두 크게 성장했다. - 입사 당시와 현재의 조직 환경은 달라졌으며, 회사는 하이브리드 모델로 전환하기 시작했다. - 따라서 취업 선택은 고정된 조건을 고르는 일이 아니라, 변화하는 회사 안에서 자신의 관심과 역할이 어떻게 발전할 수 있는지를 판단하는 일이다. - 좋은 직장은 처음부터 모든 조건이 완벽한 곳이라기보다, 개인의 성장과 변화에 맞춰 역할을 확장하거나 조정할 수 있는 환경일 수 있다. 취업을 준비하는 신입 개발자는 회사의 유명세나 기술 목록만 비교하기보다, 자신이 배우고 싶은 방식과 일의 의미를 먼저 정리하는 것이 좋다. 면접에서는 업무 내용뿐 아니라 멘토링, 기능 소유권, 역할 변화 가능성, 조직의 성장 방향을 구체적으로 질문하는 것이 실용적이다.

원문 읽기(새 탭에서 열림)
디자인 시스템웹 개발product-developmentc+++1