수집 코드가 있어도 요청이 아예 그 코드를 지나가지 않고 있었다
한눈에 답변
배포 방식을 바로잡은 지 얼마 지나지 않아 같은 종류의 문제가 다시 나타났다. 관리자 페이지처럼 구체적인 경로로 만든 요청은 수집 코드에 기록되는데, 일반 공개 문서 요청은 캐시 응답으로 곧바로 처리되며 수집 코드를 거치지 않고 있었다. 로컬 테스트 환경은 실제 운영 환경과 다르게 동작해 이 문제를 숨기고 있었다. 모든 경로를 강제로 가로채는 라우트를 새로 만들어서 해결했다.
무엇이 다시 문제였나
배포 실체를 바로잡은 지 얼마 안 돼 실제 운영 환경에서 확인해 보니, 구체적인 파일 경로로 만들어진 관리자 API 요청만 방문 기록에 남고, 일반적인 공개 문서 요청은 기록에 전혀 남지 않고 있었다. 존재하지 않는 주소로 요청해도 기록이 남지 않았다.
왜 로컬에서는 문제를 못 잡았나
로컬 테스트 환경은 전체 경로를 가로채도록 만든 설정 파일의 의도를 그대로 존중해서 동작한다. 그래서 로컬에서 테스트할 때는 이 설정이 잘 작동하는 것처럼 보였다. 그런데 실제 운영 환경은 이 설정 파일을 다르게 해석해서, 이미 캐시되거나 정적으로 서빙되는 요청은 그 앞단의 수집 코드를 거치지 않고 곧바로 처리해 버리고 있었다.
어떻게 고쳤나
모든 경로를 예외 없이 가로채는 파일 하나를 새로 만들었다. 이 파일이 모든 요청을 일단 받아서 수집 코드를 거치게 한 다음, 원래 있어야 할 정적 파일 서빙으로 응답을 넘기는 방식이다. 이렇게 하면 캐시가 있든 없든 관계없이 요청이 반드시 수집 코드가 있는 계층을 지나가게 된다.
이미지나 스타일 파일 같은 자잘한 요청까지 전부 기록되면 안 되지 않나
맞다. 그래서 이미지·폰트·스타일시트 같은 정적 자원 확장자를 가진 요청은 수집 코드 안에서 걸러내도록 가드를 추가했다. 전부 다 가로채게 만든 대신, 기록할 필요가 없는 요청은 그 안에서 다시 골라내는 구조다.
이번에는 검증을 어떻게 했나
응답 헤더에 수집 코드를 실제로 통과했다는 표시를 남기도록 만들어서, 배포 후에 그 표시가 붙어 있는지를 직접 요청해 확인할 수 있게 했다. 로컬 테스트만으로는 실제 운영 환경의 동작을 보장할 수 없다는 것을 이번 일로 다시 확인했기 때문이다.