cloudflare·2026년 4월 17일원문

공유 사전: 에이전틱 웹에 발맞춘 압축 기술 (새 탭에서 열림)

웹 페이지의 무게가 매년 증가하고 에이전트 기반의 트래픽이 급증하는 현대 웹 환경에서, 공유 사전(Shared Dictionaries) 기술은 대역폭 낭비를 획기적으로 줄일 수 있는 핵심 솔루션입니다. 이 기술은 클라이언트가 이미 캐시한 데이터를 사전으로 활용해 변경된 차이점(Delta)만 전송함으로써, 잦은 배포와 무거운 에셋 환경에서도 로딩 속도를 극대화하고 서버 부하를 최소화합니다. 클라우드플레어는 이러한 압축 표준인 RFC 9842 지원을 통해 효율적인 에이전틱 웹(Agentic Web) 시대를 대비하고자 합니다. ### 빈번한 배포와 캐싱 효율의 저하 * **에이전트 트래픽의 급증:** AI 크롤러와 에이전트 기반 도구들이 전체 요청의 상당 부분을 차지하며, 이들은 정보를 추출하기 위해 전체 페이지를 반복적으로 호출합니다. * **AI 기반 개발 가속화:** AI 보조 개발로 인해 팀들의 배포 주기가 짧아졌으나, 이는 곧 캐시 무효화의 빈도를 높여 단 몇 줄의 코드 수정만으로도 사용자가 전체 JS/CSS 번들을 다시 다운로드하게 만듭니다. * **중복 데이터 전송:** 기존 압축 방식은 파일 내부의 중복은 줄여주지만, 클라이언트가 이미 95% 동일한 파일을 가지고 있다는 사실을 인지하지 못해 수백 메가바이트의 불필요한 데이터를 전송하게 됩니다. ### 공유 사전과 델타 압축의 메커니즘 * **참조 기반 압축:** 서버와 클라이언트가 공통의 '사전(Dictionary)'을 공유하여, 서버는 "이미 알고 있는 내용은 제외하고 새로운 부분만 보낸다"는 방식으로 데이터를 압축합니다. * **델타 압축(Delta Compression):** 브라우저에 이미 캐시된 이전 버전의 리소스를 사전으로 변환합니다. 예를 들어 500KB 크기의 번들에서 한 줄의 코드만 수정되었다면, 실제 네트워크를 통해 전송되는 크기는 몇 KB 수준으로 줄어듭니다. * **HTTP 헤더 활용:** 서버가 `Use-As-Dictionary` 헤더를 통해 특정 파일을 사전으로 지정하면, 브라우저는 다음 요청 시 `Available-Dictionary` 헤더를 통해 자신이 가진 사전을 서버에 알리고 차이점만 수신합니다. * **지속적인 절감:** 버전 1과 버전 2 사이의 차이점만 전송하고, 다시 버전 2를 사전 삼아 버전 3의 차이점만 전송하는 방식으로 배포 횟수가 늘어나도 데이터 절감 효과가 누적됩니다. ### 과거의 한계 극복과 보안 강화 * **SDCH의 실패와 교훈:** 2008년 구글이 시도했던 SDCH는 성능은 좋았으나 CRIME, BREACH 같은 압축 사이드 채널 공격에 취약했고 동일 출처 정책(Same-Origin Policy) 위반 이슈로 퇴출되었습니다. * **RFC 9842 표준:** 최신 표준인 'Compression Dictionary Transport'는 사전을 동일 출처 응답에만 사용할 수 있도록 강제하여 보안 취약점을 해결했습니다. * **브라우저 지원 현황:** 크롬과 엣지는 이미 지원을 시작했으며 파이어폭스도 도입을 준비 중입니다. 이는 단순한 압축 기술을 넘어 복잡한 캐싱 로직과 실시간 델타 압축을 결합한 고난도 기술 구현의 결과물입니다. 잦은 업데이트가 발생하는 모바일 앱의 웹뷰나 대규모 자바스크립트 프레임워크를 사용하는 프로젝트라면, 공유 사전 기술 도입을 통해 사용자 경험을 혁신할 수 있습니다. 특히 네트워크 환경이 불안정한 사용자나 데이터 비용이 민감한 환경에서 그 가치는 더욱 빛을 발할 것입니다.

