국내 개발 블로그 명글 큐레이션 4 — 프론트엔드, 직접 열어 확인한 14편

프레임워크 사용법이 아니라 그 아래를 다루는 글들
언어와 타입 — 프레임워크보다 오래 남는 층
브라우저와 번들 — 코드가 실행되기까지
설계 — 무엇을 상태로 둘 것인가
레이아웃과 가독성 — 화면과 코드 양쪽
- [CSS] 성배 (Holy Grail) 레이아웃 (Flexbox, Grid)
- 우리는 왜 어떤 코드를 읽기 쉽다고 느낄까
이 블로그의 관련 글과 도구
시리즈의 다른 글

프레임워크 사용법이 아니라 그 아래를 다루는 글들

프론트엔드는 도구 교체 주기가 가장 빠른 분야이고, 그래서 사용법 글은 금방 낡습니다. 이 목록은 의도적으로 그 아래층을 다루는 글로 채웠습니다. 언어의 동작, 브라우저의 동작, 설계 판단처럼 도구가 바뀌어도 남는 것들입니다.

선정 방법은 시리즈 전체와 같습니다. 검색으로 후보를 찾은 뒤 글을 직접 열어 확인했고, 그중에서 설명이 구체적이고 재현 가능한 것을 골랐습니다. 이 목록은 편집자의 선택이며 순위가 아닙니다. 조회수나 인기는 측정하지 않았고 측정할 수단도 없습니다.

출처는 개인 블로그를 우선했습니다. 개인 도메인과 GitHub Pages 블로그의 비중이 높은데, 이 분야에서 긴 호흡의 글이 그쪽에 몰려 있기 때문입니다. 우아한테크코스의 Tecoble에서 두 편을 넣었고, 그 둘은 각각 구체적인 개선 기록과 팀 단위 설계 결정이라 개인 글로 대체하기 어려웠습니다.

링크는 2026-08-12에 직접 열어 확인했습니다. 개인 블로그 글은 사라지거나 주소가 바뀔 수 있습니다.

언어와 타입 — 프레임워크보다 오래 남는 층

Closure

블로그 · 작성자: PoiemaWeb (이웅모)
한 줄 요약: 클로저를 실행 컨텍스트 위에서 설명하고, 정보 은닉과 부분 적용과 커링 같은 실제 쓰임까지 이어 갑니다.
이런 사람에게: 클로저를 면접용으로 외웠지만 왜 그렇게 동작하는지는 설명하지 못하는 사람.

클로저 설명 글의 대다수는 카운터 예제에서 끝나는데, 이 글은 그것이 왜 유지되는지를 어휘적 환경으로 설명합니다. 클로저가 언어가 제공하는 기능이라기보다 실행 컨텍스트의 구조에서 나오는 현상이라는 관점이 이 글의 핵심입니다. 그래서 읽고 나면 클로저 하나만이 아니라 스코프 전반이 정리됩니다. 오래된 문서지만 다루는 층이 언어의 기초라 지금도 유효하고, 한국어 자바스크립트 자료 중 참조 문서로 쓰기에 가장 정돈되어 있습니다.

자바스크립트는 왜 프로토타입을 선택했을까

블로그 · 작성자: te-ing.log (velog)
한 줄 요약: 프로토타입 기반 설계를 범주와 의미에 대한 철학적 논의에서 시작해 언어의 동작으로 연결합니다.
이런 사람에게: 프로토타입 체인을 알고는 있는데 왜 하필 이 방식인지 납득이 안 된 사람.

접근이 특이한 글입니다. 클래스와 인스턴스라는 구분이 어디에서 왔는지, 그 구분에 대한 반론이 무엇이었는지를 짚은 뒤 자바스크립트의 선택을 그 맥락에 놓습니다. 이런 종류의 글은 자칫 겉멋으로 끝나기 쉬운데, 후반부에서 호이스팅과 클로저와 스코프 체인이라는 구체적인 동작으로 착지하기 때문에 균형이 잡힙니다. 동의하지 않더라도 언어 설계를 바라보는 각도를 하나 얻게 됩니다. 기술서를 읽다 지쳤을 때 읽기 좋은 종류이기도 합니다.

