AI로 만든 앱이 화제가 됐습니다. 트래픽 폭주를 견딜 수 있을까요?

나쁜 하루의 좋은 버전을 떠올려 보세요. AI로 만든 앱을 당신이 속한 커뮤니티에 올렸거나, 팔로워가 많은 누군가가 써 보고 공유했거나, 직접 올리지도 않았는데 어느 포럼 첫 화면에 떴습니다. 그러자 익숙하던 방문자의 가느다란 흐름이 갑자기 홍수로 바뀝니다. 천 명이, 같은 시간에, 여기저기 클릭하고 있습니다.

바로 이 순간을 위해 그 앱을 만든 것이죠. 그런데 이 순간은 수많은 AI로 만든 앱이 조용히 무너지는 순간이기도 합니다 — 느려진 페이지, 빙글빙글 도는 로딩, 제출되지 않는 가입 폼. 어렵게 찾아온 사람들이 벽에 부딪혀 떠나고, 그들 대부분은 다시 시도하러 돌아오지 않습니다.

좋은 소식이 있습니다. 트래픽 폭주를 견디는 일은 대개 폭주가 일어나기 전에 내릴 수 있는 몇 가지 따분한 결정에 달려 있습니다. 엔지니어가 될 필요는 없습니다. 어떤 모서리를 잘라 내면 안 되는지만 알면 됩니다.

트래픽이 치솟을 때 실제로 무엇이 망가지나

평소의 백 배에 달하는 사람들이 한꺼번에 앱을 쓰면, 무작위로 망가지지 않습니다. 예측 가능한 순서대로 망가지고, 거의 늘 같은 세 곳에서 망가집니다.

데이터베이스가 과부하에 걸립니다. 누군가 페이지를 열 때마다 앱은 보통 데이터베이스에 질문을 던집니다. “이 사용자의 데이터가 뭐지?” 한 사람이 묻는 건 아무것도 아닙니다. 하지만 천 명이 같은 분에 같은 질문을 던지면, 데이터베이스가 답하는 속도보다 빠르게 쌓일 수 있고, 모두의 페이지가 기어가듯 느려집니다.

앱 바깥의 무언가가 느려집니다. 대부분의 AI로 만든 앱은 다른 서비스에 기댑니다 — 이메일 발송, 결제 처리, AI 모델 호출. 이런 서비스는 흔히 얼마나 빠르게 호출할 수 있는지를 제한합니다. 평소 트래픽에서는 그 한계를 전혀 느끼지 못합니다. 그러나 폭주 상황에서는 앱이 그 한계에 부딪히고, 그 서비스를 건드리는 모든 동작이 갑자기 멈춥니다.

앱이 같은 무거운 작업을 반복하고 또 반복합니다. 누군가 방문할 때마다 홈페이지가 매번 무거운 계산을 돌린다면 — 목록을 가져와 순위를 매기고 형식을 잡는다면 — 방문자 열 명에게는 괜찮지만 천 명에게는 가혹합니다. 그 작업은 처음부터 낭비였습니다. 낮은 트래픽이 그걸 가려 줬을 뿐입니다.

패턴이 보이시나요. 이 중 어느 것도 새로 생긴 버그가 아닙니다. 폭주가 무언가를 망가뜨린 게 아닙니다. 낮은 트래픽 아래 조용히 자리 잡고 있던 약점을 드러냈을 뿐입니다.

가장 값싼 해법: 변하지 않는 것은 캐싱하라

캐싱은 기술적으로 들리지만 개념은 단순합니다. 어떤 질문의 답이 모두에게 똑같고 거의 변하지 않는다면, 방문자마다 그 작업을 다시 하는 대신 한 번만 계산해 두고 재사용하는 것입니다.

홈페이지는 아마 1,000명 모두에게 똑같이 보일 겁니다. 그런데 왜 데이터베이스에게 그걸 1,000번이나 다시 만들라고 시킬까요? 한 번 만들어서 그 결과를 몇 분간 저장해 두고, 그 저장본을 모두에게 보여 주세요. 방금 비싼 데이터베이스 왕복 천 번을 한 번으로 바꿨습니다.

AI 빌더에게 바로 그렇게 말하세요. “방문할 때마다 데이터베이스를 치지 않도록 홈페이지와 공개 상품 목록을 5분간 캐싱해 줘.” 모두에게 똑같고 초 단위로 최신일 필요가 없는 것이라면 무엇이든 — 가격 페이지, 공개 목록, 블로그 인덱스 — 캐싱 후보입니다. 개인화된 것(누군가의 개인 대시보드, 계정 설정)은 같은 방식으로 캐싱할 수 없지만, 그건 보통 폭주 중 트래픽의 작은 조각에 불과합니다. 대부분의 사람은 똑같은 몇 개의 공개 페이지를 보고 있습니다.

나중에 해도 되는 일을 사람들이 기다리게 하지 마라

