코딩하는 곰돌이

디바운싱과 쓰로틀링, 같은 문제를 다르게 푸는 두 가지 방법검색창에 글자를 입력할 때마다 API를 호출한다면 어떻게 될까요. scroll 이벤트가 발생할 때마다 레이아웃을 다시 계산한다면요. 브라우저는 이런 이벤트를 초당 수십, 수백 번씩 발생시킬 수 있습니다. 이 모든 이벤트에 성실하게 반응하는 코드는 사용자 경험을 해치고, 서버에는 불필요한 부하를 줍니다.디바운싱과 쓰로틀링은 이 문제를 푸는 대표적인 두 가지 기법입니다. 둘 다 "이벤트 실행 빈도를 줄인다"는 목적은 같지만, 접근 방식이 완전히 다릅니다. 이 차이를 정확히 설명하지 못하면 실무 경험이 있어도 면접에서 애매하게 답하게 되는 경우가 많습니다.1. 문제 상황: 왜 필요한가먼저 이벤트가 얼마나 자주 발생하는지 감을 잡아보겠습니다.window..

Object.create()와 프로토타입지난 글에서 프로토타입 체인의 기본 동작 원리를 살펴봤습니다. 이번에는 한 걸음 더 들어가서, new 없이 프로토타입 상속을 구현하는 Object.create()와, 프로토타입 체인이라는 구조 자체가 만들어내는 보안 취약점인 프로토타입 오염을 다뤄보겠습니다. 둘은 언뜻 관계없어 보이지만, 사실 같은 동전의 양면입니다 — 프로토타입 체인을 "의도적으로 설계"하면 Object.create()가 되고, "의도치 않게 오염"되면 취약점이 됩니다.1. new 없이 상속하기: Object.create()new Person()은 익숙하지만, 사실 프로토타입 상속을 만드는 방법은 하나가 아닙니다. Object.create()는 생성자 함수도, class도 거치지 않고 프로토타입 ..

자바스크립트 프로토타입, 정말 이해하고 계신가요?class 키워드에 익숙해진 요즘, 프로토타입은 "예전에 쓰던 문법" 정도로 여겨지곤 합니다. 하지만 자바스크립트 엔진 내부에서는 지금 이 순간에도 프로토타입 체인이 쉼 없이 동작하고 있습니다. 면접에서 유독 이 주제가 자주 나오는 이유도 여기에 있습니다 — "자바스크립트를 얼마나 깊이 이해하고 있는가"를 가장 효율적으로 확인할 수 있는 질문이기 때문입니다.이 글에서는 프로토타입이 왜 존재하는지부터, 프로토타입 체인이 실제로 어떻게 동작하는지, 그리고 class 문법이 이것을 어떻게 감싸고 있는지까지 순서대로 정리해보겠습니다.1. 프로토타입은 왜 필요했을까자바스크립트에는 원래 클래스가 없었습니다. 대신 객체가 다른 객체를 참조해서 속성과 메서드를 "빌려 쓰..

Redux 비동기 관리 정리(thunk부터 RTK Query까지)Redux의 reducer는 순수 함수여야 합니다. 그런데 API 호출, 타이머, 웹소켓처럼 세상의 대부분은 비동기입니다. 이 근본적인 긴장을 Redux 생태계가 어떻게 풀어왔는지, 그리고 지금 가장 권장되는 방식은 무엇인지 정리합니다.1. 왜 Redux에서 비동기가 특별한 문제인가Redux의 핵심 원칙은 reducer가 순수 함수여야 한다는 것입니다.(state, action) => newState같은 입력에는 항상 같은 출력이 나와야 하고, 부수 효과(side effect)가 없어야 합니다. 하지만 fetch로 서버에 요청을 보내는 행위 자체가 이미 부수 효과입니다. 그래서 Redux는 "비동기 로직은 reducer 바깥, 미들웨어라는 ..