타입스크립트 타입 정복: Conditional Types

블로그 · 작성자: Front J · JonghwanWon
한 줄 요약: 조건부 타입과 infer 키워드를 제네릭과 엮어 설명하고, 중첩 배열 평탄화 같은 실제 예제로 마무리합니다.
이런 사람에게: 유틸리티 타입을 쓰기만 했고 직접 만들어 본 적은 없는 사람.

조건부 타입은 타입스크립트에서 난이도가 급격히 올라가는 지점이고, 그래서 좋은 한국어 설명이 귀합니다. 이 글은 삼항 연산자와 닮은 문법에서 출발해 infer로 타입을 꺼내 오는 단계까지 계단을 만들어 놓았습니다. 예제가 실제로 쓸 법한 것들이라 개념이 추상적으로 남지 않습니다. 표준 라이브러리의 유틸리티 타입이 어떻게 만들어졌는지를 이해하게 되는 것도 부수적인 소득입니다.

타입 시스템은 왜 증명처럼 동작하는가

블로그 · 작성자: 문동욱 (Evan Moon)
한 줄 요약: 타입 검사가 오류 탐지가 아니라 논리적 증명으로 작동한다는 관점을, 커리-하워드 대응까지 짚어 설명합니다.
이런 사람에게: 타입을 귀찮은 검사기로만 여기다가 최근에 생각이 바뀌기 시작한 사람.

타입이 명제이고 프로그램이 증명이라는 대응은 알고 나면 타입 설계를 보는 눈이 달라집니다. 이 글은 그 대응을 함수와 튜플과 유니온과 제네릭이라는 익숙한 문법에 하나씩 대응시켜서 설명하기 때문에, 이론이 실무 문법과 분리되지 않습니다. 형식 논리와 집합론과 람다 대수를 언급하지만 필요한 만큼만 꺼내 쓰기 때문에 진입 장벽이 높지 않습니다. 불가능한 상태를 타입으로 막는다는 실무 기법이 왜 강력한지도 여기에서 근거를 얻습니다.

브라우저와 번들 — 코드가 실행되기까지

브라우저 렌더링 과정 (리플로우와 리페인트)

블로그 · 작성자: Minjae Kim
한 줄 요약: HTML과 CSS가 파싱되어 렌더 트리가 되는 과정, 그리고 무엇이 리플로우를 부르고 무엇이 리페인트에서 끝나는지를 정리합니다.
이런 사람에게: 애니메이션이 끊기는 이유를 설명해야 하는데 근거를 대지 못하는 사람.

렌더링 파이프라인 설명은 흔하지만 이 글은 최적화 지점까지 이어 갑니다. 어떤 속성을 바꾸면 레이아웃 재계산이 일어나고 어떤 속성은 합성 단계에서 처리되는지를 구분해 주기 때문에, 코드에서 무엇을 바꿔야 하는지가 분명해집니다. 길이가 적당해서 팀 위키에 링크로 걸어 두기 좋고, 신입 온보딩 자료로도 씁니다. 프레임워크와 무관한 층이라 유효 기간이 깁니다.

React 효율 개선을 위한 Fiber Reconciler

블로그 · 작성자: Jason Kang
한 줄 요약: 스택 리컨실러의 한계와 Fiber가 그것을 어떻게 바꿨는지를, 중단 가능한 작업 단위라는 개념 중심으로 설명합니다.
이런 사람에게: React가 렌더링을 미룬다는 말을 들었지만 무엇을 어떻게 미루는지 모르는 사람.

동기적 재귀 렌더링이 왜 문제였는지에서 출발하기 때문에 Fiber의 설계가 필연으로 읽힙니다. 작업을 쪼개고 우선순위를 매기고 중단했다가 재개한다는 세 가지가 어떻게 맞물리는지, 그리고 현재 트리와 작업 중 트리를 이중으로 두는 이유까지 다룹니다. React의 동시성 기능들이 왜 그런 모양인지 이해하려면 이 층을 한 번은 봐야 합니다. 분량이 부담스럽지 않아 시작점으로 적합합니다.

차세대 번들러 비교 및 분석 (feat. webpack, rollup, esbuild, vite)

