블로그

IT 시스템은 날이 갈수록 복잡해지고 있습니다. 모놀리식 아키텍처는 유연한 마이크로서비스(MSA)로 분화되었고, 정적인 서버 환경은 컨테이너와 서버리스 기반의 클라우드 네이티브로 빠르게 전환되었습니다.이러한 변화 속에서 DevOps 문화의 확산과 함께 시스템 전체의 상태를 파악하는 '옵저버빌리티(Observability)'의 중요성은 그 어느 때보다 커졌습니다.


이러한 배경에서 브레인즈컴퍼니는 고객들이 사용자 경험의 최접점인 웹 브라우저 구간까지 모니터링 범위를 확장하여 서비스 전반의 가시성을 확보할 수 있도록, 브라우저 모니터링 시스템인 'Zenius BRMS(Browser Monitoring System)'를 개발하게 되었습니다. 사용자 행동 추적과 정밀한 체감 성능 분석이 강점인 Zenius BRMS의 핵심 엔진을 구현하기 위한 내용을 정리했습니다.




우리만의 아키텍처: 중계 에이전트가 없는 통합 파이프라인

Zenius BRMS는 브라우저 데이터 수집의 핵심 도구로 표준 오픈소스 프레임워크를 채택했습니다. 이는 특정 벤더에 종속되지 않으면서 MSA 및 클라우드 네이티브 환경의 사실상 표준(De Facto Standard)으로 자리 잡은 기술이기 때문입니다. 단순히 데이터를 수집하는 기능을 넘어, 데이터의 생성부터 전송까지 수집 라이프사이클 전체를 아우르는 포괄적인 규격을 갖추었다는 점이 결정적인 도입 배경이 되었습니다.


다만, 표준 아키텍처를 그대로 따르기보다는 운영 환경에 최적화된 구조를 설계하는 데 집중했습니다. 이미 백엔드 데이터 처리의 중추 역할을 하는 자사 매니저가 존재하므로, 이를 최대한 활용하여 전체 구조를 단순화하기로 한 것입니다. 결과적으로 운영 복잡도를 높이는 별도의 오픈소스 수집 에이전트를 중간에 두는 대신, 브라우저에서 수집한 데이터를 자사 매니저로 직접 전송하는 효율적인 통합 파이프라인을 구축했습니다.


“애플리케이션  -> 매니저 -> 저장소” 구조로 배치 프로세서를 사용하여 데이터를 수집한 후 매니저로 전송합니다.



이를 통해 외부 프레임워크 관리 포인트를 줄이면서도 자사 솔루션의 강력한 데이터 처리 기능을 활용하여 프로세스를 일원화할 수 있었습니다. NodeJS나 모바일 앱 환경이라도 엔드포인트만 매니저로 지정하면 즉시 연동이 가능한 구조입니다.


이제 이렇게 수집된 데이터를 어떻게 다루고 있는지 살펴보겠습니다.




세션(Session) 정의와 생명주기

수집된 데이터를 분석하기 위해서는 기준이 필요합니다. 우리는 식별 ID를 가진 특정 사용자가 아니라 브라우저에 접근한 행위 자체를 하나의 세션으로 정의했습니다. 따라서 한 명의 사용자라도 상황에 따라 여러 개의 세션을 생성할 수 있습니다.


세션은 무한히 지속될 수 없으므로, 미동작 만료 시간(15분)과 최대 지속 시간(4시간)을 두어 생명주기를 관리합니다. 사용자가 활동을 하면 만료 시간이 갱신되지만 시작 후 15분 이내 동작이 없거나 4시간이 지나면 강제로 만료되는 구조입니다.



세션 정보는 쿠키를 활용하여 데이터 수집시점에 활용합니다.


external_image



해시 기반 샘플링 (XOR 연산의 활용)

