한 번에 한 가지만 하는 코드 — 명령형·선언형·함수형 쉽게 이해하기
좋은 코드는 결국 한 번에 한 가지만 한다. 그래야 읽기 쉽고, 고치기도 쉽다. 복잡한 건 아래에 맡긴다는 하나의 원리로, 명령형·선언형·함수형이 프론트엔드에서 어떻게 적용되는지 두 가지 리팩터링으로 풀어본다.
선언형 모달 보일러플레이트를 훅으로 걷어내기 — 추상화와 지역 상태 축소
컴포넌트마다 반복되는 useState + 조건부 렌더 모달 패턴을 useModal 훅으로 추상화하면서, 추상화와 선언적이 어떻게 다른지, 그리고 호출부의 지역 상태가 어떻게 사라지는지 정리했다.
React 배칭은 어떻게 동작하나 — flushSync와 업데이트 큐
state를 변경하면 리렌더링이 언제, 몇 번 일어날까? React의 배칭 동작과 flushSync를 업데이트 큐 관점에서 따라가며 정리한 메모.
공개키·비밀키부터 mTLS까지 — 인증서가 HTTPS에서 동작하는 원리
자물쇠와 열쇠 비유로 공개키·비밀키·대칭키를 정리하고, 일반 HTTPS와 클라이언트 인증서(양방향 인증)가 신원을 증명하는 과정, 그리고 키체인이 이 모든 걸 왜 '인증서'로 묶어 다루는지 짚는다.
useQuery vs useMutation, POST라고 무조건 useMutation은 아니다
조회 API가 POST로 구현됐다고 useMutation을 쓰는 건 오해다. 둘을 가르는 기준은 HTTP 메소드가 아니라 서버 상태의 멱등성이다. 메소드와 본질이 어긋나는 실사례와 Key 관리까지 정리한다.
RAG, 세 단계로 분해하기 — 지식 베이스 생성부터 대답 생성까지
NotebookLM을 쓰다 든 '이게 RAG인가?'라는 의문에서 출발해, RAG를 지식 베이스 생성·활용·대답 생성 세 단계로 분해하고 마지막에 실제 서비스 활용까지 정리한 학습 기록. RAG 개념을 처음 잡는 사람에게.
ContentHeader의 children — 예측 불가능한 Props 네이밍 리뷰
공유 컴포넌트에서 children 대신 역할 기반 이름(rightSide)을 써야 하는 이유를 코드 예시와 함께 살펴본다. 인터페이스만으로 컴포넌트 동작을 예측할 수 있는지 점검하는 관점을 다룬다.
좋은 코드란 무엇일까? ② 너무 많이 들게 할 때
명령형은 끝까지 읽어야 알고, 양방향 흐름은 모든 변경 지점을 머릿속에 들게 한다. 한 번에 들 짐 자체를 줄이는 법.
좋은 코드란 무엇일까? ③ 미래를 점치지 마라
오버엔지니어링은 안 올 미래를 점쳐 기계를 미리 짓는 일이다. 미래를 맞히는 대신, 틀려도 싸게 만드는 법.
좋은 코드란 무엇일까? ① 예측이 깨질 때
이름은 약속이고, 디렉토리 구조도 약속이다. 그 약속이 깨지는 순간 우리는 모든 코드를 의심하게 된다.
코드 판단 가이드 : 불편함에서 시작하기
코드가 불편할 때 딱 두 가지만 물어보면 된다. 그러면 결합도·응집도 같은 키워드는 알아서 따라온다.
`handle`과 `on` — 이름이 드러내는 소유권
`handleClick`과 `onSubmit`을 혼용하는 건 스타일 취향이 아니다. 누가 정의하고 누가 받는지의 방향이 이름에 담겨야 한다.