— 호스팅 캐싱이 REST API를 캐시하던 6시간
리드 매칭 자동화 시스템을 운영하면서, 파트너 대시보드 v3.1 작업을 진행 중이었다. Google Sheets와 WordPress 사이에 양방향 동기화를 만들고, 일주일 동안 잘 돌고 있었다.
그런데 어느 순간, 같은 코드가 깨지기 시작했다.
시트에서 수정한 값이 WordPress 화면에 안 반영되거나, 잠시 반영됐다가 다시 옛날 값으로 돌아갔다. 코드는 한 줄도 안 바꿨는데.
1라운드 — 코드 의심
당연히 코드부터 봤다.
Apps Script의 양방향 동기화 함수, REST API 엔드포인트, race condition 가능성, user_meta vs 커스텀 테이블 충돌. 가설을 세우고 검증하고, 세우고 검증했다.
AI에도 물어봤다.
"Memcached 캐시일 수도 있어요. 클리어해보세요."
"Apps Script 함수 중복 실행 같은데요?"
"WP Cron 충돌일 가능성도 있습니다."
다 헛다리였다. 코드 만지고 다시 테스트, 만지고 다시 테스트. 두 시간이 지났다.
2라운드 — 그 사이 무엇이 바뀌었나
문득 한 가지 사실이 머리를 스쳤다.
일주일 전엔 정상이었다. 그 사이에 코드는 안 바꿨다. 그러면 코드가 아닌 다른 무언가가 바뀐 것이다.
그 사이에 바뀐 건 단 두 가지였다.
일주일 전: 정상
지금까지 변경: 보안 플러그인 추가 + 호스팅 캐싱 설정 변경
지금: 비정상
코드는 무죄였다. 추측으로 코드 만지는 짓을 멈추고, 진짜 변경된 것만 봐야 할 시점이었다.
3라운드 — 항목별 검증
두 가지를 ON/OFF로 하나씩 검증했다.
조건
| 보안 플러그인 | 호스팅 캐싱 | 결과 |
|---|---|---|
| OFF | OFF | ✅ 정상 |
| ON | OFF | ✅ 정상 |
| OFF | ON | ❌ 비정상 |
| ON | ON | ❌ 비정상 |
→ 범인은 호스팅의 동적 캐싱 기능이었다.
호스팅 차원의 캐싱이 내부 REST API 응답까지 캐시하고 있었다. 시트에서 값이 바뀌어도 WordPress는 캐시된 옛날 응답을 돌려주고 있었던 것이다.
해결
해결은 한 줄짜리였다.
해당 REST API 경로를 호스팅 캐싱 제외 목록에 추가.
끝.
여섯 시간 동안 코드를 헤맸는데, 답은 호스팅 설정 한 줄이었다.
교훈
이번 사건이 가르쳐준 건 명확하다.
정상이던 게 깨졌다 = 그 사이 변경된 것만 봐라
코드는 그 사이에 안 바꿨으면 코드는 무죄다. 추측으로 코드 만지는 거 그만하고, 그 일주일 사이에 진짜 변경된 것부터 확인하면 된다.
AI 도구들이 던지는 가설은 끝이 없다. Memcached, Cron, race condition, 함수 중복. 모두 그럴듯한 가설이지만, 정답은 운영 변경 기록에 있었다.
AI는 코드를 추측한다. 운영자는 그 사이 무엇이 바뀌었나를 기억한다. 그 분업이 명확할 때 디버깅이 빨라진다.
의도 기반 리드 필터링 시스템을 운영하면서, 이런 코드 바깥의 함정은 앞으로도 계속 나타날 것이다. 그때마다 코드를 의심하기 전에 운영 변경 기록부터 확인하는 습관이, 결국 가장 빠른 디버깅 경로다.
긴 글 읽어주셔서 감사합니다.
