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

datadog원문

Datadog의 데이터 시각화를 iOS에 구현한 방법: 성능 최적화에 집중하며 (새 탭에서 열림)

Datadog은 복잡한 데이터 시각화를 iOS 모바일 앱에 네이티브로 구현하기 위해 자체 SwiftUI 기반 그래프 라이브러리인 'DogGraphs'를 개발했습니다. iOS 14 호환성을 유지해야 하는 제약 속에서 성능 병목을 해결하기 위해 SwiftUI의 렌더링 파이프라인과 디핑(Diffing) 메커니즘을 심도 있게 분석하고 최적화했습니다. 그 결과, 다양한 제품군에서 빠르고 유연하게 동작하며 컴파일 타임에 타입 안정성까지 보장하는 선언형 그래프 프레임워크를 구축할 수 있었습니다. ### DogGraphs 개발 배경과 도전 과제 * **자체 라이브러리 필요성**: 개발 당시 Swift Charts 같은 공식 라이브러리가 없었으며, Datadog 특유의 복잡한 데이터 시각화 요구사항을 충족하기 위해 직접 개발을 결정했습니다. * **하위 호환성 제약**: iOS 14를 지원해야 했기에 성능 최적화에 유리한 최신 `Canvas` API를 사용할 수 없었고, 표준 SwiftUI 뷰 계층 구조만으로 고성능을 구현해야 했습니다. * **선언형 API 설계**: Swift의 Result Builder를 활용해 SwiftUI와 유사한 구문으로 복잡한 그래프를 정의할 수 있게 했으며, 서로 다른 유형의 그래프를 잘못 쌓는 등의 실수를 컴파일 타임에 방지하도록 설계했습니다. ### 성능 분석 및 프로파일링 도구 활용 * **_printChanges() 활용**: 뷰의 `body` 내에서 이 비공개 API를 호출하여 어떤 상태 변화가 불필요한 재렌더링을 유발하는지 로그로 확인하고 디버깅했습니다. * **Xcode Instruments**: 'SwiftUI View body evaluations'를 통해 뷰의 바디가 평가되는 횟수와 평균 소요 시간을 측정했으며, 'Time profiler'로 실행 시간이 긴 함수를 찾아 최적화했습니다. * **주요 측정 시나리오**: 초기 그래프 렌더링 시점, 툴팁 선택이나 레이어 토글 같은 상호작용 발생 시, 기기 회전 및 다크/라이트 모드 전환 시의 성능을 집중적으로 점검했습니다. ### SwiftUI 핵심 개념과 디핑(Diffing) 메커니즘 * **렌더링 원리 이해**: SwiftUI의 성능 최적화를 위해 Identity(정체성), Lifetime(생명주기), Dependencies(의존성)라는 세 가지 핵심 개념을 기반으로 뷰 업데이트 방식을 분석했습니다. * **비트 단위 비교**: SwiftUI는 뷰의 필드를 비트 단위로 비교(memcmp)하여 이전 값과 차이가 없으면 `body`를 다시 계산하지 않고 건너跳는 최적화 방식을 사용합니다. * **의존성 관리**: 불필요한 의존성 전파를 막고 뷰 구조를 효율적으로 설계함으로써, 데이터 변경 시 영향을 받는 뷰만 정확히 다시 그려지도록 유도했습니다. ### 실용적인 권장 사항 복잡한 SwiftUI 애플리케이션의 성능을 높이려면 단순히 최신 기능을 사용하는 것에 그치지 말고, **뷰의 정체성(Identity)과 의존성 관계를 명확히 정의**해야 합니다. 특히 대규모 데이터를 다루는 시각화 도구에서는 SwiftUI의 내부 디핑 엔진이 효율적으로 작동할 수 있도록 뷰 모델과 프로퍼티 구조를 최적화하고, Instruments를 통해 렌더링 비용을 주기적으로 측정하는 과정이 필수적입니다.

figma3분 읽기큐레이션 요약

The Long and Short of

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

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

Framework 2024

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

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

디자인 시스템을 위한 올바

Code Connect는 Figma의 Dev Mode에서 자동 생성된 CSS 대신 조직의 실제 디자인 시스템 코드를 보여줘 디자인 시스템 도입률을 높이는 도구다. 개발자는 목업과 연결된 컴포넌트의 올바른 코드와 사용 지침을 바로 확인할 수 있어 구현 속도와 일관성이 향상된다. 결과적으로 잘못된 컴포넌트 사용과 중복된 일회성 컴포넌트의 생성·유지보수를 줄이는 것이 목표다. ## 디자인 시스템 도입이 어려운 이유 - 디자인 시스템을 구축해도 개발자가 시스템의 모든 컴포넌트와 패턴을 알지 못하는 경우가 많다. - 일부 컴포넌트를 사용하더라도 의도된 가이드라인과 다르게 적용할 수 있다. - 디자인 시스템의 성공은 단순히 사용 여부가 아니라, 올바르고 일관되게 사용하는지에 달려 있다. - 디자인과 코드는 서로 다른 도구와 제약을 가진 별개의 작업 영역으로 발전해 왔기 때문에 연결 지점이 부족했다. ## 디자인과 코드의 연결 - 디자인은 무엇을 만들지 탐색하고 결정하는 데 초점을 두며, 코드는 이를 구조적이고 유지보수 가능한 형태로 구현하는 데 초점을 둔다. - Figma는 두 영역이 원활하게 오갈 수 있어야 한다고 보고, Code Connect를 그 연결을 강화하는 기능으로 소개한다. - 기존의 Auto Layout, Variables, Component Props, Dev Mode 등의 기능과 함께 디자인 시스템을 코드에 더 가깝게 통합하려는 흐름에 속한다. - 디자인 시스템 팀이 작성한 실제 구현 방식과 문서를 디자인 목업의 맥락 안에서 제공한다. ## Code Connect의 핵심 기능 - Dev Mode에 표시되는 코드 스니펫을 조직의 실제 디자인 시스템 코드로 사용자 지정할 수 있다. - 자동 생성 CSS가 아니라 프로젝트에서 사용하는 컴포넌트, 속성, 패턴에 맞는 코드를 개발자에게 보여준다. - 개발자가 목업에서 특정 요소를 선택하면 관련 코드와 사용법을 별도의 문서 검색 없이 확인할 수 있도록 한다. - 올바른 구현 예시와 디자인 시스템 사용 원칙을 함께 제공해 오용을 줄인다. - 디자인 시스템의 재사용을 촉진해 중복 컴포넌트와 일회성 구현의 생성을 줄인다. ## 개발자 워크플로에 맞춘 설치 방식 - Code Connect는 개발자가 익숙한 패키지 및 명령줄 기반 방식으로 설치·설정할 수 있다. - JavaScript와 TypeScript 프로젝트에서는 **npm**을 사용한다. - SwiftUI 프로젝트에서는 **Swift Package Manager**를 지원한다. - 설치 패키지와 설정 방법은 GitHub 저장소에서 제공된다. - 향후 더 많은 플랫폼을 지원해 기존 개발 환경에 자연스럽게 통합하는 것을 목표로 한다. ## 기대 효과 - 개발자가 디자인 시스템 컴포넌트를 더 쉽게 발견하고 사용할 수 있다. - 디자인에서 코드로 전환하는 과정이 빨라지고 구현 효율이 높아진다. - 실제 코드와 디자인 간의 차이를 줄여 제품 전반의 UI 일관성을 높인다. - 디자인 시스템 팀의 문서화와 모범 사례를 개발 작업의 적절한 시점에 전달할 수 있다. - 결과적으로 조직 전체의 디자인 시스템 채택률과 유지보수성을 개선한다. Code Connect를 도입할 때는 자주 사용하는 컴포넌트부터 실제 프로덕션 코드와 연결하고, 각 컴포넌트의 올바른 사용 예시와 속성 매핑을 함께 관리하는 것이 효과적이다. Primitives나 자동 생성 코드보다 조직의 표준 컴포넌트가 우선 노출되도록 구성해야 도입 효과를 극대화할 수 있다.

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

