1. 프로젝트 소개 🎉
🧠 기획 배경
PC 게임은 잘 하지 않지만, 가끔 즐기는 모바일 게임이 하나 있는데 바로 브롤스타즈다.
게임을 하다 보면 ‘내가 어떤 브롤러로 잘하는지’, ‘승률은 어느 정도인지’ 궁금해지는데, 게임 내에서는 승률을 확인할 수 있는 기능이 없었다.
그래서 외부 사이트를 찾아봤지만, UI/UX가 깔끔한 전적 분석 사이트는 많지 않았다.
공식 API도 제공되고 있었고, 무엇보다 브롤러 이미지 등 필요한 asset들도 깔끔하게 제공되다 보니, 시작하게 되었다.
🚀 핵심 기능
- 플레이어 태그 기반 전적 조회
- 브롤러별 승률, 픽률, 스타 플레이어 비율 계산
- 최근 검색 기록 로컬 저장
- 반응형 UI 및 심플한 UX
🎯 타겟 유저
- 브롤스타즈를 즐기며 자신의 실력을 분석하고 싶은 일반 유저
- 전적 기반으로 브롤러 밸런스나 메타를 참고하고 싶은 고수 유저
- 친구 전적을 궁금해하는 라이트 유저
👨🏻💻 팀원 소개
기획, 디자인, 프론트엔드, 백엔드, 배포까지 모두 혼자 진행했다.
📅 작업 기간
약 2주간의 집중 개발 (2025년 4월 초 ~ 4월 중순)
🛠 기술 스택
Next.js 15 (App Router)
TypeScript
Drizzle ORM
React Query
Tailwind CSS
Vercel (배포)
3. 기술적인 도전과 고민
1. 브롤스타즈 전적에서 ‘승리팀’ 판단하기
브롤스타즈의 전적 데이터를 제공하는 battlelog API는 팀으로 진행되는 게임의 경우에는 어느 팀이 승리했는지 정보를 제공하지만,
개인전 모드인 '쇼다운(Showdown)'에서는 단순히 1등부터 10등까지의 순위만 제공할 뿐, 승/패 여부가 명확하게 나오지 않는다.
또한, API 응답은 조회한 유저의 시점에서만 기록이 제공되기 때문에, 게임에 참여한 각 브롤러(캐릭터)의 승패 여부를 직접 계산해서 DB에 저장해야 했다.
이를 위해 다음과 같은 기준을 정의해 승패를 판단했다.
✅ 스타 플레이어가 존재한다면, 그 캐릭터가 속한 팀이 승리
✅ 스타 플레이어가 없다면, 전적 데이터 상 1~4번째에 나오는 캐릭터들이 속한 팀을 승리한 것으로 간주
이 기준은 실제 게임 상황과 거의 일치하는 결과를 제공했고, 분석 정확도를 높이기 위해 다양한 전적 데이터를 수동으로 확인하며 검증했다.
2. 무한스크롤 적용
브롤스타즈의 전적(battlelog) 데이터를 다루다 보니,
유저마다 많게는 수백 개의 전적이 존재했다.
한 번에 다 불러오는 건 비효율적이라, 무한스크롤 방식을 도입하기로 했다.
이를 위해 React Query의 useInfiniteQuery를 활용했다.
첫 로딩 시에는 서버에서 받아온 initialData를 넣어주고
이후에는 클라이언트 측에서 스크롤 이벤트에 따라 추가 호출되도록 설계했다.
이 방식 덕분에 초기 로딩 속도는 빨라지고,
스크롤할수록 자연스럽게 더 많은 전적이 로드되는 사용자 경험을 구현할 수 있었다. 🚀
3. 브롤러 승률 계산 방식 개선기
메인 페이지에는 승률이 가장 높은 브롤러 TOP 10을 보여주는 기능이 있다.
처음에는 이 데이터를 API에서 실시간으로 계산해서 가져오는 방식으로 구현했다.
하지만 사용자 수와 전적 데이터가 많아지면서
점점 API 응답 속도가 느려지는 문제가 발생하기 시작했다.
이에 대응해, revalidate 옵션을 적용해 5분마다 데이터를 새로 고치는 방식으로 개선했다.
그런데 이번엔 뜻밖의 문제가 터졌다 —
바로 Vercel 빌드 타임에 함수 실행 시간이 초과되어 배포 자체가 실패하는 상황.
실시간 계산 구조는 결국 한계가 있다고 판단했다.
그래서 최종적으로 구조를 다음과 같이 변경했다
유저의 전적을 저장할 때마다
→ 해당 브롤러의 픽률, 승률, 스타 플레이어 비율을 미리 계산해 누적 저장
메인 페이지에서는 이 집계 테이블만 조회
이 방식으로 변경하고 나서는
메인 페이지 로딩 성능이 평균 10초 이상 개선되었다.
4. 프록시 서버 만들기
처음에는 "Vercel에만 배포하면 끝이겠지!"라고 생각했지만, 곧 예상치 못한 문제가 발생했다.
브롤스타즈 공식 API는 '허용된 IP 주소에서만 접근 가능'하도록 제한되어 있었고,
Vercel은 서버리스 환경이라 IP가 고정되지 않아 API 호출이 차단되었다.
이를 해결하기 위해, AWS EC2 인스턴스를 생성해 프록시 서버로 활용하는 구조로 변경했다.
모든 브롤스타즈 API 요청은 프론트엔드 → 프록시 서버(EC2) → 브롤스타즈 API 순으로 전달 되도록 수정했다.
5. GPTBot 때문에 418 에러?!
추가기능을 배포하려고 했는데, 빌드 타임에 이상한 에러가 발생했다.
에러 코드는 무려 418 I'm a teapot!
살면서 처음 보는 에러라 당황했는데, 찾아보니 브롤스타즈 API를 너무 빠르게 호출할 때 발생할 수 있다는 글이 있었다.
"아직 사용하는 사람도 별로 없는데 왜?" 하고 의문이 들어
Vercel 로그를 확인해보니, 1초마다 계속해서 내 서버로 요청이 들어오고 있었다.
유저 에이전트를 확인해보니 다음과 같았다
Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; GPTBot/1.2; +https://openai.com/gptbot)GPTBot...?
찾아보니 OpenAI에서 웹 크롤링용으로 사용하는 봇이었다.
이전엔 이런 적이 없어서 당황했지만 다행히 Vercel의 Firewall 기능을 발견했다.
Vercel Firewall에서는 User-Agent 기준으로 요청을 차단할 수 있는 기능을 제공한다.
덕분에 GPTBot User-Agent를 기준으로 차단 설정을 추가했고,
이후 더 이상 이상한 요청이 들어오지 않아서 무사히 문제를 해결할 수 있었다. 😮💨
6. GA, GTM 연결로 스크래치 기능 사용자 행동 추적하기
처음엔 단순히 전적 조회 기능만 제공했지만,
추가로 스크래치 기능(랜덤 브롤러 추첨)을 넣으면서
“사용자들이 이 기능을 얼마나 자주 사용할까?” 하는 궁금증이 생겼다.
그래서 사용자 행동을 트래킹하기 위해
Google Analytics (GA)와 Google Tag Manager (GTM)를 연결했다.
공식 문서를 참고하니 @next/third-parties/google 패키지를 활용하면 좋다고 해서, 이걸 사용해 깔끔하게 연동할 수 있었다.
현재는 스크래치 시작, 결과 확인, 다시 하기 클릭 등의 이벤트가
GA에 잘 쌓이고 있으며, 추후 출시될 기능에도 동일한 방식으로 연결할 예정이다.
무엇보다 클릭 수가 많지 않다면 기능 제거에 대한 객관적인 판단 근거가 생기기 때문에
데이터 기반으로 의사결정을 할 수 있어 이번 기획에서 큰 도움이 되고 있다.
