브라우저 기초: 신화 없이 보는 네트워킹, 렌더링, 캐싱

브라우저에 관한 오해들이 실제 버그를 만드는 이유

많은 프런트엔드 버그는 "브라우저의 수수께끼 같은 동작" 때문이 아닙니다. 대부분은 “브라우저는 모든 걸 캐시한다”거나 “React는 기본적으로 빠르다” 같은 반쯤 기억한 규칙들 때문입니다. 이런 문구들은 그럴듯하게 들리기 때문에, 사람들은 슬로건에서 멈추고 “무엇과 비교해서 빠른가? 어떤 조건에서 그런가?” 같은 질문을 하지 않습니다.

웹은 절충의 연속입니다. 브라우저는 네트워크 지연, CPU, 메모리, 메인 스레드, GPU 작업, 저장공간 한도를 동시에 조율합니다. 머릿속 모델이 흐릿하면 노트북에선 괜찮아 보이던 UI가 중간급 휴대폰의 불안정한 Wi‑Fi에서 무너질 수 있습니다.

현실에서 버그로 이어지는 몇 가지 흔한 가정들:

• “첫 로드 이후에는 빨라야 한다.” 그런데 헤더가 빠졌거나 빌드마다 URL이 바뀌어 아무 것도 캐시되지 않았음을 발견합니다.
• “브라우저는 모든 걸 병렬로 다운받는다.” 그런데 하나의 큰 스크립트가 메인 스레드를 막아 입력이 멈춘 것처럼 느껴집니다.
• “이미지는 싸다.” 하지만 압축되지 않은 히어로 이미지는 렌더링을 지연시키고 레이아웃을 밀어 Core Web Vitals가 나빠집니다.
• “내 코드만 중요하다.” 그런데 서드파티 위젯, 폰트, 긴 작업이 타임라인을 장악해 버립니다.

AI로 생성된 프론트엔드는 이런 실수를 증폭시킬 수 있습니다. 모델은 외형상 올바른 React 페이지를 만들 수 있지만, 지연을 느끼지 못하고 대역폭 비용을 계산하지 않으며, 각 렌더가 추가 작업을 트리거한다는 사실을 알아차리지 못합니다. 불필요하게 큰 종속성을 추가하거나, 거대한 JSON을 HTML에 인라인하거나, 두 가지 합리적으로 보이는 패턴을 결합해 같은 데이터를 두 번 가져오게 할 수 있습니다.

Koder.ai 같은 vibe‑coding 도구를 쓰면 더 문제가 될 수 있습니다: UI를 빠르게 많이 생성할 수 있지만, 숨겨진 브라우저 비용은 아무도 눈치채기 전에 쌓입니다.

이 글은 일상 작업에서 자주 보이는 기본 사항들—네트워킹, 캐싱, 렌더링 파이프라인—에 집중합니다. 목표는 브라우저가 무엇을 할지 예측할 수 있는 머릿속 모델을 갖게 해, 흔한 “빠를 줄 알았다” 함정을 피하는 것입니다.

URL에서 픽셀까지: 명확한 머릿속 모델

브라우저를 URL을 픽셀로 바꾸는 공장으로 생각해 보세요. 생산 라인의 각 역을 알면 어디서 시간이 새는지 짐작하기 쉬워집니다.

대부분의 페이지는 이런 흐름을 따릅니다:

• 네비게이션 시작: URL을 입력하거나 링크를 클릭하면 브라우저가 요청을 보낼 위치를 결정합니다.
• 바이트 도착: 먼저 HTML, 그다음 CSS, JS, 이미지, 폰트가 옵니다.
• 파싱 발생: HTML은 DOM이 되고, CSS는 브라우저가 적용할 수 있는 규칙이 됩니다.
• 렌더링 작업 시작: 레이아웃(크기와 위치), 페인트(그리기), 그리고 컴포지팅(레이어 쌓기).
• 상호작용: 자바스크립트가 실행되고 이벤트 핸들러가 붙습니다.

서버는 HTML, API 응답, 에셋과 함께 캐싱 및 보안 관련 헤더를 돌려줍니다. 브라우저의 일은 요청 전(cache 조회, DNS, 연결 설정)에도 시작되고 응답 후(파싱, 렌더링, 스크립트 실행, 다음 번을 위한 저장)에도 계속됩니다.

