AI로 만든 앱이 느리게 느껴지는 이유 (그리고 어떻게 할 것인가)

AI로 만든 앱이 작동합니다. 버튼은 가야 할 곳으로 가고, 화면은 줄이 맞고, 데이터는 저장됩니다. 그런데 뭔가 미묘하게 거슬립니다. 페이지가 로드되는 데 한 박자 너무 오래 걸립니다. 항목 쉰 개짜리 목록이 잠깐 멈칫합니다. “저장”을 누르면 기다리게 하고, 또 조금 더 기다리게 하고, 다시 눌러야 하나 싶게 만듭니다. 고장 난 건 없습니다 — 그냥 느리게 느껴질 뿐이죠.

AI 앱 빌더로 출시하는 비개발자 창업가라면, 이건 가장 흔한 “뭐가 잘못됐는지 모르겠는” 순간 중 하나입니다. 좋은 소식은 느린 AI로 만든 앱의 80%가 똑같은 몇 가지 이유로 느리다는 겁니다. 그중 어느 것도 데이터베이스가 어떻게 돌아가는지 배우라고 요구하지 않습니다. 모두 평소 말로 AI 빌더에게 요청할 수 있는 해결책이 있고요.

이 글이 그 치트시트입니다.

”느림”은 보통 네 가지다

사용자가 앱이 느리다고 할 때, 그들은 거의 절대 “서버 성능이 부족하다”는 뜻이 아닙니다. 다음 넷 중 하나를 뜻하죠:

첫 화면이 뜨는 게 느리다 — 링크를 클릭하고 빈 화면을 2초 동안 보다가 뭔가가 나타납니다.
긴 목록이 굼뜨다 — 스크롤, 필터링, 또는 “내 모든 프로젝트” 불러오기가 인스타그램 스크롤보다 오래 걸립니다.
어떤 동작이 무슨 일이 일어나는지 알려 주지도 않고 너무 오래 걸린다 — “저장”이나 “보내기”를 눌렀는데 눈에 보이는 반응이 없습니다.
데이터베이스에 너무 많은 질문을 던진다 — 여러 곳의 데이터를 보여 주는 페이지가 각 조각을 따로따로 가져와 대기 시간을 쌓습니다.

그게 전부입니다. 제가 본 느린 AI로 만든 앱은 거의 다 이 네 가지 중 하나로 느립니다. 각각을 어떻게 알아채고 빌더에게 무엇을 요청할지 알려 드리겠습니다.

느린 이유 1번: 첫 화면 그리기

어떻게 보이는가: 앱 링크를 클릭하면, URL 바는 로딩을 끝냈는데, 페이지는 1~2초 동안 하얗다가 그제야 뭔가가 나타납니다.

보통 무엇이 원인인가: 앱이 무언가를 보여 주기 전에 필요할 법한 모든 JavaScript 조각을 먼저 불러오고 있습니다. AI 앱 빌더는 넉넉하게 묶는 경향이 있고 — 빠뜨리느니 넣는 게 낫다는 식이죠 — 기능을 추가할수록 그 묶음은 커집니다.

AI 빌더에게 무엇을 요청할까: “첫 페이지 로드가 느리게 느껴져. 홈페이지가 관리자 섹션 전체를 내려받지 않아도 되게 JavaScript 번들을 라우트별로 나눠 줄 수 있어?” 아니면 더 간단하게: “홈페이지가 아닌 라우트에 지연 로딩을 추가해 줘.” 대부분의 최신 프레임워크는 이걸 설정 한두 줄로 지원합니다. AI는 방법을 압니다 — 당신은 요청만 하면 됩니다.

이왕 하는 김에: “랜딩 페이지에 최적화할 수 있는 큰 이미지가 있어?” 4MB짜리 히어로 사진은 어떤 코드 문제보다도 체감 속도를 더 끌어내립니다.

느린 이유 2번: 긴 목록