알래스카 항공, 변

Alaska Airlines는 Figma의 디자인 시스템과 Variables를 활용해 웹·모바일·디지털 사이니지·키오스크 전반의 경험을 일관되게 관리하고 있다. 45명 규모의 디자인 팀은 이를 통해 디자이너당 주당 평균 11시간을 절약했으며, 개발팀과의 협업과 접근성·구현 정확성도 개선했다. 특히 Auro 디자인 시스템의 재사용 컴포넌트는 긴급한 서비스 개편을 한 스프린트 안에 완료하도록 도왔다. ## 기존 도구와 단일 기준 부재의 문제 - Sketch와 InVision을 사용하던 시기의 디자인 시스템은 여러 도구가 뒤섞인 “프랑켄슈타인” 같은 상태였다. - 재사용 위젯이 직관적이지 않았고, 프로토타이핑과 실시간 협업 기능도 부족했다. - 디자인과 개발을 연결하는 단일 진실 공급원(Single Source of Truth)이 없어 다음 문제가 발생했다. - 컴포넌트와 패턴의 간격·색상 등이 몇 픽셀씩 어긋남 - 플랫폼별로 변경 사항을 수동 복사·붙여넣기 - 버튼, 체크박스, 모달, 색상, 날짜 선택기 등의 불일치 - 접근성 기준을 놓칠 가능성 증가 - 최신 파일이나 올바른 버전을 찾기 어려움 - 결과적으로 개발자는 실제 웹사이트와 맞지 않는 디자인을 전달받는 경우가 많았다. ## Auro 디자인 시스템과 Figma 도입 - Alaska Airlines는 Figma를 도입하며 디자이너와 엔지니어 모두를 위한 디자인 시스템 문서를 구축했다. - Auro는 웹 컴포넌트와 대응되는 디자인 컴포넌트를 제공해 설계와 구현 사이의 차이를 줄였다. - 컴포넌트, 색상, 패턴 등을 공통으로 참조할 수 있어 여러 인터페이스에서 일관된 사용자 경험을 유지할 수 있게 됐다. - 디자인 시스템 운영 과정에서 Auto Layout, 브랜치 및 병합 기능 등의 사용법도 문서화해 팀 내 채택률을 높였다. - 교육을 강화한 결과 디자이너의 Figma 활용도가 높아졌고, 디자이너와 엔지니어 간 충돌도 줄었다. ## 재사용 컴포넌트로 긴급 대응 속도 향상 - 심각한 폭풍으로 항공편 지연이 급증했을 때, 기존에 충분히 활용되지 않던 항공편 상태 페이지를 빠르게 개편했다. - 디자인·개발 타이거 팀은 개편에 필요한 컴포넌트의 90%를 Figma의 Auro 디자인 시스템에서 재사용했다. - Figma가 없었다면 최소 4~5개 스프린트가 필요했을 작업을 단 한 스프린트에 완료했다. - 개편 후 항공편 상태 페이지의 평균 체류 시간은 다음과 같이 증가했다. - 기존: 36초 - 변경 후: 5분 10초 - 증가율: 761% - 새 페이지에는 항공편 추적 정보와 항공기 세부 정보 등 고객에게 필요한 정보가 추가됐다. ## 디자인과 개발 간 신뢰 강화 - Figma는 처음에는 디자이너 간 협업 도구로 도입됐지만, 점차 엔지니어가 Auro의 설계 원칙을 이해하는 수단으로도 활용됐다. - 엔지니어가 실제로 사용하는 웹 컴포넌트와 유사한 디자인 컴포넌트를 참조할 수 있어 구현 가능성을 더 쉽게 판단하게 됐다. - 디자인이 구현 결과와 가까워지면서 팀 간 신뢰가 높아졌다. - 디자인 시스템 문서와 기능 교육은 디자이너가 Figma의 기능을 제대로 활용하도록 돕고, 협업 과정의 불필요한 충돌을 줄였다. ## Variables를 통한 다중 환경 대응 - Figma Variables를 활용해 23,000명 이상의 직원과 다양한 조직·파트너의 요구에 맞춰 디자인을 조정할 수 있게 됐다. - 다음과 같은 조건을 체계적으로 관리할 수 있다. - 다양한 화면 크기 - 라이트 모드와 다크 모드 - 팀별 테마 - 외부 파트너를 위한 테마 - 여러 환경에 맞는 디자인을 개별적으로 수정하는 대신, 변수 기반으로 체계화해 반복 작업을 줄였다. - 그 결과 Alaska의 디자이너들은 평균적으로 주당 11시간의 작업 시간을 절약했다. Alaska Airlines 사례는 디자인 시스템을 단순한 컴포넌트 모음이 아니라 디자인·개발·문서·교육을 연결하는 운영 체계로 구축해야 효과가 커진다는 점을 보여준다. 여러 플랫폼과 테마를 동시에 지원해야 하는 조직이라면 공통 컴포넌트와 Variables를 함께 도입하고, 이를 뒷받침할 문서화와 팀 교육까지 병행하는 것이 실용적이다.

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

카바나가 일관성과 확장성을