많은 혼란은 브라우저가 한 번에 한 가지 일만 한다고 가정하는 데서 옵니다. 사실은 그렇지 않습니다. 일부 작업은 메인 스레드 외부에서 일어납니다(네트워크 가져오기, 이미지 디코드, 일부 컴포지팅). 메인 스레드는 ‘막지 말아야 할’ 차선입니다. 사용자 입력을 처리하고 대부분의 자바스크립트를 실행하며 레이아웃과 페인트를 조정합니다. 메인 스레드가 바쁘면 클릭이 무시되는 듯하고 스크롤이 끈적거리게 됩니다.

대부분의 지연은 네트워크 대기, 캐시 미스, CPU 무거운 작업(자바스크립트, 레이아웃, 너무 많은 DOM), 또는 GPU 무거운 작업(너무 많은 큰 레이어와 효과)에서 숨어 있습니다. 이런 머릿속 모델은 AI 도구가 "괜찮아 보이는" 결과물을 만들었지만 느리게 만드는 곳을 짐작하는 데도 도움이 됩니다: 보통 그 역들 중 하나에 추가 작업을 만들어 냈습니다.

UI에 실제로 영향을 주는 네트워킹 기초

실제 "콘텐츠"가 다운로드되기 전에도 페이지가 느리게 느껴질 수 있습니다. 브라우저가 먼저 서버에 도달해야 하기 때문입니다.

URL을 입력하면 브라우저는 일반적으로 DNS(서버 찾기), TCP 연결 열기, 그다음 TLS 협상(암호화 및 검증)을 합니다. 각 단계는 특히 모바일 네트워크에서 대기 시간을 더합니다. 그래서 “번들이 200KB뿐인데”도 느껴질 수 있습니다.

그 다음 브라우저는 HTTP 요청을 보내고 응답을 받습니다: 상태 코드, 헤더, 바디. 헤더는 캐싱, 압축, 콘텐츠 타입을 제어하므로 UI에 중요합니다. 콘텐츠 타입이 잘못되면 브라우저가 파일을 의도한 대로 파싱하지 못할 수 있습니다. 압축이 활성화되어 있지 않으면 텍스트 자산은 훨씬 큰 다운로드가 됩니다.

리디렉션은 시간을 낭비하는 또 다른 쉬운 방법입니다. 한 번의 추가 홉은 또 다른 요청과 응답을 의미하고, 때로는 또 다른 연결 설정을 요구합니다. 홈페이지가 한 URL에서 다른 URL로, 다시 다른 URL로(예: http → https → www → 지역) 리디렉션된다면, 브라우저가 중요한 CSS와 JS를 가져오기 전에 여러 번의 대기 시간을 추가한 것입니다.

크기는 이미지만이 아닙니다. HTML, CSS, JS, JSON, SVG도 일반적으로 압축되어야 합니다. 또한 자바스크립트가 무엇을 끌어오는지도 주의하세요. “작은” JS 파일이더라도 즉시 다른 요청들(청크, 폰트, 서드파티 스크립트)을 촉발할 수 있습니다.

UI에 관련된 문제를 잡아내는 빠른 점검 항목:

• 첫 네비게이션에서 불필요한 리디렉션 제거.
• 텍스트 자산(CSS, JS, JSON, SVG)에 대해 압축이 활성화되어 있는지 확인.
• 파일이 올바르게 파싱되도록 콘텐츠 타입 확인.
• 요청 폭주(수십 개의 청크, 폰트, 아이콘, 트래커)를 주의.
• 가능한 한 주요 자산을 같은 오리진에 유지해 연결 재사용을 활용.

AI가 생성한 코드는 출력물을 여러 청크로 나누고 기본적으로 추가 라이브러리를 끌어오는 방식으로 이를 악화시킬 수 있습니다. 각 파일이 작더라도 네트워크가 “바쁘다”고 보이며 시작 시간이 길어집니다.

민속학 없는 캐싱: 언제 무엇이 재사용되는가

“캐시”는 하나의 마법 상자가 아닙니다. 브라우저는 여러 장소에서 데이터를 재사용하며, 각 장소는 서로 다른 규칙을 가집니다. 어떤 리소스는 메모리에 짧게 존재(빠르지만 새로고침 시 사라짐)하고, 다른 리소스는 디스크에 저장되어 재시작 후에도 남습니다. HTTP 캐시는 응답이 재사용될 수 있는지를 결정합니다.

쉽게 풀어 쓴 Cache-Control

대부분의 캐싱 동작은 응답 헤더로 제어됩니다:

• max-age=...: 시간이 다할 때까지 서버에 다시 확인하지 않고 응답을 재사용.
• no-store: 메모리나 디스크에 저장하지 마세요(민감한 데이터에 적합).
• public: 사용자 브라우저뿐 아니라 공유 캐시에서도 캐시할 수 있음.
• private: 사용자 브라우저에만 캐시.
• no-cache: 혼란스러운 이름. 보통은 “저장하되 재사용 전에 재검증”을 의미합니다.

브라우저가 재검증할 때 전체 파일을 다시 다운로드하지 않으려 합니다. 서버가 ETag나 Last-Modified를 제공했다면 브라우저는 “변경되었나?”라고 물어볼 수 있고 서버는 “변경 없음”으로 답할 수 있습니다. 그 왕복은 여전히 시간이 들지만 전체 다운로드보다 보통 저렴합니다.

흔한 실수(특히 AI 생성 설정에서)는 app.js?cacheBust=1736 같은 무작위 쿼리 문자열을 빌드마다 또는 더 나쁘게는 페이지 로드마다 추가하는 것입니다. 안전해 보이지만 캐싱을 무력화합니다. 더 나은 패턴은 고정된 URL을 안정된 콘텐츠에 쓰고, 버전이 있는 자산에는 콘텐츠 해시를 파일명에 포함시키는 것입니다.

역효과를 내는 캐시 버스터는 예측 가능한 형태로 나타납니다: 무작위 쿼리 파라미터, 변경되는 JS/CSS에 같은 파일명 재사용, 배포마다 콘텐츠가 바뀌지 않았는데 URL을 변경, 또는 개발 중에 캐싱 비활성화 후 이를 되돌리는 것을 잊음.

서비스 워커는 오프라인 지원이나 반복 로드를 즉시 제공해야 할 때 도움이 되지만 또 다른 캐시 계층을 추가하므로 관리해야 합니다. 앱이 “업데이트되지 않는다”고 느껴지면 종종 오래된 서비스 워커 탓입니다. 무엇을 캐시할지, 업데이트를 어떻게 배포할지 명확히 설명할 수 있을 때만 사용하세요.

렌더링 파이프라인 기초: 파싱, 레이아웃, 페인트, 컴포지트

"수수께끼" 같은 UI 버그를 줄이려면 브라우저가 바이트를 픽셀로 바꾸는 과정을 배우세요.

HTML이 도착하면 브라우저는 위에서 아래로 파싱해 DOM(요소의 트리)을 만듭니다. 파싱 중에 브라우저는 표시를 바꾸는 CSS, 스크립트, 이미지, 폰트를 발견할 수 있습니다.

CSS는 특수합니다. 브라우저는 최종 스타일을 알아야 안전하게 콘텐츠를 그릴 수 있습니다. 그래서 CSS는 렌더링을 차단할 수 있습니다: 브라우저는 CSSOM(스타일 규칙)을 만들고 DOM + CSSOM을 렌더 트리로 결합합니다. 중요한 CSS가 지연되면 첫 페인트가 지연됩니다.

스타일이 확정되면 주요 단계는 다음과 같습니다:

• 레이아웃: 크기와 위치 계산.
• 페인트: 텍스트, 테두리, 그림자, 이미지의 픽셀을 그리기.
• 컴포지트: 페인트된 레이어를 쌓고 변환/투명도 적용.

이미지와 폰트는 종종 사용자가 “로딩되었다”고 느끼는 요소를 좌우합니다. 지연된 히어로 이미지는 Largest Contentful Paint를 늦춥니다. 웹 폰트는 텍스트가 보이지 않거나 스타일이 바뀌어 깜박이는 것처럼 보이게 할 수 있습니다. 스크립트는 파싱을 차단하거나 추가 스타일 재계산을 유발하면 첫 페인트를 지연시킬 수 있습니다.

“애니메이션은 무료다”라는 지속적인 오해가 있습니다. 어떤 속성을 애니메이트하느냐에 따라 다릅니다. width, height, top, left를 변경하면 종종 레이아웃을 강제하고 그다음 페인트와 컴포지팅이 필요합니다. 반면 transform이나 opacity를 애니메이트하면 보통 컴포지팅 단계 내에서 처리되어 훨씬 비용이 적습니다.

현실적인 AI 생성 실수 예시는 많은 카드에 background-position을 애니메이트하는 로딩 시머와 타이머로 빈번히 DOM을 업데이트하는 것입니다. 결과는 지속적인 리페인트입니다. 보통 해결책은 단순합니다: 애니메이션 요소 수 줄이기, 동작에 transform/opacity 선호, 레이아웃을 안정적으로 유지.