web-performancehttpdelta-compressionshared-compression+4

github·2026년 4월 3일·4분 읽기큐레이션 요약

Diff 라인 성능 개선을 위한 험난한 여정

GitHub는 대규모 풀 리퀘스트에서도 **Files changed** 탭의 반응성과 안정성을 유지하기 위해 단일 해결책이 아닌 여러 최적화 전략을 적용했다. 특히 diff 라인마다 생성되는 DOM 요소, React 컴포넌트, 이벤트 핸들러를 줄여 메모리 사용량과 입력 지연을 낮추고, 가장 큰 변경 사항에는 가상화를 적용해 렌더링 범위를 제한하는 방향을 택했다. 핵심 교훈은 작은 구조적 최적화도 수천 개의 diff 라인에 누적되면 큰 성능 개선으로 이어진다는 것이다. ## 대규모 풀 리퀘스트에서 성능이 어려운 이유 - GitHub의 풀 리퀘스트는 한 줄 수정부터 수천 개 파일과 수백만 줄을 포함하는 변경까지 규모 편차가 매우 크다. - 일반적인 풀 리퀘스트는 빠르게 동작했지만, 대규모 변경에서는 다음 문제가 발생했다. - JavaScript 힙이 극단적인 경우 1GB를 초과 - DOM 노드 수가 40만 개 이상으로 증가 - 페이지 상호작용이 매우 느려지거나 사실상 사용할 수 없게 됨 - 입력 후 다음 화면이 표시되기까지의 시간인 INP가 허용 수준을 초과 - 모든 기능과 브라우저의 기본 동작을 유지하면서 최악의 경우까지 해결하는 단일 기법은 현실적인 한계가 있었다. ## 풀 리퀘스트 규모별 최적화 전략 GitHub는 변경 규모와 복잡도에 따라 서로 다른 전략을 조합했다. - **diff 라인 컴포넌트 최적화** - 대부분의 풀 리퀘스트에서 기본 diff 화면을 빠르게 유지 - 중간 및 대규모 리뷰에서도 브라우저의 기본 `find-in-page` 같은 동작을 보존 - **가상화를 통한 점진적 성능 저하** - 가장 큰 풀 리퀘스트에서는 한 번에 렌더링하는 콘텐츠 양을 제한 - 모든 내용을 동시에 DOM에 올리지 않아 응답성과 안정성을 우선 - **기반 컴포넌트와 렌더링 개선** - 특정 모드에 관계없이 모든 크기의 풀 리퀘스트에 누적 효과를 제공 - 렌더링 구조 자체를 단순화해 메모리와 상호작용 비용을 줄임 ## 초기 목표와 측정 지표 최적화 작업의 목표는 단순히 평균 속도를 높이는 데 그치지 않았다. - JavaScript 힙 크기와 메모리 사용량 감소 - DOM 노드 수 감소 - 평균 INP 개선 - 특히 최악의 사용자 경험을 나타내는 p95와 p99 INP 대폭 개선 - 이를 위해 상태, HTML 요소, JavaScript 코드, React 컴포넌트 수를 전반적으로 줄이는 단순화 전략을 채택 ## v1의 문제: diff 라인당 높은 렌더링 비용 React로 처음 diff 화면을 구현한 v1은 작은 재사용 컴포넌트를 많이 조합하는 구조였다. - unified 뷰의 diff 한 줄에는 최소 약 10개의 DOM 요소가 필요했다. - split 뷰에서는 한 줄당 약 15개의 DOM 요소가 필요했다. - 구문 강조를 적용하면 추가 `<span>` 요소가 더해져 DOM 수가 증가했다. - React 계층에서도 다음과 같은 컴포넌트가 생성됐다. - unified 뷰: 한 줄당 최소 8개 컴포넌트 - split 뷰: 한 줄당 최소 13개 컴포넌트 - 댓글, hover, focus 등 추가 상태가 활성화되면 컴포넌트 수는 더 늘어났다. - 작은 컴포넌트마다 React 이벤트 핸들러를 5~6개씩 연결하는 경우가 많았다. - 결과적으로 diff 한 줄에 20개 이상의 이벤트 핸들러가 붙을 수 있었고, 이를 수천 줄에 적용하면서 비용이 급격히 커졌다. v1의 한 줄당 최소 구조는 다음과 같았다. - DOM 요소 10~15개 - React 컴포넌트 8~13개 - React 이벤트 핸들러 20개 이상 - 다수의 작은 재사용 컴포넌트 이 구조는 일반적인 규모에서는 문제가 없었지만, 데이터 크기가 사실상 제한되지 않는 대규모 풀 리퀘스트에서는 변경 줄 수가 늘수록 INP와 JavaScript 힙 사용량이 함께 악화됐다. ## v2의 방향: 작은 변경을 대규모로 누적 v2에서는 눈에 띄지 않는 HTML 구조까지 점검해 diff 라인당 비용을 줄였다. - 줄 번호 셀에 불필요하게 포함되어 있던 `<code>` 태그를 제거했다. - diff 한 줄에서 DOM 노드 2개를 줄이는 것은 개별적으로는 작은 개선처럼 보인다. - 그러나 10,000줄을 렌더링하면 DOM 노드 20,000개를 제거하는 효과가 발생한다. - 이처럼 줄 단위의 사소한 최적화도 대규모 데이터에서는 메모리 사용량과 렌더링 비용에 크게 누적된다. - 성능 개선에서는 큰 기능 변경만큼 불필요한 태그, 컴포넌트, 이벤트 핸들러를 하나씩 제거하는 작업도 중요하다. ## 실용적인 결론 대규모 목록이나 코드 diff를 렌더링할 때는 처음부터 최악의 데이터 규모를 고려해야 한다. 컴포넌트를 잘게 나누는 구조가 유지보수에는 유리할 수 있지만, 각 요소에 상태와 이벤트 핸들러를 추가하면 수천 개 항목에서 큰 비용이 된다. 따라서 DOM 구조를 단순화하고, 항목별 렌더링 비용을 측정하며, 극단적인 규모에는 가상화를 적용하는 조합이 효과적이다.

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

