API 응답 캐싱으로 인한 문제를 디버깅할 때

API 응답을 캐싱하는 건 성능 최적화의 핵심이다. 하지만 캐싱 때문에 정확히 뭐가 문제인지 파악하기 어려워진다. 최신 데이터를 받은 건지, 캐시된 데이터를 받은 건지 구분이 안 되기 때문이다.

특히 운영 중에 문제가 터지면, 클라이언트 캐시, 서버 캐시, CDN 캐시 등 여러 층을 확인해야 한다. 어느 레이어에서 문제가 있는지 체계적으로 찾아야 한다.

목표 정의하기

캐싱 문제를 해결하려면, 먼저 목표를 명확히 해야 한다:

• 응답이 최신 데이터를 포함하는가?
• 캐시는 얼마나 오래 유지되는가?
• 캐시를 무효화할 때는 언제인가?

이 세 가지를 정의해야 다음 단계로 나아갈 수 있다.

현재 상태 파악하기

지금 뭐가 캐시되고 있는지 확인해보자:

• 응답의 status code는?
• 응답 헤더에 cache-control은 뭐라고 되어 있는가?
• ETag나 Last-Modified 헤더는 있는가?

이 정보들이 있어야 원인을 찾을 수 있다.

curl로 직접 확인해보기

네트워크 요청을 직접 확인해보자:

curl -i 'https://example.com/api/items?page=1'

이 명령으로 실제 응답 헤더와 상태 코드를 볼 수 있다. -i 플래그가 중요하다.

수정 순서

캐싱 문제를 수정할 때는 가장 가까운 레이어부터 확인한다:

1. 클라이언트 캐시 (브라우저)
2. 서버 캐시 (Redis 등)
3. CDN 캐시

각 레이어에서 뭐가 문제인지 확인하고, 그 다음으로 나아가야 한다.

인증 상태 확인

인증된 요청과 인증 안 된 요청이 다르게 캐싱될 수 있다. Authorization 헤더를 확인해보자.

다음 액션 정하기

캐싱을 수정한 후에는, 같은 조건에서 다시 테스트해봐야 한다. 특히 브라우저 캐시를 비운 후에 테스트하는 게 좋다.

1. 같은 조건에서 다시 나는가?
2. 로그와 응답에서 뭐가 달라졌는가?
3. 캐시 헤더가 제대로 설정됐는가?

캐싱은 성능을 위해 필요하지만, 정확한 이해와 관리가 필수다. 정리해두면 나중에 훨씬 수월하다.