Carvana는 Figma의 디자인 시스템과 변수를 활용해 빠른 성장 속에서도 제품 경험의 일관성과 확장성을 유지했다. 분산된 디자인 도구를 Figma로 통합해 단일 기준을 만들고, 변수와 테마 기능으로 디자인·개발 협업과 브랜드 확장을 효율화했다. 그 결과 반복 작업과 수정이 줄고, 새로운 사업 영역에도 기존 디자인 언어를 빠르게 적용할 수 있었다. ## 성장에 대응하는 단일 기준 마련 - Carvana는 2019년 성장세가 가속화되면서 확장 가능한 디자인 플랫폼이 필요해졌다. - 기존 디자인 시스템은 PDF 기반 UI 키트, Principle, Sketch 등 여러 도구에 흩어져 있었다. - 컴포넌트를 복사해 사용하는 방식 때문에 동일한 요소가 조금씩 변형됐고, 디자인과 개발팀이 참조할 중앙 기준이 없었다. - Figma로 디자인 시스템을 이전하면서 디자인·개발팀이 함께 참조할 수 있는 연결된 단일 소스 오브 트루스를 구축했다. - 코로나19 시기 차량 판매가 급증했을 때도 통합된 시스템 덕분에 기존 도구에서 발생하던 협업 마찰을 줄이고 수요에 대응할 수 있었다. - 약 40명의 디자인 시스템 팀이 1만 명 규모의 회사 전반에 디자인 품질을 확산시키는 역할을 담당했다. ## 변수로 디자인 일관성과 효율성 강화 - 제품 생태계가 커지면서 색상, 간격, 타이포그래피, 모서리 반경이 화면과 컴포넌트마다 달라지는 문제가 발생했다. - Figma 변수는 색상이나 수치처럼 재사용 가능한 값을 정의하고 여러 디자인 속성에 적용할 수 있게 했다. - 특히 숫자 변수를 활용해 spacing과 corner radius를 일관된 값으로 관리했다. - 변수의 값을 중앙에서 정의하면 디자이너가 픽셀 수준의 정확성을 유지하면서도 반복적인 수정 작업을 줄일 수 있다. - 초기에는 변수 설정과 학습에 비용이 들었지만, 결과적으로 디자인 완성도가 높아지고 리뷰 과정에서 되돌아오는 수정 사항이 감소했다. - 변수 기반 시스템은 장기적으로 디자이너의 반복 작업과 리비전을 줄여 효율을 높인다. ## 테마 기능으로 인수 사업 통합 - Carvana가 자동차 경매 기업 ADESA를 인수한 뒤에도 변수는 새로운 브랜드 테마를 빠르게 도입하는 데 활용됐다. - 컴포넌트의 구조와 기능은 유지하면서 변수 값만 바꾸어 ADESA 전용 색상과 스타일을 적용할 수 있었다. - 기존 방식이라면 새 스타일에 맞춰 컴포넌트 라이브러리를 다시 구축하는 데 최소 한 달이 걸렸을 작업을, 변수 기반 테마로 1주일 이내에 처리했다. - ADESA용 디자인 시안을 평소보다 약 3배 빠르게 제작할 수 있었다. - 브랜드 변경을 개별 컴포넌트의 재작업이 아니라 테마 전환으로 처리함으로써 여러 화면 너비와 제품 영역에 일관되게 적용할 수 있었다. ## 디자인과 개발 간 연결 강화 - Figma 기반 디자인 시스템은 디자이너와 개발자가 동일한 컴포넌트와 변수 기준을 참조하도록 돕는다. - 중앙화된 라이브러리와 변수는 디자인 변경 사항을 일관되게 관리하고 핸드오프 과정의 마찰을 줄이는 기반이 된다. - 글에서는 변수와 Figma REST API를 활용한 개발 연계 및 변수 마이그레이션 사례도 소개한다. Carvana 사례는 성장하는 조직일수록 디자인 시스템을 여러 파일이나 도구에 분산시키기보다 단일 기준으로 통합해야 한다는 점을 보여준다. 특히 색상·간격·브랜드 스타일을 변수와 테마로 관리하면 제품 확장이나 인수 이후의 리브랜딩도 빠르고 안정적으로 수행할 수 있다.

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

디자인에서 코드로의 자동화를

Dev Mode의 코드 생성(codegen)은 디자인을 완성된 코드로 자동 변환하는 기능이라기보다, 개발자가 구현을 시작할 수 있도록 돕는 출발점이다. Figma는 기본 코드 스니펫을 제공하고, 팀의 디자인 시스템과 기술 스택에 맞춰 다양한 codegen 플러그인으로 확장할 수 있다고 설명한다. Anima, Builder, Figma to Code, Locofy.ai 같은 도구는 React·HTML·Tailwind부터 Flutter·SwiftUI까지 지원하며 반응형 구현과 컴포넌트화를 가속한다. ## Dev Mode와 codegen의 역할 - Codegen은 정해진 규칙이나 명세를 바탕으로 코드를 자동 생성하는 과정이다. - Figma Dev Mode에서 캔버스의 객체를 선택하면 Inspect 패널에 자동 코드 스니펫이 표시된다. - 사용자는 코드 언어와 단위 체계를 드롭다운에서 선택할 수 있다. - codegen은 디자인을 개발로 옮기는 작업을 완전히 대체하기보다, 매번 빈 화면에서 시작하지 않도록 구현의 출발점을 제공한다. - 성숙한 디자인 시스템을 운영하는 팀은 자체 규칙과 컴포넌트를 반영하기 위해 custom codegen 플러그인을 만들 수 있다. ## Anima를 활용한 디자인 코드 변환 - Figma의 레이어·컴포넌트·프레임을 React 또는 HTML 코드로 내보낼 수 있다. - CSS, SCSS, Tailwind 형식의 스타일 코드와 함께 인터랙티브하고 반응형인 결과물을 생성한다. - 반복되는 컴포넌트를 자동으로 감지해 코드 중복을 줄인다. - 팀이 사용하는 코드 스타일과 관례를 학습해 더 적절한 코드 스니펫을 제공한다. - Dev Mode에서 애니메이션을 추가하거나 특정 스타일에 맞게 코드를 조정하도록 요청할 수 있다. ## Builder의 AI 기반 코드 컴포넌트 활용 - React, Svelte, HTML 등의 코드를 AI로 생성한다. - 팀의 기존 코드 컴포넌트를 활용해 디자인과 실제 구현 사이의 간극을 줄인다. - 생성된 코드에 대해 대화형으로 수정 사항을 요청할 수 있다. - 팀의 코드 스타일에 맞도록 AI를 학습시키고, 디자인을 자동으로 반응형으로 변환할 수 있다. - Figma 밖의 별도 웹 인터페이스에서 생성 코드를 시험하고 수정할 수 있다. ## Figma to Code로 웹·모바일 코드 생성 - Figma Community에서 제공되는 무료 오픈 소스 플러그인이다. - 반응형 웹을 위해 HTML 또는 Tailwind 코드를 생성한다. - 모바일 앱 개발을 위해 Flutter와 SwiftUI 코드도 지원한다. - 플러그인에서 생성된 Tailwind 코드를 확인한 뒤 코드 에디터로 복사해 사용할 수 있다. - 별도의 유료 도구 없이 디자인을 여러 플랫폼의 코드로 빠르게 변환할 수 있다는 점이 특징이다. ## Locofy.ai를 통한 웹·모바일 프로토타입 구현 - React, HTML/CSS, Next.js, Gatsby, Vue 기반의 인터랙티브 코드를 생성한다. - 개별 컴포넌트뿐 아니라 전체 화면 단위의 코드 생성도 지원한다. - 자동 레이아웃과 프레임 그룹화 같은 디자인 최적화를 적용한다. - 시맨틱 HTML 요소, 라이브러리, 동작을 태깅해 인터랙션을 구성한다. - 화면 크기에 따른 반응형 동작을 지원한다. - 컴포넌트와 props를 생성해 결과물을 모듈화한다. - 사람이 이해하기 쉬운 문맥 기반 클래스명을 사용해 협업과 확장성을 높인다. - 생성 코드를 다듬은 뒤 프로토타입을 공유하고, 데이터를 연결하며, 코드나 Storybook 파일로 내보낼 수 있다. - GitHub와 직접 동기화하고 자동 병합 및 충돌 해결을 지원해 지속적 통합 흐름에 연결할 수 있다. 실무에서는 생성된 코드를 최종 결과물로 그대로 사용하기보다, 팀의 디자인 시스템·컴포넌트 구조·접근성·상태 관리·성능 기준에 맞게 검토하고 수정하는 것이 좋다. codegen 플러그인은 반복적인 초기 구현을 줄이고 협업을 빠르게 만드는 보조 도구로 활용할 때 가장 효과적이다.

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