web-performanceReactJavaScriptHTML+3

naver·2026년 1월 19일원문

네이버 통합검색 AIB 도입과 웹 성능 변화 분석 (새 탭에서 열림)

네이버 통합검색에 도입된 AI 브리핑(AIB)은 채팅 기반의 동적인 UI 특성으로 인해 기존의 핵심 웹 지표인 LCP(Largest Contentful Paint)를 지연시키는 결과를 초래했습니다. 분석 결과, 이는 서버 성능의 문제가 아니라 스트리밍 방식의 어절 단위 렌더링과 인터랙션을 위한 DOM 재구성 등 클라이언트 측의 구조적 특성이 LCP 측정 방식과 충돌하며 발생한 현상으로 확인되었습니다. 네이버는 이러한 UI 특성을 고려하여 LCP 위주의 단일 지표 관리에서 벗어나, TTFT(Time to First Token)와 같은 사용자 체감 성능에 특화된 새로운 측정 체계를 도입하여 성능 관리를 고도화할 계획입니다. **AIB 도입에 따른 성능 지표의 변화** * **LCP p95 지표 악화:** AIB 노출량이 증가함에 따라 통합검색의 LCP p95 값이 목표치인 2.5초를 상회하는 약 3.1초까지 상승하는 경향을 보였습니다. * **성능 분포의 변화:** AIB가 전체 LCP 분포의 꼬리(tail) 영역에 영향을 주면서, 'Good' 구간에 해당하는 사용자 비율이 감소하고 느린 구간의 사용자가 증가했습니다. * **렌더링 방식의 차이:** 구글의 AI Overview가 블록 단위로 렌더링하는 것과 달리, 네이버 AIB는 어절 단위의 점진적 노출과 적극적인 애니메이션을 사용하여 지표 측정에 더 큰 영향을 미쳤습니다. **채팅 UI에서 LCP 왜곡이 발생하는 기술적 원인** * **DOM 재구성 로직:** 텍스트 애니메이션이 끝난 후 하이라이트 기능을 위해 DOM 구조를 다시 변경하는 과정에서, 브라우저가 LCP 후보 영역의 렌더링 시점을 실제보다 늦게 기록하게 됩니다. * **어절 단위 렌더링의 한계:** 콘텐츠가 어절 단위로 쪼개져 렌더링되면 LCP 알고리즘이 '가장 큰 텍스트 블록'을 찾지 못하거나, 의미가 적은 작은 요소를 LCP로 잘못 선택하는 문제가 발생합니다. * **Chromium Paint Invalidation:** 스트리밍 방식으로 텍스트가 추가될 때마다 해당 레이어 전체에 페인트 무효화가 발생하며, 이로 인해 이미 화면에 그려진 요소의 `renderTime`이 프레임 단위로 계속 갱신되어 최종 측정값이 늦춰집니다. **네이버 통합검색의 성능 관리 개선 방향** * **독립적 성능 기준 수립:** AIB 영역을 제외한 일반 검색 결과의 LCP 'Good' 비율은 96%로 안정적이므로, AIB와 같은 특수 UI에는 별도의 성능 지표를 적용할 필요가 있습니다. * **TTFT(Time to First Token) 도입:** 사용자가 첫 번째 응답을 인지하는 시점을 측정하는 TTFT를 핵심 지표로 검토하여, 채팅 UI의 실제 체감 성능을 더 정확하게 반영하고자 합니다. * **지표 해석의 고도화:** 단순히 수치상의 LCP 최적화에 매몰되지 않고, UI의 특성과 사용자 경험을 더 잘 예측할 수 있도록 지표 분석 체계를 세분화하고 개선해 나갈 예정입니다. 현대적인 웹 환경에서는 스트리밍이나 동적 인터랙션이 강조되는 만큼, 기존의 정적 페이지 중심 지표인 LCP만으로 모든 성능을 대변하기 어렵습니다. 따라서 서비스의 UI 특성에 맞춰 TTFT와 같은 대안 지표를 함께 활용하고, 지표의 수치 너머에 있는 브라우저 렌더링 파이프라인의 동작 원리를 이해하는 것이 실질적인 사용자 경험 개선의 핵심입니다.

