코딩하는 곰돌이

이벤트 최적화 실험실 Debounce/Throttle 1초에 수십 번씩 쏟아지는 scroll, resize, input 이벤트를 다스리는 두 가지 방법. 정의는 다들 아는데, 막상 눈으로 보면 헷갈리는 두 개념의 차이를 직접 실행해보며 확인합니다. Raw Event Throttle Debounce 브라우저는 마우스를 1px만 움직여도 mousemove를 발화하고, 스크롤바가 살짝만 움직여도 scroll을 발화합니다. 이 이벤트에 매번 API를 호출하거나 무거운 연산을 걸어두면 브라우저는 순식간에 버벅이기 시작합니다. Debounce와 Thro..

```htmlFrontend Performance웹에서부드러운 애니메이션만들기브라우저는 화면을 일정한 주기로 다시 그립니다.requestAnimationFrame()은 이 렌더링 타이밍에 맞춰 실행되므로setInterval()보다 훨씬 자연스럽고 성능도 뛰어난 애니메이션을 만들 수 있습니다.requestAnimationFrame이란?requestAnimationFrame()은 브라우저가 다음 화면을 그리기 직전에콜백을 실행하는 API입니다.덕분에 브라우저 렌더링과 동기화되어 프레임 드랍이 적고,백그라운드 탭에서는 자동으로 호출 빈도를 줄여 CPU 사용량도 감소합니다.브라우저 렌더링 주기와 동기화60fps에 최적화백그라운드에서 자동 절전게임, Canvas, WebGL에서 필수 API기본 사용법animati..

대규모 리스트 렌더링 성능 개선 (가상 스크롤 구현)문제 정의: 왜 10,000개의 li가 브라우저를 멈추게 하는가리스트 아이템이 100개 정도면 그냥 .map()으로 전부 렌더링해도 문제없다. 하지만 10,000개가 되면 이야기가 달라진다.function NaiveList({ items }) { return ( {items.map(item => )} );}이 코드가 느린 이유는 "JS 연산이 오래 걸려서"가 아니다. 진짜 비용은 다음 두 곳에서 발생한다.DOM 노드 개수 자체의 비용: 10,000개의 실제 DOM 노드가 존재하면, 브라우저는 스크롤이 발생할 때마다 이 노드들에 대한 Layout/Paint 계산 후보군을 유지해야 한다. 화면에 보이지 않는 9,900개의 노드도 ..

FLOW-3D 교량 세굴 3D 대시보드실데이터 CSV 연동과 유체·하상 통합 시각화한 줄 요약합성 데모에서 한 걸음 더 — FLOW-3D CSV를 브라우저에서 직접 파싱하고,하상·수면·유체장·세굴 변화량을 단일 시간축 위에 겹쳐 보여주는 3D 대시보드를 완성했다.들어가며지난 스프린트에서 Three.js 기반의 교량 세굴 3D 대시보드 골격을 만들었다.지형 애니메이션, 교각 붕괴 시뮬레이션, 합성 유체장까지 — 데모는 돌아갔다.오늘의 목표는 명확했다.BeforeAfter합성 데이터만 시각화FLOW-3D CSV 직접 업로드수평 슬라이스 중심 유체 표현지형 위 수면 + 추적 입자 + 3D 점군파라미터 패널 하나실험 조건 / 유체 / CSV / 시각 설정 역할 분리HUD 텍스트 오버레이Dock 패널 + 글래스 ..

메모리 누수 디버깅기: Chrome DevTools로 원인 찾기이 글은 실제 트러블슈팅 과정에서 흔히 마주치는 패턴을 재구성한 사례입니다. 본인이 직접 겪은 프로젝트의 세부사항(어떤 컴포넌트였는지, 어떤 지표로 발견했는지)으로 바꿔 넣으면 더 설득력 있는 글이 됩니다. 아래는 그 틀로 활용할 수 있는 실제 디버깅 흐름입니다.증상: 사용자 제보로 시작된 조사"페이지를 오래 켜두면 브라우저가 느려지다가 결국 탭이 죽어요."대시보드형 SPA에서 실시간 데이터를 폴링하며 그래프를 갱신하는 화면이었다. 사용자는 이 화면을 하루 종일 켜둔 채로 사용했고, 몇 시간 뒤부터 스크롤이 버벅이다가 결국 탭이 응답 없음 상태에 빠진다는 제보가 들어왔다.첫 반응은 "메모리 누수겠구나"였지만, 정확히 어디서 새는지 특정하는 게..

검색창에 숫자가 잘못 뜨는 버그, 원인은 내가 처음 의심한 곳이 아니었다아래 사례는 자동완성/검색 기능에서 흔히 발생하는 레이스 컨디션 패턴을 재구성한 것입니다.QA에서 올라온 티켓 제목은 단순했다."검색어를 빠르게 바꾸면 결과 개수가 이상하게 나옵니다."재현 스텝은 더 단순했다. 검색창에 "ا"를 입력하고, 바로 지운 다음 "b"를 입력. 그러면 화면에는 분명 "b"로 검색한 결과가 나와야 하는데, 가끔 "a"로 검색했을 때의 결과 개수가 잠깐 스쳐 지나가듯 보였다가 사라진다는 것이었다. "가끔"이라는 단어가 마음에 걸렸다. 재현이 100%가 아니라는 건 대부분 타이밍 문제라는 뜻이니까.처음의 오진단: 디바운스가 문제인 줄 알았다가장 먼저 의심한 건 디바운스 로직이었다. 검색 입력에 300ms 디바운스..

번들 사이즈 30% 줄인 과정 (Before/After 수치 포함)이 글은 실제 번들 최적화 작업에서 흔히 나타나는 흐름과 대표적인 수치 감소 폭을 재구성한 사례입니다. 아래 수치는 예시이며, 본인의 실제 webpack-bundle-analyzer 결과와 프로젝트 세부사항으로 교체하면 훨씬 신뢰도 높은 포트폴리오 글이 됩니다.배경: Lighthouse 점수 하락으로 시작된 조사배포 후 정기적으로 확인하던 Lighthouse Performance 점수가 몇 주에 걸쳐 조금씩 떨어지고 있었다. "기능을 추가할 때마다 스크립트도 같이 늘어나는 건 자연스러운 일"이라고 넘기기엔, Total Blocking Time과 Largest Contentful Paint 지표가 특히 모바일 환경에서 눈에 띄게 악화되고 있..

CSS의 Layout, Paint, Composite 단계와 리플로우 최적화들어가며"transform과 opacity를 쓰면 성능이 좋다"는 말은 프론트엔드 개발자라면 누구나 안다. 하지만 왜 그런지, 정확히 브라우저 내부의 어느 단계를 건너뛰길래 빠른 것인지 설명할 수 있는 사람은 생각보다 많지 않다. 이 글은 렌더링 파이프라인의 각 단계를 코드 수준에서 파고들고, 실제로 측정 가능한 방식으로 리플로우 비용을 검증하는 것을 목표로 한다.1. 렌더링 파이프라인 전체 구조브라우저가 HTML/CSS를 화면에 그리기까지의 과정은 다음과 같다.1. DOM 생성 : HTML 파싱 → DOM 트리2. CSSOM 생성 : CSS 파싱 → CSSOM 트리3. Render Tree 생성 :..

Webpack vs Vite, 번들링 원리부터 이해하기들어가며"Vite가 Webpack보다 빠르다"는 문장은 이제 너무 흔해서 오히려 아무 정보도 주지 못한다. 왜 빠른지, 정확히 어느 단계에서 빠른지, 그리고 그 대가로 무엇을 포기했는지를 설명하지 않으면 이 문장은 마케팅 문구와 다를 게 없다.이 글은 "설정 방법"이나 "속도 비교표"를 다루지 않는다. 대신 두 도구가 내부적으로 모듈을 어떻게 다루는지, 그리고 그 설계 차이가 왜 필연적으로 지금의 성능 특성을 만드는지를 파고든다.1. 번들러가 푸는 문제: 모듈 그래프모든 번들러의 출발점은 동일하다. 브라우저는 원래 import라는 개념을 파일 단위로 즉시 이해하지 못했던 시절이 있었고(지금은 ESM을 네이티브 지원하지만), 수백~수천 개의 모듈을 하나..

React가 Virtual DOM을 사용하는 이유와 실제 성능 이점 측정들어가며"React는 Virtual DOM을 사용하기 때문에 빠르다"는 말은 프론트엔드 개발자라면 한 번쯤 들어봤을 것이다. 하지만 이 명제는 정확하지 않다. Virtual DOM은 실제 DOM보다 본질적으로 빠르지 않으며, 오히려 순수한 연산량만 놓고 보면 오버헤드가 추가되는 구조다.그렇다면 React는 왜 Virtual DOM을 채택했을까? 이 글에서는 Virtual DOM의 동작 원리를 분석하고, 실제 DOM 조작과 React의 렌더링 방식을 벤치마크 코드로 직접 비교하여 "무엇이 진짜 이점인지"를 정리한다.1. 실제 DOM 조작이 비싼 이유브라우저가 DOM을 변경할 때 내부적으로 다음 파이프라인이 발생한다.DOM/CSSOM 변..