디자인 시스템의 미래는

디자인 시스템은 좋은 컴포넌트와 문서를 만드는 것만으로 성공하지 않으며, 조직 구성원이 실제로 사용하도록 만드는 채택 전략이 필요하다. 따라서 디자인 시스템 팀은 자신들의 시스템을 하나의 제품처럼 보고, 사용자 이해·메시지 설계·조직 내 홍보·성과 측정을 마케팅 방식으로 수행해야 한다. 이를 통해 디자인 시스템을 선택 사항이 아닌 조직의 필수 기반으로 자리매김할 수 있다. ## 디자인 시스템도 제품처럼 시장 적합성을 찾아야 한다 - 디자인 시스템의 효과인 일관성, 효율성, 확장성은 구성원들이 널리 사용할 때 비로소 실현된다. - 단순히 Slack 메시지를 보내거나 교육 세션을 여는 것만으로는 채택을 이끌어내기 어렵다. - 디자인 시스템 팀은 내부 사용자를 대상으로 제품-시장 적합성(product-market fit)을 지속적으로 탐색해야 한다. - 디자이너, 개발자, 의사결정자 등 다양한 사용자의 다음 요소를 파악해야 한다. - 현재 업무 방식과 프로세스 - 반복되는 병목과 불편 - 새로운 도구에 대한 우려 - 시스템이 일상 업무에 제공할 수 있는 가치 - 아직 명확히 표현하지 못한 욕구와 불만 - 개별 실무자부터 리더십까지 Product Design and Engineering 조직 전반을 인터뷰하면 역할별 관점을 전략에 반영할 수 있다. - 인터뷰는 디자인 시스템 자체를 설명하는 것보다 현재의 업무 목표와 문제점을 먼저 묻는 방식으로 시작하는 것이 효과적이다. ## 대상별로 다른 메시지를 설계해야 한다 - 디자이너, 개발자, 프로젝트 관리자, 의사결정자는 같은 시스템을 사용하더라도 관심사와 판단 기준이 다르다. - 따라서 모두에게 동일한 홍보 문구를 전달하기보다 대상별로 설득 논리를 조정해야 한다. - **디자이너에게는** - 브랜드 일관성을 유지하면서도 창의성을 발휘할 수 있다는 점을 강조한다. - **개발자에게는** - 컴포넌트 재사용과 표준화 - 디자인과 코드 사이의 원활한 협업 - 반복 작업 감소와 효율 향상을 설명한다. - **의사결정자에게는** - 출시 속도 향상 - 기술 부채 감소 - 투자 대비 효과(ROI)를 중심으로 제안한다. - 유연성 부족, 기술적 한계, 도입 비용과 같은 반대 의견도 피하지 말고 구체적으로 다뤄야 한다. - 사용자의 회의적인 이유를 이해하고 이에 답하는 메시지를 제시하면 저항을 설득과 참여로 전환할 수 있다. ## 채택을 높이는 기능과 도구 - 글에서는 조직 전체의 채택을 지원하는 사례로 다음과 같은 기능을 언급한다. - 개발자를 위한 Code Connect - 타이포그래피 및 그라디언트 변수 - 디자인 시스템 사용 현황을 파악하는 Library Analytics API - 이런 기능은 디자인과 코드의 연결을 강화하고, 시스템이 실제로 어떻게 사용되는지 확인하게 해준다. - 특히 사용 데이터를 확보하면 어떤 팀이 시스템을 사용하고 있는지, 어느 부분에서 채택이 막히는지 파악해 후속 전략을 세울 수 있다. ## 조직 내부의 마케팅으로 접근하기 - 디자인 시스템 팀의 역할은 시스템을 구축하는 데서 끝나지 않고, 조직 안에서 그 가치를 지속적으로 알리고 확산시키는 데까지 확장되어야 한다. - 시스템을 성공시키려면 다음과 같은 제품 출시 전략이 필요하다. - 대상 사용자와 문제 정의 - 대상별 가치 제안 작성 - 도입 장벽과 반론에 대한 대응 - 내부 홍보와 지지자 확보 - 사용량과 성과 측정 - 이런 마케팅 관점은 디자인 시스템을 “있으면 좋은 도구”가 아니라 디지털 제품을 설계하고 개발하는 방식의 핵심 기반으로 바꾸는 데 목적이 있다. 실무적으로는 먼저 디자이너·개발자·리더를 인터뷰해 각자의 문제를 정리하고, 대상별 가치 제안과 도입 장벽을 문서화하는 것이 좋다. 이후 사용량과 반복 사용률 같은 데이터를 추적하면서 메시지와 지원 방식을 계속 개선해야 한다.

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

컴포넌트 스프린트의

