내 앱 느릴 때 AI한테 그대로 시킬 말 11개

먼저: 어디가 느린지 찾는 법 (3단계)

1. 크롬에서 내 사이트를 열고 F12(맥은 Cmd+Option+I)로 개발자 도구를 열어요.
2. 위쪽 탭에서 Lighthouse를 누르고, 기기는 모바일을 고른 뒤 페이지 로드 분석(Analyze page load)을 눌러요.
3. 결과의 '개선 기회'(Opportunities)에 아래 이름이 보이면, 그 항목의 문장을 AI에게 붙여 넣으세요.

메뉴 이름은 크롬 버전에 따라 조금 다를 수 있어요. Lighthouse 감사 이름은 Chrome 개발자 문서 기준(2026-11-03)이에요.

제일 빠른 방법: 한 번에 붙여 넣기

내 앱이 느려서 사용자가 떠날까 걱정돼. 아래 11가지를 점검해서 항목마다 '이미 됨 / 해야 함 / 해당 없음'과 이유를 표로 알려 줘. 아직 고치지는 말고, '해야 함' 중에서 효과가 클 것 같은 순서로 3개만 골라 고칠 계획을 적어 줘.
1. 사진을 WebP나 AVIF로 제공하는지 (예전 아이폰용 JPEG·PNG 대체 파일 포함)
2. 첫 화면 아래 사진에 loading="lazy"가 붙어 있는지
3. 글자 파일(HTML·CSS·JS)을 Brotli 또는 GZIP으로 압축해서 보내는지
4. 받기만 하고 안 쓰는 JavaScript가 있는지, 페이지별로 나눌 수 있는지
5. 채팅창·광고·분석 같은 외부 스크립트가 본 내용보다 먼저 막고 있지 않은지 (async·defer)
6. 검색창이 글자마다 요청을 보내는지 (debounce 적용 여부)
7. 긴 목록을 한꺼번에 다 그리는지 (가상화 필요 여부)
8. 사진·글꼴·JS 같은 정적 파일에 캐시 기간이 설정돼 있는지
9. 웹 글꼴을 몇 개, 몇 굵기나 받는지 줄일 수 있는지
10. 자주 검색하는 데이터베이스 열에 색인이 있는지 (너무 많이 달지는 말고)
11. 크롬 개발자 도구에서 CPU·네트워크를 느리게 설정했을 때 어디가 막히는지 확인하는 방법

1. 사진은 WebP·AVIF로 가볍게

한 줄로: 사진 파일 형식을 JPEG·PNG에서 WebP나 AVIF로 바꾸는 거예요.

왜: 같은 그림을 더 작은 상자에 담는 것과 같아요. Chrome Lighthouse 문서에 따르면 AVIF·WebP는 JPEG·PNG보다 압축과 화질 특성이 좋아서, 바꾸면 더 빨리 뜨고 데이터도 덜 써요.

이 사이트의 사진을 WebP(가능하면 AVIF)로 바꿔 줘. 단, 예전 브라우저용으로 JPEG나 PNG 대체 파일도 같이 준비하고 <picture> 태그로 순서대로 고르게 해 줘.

확인하는 법: Lighthouse를 다시 돌려 'Serve images in modern formats'가 사라졌는지 봐요. (Lighthouse는 아낄 수 있는 양이 8KiB 미만인 사진은 목록에 안 보여 줘요.)

막히면:

• iOS 16 미만 아이폰에서는 WebP·AVIF가 안 보여요 (Chrome Lighthouse 문서). 그래서 대체 파일이 꼭 필요해요.
• AVIF는 WebP보다 지원 브라우저가 적어요. 둘 다 두고 JPEG·PNG를 마지막 대체로 두세요.

2. 화면 아래쪽 사진은 내려갈 때 불러오기

한 줄로: 첫 화면에 안 보이는 사진은 손님이 그 근처까지 내려왔을 때 받는 거예요. 원래 용어는 지연 로딩(lazy loading).

왜: 식당에서 코스 요리를 한 번에 다 내오지 않고, 먹는 순서대로 내오는 것과 같아요. web.dev 문서에 따르면 loading="lazy"는 화면 근처에 올 때까지 사진 받기를 미뤄요.

첫 화면 아래에 있는 사진에만 loading="lazy"를 붙여 줘. 첫 화면 맨 위의 큰 사진에는 붙이지 마. 사진마다 width와 height도 적어서 화면이 덜컹거리지 않게 해 줘.

