Remote Config 갱신은 두 번 호출한다 — validateOnly + If-Match

안녕하세요, 로건입니다 👋

Firebase Remote Config를 한 줄로 publish 할 수 있음. curl -X PUT .... 그런데 운영하다 보니 그 한 줄에는 두 가지 사고 표면이 있음.

잘못된 JSON 구조로 publish하면 RC가 깨짐. 사용자에게 가는 진실원인 만큼, 반쪽 상태는 곧 모든 사용자에게 영향.
그 사이에 누가 RC를 바꿨어도 모르고 덮어쓰게 됨. 조용한 race.

그래서 우리는 publish를 두 단계로 쪼갰음.

// 1단계: dry-run
PUT .../remoteConfig?validateOnly=true
Headers: If-Match: <etag>
Body: <updated template>
 
// 통과하면 2단계: 실제 publish
PUT .../remoteConfig
Headers: If-Match: <etag>
Body: <updated template>

두 안전망의 역할이 다름.

validateOnly=true — 구조 검증을 publish 없이 먼저 함. 잘못된 JSON, 필수 필드 누락, 타입 mismatch — 이 단계에서 막힘. 실제 RC에는 아무 일도 일어나지 않음.

If-Match: <etag> — 우리가 처음 fetch했을 때 들고 온 etag. 그 사이에 누가 RC를 바꿨으면 그쪽의 새 etag가 박혀 있어서, 우리의 publish가 거절됨. 낙관적 동시성 제어.

이 두 줄짜리 안전망이 잡아주는 사고가 생각보다 많음.

동시에 두 사람이 RC를 만지는 경우. CI와 콘솔에서 사람이 동시에.
코드를 수정하다가 우연히 망가진 template을 던지는 경우.
임시 dir의 파일이 deploy 도중 다른 프로세스에 의해 수정된 경우.

publish는 sleep을 길게 갖는 명령이 아님. 그 짧은 시간 안에 두 줄을 더 두는 게, 사고를 한 자릿수로 묶음.

API 한 줄이 충분히 안전해 보일 때, 한 번 더 의심하면 두 줄을 얻을 수 있음.