때에 따라 대량의 데이터를 모두 수집하는 것은 비효율적이므로 샘플링이 필수적입니다. 기존의 샘플링은 단편적인 데이터 손실을 유발했기에 우리는 세션 기준 샘플링을 도입했습니다.


external_image


알고리즘 핵심은 균등한 분포(Uniform Distribution)를 만드는 것입니다. 세션 ID(UUID)를 32비트 정수로 변환하여 샘플링에 활용했는데 이 과정에서 AND 연산은 0으로 OR 연산은 최대값으로 수렴하는 경향이 있습니다. 따라서 우리는 비트의 무작위성을 가장 잘 보존하는 XOR 연산을 사용하여 균등한 샘플링 확률을 보장했습니다.




데이터 유실 없는 전송: sendBeacon vs keepalive

조금 더 자세한 가시성 확보를 위해 우리는 세션의 행동이 녹화되는 기능을 추가했습니다. 



세션 행동을 녹화하여 전송할 때 가장 큰 문제는 브라우저 닫기 등으로 인한 데이터 유실입니다. 보통 이 시점에 navigator.sendBeacon을 많이 사용하지만 우리는 Fetch API의 keepalive: true 옵션을 선택했습니다.


sendBeacon은 헤더 커스터마이징에 제약이 있고 응답 처리가 불가능한 반면 keepalive 옵션은 훨씬 유연한 제어가 가능하기 때문입니다. 64KB 용량 제한 이슈는 전송 주기를 조절하고 자체 용량 체크 로직을 추가하여 해결했습니다.


external_image




단순 저장소를 넘어: 다차원 분석을 위한 데이터 아키텍처 전환

Zenius BRMS의 초기 설계에서는 매니저에서 가공된 데이터의 신속한 기록과 실시간 조회를 위해, 입출력 속도가 뛰어난 Key-Value 기반의 인메모리 데이터베이스가 활용되었습니다. 하지만 분석해야 할 데이터 속성이 점차 다차원적으로 고도화되고, 분산된 시스템 간의 정교한 데이터 동기화가 요구되면서 기존 Key-Value 구조를 넘어선 확장성이 필요해졌습니다.


이에 따라 대규모 데이터 검색과 복잡한 집계 연산에 최적화된 검색 엔진 기반 저장소로 아키텍처를 전환했습니다. 특히 데이터 유입 단계의 파이프라인에서 요청-응답 시간(Response Time)과 같은 주요 파생 데이터를 미리 연산하여 저장하는 방식을 도입함으로써, 조회 시점의 연산 부하를 줄이고 데이터 가공 효율을 높였습니다.


단순한 처리 속도를 넘어 데이터의 활용성과 분석의 유연성에 무게를 둔 결과, 보다 심도 있고 다각적인 모니터링이 가능한 분석 환경을 구축할 수 있게 되었습니다.



브라우저에서 실시간으로 수집된 데이터는 자사 매니저를 거쳐 분석 목적에 최적화된 저장소에 안전하게 기록됩니다. 이로써 그간 파악하기 어려웠던 사용자 경험의 최전방인 프론트엔드 구간의 가시성을 확보할 수 있게 되었습니다. 이제 남은 핵심 과제는 "사용자의 클릭 한 번이 백엔드의 구체적인 어떤 쿼리를 유발했는가?"를 단절 없이 연결하는 것입니다.


이러한 전 구간(End-to-End) 추적을 실현하기 위해 서비스 간의 연관 관계를 정의하는 컨텍스트 전파(Context Propagation) 기술을 더욱 고도화할 계획입니다. 나아가 AI 기반의 이상 탐지(AIOps) 기술을 결합하여, 단순한 수치 관찰을 넘어 시스템 스스로 문제를 진단하고 예측하는 진정한 의미의 옵저버빌리티를 완성해 나갈 예정입니다.

김범호 부장 사진
김범호부장

개발본부에서 지능형 IT 인프라 통합관리 솔루션 Zenius의 개발 및 유지보수를 담당하고 있습니다.

추천 콘텐츠