공식 문서의 예시 모양:

<img src="image.png" loading="lazy" alt="…" width="200" height="200">

확인하는 법: 개발자 도구 Network 탭에서 이미지(Img)만 보이게 한 뒤 새로고침 → 아래로 내릴 때 사진 요청이 새로 생기면 성공이에요.

막히면: 첫 화면 사진까지 lazy를 붙이면 오히려 첫 화면이 늦어져요. 맨 위 사진은 빼세요.

3. 파일은 압축해서 보내기

한 줄로: HTML·CSS·JavaScript 같은 글자 파일을 줄여서 보내는 거예요. 원래 용어는 텍스트 압축 (Brotli, GZIP).

왜: 이삿짐을 압축 팩에 넣어 부피를 줄이는 것과 같아요. Chrome Lighthouse 문서는 전송량을 줄이려면 글자 파일을 압축하라고 하고, Brotli가 더 작게 줄이고 GZIP은 그 대체라고 설명해요.

서버(또는 배포 서비스)가 HTML, CSS, JS 파일을 Brotli로 압축해서 보내는지 확인하고, 안 되어 있으면 Brotli를 켜고 지원 안 하는 경우 GZIP으로 보내게 설정해 줘.

확인하는 법: Network 탭에서 JS 파일을 눌러 응답 헤더의 content-encoding이 br 또는 gzip인지 봐요.

막히면: Vercel·Netlify 같은 배포 서비스는 이미 켜져 있는 경우가 많아요. 그럼 이 항목은 '이미 됨'이에요.

4. 안 쓰는 코드 빼기

한 줄로: 받기만 하고 실제로는 안 쓰는 JavaScript를 덜어 내는 거예요.

왜: Chrome Lighthouse 문서 첫 문장이 이거예요. "사용하지 않는 JavaScript를 사용하면 페이지 로드 속도가 느려질 수 있습니다." 렌더링을 막는 스크립트는 다 받아서 읽을 때까지 화면을 못 그리고, 비동기여도 다른 파일과 대역폭을 나눠 써요.

이 프로젝트에서 안 쓰는 라이브러리와 import를 찾아서 지워 줘. 그리고 페이지마다 필요한 코드만 받도록 코드 분할(dynamic import)을 적용해 줘. 지우기 전에 목록부터 보여 줘.

확인하는 법: 개발자 도구 Coverage(적용 범위) 탭에서 빨간 막대(안 쓰는 코드)가 줄었는지 봐요. Lighthouse는 안 쓰는 코드가 20KiB 넘는 파일을 표시해요.

막히면: AI가 '안 쓰는 것 같다'며 필요한 코드까지 지울 수 있어요. 지운 뒤 주요 화면을 꼭 직접 눌러 보세요.

5. 채팅창·광고 같은 바깥 기능은 본 내용 다음에

한 줄로: 다른 회사 코드(채팅 상담, 광고, 분석 도구)는 본 내용이 다 뜬 뒤에 불러오는 거예요. 원래 용어는 서드 파티 스크립트와 async·defer.

왜: 손님이 들어왔는데 전단지부터 나눠 주면 정작 상품을 늦게 봐요. web.dev 문서는 핵심 렌더링 경로에 필요 없는 외부 스크립트에는 async나 defer를 쓰고, 성능이 중요하면 핵심 내용이 뜬 뒤에 추가하라고 해요.

채팅 상담, 광고, 분석 같은 외부 스크립트를 찾아서 본 내용이 다 뜬 다음에 불러오게 바꿔 줘 (async 또는 defer, 또는 페이지 로드 뒤에 추가). 단, 사이트가 돌아가는 데 꼭 필요한 라이브러리는 건드리지 마.

확인하는 법: 페이지 소스에서 외부 <script> 태그에 async나 defer가 붙었는지 보고, 새로고침해서 본 내용이 채팅창·광고보다 먼저 뜨는지 눈으로 확인해요.

막히면: web.dev 문서는 jQuery 같은 필수 라이브러리에는 async를 쓰지 말라고 해요. 결제처럼 꼭 먼저 필요한 것도 미루지 마세요.

6. 검색창은 다 치고 멈추면 찾기

한 줄로: 글자를 칠 때마다 검색하지 않고, 입력이 멈추면 한 번만 찾는 거예요. 원래 용어는 디바운스(debounce).