web-performancechromiumlargest-contentful-paintcore-web-vitals+4

figma·2025년 4월 16일·4분 읽기큐레이션 요약

버전 관리: UX 라이터

Figma의 UX Writer Henry Freedland는 프로토타입 오프라인 기능의 메뉴 문구를 다듬으며, 단어 하나가 사용자의 기대와 실제 시스템 동작 사이의 신뢰를 좌우한다고 설명합니다. 기술적으로 정확한 표현보다 사용자가 무엇을 하려는지, 클릭 후 어떤 결과를 기대하는지를 명확히 연결하는 표현이 중요합니다. 결국 UX 글쓰기는 단순한 문구 수정이 아니라 제품의 동작과 사용자 경험을 정렬하는 작업입니다. ## UX 글쓰기가 드러내는 제품의 본질 - Figma는 인터넷 없이도 프로토타입을 안정적으로 발표할 수 있도록 오프라인 기능을 개발했습니다. - 기능 구현이 거의 끝난 시점에 메뉴 문구를 정하려 했지만, 어떤 단어를 선택할지 논의하는 과정에서 제품이 실제로 무엇을 하는지에 대한 근본적인 질문이 드러났습니다. - UX 문구는 사용자가 시스템의 동작 방식을 이해하고 예측하도록 돕는 일종의 안내 규칙입니다. - 동작 자체가 명확하지 않다면, 아무리 짧고 자연스러운 문구라도 사용자 기대와 실제 결과 사이에 혼란이 생깁니다. ## 1차 시도: “Preload prototype”의 기술적 정확성 - 초기 문구는 **“Preload prototype”**이었습니다. - 프로토타입을 화면을 이동할 때마다 불러오는 대신, 필요한 리소스를 미리 모두 로드한다는 기술적 동작을 정확히 표현합니다. - 하지만 “pre-”라는 접두사는 보통 어떤 일이 일어나기 전에 수행되는 작업을 뜻합니다. - 예: 오븐을 미리 데우는 “preheat” - 사용자는 이미 프로토타입을 로드한 뒤 이 옵션을 보게 되므로, 무엇을 “미리” 로드한다는 것인지 직관적으로 이해하기 어렵습니다. - 기술 배경이 있는 사람에게는 익숙하지만, 일반 사용자에게는 다음과 같은 추가 설명이 필요합니다. - 현재 무엇이 이미 로드되었는가? - 무엇을 추가로 로드하는가? - 언제 오프라인 상태로 전환되는가? ## “Load full prototype”이 해결하지 못한 신뢰 문제 - 더 익숙한 동사인 **“load”**를 사용해 다음과 같은 표현도 검토했습니다. - “Load full prototype” - “Load all screens” - “Load all assets” - 그러나 사용자는 이미 프로토타입을 열었기 때문에, “전체 프로토타입을 로드한다”는 표현이 현재 상태와 충돌할 수 있습니다. - 컴퓨터가 “로드 중”이라고 알려주면 사용자는 그 과정을 신뢰하지만, 로딩이 끝난 뒤에는 모든 것이 준비되었다고 믿게 됩니다. - 따라서 “Load full prototype”은 현재 화면이 사실은 완전히 준비된 상태가 아니라는 인상을 주며, 프로그램과 사용자 사이의 신뢰를 약화시킬 수 있습니다. - 기술적으로 정확한 명칭이라도 사용자의 현재 상황과 맞지 않으면 좋은 UX 문구가 되지 않습니다. ## 2차 시도: 사용자의 목적을 직접 표현하기 - 기능의 목적은 인터넷이 없어도 프로토타입을 안정적으로 발표하는 것이므로 다음 표현도 제안되었습니다. - “Present prototype offline” - “Prepare to present offline” - 소프트웨어 문구는 사용자가 왜 어떤 행동을 하는지부터 고려해야 합니다. - Terry Winograd의 표현처럼 사람은 언어를 통해 행동하므로, 메뉴 문구는 사용자의 의도와 컴퓨터의 실행 동작을 연결해야 합니다. - **“Present prototype offline”**은 실제로 클릭하는 순간 발표가 시작되지 않는다는 점에서 문제가 있습니다. - 사용자는 즉시 발표 화면이 나타날 것이라고 기대할 수 있습니다. - **“Prepare to present offline”**은 준비의 의미가 모호합니다. - 무엇을 준비하는가? - 얼마나 일찍 눌러야 하는가? - 준비가 끝났다는 것을 어떻게 알 수 있는가? - 이 표현들은 사용자를 위한 단계별 안내나 후속 화면이 있다면 사용할 수 있지만, 단순한 토글 메뉴에는 지나치게 무겁고 불명확합니다. ## 문구 선택 기준: 생각·언어·시스템 동작의 일치 - 좋은 UX 문구는 다음 세 가지를 일치시켜야 합니다. - 사용자가 머릿속으로 생각하는 목표 - 메뉴에 표시된 언어 - 실제 시스템이 수행하는 동작 - 세 요소 사이의 간격이 크면 사용자는 클릭 결과를 예측하기 어렵습니다. - 기술 용어를 그대로 노출하면 구현 방식은 설명할 수 있지만 사용자의 목적을 놓칠 수 있습니다. - 반대로 사용자의 목표만 강조하면 시스템이 실제로 무엇을 하는지 알 수 없게 될 수 있습니다. - 특히 토글 메뉴에서는 문구만 보고도 현재 옵션의 의미와 활성화 후 결과를 이해할 수 있어야 합니다. ## 실용적인 결론 오프라인 기능처럼 내부적으로는 복잡한 동작을 수행하는 기능일수록, 기술적 구현명보다 사용자의 기대와 실제 결과를 정확히 연결하는 문구를 선택해야 합니다. 메뉴 문구를 정할 때는 “무엇을 하는가”뿐 아니라 “사용자는 왜 이 기능을 켜는가”, “클릭 직후 무엇이 일어날 것이라고 기대하는가”를 함께 검토하는 것이 좋습니다.

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

