서버가 아니라 사용자가 보는 화면에서 품질을 측정합니다.
MAXY Web은 실제 사용자의 브라우저에서 발생하는 성능 저하와 오류, 그리고 사용자의 행위 데이터를 실시간으로 수집·분석하는 프론트엔드 모니터링(RUM) 솔루션입니다. 사용자의 조작 과정을 그대로 재현하고, 제니퍼소프트 APM과 연동하면 체감 지연이 API 응답 대기에서 생겼는지 WAS 처리에서 생겼는지를 한 화면에서 나눠 봅니다.
다음 중 하나라도 해당한다면 MAXY Web이 필요한 시점입니다.
체감 성능을 숫자로, 조작을 화면으로, 병목을 구간으로.
FeelDex와 Core Web Vitals
응답 시간이 몇 초인지보다 중요한 것은 사용자가 그것을 어떻게 느끼는지입니다. MAXY Web은 Google Core Web Vitals(LCP·INP·CLS)를 기반으로 복잡한 성능 데이터를 FeelDex라는 단일 체감 지수로 변환합니다.
여러 지표를 따로 해석하지 않고 하나의 숫자로 품질 저하를 감지하고, 어느 항목이 지수를 끌어내리고 있는지가 함께 표시되므로 무엇을 먼저 개선할지 정할 수 있습니다. 성능 개선 과제를 조직에 설명할 때 쓸 수 있는 공통 언어이기도 합니다.
사용자의 조작을 그대로 재현
사용자가 어떤 순서와 방법으로 화면을 사용했는지를 그대로 되짚어 볼 수 있습니다. 어떤 화면을 거치는지, 어느 지점에서 같은 조작을 반복하거나 멈추는지를 눈으로 확인함으로써, 설문이나 현장 문의에 의존하던 사용성 파악을 실제 사용 데이터에 기반한 방식으로 전환합니다.
같은 버튼을 세 번 연속 클릭했다거나 응답을 2.4초 기다렸다는 사실은 지표로만 보면 드러나지 않습니다. 재생 화면에서는 그대로 보입니다.
전국 대리점과 종합보험사의 설계사가 가입설계 시스템을 실제로 어떤 순서로 사용하는지를 세션 리플레이로 확인하고, 화면별 실사용량을 함께 측정해 개선 우선순위를 판단하고 있습니다.
사례 읽기
한 번의 클릭으로 구간별 소요 시간까지
사용자가 4.2초를 기다렸다면, 그중 API 응답을 기다린 시간이 1.5초, WAS의 SQL 조회가 1.8초일 수 있습니다. MAXY Web은 API 호출의 응답 시간을 대기(Waiting)·다운로드 구간으로 나누고, 제니퍼소프트 APM과 연동된 요청은 WAS·네트워크·SQL·외부 호출 구간까지 이어서 나눠, 시간이 어디에 쓰였는지를 하나의 화면에서 보여줍니다.
프론트엔드에서 시작된 지연을 WAS 트랜잭션까지 이어서 볼 수 있으므로, 화면 문제인지 서버 문제인지를 두고 반복되던 조직 간 확인 과정이 데이터 한 장으로 정리됩니다.
화면에서 발생하는 JavaScript 오류와 네트워크·API 오류, 리소스 오류를 실시간으로 수집해 대시보드에서 바로 확인합니다. 오류 상세에서 세션 리플레이와 페이지 흐름으로 이어지므로 어떤 조작 경로에서 문제가 생겼는지 바로 확인할 수 있어, 원인을 찾는 데 걸리던 시간과 장애 대응 시간을 함께 줄입니다.
접속 IP로 지역을 추정해 지역별 사용자 수와 페이지 로딩 시간을 함께 보여줍니다. 사내 IP 대역에 기관명을 등록해 두면 사업장 단위로도 구분됩니다. 한 지역이나 한 사업장만 로딩이 느리다면, 원인이 서비스보다 그 현장의 네트워크에 있을 가능성부터 확인할 수 있습니다.
데이터는 고객사 안에, 수집 범위는 고객사 정책대로
수집한 성능·오류·사용자·화면 사용량 데이터는 고객사 인프라 안의 MAXY 저장소에 적재되고, 항목별 보관 기간도 고객사가 정합니다. 세션 리플레이 화면 속 개인정보는 태그나 클래스 단위로 가리고, 로그를 수집할 URL과 제외할 URL, API 요청·응답 메시지의 수집 여부도 설정으로 정합니다.
내부 시스템은 외부 연동 API로 이벤트 로그와 페이지 성능 데이터를 조회해 갈 수 있고, 콘솔 로그인은 SSO로 사내 인증과 연동할 수 있습니다. 사번·부서·사업장 같은 사용자 조직 정보는 SDK가 함께 보내 이벤트 목록에서 같이 조회됩니다. 고객사 표준 DBMS로의 적재는 구축 범위에서 별도로 연계하며, 삼성화재 가입설계 시스템이 그 사례입니다.
삼성화재 가입설계 시스템 도입 기준입니다.
| 과제 | 도입 후 |
|---|---|
| 전국 대리점·종합보험사의 네트워크 이상 상황을 확인할 방법이 없음 | 접속 지역별 로딩 시간을 데이터로 비교해 대응 주체를 판단 |
| 설계사의 실제 사용 패턴을 파악할 수 없음 | 세션 리플레이로 조작 순서와 반복·정체 구간을 직접 확인 |
| 개선 우선순위를 정할 근거 부재 | 화면별 실사용량 + 성능 지표를 함께 보고 순서 결정 |
| 장애 원인 규명에 시간 소요 | 실시간 오류 수집과 조작 경로 확인으로 대응 시간 단축 |
| 프론트와 WAS 구간이 분리되어 추적 불가 | 제니퍼소프트 APM 연동으로 Front-End와 WAS 구간을 잇는 성능 분석 체계 확보 |
| 데이터가 내부에 축적되지 않음 | 표준 DBMS 적재로 운영 데이터 자산화 |
대외 서비스 · 사내 업무 웹 · 모바일 웹. 스크립트 삽입만으로 연동합니다.
| 적용 대상 | 대외 웹 서비스, 사내 업무 웹 시스템, 모바일 웹 |
|---|---|
| 설치 방식 | 스크립트 삽입 방식 연동 |
| 수집 지표 | Core Web Vitals, 페이지 로딩·응답 시간, API/AJAX 성능, JavaScript·네트워크/API·리소스 오류, 사용자 행위, 접속 IP 기반 지역 |
| 브라우저 | 주요 데스크톱·모바일 브라우저 |
| 연계 | 제니퍼소프트 APM, 외부 연동 API(이벤트 로그 · 페이지 성능), SSO 로그인. 고객사 DBMS 적재는 구축 시 별도 연계 |
| 인증 | GS인증 1등급 |
| 구축 형태 | 온프레미스 / 망분리 환경 대응 |
RUM 도입 검토에서 가장 자주 나온 여덟 가지.
RUM(Real User Monitoring)은 실제 사용자의 브라우저에서 웹 서비스가 어떻게 동작하는지를 측정하는 방식입니다. 서버에 요청이 도달한 이후를 보는 서버 모니터링과 달리, 화면이 그려지는 시간과 사용자의 접속 환경, 브라우저에서 발생한 오류, 그리고 사용자가 실제로 한 조작까지를 사용자가 겪은 그대로 수집합니다.
합성 모니터링은 정해진 시나리오를 정해진 환경에서 주기적으로 실행해 서비스가 살아 있는지를 확인합니다. 미리 정의한 경로만 보기 때문에, 실제 사용자가 겪는 다양한 단말·브라우저·네트워크 환경에서의 문제나 예상하지 못한 조작 경로에서 생기는 오류는 잡히지 않습니다. RUM은 실사용 데이터 전체를 수집한다는 점에서 다릅니다. 두 방식은 서로 대체하기보다 보완 관계입니다.
금융권을 비롯한 규제 산업 도입 시 가장 먼저 확인하는 사항입니다. MAXY Web은 온프레미스 구축과 망분리 환경 도입이 가능하며, 수집 데이터는 고객사 내부에 적재됩니다. 화면 내 개인정보 항목의 수집 제외 처리와 마스킹 정책은 고객사의 내부 보안정책에 맞춰 설정합니다. 구체적인 적용 범위는 도입 검토 단계에서 함께 정의합니다.
FeelDex는 Core Web Vitals를 기반으로 산출하는 체감 성능 지수입니다. LCP·INP·CLS를 각각 따로 해석하면 어느 지표를 먼저 개선해야 하는지 판단이 어렵고, 개발 조직 외부와 논의하기도 어렵습니다. FeelDex는 이를 하나의 숫자로 통합해 품질 저하를 빠르게 감지하고, 어느 지표가 지수를 끌어내리는지 함께 보여줘 무엇부터 볼지 정하는 데 목적이 있습니다.
가능합니다. 제니퍼소프트 APM과 연동해 프론트엔드에서 발생한 지연을 WAS 트랜잭션 구간까지 이어서 추적할 수 있습니다. 서버 APM은 요청이 도달한 이후를, MAXY Web은 사용자의 화면에서 요청이 발생하기까지와 응답이 그려지기까지를 봅니다. 두 구간이 연결되어야 사용자가 겪은 4초가 어디서 만들어졌는지 설명할 수 있습니다.
적용할 수 있습니다. 오히려 사내 업무 웹은 사용자가 매일 장시간 사용하는데도 품질 측정이 되지 않는 경우가 많습니다. 삼성화재는 전국 대리점과 종합보험사의 설계사가 사용하는 가입설계 시스템에 MAXY Web을 적용해, 현장의 네트워크 이상 상황과 설계사의 실제 사용 패턴을 파악하고 있습니다.
수집 데이터는 처음부터 고객사 인프라 안의 MAXY 저장소에 적재되고, 항목별 보관 기간도 고객사가 정합니다. 내부 시스템에서는 외부 연동 API로 이벤트 로그와 페이지 성능 데이터를 조회해 쓸 수 있습니다. 고객사 표준 DBMS로의 적재는 구축 범위에서 별도로 연계하며, 삼성화재가 그 사례입니다. 사번·부서·사업장 같은 사용자 조직 정보는 SDK가 함께 수집해 이벤트 목록에서 조회할 수 있습니다.
경량 수집 구조로 설계되어 대상 서비스의 성능 영향을 최소화합니다. 구체적인 스크립트 용량과 로딩 영향도 수치는 도입 검토 시 제공합니다.
Mobile · Web · Analytics는 같은 SDK로 수집해 한 콘솔에서 봅니다. 각 제품이 무엇을 보는지 확인해 보세요.
도입 검토에 필요한 자료를 보내드리고, 환경에 맞는 구성을 함께 정리해 드립니다.
주식회사 씽크엠 · sales@thinkm.co.kr · 02-2202-5651