왜: 엘리베이터가 사람 탈 때마다 출발하지 않고, 잠깐 아무도 안 탈 때 출발하는 것과 같아요. MDN 문서는 입력하는 동안은 아무것도 안 하다가 멈추면 그때 처리해 화면이 버벅이는 걸 막는 예를 들어요.

검색창에 디바운스를 적용해 줘. 입력이 300밀리초 동안 멈추면 그때 한 번만 검색 요청을 보내게 해 줘.

(300밀리초는 흔히 쓰는 출발값이에요. 공식 문서가 정한 숫자는 아니니, 써 보고 조절하세요.)

확인하는 법: Network 탭을 열고 검색어를 빠르게 쳐 보세요. 요청이 글자 수만큼이 아니라 한 번만 생기면 성공.

7. 긴 목록은 보이는 것만 그리기

한 줄로: 목록이 수백·수천 줄이어도 지금 화면에 보이는 줄만 실제로 그리는 거예요. 원래 용어는 목록 가상화(virtualization).

왜: 두꺼운 책을 읽을 때 펼친 두 쪽만 보는 것과 같아요. web.dev 문서는 react-window로 지금 보이는 항목만 그려 렌더링과 스크롤 성능을 높이는 법을 설명해요.

이 긴 목록에 가상화를 적용해 줘. React면 react-window를 써서 화면에 보이는 줄만 그리게 하고, 스크롤해도 높이가 튀지 않게 해 줘.

확인하는 법: 개발자 도구 Elements 탭에서 목록 안의 줄 수가 전체 개수보다 훨씬 적으면 적용된 거예요.

막히면: 목록이 수십 줄 정도면 굳이 안 해도 돼요. 정말 긴 목록에서만 쓰세요.

8. 한 번 받은 파일은 저장해 두기

한 줄로: 사진·글꼴·JS 같은 잘 안 바뀌는 파일을 손님 폰에 저장해 두게 하는 거예요. 원래 용어는 HTTP 캐시.

왜: 단골손님 자리에 미리 물컵을 놓아 두는 것과 같아요. Chrome Lighthouse 문서: "HTTP 캐싱을 사용하면 재방문 시 페이지 로드 시간이 줄어들 수 있습니다."

이미지, 글꼴, 빌드된 JS·CSS 같은 정적 파일에 긴 캐시 기간(Cache-Control)을 설정해 줘. 파일이 바뀌면 이름(해시)이 바뀌어서 새 파일을 받게 해 줘.

확인하는 법: 한 번 연 뒤 새로고침하고 Network 탭의 Size 칸에 (memory cache)나 (disk cache)가 보이면 저장된 거예요.

9. 글씨체 종류는 필요한 것만

한 줄로: 사이트가 받는 웹 글꼴 수와 굵기 수를 줄이는 거예요.

왜: web.dev 문서: "전달 속도가 가장 빠른 글꼴은 요청되지 않은 글꼴입니다." 시스템 글꼴과 가변 글꼴로 받을 글꼴 수를 줄일 수 있대요.

이 사이트가 받는 웹 글꼴과 굵기를 전부 목록으로 보여 줘. 실제로 쓰는 것만 남기고, 가능하면 가변 글꼴 하나나 시스템 글꼴로 바꿔 줘. 글꼴 파일은 WOFF2로 해 줘.

확인하는 법: Network 탭에서 Font만 보이게 하고 새로고침 → 받는 글꼴 파일 수를 세어 봐요.

참고: 원래 31개 목록에는 '글꼴을 직접 올리기(셀프 호스팅)'도 있었는데, 같은 web.dev 문서가 효과가 분명하지 않다고 해서 뺐어요.

10. 자주 찾는 데이터에는 색인

한 줄로: 데이터베이스에서 자주 검색하는 열에 **색인(index)**을 달아 두는 거예요.

왜: 색인은 책 맨 앞 목차 같은 거예요. 처음부터 한 장씩 넘기지 않고 바로 찾아가요. Supabase 문서도 색인을 데이터의 '목차'라고 부르고, 표 전체를 훑지 않고 원하는 줄을 찾게 해 준다고 설명해요.

내 앱에서 자주 쓰는 데이터베이스 조회(검색·필터·정렬)를 찾아서, 색인이 없어서 느린 곳이 있는지 알려 줘. 색인은 꼭 필요한 열에만 추천하고, 추가하는 SQL과 이유를 같이 적어 줘.

