배포된 preview가 로컬 HEAD와 다를 때

preview URL이 살아 있다고 해서 내가 방금 고친 코드가 배포된 것은 아니다. Oracle Tarot 작업에서 이걸 다시 확인했다.

로컬 main의 HEAD와 Vercel Preview가 가리키는 commit이 달랐고, readiness API는 storage와 reading provider 상태가 fallback임을 보여줬다. 문서상으로는 “배포됨”처럼 보일 수 있었지만, 실제 운영 상태는 더 구체적으로 봐야 했다.

먼저 분리한 것

처음에는 같은 말처럼 보이는 상태를 나눴다.

• 로컬 repo의 현재 HEAD
• Vercel Preview가 실제로 배포한 commit
• readiness endpoint가 반환하는 운영 상태
• storage가 production 설정으로 붙었는지
• reading provider가 fallback template인지 실제 provider인지

이걸 나누지 않으면 “로컬에서는 고쳤다”와 “서비스가 고쳐졌다”가 섞인다.

active repo와 legacy repo

Oracle 작업에서는 repo도 헷갈릴 수 있었다. oracle-v3가 현재 기준 repo이고, oracle-tarot는 legacy/template 성격의 dirty worktree였다.

그래서 상태를 말할 때는 먼저 기준 repo를 고정했다. 그 다음 로컬 HEAD, deployed Preview, readiness를 각각 확인했다.

active repo      -> oracle-v3
legacy worktree  -> oracle-tarot
local HEAD       -> 내가 보고 있는 최신 코드
preview commit   -> 실제 preview가 가리키는 코드
readiness        -> 서비스가 production dependency를 쓰는지

readiness가 알려준 것

GET /api/ops/readiness는 “사이트가 떠 있다”보다 더 구체적인 상태를 보여준다.

이 작업에서 readiness는 degraded 상태였고, storage는 ready가 아니었으며 memory fallback을 쓰고 있었다. reading provider도 fallback template 모드였다.

이 상태에서는 UI가 보이더라도 운영 준비가 끝났다고 말하면 안 된다.

작은 UI 수정도 테스트로 남기기

Oracle home의 상단 탭 가운데 정렬 같은 작은 UI 수정도 테스트로 남겼다. 이유는 간단하다. inline CSS가 길고, home shell의 구조가 여러 화면 상태에 걸쳐 있었기 때문이다.

작은 변경일수록 “눈으로 봤다”로 끝내기 쉽다. 하지만 같은 화면이 다시 깨지면 어디가 기준이었는지 알 수 없다. 그래서 discovery shell layout 관련 regression guard를 추가했다.

배운 점

배포 상태는 하나의 단어로 말하면 안 된다. “URL이 있음”, “최신 commit이 배포됨”, “readiness가 정상”, “실제 provider가 production mode”는 서로 다른 상태다.

다음부터는 상태 보고를 할 때 로컬, preview, readiness를 분리해서 적는다.