체감할 수 있는 자바스크립트와 프레임워크 비용

네트워크가 빠르더라도 브라우저가 자바스크립트를 실행하는 동안 페이지는 그릴 수도 응답할 수도 없어서 느끼게 됩니다. 번들을 다운로드하는 건 첫 단계일 뿐입니다. 더 큰 지연은 파싱과 컴파일 시간, 그리고 메인 스레드에서 실행하는 작업입니다.

프레임워크는 자체적인 비용을 더합니다. React에서는 “렌더링”이 UI가 어떻게 보여야 하는지를 계산하는 것입니다. 첫 로드에서 클라이언트 사이드 앱은 종종 하이드레이션을 수행합니다: 이벤트 핸들러를 붙이고 이미 있는 마크업을 재조정합니다. 하이드레이션이 무거우면 페이지는 준비된 것처럼 보이지만 잠깐 탭을 무시할 수 있습니다.

문제는 보통 긴 작업으로 드러납니다: 자바스크립트가 너무 오래(종종 50ms 이상) 실행되어 브라우저가 중간중간 화면을 업데이트할 수 없게 됩니다. 그 결과 지연된 입력, 프레임 드롭, 끊기는 애니메이션을 느낍니다.

흔한 원인은 단순합니다:

• 시작 시 너무 많은 코드 실행
• 파싱 및 변환에 시간이 걸리는 큰 JSON 페이로드
• 한 번에 너무 많은 작업을 렌더하는 컴포넌트
• 마운트 시 너무 많은 이펙트가 실행되어 추가 렌더를 촉발
• 불안정한 props, state, 또는 context로 인한 빈번한 재렌더

해결책은 메인 스레드 작업에 집중하면 더 분명해집니다. 단순히 바이트 수만 보는 것이 아니라:

• 라우트나 기능별로 코드 분할해 첫 화면에 로드되는 것을 줄이기.
• 첫 페인트 후 또는 상호작용 이후에 비핵심 작업을 연기.
• 하이드레이션을 가볍게 유지하고 초기 렌더에서 무거운 변환 피하기.
• 측정하면서 신중히 메모이제이션 적용해 불필요한 복잡성 추가 금지.
• 가능한 경우 비싼 파싱/포맷 작업을 메인 스레드 밖으로 이동.

Koder.ai 같은 채팅 기반 도구로 빌드할 때는 이러한 제약을 직접 요청하면 도움이 됩니다: 초기 JS를 작게 유지, 마운트 시 이펙트 피하기, 첫 화면을 단순하게 유지 등.

단계별: 느린 페이지 디버그 방법

증상을 간단한 말로 정의하는 것부터 시작하세요: “첫 로드가 8초 걸린다”, “스크롤이 끈적거리다”, “새로고침 후 데이터가 오래돼 보인다” 등. 증상마다 원인이 다릅니다.

실용적인 워크플로

먼저 네트워크를 기다리는 중인지 CPU를 태우는 중인지 결정하세요. 간단한 확인: 로드하는 동안 무엇을 할 수 있는지 보며 새로고침하세요. 페이지가 빈 화면이고 아무 반응이 없으면 종종 네트워크가 병목입니다. 페이지가 보이지만 클릭이 지연되거나 스크롤이 끊기면 종종 CPU가 병목입니다.

모든 것을 한꺼번에 고치지 않게 해주는 워크플로:

• 느린 부분(초기 로드, 상호작용, 데이터 새로고침)과 대략적 시간을 적어두기.
• 네트워크 vs CPU 분리: 연결을 느리게(throttle) 해보고 비교. 많이 나빠지면 네트워크 비중이 큼. 거의 변하지 않으면 CPU 작업에 집중.
• 가장 큰 요청과 가장 긴 작업 찾기. 거대한 JS 번들, 큰 이미지, 긴 "script" 태스크가 주범인 경우가 많음.
• 원인 하나씩 제거(번들 분할, 이미지 리사이즈, 서드파티 스크립트 연기 등) 후 재테스트.
• 현실적인 기기와 연결에서 재테스트. 빠른 노트북은 중간급 휴대폰에서 드러나는 문제를 숨깁니다.

구체적 예: AI가 만든 React 페이지가 2MB짜리 단일 JS 파일과 큰 히어로 이미지를 배포했다고 합시다. 내 기기에서는 괜찮아 보입니다. 휴대폰에서는 JS를 파싱하는 데 몇 초를 소비해 응답하지 못합니다. 첫 화면 JS를 줄이고 히어로 이미지를 리사이즈하면 보통 상호작용까지 걸리는 시간이 크게 줄어듭니다.

