코드 땜장이

스레드, 프로세스, 코어는 언제 많을수록 느려질까? 빠른 답 스레드 수를 늘리면 동시에 처리할 수 있는 작업은 늘 수 있지만, 컨텍스트 스위칭, 락 경합, 캐시 미스 비용도 함께 커질 수 있습니다. 프로세스는 메모리 격리와 장애 분리에 유리하지만, 스레드보다 생성 비용과 메모리 사용량, 프로세스 간 통신 비용이 큽니다. 코어가 많아도 프로그램이 일을 병렬로 나누지 못하거나 다른 자원에서 막히면 성능 향상은 제한됩니다. 적정 개수는 CPU 사용률, run queue, 메모리, I/O 대기, p95·p99 응답 시간을 함께 보며 측정해야 합니다. 목차 한눈에 비교 시간 흐름으로 이해하기 왜 많을수록 빨라 보일까 스레드가 많을 때 생기는 비용 프로세스가 많을 때 생기는 비용 코어가 많아도 빨라지지 않는 경우 CPU 바운드와 I/O 바운드의 선택 기준 워커 수와 스레드 풀 크기 잡기 Node.js 워커 스레드로 비교하기 운영 명령 출력으로 병목 확인하기 숫자를 조정할 때 남겨야 할 증거 한눈에 비교 스레드, 프로세스, 코어는 모두 동시 처리와 관련 있지만 같은 층위의 개념은 아닙니다. 코어는 하드웨어 실행 자원이고, 프로세스는 운영체제가 격리해 관리하는 실행 단위이며, 스레드는 프로세스 안에서 작업을 나누는 실행 흐름입니다. 실행 자원 코어는 실제 명령어를 실행하는 CPU 자원이고, 스레드와 프로세스는 그 자원을 배정받는 실행 단위입니다. 격리 수준 프로세스는 독립된 메모리 공간을 갖고, 같은 프로세스 안의 스레드는 메모리를 공유합니다. 생성 비용 프로세스는 주소 공간과 자원을 새로 준비해야 하므로 대체로 무겁고, 스레드는 상대적으로 가볍지만 많아지면 스택 메모리와 스케줄링 비용이 누적됩니다. 통신 방식 스레드는 공유 메모리로 빠르게 데이터를 주고받을 수 있지만 동기화가 필요하고, 프로세스는 IPC를 통해 더 격리된 방식으로 통신합니다. 느려지는 지점 실행 가능한 작업이 CPU 코어보다 많아지거나, 락·메모리·DB·디스크·네트워크 같은 공유 자원에서...

React 리렌더링을 줄이는 실전 기준: memo, useMemo, useCallback은 언제 써야 할까 빠른 답 리렌더링은 React의 정상 동작입니다. 먼저 React DevTools Profiler나 Profiler API로 느린 컴포넌트와 상호작용을 확인하는 편이 좋습니다. memo 는 부모가 자주 렌더링되지만 자식의 props 가 자주 같게 유지되는 경우에 효과가 있습니다. useMemo 는 비싼 계산 결과를 캐시할 때, useCallback 은 함수 참조 변화가 자식 리렌더링이나 Effect 재실행으로 이어질 때 씁니다. 메모이제이션에도 비교 비용, 메모리 비용, 의존성 관리 비용이 있으므로 모든 값과 함수에 붙이는 방식은 대체로 이득이 작습니다. 목차 선택 기준 매트릭스 React 리렌더링 흐름 문제가 되는 리렌더링 현재 기준과 오래된 설명의 차이 상태 소유권부터 정리하기 자식 컴포넌트 리렌더링 줄이기 린트와 구성 기준 Profiler로 병목 확인하기 흔한 오해와 주의사항 선택 기준 매트릭스 상황 부모만 자주 바뀌고 자식 props 는 그대로라면 memo 로 자식 렌더링을 건너뛸 수 있습니다. 상황 큰 배열 필터링, 정렬, 집계처럼 렌더 중 계산이 무겁다면 useMemo 로 계산 결과를 재사용합니다. 상황 memo 로 감싼 자식에게 콜백을 넘기는데 함수 참조가 매번 바뀐다면 useCallback 을 고려합니다. 조건 객체, 배열, 함수가 매 렌더마다 새로 만들어진다면 props 형태를 줄이거나 참조를 안정화해야 memo 가 의미를 가집니다. 조건 입력값, hover, 모달 열림 같은 일시적 UI 상태가 너무 위에 있다면 메모이제이션보다 상태 위치 조정과 컴포넌트 분리가 먼저입니다. 상황 React Compiler를 도입한 환경이라면 수동 메모이제이션 필요성이 줄 수 있지만, 빌드 설정과 지원 범위를 먼저 확인해야 합니다. React 리렌더링 흐름 React 컴포넌트는 state , props , context 가 바뀌면 다시...