어떻게 보이는가: 목록이 있습니다 — 프로젝트, 연락처, 게시물, 무엇이든 — 그런데 마흔이나 쉰 항목을 넘기면 스크롤이 버벅이거나 필터링이 눈에 띄게 멈칫합니다.

보통 무엇이 원인인가: 앱이 보이지 않는 것까지 포함해 모든 항목을 한꺼번에 페이지에 렌더링하고 있습니다. 열 개라면 괜찮습니다. 오백 개라면 브라우저가 질식합니다.

AI 빌더에게 무엇을 요청할까: “항목이 많을 때 프로젝트 목록이 느려. 페이지네이션을 추가하거나, 보이는 행만 렌더링되게 목록을 가상화할 수 있어?” 페이지네이션(“페이지당 20개씩, 이전/다음 버튼과 함께”)이 가장 쉬운 해결책입니다. 가상화(“사용자가 스크롤할 때 화면에 있는 것만 렌더링”)는 더 매끄럽게 느껴지지만 조금 더 손이 갑니다. 어느 쪽이든 괜찮습니다.

목록에 검색이나 필터링도 있다면: “검색 필터를 브라우저가 아니라 서버에서 하게 할 수 있어?” 서버 측 필터링은 브라우저가 전체 데이터가 아니라 일치하는 행만 들고 있게 한다는 뜻입니다.

느린 이유 3번: 조용한 대기

어떻게 보이는가: “저장”이나 “보내기”나 “생성”을 누릅니다. 눈에 보이는 일은 아무것도 없습니다. 2초 뒤 화면이 갱신되고, 그제야 내내 작동하고 있었다는 걸 깨닫습니다.

보통 무엇이 원인인가: 앱은 실제로 일을 하고 있습니다 — 데이터베이스에 저장하고, API를 호출하고 — 그런데 AI 빌더가 로딩 상태를 추가하지 않았습니다. 그래서 당신 입장에서는 클릭이 아무 일도 안 한 것처럼 보입니다.

이건 사실 성능 문제가 아닙니다. 체감 성능 문제이고, 그런 건 종종 진짜 문제보다 더 아픕니다. 피드백 없는 200밀리초짜리 동작이 스피너 있는 2초짜리 동작보다 느리게 느껴집니다. 사용자의 뇌가 깜깜한 상태에 놓이니까요.

AI 빌더에게 무엇을 요청할까: “동작을 일으키는 모든 버튼에 로딩 상태를 추가해 줘. 작동하는 동안 스피너나 ‘저장 중…’ 텍스트를 보여 주고, 사용자가 두 번 누르지 못하게 버튼을 비활성화해 줘.” 이건 어떤 앱에서도 투자 대비 효과가 가장 높은 성능 개선이고, 비용은 거의 들지 않습니다.

이왕 하는 김에: “결과가 무엇일지 우리가 아는 동작에 대해서는, UI를 낙관적으로 갱신할 수 있어? 변경을 즉시 보여 주고, 서버가 거부하면 되돌리는 식으로.” 낙관적 갱신은 휴대폰 수신 상태가 끔찍할 때조차 소셜 앱의 “좋아요” 버튼이 즉각적으로 느껴지는 이유입니다.

느린 이유 4번: 수다스러운 데이터베이스

어떻게 보이는가: 각 항목마다 추가 정보가 붙은 목록을 보여 주는 페이지 — 가령 각 프로젝트의 작업 개수가 함께 나오는 프로젝트 목록 — 이 평범한 목록보다 훨씬 오래 걸립니다.

보통 무엇이 원인인가: 페이지가 프로젝트를 한 쿼리로 불러온 다음, 각 프로젝트의 작업 개수를 별도의 쿼리로 불러옵니다. 프로젝트 열 개? 쿼리 열한 개. 백 개? 백한 개. 이걸 “N+1 쿼리”라고 부르며, AI로 만든 앱에서 가장 흔한 데이터베이스 성능 버그입니다. AI가 효율적으로 돌아가는 코드가 아니라 명확하게 읽히는 코드를 최적화하기 때문이죠.

