Vercel Analytics와 Speed Insights 붙이기
이전까지 KAU Notice Hub는 “잘 동작하는 서비스”에 가까워지는 과정이었다.
SQLite 전환으로 OOM 문제를 줄였고, 부하 테스트를 통해 서버가 어느 정도 요청을 버틸 수 있는지도 확인했다.
RAG 평가를 통해 챗봇 답변 품질도 수치로 확인했고, 홍보 전 보안 점검을 하면서 Rate Limit, 요청 본문 크기 제한, OpenAI 출력 토큰 제한 같은 운영 리스크도 정리했다.
이제 남은 질문은 조금 달랐다.
“사람들이 실제로 잘 쓰고 있을까?”
“어떻게 쓰고 있을까?”
“어떤 페이지를 많이 볼까?”
“우리 서비스에 사용자가 조금 몰리면 느려지지 않을까?”
“성능은 어떻게 모니터링 하지?”
기능을 만들고, 보안 점검까지 마쳤다면 그다음은 운영 상태를 볼 수 있어야 한다고 생각했다.
그래서 Vercel Analytics와 Speed Insights를 붙여 웹 서비스의 사용량과 성능을 수치로 모니터링할 수 있는 환경을 만들었다.
왜 모니터링이 필요했나?
처음에는 주변 사람들에게 조금씩 공유하면서 피드백을 받았다.
“공지 검색이 편하다”, “챗봇이 생각보다 유용하다” 같은 반응을 들을 수 있었고, 서비스 방향성에 대한 확신도 조금 생겼다.
하지만 이런 피드백만으로는 운영 상태를 정확히 알기 어렵다.
사용자가 실제로 몇 명이나 들어오는지, 어떤 페이지에서 많이 머무는지, 모바일과 데스크톱 중 어디서 더 많이 사용하는지, 페이지 로딩이 느리지는 않은지 같은 정보는 감으로 알 수 없다.
특히 KAU Notice Hub는 학교 공지를 빠르게 찾는 것이 핵심인 서비스다.
아무리 기능이 좋아도 페이지가 느리거나, 사용자가 원하는 공지까지 가는 과정이 불편하면 실제 사용성은 떨어질 수밖에 없다.
그래서 단순히 “잘 되는 것 같다”가 아니라, 실제 데이터를 보면서 운영할 수 있는 환경이 필요했다.
Vercel Analytics 붙이기
먼저 Vercel Analytics를 붙였다.
이는 지난번 WeBand(일정 조율 웹사이트)를 운영하며 사용해본 서비스이기에 익숙했다.
Vercel Analytics 다음과 같은 것을 수치화해서 보여줄 수 있다.
- 방문자가 얼마나 들어오는지
- 어떤 페이지가 많이 조회되는지
- 사용자가 어떤 경로로 들어오는지
- 모바일과 데스크톱 중 어디서 더 많이 사용하는지
이런 데이터가 있으면 단순히 방문자 수를 보는 것에서 끝나지 않고, 서비스 개선 방향을 잡는 데도 도움이 된다.
예를 들어 공지 상세 페이지 조회가 많다면 사용자가 실제로 공지를 탐색하고 있다는 의미일 수 있다.
반대로 메인 페이지 방문은 있는데 상세 페이지나 챗봇 사용으로 이어지지 않는다면, 사용 흐름이나 UI를 다시 봐야 할 수도 있다.
아직 데이터가 많지는 않지만, 이제는 “느낌”이 아니라 숫자로 사용 흐름을 확인할 수 있게 되었다.
Speed Insights 붙이기
다음으로 Speed Insights를 붙였다.
Analytics가 “얼마나 사용되는가”를 보는 도구라면, Speed Insights는 성능을 보기 위한 도구에 가깝다.
KAU Notice Hub는 공지 목록, 검색, 상세 조회처럼 사용자가 빠르게 이동해야 하는 화면이 많다.
특히 모바일에서 학교 공지를 확인하는 사용자가 많을 수 있기 때문에, 실제 사용자 환경에서 페이지가 느리게 뜨지는 않는지 확인할 필요가 있었다.
Speed Insights를 통해 Core Web Vitals 기반의 성능 지표를 확인할 수 있다.
대표적으로 페이지 로딩 속도, 사용자 상호작용 반응성, 레이아웃이 갑자기 흔들리는지 같은 지표를 볼 수 있다.
"내가 써봤는데 괜찮았어." 라는 것으로 모든 것을 판단할 순 없다.
실제 사용자는 각자 다른 기기, 다른 네트워크 환경에서 접속한다.
그래서 실제 사용자 기준으로 성능 문제가 발생하는지 모니터링이 필요한 것이다.
Vercel Analytics와 Speed Insights를 붙이는 작업 자체는 어렵지 않았다.
Vercel에 붙어있는 Agent를 통해 관련 코드를 내 코드베이스에 추가하고 PR까지 자동으로 생성해준다.
나는 Merge만 해주었고 그렇게 세팅은 끝났다. (라떼는 직접 했었는데 세상 참 좋아졌다..)
앞으로 확인할 것들
이번에 모니터링 환경을 붙이면서 앞으로 확인하고 싶은 지표도 생겼다.
먼저 방문자 수와 페이지 조회 흐름을 확인할 예정이다.
홍보 이후 실제로 얼마나 많은 사용자가 들어오는지, 방문자가 늘어났을 때도 현재 성능이 유지되는지 보고 싶었다.
또한 사용자가 어떤 기능을 주로 사용하는지도 확인해보고 싶다.
KAU Notice Hub에는 챗봇을 통한 공지 탐색, 필터링 기반 탐색, 검색 기반 탐색이 함께 들어가 있다.
이 중 어떤 방식이 실제 사용자에게 가장 많이 쓰이는지 확인하면, 이후 어떤 기능을 더 개선해야 할지 판단하는 데 도움이 될 것이라고 생각했다.
비용도 함께 봐야 한다.
특히 챗봇 기능은 OpenAI API 호출과 연결되어 있기 때문에, 사용량이 늘어나면 비용도 함께 증가할 수 있다.
현재는 비용을 최소화하기 위해 작은 서버 인스턴스를 사용하고 있기 때문에, 실제 사용자 수와 트래픽을 보면서 서버 인스턴스 확장이나 Load Balancer 도입이 필요한 시점인지 판단할 계획이다.
성능 측면에서는 모바일 환경을 특히 신경 쓰려고 한다.
학교 공지는 PC보다 모바일로 빠르게 확인하는 경우가 많을 수 있기 때문이다.
Speed Insights에서 성능 지표가 나빠진다면, 어떤 페이지에서 문제가 생기는지 확인하고 이미지 최적화, 렌더링 구조, API 호출 방식 등을 다시 점검할 계획이다.
결국 이번 모니터링 환경 구축의 목적은 단순히 방문자 수를 보기 위한 것이 아니다.
사용량, 비용, 성능 데이터를 함께 보면서 지금 구조로 계속 운영해도 되는지, 어느 시점에 확장이 필요한지 판단하기 위한 기반을 만드는 것이었다.
마무리
이번 작업은 새로운 기능을 추가한 것은 아니다.
하지만 서비스를 공개적으로 운영하기 위해서는 기능만큼이나 중요한 작업이었다고 생각한다.
KAU Notice Hub는 이제 단순히 “동작하는 웹 서비스”에서 조금씩 “운영할 수 있는 웹 서비스”에 가까워지고 있다.
아직 완벽한 서비스라고 말하기는 어렵다.
하지만 적어도 이제는 문제가 생겼을 때 감으로 추측하는 것이 아니라, 데이터를 보고 개선할 수 있는 출발점이 생겼다.
현재 프로젝트에는 아직 개선하고 확장할 부분이 많다.
Redis를 활용한 캐싱, Elasticsearch를 통한 검색 성능 개선, Vector DB 기반의 챗봇 검색 품질 향상처럼 해보고 싶은 작업들이 남아 있다.
다만 이런 기술을 무작정 붙이기보다는, 실제 사용 데이터를 보고 우선순위를 정하고 싶었다.
사용자가 어떤 기능을 많이 쓰는지, 어느 페이지에서 성능이 떨어지는지, 현재 서버 구조로 어느 정도 트래픽까지 감당할 수 있는지를 먼저 확인해야 한다고 생각했다.
이번에 Vercel Analytics와 Speed Insights를 붙인 것도 그 이유다.
단순히 방문자 수를 보기 위한 것이 아니라, 앞으로 어떤 부분을 먼저 개선하고 확장해야 할지 판단하기 위한 운영 데이터 기반을 만들고 싶었다.
챗봇 사용 기록과 사용자 데이터가 어느 정도 쌓이면, 2학기에는 이를 바탕으로 개선 및 확장 계획을 구체화할 예정이다.
인턴 지원, 공모전, 대회까지 이것저것 일을 너무 많이 벌려둔 상태이기 때문에 당분간은 무리하게 확장하기보다, 서비스가 안정적으로 운영되는지 지켜보면서 학기 전까지는 유지 및 보수만 할 생각이다.
이만........
'고민의 흔적.. > KAU-Notice-Hub' 카테고리의 다른 글
| 정말 배포하고 홍보해도 될까? (운영 리스크 점검) (0) | 2026.06.28 |
|---|---|
| 너가 만든 RAG 얼마나 잘되는데? (RAG 성능을 평가해보자!) (0) | 2026.06.20 |
| RAG, 꼭 벡터로 해야돼?? (키워드 기반 RAG 구현에 대한 고찰) (0) | 2026.05.29 |
| 안정적으로 인프라를 구축해보자! (0) | 2026.05.23 |