확인하는 법: Supabase면 SQL 편집기에서 쿼리 앞에 explain analyze를 붙여 실행 → Seq Scan(전체 훑기)이 Index Scan으로 바뀌었는지 봐요.

막히면: 너무 많이 달면 저장이 느려져요. Supabase 문서: 색인은 쓰기 작업과 저장 공간이 늘어나는 부담이 있어요. 모든 열에 다는 게 가장 흔한 실수예요. 큰 표에 색인을 만들 때는 create index concurrently를 쓰면 만드는 동안 쓰기가 막히지 않아요.

11. 느린 폰·느린 인터넷처럼 만들어 놓고 시험 (꼭)

한 줄로: 내 빠른 컴퓨터가 아니라, 손님의 느린 폰·느린 인터넷처럼 만들어 놓고 앱을 써 보는 거예요. 원래 용어는 스로틀링(throttling).

왜: 내 컴퓨터에서 빠르다고 손님 폰에서도 빠른 건 아니에요. Chrome 개발자 도구 문서에 따르면 설정 > 제한에서 CPU 제한 사전 설정을 저가형·중가형 휴대기기 성능에 가깝게 맞추고, 원하는 네트워크 속도 프로필을 직접 만들 수 있어요.

따라 하기 (공식 문서 순서)

1. 개발자 도구를 열고 톱니바퀴(설정)를 눌러요.
2. 제한(Throttling) > CPU 제한 사전 설정에서 보정 및 계속을 눌러요. 5초쯤 기다리면 저가형·중가형 폰에 가까운 CPU 비율이 나와요.
3. 같은 화면 네트워크 제한 프로필에서 프로필 추가 → 이름, 다운로드·업로드 속도(Kbps), 지연 시간(ms)을 넣고 추가.
4. Network 탭의 제한 목록에서 방금 만든 프로필을 골라 앱을 써 봐요. CPU는 Performance 탭에서 고를 수 있어요.

크롬 개발자 도구에서 CPU와 네트워크를 느리게 설정해서 이 앱을 시험하는 방법을 단계별로 알려 줘. 그리고 그 상태에서 첫 화면, 로그인, 목록 화면이 몇 초 걸리는지 재는 체크 표를 만들어 줘.

막히면: 메뉴 이름은 크롬 버전에 따라 조금 달라요. 'Slow 4G' 같은 이름은 이 공식 문서에 없어서 여기 적지 않았어요. 목록에 보이는 기본 프로필을 쓰거나 직접 만들어 쓰세요.

원래 31개 전체 목록

영상은 해외 릴스(@breakingbreach)의 'AI한테 시킬 속도 개선 31개'를 참고했어요. 그중 초보가 바로 시킬 수 있고 공식 문서로 확인되는 11개만 영상에 남겼어요. 나머지도 한 줄씩 풀어 둘게요. (✅ = 영상 11개에 포함)

체크리스트

• Lighthouse(모바일)로 느린 곳부터 찾았다
• 사진: WebP·AVIF + JPEG·PNG 대체 파일 (iOS 16 미만 대비)
• 첫 화면 아래 사진에만 loading="lazy"
• 글자 파일 압축 (br 또는 gzip)
• 안 쓰는 코드 정리 후 주요 화면 직접 눌러 봄
• 외부 스크립트는 본 내용 다음에 (필수 라이브러리는 제외)
• 검색 디바운스
• 정말 긴 목록만 가상화
• 정적 파일 캐시 기간
• 글꼴 수·굵기 줄이기
• 자주 찾는 열에만 색인 (너무 많이 X)
• 느린 CPU·느린 네트워크로 직접 써 봄

출처 (2026-11-03 확인)

• Chrome Lighthouse: 최신 형식으로 이미지 제공
• web.dev: 브라우저 수준 이미지 지연 로드
• Chrome Lighthouse: 텍스트 압축 사용
• Chrome Lighthouse: 사용하지 않는 자바스크립트 삭제하기
• web.dev: 서드 파티 자바스크립트 로드
• MDN: Debounce
• web.dev: react-window로 대규모 목록 가상화
• Chrome Lighthouse: 효율적인 캐시 정책으로 정적 애셋 제공
• web.dev: 글꼴 권장사항
• Supabase: Managing Indexes in Postgres
• Chrome DevTools: 제한(Throttling)

Chrome·web.dev 문서의 한국어판은 구글 AI 번역 표시가 있는 페이지예요. 문장이 어색하면 영어 원문(주소 끝 ?hl=en)을 같이 보세요.