워싱턴 포스트는 디자인과 개발이 분리된 채 진행되던 컴포넌트 제작의 문제를 해결하기 위해 약 10일간의 ‘컴포넌트 스프린트’를 도입했다. 디자이너와 개발자가 처음부터 한 쌍으로 참여하고, 관련 팀의 의견을 단계별로 반영해 기술적 제약과 실제 사용 맥락을 함께 고려한다. 이 방식은 디자인 시스템 컴포넌트를 더 빠르고 일관되게 제작하면서도, 팀 전체의 공동 소유 의식을 높이는 것이 핵심이다. ## 디자인 주도·개발 주도 방식의 한계 - 초기 WPDS(The Washington Post Design System)는 컴포넌트 성격에 따라 제작 주체가 달랐다. - `select`, `radio`, `checkbox`처럼 시각적 설계가 중심인 요소는 디자인 주도로 제작했다. - `carousel`, `input search`처럼 기술적 복잡성이 큰 요소는 개발 주도로 제작했다. - 한쪽 팀이 주도하면 다른 팀의 전문 지식이 늦게 반영되어 일정 지연과 타협이 발생했다. - 개발자는 디자인 단계에서 기술적 한계를 뒤늦게 지적하거나, 구현보다 세부적인 시각 요소에 집중하도록 압박받을 수 있었다. - 디자이너는 자신의 사용 사례가 충분히 고려되지 않거나, 이미 존재하는 컴포넌트를 알지 못해 별도 솔루션을 만들기도 했다. - 그 결과 디자인 시스템에는 잦은 오버라이드와 즉석에서 판단해야 하는 기능·변형 요청이 누적됐다. ## 컴포넌트 스프린트의 운영 원칙 - 모든 컴포넌트마다 스프린트를 시작하며, 일반적으로 약 10일 동안 진행한다. - 디자이너와 개발자가 처음부터 끝까지 프로세스를 이끄는 담당자로 짝을 이룬다. - 핵심 담당자 외에도 관련 팀의 의견을 수집해 폐쇄적인 순차 작업을 개방적이고 협력적인 과정으로 바꾼다. - 프로세스는 대체로 다음 단계로 구성된다. - 킥오프 - 콘셉트 정의 - 디자인과 구현 - 개선 및 다듬기 - 문서화 - 모든 참여자가 초기에 요구사항과 기술적 제약을 공유하므로, 후반부의 재작업과 오해를 줄일 수 있다. ## 킥오프: 영향도와 노력으로 우선순위 정하기 - 매주 30분 회의에서 Jira의 후보 컴포넌트 티켓을 검토한다. - 각 아이디어를 예상 영향도와 필요한 노력의 관점에서 비교해 우선순위를 정한다. - 아이디어 보드는 단순한 목록이 아니라 다음 정보를 축적하는 협업 공간으로 활용한다. - 이해관계자의 비동기 피드백 - Slack에서 논의된 관련 정보 - 비슷한 아이디어의 묶음 - 사업 목표와의 연관성 - 시각화된 영향도-노력 매트릭스에서는 원의 크기로 투표 수나 인기도를 표현하고, 색상으로 연관된 사업 목표를 구분한다. - 우선순위가 결정되면 디자인 시스템 팀에서 디자이너와 개발자를 각각 배정한다. - 두 담당자를 초기 단계부터 정함으로써 프로세스 전반의 지속적인 커뮤니케이션을 보장한다. ## 콘셉트 정의: 범위와 목표 합의하기 - 스프린트 시작 시 전체 팀과 함께 약 2시간의 회의를 진행한다. - FigJam에서 다음 내용을 공동으로 정리한다. - 컴포넌트의 목표 - 필수 요구사항 - 작업 범위 - 기술적 요구사항 - 검토가 필요한 가정과 쟁점 - 회의 마지막 15분은 결과 검토에 사용한다. - 기술 담당자와 비기술 담당자가 같은 공간에서 의견을 남기므로, 서로 다른 관점의 기대치를 조기에 맞출 수 있다. - 이 단계에서는 구체적인 디자인 세부사항보다 문제의 범위, 사용 목적, 구현 조건을 먼저 합의한다. - FigJam을 활용하면 특정 직군이 논의를 독점하지 않고, 참여자 모두가 요구사항을 명확히 할 수 있다. ## 실용적인 적용 방향 컴포넌트 제작을 한 팀에 일괄 위임하기보다, 디자이너와 개발자를 초기부터 공동 책임자로 배치하는 것이 효과적이다. 또한 영향도·노력 기반 우선순위 보드와 공개적인 요구사항 문서를 운영하면 불필요한 컴포넌트 중복과 후반 재작업을 줄일 수 있다.

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

디자인 시스템 구축 방법

디자인 시스템은 제품 전반의 일관성을 높이고, 재사용 가능한 컴포넌트와 공통 언어를 통해 디자인·개발 업무를 효율화하는 기반이다. 성공적인 시스템은 정해진 정답을 따르기보다 조직의 목표와 문제에 맞춰 설계하고, 제품과 팀의 변화에 따라 지속적으로 발전해야 한다. 이를 위해 목표 설정, 기존 자산 조사, 협업자 확보, 적절한 구축 방식 선택이 선행되어야 한다. ## 디자인 시스템의 목표와 범위 정의 - 컴포넌트를 만들기 전에 디자인 시스템을 도입하려는 이유를 명확히 해야 한다. - 다음 질문에 답하면서 목표를 구체화한다. - 왜 디자인 시스템이 필요한가? - 어떤 문제를 해결할 것인가? - 문제가 해결되었는지 어떻게 측정할 것인가? - 플랫폼 간 UI 불일치, 반복적인 수동 수정, 디자인·개발팀 간 협업 문제 등이 주요 도입 계기가 될 수 있다. - 디자인 시스템은 소규모 팀의 단순한 컴포넌트 모음부터 대기업의 종합적인 표준 체계까지 다양한 규모로 구성할 수 있다. - 중요한 것은 조직의 현재 상황에 맞게 시작하고, 필요에 따라 확장 가능한 구조를 만드는 것이다. ## 기존 디자인과 코드 자산 조사 - 여러 플랫폼과 디바이스에서 제품 UI를 수집한다. - 일반 화면뿐 아니라 다음과 같은 변형도 함께 확인한다. - 호버·포커스·비활성·오류 등 인터랙션 상태 - 반응형 레이아웃 - 플랫폼별 또는 제품별 대체 버전 - 스크린샷을 모으면 반복되는 시각적 패턴과 일관된 요소를 파악하기 쉽다. - 디자인 파일만 조사해서는 안 되며, 코드베이스도 함께 점검해야 한다. - 개발자가 이미 구현한 다음 자산을 확인하면 기존 엔지니어링 작업을 재활용할 수 있다. - 반복적으로 사용되는 UI 요소 - 공통 CSS 변수 - 공유 컴포넌트 - 표준화된 구현 패턴 - 디자인과 코드 양쪽을 조사해야 서로 다른 시스템이 병렬로 만들어지는 문제를 줄일 수 있다. ## 패턴 분류와 문제점 평가 - 수집한 화면과 컴포넌트를 유형별로 분류해 현재 제품의 디자인 언어를 파악한다. - 같은 문제를 여러 방식으로 해결하고 있는지 확인한다. - 다음과 같은 문제는 디자인 시스템으로 개선할 후보가 된다. - 비슷한 UI가 제품마다 다르게 보이는 경우 - 중복 컴포넌트나 불필요한 변형이 많은 경우 - 디자인팀과 개발팀이 동일한 문제를 각자 다르게 해결하는 경우 - 사용자 경험이 화면이나 플랫폼에 따라 단절되는 경우 - 이 과정은 무엇을 새로 만들지뿐 아니라 무엇을 통합·정리·폐기할지도 결정하는 단계다. ## 조직 내 챔피언 확보 - 디자인 시스템은 한 직군만의 프로젝트가 아니라 디자인, 개발, 제품 관리가 함께 참여하는 팀 작업이다. - 일관된 제품 경험에 관심이 있는 사람을 조직 내 협력자로 확보해야 한다. - 개발자는 실제 코드 구현과 유지보수를 담당하므로 초기부터 참여시키는 것이 중요하다. - 개발자는 컴포넌트의 기술적 실현 가능성, API 설계, 유지보수 비용에 대한 현실적인 의견을 제공할 수 있다. - 성공적인 디자인 시스템이 반드시 대규모 전담 조직에서 시작되는 것은 아니며, 한 명의 담당자에서 출발할 수도 있다. ## 구축 방식 선택 - 디자인 시스템을 구축하는 방법은 크게 두 가지다. - 조직의 요구에 맞춰 처음부터 직접 구축하기 - 기존 프레임워크를 도입한 뒤 제품 상황에 맞게 조정하기 - 선택할 때는 현재 보유한 디자인·코드 자산, 팀 규모, 기술 역량, 유지보수 가능성을 함께 고려해야 한다. - 기존 시스템을 그대로 복사하기보다 조직의 목표와 제품 특성에 맞는 수준으로 조정하는 것이 중요하다. ## 이후의 구축 단계 - 글은 전체 과정을 다음 세 단계로 제시한다. - 기반 마련: 목표 정의, 기존 자산 조사, 문제 평가, 협력자 확보 - 디자인 기반 정의: 색상, 타이포그래피, 간격 등 공통 시각 규칙 수립 - Figma에서 구축: 디자인 자산과 재사용 가능한 컴포넌트를 체계적으로 구성 - 구축 후에도 시스템은 고정된 결과물이 아니라 제품과 팀의 변화에 맞춰 계속 관리하고 발전시켜야 한다. 실무에서는 모든 것을 한 번에 만들기보다 가장 반복적으로 사용되고 영향이 큰 패턴부터 시작하는 것이 좋다. 디자인과 코드를 함께 조사하고 개발자를 초기 단계부터 참여시키면 실제 제품에 적용되고 유지되는 디자인 시스템을 만들 가능성이 높아진다.

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

