[{"i":"599","t":"CORS error 원인 찾기","k":["cors","preflight","alb","http","debug"],"c":"2026-09-04","m":"2026-09-29","b":"| 언제 | 왜 |\n| ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Console·Network 에 `CORS error` | preflight 에 [`Access-Control-Allow-Origin`(ACAO)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Access-Control-Allow-Origin) 이 없으면 브라우저는 5xx·404·타임아웃을 전부 CORS 로 뭉갠다 |\n| preflight 가 `server: awselb/2.0` 의 5xx | LB 가 타깃에 닿기 전에 직접 만든 응답이다 — 앱을 안 거쳤으니 CORS 헤더가 붙을 수 없다 |\n\n![정상이면 OPTIONS 가 LB 를 지나 앱에 닿고 앱이 204 와 access-control-allow-origin 을 돌려준다. 장애면 healthy 타깃이 0 이라 LB 가 CORS 헤더 없는 503 을 직접 만들어 돌려주고, 브라우저는 그걸 CORS error 로 표시한다.](/svg/cors_preflight_lb_503.svg)\n\npreflight 의 status 와 `server` 헤더 둘로 가른다.\n\n| preflight | server | ACAO | 갈래 | 원인 |\n| ----------- | ---------- | ---- | ---------- | ---------------------------------------------------------------- |\n| `503` | awselb/2.0 | 없음 | **인프라** | healthy target 0 — 서비스 다운·배포 실패·CrashLoop |\n| `502` | awselb/2.0 | 없음 | **인프라** | 타깃이 끊거나 잘못 응답 — 크래시·OOM·포트 불일치 |\n| `504` | awselb/2.0 | 없음 | **인프라** | LB idle timeout 초과 — 느린 쿼리·외부 연동 지연 |\n| `404` | 앱 | 없음 | **경로** | path 오타, ingress rule 불일치 |\n| `204`·`200` | 앱 | 없음 | **CORS** | CORS 미설정 |\n| `204` | 앱 | 있음 | **CORS** | `access-control-allow-headers` 에 요청 헤더가 빠짐 |\n| `204` | 앱 | `*` | **CORS** | `credentials: 'include'` 와 `*` 는 병용 불가 — 오리진을 명시한다 |\n| `204` | 앱 | 정상 | **정상** | CORS 아님. 본 요청의 본문·인증·에러를 본다 |"},{"i":"594","t":"렌더 흐름에서 규칙이 걸리는 자리","k":["react","ssr","usememo","ref"],"c":"2026-09-02","m":"2026-09-30","b":"![렌더 흐름. 클라이언트: render → commit(DOM 반영·ref 콜백) → useLayoutEffect(페인트 전) → paint → useEffect(페인트 후) → … → 노드 제거(ref cleanup). 서버: render → HTML 문자열, useLayoutEffect 는 실행 안 됨·경고, useEffect 는 실행 안 됨. ① render 중 useMemo: 캐시는 버려질 수 있다, 순수하면 재계산돼도 같은 값, 유지해야 하면 useState(init). ② useLayoutEffect: 페인트 전에 DOM 을 고쳐 flash 를 막는다, 서버엔 이 단계가 없어 경고가 난다, shim 으로 서버에선 useEffect. ③ useEffect: ref.current 가 채워진 뒤라 ownerDocument.defaultView = 노드가 실제로 사는 창. ④ commit 의 ref 콜백이 cleanup 을 반환하고 노드 제거 때 실행된다 → 리스너 수명 = 노드 수명.](/svg/react_render_commit_timeline.svg)\n\n## ① render — 유지돼야 하는 값은 useMemo 가 아니라 state\n\n`useMemo(getRandomColors, [])` 로 만든 값이 HMR 뒤에 바뀐다.\n\n![useMemo(calc, []): 마운트 → 캐시 없음. 캐시 없음 → 렌더·계산 → 캐시 있음(값 v). 캐시 있음 → deps 같음 → 재사용. 캐시 있음 → 캐시 폐기(HMR·첫 마운트 중 suspend·화면 밖) → 캐시 없음. 다시 계산하면 순수는 같은 v 라 드러나지 않고, 랜덤은 다른 v′ 라 값이 바뀐다. useState(init): 마운트·init 1회 → state(값 v). state → 리렌더·HMR → 유지. state → 언마운트 → 끝. 값이 사라지는 길은 언마운트뿐.](/svg/usememo_vs_usestate_lifecycle.svg)\n\n```tsx\nconst resolved = resolveTheme(mode, systemDark) // 순수 파생은 그냥 계산\nconst [colors] = useState(getRandomColors) // 유지가 곧 correctness 면 state\n```\n\n## ② useLayoutEffect — 서버 경고는 shim 으로\n\n![페인트 전에 DOM 을 고쳐야 하나? 아니오 → useEffect. 예 → SSR 도 하나? 아니오 → useLayoutEffect. 예 → useIsoLayoutEffect. useIsoLayoutEffect 는 서버에선 useEffect 가 되어 실행 안 되고 경고도 없으며, 브라우저에선 useLayoutEffect 가 되어 페인트 전에 실행된다.](/svg/layout_effect_ssr_choice.svg)\n\n```ts\nconst useIsoLayoutEffect =\n typeof window !== 'undefined' ? useLayoutEffect : useEffect\n```\n\n## ③ useEffect — 이벤트는 노드가 사는 window 에\n\n`window.open`·포털로 다른 창에 렌더해도 `window.addEventListener` 는 원래 창을 듣는다.\n\n![컴포넌트 코드는 원래 창에서 돌고, window.open·포털로 렌더한 DOM 노드(ref.current)는 새 창에 산다. window.addEventListener → 원래 창의 window 에 붙는다, 노드가 없는 창이다. ref.current.ownerDocument.defaultView → 새 창의 window 에 붙는다, 노드가 사는 창이다.](/svg/listener_owner_window.svg)\n\n```ts\nconst win = ref.current?.ownerDocument.defaultView ?? window\n```\n\n멀티윈도우로 쓰일 수 있는 라이브러리 컴포넌트에만 필요하다.\n\n## ④ ref 콜백 — cleanup 을 반환한다 (React 19)\n\n![컴포넌트가 마운트된 동안 DOM 노드가 A 에서 B 로 교체되고, 마지막에 언마운트된다. useEffect + ref: effect 가 한 번 돌아 ref.current(=A) 에 리스너를 붙인다. A 가 떠난 뒤에도 리스너는 떠난 A 에 남아 언마운트까지 가고, B 에는 리스너가 없다. ref 콜백: ref(A) 가 A 에 붙이고 A 가 떠날 때 cleanup 이 abort() 로 떼며, ref(B) 가 B 에 붙이고 B 가 떠날 때 cleanup 이 뗀다. effect 는 컴포넌트 수명, ref 콜백은 노드 수명을 따른다.](/svg/ref_callback_listener_lifetime.svg)\n\n```tsx\n {\n const ctrl = new AbortController()\n node.addEventListener('scroll', onScroll, { signal: ctrl.signal })\n return () => ctrl.abort()\n }}\n/>\n```"},{"i":"593","t":"Chrome 외부 앱 딥링크 \"항상 열기\" 해제","k":["chrome","deep-link","troubleshooting","macos"],"c":"2026-09-01","m":"2026-09-30","b":"커스텀 스킴(`myapp://`) 다이얼로그에서 \"항상 열기 허용\"을 실수로 체크해 되돌리고 싶을 때. **설정 UI 에는 항목이 없다** — 체크는 프로필의 `Preferences` JSON 에 origin 단위로 저장된다.\n\n```json\n\"protocol_handler\": {\n \"allowed_origin_protocol_pairs\": { \"https://example.com\": { \"myapp\": true } }\n}\n```\n\n![\"항상 열기\"를 체크하면 허용이 origin 단위로 저장된다. chrome://settings/handlers 는 웹 프로토콜 핸들러(mailto: 등)만 다루는 별개 화면이라 여기서는 못 푼다. ① chrome://settings/content/all 에서 사이트 데이터를 삭제한다 → 재시작해 다이얼로그가 다시 뜨면 해제된 것이다. 안 뜨면 ② Chrome 을 백그라운드까지 완전 종료하고 → Preferences 에서 그 origin 의 스킴 항목을 지운 뒤 → 재시작해 다시 확인한다. ② 를 건너뛰고 실행 중에 편집하면 종료 시 메모리 상태로 덮어써 되돌아간다. excluded_schemes 에 true 인 스킴은 반대로 차단 상태이고, 같은 파일에서 푼다.](/svg/chrome_external_protocol_reset.svg)\n\n| OS | 경로 |\n| ------- | ------------------------------------------------------------------- |\n| macOS | `~/Library/Application Support/Google/Chrome//Preferences` |\n| Windows | `%LOCALAPPDATA%\\Google\\Chrome\\User Data\\\\Preferences` |\n| Linux | `~/.config/google-chrome//Preferences` |"},{"i":"582","t":"Next.js SSG + S3 + CloudFront 캐시 정책","k":["aws","cloudfront","nextjs","cache","deploy"],"c":"2026-09-01","m":"2026-09-30","b":"정적 SPA에서 Next.js SSG로 옮길 때 **배포해도 구버전 HTML이 서빙되는** 문제를 헤더 설계로 해결한다. `example.com` 기준.\n\n## 왜 문제가 생기는가\n\nSPA는 HTML이 `index.html` 하나라 진입점만 무효화하면 됐다. SSG는 라우트마다 HTML 오브젝트가 생기고 각자 **독립된 TTL**로 엣지에 캐시된다.\n\n`Cache-Control` 이 없으면 CloudFront는 Default TTL(미설정 시 86400초), 브라우저는 휴리스틱 캐싱(`(Date - Last-Modified) × 10%`)을 적용한다. 그 동안 엣지는 오리진에 가지 않는다 — 로컬에서 재현 안 돼도 문제다.\n\n## 디버깅 — 오리진 → 엣지 → 브라우저 순으로 좁힌다\n\n배포했는데 구버전이 보이면 **어느 층이 구버전을 들고 있는지**부터 가른다. 안쪽부터 본다 — 오리진이 구버전이면 바깥을 볼 이유가 없다.\n\n### 1. 오리진에 새 HTML이 올라갔나\n\n```bash\naws s3api head-object --bucket example.com --key index.html\n```\n\n- `LastModified` 가 배포 시각보다 이전 → 배포가 안 됐다. buildspec 2단계 로그를 본다\n- `CacheControl` 이 없다 → 헤더 미적용. 2단계에서 `Hit` 로 드러난다\n\n### 2. 엣지가 무엇을 내보내나\n\n```bash\ncurl -sI https://example.com/ | grep -iE 'cache-control|x-cache|age'\ncurl -sI https://example.com/a | grep -iE 'cache-control|x-cache|age'\n```\n\n![Miss: 브라우저 → 엣지 → 오리진(S3)까지 가서 새로 받는다. 엣지 캐시가 비어 있었을 뿐 최신이라는 뜻은 아니다. Hit: 브라우저 → 엣지에서 멈추고 오리진에는 가지 않은 채 캐시본을 돌려준다 — 구버전이 서빙되는 지점이다. RefreshHit: 브라우저 → 엣지 → 오리진에 재검증 → 304 → 엣지가 캐시본을 돌려준다 — max-age=0 의 정상 동작이고 HTML 의 목표 상태다. 엣지의 TTL 타이머는 POP·경로별로 독립이라 새 화면과 구 화면이 재현성 없이 섞인다.](/svg/cloudfront_xcache_paths.svg)\n\n- `cache-control` 없음 + `Hit` → 헤더 미적용 → [헤더 레시피](#오브젝트-종류별로-정반대-헤더) + 전환 최초 1회 `/*` 무효화\n- `max-age=0` 인데 `Hit` + `age` 증가 → **Minimum TTL이 오리진 헤더를 무시**. Cache Policy 수정\n- `RefreshHit` · `Miss` → 엣지는 정상. 3으로\n\n약한 ETag(`W/\"...\"`)·`vary: Accept-Encoding`은 엣지 자동 압축 흔적이다. 무시한다.\n\n### 3. 브라우저만 구버전인가\n\n`curl` 은 새 버전인데 브라우저만 구버전 → 헤더 없이 받았던 응답을 휴리스틱으로 들고 있다. **invalidation이 못 닿는다.** 만료를 기다린다. 헤더 적용 이후 배포분부터는 재발하지 않는다.\n\n### 곁증상\n\n| 증상 | 원인 | 처방 |\n| ------------------------ | ---------------------------------------------------- | -------------------------------------------- |\n| 배포 직후 lazy chunk 404 | 1단계에 `--delete`, 또는 HTML이 에셋보다 먼저 올라감 | 순서·`--delete` 위치 |\n| 일부 오브젝트만 403 | 한쪽 sync에 `--acl public-read` 누락 | 두 명령 모두에 |\n| `--acl` 자체가 에러 | 버킷이 `BucketOwnerEnforced` | `--acl` 빼고 OAC + 버킷 정책 |\n| 3단계 AccessDenied | 롤에 `cloudfront:CreateInvalidation` 없음 | [3단계 무효화](#3단계-무효화--어디까지-닿나) |\n\n## 오브젝트 종류별로 정반대 헤더\n\n| 대상 | Cache-Control | 이유 |\n| --------------------- | ----------------------------------- | -------------------------------------------------- |\n| `_next/static/**` | `public,max-age=31536000,immutable` | 파일명에 콘텐츠 해시 — 내용이 바뀌면 이름이 바뀐다 |\n| `*.html`, 데이터 파일 | `public,max-age=0,must-revalidate` | 매 요청 재검증, 안 바뀌었으면 304 |\n\n```yaml\nversion: 0.2\n\nenv:\n variables:\n BUCKET: example.com\n\nphases:\n post_build:\n commands:\n # 1) 해시 에셋: 영구 캐시, 삭제 없음\n - aws s3 sync ./out/_next/static s3://$BUCKET/_next/static\n --acl public-read\n --cache-control 'public,max-age=31536000,immutable'\n\n # 2) HTML·데이터: 매 요청 재검증, 구 HTML 정리\n - aws s3 sync ./out s3://$BUCKET\n --acl public-read\n --exclude '_next/static/*'\n --cache-control 'public,max-age=0,must-revalidate'\n --delete\n\n # 3) 엣지 무효화 (권한 있을 때만 — 아래 참고)\n - export CF_DIST_ID=$(aws cloudfront list-distributions\n --query \"DistributionList.Items[?Aliases.Items[?contains(@, '$BUCKET')]].Id\"\n --output text)\n - test -n \"$CF_DIST_ID\" || (echo \"CF_DIST_ID 조회 실패\" && exit 1)\n - aws cloudfront create-invalidation --distribution-id $CF_DIST_ID --paths '/*'\n```\n\n**순서를 지켜야 한다**\n\n- **에셋(1) → HTML(2).** 단일 sync는 순서를 보장하지 않아, HTML이 먼저 가면 청크가 없는 창이 생긴다. 이 순서면 2가 실패해도 \"새 에셋 + 구 HTML\"로 정상 동작한다.\n- **1단계는 `--delete` 없음.** 구 해시 에셋이 남아야 열려 있던 탭의 lazy chunk 404가 안 난다.\n- **`--acl public-read`는 둘 다에.** 빠지면 그 오브젝트가 403.\n\n### 3단계 무효화 — 어디까지 닿나\n\n![create-invalidation --paths '/*' 는 모든 엣지 POP 의 캐시본을 비운다. 브라우저 캐시(휴리스틱)에는 닿지 않는다. 과금은 경로 단위라 경로 200개를 열거하면 200 paths, /* 는 몇 개를 매칭하든 1 path 이고 월 1,000 path 까지 무료다. 헤더 적용 전에는 Cache-Control 없는 구 HTML 이 엣지에 Default TTL(24시간) 동안 남으므로 전환 최초 1회는 무효화가 필수다. 헤더 적용 후에는 HTML 이 max-age=0 이라 엣지가 매 요청 재검증하므로 무효화는 즉시 반영을 위한 보험일 뿐이다.](/svg/cloudfront_invalidation_reach.svg)\n\n## 확인\n\n```bash\naws s3api head-object --bucket example.com --key index.html\naws s3api head-object --bucket example.com --key '_next/static//...'\ncurl -sI https://example.com/a | grep -iE 'cache-control|x-cache|age'\n```\n\n| 대상 | cache-control | x-cache | age |\n| ----------------- | ----------------------------------- | ------------------------- | --------- |\n| HTML | `public,max-age=0,must-revalidate` | 반복 요청 시 `RefreshHit` | 없거나 0 |\n| `_next/static/**` | `public,max-age=31536000,immutable` | `Hit` | 계속 증가 |\n\nHTML이 `Hit` + `age` 증가일 때만 Minimum TTL을 본다."},{"i":"580","t":"MySQL TIME × 언어 타입 폭 불일치","k":["mysql","java","mybatis","typeorm","type-design","error-handling"],"c":"2026-08-31","m":"2026-09-30","b":"운영시간 목록 API가 통째로 500이고, 프론트는 그걸 \"선택 가능한 날짜가 없는 정상 달력\"으로 그린다. 원인은 `operation_hours`의 `to = 24:00:00` 행 하나였다.\n\n![1 원인 행 찾기 → 2 값 감사 → 4 정규화 결정 → 데이터 핫픽스 → 5 TypeHandler → 6 쓰기 제약 순으로 백엔드를 고친다. 4 를 고르기 전에 3 정의역 확인을 본다. 5 → 6 은 읽기가 먼저다 — 쓰기부터 막으면 이미 들어 있는 행 때문에 여전히 500 이다. 7 결핍 상태 분리 렌더는 프론트에서 백엔드와 별개로 지금 바로 할 수 있다. 8 타입 폭 감사 → 스키마 재설계 검토는 예방이다.](/svg/mysql_time_recipe_order.svg)\n\n## 1. 스택트레이스 최하단\n\n```\nDateTimeException: Invalid value for HourOfDay (valid values 0 - 23): 24\n at java.time.LocalTime.of\n at com.mysql.cj.result.LocalTimeValueFactory...\n```\n\n`ValueFactory`·`TypeHandler`·`ResultSetImpl` 프레임의 `DateTimeException`이면 매핑 실패다. `24`·`HourOfDay`가 원인 행의 값 → 2의 조건. 로그에 cause 체인이 없으면 2부터 돌려 역으로 좁힌다.\n\n## 2. 도메인 밖 값 감사 — 핫픽스 전에\n\n```sql\nSELECT owner_id, slot_type, `from`, `to`\nFROM operation_hours\nWHERE TIME_TO_SEC(`from`) >= 86400 -- 24시 이상\n OR TIME_TO_SEC(`to`) >= 86400\n OR TIME_TO_SEC(`from`) < 0 -- MySQL TIME은 음수 허용\n OR `from` > `to`; -- 익일 걸침 (별개 문제)\n```\n\n문자열 비교는 `'9:00:00'` 같은 비제로패딩에서 틀리니 `TIME_TO_SEC`. `from > to`(야간 걸침)는 다른 요구라 따로 세서 별건으로 뺀다.\n\n## 3. 정의역 대조 — 데이터가 더러운가, 타입이 좁은가\n\nMySQL `TIME`은 `-838:59:59 ~ 838:59:59`인 duration 타입이라 `24:00:00`은 합법값이다.\n\n| 언어/타입 | 정의역 | TIME 전 범위 |\n| ---------------------- | ---------------------------- | ------------- |\n| Java `LocalTime` | `00:00 ~ 23:59:59.999999999` | ✗ |\n| Java `Duration` | 사실상 무제한 | ✓ |\n| TS `string` | 제약 없음 | ✓ (검증 없음) |\n| Python `datetime.time` | `00:00 ~ 23:59:59.999999` | ✗ |\n| Go `time.Duration` | ±292년 | ✓ |\n\n![기준선은 MySQL TIME 컬럼의 정의역 -838:59:59 ~ 838:59:59 다. 쓰는 쪽 string·Duration 은 이 범위를 전부 덮는다. 읽는 쪽 LocalTime·datetime.time 은 00:00 ~ 24:00 미만만 덮어서, 그 바깥 구간은 컬럼에 들어갈 수 있는데 읽으면 예외가 난다. 24:00:00 과 -01:00:00 이 그 구간에 있다 — 컬럼 안, LocalTime 밖. 넓은 쓰기 / 좁은 읽기면 시한폭탄이고 반대 방향이면 안전하다. 눈금은 비례가 아니다.](/svg/mysql_time_domain_width.svg)\n\n읽는 쪽 `LocalTime`이 좁은 것이다. 정타입 매핑은 `Duration`(Connector/J 8 `rs.getObject(col, Duration.class)`). `zeroDateTimeBehavior`는 DATE/DATETIME 전용이라 우회가 안 된다.\n\n## 4. 정규화 후보를 슬롯 계산에 넣어 본다\n\n`UPDATE` 전에 **두 서비스의** 슬롯 계산을 읽고 후보를 넣어 본다.\n\n| 후보 | 결과 | 확인할 것 |\n| ------------------- | ---------------------------------------- | ------------------------------------------------------- |\n| `23:59:59` | 1초 손실. 무해한 편 | 슬롯 생성이 `to`를 exclusive로 쓰면 23:30 슬롯이 사라짐 |\n| `00:00:00` | `from > to`가 되어 범위 비교 전부 뒤집힘 | 익일 처리 분기 없으면 **조용히 영업시간 0분** |\n| `Duration`으로 승격 | 손실 없음 | 하위 계산 로직 전부 수정 |\n\n![지금: to = 24:00:00 이라 영업 구간이 from 부터 24:00 까지이고 마지막 슬롯 23:30~24:00 이 있지만 LocalTime 이 못 읽는다. 23:59:59 로 바꾸면 1초가 줄어, 슬롯 생성이 to 를 exclusive 로 쓰면 23:30 슬롯이 들어가지 못한다. 00:00:00 으로 바꾸면 to 가 from 보다 앞이 되어 범위 비교가 전부 뒤집히고, 익일 분기가 없으면 예외 없이 영업시간 0분이 된다. Duration 으로 승격하면 손실 없이 24:00 까지 그대로지만 하위 계산 로직을 전부 고쳐야 한다. 눈금은 비례가 아니다.](/svg/mysql_time_normalize_choices.svg)\n\n`00:00:00`은 예외가 안 나서 지금보다 나쁘다 — 터지는 버그가 침묵하는 버그가 된다.\n\n## 5. 읽기 방어 — TypeHandler\n\n```java\n@MappedTypes(LocalTime.class)\npublic class SafeLocalTimeTypeHandler extends BaseTypeHandler {\n @Override\n public LocalTime getNullableResult(ResultSet rs, String col) throws SQLException {\n String raw = rs.getString(col);\n if (raw == null) return null;\n Duration d = parseMysqlTime(raw);\n return d.compareTo(Duration.ofDays(1)) >= 0\n ? LocalTime.MAX.truncatedTo(ChronoUnit.SECONDS) // 23:59:59\n : LocalTime.ofSecondOfDay(d.getSeconds());\n }\n // ...\n}\n```\n\n## 6. 쓰기 제약 — 읽기 다음에\n\n쓰기부터 막으면 이미 들어 있는 행 때문에 여전히 500이다. 2를 다시 돌려 0건인지 보고 건다.\n\n```sql\nALTER TABLE operation_hours\n ADD CONSTRAINT chk_operation_hours_range\n CHECK (TIME_TO_SEC(`to`) <= 86340 AND TIME_TO_SEC(`from`) >= 0);\n```\n\nMySQL 8.0.16+. DDL이 성공하면 위반 행이 없다는 확인이기도 하다. 낮은 버전의 TypeORM validator는 배치·수동 SQL로 뚫린다.\n\n## 7. 프론트 — 별개 티켓\n\n`useQuery` 에러 → `hours = undefined` → 모든 날짜 `null` → 달력 통째로 비활성. `isPending` / `isError` / 빈 배열을 따로 그리고 실패엔 재시도 UI. 빈 배열은 \"휴무\", 못 가져옴은 \"다시 시도\"다.\n\n## 8. 예방 — 같은 폭탄 찾기\n\n공유 테이블의 컬럼마다 스택별 매핑 타입을 **DB 도메인 위에 겹친다**(3의 그림). 스키마 파일끼리 비교하면 양쪽 다 `time`이라 안 잡힌다. 넓은 쓰기 / 좁은 읽기가 시한폭탄이다.\n\n| 컬럼 타입 | 넓은 쪽 | 좁은 쪽 |\n| --------------------- | ------------------ | -------------------------- |\n| `TIME` | string, Duration | LocalTime, `datetime.time` |\n| `DECIMAL(20,0)` | BigDecimal, string | JS `number` (2^53) |\n| `BIGINT` | int64 | JS `number` |\n| `VARCHAR` (utf8mb4) | string | 이모지 미대응 정규식 검증 |\n| `DATE` (`0000-00-00`) | string | `LocalDate` |\n\n## 장기 · 미해결\n\n- `TIME` 대신 자정 기준 분 `SMALLINT`(0~1440): `24:00 = 1440`, 양 언어 모두 정수라 폭이 같고, `CHECK (col BETWEEN 0 AND 1440)`. 별건 티켓.\n- `24:00:00`이 어디서 들어왔나 — 어드민 UI면 validator로 충분, 배치면 DB 제약 필수.\n- 휴무 행의 `from`/`to`를 애초에 읽어야 하나 — 안 읽어도 되면 5보다 싸다."},{"i":"578","t":"useMemo 캐시 적중 진단 — 매 렌더 새로 만들어지는 deps","k":["react","usememo"],"c":"2026-06-23","m":"2026-09-30","b":"import AutoIframe from '@components/AutoIframe/AutoIframe.astro'\n\n무거운 계산을 `useMemo`로 감쌌는데 렌더 시간이 줄지 않는다. 각 단계는 질문 하나에 답하고, 그 답이 다음 질문을 만든다. 단계마다 **추론이 아니라 관찰로** 넘어간다.\n\n![1 렌더가 느린가(Profiler ms) → 2 재사용되나(calc 횟수) → 3 왜 다시 계산하나(Object.is 로 참조 비교) → 4 누가 새 참조를 만드나(부모로 거슬러 올라가 useMemo) → 5 고쳐졌나(같은 조작으로 횟수와 ms 비교). 1 에서 병목이 아니면 멈춘다. 5 에서 둘 다 줄었으면 해결이고, 횟수는 줄었는데 ms 가 그대로면 병목이 다른 곳이라 1 로 돌아간다. 6 값이 틀리다면 느린 게 아니라 별개 축이다 — stale closure 는 exhaustive-deps 로, 비결정 계산은 두 번 호출 결과 비교나 HMR 로 확인한다.](/svg/usememo_debug_flow.svg)\n\n## 1. 정말 이 계산이 느린가\n\nReact DevTools **Profiler**로 조작 하나를 녹화하고, flamegraph에서 그 컴포넌트의 렌더 시간(ms)을 본다. 여기서 이 컴포넌트가 병목이 아니면 `useMemo`를 볼 이유가 없다. 이 숫자는 5에서 수정 전후를 비교할 기준선이 된다.\n\n## 2. 정말 재사용되고 있나\n\n계산 함수 안에 카운터를 넣고 리렌더를 몇 번 일으킨다.\n\n```jsx\nconst rows = useMemo(() => {\n console.count('calc')\n return items.filter(fn)\n}, [items])\n```\n\n`calc`가 렌더와 **같이** 늘어나면 한 번도 재사용되지 않고 있다. 개발 모드에서는 React가 계산 함수를 **일부러 두 번 부르므로**[^react-usememo] 렌더당 2씩 뛰는 게 정상이다 — 보는 건 절대값이 아니라 렌더를 따라 늘어나는지다.\n\n**CDP로 읽을 때.** `Runtime.enable` 뒤 `Runtime.consoleAPICalled`가 `type: \"count\"`로 온다. 숫자는 따로 오지 않고 `args[0].value`에 `\"calc: 3\"` 같은 문자열 하나로 오므로 `/: (\\d+)$/`로 꺼낸다. `console.countReset`은 이벤트를 내지 않는다. `Runtime.enable` 전에 찍힌 메시지도 enable 시점에 다시 보내준다.[^cdp-observed]\n\n**코드를 고치지 않고 셀 때.** 앱에 로그를 심을 수 없으면 V8 커버리지의 호출 횟수를 쓴다.\n\n```js\nawait send('Profiler.enable')\nawait send('Profiler.startPreciseCoverage', { callCount: true, detailed: true })\n// 리렌더 한 번 일으키고\nconst { result } = await send('Profiler.takePreciseCoverage')\n// result[].functions[].ranges[0].count = 그 사이 호출 횟수\n```\n\n`takePreciseCoverage`는 부를 때마다 카운터를 0으로 되돌린다.[^cdp-observed] 리렌더마다 한 번씩 부르면 그 렌더 동안의 호출 횟수가 바로 나온다. 다만 `useMemo(() => …)`의 화살표 함수는 `functionName`이 비어 있어 스크립트 `url`과 `ranges` 오프셋으로 찾아야 하고(번들이면 소스맵으로 되짚는다), 개발 모드의 두 번 호출도 그대로 세어진다.\n\n## 3. 왜 매번 다시 계산하나\n\n계산 쪽이 아니라 `deps`를 의심한다. React는 재료 **안을 들여다보지 않고** `Object.is`로 *같은 물건인지*만 본다.[^react-usememo] 매 렌더 새로 만들어지는 값이 `deps`에 있으면 내용이 같아도 매번 \"다른 재료\"다.\n\n의심만 하지 말고 참조가 실제로 바뀌는지 찍는다.\n\n```jsx\nconst prev = useRef(items)\nuseEffect(() => {\n console.log('items same?', Object.is(prev.current, items))\n prev.current = items\n})\n```\n\n매 렌더 `false`면 확정이다. Profiler 설정의 \"Record why each component rendered while profiling\"을 켜면 코드 없이 `Props changed: items`로도 보인다.\n\n## 4. 누가 새 참조를 만드나\n\n같은 비교를 부모 쪽에 두고 거슬러 올라간다. 렌더 중에 새 배열을 만들어 넘기고 있었다.\n\n```jsx\n\n```\n\n넘기는 쪽에서 참조를 붙잡아 둔다.\n\n```jsx\nconst items = useMemo(() => data.map(transform), [data])\n```\n\n\n\n[^react-usememo]: _\"React will compare each dependency with its previous value using the `Object.is` comparison.\"_ / _\"React will not throw away the cached value unless there is a specific reason to do that … This should be fine if you rely on `useMemo` solely as a performance optimization.\"_ / _\"In Strict Mode, React will call your calculation function twice in order to help you find accidental impurities.\"_ ([useMemo — React](https://react.dev/reference/react/useMemo))\n\n[^cdp-observed]: Chrome 154 headless 에서 원시 CDP 로 실측 (2026-09-30). `console.count('calc')` 세 번 → `\"calc: 1\"`·`\"calc: 2\"`·`\"calc: 3\"`, `countReset` 뒤 다시 `\"calc: 1\"`. 커버리지는 3회 호출 뒤 `take` → 3, 2회 더 호출 뒤 `take` → 2."},{"i":"576","t":"dayjs 날짜 표기 카탈로그","k":["typescript","dayjs","date-format","type-safety"],"c":"2026-06-28","m":"2026-10-01","b":"## 1. 문제 — 날짜 표기를 한곳으로 모으고 싶다\n\n화면마다 `dayjs().format('…')`이 흩어져 같은 날짜가 다르게 찍힌다. 날짜 표기를 받는 인자를 타입으로 닫아 허용된 표기만 쓰게 하고 싶다.\n\n## 2. 첫 발상 — 매핑 객체\n\n표기 이름과 포맷 문자열을 짝짓는 객체(`{ DATE: 'YYYY-MM-DD', … }`)부터 떠올랐다. i18n 습관이다 — i18n은 이름표(`인사`)와 내용(`Hello`)이 달라서 짝지어 주는 객체가 필수였다.\n\n그런데 dayjs는 **포맷 문자열이 곧 키이자 값이다.**[^dayjs-format] 이름을 따로 붙이면 같은 정보를 두 번 들고 있게 된다. 매핑 객체는 필요 없다.\n\n## 3. 해결 — 배열 하나에서 파생\n\n허용 표기를 `as const` 배열 하나에 두고, 타입과 진입점을 거기서 파생한다.\n\n```ts\nimport dayjs from 'dayjs'\n\nexport const DATE_FORMATS = [\n 'YYYY-MM-DD',\n 'YYYY-MM-DDTHH:mm:ss',\n 'HH:mm',\n 'YYYY년 M월',\n 'YY년 M월 D일',\n 'YYYY.MM.DD',\n 'YY.MM.DD',\n 'YYYY.MM.DD(ddd)',\n 'YYYY.MM.DD HH:mm',\n] as const\n\nexport type DateFormat = (typeof DATE_FORMATS)[number]\n\nexport const formatDate = (\n date: dayjs.ConfigType,\n format: DateFormat,\n): string => dayjs(date).format(format)\n```\n\n- `DATE_FORMATS` — 허용 표기의 단일 출처\n- `DateFormat` — 배열에서 파생된 닫힌 union. 따로 손댈 곳이 없다\n- `formatDate` — 유일한 진입점\n\n## 4. 새 표기가 필요해지면\n\n1. **여러 곳에서 통일이 필요한 표기인지** 먼저 본다. 일회성(`'M.D'` 등)이면 raw `dayjs().format()`으로 둔다 — 이 기준이 없으면 배열이 잡동사니 enum이 된다.\n2. `DATE_FORMATS`에 추가한다. 그게 전부다.\n3. `ddd`가 들어 있으면 진입점에 `dayjs.locale('ko')`가 있는지 본다.[^dayjs-i18n]\n\n## 5. 남은 구멍\n\n- **raw 우회는 타입이 못 막는다.** 카탈로그에 있는 표기를 `formatDate` 없이 raw로 다시 써도 오류가 없다. [no-raw-date-format](/rules/no-raw-date-format.md)(`no-restricted-syntax`)이 필요한데 아직 안 썼다. 그 규칙 전까지 단일 출처는 관행일 뿐이다.\n- **`ddd`는 조용히 샌다.** `dayjs.locale('ko')` 없이 쓰면 `Mon`·`Tue`처럼 영어로 나오고, 예외도 타입 오류도 없다. `YYYY.MM.DD(ddd)`만 런타임 전제를 가진 항목이다.\n\n---\n\n[^dayjs-format]: [dayjs — Format](https://day.js.org/docs/en/display/format)\n\n[^dayjs-i18n]: [dayjs — Loading locale](https://day.js.org/docs/en/i18n/loading-into-nodejs)"},{"i":"575","k":["react","suspense","declarative"],"c":"2026-06-23","m":"2026-09-30","b":"Suspense는 **비동기를 동기처럼 보이게** 만든다. 데이터가 아직 없으면 promise를 던지고, React가 그걸 받아 기다렸다가 다시 그린다. 그래서 상태를 조율하는 대신 **입력을 미루고 → 질의하고 → 그리는** 순서로 끝난다.\n\n**언제**: 비동기 데이터를 그리는데 로딩·에러가 늘면서 화면이 튈 때. 또는 새로 만들면서 어느 쪽으로 갈지 고를 때.\n\n![각각 들고 있으면: loading 과 error 가 따로 켜지고 꺼져 네 칸이 생긴다 — 둘 다 꺼짐은 성공, error 만 켜짐은 에러, loading 만 켜짐은 로딩, 둘 다 켜짐은 있을 수 없는 \"로딩 + 에러\"인데도 적을 수 있다. 그 칸이 한 프레임이라도 그려지면 화면이 튄다. 트리로 옮기면: 로딩(Suspense) → resolve → 성공(본문), 로딩 → reject → 에러(ErrorBoundary), 성공 → 입력 변경으로 promise 를 던지면 → 로딩. 상태는 셋 중 하나라 넷째 칸을 적을 수가 없다.](/svg/suspense_state_collapse.svg)\n\n**절차**\n\n1. 검색어·결과·로딩 중인지·에러인지를 **각각** 들고 있는지 본다.\n2. 분기를 `if/else`에서 **트리로 옮긴다** — 로딩은 ``, 에러는 ``, 성공은 본문.\n3. 본문에 loading·error를 인자로 넘기지 않는다. 안 넘겨도 **가장 가까운 경계가 대신 잡기** 때문이다 — `render`는 결과 하나만 받는다.\n\n**확인**: 있을 수 없는 조합을 적을 수 있는가. 적을 수 **없으면** 된 것이다.\n\n**함정**: 스피너가 너무 빨리 뜨고 사라지는 건 이 축으로 안 고쳐진다 — 다른 축이다 → [573](/memo/573)\n\n---\n\n곁가지 — 인자를 위로 들어올려 바깥이 처리하게 하는 이 모양은 대수적 효과(algebraic effects)의 handler와 같다.[^algebraic-effects]\n\n[^algebraic-effects]: `try/catch`와 비슷하다 — 중간 함수들은 몰라도 되고 가장 가까운 handler가 받는다. 다른 점은 **처리하고 끝나지 않는다**는 것이다. handler가 값을 돌려주면 효과를 일으킨 자리로 되돌아가 실행이 이어진다. ([Algebraic Effects for the Rest of Us](https://overreacted.io/algebraic-effects-for-the-rest-of-us/))\n\nstale-while-revalidate(두 시계·isStale) 부분은 [570](/memo/570)으로."},{"i":"573","t":"로딩 스피너 깜빡임의 두 끝 — 앞쪽은 CSS, 뒤쪽은 JS","k":["react","css","loading-ux"],"c":"2026-06-23","m":"2026-09-30","b":"import AutoIframe from '@components/AutoIframe/AutoIframe.astro'\n\n스피너가 한 프레임 번쩍하고 사라지거나, 떴다가 하드컷으로 끊긴다. 깜빡임은 **양 끝에서 따로 생기는데** CSS는 한쪽만 잡는다. 어느 끝인지는 응답 시각을 붙잡고 **보인 시간**을 재서 가른다 — DOM에 붙어 있던 시간이 아니다.\n\n![요청 뒤 CSS 지연이 지나야 스피너가 뜬다. 앞쪽: 응답이 지연보다 먼저 오면 스피너는 한 프레임도 안 뜬다 — 지연이 통째로 건너뛰게 한다. 뒤쪽, CSS 만: 지연 뒤에 뜬 스피너가 곧바로 온 응답에 끊겨 짧게 번쩍하고 하드컷된다. 뒤쪽, useMinimumLoading: 응답이 와도 unmount 를 밀어 최소 노출 시간만큼은 보이게 한다. CSS 는 시작(지연)만 정하고, 끝은 응답 시각이 정하는데 CSS 는 그 값을 모른다.](/svg/spinner_flicker_two_ends.svg)\n\n## 흐름\n\n![Claude Code 의 node 스크립트가 Chrome(CDP)에 Fetch.enable 로 */api 를 가로채게 하고, 경계값을 볼 때는 Tracing.start 로 스크린샷도 켠다. hold 를 100·350·700 으로 바꿔 가며 반복한다: 프로브 evaluate 를 기다리지 않고 보낸 뒤 console.timeStamp 와 클릭을 보낸다. 페이지에 스피너가 붙고 fetch /api 가 나가면 Chrome 이 Fetch.requestPaused 를 보내고, 스크립트는 holdMs 를 기다린 뒤 Fetch.continueRequest 로 놓아준다. 요청이 서버에 가고 응답이 오면 스피너가 제거되고 프로브가 firstVisibleAt·visibleFrames·visibleMs 를 JSON 으로 돌려준다. 끝나면 Tracing.end 로 Screenshot 이벤트를 받는다 — 처음 물든 장부터 다음 흰 장까지가 실제로 보인 시간이고, 프로브는 1프레임쯤 더 센다.](/svg/cdp_spinner_measure_sequence.svg)\n\n1. headless Chrome + Node 전역 `WebSocket`으로 raw CDP. MCP `emulate`는 프리셋 스로틀링뿐이라 요청 하나를 못 붙잡는다.\n2. 프로브 — 스피너가 사라질 때 보인 시간을 돌려준다.\n3. 경계값이면 `disabled-by-default-devtools.screenshot` trace로 확인한다. 스크린샷은 바뀐 프레임에만 찍히니 처음 물든 장 → 다음 흰 장이 보인 시간이다.\n4. 응답 < 지연인데 보였으면 앞쪽, 응답 > 지연인데 최소 노출보다 짧으면 뒤쪽.\n\n| 지연 | 응답 | 최소 노출 | 프로브 | trace | 판정 |\n| ---- | ---- | --------- | --------------- | ----------------------------- | -------------- |\n| 0 | 100 | — | 9프레임 · 133ms | | **앞쪽** |\n| 300 | 100 | — | 0 | 물든 장 없음 | 앞쪽 억제됨 |\n| 300 | 350 | — | 4프레임 · 66ms | 약 48ms, 불투명도 최대 약 0.8 | **뒤쪽** |\n| 300 | 350 | 500 | 515ms | | 뒤쪽 잡힘 |\n| 300 | 100 | 500 | 0 | | 앞쪽 억제 유지 |\n\n실측 조건은 각주에 있다.[^spinner-observed] 셋째 줄이 뒤쪽 깜빡임의 실제 모습이다 — 페이드가 끝나기 전에 끊겨 **한 번도 제대로 진해지지 못하고** 사라진다.\n\n## 처방\n\n- **앞쪽** — `animation-delay`/`transition-delay`. 응답이 지연보다 빠르면 스피너를 통째로 건너뛴다. `@starting-style` 단독(지연 0)으로는 못 막는다.\n- **뒤쪽** — CSS는 시작만 통제하고 끝은 CSS가 모르는 응답 시각이 정하니, 사라지는 시각을 JS에서 민다(`useMinimumLoading`). 최소 노출은 **처음 보인 시각부터** 잰다: 사라지는 시각 = `max(응답 시각, firstVisibleAt + 최소 노출)`. 요청 시점부터 재면 표 마지막 줄에서 안 떠도 될 스피너를 붙잡는다.\n\n## 밟은 것\n\n- `spawn`한 프로세스만 죽이면 Chrome 자식이 남아 다음 실행이 옛 페이지에 붙는다 → `detached: true` + `process.kill(-pid)`.\n- 옛 페이지에 붙은 채 `Runtime.enable`하면 이전 console 메시지가 다시 온다.\n- 포트가 뜨기 전 `/json`은 `ECONNREFUSED` → 폴링.\n- 첫 측정은 느리다(hold 100에 응답 149ms) → 첫 줄은 다시 잰다.\n\n\n\n곁가지 — `@starting-style`은 **같은 뿌리의 반대편**이다. transition은 두 상태 사이를 보간하는데, 진입에는 옮겨갈 이전 상태가 없고[^starting-style] 퇴장에는 요소 자체가 이미 사라진다. `@starting-style`은 앞쪽의 출발값을 대신 정해주고(진입 fade-in), `useMinimumLoading`은 뒤쪽의 unmount를 미룬다. 뿌리는 같아도 **손대는 지점이 달라 별개 결정**이다.\n\n[^starting-style]: CSS transition은 요소의 첫 스타일 적용이나 `display: none` → 표시 전환에서는 기본적으로 발동하지 않는다. `@starting-style`이 \"무엇에서 출발할지\"를 정의해 그걸 가능하게 한다. ([@starting-style — MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/@starting-style))\n\n[^spinner-observed]: Chrome 154 headless 에서 raw CDP 로 실측 (2026-09-30). `/api` 요청을 `Fetch.requestPaused` 로 100·350ms 붙잡고, 스피너(`animation: fade 100ms <지연> both`)의 `opacity` 를 매 `requestAnimationFrame` 마다 읽었다. 프로브를 먼저 걸고 버튼 클릭으로 스피너를 띄운 실행에서도 hold 100 → 0프레임, hold 350 → 2프레임(34ms)으로 같았다. 프로브 대 trace 비교는 스피너를 400px 빨간 상자로 두고 `Tracing` 의 `Screenshot` 이벤트를 받아, JPEG 를 `sips` 로 BMP 로 바꿔 상자 안 한 점의 픽셀을 읽었다 — hold 350 에서 `(255,199,200)` → `(255,109,110)` → `(255,51,52)` → 흰색."},{"i":"572","t":"요청 취소의 경계","k":["http","abort","cancellation"],"c":"2026-06-23","m":"2026-10-01","b":"import AutoIframe from '@components/AutoIframe/AutoIframe.astro'\n\n**HTTP 요청 취소는 클라이언트에서만 일어난다.**[^fetch-abort] 이미 보낸 바이트를 회수하지도, 서버가 하고 있는 일을 멈추지도 못한다. **취소한 순간에 요청 전송이 이미 끝나 있었나.** 끝나 있었다면 서버는 그걸 받았고, 받았으면 처리한다. 취소는 그 처리를 못 막는다.\n\n| 구간 | 어디 | 여기서 취소하면 |\n| ------------ | --------------------- | ----------------------------------------------------------- |\n| `send` | 클라이언트 | 요청이 다 전송되지 않는다 — 헤더·본문 일부는 도착할 수 있다 |\n| `in-flight` | 네트워크 | 이미 다 보냈다. 서버는 받는다 |\n| `processing` | 서버 | 서버가 처리 중이고 멈출 방법이 없다 |\n| `resp` | 네트워크 → 클라이언트 | 응답이 오는 중이다. 클라이언트가 안 읽을 뿐 |\n\n구간 사이 경계는 셋인데 **결과를 가르는 건 첫 번째 하나**다 — `send`와 `in-flight` 사이, 전송이 끝나는 순간. 그 뒤로는 어디서 취소하든 서버 입장에선 똑같다.\n\n![요청은 send(클라이언트) → in-flight(네트워크) → processing(서버) → resp(응답) 네 구간을 지난다. 결과를 가르는 경계는 send 가 끝나는 순간 하나다. 빠른 네트워크에서 전송이 끝난 뒤 abort 하면 promise 는 reject 되지만 서버는 요청을 받아 처리하고, 클라이언트는 응답을 안 읽을 뿐이다. 같은 시각에 abort 해도 네트워크가 느려 전송이 그 시각을 넘겨 끝나면 전송이 끊겨 서버는 요청을 다 받지 못한다(헤더·본문 일부는 도착할 수 있다). 서버가 처리 중일 때 abort 해도 서버 입장에선 전송 뒤 abort 와 같다 — reject 이면서 서버는 처리한다.](/svg/request_abort_boundary.svg)\n\n**클라이언트에서는 네 경우가 똑같이 보인다** — promise는 `AbortError`, CDP는 `Network.loadingFailed`(`canceled: true`, `net::ERR_ABORTED`). 응답 전에 끊기면 `responseReceived`도 안 와서 `timing.sendEnd`조차 없다. \"서버가 받았나\"의 정답은 **서버 로그에만** 있고, CDP는 취소를 원하는 구간에 정확히 일으키는 데 쓴다.[^abort-observed]\n\n| 구간 | CDP로 일으키기 | 서버 로그 |\n| ------------ | ------------------------------------------------------------------------------------------ | -------------------------------------- |\n| `send` 전 | `Fetch.enable({ patterns: [{ requestStage: 'Request' }] })`로 보내기 전에 붙잡고 abort | 없음 |\n| `send` 중 | `Network.emulateNetworkConditions`의 `uploadThroughput`을 낮추고(200KB 본문, 20KB/s) abort | 헤더 + 본문 16KB, 미완료, 핸들러 안 돎 |\n| `processing` | 서버가 오래 걸리는 엔드포인트에서 abort | 받음, 처리 완료 |\n| `resp` | `requestStage: 'Response'`로 응답을 붙잡고 abort | 받음, 처리 완료 |\n\n`send` 중 줄이 경계를 한 번 더 쪼갠다. 전송 도중 취소하면 서버는 아무것도 못 받는 게 아니라 **헤더와 본문 일부를 받는다.** 본문이 끝나야(`end`) 처리하는 서버라 핸들러가 안 돌았을 뿐이다. 헤더만 보고 일을 시작하는 서버라면 전송 완료 전 취소도 부수효과를 낸다 — \"경계는 전송 완료\"는 **본문까지 받고 처리하는 서버**에서의 이야기다.\n\n\n\n[^fetch-abort]: Fetch 표준의 abort 알고리즘은 controller 상태를 `aborted`로 바꾸고 이유를 기록할 뿐, 서버로 무엇을 보내라고 정하지 않는다. 연결을 닫거나 응답 읽기를 멈추는 건 구현 재량이다. ([Fetch Standard — abort a fetch](https://fetch.spec.whatwg.org/#abort-fetch))\n\n[^abort-observed]: Chrome 154 headless 에서 raw CDP 로 실측 (2026-10-01). 로컬 Node 서버가 요청 수신·본문 바이트·`end`·응답 완료를 기록했고, 페이지는 `AbortController` 로 POST 를 취소했다. 네 경우 모두 promise `AbortError`, `Network.loadingFailed` `canceled: true` `net::ERR_ABORTED` 로 같았다. `uploadThroughput` 스로틀링은 localhost 요청에도 걸렸다."},{"i":"569","t":"location.href 는 암묵적 await 가 아니다 — setter 는 동기, navigation 은 태스크","k":["javascript","event-loop","navigation"],"c":"2026-06-23","m":"2026-10-01","b":"`location.href`에 값을 넣으면 그 줄에서 멈추고 이동할 것 같다 — **암묵적 `await`** 처럼. 그럼 뒤의 코드는 안 돌까. 추측하지 말고 CDP로 깨 본다.\n\n## 1. 실험을 건다\n\n외부 도메인 대신 로컬 서버의 `/a`·`/b`로 이동시킨다(서버는 받은 요청을 기록한다). `Runtime`·`Page`·`Network`를 enable 하고, 마지막 식의 값까지 돌려받게 한 줄을 붙여 `Runtime.evaluate`로 실행한다.\n\n```js\nlocation.href = '/a'\nconsole.log('실행됨 1')\nlocation.href = '/b'\nconsole.log('실행됨 2')\n// 'evaluate 끝까지 돌았다'\n```\n\n`await`였다면 첫 줄에서 멈춰 `실행됨 1`도 안 찍히고 `/a`로 가야 한다.\n\n## 2. 이벤트 순서를 읽는다\n\nCDP가 받은 순서 그대로다.[^nav-observed]\n\n| ms | 이벤트 | |\n| --- | --------------------------------------------------- | ------------------------------------- |\n| 514 | `Page.frameRequestedNavigation` | `/a` · `scriptInitiated` |\n| 516 | `Runtime.consoleAPICalled` | `실행됨 1` |\n| 517 | `Page.frameRequestedNavigation` | `/b` |\n| 517 | `Runtime.consoleAPICalled` | `실행됨 2` |\n| 517 | `Runtime.evaluate` 응답 | `'evaluate 끝까지 돌았다'` |\n| 518 | `Page.frameStartedNavigating` | `/a` |\n| 520 | `Network.requestWillBeSent` | `/a` |\n| 521 | `Network.loadingFailed` | `net::ERR_ABORTED` · `canceled: true` |\n| 523 | `Page.frameStartedNavigating` · `requestWillBeSent` | `/b` |\n| 528 | `Page.frameNavigated` | `/b` |\n\n- **setter는 동기로 끝나고 흐름을 안 끊는다.** 이동 요청(`frameRequestedNavigation`)이 console 로그 사이사이에 찍히고, `evaluate`가 마지막 식의 값을 돌려준다 — 코드는 끝까지 돌았다.\n- **실제 이동은 그 뒤에 시작된다.** `frameStartedNavigating`은 `evaluate`가 끝난 다음이다. 문서 언로드·페치는 태스크로 넘어가 지금 코드가 끝난 뒤에 돈다.\n- **마지막 값이 이기는 건 앞의 것이 취소되기 때문이다.** `/a`가 시작됐다가 `/b`가 시작되며 `ERR_ABORTED`로 끊긴다.[^html-spec-navigate] 덮어쓴 게 아니다.\n\n\n\n## 3. 덤 — 버려진 이동도 서버에는 갔다\n\n서버 기록은 `[\"/a\",\"/b\"]`다. `/a`는 `requestWillBeSent`까지 갔다가 클라이언트에서 끊겼을 뿐, 요청은 서버에 도착했다. 이동 전에 서버 부수효과가 있는 URL(로그아웃 링크 같은)이라면 \"결국 `/b`로 갔으니 `/a`는 없던 일\"이 아니다 — [572](/memo/572)의 \"취소는 클라이언트에서만 일어난다\"와 같은 이야기다.\n\n[^html-spec-navigate]: _\"Set the ongoing navigation for navigable to navigationId. This will have the effect of **aborting other ongoing navigations** of navigable, since at certain points during navigation changes to the ongoing navigation will cause further work to be abandoned.\"_ — 그리고 문서 언로드·페치는 `in parallel` 로 넘어간다. ([HTML Standard — navigate](https://html.spec.whatwg.org/multipage/browsing-the-web.html#navigate))\n\n[^nav-observed]: Chrome 154 headless 에서 raw CDP 로 실측 (2026-10-01). ms 는 스크립트 시작 기준이고, `evaluate` 를 보낸 시각은 512ms 다. 로컬 Node 서버가 문서 요청 경로를 기록했다."},{"i":"568","k":["probability","coupon-collector","math"],"c":"2026-06-23","m":"2026-08-23","b":"import AutoIframe from '@components/AutoIframe/AutoIframe.astro'\n\n목록 90개에서 매번 무작위로 하나를 뽑아 보여준다고 하자 (작업 중에 문구를 바꿔 띄우는 스피너 같은 것). **90개를 다 보려면 90번쯤이면 될까.**\n\n아니다. **평균 457번**이다. 5배다. 1초에 하나씩이면 7분 반.\n\n목록을 한 번 섞어서 처음부터 끝까지 도는 게 아니라 **매번 90개 전체에서 다시 뽑기** 때문이다. 그러면 이미 본 것이 계속 다시 나온다. 섞어 돌았다면 90번에 정확히 끝났을 일이다.\n\n**꼬리가 어디서 생기는지가 핵심이다.** 89개를 모았을 때, 남은 마지막 하나가 뽑힐 확률은 90분의 1이다. 그 **한 개를 만나는 데만 평균 90번** — 섞어서 돌았다면 90개 전부를 봤을 횟수다.[^wikipedia-coupon-collector]\n\n이게 쿠폰 수집가 문제(coupon collector)다. 전부 모으는 데 걸리는 평균 횟수는\n\n```\nn × (1 + 1/2 + 1/3 + … + 1/n)\n```\n\n\n\n[^wikipedia-coupon-collector]: 전부 모으는 기대 횟수는 `n·H_n`(`H_n`은 조화수). 그리고 `i`번째 새 쿠폰까지의 기대 대기는 `n/(n-i+1)` 이므로 **마지막 한 장은 `n/1 = n`** — 단계 중 가장 오래 걸린다. ([Coupon collector's problem — Wikipedia](https://en.wikipedia.org/wiki/Coupon_collector%27s_problem))"},{"i":"567","t":"'blocking=render 는 전에만 등록된다 — 뒤에 붙으면 조용한 no-op'","k":["performance","rendering","fouc","html"],"c":"2026-06-23","m":"2026-10-01","b":"import AutoIframe from '@components/AutoIframe/AutoIframe.astro'\n\n새로고침하면 한 프레임 동안 스타일이 붙기 전 default 상태가 보인다. **파서를 멈추는 것과 paint를 멈추는 것은 다르다** — 동기 `\n \n \n {/block:Text}\n\n```\n\n```javascript\n// 데이터 참조\nconst post = this.closest('[id][data-type]')\nconst npf = JSON.parse(post.querySelector('script[data-npf]').textContent)\n\n// 렌더링 - createElement 사용 (Tumblr 템플릿 ${} 충돌 회피)\nconst img = document.createElement('img')\nimg.src = imageURL\nthis.appendChild(img)\n```\n\n제약: `{NPF}`는 Text 포스트에서만 사용 가능. Photo는 기존 Tumblr 변수 사용."},{"i":"506","k":[],"c":"2025-12-26","m":"2025-12-26","b":"React에서 iframe 내부에 컴포넌트 렌더링\n\n```tsx\n// react-frame-component 사용 (권장)\nimport Frame from 'react-frame-component'\n;{`body { margin: 0; }`}}>\n \n\n\n// 직접 구현: createPortal + contentDocument\nfunction IframeRenderer({ children }) {\n const iframeRef = useRef(null)\n const [mountNode, setMountNode] = useState(null)\n useEffect(() => {\n const iframe = iframeRef.current\n const handleLoad = () => setMountNode(iframe?.contentDocument?.body ?? null)\n iframe?.addEventListener('load', handleLoad)\n if (iframe?.contentDocument?.readyState === 'complete') handleLoad()\n return () => iframe?.removeEventListener('load', handleLoad)\n }, [])\n return (\n <>\n