블로그 · 작성자: bepyan blog · Edward Kim
한 줄 요약: 번들러 네 종을 기능 비교가 아니라 각각이 등장한 이유의 순서로 설명합니다.
이런 사람에게: 번들러를 골라야 하는데 무엇이 어떤 문제를 풀려고 만들어졌는지 모르겠는 사람.

계보로 설명한다는 것이 이 글의 결정적인 장점입니다. 태스크 러너에서 시작해 각 도구가 어떤 불편에 대한 응답으로 나왔는지를 순서대로 보여 주기 때문에, 비교표를 외우지 않아도 판단할 수 있습니다. 도구가 계속 바뀌는 분야에서 이런 구조로 쓴 글은 새 도구가 나와도 그 자리에 끼워 넣어 이해할 수 있게 해 줍니다. 2023년 글이라 최근 도구는 빠져 있지만, 틀 자체는 여전히 씁니다.

useLayoutEffect를 활용한 산발적 마커 렌더링 최적화

블로그 · 작성자: Tecoble (우아한테크코스) · 5기_센트
한 줄 요약: 지도 마커가 뚝뚝 끊겨 그려지던 문제를 훅의 실행 시점 차이로 설명하고 해결합니다.
이런 사람에게: useEffect와 useLayoutEffect의 차이를 알고는 있지만 실제로 갈리는 상황을 본 적 없는 사람.

두 훅의 차이는 문서로 읽으면 추상적인데, 이 글에는 눈에 보이는 증상이 있습니다. 마커가 한꺼번에 그려지지 않고 나뉘어 나타나던 현상이고, 원인은 브라우저가 화면을 그리기 전과 후라는 실행 시점 차이였습니다. 대안으로 검토했던 다른 방법과 그것을 채택하지 않은 이유까지 적어 두어서 판단 과정이 남아 있습니다. 성능 개선 글이 갖춰야 할 형식을 갖춘 글입니다.

설계 — 무엇을 상태로 둘 것인가

프론트엔드에서 대부분의 복잡도는 상태를 잘못 잡는 데서 나옵니다. 이 절의 네 편은 그 지점을 각각 다른 각도에서 다룹니다.

선언적 프로그래밍에 대한 착각과 오해

블로그 · 작성자: 문동욱 (Evan Moon)
한 줄 요약: 특정 문법이나 라이브러리를 쓴다고 선언적이 되는 것이 아니라는 점을, 여러 예제로 반복해서 보여 줍니다.
이런 사람에게: 배열 메서드를 체이닝하면서 선언적으로 짰다고 말해 본 적 있는 사람.

이 글이 겨냥하는 오해가 정확합니다. 반복문을 map으로 바꾸는 것은 문법의 교체이지 사고의 전환이 아니라는 것입니다. 대신 데이터 변환 사이의 논리적 관계를 표현하는 것이 선언적이라는 정의를 세우고, JSX와 유니온 타입과 데이터 파이프라인을 그 정의로 다시 읽습니다. 불가능한 상태를 만들 수 없게 모델링하는 것까지 선언적 사고의 일부로 묶는 대목이 이 글의 도달점입니다. 읽고 나면 자기 코드에서 무엇이 선언적이고 무엇이 아닌지 구분이 생깁니다.

상태에서 관계로: 선언적 오버레이 패턴(Declarative Overlay Pattern)

블로그 · 작성자: 문동욱 (Evan Moon)
한 줄 요약: 모달과 확인창을 여러 개의 상태 변수 대신 값을 돌려주는 함수로 다루는 패턴을 제안합니다.
이런 사람에게: 모달이 하나 늘 때마다 불리언 상태가 두세 개씩 늘어나는 코드를 가진 사람.

앞 글의 원칙을 구체적인 문제에 적용한 사례로 읽으면 좋습니다. 열림 여부와 결과와 로딩 상태를 각각 변수로 두면 유효하지 않은 조합이 생기는데, 그 조합을 애초에 만들 수 없게 만드는 것이 이 패턴의 요지입니다. 브라우저 기본 확인창과 같은 사용 감각을 갖는다는 비유가 이해를 빠르게 합니다. 특정 라이브러리를 예로 들지만 패턴 자체는 도구와 무관하게 옮길 수 있습니다.