AI 빌더에게 무엇을 요청할까: “이 페이지가 항목마다 쿼리를 하나씩 하고 있어. 관련 데이터를 전부 한 쿼리로 — 조인이나 집계로 — 가져올 수 있어?” 두 단어가 무슨 뜻인지 알 필요는 없습니다. AI는 압니다. 느린 페이지를 보여 주며 “이거 N+1 문제가 있는 것 같아”라고 말하는 것만으로 보통 충분합니다.

도구 없이도 N+1 문제를 알아챌 수 있습니다: 페이지를 열고, 시간이 얼마나 걸리는지 재고, 그 밑의 목록에 항목을 열 배로 추가하세요. 페이지가 이제 열 배 느려졌다면, N+1입니다. 아주 조금만 느려졌다면, 아닙니다.

조급한 최적화에 관한 한마디

새내기 빌더가 빠지는 함정: 아무도 앱을 쓰기 전에 모든 페이지를 빠르게 만들려는 것. 그러지 마세요.

성능 작업에는 실제 비용이 듭니다. 영원히 스무 행만 가질 목록에 페이지네이션을 추가하는 건 낭비입니다. 하루에 두 번 로드되는 페이지를 최적화하는 건 낭비입니다. 사용자 세 명짜리 내부 도구의 번들을 나누는 건 낭비입니다. 느린 페이지를 고칠 적기는, 그 페이지와 동작과 그것 때문에 짜증 난 사람을 이름 댈 수 있을 때입니다.

그러니 일단 평범하게 만드세요. 출시하세요. 어떻게 쓰이는지 지켜보세요. 진짜 사람 — 당신 자신을 포함해 — 에게 무언가 느리게 느껴지면, 그 증상을 위 네 가지 범주 중 하나에 맞추고 그 구체적인 해결책을 요청하세요. 사용자가 절대 알아채지 못할 인프라에 일주일을 쓰지 않고도 더 빠른 앱을 얻게 됩니다.

속도에 대해 AI 빌더와 대화하는 법

통하는 패턴: 해결책이 아니라 증상을 설명하세요. AI는 무엇이 실제로 잘못됐는지만 알면, 당신이 기대하는 것보다 훨씬 잘 알맞은 해결책을 고릅니다.

복사해 쓸 좋은 프롬프트:

“설정 페이지를 열면 뭔가 나타나기까지 1초 지연이 있어. 무엇이 첫 렌더링을 막고 있는지 알아봐 줄 수 있어?”
“대시보드가 홈페이지보다 데이터를 적게 보여 주는데도 더 오래 걸려. 데이터를 어떻게 가져오는지 살펴봐 줄 수 있어?”
“프로필 페이지에서 ‘변경 사항 저장’을 누르면 2초 동안 아무 일도 안 일어나. 로딩 상태를 추가하고 버튼이 두 번 눌리지 않게 해 줘.”
“이 목록을 가짜 항목 500개로 테스트하고 어디가 느려지는지 알려 줘.”

마지막 것은 저평가되어 있습니다. AI에게 테스트 데이터를 생성해 직접 페이지를 시험해 보라고 하는 건 당신이 할 수 있는 가장 유용한 일 중 하나입니다. 사용자가 발견하기 전에 AI가 느린 지점을 종종 찾아내고 — 같은 답변에서 해결책까지 제안합니다.

AI로 만든 앱의 속도는 마법이 아닙니다. 당신의 문제가 네 가지 양동이 중 어디에 떨어지는지 알고, 알맞은 해결책을 명확한 말로 요청하는 일입니다. 그렇게 하면 “느리게 느껴짐”이 — 재작성이 아니라 — 작고 겨냥된 변경 몇 가지로 “괜찮게 느껴짐”이 됩니다.