web-performanceFigma사용자 경험프로토타이핑+2

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

장인정신과 아름다움

아름다움과 세밀한 완성도는 단순한 장식이 아니라 사용성, 전환율, 매출을 높이는 제품 경쟁력이다. Stripe, Linear, Figma의 리더들은 품질을 제품의 모든 접점에贯穿하는 문화로 정착해야 하며, 이를 위해 성능·명확성·직관성까지 포함한 전방위적인 노력이 필요하다고 말한다. 실제로 Stripe의 결제 제품은 평균 11.9%의 매출 증가를, 이메일 개편은 전환율 20% 향상을 이끌었다. ### 아름다움은 사용성과 전환율을 높인다 - 미적인 요소는 표면적인 꾸밈이 아니라 제품을 더 쉽게 이해하고 사용하게 만드는 기능적 요소다. - 사용자는 아름답고 명확한 제품을 더 잘 작동한다고 인식하는 경향이 있다. 이를 **미적 사용성 효과(aesthetic usability effect)**라고 한다. - 매력적이고 이해하기 쉬운 인터페이스는 사용자의 관심을 끌고, 다음 행동을 명확하게 하며, 성공적인 사용 경험으로 이어진다. - Stripe는 이메일의 문구, 시각적 계층 구조, 전체적인 사용 흐름을 개선했다. - 그 결과 해당 이메일 시리즈의 제품 전환율이 **20% 증가**했다. - Stripe Optimized Checkout Suite를 사용한 기업들은 평균적으로 **11.9% 더 높은 매출**을 기록했다. - 따라서 제품 여정의 모든 접점은 가치를 더하거나 빼는 요소가 될 수 있으며, 모든 단계에서 완성도를 관리해야 한다. ### 크래프트는 태도이고 아름다움은 결과다 - Linear의 Karri Saarinen은 두 개념을 구분한다. - **크래프트(craft)**: 결과물의 품질을 중요하게 여기는 작업 방식과 태도 - **아름다움(beauty)**: 그러한 태도가 만들어낸 사용자가 경험하는 품질과 결과 - 크래프트는 단순히 요구사항을 빨리 끝내는 것이 아니라, 결과가 충분히 좋은지 지속적으로 고민하는 자세다. - 아름다움은 외형만을 뜻하지 않는다. - 창문이 실제로 잘 열리는가 - 소음이 적은가 - 사용 과정이 자연스러운가 - 따라서 디자인의 가치는 시각적 매력뿐 아니라 기능성과 전반적인 품질을 포함한다. ### 성능과 완성도는 제품의 기본 조건이다 - Figma는 웹에서도 네이티브 애플리케이션과 같은 경험을 제공하는 것을 목표로 출발했다. - 이를 위해 프레임 레이트와 상호작용 성능 같은 기초 요소를 중요하게 다룬다. - 초당 60프레임 수준의 부드러운 상호작용이 무너지면, 그 위에 쌓이는 다른 디자인 요소도 제대로 경험할 수 없다. - 제품 품질에는 위계가 있다. - 먼저 성능과 안정성 같은 기반이 갖춰져야 한다. - 그 위에 직관성, 세심한 인터랙션, 시각적 아름다움을 쌓을 수 있다. - 최고의 완성도는 사용자가 특별히 의식하지 않아도 “모든 것이 자연스럽게 작동한다”고 느끼게 만든다. ### 크래프트는 조직 문화에서 시작된다 - 완성도는 특정 디자인팀이나 QA팀만의 책임이 아니라 회사 전체의 문화적 책임이다. - 구성원들이 품질을 중요하게 여기도록 별도의 목표나 OKR로 강제하기보다, 처음부터 품질에 관심이 있는 사람을 채용하고 육성해야 한다. - 크래프트는 사용자가 세부 사항을 자세히 보지 않더라도 경험 전반에 영향을 준다. - 성능, 문구, 시각 디자인, 인터랙션, 제품 흐름 등 여러 직군의 판단이 합쳐져 최종 품질을 만든다. ### 처음부터 끝까지 제품을 직접 점검하라 - Stripe는 문제를 발견하기 위해 **프릭션 로깅(friction logging)** 방식을 활용한다. - 엔지니어, 제품 관리자, 디자이너 등 여러 직군이 함께 실제 사용자처럼 제품을 처음부터 끝까지 사용한다. - 이러한 “매장 둘러보기(walking the store)” 방식으로 다양한 화면과 접점에서 불편함을 직접 찾는다. - 특정 팀의 화면만 개선하는 것이 아니라, 전체 사용자 여정에서 마찰과 품질 저하 지점을 확인하는 접근이다. - 제품의 모든 접점이 브랜드와 비즈니스 성과에 영향을 주므로, 엔드투엔드 관점의 검토가 필요하다. 제품의 아름다움은 장식이 아니라 성능, 명확성, 사용성, 세심함이 결합된 결과다. 따라서 기업은 단기적인 기능 출시보다 모든 팀이 품질을 당연하게 여기는 문화를 만들고, 실제 사용자 여정을 반복적으로 점검하는 방식을 도입하는 것이 좋다.

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

