기본 콘텐츠로 건너뛰기

React 리렌더링을 줄이는 실전 기준: memo, useMemo, useCallback은 언제 써야 할까

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 가 바뀌면 다시...
최근 글

CORS를 제대로 이해하기: 브라우저가 막는 것과 서버가 허용하는 것

CORS를 제대로 이해하기: 브라우저가 막는 것과 서버가 허용하는 것 빠른 답 CORS 오류는 서버 요청 자체가 실패했다기보다, 브라우저가 응답을 JavaScript에 노출하지 않았다는 뜻인 경우가 많습니다. Access-Control-Allow-Origin 은 클라이언트가 요청에 붙여 해결하는 헤더가 아니라 서버가 응답으로 내려줘야 하는 헤더입니다. 쿠키나 인증 정보를 포함하는 요청은 Access-Control-Allow-Origin: * 와 함께 쓸 수 없고, 클라이언트와 서버의 credentials 설정이 함께 맞아야 합니다. 디버깅할 때는 콘솔 메시지뿐 아니라 OPTIONS preflight 응답과 실제 요청의 응답 헤더를 나눠서 확인해야 합니다. 목차 흐름으로 보기 CORS가 필요한 배경 실제로 막히는 지점 서버 CORS 기준선 요청 코드에서 확인할 부분 디버깅과 운영 검증 품질 기준으로 보는 점검 순서 CORS와 CSRF의 차이 흐름으로 보기 흐름 다이어그램 브라우저에서 요청이 발생하면, 브라우저는 현재 페이지의 출처와 요청 대상의 출처를 비교합니다. 출처는 프로토콜, 호스트, 포트의 조합입니다. https://app.example.com 과 https://api.example.com 은 호스트가 다르므로 다른 출처이고, http://localhost:3000 과 http://localhost:8080 은 포트가 다르므로 다른 출처입니다. 출처가 다르면 브라우저는 동일 출처 정책을 기준으로 응답을 JavaScript에 보여줘도 되는지 판단합니다. 요청 자체가 서버까지 도달할 수는 있지만, 서버 응답에 올바른 CORS 헤더가 없으면 브라우저가 응답 본문과 일부 헤더를 코드에 숨깁니다. 요청 메서드나 헤더가 단순 요청 범위를 벗어나면 실제 요청 전에 OPTIONS preflight 요청이 먼저 나갑니다. 예를 들어 Content-Type: application/json 으로 POST 를 보내거나 Authorization 헤더를...

동기와 비동기, 블로킹과 논블로킹을 호출 흐름으로 구분하기

동기와 비동기, 블로킹과 논블로킹을 호출 흐름으로 구분하기 빠른 답 동기와 비동기는 결과를 호출 흐름 안에서 기다릴지, 나중에 별도 흐름으로 받을지의 차이다. 블로킹과 논블로킹은 호출한 스레드가 멈춰서 기다리는지, 제어권을 돌려받아 다음 일을 할 수 있는지의 차이다. 비동기 API를 써도 결과를 바로 get() 이나 join() 으로 기다리면 다시 블로킹 구간이 생긴다. Spring @Async 는 프록시와 Executor 위에서 동작하므로 내부 호출, 예외, 트랜잭션, 스레드풀 포화 상태를 함께 봐야 한다. 목차 한눈에 비교 시간 흐름으로 이해하기 왜 헷갈릴까 동기와 블로킹이 항상 같은 말은 아니다 코드와 출력으로 보는 실행 시점 값, 상태, 오류의 의미 현재 기준 버전과 마이그레이션 포인트 Spring Async 설정과 반환 타입 내부 호출, 예외, 트랜잭션 함정 디버깅과 운영 로그 한눈에 비교 관계 기준 동기와 비동기는 호출자와 작업 결과가 같은 흐름에 묶이는지로 나뉜다. 제어권 기준 블로킹과 논블로킹은 호출 후 현재 스레드가 대기 상태에 들어가는지로 나뉜다. 값 기준 동기 호출은 대개 T 또는 예외를 돌려주고, 비동기 호출은 CompletableFuture<T> 처럼 나중의 완료 상태를 나타내는 핸들을 돌려준다. 오류 기준 동기 오류는 호출 지점의 try-catch 에서 보이고, 비동기 오류는 완료 핸들러, get() , join() 같은 관찰 지점에서 보인다. Spring 기준 @Async 는 호출자 흐름을 먼저 반환시킬 수 있지만, 작업 스레드 안에서 JDBC, 파일, 외부 API를 호출하면 그 스레드는 여전히 블로킹될 수 있다. 시간 흐름으로 이해하기 호출 시작 호출자는 작업을 요청하고 결과가 필요한지, 나중에 받아도 되는지를 정한다. → 제어권 반환 동기 호출은 보통 결과가 나올 때까지 같은 흐름에 머물고, 비동기 호출은 완료 전에도 핸들을 돌려줄 수 있다. → 대기 구간 블로킹이면 현재 스레드가 멈추고, 논블로킹이...

TCP 3-Way Handshake는 어떻게 연결을 만드는가

TCP 3-Way Handshake는 어떻게 연결을 만드는가 빠른 답 3-way handshake는 양쪽이 서로 송수신 가능하다는 사실과 초기 순서 번호를 확인하는 연결 설정 절차입니다. SYN은 연결 요청, SYN-ACK은 요청 수락과 서버의 초기 번호 전달, ACK는 클라이언트의 최종 확인입니다. 연결이 안 될 때는 애플리케이션 코드보다 먼저 포트 리슨 상태, 방화벽, 라우팅, SYN 재전송 여부를 확인해야 합니다. tcpdump나 Wireshark 출력에서 SYN만 반복되면 서버 응답이 없거나 중간 네트워크에서 막힌 상황일 가능성이 큽니다. 목차 시간 흐름으로 이해하기 흐름으로 보기 TCP 연결 설정이 필요한 이유 Sequence Number와 ACK Number 서버 포트와 배포 구성 연결 확인을 위한 최소 예시 패킷 캡처로 보는 정상 handshake 장애 징후와 점검 순서 흔한 오해 시간 흐름으로 이해하기 연결 요청 전 DNS 조회나 설정을 통해 대상 IP와 포트가 정해집니다. → 첫 번째 왕복 전 클라이언트가 SYN 으로 연결 의사와 초기 순서 번호를 보냅니다. → 서버 응답 시점 서버가 포트를 열고 있다면 SYN-ACK 로 요청 수락과 서버의 초기 순서 번호를 돌려줍니다. → 최종 확인 시점 클라이언트가 ACK 를 보내면 양쪽 TCP 상태가 ESTABLISHED 로 바뀝니다. → 데이터 전송 이후 HTTP, 데이터베이스, gRPC 같은 애플리케이션 프로토콜 데이터가 TCP 연결 위에서 오갑니다. 흐름으로 보기 흐름 다이어그램 이 흐름은 브라우저, API 클라이언트, 백엔드 서비스, 데이터베이스 클라이언트 모두에서 같은 구조로 나타납니다. 차이가 있다면 80, 443, 5432, 6379처럼 대상 포트와 그 위에서 동작하는 애플리케이션 프로토콜이 달라진다는 점입니다. ESTABLISHED 상태가 되었다는 말은 TCP 연결이 만들어졌다는 뜻입니다. TLS 인증서 검증, HTTP 라우팅, 데이터베이스 인증, 애플리케이션 권한 ...