요청 본문 로그 저장 시 용량 증가율 분석

By PLURA 2023-05-05

📝 전통적인 웹 서버의 access.log에는 요청 본문(Post-body)이 포함되지 않습니다.
그래서 본문 로그를 저장한다고 하면 가장 먼저 나오는 질문이 있습니다.

“로그 용량이 너무 많이 늘어나는 것 아닌가요?”

결론부터 말하면, 늘어나는 것은 맞지만 대부분의 웹 서비스 환경에서는 운영상 감당 가능한 수준입니다.
중요한 것은 단순히 “늘어난다/안 늘어난다”가 아니라, 어떤 서비스 구조에서 얼마나 늘어나는가를 이해하는 것입니다.

요청 본문 로그 저장 분석

1. 왜 요청 본문 로그가 필요한가?

요청 본문 로그는 단순 저장 데이터가 아닙니다.

WAF 우회 공격 대응: URL, 헤더만으로는 확인할 수 없는 페이로드를 분석할 수 있습니다.
API 공격 가시성 확보: JSON/XML/폼 데이터 내부의 악성 행위를 식별할 수 있습니다.
사고 원인 분석: 실제로 무엇이 전송되었는지 확인할 수 있습니다.

즉, 요청 본문 로그는 “추가 데이터”가 아니라,
애플리케이션 공격을 설명하는 핵심 근거 로그입니다.

2. 용량 증가는 어떻게 계산해야 하나?

요청 본문 로그 저장 시 용량 증가는 대체로 아래 요소로 결정됩니다.

전체 요청 중 POST/PUT/PATCH 비율
요청 본문의 평균 크기
기존 access.log의 평균 크기
본문 저장 시 압축 여부
로그 보관 기간(retention)

즉, “무조건 몇 배 증가”가 아니라,
서비스의 요청 구조에 따라 증가율이 달라집니다.

3. 간단한 계산 예시

시나리오 A. 일반적인 웹 서비스

하루 요청 수: 1,000만 건
기존 access.log 평균 크기: 요청당 1KB
POST/PUT 계열 비율: 20%
본문 평균 크기: 2KB

이 경우 추가 로그량은:

본문 저장 대상 요청 수: 200만 건
추가 로그량: 200만 × 2KB = 약 4GB
기존 로그량: 1,000만 × 1KB = 약 10GB

즉, 전체 로그량은 약 10GB → 14GB 수준으로 증가합니다.
증가율은 약 40%입니다.

시나리오 B. API 비중이 높은 서비스

하루 요청 수: 1,000만 건
기존 access.log 평균 크기: 요청당 1KB
POST/PUT 계열 비율: 30%
본문 평균 크기: 1KB

이 경우 추가 로그량은:

본문 저장 대상 요청 수: 300만 건
추가 로그량: 300만 × 1KB = 약 3GB
기존 로그량: 약 10GB

즉, 전체 로그량은 약 10GB → 13GB 수준으로 증가합니다.
증가율은 약 30%입니다.

4. 왜 “평균 30~50%”라고 보는가?

실무적으로 보면:

모든 요청이 본문을 갖는 것은 아니고
GET 중심 트래픽은 증가폭이 거의 없으며
POST 요청도 평균 본문 크기가 매우 크지 않은 경우가 많습니다.

그래서 일반적인 웹 애플리케이션/업무 시스템 환경에서는
요청 본문 로그 저장 시 전체 로그량이
대체로 30~50% 수준 증가하는 경우가 많습니다.

물론 아래 환경에서는 더 높아질 수 있습니다.

대용량 업로드 API
파일 전송 중심 서비스
POST 비율이 매우 높은 모바일/API 서비스

즉, 30~50%는 모든 환경의 절대값이 아니라,
일반적인 업무형 웹 서비스 기준의 실무적 범위로 이해하는 것이 정확합니다.

5. 저장 전략을 어떻게 가져가야 하나?

로그 용량 문제는
본문 로그를 저장하느냐 마느냐의 문제가 아니라,
어떻게 저장하고 관리하느냐의 문제입니다.

1) 압축 저장

요청 본문 로그는 텍스트 기반(JSON, XML, form-data)이 많아
압축 효율이 높은 편입니다.

2) 민감정보 마스킹

비밀번호, 주민번호, 카드번호 등은
저장 전 마스킹/필터링하여 보안과 컴플라이언스를 함께 만족시켜야 합니다.

3) Hot / Cold 스토리지 분리

최근 7~30일: 빠른 검색용 hot storage
장기 보관: 저비용 cold storage

4) Retention 정책

모든 로그를 동일 기간 유지할 필요는 없습니다.
중요 이벤트와 일반 이벤트를 구분해 보관 기간을 차등 적용할 수 있습니다.

6. 진짜 문제는 무엇인가?

현장에서 더 큰 문제는
“로그가 너무 많다”가 아닙니다.

요청 본문 로그가 없어서
실제 공격 내용을 설명할 수 없는 상태가 더 심각합니다.

URL, 헤더, 상태 코드만으로는
애플리케이션 공격의 핵심을 놓칠 수 있습니다.

즉, 로그 용량 증가를 이유로 본문 로깅을 포기하는 것은
스토리지 비용을 아끼기 위해
사고 원인 분석 능력을 포기하는 것과 같습니다.

✍️ 결론

요청 본문 로그를 저장하면
전체 로그 용량은 분명 증가합니다.

하지만 일반적인 웹 애플리케이션 환경에서는
그 증가율이 대체로 30~50% 수준에 머무는 경우가 많으며,
현재의 서버·스토리지 환경에서는 충분히 운영 가능한 범위입니다.

중요한 것은
용량 증가 자체를 두려워하는 것이 아니라,

어떤 서비스 구조에서
얼마나 증가하는지 계산하고
어떤 저장 전략으로 운영할지를 정하는 것입니다.

로그가 많아지는 것이 문제가 아니라,
필요한 로그가 없어서 공격을 설명하지 못하는 상태가 더 큰 문제입니다.