web-performanceFigma사용자 경험프로덕트 디자인+2

figma·2023년 5월 2일원문

피그마가 게임 세계에서 (새 탭에서 열림)

피그마는 단순한 웹 애플리케이션을 넘어 고성능 게임 엔진과 유사한 기술적 아키텍처를 기반으로 구축된 창의적 협업 도구입니다. 이 글은 피그마가 실시간 멀티플레이어 시스템, 물리 기반 애니메이션, 그리고 C++와 WebAssembly, Rust와 같은 고성능 스택을 통해 어떻게 디지털 세계를 구축하는지 설명합니다. 결과적으로 피그마는 게임 개발의 복잡한 시스템 상호작용 원리를 차용하여 사용자들에게 몰입감 있고 매끄러운 디자인 경험을 제공하고 있습니다. ## 디지털 세계를 구축하는 엔진으로서의 피그마 * 피그마의 핵심은 웹 기반의 2D 그래픽 및 렌더링 시스템으로, 이는 마인크래프트와 같은 게임 엔진의 근간과 동일한 구조를 가집니다. * 사용자가 생성하는 모든 텍스트, 도형, 선을 브라우저에서 실시간으로 구현하며, 방대한 캔버스에서의 팬(pan)과 줌(zoom) 조작 시에도 정확한 위치에 객체를 렌더링합니다. * 실시간 동시 편집 기능을 게임의 개념에서 착안한 '멀티플레이어(multiplayer)' 엔진이라고 명명하여 협업의 핵심 시스템으로 발전시켰습니다. * 브라우저 및 모바일 앱의 메모리와 성능 제약을 극복하기 위해 일반적인 웹 스택 대신 C++로 캔버스를 구축한 후 WebAssembly로 컴파일하여 로딩 속도를 3배 개선했으며, 서버 측 성능 향상을 위해 Rust 언어를 도입했습니다. ## 시스템 기반의 창의적 협업과 상호작용 * 게임 스튜디오에서 엔지니어와 아티스트가 협업하듯, 피그마 엔지니어들은 시스템의 한계를 밀어붙이기 위해 디자이너, PM, 데이터 과학자들과 긴밀하게 소통합니다. * '젤다의 전설: 브레스 오브 더 와일드'의 불(fire) 시스템이 빛, 온기, 공격 수단 등 다양한 방식으로 상호작용하는 것처럼, 피그마의 오토세이브, 멀티플레이어, 렌더링 시스템도 서로 유기적으로 연결되어 작동합니다. * 단순한 도구 기능을 넘어 스프링 물리 법칙을 적용한 애니메이션 시스템, 커서 채팅, 하이파이브 기능 등을 통해 사용자가 도구 내에서 살아있는 피드백을 느낄 수 있도록 설계했습니다. * 베리언트(Variants) 기능과 플러그인/위젯 시스템을 통해 디자인 컴포넌트와 코드를 긴밀하게 연결하고, 사용자가 직접 생태계를 확장할 수 있는 개방형 플랫폼을 지향합니다. 웹 환경에서 복잡하고 성능 집약적인 도구를 개발해야 한다면, 전통적인 웹 프레임워크의 틀을 벗어나 게임 엔진의 설계 방식과 고성능 언어(WASM, Rust) 도입을 검토해야 합니다. 기술적 한계를 극복하는 열쇠는 도구를 하나의 살아있는 '시스템'들의 집합으로 바라보고, 각 요소 간의 상호작용이 사용자 경험에 미치는 영향을 정교하게 설계하는 데 있습니다.

web-performancereal-time-collaborationRustwebassembly+3