맥락 없는 일을 복원하고 여러 문제를 해결했지만 잘 처리했다는 결과 뒤에는 피로가 남았다. AI로 더 많이 할 수 있게 된 시기에 무엇을 맡지 않을지도 돌아본다.
[Read More]
모든 VOC를 직접 읽지 않고도 놓치지 않는 법: Slack과 Amplitude로 만든 예외 기반 모니터링
여러 VOC 채널을 매일 직접 읽는 대신 AI로 중복과 잡음을 줄이고 제품 행동 데이터로 신호를 검증했다. 집중력을 지키면서 실제 이상에만 개입하는 흐름을 정리한다.
[Read More]
겉멋 AI: 매끈한 요청이 판단의 부재를 가릴 때
AI가 매끈하게 만든 요청이라도 목표·대상·근거·책임에 대한 판단이 빠지면 협업 비용은 수신자에게 넘어간다. AI 사용 여부보다 총 협업 비용을 묻는다.
[Read More]
SSR은 클라이언트의 일을 없애지 않는다: 빨라지는 화면과 그렇지 않은 화면 구분하기
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]