큰 이미지가 느릴 때 렌더링 속도를 높이는 법: 포맷, 크기, 로딩 전략 한 번에 정리 빠른 답 원본 이미지를 그대로 내려보내지 말고 실제 표시 크기와 DPR에 맞춘 파일을 서버나 CDN에서 변환해 제공합니다. AVIF와 WebP를 우선하되 로 JPEG 또는 PNG fallback을 함께 두어 브라우저 호환성을 확보합니다. 첫 화면 핵심 이미지는 무조건 lazy 처리하지 말고 fetchpriority="high" 또는 preload를 검토하고, 나머지 이미지만 지연 로딩합니다. Network와 Performance 패널에서 전송 크기, 선택된 소스, 디코드 시간, LCP 후보 이미지를 함께 봐야 병목을 정확히 찾을 수 있습니다. 브라우저 렌더링 흐름을 중심으로 초안을 다시 정리하고, 현재 기준의 포맷 지원과 우선순위 관련 공식 문서 포인트를 짧게 확인하겠습니다. 오래된 설명과 지금 설명이 갈리는 부분도 함께 정리해서 발행용 본문으로 맞추겠습니다.# 큰 이미지가 느릴 때 렌더링 속도를 높이는 법: 포맷, 크기, 로딩 전략 한 번에 정리 목차 시간 흐름으로 이해하기 흐름으로 보기 브라우저 안에서 실제로 무슨 순서로 일어날까 큰 이미지가 느린 이유는 다운로드만이 아니다 현재 기준 포맷 선택과 오래된 설명의 차이 요청 시점과 우선순위 다루기 표시 크기와 레이아웃 안정성 맞추기 CDN, 캐시, 변환 파이프라인에서 줄일 수 있는 비용 DevTools로 병목 확인하기 무엇부터 바꾸면 좋을까 공식 문서와 레퍼런스 시간 흐름으로 이해하기 HTML 파싱 시점 img 는 비교적 빨리 발견되지만 CSS 배경 이미지는 CSS를 읽은 뒤에야 요청 후보가 되는 경우가 많습니다. → 전송 시점 파일 크기, 캐시 적중 여부, CDN 거리 차이가 첫 바이트와 다운로드 시간을 바꿉니다. → 디코드 시점 압축된 파일을 화면용 비트맵으로 풀어내는 과정에서 CPU와 메모리를 사용합니다. → 레이아웃 시점 이미지 비율이 늦게 확정되면 자리 계산이 다시 일어나고 CL...

React에서 useEffect와 useLayoutEffect, 언제 무엇을 써야 할까 빠른 답 기본 선택은 useEffect다. 네트워크 요청, 구독, 이벤트 등록처럼 화면 표시를 막을 이유가 없는 작업에 맞다. useLayoutEffect는 DOM 크기 측정이나 위치 보정처럼 화면이 그려지기 전에 끝나야 하는 작업에만 좁게 쓴다. useLayoutEffect는 브라우저 페인트를 막는 동기 작업이므로 무거우면 첫 화면 표시가 느려진다. React 18 개발 모드에서는 Strict Mode 때문에 Effect가 두 번 실행된 것처럼 보일 수 있어 타이밍 로그를 해석할 때 주의해야 한다. 현재 초안의 구조는 이미 잡혀 있어서, React 공식 문서와 MDN 기준으로 실행 시점 표현만 다시 확인한 뒤 발행용 문장으로 정리하겠습니다. 비교 섹션과 시간축 섹션은 초반에 더 압축하고, 오래된 설명으로 보일 수 있는 부분은 현재 기준 용어로 바로잡겠습니다.공식 문서 기준선은 반영했습니다. 현재 React 문서는 react.dev 의 최신 메이저인 React 19.2 기준이고, 오래된 글에서 자주 보이는 “항상 페인트 후”, “DOM 업데이트 직전” 같은 표현은 지금 문서의 설명과 어긋나는 부분이 있어 그 차이를 본문에 녹여 정리하겠습니다.# React에서 useEffect와 useLayoutEffect, 언제 무엇을 써야 할까 목차 한눈에 비교 시간 흐름으로 이해하기 왜 둘 다 렌더 후처럼 보일까 어떤 작업에 무엇을 써야 하나 깜빡임이 생기는 예제와 해결 방식 React 19.2 기준으로 다시 볼 점 SSR과 하이드레이션에서의 처리 성능과 DevTools에서 확인할 지점 한눈에 비교 실행 시점 useLayoutEffect 는 DOM 커밋 직후, 브라우저 리페인트 전에 실행된다. useEffect 는 대체로 페인트 뒤에 실행된다. 브라우저 영향 useLayoutEffect 는 현재 프레임의 표시를 막을 수 있다. useEffect 는 이미 그려진 화면 뒤...