배포 방식을 다르게 알고 있었던 것 자체가 문제였다
한눈에 답변
이 사이트가 오랫동안 특정 배포 서비스로 운영되는 것으로 기록돼 있었는데, 실제로 배포 이력을 확인해 보니 완전히 다른 서비스(전용 서버리스 실행 환경)로 배포되고 있었다. 이전 서비스 전용 개념으로 짜여 있던 구조는 새 실행 환경에서 아예 작동하지 않았고, 그 결과 방문자 수집 코드를 만들어 뒀는데도 공개 페이지 요청이 단 한 건도 그 코드를 거치지 않고 있었다는 것이 드러났다.
무엇을 잘못 알고 있었나
이 사이트의 배포 방식이 특정 정적 호스팅 서비스라고 문서에 기록돼 있었고, 그 전제로 코드 구조를 짜 왔다. 그런데 실제 배포 이력을 확인하는 작업을 하다가, 그 전제 자체가 틀렸다는 것을 발견했다. 실제로는 완전히 다른 서비스(코드를 직접 실행하는 서버리스 환경)로 배포되고 있었다.
왜 이 차이가 중요했나
이전 서비스는 특정 폴더 구조와 라우팅 설정 파일로 동작을 제어하는 방식이었다. 그런데 실제로 쓰이고 있는 서비스는 이 구조를 아예 이해하지 못한다. 그 폴더와 설정 파일이 있어도 무시되고, 코드가 컴파일되는 형태 자체가 다르다.
실제로 무슨 문제가 있었나
방문자 요청을 기록하는 코드를 이미 만들어 뒀는데, 실제로는 공개 페이지에 대한 어떤 요청도 그 코드를 한 번도 거치지 않고 있었다. 캐시 응답 표시를 확인해 보니 요청이 곧바로 캐시나 정적 파일 서빙으로 처리되고, 우리가 만든 수집 코드가 있는 계층까지 아예 도달하지 않고 있었다.
어떻게 바로잡았나
새로 실제 쓰이는 서비스의 방식에 맞춰 설정 파일을 처음부터 다시 만들었다. 관리자 전용 경로는 별도 인증을 거치고, 나머지 공개 요청은 수집 로직을 거친 뒤 정적 파일 서빙으로 넘기도록 순서를 다시 짰다. 기존 코드의 내용 자체는 옮기기만 했고 로직은 그대로 뒀다.
제대로 고쳤는지 어떻게 확인했나
로컬 환경에서 실제 배포와 같은 방식으로 실행해 보고, 정해진 크롤러 이름으로 요청했을 때는 기록이 남고 일반 방문자로 요청했을 때는 기록이 남지 않는 것을 직접 확인했다. 존재하지 않는 주소로 요청했을 때 오류가 기록되는 것도 함께 확인한 뒤에 배포했다.