중복 요청 · 트랜지션 취소 · 중복 에러 로깅지금까지 Error Boundary의 기본기, react-error-boundary의 내부 구현, React 19의 Actions·useTransition 패턴을 다뤘습니다. 이론적으로 우아한 패턴도 실제 프로덕션 코드에 넣으면 세 가지 문제에 반드시 부딪힙니다. 중복 요청, 취소되지 않는 트랜지션, 그리고 중복 로깅되는 에러입니다. 하나씩 뜯어보겠습니다.1. 중복 요청 방지: isPending만으로는 부족하다문제 상황useTransition을 쓰면 흔히 disabled={isPending}으로 버튼을 잠그는 패턴을 씁니다.function SubmitButton() { const [isPending, startTransition] = useTransitio..

React 19: useTransition과 Error Boundary가 만나면 생기는 일지난 글들에서 Error Boundary의 기본 개념과 react-error-boundary의 내부 구현을 다뤘습니다. 이번에는 React 19에서 등장한 Actions와 useTransition이 Error Boundary와 결합하면서 만들어진 새로운 에러 핸들링 패턴을 살펴봅니다.1. 기존 방식의 한계: 흩어진 로딩·에러 상태React 18까지, 비동기 작업을 다루는 코드는 대개 이런 모양이었습니다.function ProfileForm() { const [isLoading, setIsLoading] = useState(false); const [error, setError] = useState(null); ..

react-error-boundary 내부는 어떻게 동작할까지난 글에서 React의 Error Boundary 개념과 react-error-boundary 라이브러리의 사용법을 다뤘습니다. 이번에는 한 걸음 더 들어가, 이 라이브러리가 내부적으로 어떤 원리로 동작하는지 직접 구현해보며 파헤쳐 보겠습니다.⚠️ 아래 코드는 실제 라이브러리 소스를 그대로 옮긴 것이 아니라, 핵심 동작 원리를 이해하기 위해 단순화하여 재구성한 예시입니다. 실제 구현은 TypeScript 타입, 엣지 케이스 처리 등이 훨씬 정교합니다.1. 이 라이브러리가 제공하는 것react-error-boundary는 React가 기본으로 제공하지 않는 세 가지를 채워줍니다.바로 쓸 수 있는 ErrorBoundary 컴포넌트 — 매번 클래스를..

React Error Boundary 완벽 가이드"예상치 못한 에러 하나가 앱 전체를 하얀 화면으로 만들어버린 경험, 다들 있으시죠?"1. 왜 Error Boundary가 필요한가React 16 이전에는 렌더링 중 하나의 컴포넌트에서 에러가 발생하면 React의 내부 상태가 손상되어, 이후 렌더링에서 예측 불가능한 결과를 냈습니다. React 16부터는 렌더링 도중 처리되지 않은 에러가 발생하면 컴포넌트 트리 전체를 언마운트하도록 정책이 바뀌었습니다.즉, 아무 처리도 하지 않으면 다음과 같은 일이 벌어집니다.댓글 위젯 하나가 에러를 던짐 ↓React가 컴포넌트 트리 전체를 unmount ↓사용자는 완전히 하얀 화면(White Screen of Death)을 마주함이 문제를 해결하..

들어가며"key 경고 뜨는데 그냥 index 넣어" — 신입 시절 리뷰어에게 가장 자주 들었던 조언 아닌 조언이다. 콘솔에 뜨는 노란 경고를 없애는 게 목적이었으니, key={index}를 넣으면 경고가 사라진다는 사실만으로 충분했다. 그 뒤에 어떤 문제가 숨어있는지는 실제로 버그를 겪고 나서야 알게 됐다.체크리스트 항목을 삭제하는 기능을 만들었는데, 삭제한 항목이 아니라 엉뚱한 항목의 체크 상태가 지워지는 버그였다. 로직을 아무리 봐도 문제가 없어 보였다. 원인은 로직이 아니라 key에 있었다. 이 글은 그때 파고들며 정리한 key의 동작 원리와, 인덱스를 key로 쓰면 왜 문제가 생기는지에 대한 기록이다.1. key는 대체 왜 필요한가1-1. 재조정(Reconciliation)의 기본 전제React는..

들어가며variables.less 파일 하나로 시작했던 프로젝트가 2년쯤 지나자 Less 파일이 80개를 넘어섰다. 새 기능 하나를 추가하려고 스타일을 짜면, 어디선가 이미 비슷한 mixin이 있는지 찾는 데 스타일 작성 시간보다 더 오래 걸리는 지경이 됐다. !important가 파일 곳곳에 40개 넘게 박혀 있었고, 특정 컴포넌트의 배경색을 바꾸려면 어느 파일의 어느 규칙이 이기고 있는지 개발자 도구로 하나하나 추적해야 했다.이 글은 이 프로젝트의 Less 코드베이스를 정리하면서 세운 원칙들, 그리고 그 과정에서 배운 것들을 정리한 기록이다. Less 자체의 문법보다는 "여러 명이 오래 건드리는 스타일 코드를 어떻게 관리 가능한 상태로 유지하는가"에 초점을 맞췄다.1. 문제의 근원 — 왜 Less 코..