SSR은 서버가 초기 HTML을 만들지만 브라우저의 DOM 구성·레이아웃·페인트까지 없애지는 않는다. 서버가 아는 입력과 기존 prefetch를 기준으로 SSR이 실제로 빨라지는 조건을 구분한다.
[Read More]
Next.js 보안 패치, 버전만 올리고 끝내지 않기
Next.js 보안 릴리스는 버전만 올리고 끝낼 일이 아니다. 먼저 패치한 뒤 Server Actions, 라우팅, 이미지 최적화, 서버 캐시의 노출 표면을 확인하는 절차를 정리한다.
[Read More]
프론트엔드는 왜 이렇게 복잡해졌을까: 도구 뒤의 상처를 따라가 보기
프론트엔드의 복잡성은 유행이나 과잉 설계만으로 생기지 않았다. 브라우저 제약과 제품 요구에 대응하며 쌓인 도구들의 역사와 지금의 선택 기준을 살펴본다.
[Read More]
모니터링은 대시보드 하나가 아니었다: 숫자를 보는 RUM, 신호를 읽는 AI 스킬
서버 대시보드만으로는 브라우저 메인 스레드의 개선과 사용자 화면의 이상을 설명하기 어려웠다. RUM 지표와 읽기 전용 AI 점검을 나눠 운영한 방법을 정리한다.
[Read More]
체크아웃 성능을 1초 아래로 줄이려다 만난 세 개의 벽
체크아웃 화면을 1초 아래로 줄이려다 네트워크, 측정 분포, 브라우저 렌더링이라는 세 개의 벽을 만났다. 실패한 가설과 실제 병목을 구분한 성능 개선 과정을 정리한다.
[Read More]
useLayoutEffect는 '더 안전한 useEffect'가 아니다: reflow와 flash의 맞교환
첫 페인트 전 DOM 크기를 읽어 깜빡임을 막았지만 강제 동기 reflow가 렌더링을 늦췄다. useLayoutEffect와 useEffect 사이에서 reflow와 flash를 어떻게 비교할지 정리한다.
[Read More]
흰 화면은 네트워크가 아니라 렌더였다: 하던 성능 작업을 접고 방향을 바꾼 기록
네트워크가 느리다고 가정해 prefetch를 준비했지만 영상 비교에서는 흰 화면 시간이 거의 같았다. 잘못 잡은 가설을 접고 렌더링과 CPU 비용으로 방향을 바꾼 기록이다.
[Read More]
잘못 이해한 요구도 AI는 빠르게 구현한다
AI는 명확한 요구뿐 아니라 잘못 이해한 요구도 빠르게 구현한다. 화면의 증상과 실제 계약을 구분하지 못해 생긴 재작업을 통해 구현 전 확인할 질문을 정리한다.
[Read More]
평균이 빨라져도 성능 개선이 아닐 수 있다: 캐시와 이봉 분포 읽기
평균은 빨라졌지만 측정값은 빠른 실행과 느린 실행 두 무리로 갈렸다. 코드 효과를 단정하기 전에 캐시·연결 재사용·실험 조건과 원본 분포를 읽는 방법을 정리한다.
[Read More]
같은 정책, 다른 API: 화면마다 답이 달라지는 데이터 일관성 문제
같은 사용자 정책을 여러 API가 서로 다른 값과 시점으로 제공하면 화면마다 답이 달라진다. 기준 원천과 정책 소유권 없이 프론트엔드가 한쪽을 고를 때 생기는 문제를 살펴본다.
[Read More]
Feature Flag 장애가 흰 화면을 만들 때: return null 대신 실패 정책 설계하기
Feature Flag 조회 실패를 비활성 상태와 똑같이 처리하자 핵심 화면이 흰 페이지가 됐다. 로딩·실패·값 없음·비활성을 나누고 복구 가능한 화면을 남기는 실패 정책을 설계한다.
[Read More]
장애 기록은 저장으로 끝나지 않는다: 검색되고 전파되고 대응을 시작해야 한다
장애 기록은 저장됐다는 사실만으로 다음 대응을 돕지 못한다. 증상과 완화 방법으로 검색되고, 검토·전파·후속 조치까지 이어지는 완료 조건을 정리한다.
[Read More]