.NET 지속적 프로파일

Datadog이 Gartner의 **2026년 Observability Platforms Magic Quadrant에서 Leader로 선정되었다는 소식**을 소개하는 페이지입니다. 제공된 내용에는 Datadog의 인프라·애플리케이션·로그·보안·디지털 경험·소프트웨어 전달·AI 관련 제품 목록이 주로 포함되어 있으며, 선정 근거와 Gartner의 평가 세부 내용은 확인되지 않습니다. ### Gartner Magic Quadrant 리더 선정 - Datadog이 **Gartner® Magic Quadrant™ for Observability Platforms 2026**에서 Leader로 이름을 올렸다고 알립니다. - 다만 제공된 본문에는 다음과 같은 구체적인 정보가 없습니다. - 평가 기준과 점수 - 실행 능력 및 비전 완성도에 대한 평가 - 경쟁 제품과의 비교 - Gartner가 제시한 Datadog의 강점과 주의점 ### Datadog의 관측성 제품군 페이지에 연결된 제품 범위는 다음과 같습니다. - **인프라 모니터링** - 호스트, 메트릭, 컨테이너, Kubernetes, 네트워크, 서버리스 모니터링 - 클라우드 비용, 스토리지, GPU 모니터링 - **애플리케이션 성능 관리** - APM, 서비스 모니터링, Continuous Profiler - 동적 계측과 AI 에이전트 관측성 - **데이터 및 로그** - 데이터베이스·데이터 스트림 모니터링 - 로그 관리, 민감 데이터 탐지, 감사 추적, Observability Pipelines - **디지털 경험** - 브라우저·모바일 RUM - 세션 리플레이, 신서틱 모니터링, 오류 추적, 제품 분석 - **보안** - 코드·클라우드·런타임 보안 - SAST, SCA, SIEM, 취약점 관리, 워크로드 보호 - **소프트웨어 전달 및 서비스 관리** - CI Visibility, 테스트 최적화, 코드 커버리지 - 이벤트 관리, SLO, 인시던트 대응, 워크플로 자동화 - **AI 기능** - AI 에이전트 관측성 - Bits AI Agents, Bits Chat, 조사 자동화, MCP Server, GPU 모니터링 ### 제공된 내용의 한계 - 실제 글 본문이 아니라 Datadog 웹사이트의 헤더와 제품 탐색 메뉴가 대부분입니다. - 따라서 “Leader” 선정 사실과 Datadog이 광범위한 관측성·보안·AI 제품을 제공한다는 점 외에는 자세한 분석을 도출하기 어렵습니다. - Gartner 보고서 원문이나 Datadog의 발표문 전체가 있다면 평가 근거와 의미를 더 정확히 요약할 수 있습니다. 실무적으로는 이번 선정 소식을 Datadog의 통합 관측성 플랫폼 역량을 보여주는 참고 자료로 활용하되, 도입 판단 시에는 Gartner 평가만으로 결정하지 말고 비용, 데이터 보존 정책, 기존 기술 스택과의 통합성, 실제 운영 환경의 탐지·대응 성능을 함께 검증하는 것이 좋습니다.

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

.NET 지속적 프로파일러: 예외 및 락 경합 (새 탭에서 열림)

