코딩하는 곰돌이

들어가며"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 코..

들어가며tsc 한 줄이면 타입스크립트 코드가 자바스크립트로 바뀐다. 그런데 언젠가부터 이 명령어가 점점 느려지기 시작했다. 처음엔 5초, 나중엔 40초 넘게 걸리는 빌드를 보면서 "타입스크립트는 원래 느린 언어인가 보다" 하고 그냥 넘어갔었다.그러다 CI 파이프라인에서 빌드 시간이 병목이 되면서 제대로 파고들 수밖에 없었다. 알고 보니 문제는 언어 자체가 아니라, 타입 체킹과 코드 변환(트랜스파일)을 하나의 프로세스가 전부 떠맡는 기본 설정 때문이었다. 이 글은 그 과정에서 정리한 TypeScript 빌드 파이프라인의 동작 원리와, 빌드를 빠르게 만드는 방법들을 다룬다.1. tsc가 하는 두 가지 일 — 타입 체킹과 트랜스파일tsc를 실행하면 내부적으로는 크게 구분되는 두 가지 작업이 함께 일어난다.소스..

들어가며Promise.race로 API 타임아웃을 구현하는 코드는 여러 번 써봤다. Promise.allSettled로 여러 요청을 동시에 보내고 실패한 것만 골라내는 코드도 익숙하다. 그런데 정작 "이 두 메서드가 내부적으로 어떻게 동작하길래 이런 결과가 나오는가"라는 질문을 받으면 말문이 막혔다.사용법은 아는데 원리는 모르는 상태. 이런 지점을 가장 확실하게 메우는 방법은 직접 구현해보는 것이다. 이 글은 Polyfill이 왜 필요한지부터 시작해서, Promise.race와 Promise.allSettled를 직접 만들어보고, 그 과정에서 왜 특정 최신 스펙 API를 도입하지 못하고 있는 프로젝트들이 여전히 Polyfill에 의존하는지를 정리한 기록이다.1. Polyfill이란 무엇이고, 왜 여전히 ..

들어가며메이저 버전 업그레이드 공지가 뜨면 늘 하는 고민이 있다. "지금 당장 옮겨야 하나, 아니면 좀 더 지켜볼까." React 19도 마찬가지였다. 릴리즈 노트를 처음 훑어봤을 때는 use 훅이나 Actions 같은 개념들이 매력적으로 보였지만, 실제로 우리 프로젝트에 들어왔을 때 어떤 코드가 사라지고 어떤 코드가 새로 생기는지는 직접 옮겨보기 전까진 감이 안 왔다.이 글은 사이드 프로젝트 하나와 팀 프로젝트의 일부 기능을 React 19로 옮기면서 실제로 써본 기능들, 기대와 달랐던 부분, 그리고 마이그레이션 과정에서 부딪힌 문제들을 정리한 기록이다.1. Actions — "로딩 상태 관리 코드"가 사라졌다1-1. 이전에는 이렇게 짰다React 18까지 폼을 제출하는 로직을 짜면, 로딩/에러/성공 ..