코드 땜장이

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

React 동시성 이해하기: 입력은 즉시 반응하고 무거운 렌더링은 뒤로 미루는 법 빠른 답 현재 기준으로는 Concurrent Mode 라는 전역 모드를 켜는 방식보다, createRoot 기반의 동시 렌더링과 transition API를 필요한 업데이트에 적용하는 방식으로 이해하는 편이 정확합니다. 입력창 값처럼 즉시 반영되어야 하는 상태는 transition 으로 감싸지 않고, 그 입력에 따라 바뀌는 무거운 결과 영역만 낮은 우선순위로 미룹니다. 상태 업데이트를 직접 호출하는 위치라면 useTransition 또는 startTransition 을, 이미 전달받은 값의 화면 반영만 늦추고 싶다면 useDeferredValue 를 고려합니다. 동시성 API는 느린 계산을 빠르게 만드는 도구가 아니라, 사용자가 먼저 체감하는 렌더링이 막히지 않도록 우선순위를 나누는 도구입니다. 목차 시간 흐름으로 이해하기 흐름으로 보기 Concurrent Mode라는 표현이 헷갈리는 이유 설정 기준 잡기 데이터 흐름과 상태 소유권 useTransition과 startTransition을 쓰는 위치 useDeferredValue가 어울리는 경우 흔한 안티패턴 현재 기준의 마이그레이션 포인트 시간 흐름으로 이해하기 검색창에 글자를 입력하고 그 결과로 큰 목록이 다시 렌더링되는 상황을 기준으로 보면 React 동시성은 다음 흐름으로 동작합니다. 입력 발생 사용자가 검색어를 입력합니다. → 긴급 업데이트 입력창의 text 상태는 즉시 반영됩니다. → 전환 예약 결과 목록을 바꾸는 query 업데이트는 낮은 우선순위로 표시됩니다. → 렌더링 조정 결과 렌더링 중 새 입력이 들어오면 React가 기존 작업을 중단하거나 최신 값 기준으로 다시 시작할 수 있습니다. → 화면 커밋 렌더링이 완료된 결과만 실제 DOM에 반영됩니다. 여기서 중요한 구분은 입력 상태와 결과 상태를 같은 속도의 일로 보지 않는 것입니다. 사용자는 키를 눌렀을 때 글자가 바로 찍히는지를 먼저 ...

트랜잭션 격리 수준, 동시성과 정합성 사이에서 어떻게 선택할까 빠른 답 트랜잭션 격리 수준은 동시에 실행되는 트랜잭션이 서로의 변경을 어디까지 볼 수 있는지 정하는 설정이다. READ COMMITTED 는 Dirty Read를 막지만, 같은 트랜잭션 안에서 같은 행을 다시 읽었을 때 값이 달라질 수 있다. REPEATABLE READ 와 SERIALIZABLE 은 더 강한 일관성을 제공하지만, DBMS의 MVCC, 락, 인덱스 상태에 따라 성능 영향이 달라진다. 격리 수준은 이름만으로 고르기보다 쿼리 패턴, 트랜잭션 길이, 인덱스, 락 대기 상황을 함께 보고 결정해야 한다. 목차 한눈에 비교 왜 격리 수준은 이름만 외우면 헷갈릴까 선택 기준 매트릭스 세 가지 읽기 이상 현상 예제 테이블과 인덱스 트랜잭션 재현 SQL 실행 계획과 결과 해석 락 대기와 운영 출력 예시 애플리케이션 코드에서의 보완 흔한 오해 한눈에 비교 읽기 기준 READ UNCOMMITTED 는 커밋 전 변경까지 읽을 수 있고, READ COMMITTED 부터는 커밋된 데이터만 읽는다. 반복 조회 READ COMMITTED 에서는 같은 행을 다시 읽을 때 값이 바뀔 수 있고, REPEATABLE READ 는 같은 트랜잭션 안의 반복 읽기를 더 강하게 보장한다. 범위 조회 Phantom Read는 같은 조건으로 다시 조회했을 때 행의 개수나 집합이 달라지는 현상이며, DBMS의 MVCC와 범위 락 구현에 따라 관찰 결과가 달라진다. 동시성 비용 격리 수준이 높아질수록 일관성은 강해질 수 있지만 락 대기, 충돌, 재시도 비용이 늘 수 있다. 선택 기준 단순 조회인지, 결제·재고·계좌처럼 경쟁 상태를 막아야 하는 쓰기인지에 따라 격리 수준과 잠금 전략을 함께 봐야 한다. 왜 격리 수준은 이름만 외우면 헷갈릴까 트랜잭션 격리 수준은 동시에 여러 트랜잭션이 실행될 때 한 트랜잭션이 다른 트랜잭션의 변경을 어떻게 관찰할지 정한다. 낮은 격리 수준은 동시 처리에는 유리할 수 있지만 아직 ...

React render phase와 commit phase, 리렌더링이 DOM에 반영되기까지 빠른 답 render phase는 무엇이 바뀌어야 하는지 계산하는 단계라서 다시 실행되거나 중단될 수 있습니다. commit phase는 계산 결과를 실제 DOM에 반영하는 단계라서 짧고 일관되게 끝나는 것이 중요합니다. DOM 접근, 측정, 외부 부수효과는 render가 아니라 commit 이후 훅에서 처리해야 안전합니다. React 18 이후에는 render가 곧바로 화면 반영으로 이어진다고 보면 동작을 잘못 이해하기 쉽습니다. 목차 한눈에 비교 흐름으로 보기 왜 render phase와 commit phase를 자주 헷갈릴까 상태 변경부터 화면 반영까지 따라가기 실수를 빨리 잡는 설정 render에 둘 코드와 commit 이후에 둘 코드 로그로 보는 실행 순서 React 19.2 기준에서 달라진 설명 흔한 안티패턴과 디버깅 체크포인트 한눈에 비교 render phase : 컴포넌트를 호출해 다음 UI 스냅샷을 계산하는 단계입니다. 같은 입력이면 같은 출력이 나와야 하는 순수 계산이어야 합니다. commit phase : render 결과를 실제 DOM에 반영하는 단계입니다. ref 연결, DOM mutation, effect 실행 준비가 여기서 이어집니다. useLayoutEffect : commit 직후, 브라우저가 그리기 전에 실행됩니다. DOM 크기 측정이나 위치 보정처럼 paint 전에 끝나야 하는 작업에 맞습니다. useEffect : 외부 시스템과 동기화하는 용도입니다. 보통은 paint 뒤에 실행되지만, 사용자 상호작용으로 시작된 업데이트에서는 paint 전에 관찰될 수도 있습니다. 실무 기준으로는 파생값 계산은 render, DOM 측정은 useLayoutEffect , 네트워크·구독·타이머·로그 수집은 useEffect 로 나누면 거의 틀리지 않습니다. 흐름으로 보기 React 공식 문서는 이 과정을 trigger ...