Datadog의 .NET 컨티뉴어스 프로파일러는 애플리케이션의 성능에 보이지 않는 영향을 미치는 예외(Exception)와 락 경합(Lock Contention)을 정밀하게 추적합니다. 단순히 발생 횟수를 세는 것을 넘어, 로우 레벨 CLR 콜백과 메타데이터 분석을 통해 예외 메시지와 락 유지 시간 등 구체적인 컨텍스트를 제공하여 성능 병목의 원인을 정확히 파악하도록 돕습니다. 이를 통해 개발자는 무분별한 예외 발생으로 인한 CPU 낭비와 병렬 알고리즘의 지연 시간을 효과적으로 최적화할 수 있습니다. **예외 발생 데이터 수집 및 타입 분석** * 예외가 던져질 때 CLR은 `ICorProfilerCallback::ExceptionThrown`을 호출하며, 프로파일러는 이를 통해 예외 객체의 `ObjectID`를 획득합니다. * `ICorProfilerInfo::GetClassFromObject`를 사용하여 예외 인스턴스의 `ClassID`를 구하고, 이를 `FrameStore`와 연동하여 클래스 이름을 확인하고 캐싱합니다. * 예외 처리는 `catch` 및 `finally` 블록의 실행을 보장하기 위해 런타임에서 많은 CPU 사이클을 소모하므로, 발생 지점과 타입별 통계를 파악하는 것이 중요합니다. **System.Exception 메시지 추출을 위한 메타데이터 탐색** * 예외의 세부 내용을 파악하기 위해 `_message` 필드의 값을 읽어야 하며, 이를 위해서는 해당 필드의 정확한 메모리 오프셋을 알아야 합니다. * .NET 버전(Framework 또는 Core)에 따라 `mscorlib`나 `System.Private.CoreLib` 모듈을 식별한 후, `IMetaDataImport`를 통해 `System.Exception` 클래스의 메타데이터 토큰을 찾습니다. * `ICorProfilerInfo2::GetClassLayout`을 호출하여 클래스의 필드 레이아웃 정보를 얻고, `_message` 필드의 `COR_FIELD_OFFSET`을 계산하여 문자열 버퍼의 위치를 특정합니다. **락 경합의 지속 시간 및 원인 식별** * .NET 런타임은 `Monitor.Enter` 등을 사용하는 락 패턴에 대해 `ContentionStart`와 `ContentionStop` 이벤트를 발생시킵니다. * .NET Framework와 같이 이벤트 자체에서 지속 시간을 제공하지 않는 경우, 프로파일러가 직접 스레드별로 시작 시점의 타임스탬프를 관리하여 대기 시간을 계산합니다. * .NET 8부터는 `ContentionStart` 이벤트에 락의 `ObjectID`와 현재 락을 점유 중인 스레드 정보가 포함되어, 어떤 스레드가 다른 스레드를 대기하게 만드는지 구체적으로 가시화할 수 있습니다. **EventPipe를 통한 효율적인 실시간 이벤트 모니터링** * .NET 5 이상에서는 `ICorProfilerCallback10::EventPipeEventDelivered` 메서드를 통해 CLR 이벤트를 동기적으로 수신할 수 있습니다. * `ClrEventParser` 클래스는 이벤트 페이로드에서 ID와 키워드를 기반으로 필요한 필드만 추출하여 성능 부하를 최소화합니다. * 이러한 메커니즘을 통해 애플리케이션 실행에 거의 영향을 주지 않으면서도(Negligible impact) 상세한 프로파일링 데이터를 확보합니다. 성능 최적화를 위해서는 `Parse` 대신 `TryParse`를 사용하여 불필요한 예외 비용을 줄이고, 프로파일러가 제공하는 락 지속 시간 데이터를 바탕으로 과도한 동기화 구문을 개선하는 실용적인 접근이 필요합니다.

figma3분 읽기큐레이션 요약

이 올드스쿨 커서

Figma는 2024년 April Fun Day를 맞아 DOS부터 Y2K, 스큐어모피즘, Windows Vista의 Aero까지 과거 디지털 디자인을 재현한 커서를 공개했다. 커서는 단순한 포인터가 아니라 Figma·FigJam에서 사용자의 존재와 협업을 나타내는 아바타이므로, 시대별 시각 언어를 통해 개인 표현과 공동 작업 경험을 확장하려는 시도다. 사용자는 Figma 또는 FigJam 파일 우측 상단의 커서 아이콘에서 일주일 동안 네 가지 레트로 스타일을 선택할 수 있었다. ## 커서와 온라인 협업의 의미 - Figma와 FigJam에서 커서는 여러 사용자가 같은 캔버스에서 작업하고 있음을 보여주는 협업 아바타다. - 커서는 위치 표시뿐 아니라 커서 채팅, 이모트, 하이파이브 같은 상호작용도 지원한다. - 화면을 사이에 두고도 서로의 존재와 감정을 확인하게 해주는 인터페이스 요소라는 점에서, 단순한 UI 장식 이상의 역할을 한다. - 이번 기획은 커서를 디지털 시대의 상징적 상호작용 요소로 보고, 인터넷 역사 속 네 가지 미학으로 재해석했다. ## 8비트: 픽셀로 표현한 초기 컴퓨터 문화 - 8비트 스타일은 텍스트 기반 터미널부터 Windows 2000 초기까지의 웹과 컴퓨터 문화를 떠올리게 한다. - Pac-Man, Space Invaders 같은 아케이드 게임과 저해상도 화면, 굵은 픽셀이 주요 시각적 영감이다. - DOS는 GUI 없이 사용자가 명령어를 직접 입력하는 텍스트 기반 운영체제이며, GUI는 아이콘·창·메뉴·버튼으로 정보를 표현한다. - 제작진에게 DOS 시절의 컴퓨터 경험은 초기 컴퓨팅에 대한 개인적인 향수와 연결되어 있다. - Windows 2000의 입체적인 아이콘, 돌출된 시작 버튼, 움푹 들어간 시계 영역처럼 빛과 깊이를 표현한 디자인도 당시의 중요한 기억으로 언급된다. - 커서 디자인에서는 해상도를 의도적으로 낮춰 픽셀 격자를 강조하고, 손가락 모양이나 2번 연필처럼 단순하고 친근한 아이콘을 활용했다. - 제한적인 그래픽 안에서도 손, 하트, 연필 등 표현력 있는 형태를 사용해 레트로 감성과 개성을 살렸다. ## Y2K: 2000년 전후의 대중문화와 디지털 감성 - Y2K 섹션은 2000년 전후의 패션과 대중문화를 배경으로 한다. - 카고 팬츠, 베이비 티, Backstreet Boys의 앨범 *Millennium*, 전화 접속 인터넷의 전자음 같은 요소가 시대적 분위기를 구성한다. - 투명한 플라스틱 소재의 다마고치 이미지는 당시 소비자 전자제품과 장난감에서 나타난 미래 지향적이고 장난스러운 감성을 상징한다. - 글은 Y2K가 약 25년 전의 스타일임에도 현재 낯설지 않은 이유를 되짚으며, 당시의 시각 언어를 커서 디자인으로 재현하려 한다. ## 네 가지 레트로 스타일의 재해석 - Figma가 소개한 커서 테마는 8비트, Y2K, 스큐어모픽, Aero로 구성된다. - 각 스타일은 특정 운영체제나 장식만 복원하는 것이 아니라, 해당 시대의 기술 경험과 대중문화, 인터페이스 감각을 함께 재현한다. - 레트로 디자인을 현대 협업 도구에 적용함으로써 향수를 자극하면서도 사용자의 개성을 드러내는 기능으로 확장했다. - 커서는 작고 단순한 UI 요소지만, 색상·형태·질감만으로도 시대적 분위기와 사용자 정체성을 표현할 수 있다. 실용적으로는 레트로 스타일을 단순한 장식으로만 보지 말고, 사용자의 존재감과 감정 표현을 강화하는 인터랙션 디자인 요소로 활용할 수 있다. 특히 협업 제품에서는 작은 시각적 변화도 참여감과 친밀감을 높이는 장치가 될 수 있다.

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

