광고 데이터 조회 기간이 길어질수록 대시보드가 느려지는 이유와 집계 테이블 설계

📖 약 3분 읽기

광고 성과 대시보드를 점검하는 과정에서 반복되는 패턴이 하나 확인되었다. 일주일 단위로 조회할 때는 화면이 문제없이 열리지만, 조회 기간을 한 달 가까이로 늘리면 일부 요청이 제한 시간을 넘겨 실패하는 현상이 나타났다. 인트렌치컨설팅은 이 현상을 진단하는 과정에서, 화면 쪽 문제로 보였던 증상이 실제로는 데이터를 쌓고 꺼내 오는 구조에서 비롯되었다는 점을 확인했다.

일주일은 괜찮고 한 달에서 멈추는 이유

같은 화면인데 조회 기간만 다르게 주었을 뿐인데 결과가 달라진다면, 그 차이는 화면이 그리는 방식이 아니라 그 화면이 불러오는 데이터의 양과 처리 경로에 있을 가능성이 크다. 일주일치 데이터는 양이 적어 어떤 방식으로 처리하든 큰 부담이 되지 않는다. 그러나 조회 기간이 한 달 가까이로 늘어나면 처리해야 할 데이터의 양이 그만큼 커지고, 그 데이터를 다루는 방식에 담긴 비효율이 비로소 드러난다. 이런 증상은 짧은 기간으로 테스트할 때는 발견되지 않다가, 실제 운영에서 사용자가 긴 기간을 조회할 때에야 뒤늦게 나타나는 경우가 많다.

처음에는 화면을 의심했던 진단

진단 초기에는 화면이 데이터를 받아 그려 내는 처리 방식에 문제가 있을 것으로 보았다. 그러나 다시 들여다본 결과, 느려지는 지점은 화면이 아니라 데이터를 조회해 오는 경로에 있었다. 같은 데이터 경로를 공유하는 화면이 여러 개 존재했고, 이 경로를 쓰는 여러 고객사의 대시보드가 동시에 영향을 받고 있었다. 하나의 화면만 고치는 방식으로는 근본적인 해결이 되지 않는 구조였다.

두 갈래로 나뉜 원인

첫 번째 원인은 화면을 열 때마다 운영 데이터베이스에 쌓인 원본 광고 데이터를 처음부터 다시 집계하는 경로였다. 조회 기간이 길어지면 집계 대상이 되는 데이터의 행 수가 늘어나고, 그 과정에서 정렬 작업이 감당할 수 있는 범위를 넘어서면서 응답이 크게 느려졌다. 두 번째 원인은 화면을 열 때마다 외부 데이터베이스를 원격으로 조회하는 경로였다. 이 경로는 데이터의 양과는 무관하게, 원격으로 연결해 조회하는 한 건마다 일정한 지연이 붙는 구조였다. 조회해야 할 건수가 늘어나면 그 지연이 그대로 누적되어 전체 응답 시간을 끌어올렸다.

두 원인은 서로 다른 경로에서 발생했지만 공통점이 있었다. 둘 다 화면을 열 때마다 매번 처음부터 작업을 다시 수행하고 있었다는 점이다. 이미 계산된 결과를 재사용하지 않고 매번 원본부터 다시 훑는 구조이기 때문에, 조회 기간이 늘어날수록 부담도 그대로 늘어날 수밖에 없었다.

미리 집계해 두고 화면은 그것만 읽는 구조

이번 진단을 거쳐 적용 중인 방향은, 화면이 원본 데이터를 매번 집계하지 않도록 집계된 결과를 별도의 테이블에 미리 저장해 두고 화면은 그 테이블만 읽게 하는 것이다. 캠페인 단위 집계는 이미 이런 방식으로 동작하고 있었기 때문에, 이번 작업은 완전히 새로운 구조를 들여오는 일이 아니라 기존에 검증된 방식을 더 세부적인 단위까지 넓히는 일에 가깝다. 외부 데이터베이스를 원격으로 조회하던 경로는 하루에 한 번 집계해 운영 데이터베이스에 적재하고, 화면은 운영 데이터베이스만 읽도록 바꾸는 방향으로 정리하고 있다. 이렇게 구조를 바꾸면 원본 데이터가 계속 쌓여 늘어나는 상황과 화면의 응답 속도가 서로 분리된다. 원본 데이터가 얼마나 쌓였는지와 무관하게, 화면은 이미 정리된 결과만 읽으면 되기 때문이다.

이번 진단에서 얻은 시사점

대시보드가 느려지는 문제는 겉으로는 화면에서 시작된 것처럼 보이지만, 그 원인을 따라가 보면 데이터를 쌓고 꺼내 오는 구조에 가 닿는 경우가 많다. 짧은 기간으로만 점검해서는 이런 구조적인 문제를 발견하기 어렵다. 조회 기간을 의도적으로 늘려 재현해 보고, 화면이 원본 데이터를 직접 집계하고 있는지, 아니면 미리 정리된 결과를 읽고 있는지부터 확인하는 작업이 진단의 출발점이 되어야 한다.