동일성은 왜 프로그래밍에서 가장 어려운 문제인가

블로그 · 작성자: 문동욱 (Evan Moon)
한 줄 요약: 참조 동일성과 구조적 동일성과 도메인 식별자가 시스템 경계에서 충돌하며 만드는 버그를 네 가지 사례로 다룹니다.
이런 사람에게: 메모이제이션이 왜 안 먹히는지, 왜 같은 객체가 다르게 취급되는지 설명이 필요했던 사람.

같음이 데이터의 성질이 아니라 개발자가 매번 선언하는 계약이라는 관점이 이 글의 중심입니다. 프론트엔드에서 이 문제는 의존성 배열과 캐시 키와 리스트 키로 매일 나타나기 때문에 남 일이 아닙니다. 여러 언어가 이 구분을 타입 시스템으로 드러내려 한 시도들까지 비교하기 때문에 시야가 넓어집니다. 최근에 쓰인 글이라 예제도 지금 쓰는 도구에 가깝습니다.

공식 팀에서의 에러 헨들링

블로그 · 작성자: Tecoble (우아한테크코스) · 4기_자스민
한 줄 요약: 컴포넌트 곳곳에 흩어지던 에러 처리를 ErrorBoundary와 에러 코드 체계로 모은 과정을 기록합니다.
이런 사람에게: try와 catch가 컴포넌트마다 반복되고 있어서 정리하고 싶은 사람.

에러 처리를 화면을 대체하는 것과 로직을 실행하는 것으로 나눈 설계가 이 글의 핵심입니다. 그 구분 덕분에 컴포넌트가 렌더링에만 집중할 수 있게 되는데, 이런 종류의 경계 설정은 실제로 해 본 사람이 쓴 글에서만 배울 수 있습니다. 비동기 에러를 선언적으로 처리하기 위해 훅을 만든 부분까지 있어서 구현 수준의 참고가 됩니다. 서버 오류와 런타임 오류와 네트워크 오류를 나눈 분류 체계도 그대로 가져다 쓸 만합니다.

레이아웃과 가독성 — 화면과 코드 양쪽

[CSS] 성배 (Holy Grail) 레이아웃 (Flexbox, Grid)

블로그 · 작성자: Engineering Blog by Dale Seo
한 줄 요약: 헤더와 푸터와 사이드바가 있는 고전적 레이아웃을 Grid와 Flexbox 두 방식으로 각각 구현해 비교합니다.
이런 사람에게: CSS 레이아웃을 감으로 맞추다가 매번 다르게 짜게 되는 사람.

같은 결과를 두 가지 방법으로 만들어 비교하는 구성이 이 글을 좋게 만듭니다. Grid 쪽이 왜 간결한지, Flexbox 쪽이 어떤 상황에서 여전히 유효한지가 코드로 대조되기 때문에 선택 기준이 생깁니다. 테이블과 float으로 만들던 시절을 짚고 넘어가는 것도 지금 문법이 무엇을 해결했는지 이해하는 데 도움이 됩니다. 짧고 실용적이라 필요할 때 다시 열어 보게 되는 종류입니다.

우리는 왜 어떤 코드를 읽기 쉽다고 느낄까

블로그 · 작성자: 문동욱 (Evan Moon)
한 줄 요약: 가독성을 취향이 아니라 작업 기억과 청킹이라는 인지 구조로 설명합니다.
이런 사람에게: 코드 리뷰에서 읽기 어렵다는 말을 근거 있게 하고 싶은 사람.

가독성 논쟁이 소모적인 이유는 양쪽 다 근거를 대지 못하기 때문입니다. 이 글은 작업 기억의 용량, 숙련자가 패턴을 덩어리로 인식하는 방식, 시각적 구조가 이해에 미치는 영향 같은 연구를 끌어와 그 근거를 만듭니다. 좋은 코드가 문제 자체의 복잡도만 남기고 나머지 부담을 줄인 코드라는 정의는 리뷰 기준으로 그대로 쓸 수 있습니다. 프론트엔드에 국한된 내용은 아니지만, 컴포넌트 분리 기준을 정할 때 특히 유용해서 이 목록에 넣었습니다.