'폼 수정이 안 돼요' — 캐시 버그가 평가 플랫폼의 신뢰를 위협한 3시간

SaaS 평가 플랫폼에서 데이터가 정상 저장되었는데도 화면에 반영되지 않는 현상의 원인은 검색 필터 캐시입니다. DB와 API가 모두 정상이라면, 사용자가 보는 화면과 실제 데이터 사이에 캐시 레이어가 끼어 있는지 확인해야 합니다. evaluate.club은 이 문제를 검색 쿼리에 타임스탬프를 추가하여 캐시 미스를 강제하는 방식으로 3시간 만에 해결했습니다.

개요

• 서비스: evaluate.club (온라인 평가 플랫폼)
• 상황: 고객이 평가 폼을 수정했는데 화면에 반영되지 않음
• 원인: 검색 필터가 캐시된 과거 데이터를 반환
• 해결: 검색 쿼리에 타임스탬프 추가로 캐시 무효화
• 소요 시간: 약 3시간 (16:50 ~ 20:00)

16시 50분 — "평가 폼 수정이랑 저장이 안 돼요"

오후 4시 50분, 고객에게서 연락이 왔습니다.

"평가 폼 수정이랑 저장이 안 돼요!"

SaaS를 운영하는 사람이라면 이 한 줄에 심장이 철렁할 겁니다. 즉시 노트북을 켜고 제 계정으로 들어가 확인했습니다. 정상 작동합니다. 폼 생성도 되고, 수정 내용도 잘 반영됩니다.

"혹시 아직도 안 되시나요?" — "네, 여전히 안 됩니다."

캡처를 받아보았습니다. 그런데 DB에 저장된 내용과 화면에 보이는 내용이 달랐습니다.

고객은 말했습니다. "내일 아침까지는 반드시 해결되어야 합니다."

시계는 5시를 넘기고 있었습니다.

2시간의 디버깅 — 모든 것이 정상인데 왜?

본격적으로 코드를 뒤지기 시작했습니다. 체크한 항목들은 이렇습니다.

체크 항목	결과
DB 저장값	정상 (수정 내용 반영됨)
API 응답	정상 (최신 데이터 반환)
렌더링 로직	정상 (API 데이터 그대로 표시)
화면 표시	비정상 (과거 데이터 노출)

DB는 정상, API도 정상, 렌더링도 정상 — 그런데 화면이 다릅니다.

문제는 검색 필터에 있었습니다. 고객은 평가 폼 목록에서 검색 기능을 사용하고 있었고, 이 검색 결과가 캐시를 히트하고 있었습니다. DB에서 내용이 바뀌어도, 검색에 반영되는 데이터는 캐시에 저장된 과거 데이터였던 겁니다.

해결: 캐시 미스를 강제하는 타임스탬프

원인을 찾은 후 해결 방법은 비교적 단순했습니다. 검색 요청 시 타임스탬프를 쿼리 파라미터에 추가하여, 데이터 변경 이후의 검색은 반드시 캐시를 우회하도록 만들었습니다.

// 수정 전: 동일한 검색어 → 캐시 히트 → 과거 데이터
GET /api/forms?search=keyword

// 수정 후: 데이터 변경 시점의 타임스탬프 포함 → 캐시 미스 → 최신 데이터
GET /api/forms?search=keyword&_t=1713340800

고객에게 "해결됐습니다"를 보낸 건 저녁 8시 즈음이었습니다.

이 사건이 남긴 교훈

살떨리는 경험이었지만, 중요한 교훈을 얻었습니다.

캐시 도입 시 반드시 확인해야 할 질문

검색 기능에 캐시를 도입할 때, 반드시 이 질문에 답할 수 있어야 합니다.

"데이터가 바뀌었을 때, 사용자가 보는 화면도 바뀌는가?"

이 질문에 "예"라고 답할 수 없다면, 캐시 전략을 재검토해야 합니다. 특히 평가 시스템처럼 데이터 정합성이 핵심인 서비스에서 캐시 불일치는 기능 장애와 동일합니다.

데이터 정합성 체크리스트

체크 항목	설명
쓰기 후 읽기 일관성	데이터를 수정한 직후, 같은 사용자가 최신 데이터를 볼 수 있는가?
캐시 무효화 경로	데이터 변경 시 관련 캐시가 모두 무효화되는가?
검색 결과 갱신	검색/필터 결과가 캐시로 인해 지연되지 않는가?
다중 진입점 확인	목록, 검색, 상세 페이지 등 모든 경로에서 동일한 데이터가 보이는가?

신뢰는 디테일에서 만들어진다

evaluate.club은 평가 담당자가 기업을 "제대로 관리하고 있다"고 느끼게 만드는 서비스입니다. 심사위원이 입력한 점수가 정확히 반영되고, 수정한 폼이 즉시 화면에 나타나는 것 — 이런 당연한 것들이 지켜질 때 신뢰가 쌓입니다.

이번 장애 대응을 통해 데이터 정합성 검증 프로세스를 강화했습니다. 캐시가 개입하는 모든 경로에 대해 "쓰기 후 읽기" 테스트를 추가하고, 데이터 변경 시 관련 캐시를 선제적으로 무효화하는 패턴을 적용했습니다.

자주 묻는 질문 (FAQ)

캐시 버그는 어떻게 발견할 수 있나요?

DB에 저장된 값과 화면에 표시되는 값이 다를 때, API 응답은 정상인데 화면이 다르다면 캐시 문제를 의심해야 합니다. 브라우저 개발자 도구의 네트워크 탭에서 응답 헤더의 Cache-Control이나 X-Cache 값을 확인하면 캐시 히트 여부를 판단할 수 있습니다.

캐시 무효화의 일반적인 전략은 무엇인가요?

대표적으로 3가지 방법이 있습니다. (1) TTL(Time-to-Live) 기반: 일정 시간 후 자동 만료, (2) 이벤트 기반: 데이터 변경 시 관련 캐시를 명시적으로 삭제, (3) 버전/타임스탬프 기반: 쿼리에 변경 시점을 포함하여 캐시 미스를 강제. 데이터 정합성이 중요한 평가 시스템에서는 이벤트 기반과 타임스탬프 기반을 조합하는 것이 가장 안전합니다.

평가 플랫폼에서 데이터 정합성이 특히 중요한 이유는 무엇인가요?

평가 결과는 참가자의 선발, 수상, 지원금 배분에 직접 영향을 미칩니다. 점수가 1점이라도 다르게 표시되면 공정성 시비가 발생할 수 있습니다. 결과 통보 자동화 과정에서도 데이터 불일치가 있으면 참가자에게 잘못된 결과가 전달될 수 있어, 데이터 정합성은 평가 플랫폼의 가장 기본적인 신뢰 요건입니다.

evaluate.club은 데이터 정합성을 어떻게 보장하나요?

evaluate.club은 모든 데이터 변경에 대해 감사 추적(audit trail)을 기록하고, 캐시가 개입하는 경로에서 "쓰기 후 읽기" 일관성 테스트를 수행합니다. 또한 심사위원 점수 오기 방지 기능과 이상치 자동 감지로 입력 단계에서부터 데이터 품질을 관리합니다.

SaaS 서비스에서 고객 장애 신고를 효과적으로 대응하는 방법은?

첫째, 고객의 환경에서 직접 재현을 시도합니다. 개발자 계정에서 정상이라고 해서 문제가 없는 것이 아닙니다. 둘째, DB → API → 캐시 → 렌더링 순서로 데이터 흐름을 추적합니다. 셋째, 해결 후 동일 유형의 문제가 재발하지 않도록 테스트를 추가합니다.