들어가며 [1편]에서 page-flip 코어를 얇게 감싸는 구조로 PoC를 끝내고 정식 구현을 시작했다. 하지만 진짜 시작은 실기기 QA부터였다. 1편에서 칭찬했던 1줄 패치가 그대로 업보가 되어 돌아오는 등, 예측하지 못한 버그 두 방을 제대로 맞았다. 📝 TL

들어가며 🙂 "라이브러리 하나 가져다 붙이면 뚝딱 아닌가?" 처음엔 가볍게 생각했다. 하지만 프로덕션 코드를 건드리기 전에 '진짜 우리 스펙을 견뎌낼 수 있을까?'라는 의문이 꼬리를 물었다. 그렇게 작은 스파이크(Spike) 라우트 하나 파놓고 시작한 PoC.

📝 TL;DR 저장소 품질 스캔 중에 .github/workflows 는 있지만 typecheck·lint 를 실제로 검증하는 잡이 없는 걸 발견했고, CI 를 추가하려고 로컬에서 ESLint 를 먼저 돌려보니 오래 잠복해 있던 위반 3건이 튀어나왔다. 🔍 상세

📝 TL;DR PR이랑 push를 한 워크플로우에 우겨넣으면 커버리지가 이중으로 올라가거나 검증이 빠지는 구멍이 생긴다. 역할별로 두 개로 쪼개고 path filter까지 살짝 얹어주면 머리도 편하고 CI 실행 시간도 줄어든다. 🔍 상세 배경 / 동기 팀 프

CLAUDE.md는 명령어가 아니라 계약서다.

📝 TL;DR structuredClone()은 네이티브 깊은 복사 API다. Date, Map, Set, 순환 참조까지 처리하고, 라이브러리도 필요 없다. JSON.parse(JSON.stringify())의 함정 흔히 겪는 시나리오가 있다. API에서 받아온

📝 TL;DR 타입을 "값이 몇 개 들어가는 상자"로 환산하면 좋은 설계인지 숫자로 판단할 수 있고, 합타입(Discriminated Union)을 먼저 떠올리는 습관이 "불가능한 상태를 아예 못 만들게" 해준다. '뭔가 이상한데 설명이 안 되는' 타입에 대하여 "

모바일 풀스크린, 새로운 정답