합성 데이터를 넣은 격리 MySQL 재현에서 웹 관리 화면의 활동 목록 20건이 약 63MB에 달했다. 목록을 가져오는 과정에 큰 원문까지 따라왔다. 화면에 표시할 항목 수가 적어도 읽어 오는 데이터는 클 수 있었다.
활동 목록에서 먼저 필요한 것은 대개 언제 무슨 일이 있었는지, 성공했는지, 어느 항목을 열어 볼지 판단할 정보다. 상세 로그는 항목을 연 뒤 읽어도 된다. 그런데 이 둘을 같은 응답에 넣으면 제목을 훑으려는 요청도 긴 로그 본문을 운반하게 된다.
줄이는 지점을 앞으로 옮기기
브라우저가 원문 전체를 받아 놓고 앞부분만 그리면 화면은 짧아진다. 데이터베이스가 읽은 본문이나 서버가 응답으로 보낸 본문은 그대로일 수 있다. 표시할 웹페이지 요소를 줄여도 이미 가져온 데이터가 되돌아가지는 않는다.
서버가 본문을 전부 읽은 다음 짧게 잘라 보내는 방식은 어떨까. 브라우저가 받는 양은 줄어도 데이터베이스에서 전체 본문을 가져온 비용은 남는다. 목록의 건수만 세거나 최종 화면만 보면 이 차이를 놓치기 쉽다.
이 구조를 고친다면 목록과 상세 읽기를 나누는 방향이 맞다. 목록은 시각·상태·짧은 요약과 원문 식별자만 읽고, 상세 화면은 선택한 원문을 별도로 요청한다. 목록용 요약은 원문을 대체하는 기록으로 취급하지 않는다. 상세 읽기에는 기존 권한 검사를 계속 적용한다.
로그를 지우지 않고 목록을 가볍게
전송량을 줄이겠다고 저장된 로그 자체를 잘라 버리면 나중에 오류를 조사할 근거까지 잃는다. 바꿔야 할 부분은 목록 조회가 매번 원문을 읽는 동작이다. 목록용 정보와 원문을 분리하되 원문을 찾아 읽는 관계는 보존해야 한다.
원문 검색처럼 내용 전체가 필요한 작업까지 같은 요약 경로로 바꿀 수는 없다. 그 작업은 별도로 다루고 검색 범위나 읽을 양을 제한해야 한다. 목록이 가벼워졌다는 이유로 검색과 상세 읽기까지 해결됐다고 결론 낼 수 없다.
이번 재현은 목록의 데이터 크기를 살펴본 분석이다. 브라우저와 HTTP의 실제 지연시간, 운영 환경의 처리 용량은 측정하지 않았다. 읽기 경로 분리는 분석에서 제안한 수정 방향이며 이 결과만으로 운영 적용이나 속도 개선을 주장하지 않는다.
목록 수정의 확인 지점도 여기에 맞춘다. 화면에 보이는 행 수와 함께 목록 응답의 바이트 수, 데이터베이스가 실제로 읽는 열을 확인한다. 원문이 길어져도 목록 요청이 그 본문을 함께 가져오지 않고, 상세 화면에서는 필요한 원문을 그대로 읽을 수 있어야 수정 목적에 맞는다.