성과를 고착화하기

측정 가능한 개선을 얻었으면 되돌아가기 어렵게 만드세요.

번들 크기, 이미지 크기 같은 예산을 정하고 이를 초과하면 빌드를 실패시키세요. 어떤 것이 느렸고, 무엇이 고쳤는지, 무엇을 주시할지에 대한 짧은 성능 노트를 레포에 두세요. 특히 AI가 구성요소를 빠르게 생성할 때 큰 UI 변경이나 새 종속성이 생기면 다시 확인하세요.

AI로 만든 프론트엔드에서 흔한 실수(그리고 원인)

AI는 동작하는 UI를 빠르게 작성하지만, 페이지를 빠르고 안정적으로 만드는 지루한 부분들을 자주 놓칩니다. 브라우저 기초를 알면 느린 로드, 끊기는 스크롤, 예상치 못한 API 요금폭탄 같은 문제를 초기에 발견할 수 있습니다.

과도한 페칭이 흔합니다. AI가 생성한 페이지는 같은 화면을 위해 여러 엔드포인트를 호출하거나 작은 상태 변경에 재조회(refetch)를 하거나 전체 데이터셋을 불러올 수 있습니다. 프롬프트는 UI를 더 자주 설명하고 데이터 형태는 덜 설명하므로 모델은 페이지네이션이나 배치 없이 여분의 호출로 메우는 경향이 있습니다.

렌더 차단도 반복되는 문제입니다. 폰트, 큰 CSS 파일, 서드파티 스크립트가 머리말(head)에 떨어져 있는 것은 “맞는 것처럼” 보이지만 첫 페인트를 지연시킬 수 있습니다. 중요한 리소스가 아닌 것들을 기다리며 빈 페이지를 보는 상황이 생깁니다.

캐싱 실수는 보통 선의에서 옵니다. AI는 때때로 “아무 것도 재사용하지 마라”와 같은 헤더나 fetch 옵션을 추가하는데, 더 안전해 보이기 때문입니다. 결과는 불필요한 다운로드, 느린 반복 방문, 백엔드에 대한 추가 부하입니다.

하이드레이션 불일치도 급하게 생성한 React 출력에서 자주 발생합니다. 서버(또는 사전 렌더)에서 생성한 마크업이 클라이언트가 렌더링하는 것과 맞지 않아 React가 경고를 내거나 재렌더하거나 이벤트를 이상하게 붙입니다. 이는 보통 초기 렌더에 무작위 값(날짜, ID)을 섞어 넣거나 클라이언트 전용 상태에 따라 달라지는 조건문에서 옵니다.

이 신호들이 보이면 페이지가 성능 가드레일 없이 조립되었다고 가정하세요: 한 화면에 중복 요청, 사용하지 않는 UI 라이브러리로 인한 거대한 JS 번들, 불안정한 값 때문에 리패치하는 이펙트, 핵심 CSS 이전에 로드되는 폰트나 서드파티 스크립트, 전역적으로 비활성화된 캐싱 등이 대표적입니다.

Koder.ai 같은 vibe‑coding 도구를 쓴다면, 생성된 출력을 초안으로 보세요. 페이지네이션, 명시적 캐싱 규칙, 첫 페인트 전에 무엇을 불러야 하는지에 대한 계획을 요구하세요.

현실적인 예: AI로 생성된 React 페이지 고치기

AI가 만든 React 마케팅 페이지는 스크린샷상 완벽해 보여도 실제 사용하면 느릴 수 있습니다. 흔한 구성은 히어로 섹션, 추천사, 가격표, API를 호출하는 “최신 업데이트” 위젯입니다.

증상은 익숙합니다: 텍스트가 늦게 보이고, 폰트 로드로 레이아웃이 튀고, 가격 카드가 이미지 도착 후에 뒤섞이며, API 호출이 여러 번 발생하고, 배포 후 일부 자산이 오래된 상태로 남습니다. 이 모든 것은 미스테리가 아니라 UI에 나타난 기본 브라우저 동작입니다.

두 가지 관점으로 시작하세요.

첫째, DevTools에서 Network 워터폴을 확인하세요. 모든 것을 막는 큰 JS 번들, 늦게 로드되는 폰트, 크기 힌트 없는 이미지, 약간 다른 쿼리 문자열로 반복되는 동일 엔드포인트 호출을 찾아보세요.