Framework by Figma에 여러분을 초대합니다

Figma는 디자인 시스템을 단순한 스타일 가이드가 아니라 제품 설계와 개발을 지탱하는 기반으로 보고, 이를 주제로 한 글로벌 행사 ‘Framework by Figma’를 2024년 4월 16일 개최한다고 소개했다. 행사는 새로운 기능, 운영 모범 사례, 디자인-코드 연결, 디자이너와 엔지니어 간 협업을 다룬다. 이후 행사에서는 Code Connect, 타이포그래피·그라디언트 변수, Library Analytics API 등이 공개됐다. ## 디자인 시스템의 확장과 복잡성 - 디자인 시스템은 초기의 단순한 스타일 가이드에서 제품 개발 전반의 기반으로 발전했다. - 실제 도입과 운영 과정에서는 도구 선택, 자동화, 접근성, 조직 내 채택률 관리 등 다양한 문제가 발생한다. - Figma는 현재와 미래의 복잡한 요구를 지원하는 기능과 운영 전략을 행사에서 공유하려 했다. - 시스템을 미리 구조화한 경우뿐 아니라 자유롭게 작업하는 상황도 지원해야 한다는 철학을 강조했다. ## Framework 행사에서 다룬 내용 - 새로운 디자인 시스템 기능을 심층적으로 소개한다. - 디자인 시스템을 효과적으로 구축하고 유지하는 모범 사례를 공유한다. - Verizon 등 업계 기업의 디자인 시스템 구축 및 운영 경험을 소개한다. - Figma 제품팀이 향후 개발 방향을 설명한다. - Bumble, GitHub, Hewlett Packard가 참여하는 디자인-코드 연계 라운드테이블을 진행한다. - 참가자들의 실무 질문에 답하는 전문가 Q&A를 마련한다. ## 디자이너와 엔지니어의 연결 - 성공적인 디자인 시스템에는 디자인과 개발 조직의 긴밀한 협업이 필요하다고 설명한다. - 세션은 디자인 원칙부터 기술적 구현까지 두 직군의 공통 관심사를 다룬다. - 디자인 시스템을 코드와 더 가깝게 연결하는 새로운 기능도 소개 대상에 포함됐다. - 이는 디자인 산출물이 실제 제품 코드로 이어지는 과정의 간극을 줄이려는 방향이다. ## 행사에서 공개된 기능 - **Code Connect**: 디자인 시스템 구성 요소와 개발자가 사용하는 코드 컴포넌트를 연결한다. - **타이포그래피 변수와 그라디언트 변수**: 디자인 토큰의 표현 범위를 확장하고 일관된 스타일 관리를 돕는다. - **Library Analytics API**: 조직 내 라이브러리 사용 현황과 디자인 시스템 채택 정도를 분석할 수 있도록 지원한다. - 이러한 기능은 디자인 시스템의 구축뿐 아니라 개발 연계와 조직 전체의 활용도 측정까지 지원하는 데 초점을 둔다. ## 글로벌 디자인 시스템 커뮤니티 - 본 행사는 온라인으로 진행되며 전 세계 디자인 시스템 실무자를 대상으로 했다. - 아시아 지역 온라인 행사는 4월 18일, 도쿄 행사는 4월 23일에 별도로 진행될 예정이었다. - 런던 등 여러 도시에서는 현지 밋업도 계획됐다. - 온라인 스트림을 통해 지역과 관계없이 주요 발표와 세션에 참여할 수 있도록 했다. Figma가 제시한 방향은 디자인 시스템을 엄격한 규칙만으로 운영하기보다, 구조화된 관리와 자유로운 창작을 함께 지원하는 것이다. 조직에서는 디자인 토큰과 컴포넌트 표준화뿐 아니라 코드 연결, 사용량 분석, 디자이너·엔지니어 간 협업 체계까지 함께 구축하는 것이 실용적이다.

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

엔지니어링 스

Datadog은 Gartner의 「Observability Platforms 2026」 매직 쿼드런트에서 ‘Leader’로 선정되었다고 알립니다. 제공된 내용은 이 선정 사실과 Datadog의 제품 카테고리·기능 목록을 중심으로 하며, 평가 기준이나 경쟁사 비교의 구체적인 근거는 포함하지 않습니다. ### Gartner 리더 선정 - Datadog이 Gartner® Magic Quadrant™ for Observability Platforms 2026에서 Leader로 분류되었다는 내용입니다. - 링크는 Datadog의 공식 리소스 페이지로 연결됩니다. - 다만 제공된 본문에는 Gartner의 평가 방법, Datadog의 세부 점수, 강점과 약점, 다른 공급업체와의 비교가 제시되지 않았습니다. ### Datadog의 관측성 제품 범위 - **인프라 모니터링** - 인프라·메트릭·컨테이너·Kubernetes 모니터링 - 네트워크, 서버리스, GPU, 스토리지, 클라우드 비용 관리 - **애플리케이션 성능 관리** - APM, 서비스 모니터링, 연속 프로파일링 - 동적 계측과 AI 에이전트 관측성 - **로그 및 데이터 관리** - 로그 관리, 데이터베이스 모니터링 - 데이터 스트림, 데이터 품질, 작업 모니터링 - 민감 데이터 탐지와 관측성 파이프라인 - **디지털 경험** - 브라우저·모바일 RUM - 세션 리플레이, 신 synthetics 모니터링, 오류 추적, 제품 분석 - **보안** - 코드·클라우드·워크로드 보안 - SAST, IAST, 취약점 관리, Cloud SIEM, 비밀정보 스캐닝 - **소프트웨어 개발 및 서비스 관리** - CI 가시성, 테스트 최적화, 코드 커버리지 - 인시던트 대응, SLO, 이벤트 관리, 워크플로 자동화 - **AI 기능** - Bits AI 에이전트, 조사·보안 분석 기능 - AI 통합, MCP 서버, GPU 모니터링 ### 시사점 - Datadog은 인프라, 애플리케이션, 로그, 보안, 사용자 경험, 개발·운영 데이터를 하나의 플랫폼에서 연결하는 전략을 강조합니다. - 이번 발표는 제품 기능 자체보다 Gartner의 산업 평가에서 리더로 인정받았다는 점을 홍보하는 성격이 강합니다. - 실제 도입을 검토할 때는 Gartner 원문 보고서에서 평가 기준과 제한사항을 확인하고, 데이터 수집 비용·보존 정책·기존 도구와의 통합성·조직의 운영 규모를 함께 비교하는 것이 좋습니다.

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