저지르기 쉽고 고치기도 쉬운 실수가 하나 있습니다. 누군가 가입하면 앱이 환영 이메일을 보낸다고 합시다. 만약 앱이 이메일이 완전히 발송될 때까지 가입 페이지에서 기다리게 한다면, 느린 이메일 서비스가 가입을 느리게 만듭니다 — 정확히 가장 많은 사람이 가입하는 그 순간에요.

해법은 느린 일은 백그라운드에서 일어나게 두는 것입니다. 사용자는 즉시 “가입 완료!”를 보고, 이메일은 아무도 기다리지 않는 사이 몇 초 뒤에 나갑니다. 결과는 같지만, 방문자는 세 회사 건너 어딘가의 이메일 서버가 느긋하게 일하는 동안 로딩만 바라보고 있지 않아도 됩니다.

빌더에게 이렇게 요청하세요. “가입이 환영 이메일을 기다리지 않도록 이메일은 백그라운드에서 보내 줘.” 사용자가 계속 진행하기 전에 끝날 필요가 없는 무엇에든 같은 논리가 적용됩니다 — 리포트 생성, 다른 도구로 동기화, 알림 발송. 사용자가 그 결과를 지금 당장 필요로 하지 않는다면, 기다리게 하지 마세요.

”사람이 너무 많을 때”를 위한 계획을 세워라

때로는 폭주가 당신이 준비한 그 무엇보다도 커서, 솔직한 선택은 무너지는 대신 우아하게 성능을 낮추는 것입니다. 그래도 작동하는 느린 앱이 망가진 앱보다 낫습니다.

이걸 위한 간단한 몇 가지 방법입니다.

• 친절한 대기 메시지. 정말로 과부하가 걸렸다면, 빈 화면이나 날것의 에러 대신 “지금 방문자가 많습니다 — 잠시만 기다려 주세요”를 보여 주는 편이 훨씬 낫습니다. 사람들은 바쁜 앱은 용서합니다. 망가진 앱은 용서하지 않습니다.
• 가장 무거운 기능을 잠시 끄세요. 한 기능이 비싼 기능이라면 — 가령 클릭마다 실제 돈과 시간이 드는 AI 생성 기능 — 폭주 중에는 그걸 숨기고 나머지 앱을 빠르게 유지할 수 있습니다. 폭주 중 방문자 대부분은 어차피 가장 부담스러운 기능을 쓰는 게 아니라 둘러보고 있습니다.
• 요금이 어디서 나오는지 파악하세요. 앱이 방문할 때마다 유료 AI 모델을 호출한다면, 방문자 천 명은 느려진 페이지만이 아니라 예상치 못한 청구서를 뜻할 수 있습니다. 어떤 동작에 돈이 드는지 알면 무엇을 미리 제한할지 결정할 수 있습니다.

30분짜리 리허설

약점을 찾는 데 거창한 도구는 필요 없습니다. 친구 몇 명과 30분이면 됩니다.

다섯이나 여섯 명에게 같은 순간에 앱을 열어 몇 분간 빡세게 클릭해 달라고 부탁하세요 — 가입하고, 핵심 기능을 쓰고, 붐비는 페이지를 열어 보게요. 투박하지만 뻔한 문제는 빠르게 드러냅니다. 여섯 명이 두드리는데도 이미 굼떠진다면, 천 명은 그걸 납작하게 만들 겁니다. 여섯 명에도 쌩쌩하다면, 적어도 낮은 문턱은 넘은 셈입니다.

사람들이 클릭하는 동안, 어느 페이지가 가장 느리게 느껴지는지 지켜보세요. 그 느린 페이지가 바로 진짜 트래픽 폭주가 가장 아프게 때릴 곳이고, 가장 먼저 캐싱하거나 단순화할 가치가 있는 곳입니다. 천 명의 사용자를 흉내 내려는 게 아닙니다. 여섯 명에도 이미 버거워하는 그 한 페이지를 찾으려는 것입니다.

진짜 목표

앱을 무한정 철벽으로 만들 수는 없고, 그럴 필요도 없습니다. 목표는 첫 입소문 순간에 만 명을 흠 하나 없이 처리하는 게 아닙니다. 어렵게 모은 수백 명 앞에서 망신당하지 않는 것입니다 — 그토록 애써 끌어들인 사람들이 빙글빙글 도는 로딩 대신 작동하는 앱을 만나게 하는 것이죠.

변하지 않는 페이지는 캐싱하세요. 느린 일은 백그라운드로 옮기세요. “사람이 너무 많을 때”를 위한 계획을 세우세요. 필요해지기 전에 친구 다섯 명과 리허설을 하세요. 그중 어느 것도 직접 코드를 쓸 필요는 없습니다 — AI 빌더에게 무엇을 요청해야 하는지만 알면 됩니다.

그러면 당신의 순간이 왔을 때, 미친 듯이 디버깅하는 대신 그 순간을 즐길 수 있습니다. 그러니 이번 주에 곱씹어 볼 만한 질문은 이것입니다. 내일 천 명이 몰려온다면, 어느 페이지가 가장 먼저 망가질까 — 그리고 당신은 이미 그 답을 알고 있나요?