API 응답 압축 전략 (네트워크 효율, CPU 부담, 최적화)
API 응답 압축을 처음 적용할 때 무조건 좋은 거라고만 생각했습니다. 데이터 크기가 줄어들면 당연히 속도도 빨라지고 서버 부담도 줄어들 거라는 막연한 기대가 있었죠. 하지만 실제로 프로덕션 환경에서 적용하고 나서 보니 놓친 부분이 있었습니다. 압축이라는 건 공짜로 얻어지는 마법이 아니라 CPU라는 비용을 지불하고 얻는 거래였던 겁니다. 이 글에서는 API 응답 압축 전략이 실제로 어떤 효과를 내는지, 그리고 어떤 상황에서 오히려 독이 될 수 있는지 제 경험을 바탕으로 정리해보겠습니다.
네트워크 효율, 압축으로 얼마나 개선되는가
일반적으로 gzip이나 brotli 같은 압축 알고리즘을 적용하면 데이터 크기가 70~80% 정도 줄어든다고 알려져 있습니다. 제가 담당했던 서비스에서 JSON 형식의 대용량 응답 데이터에 gzip 압축을 적용했을 때, 평균 200KB였던 응답이 약 50KB로 줄어들었습니다. 이론상으로는 전송 시간이 4분의 1로 단축되는 셈이죠.
특히 모바일 환경에서 이 효과가 두드러졌습니다. 4G 네트워크 환경에서 테스트했을 때 압축 전에는 응답 시간이 평균 1.2초였는데, 압축 후에는 0.4초로 줄어들었습니다. 사용자 입장에서 체감할 수 있는 수준의 개선이었죠. 모바일 데이터 요금제를 사용하는 사용자 입장에서도 데이터 사용량이 줄어드니 비용 절감 효과까지 있었습니다.
하지만 여기서 중요한 건 압축 효율이 데이터 특성에 따라 크게 달라진다는 점입니다. JSON이나 XML 같은 텍스트 기반 데이터는 압축률이 높지만, 이미지나 동영상처럼 이미 압축된 형태의 데이터는 추가 압축 효과가 거의 없습니다. 처음에는 모든 API 응답에 일괄적으로 압축을 적용했는데, 썸네일 이미지를 반환하는 API에서도 압축이 작동하고 있었던 겁니다. 결과적으로 압축 효과는 거의 없으면서 서버 CPU만 쓸데없이 소모하고 있었죠.
CPU 부담, 압축의 숨겨진 비용
압축이라는 건 결국 연산 작업입니다. 서버는 응답 데이터를 압축하기 위해 CPU 자원을 사용하고, 클라이언트는 받은 데이터를 해제하기 위해 또다시 CPU를 사용합니다. 일반적으로 서버 측 압축 비용이 더 크다고 알려져 있습니다.
제가 운영하던 서비스에서 트래픽이 급증했을 때 서버 모니터링 지표를 보니 CPU 사용률이 평소보다 30% 이상 높게 나타났습니다. 처음에는 로직 어딘가에 병목이 생긴 줄 알았는데, 프로파일링을 돌려보니 압축 처리 부분에서 CPU를 가장 많이 사용하고 있었습니다. 특히 동시 접속자가 많아지면서 압축 작업이 동시다발적으로 일어나니 CPU 코어가 포화 상태에 이르렀던 겁니다.
더 큰 문제는 작은 응답 데이터였습니다. 예를 들어 단순한 상태 확인 API처럼 10바이트도 안 되는 응답에도 압축이 적용되고 있었는데, 이런 경우는 압축 오버헤드가 압축 효과보다 훨씬 컸습니다. 압축 라이브러리 초기화부터 실제 압축, 헤더 추가까지 고려하면 오히려 응답 시간이 더 느려지는 경우도 있었죠. 압축 알고리즘 선택도 중요한데, gzip은 빠르지만 압축률이 낮고, brotli는 압축률이 높지만 처리 속도가 느립니다. 테스트했을 때 brotli 레벨 11로 압축하면 gzip 대비 15% 더 작아지지만 압축 시간은 5배 이상 걸렸습니다.
클라이언트 측 CPU 부담도 무시할 수 없습니다. 특히 저사양 모바일 기기나 IoT 디바이스에서는 압축 해제 작업이 배터리와 성능에 영향을 줄 수 있습니다. 브라우저는 압축 해제를 매우 효율적으로 처리하지만, 커스텀 앱 환경에서는 라이브러리 선택에 따라 성능 차이가 크게 나타났습니다.
최적화, 선택적 압축 전략이 답이다
압축 전략의 핵심은 '모든 것에 적용'이 아니라 '필요한 곳에만 적용'입니다. 최종적으로 정착한 방식은 다음과 같습니다.
- 응답 크기가 1KB 이상일 때만 압축을 적용합니다. 그 이하는 압축 오버헤드가 더 큽니다.
- Content-Type을 확인해서 텍스트 기반 데이터(application/json, text/html 등)에만 압축을 적용합니다.
- 이미 압축된 포맷(image/jpeg, video/mp4 등)은 압축 대상에서 제외합니다.
- 정적 리소스는 빌드 시점에 미리 압축해두고 서빙할 때는 압축을 건너뜁니다.
또한 압축 레벨도 세밀하게 조정했습니다. gzip의 경우 레벨 1~9까지 설정할 수 있는데, 레벨이 높을수록 압축률은 좋아지지만 CPU 사용량도 증가합니다. 테스트한 결과 레벨 6 정도가 압축률과 속도의 균형점이었습니다. 레벨 9로 올려봤자 압축률은 5% 정도밖에 개선되지 않는데 CPU 사용량은 2배 가까이 증가했거든요.
캐싱 전략과 조합하는 것도 효과적이었습니다. 자주 요청되는 응답은 압축된 상태로 캐시에 저장해두면 매번 압축 작업을 반복하지 않아도 됩니다. 제가 운영하던 서비스에서는 Redis에 압축된 응답을 캐싱해두고 동일한 요청이 들어오면 바로 서빙하는 방식으로 CPU 사용량을 40% 이상 줄일 수 있었습니다(출처: Redis 공식 문서).
압축 전략을 개선한 후 확인한 결과는 명확했습니다. 평균 응답 시간은 압축 적용 전과 비교해 15% 개선되었고, 서버 CPU 사용률은 오히려 20% 감소했습니다. 네트워크 대역폭 사용량도 60% 수준으로 줄어들어 인프라 비용 절감 효과까지 얻을 수 있었습니다. 이 경험을 통해 압축은 단순히 켜고 끄는 스위치가 아니라 시스템 전체를 고려한 최적화 작업이라는 걸 배웠습니다.
결국 API 응답 압축 전략은 네트워크 효율성과 CPU 사용량 사이에서 균형을 찾는 게임입니다. 무조건 압축을 적용한다고 좋은 게 아니라, 내 시스템의 특성과 사용자 환경을 고려해서 선택적으로 적용해야 합니다. 만약 여러분도 압축 전략을 도입하려 한다면, 먼저 응답 데이터의 크기와 타입을 분석하고, 압축 전후의 성능 지표를 꼼꼼히 비교해보시길 권합니다.
댓글
댓글 쓰기