둘째, 새로고침하면서 Performance 트레이스를 기록하세요. 긴 작업(메인 스레드를 막는 자바스크립트)과 Layout Shift 이벤트(콘텐츠 도착 후 페이지가 재배치되는)를 중심으로 보세요.

이 시나리오에서는 소수의 수정으로 대부분 개선을 얻는 경우가 많습니다:

• 캐싱 헤더: 버전이 붙은 자산(예: app.abc123.js)에는 긴 캐시를 설정하고 HTML은 영구 캐시하지 않아 최신 파일을 가리키게 하기.
• 폰트 전략: 시스템 폴백 사용, 실제로 필요한 한두 폰트만 프리로드, 여러 웨이트 로드 피하기.
• 코드 분할: “최신 업데이트” 위젯과 무거운 애니메이션 라이브러리는 첫 페인트에 필요하지 않다면 나중에 로드.
• 요청 정리: API 호출이 한 번만 실행되도록(개발 중 React Strict Mode가 이펙트를 두 번 호출하는 것을 주의), 페치 중복 제거, 마케팅 페이지에서 폴링 피하기.
• 이미지 안정성: width와 height(또는 aspect-ratio)를 설정해 브라우저가 공간을 예약하고 레이아웃 점프를 피하게 하기.

복잡한 도구 없이 개선을 검증하세요. 캐시 비활성화 상태에서 세 번 새로고침한 뒤 캐시 활성 상태에서 세 번 새로고침해 워터폴을 비교합니다. 텍스트가 더 빨리 렌더되고 API 호출이 하나로 줄며 레이아웃이 안정되어야 합니다. 마지막으로 배포 후 하드 리프레시하세요. 여전히 오래된 CSS나 JS가 보이면 캐시 규칙이 배포 방식과 맞지 않는 것입니다.

Koder.ai로 페이지를 만들었다면 같은 루프를 유지하세요: 한 번의 워터폴을 검사하고, 하나를 변경하고, 다시 검증하세요. 작은 반복이 “AI가 만든 놀라움”을 피하게 합니다.

빠른 체크리스트와 다음 단계

페이지가 느리거나 글리치가 있을 때 민속학은 필요 없습니다. 몇 가지 점검으로 대부분의 실무 문제(특히 AI 생성 UI에서 나타나는 문제)를 설명할 수 있습니다.

여기서 시작하세요:

• 추가 리디렉션 제거(특히 http → https, www → non‑www). 각 홉은 지연을 추가하고 첫 페인트를 늦출 수 있습니다.
• 캐싱 헤더가 자산 전략과 일치하는지 확인. 큰 번들이 절대 캐시되지 않으면 매번 전체 재다운로드입니다.
• 렌더 차단 CSS 찾기. 헤드에 있는 큰 스타일시트는 렌더링을 지연시키며 생성된 출력은 종종 과도한 CSS를 포함합니다.
• 가장 큰 자바스크립트 파일을 식별하고 왜 첫 화면에 로드되어야 하는지 결정.
• 동일 리소스에 대한 반복 요청을 찾아라(종종 불안정한 URL이나 맞지 않는 캐시 규칙이 원인).

페이지가 단순히 느린 것이 아니라 끊긴다면, 움직임과 메인 스레드 작업에 집중하세요. 레이아웃 점프는 보통 크기 정보 없는 이미지, 늦게 로드되는 폰트, 데이터 도착 후 크기가 변하는 컴포넌트에서 옵니다. 긴 작업은 대개 초기화 시 너무 많은 자바스크립트(무거운 하이드레이션, 무거운 라이브러리, 너무 많은 노드를 렌더) 때문입니다.

AI에 프롬프트할 때는 실제 제약을 가리키는 브라우저 용어를 사용하세요:

• “렌더 차단 CSS를 피하세요; 위쪽 부분만 필요한 핵심 스타일만 인라인하세요.”
• “메인 번들을 분할하세요; 비핵심 코드는 첫 상호작용 뒤에 로드.”
• “정적 자산에 대해 Cache‑Control 설정; 파일명에 핑거프린트 사용.”
• “레이아웃 점프 방지: 이미지, 광고, 비동기 컴포넌트의 공간 확보.”
• “반복 페치 방지: 요청을 중복 제거하고 URL을 안정적으로 유지.”

Koder.ai에서 빌드한다면 Planning Mode에 이런 제약을 미리 적어두는 것이 좋습니다. 그런 다음 작은 변경으로 반복하고 스냅샷과 롤백을 사용해 배포 전 안전하게 테스트하세요.