gcloud run deploy --source .의 첫 실행이 실패했습니다.

Google이 기본 컴퓨트 서비스 계정의 빌드 권한을 축소한 뒤 새 프로젝트에서 나타나는 증상입니다. roles/cloudbuild.builds.builder를 한 번 부여하면 해결됩니다. 앞의 배포 설정 절차 3단계가 이것입니다.

배포 후 Cloud Run이 발급한 run.app 주소에서 헬스 체크 경로를 확인하니 앱이 아니라 Google의 404 페이지가 돌아왔습니다. 앱은 정상이어서 /도 기록 목록도 잘 나오는데 /healthz만 그랬습니다. 경로를 바꿔 가며 확인한 결과입니다.

이 서비스에서 확인한 경로 중에는 정확히 /healthz 하나만 앞단에서 가로챘습니다. 슬래시를 붙인 /healthz/는 그대로 통과하므로, 앱의 라우팅 문제가 아닙니다.

/healthz는 Cloud Run이 요구한 경로가 아니라, 제가 관례를 따라 앱에 정한 경로입니다. 이 관례는 Google 내부의 z-pages(/healthz, /varz, /statusz)에서 나왔습니다. 실제 애플리케이션 경로와 충돌하지 않도록 z를 붙인 이름인데, Kubernetes의 liveness probe 예제와 여러 헬스 체크 라이브러리를 거치며 업계 표준처럼 퍼졌습니다. Cloud Run의 공식 "Known issues"에도 /eventlog, /_ah/로 시작하는 경로와 일부 z로 끝나는 경로를 쓸 수 없다고 나옵니다. 즉, /healthz 하나만의 특수 규칙으로 일반화하기보다 Cloud Run에서는 z로 끝나는 진단 경로를 피하는 편이 안전합니다. 기본 헬스 경로가 /healthz인 Streamlit도 GCP에서 같은 문제를 겪고 경로를 바꾸는 옵션을 추가했습니다.

Cloud Run 자체가 이 경로를 요구하지는 않습니다. 다만 외부 모니터나 Cloud Run의 HTTP startup/liveness probe가 /healthz를 호출하도록 설정돼 있다면 컨테이너가 정상이어도 계속 404로 판단합니다. 그래서 같은 핸들러를 /health에도 등록했습니다.

무료 한도는 프로젝트가 아니라 결제 계정 단위로 합산되고 매월 초기화됩니다. 요청 기반 과금(request-based billing)의 무료 한도는 CPU 180,000 vCPU-초, 메모리 360,000 GiB-초, 요청 2,000,000건입니다.

여기서 놓치기 쉬운 조건이 두 가지 있습니다.

첫째, 무료 한도는 사용량을 빼 주는 것이 아니라 Tier 1 단가에 해당하는 금액을 할인하는 방식입니다. Tier 2 리전에서 같은 양을 쓰면 단가가 더 비싸므로 할인으로 덮이는 사용량이 그만큼 줄어듭니다. 서울(asia-northeast3)은 Tier 2, 도쿄(asia-northeast1)는 Tier 1입니다. 응답 시간 때문에 도쿄로 옮긴 것이지만, 결과적으로 무료 한도를 온전히 쓰는 리전이 되기도 했습니다.

둘째, 과금 시간은 100밀리초 단위로 올림됩니다. 요청 기반 과금에서는 요청을 처리하는 동안(billable instance time)에만 CPU와 메모리가 계산되고, 컨테이너에 도달하지 못한 요청은 과금되지 않습니다. IAM 정책에서 거부된 요청도 마찬가지입니다.

gcloud run deploy --source . 한 줄로 배포해도 Cloud Run 외의 서비스가 함께 쓰이고, 각각 별도의 요금 체계를 가집니다.

이 중 Cloud Storage와 외부 데이터 전송에는 이 구성에서 기대할 수 있는 상시 무료 한도가 없습니다. 개인 앱의 사용량에서는 반올림돼 0원으로 남지만, "무료 한도 안에서 쓰고 있다"고 말할 수 있는 항목은 아닙니다.

Cloud Run에서 나가는 인터넷 전송은 Premium Tier로 Google Cloud 네트워킹 요금이 적용됩니다. 들어오는 트래픽은 무료이고, 나가는 트래픽만 GiB 단위로 계산합니다. 중요한 점은 단가가 출발 리전이 아니라 목적지 기준이라는 것입니다.

앱을 어느 리전에 두든 이 구분은 달라지지 않습니다. 서울에서 한국 사용자에게 보내도 같은 $0.19/GiB이고, 서울에서 도쿄의 Turso로 보내도 같은 $0.12/GiB입니다. Turso는 AWS에 있어서 Google 밖의 주소이므로, 도쿄에서 같은 도쿄로 나가더라도 사설 구간이 아니라 인터넷 전송으로 계산됩니다.

이 앱에서 나가는 트래픽은 두 갈래입니다.

앞의 표를 이번 전환에 대입해 보면, 프록시를 걷어낸 결정이 응답 시간에는 이득이지만 전송 요금에는 손해입니다. 두 가지가 함께 바뀌었습니다.

목적지가 싱가포르에서 한국으로 바뀌었습니다. 전환 전 til.benelog.net의 A 레코드는 13.215.239.219였고, RDAP로 조회하면 등록명이 AMAZON-SIN입니다. 즉 Cloud Run이 응답을 건네던 상대는 한국의 사용자가 아니라 싱가포르에 있는 Netlify의 엣지였습니다. GCP 입장의 목적지가 싱가포르였으므로 아시아 단가 $0.12/GiB에 0~1GiB 무료 구간이 적용됐고, 싱가포르에서 한국까지의 마지막 구간은 Netlify의 대역폭이었습니다. 직접 매핑으로 바꾼 지금은 목적지가 한국이므로 무료 구간 없이 $0.19/GiB입니다.

엣지 위치를 우리가 고를 수 있는 것도 아닙니다. Netlify는 PoP 목록을 공식적으로 공개하지 않고, 지원 포럼에서 안내한 일반 CDN 지역에는 동아시아가 없습니다. PoP가 더 많은 High-Performance Edge는 Enterprise 플랜 기능이고, 리전을 지정하는 설정은 Functions에만 있습니다(Pro 이상). 앞의 측정에서 Netlify 경유 경로의 TCP 완료가 71.7ms로 길었던 것도 이 위치와 무관하지 않아 보입니다.

응답 압축이 사라졌습니다. 이쪽이 단가 변화보다 영향이 컸습니다. 전환 직후 두 경로의 헤더를 비교해 보니 이렇게 나왔습니다.

Netlify는 Brotli를 자동으로 적용해 줬는데, 이 서비스에서는 Google Frontend가 Cloud Run의 응답을 대신 압축해 주지 않았습니다. 메인 HTML도 Accept-Encoding을 붙이든 붙이지 않든 같은 크기로 돌아왔습니다. HTML·CSS·JavaScript는 보통 3~5배까지 줄어드는 자산이므로, 단가가 1.58배 오른 것과 별개로 실제로 나가는 바이트 자체가 늘어난 상태였습니다.

프록시가 대신 해 주던 일이므로 앱이 직접 하도록 미들웨어를 넣었습니다. 표준 라이브러리 compress/gzip만 써서 순수 Go 구성은 그대로 유지했습니다.

규칙은 네 가지입니다.

마지막 규칙 덕분에 나중에 Netlify 프록시를 다시 앞에 두더라도 이중 압축이 되지 않습니다. HTTP 압축은 홉마다 Accept-Encoding과 Content-Encoding으로 협상하는 구조라, 프록시는 이미 인코딩된 응답을 다시 압축하지 않고 그대로 전달합니다.

배포한 뒤 운영 주소에서 잰 값입니다.

압축을 해제한 결과가 원본과 바이트 단위로 같은지, PNG는 그대로 나가는지도 함께 확인했습니다.

압축은 이렇게 되찾았지만, 목적지가 한국이라 단가가 $0.19/GiB이고 무료 구간이 없다는 조건은 그대로 남습니다. Netlify 프록시로 되돌리면 그 두 가지는 다시 유리해지므로 선택지로 열어 두고 있습니다. Turso로 오가는 양이 예상보다 크면 리전 구성을 다시 조정하는 것도 함께 검토할 생각입니다. 다만 지금은 청구서에 잡힌 값이 없어서 판단할 근거가 없고, 직접 매핑을 실제로 운영해 보는 것 자체가 목적이기도 해서 당분간은 이 구성을 그대로 두겠습니다.

또 하나 주의할 점은 이 무료 한도들이 대부분 결제 계정 단위라는 것입니다. 같은 결제 계정에 다른 프로젝트를 붙여 쓰고 있다면 그쪽 사용량이 이 앱의 무료 한도를 함께 소모합니다. 그래서 금액이 0원이더라도 예산 알림은 걸어 두는 편이 안전합니다. 현재 상태는 Google Cloud 콘솔의 결제 → 보고서에서 서비스별로 확인할 수 있고, 결제 → 예산 및 알림에서 임계값을 설정합니다.

처음에는 데이터베이스를 aws-us-east-2(오하이오)에 두고 있었습니다. 앱을 서울 리전에 올려도 이 상태면 요청마다 태평양을 건너게 됩니다. 이 앱은 페이지 한 장을 그릴 때 질의를 한 번 보냅니다. 그룹 위치 외의 조건을 그대로 두고 응답 시간이 크게 달라졌으므로 원격 데이터베이스까지의 왕복 경로가 주요 요인이라고 추정했습니다. 서버 내부 구간별 시간을 따로 기록하지는 않았으므로 데이터베이스가 차지한 비율까지 계산할 수는 없습니다.

그룹을 도쿄로 옮기고 같은 조건에서 다시 측정했습니다. 관찰한 범위에서는 응답 시간이 5배 이상 차이가 났습니다. 이렇듯 애플리케이션 리전과 데이터베이스의 리전을 가까운 곳으로 지정하는 이득이 큽니다.

Cloud Run 서비스는 서울에 있지만 Cloud Run의 직접 커스텀 도메인 매핑은 asia-northeast3을 지원하지 않습니다. Google이 권장하는 대안은 외부 Application Load Balancer이고 Firebase Hosting도 선택할 수 있지만, 둘 다 별도의 구성과 비용 조건을 검토해야 합니다. 이미 benelog.net의 DNS와 TLS 인증서를 Netlify에서 관리하고 있었기 때문에, til.benelog.net도 Netlify에 두고 모든 요청을 백엔드로 넘기는 rewrite 한 줄로 붙였습니다.

상태 코드 200은 리다이렉트가 아니라 rewrite라서 주소창은 til.benelog.net으로 유지됩니다. DNS와 TLS 인증서는 Netlify가 관리하므로 백엔드를 어디로 옮겨도 이 한 줄만 고치면 됩니다.

이 프록시가 더하는 시간을 직접 확인하려고 커스텀 도메인 매핑을 지원하는 도쿄(asia-northeast1)에 같은 이미지와 환경변수로 til-tokyo 서비스를 만들었습니다. Google Search Console에서 benelog.net 소유권을 확인하고 til-tokyo.benelog.net의 CNAME을 ghs.googlehosted.com.으로 지정했습니다. Cloud Run 관리형 인증서는 도메인 매핑을 만든 뒤 약 57분 만에 준비됐습니다. 인증서 SAN에 til-tokyo.benelog.net이 포함됐고, /와 /health는 모두 200으로 응답했습니다. 앞에서 설명한 /healthz는 커스텀 도메인에서도 Google Frontend의 404를 반환했습니다.

2026년 8월 22일 19시 42분(KST), 아직 운영 경로가 Netlify 프록시이던 시점에 한국의 같은 머신에서 네 주소를 측정했습니다. 각 주소를 한 번 워밍업한 뒤 20회씩 호출했고, 한 주소를 몰아서 재지 않고 매 반복마다 선두 주소를 바꿨습니다. 요청마다 새 curl 프로세스를 사용했으므로 TCP와 TLS 연결도 매번 새로 맺었습니다. 모든 요청의 상태 코드는 200이었습니다. DNS·TCP·TLS·TTFB는 요청을 시작한 시점부터 해당 단계까지 걸린 누적 시간이고, p95는 20개 중 19번째 값입니다.

서울과 도쿄 run.app의 전체 중앙값 차이는 0.9ms이고 두 표본의 변동 폭보다 작습니다. 이 결과로 어느 리전이 더 빠르다고 단정할 수 없습니다. 도메인 매핑을 거친 경로는 같은 도쿄 서비스의 run.app보다 전체 중앙값이 185.3ms 길었습니다. Cloud Run의 커스텀 도메인 진입 경로가 더한 비용을 같은 원본 서비스끼리 비교한 값입니다.

도메인 매핑 경로는 Netlify 프록시 경로보다 63.0ms 빨랐지만 run.app 수준으로 짧아지지는 않았습니다. Netlify 경유 주소의 TCP 완료가 서울 run.app보다 약 66ms 늦고, 원본 서버의 응답을 다시 전달받는 구간까지 TTFB에 포함됩니다. 이 값만으로 Netlify 접속 지점의 물리적 위치를 확정할 수는 없습니다.

앞의 Turso 리전 실험과 이 프록시 실험은 기초 응답 시간이 서로 다릅니다. 따라서 두 실험에서 구한 차이를 직접 더해 서로 상쇄됐다고 표현할 수는 없습니다. 다만 두 실험 모두 앱과 DB를 가까이 두는 것만큼 사용자가 접속하는 프록시 경로도 중요하다는 방향은 일치합니다.

커스텀 도메인을 직접 붙일 수 없는 배포처를 쓸 때는 유용한 방법이지만, 지연이 중요하면 배포처가 해당 리전에서 제공하는 도메인 연결 방법을 먼저 확인하는 편이 낫습니다. Cloud Run 직접 도메인 매핑은 Preview 기능이고 Google도 프로덕션 사용을 권장하지 않습니다. 운영 도메인을 옮기려면 새 매핑의 인증서가 발급되는 동안 TLS 오류가 날 수 있다는 점도 고려해야 합니다.

측정 결과를 바탕으로 도쿄 Cloud Run과 직접 도메인 매핑으로 운영 경로를 옮겼습니다. 서울과 도쿄의 직접 응답은 사실상 같았지만, 직접 매핑은 Netlify 경로보다 63ms 짧았습니다. 개인 앱에서 지연을 줄이는 쪽을 우선해 Preview 제약을 감수한 선택입니다.

전환에서 가장 신경 쓴 부분은 중단 시간입니다. 관리형 인증서는 그 호스트의 DNS가 ghs.googlehosted.com.을 가리킨 뒤에 발급되기 시작합니다. 같은 이름의 인증서를 미리 만들어 둘 방법이 없으므로, DNS를 바꾼 시점부터 인증서가 준비될 때까지는 그 주소로 접속한 사용자가 TLS 오류를 봅니다. 그래서 순서를 이렇게 잡았습니다.

실제로 걸린 시간은 다음과 같습니다.

레코드를 지운 20:02:30부터 HTTPS가 정상화된 20:22:59까지 약 20분 30초 동안 이 주소는 정상 동작하지 않았습니다. 그중 약 4분 30초는 레코드를 지운 뒤 CNAME을 추가하기 전까지 이름 자체가 응답하지 않은 구간이고, 나머지는 TLS 오류 구간입니다. 기존 레코드의 TTL이 120초였으므로 삭제 직후 잠시 옛 주소로 접속한 사용자도 있었을 수 있습니다.

인증서 자체는 CNAME을 넣은 지 8분 이내에 준비됐습니다. 앞서 테스트 호스트 til-tokyo.benelog.net에서는 같은 단계에 약 57분이 걸렸으므로, 이 시간은 호스트마다 다르다고 봐야 합니다. Google 안내상 최대 24시간이 걸릴 수 있습니다. CertificateProvisioned=True가 된 뒤에도 8분 정도 TLS 오류가 이어졌습니다. 매핑 상태가 준비됐다는 것과 Google Frontend가 그 인증서를 실제로 제공하기 시작하는 것은 별개의 시점입니다.

전환 뒤 발급된 인증서는 subject가 CN = til.benelog.net, issuer가 Google Trust Services, CN = WR3이고 유효 기간은 2026년 8월 22일부터 11월 20일까지입니다. SAN에는 til.benelog.net 하나만 들어 있습니다.

전환 직후 같은 방식으로 다시 측정한 값입니다.

전환 전 Netlify 프록시 경로의 347.1ms와 비교하면 전체 중앙값이 122.9ms 짧아졌습니다. 다만 이 값은 전환 약 20분 뒤에 잰 것이라 앞의 측정과 시간대가 다릅니다. 같은 시점에 잰 run.app이 98.5ms이므로, 커스텀 도메인 진입 경로가 더하는 비용은 여전히 125.7ms입니다.

서울 서비스 til, Netlify 사이트의 proxy/_redirects, 기존 DNS 레코드의 값은 지우지 않고 롤백 경로로 남겼습니다. DNS를 원래 레코드로 되돌리면 프록시 경로가 그대로 다시 동작합니다.

배포한 지 30분이 되지 않아 til.benelog.net이 응답하지 않았습니다. 대시보드의 배포 로그에 원인이 그대로 남아 있었습니다.

컨테이너가 고장난 것이 아니라 무료 요금제의 임시 주소가 만료되면서 배포 자체가 삭제됐습니다. 그 사이 서비스는 정상이었고, 앱 로그에 GET / 요청이 200으로 남아 있습니다. 대시보드에는 "URL is temporary and will be live for 60 minutes"라는 안내가 있는데, 공식 문서에는 설명이 없습니다.

만료 시점은 재현하지 못했습니다. 위 사례는 DEPLOYMENT READY 이후 약 28분이고, 다른 때는 65분이 지나도 같은 주소가 살아 있었습니다. 따라서 안내문의 60분을 정확한 만료 시점이나 최소 보장 시간으로 해석할 수 없었습니다. 무료 주소의 수명을 운영 계약처럼 믿을 수 없다는 점만 결론으로 삼았습니다.

진단이 어려웠던 이유는 따로 있습니다. 만료된 주소가 한 번도 존재한 적 없는 서브도메인과 똑같은 응답을 돌려줍니다.

컨테이너 장애 때 502나 503이 흔하지만, 플랫폼이 라우팅을 먼저 제거하면 404를 돌려줄 수도 있습니다. 이 404와 헤더만으로는 앱 장애인지 주소 회수인지 구분할 수 없었습니다. 대시보드의 배포 로그를 봐야 알 수 있습니다.

여기에 재배포하면 주소 접미사가 바뀌는 문제가 더해집니다. 실제로 되살릴 때마다 til-nsh62xv6에서 til-xu9uffq7로 바뀌었고, 그때마다 Netlify의 _redirects를 고쳐야 했습니다. 잠깐 띄워 보여 주는 용도라면 쓸 만하지만, 주소가 항상 살아 있어야 한다는 조건에는 맞지 않았습니다. 영구 주소는 월 5달러 요금제부터입니다.

그래서 "카드 등록 없이"라는 조건을 포기하고 Cloud Run으로 옮겼습니다. 카드를 등록해야 한다는 조건이 같다면, 무료 리전이 us-central과 europe-west뿐인 Northflank보다 서울 리전에서 요청이 없을 때 0개로 축소되는 Cloud Run이 이 앱의 사용 방식에 더 잘 맞았습니다. GitHub 연동으로 푸시할 때마다 자동 배포되던 점은 Back4app 쪽이 편했습니다.

앱의 설정 화면에는 현재 앱이 읽는 상태를 JSON으로 내려받는 기능이 있습니다. 이 내려받기는 일반 링크여서 URL에 비밀을 싣지 않으려고 토큰을 전달하지 않으므로, 공개 DB에서만 동작합니다. 스키마와 커밋 이력까지 포함한 DB 전체를 가져오려면 Dolt CLI로 저장소를 clone할 수 있습니다.

따라서 앱 운영자인 제가 사용자 데이터의 백업과 반출 기능을 별도로 만들 필요는 없습니다. 다만 DoltHub의 커밋 이력은 DoltHub 계정 삭제나 서비스 장애까지 막아 주는 별도의 백업은 아닙니다. 기록이 중요하다면 사용자가 주기적으로 clone해서 다른 곳에 사본을 두어야 합니다.

잘못 붙여 넣은 토큰은 검증이 없으면 첫 쓰기에서야 오류로 드러납니다. 그래서 설정의 저장 버튼을 누르는 시점에 Worker가 DoltHub의 v2 API인 GET /api/v2/user로 토큰이 유효한지 확인합니다. `v1alpha1`에는 DB와 무관하게 토큰만 확인하는 문서화된 엔드포인트가 없어서, 이 요청 하나만 v2를 씁니다.

판정은 유효와 무효의 두 가지가 아니라 세 가지로 나눴습니다. DoltHub가 명확히 거부(401, 403)한 토큰만 저장을 막습니다. DoltHub 장애나 네트워크 오류처럼 판정할 수 없는 경우에는 확인하지 못했다는 안내와 함께 저장을 진행합니다. 저장소 쪽 장애를 "토큰이 틀렸다"로 보여 주면 사용자가 멀쩡한 토큰을 의심하게 되기 때문입니다.

서버에는 사용자의 시간대가 없습니다. UTC를 기준으로 삼으면 한국 사용자는 오전 9시 전에 체크한 기록이 어제 칸에 들어갑니다. 습관 추적기에서 그것은 사슬이 끊어진 것으로 보입니다.

그래서 브라우저가 로컬 날짜를 X-Local-Date 헤더로 보내고, 서버는 그 값을 씁니다. 헤더가 없을 때만 UTC로 계산합니다. 클라이언트가 보낸 값이므로 형식은 검사합니다.

체크 시각을 UTC로 저장하고 조회할 때 사용자의 시간대로 변환하는 방법도 검토했지만, 이 앱에는 맞지 않다고 판단했습니다. check_date는 시각이 아니라 "그 날 했다"는 날짜이기 때문입니다.

시각인 데이터는 UTC로 저장합니다. 습관의 생성 시점인 created_at 칼럼이 그렇습니다. 남는 트레이드오프는 브라우저가 보낸 날짜를 형식만 검사하고 신뢰한다는 점입니다. 조작된 날짜를 막는 인증 경계가 아니라, 사용자가 자기 DB에 기록하는 개인 도구이므로 받아들였습니다.

실행할 DDL은 순번이 있는 목록으로 관리합니다. 목록은 뒤에 붙기만 하고, 순번이 의존 순서를 정합니다. 실행 시점에는 적용되지 않은 SQL 구문만 순서대로 골라냅니다.

이 형태는 Flyway나 golang-migrate 같은 마이그레이션 도구에서 가져왔습니다. 다만 도구를 그대로 붙일 수는 없었습니다. 이런 도구는 JDBC 같은 DB 연결을 전제하는데 DoltHub는 REST API만 노출합니다. 그리고 배포자가 자격증명을 갖고 배포 시점에 실행하는 모델인데, 이 앱에서는 사용자의 DB가 배포 이후에 생기고 마이그레이션은 그 사용자의 토큰으로 요청 시점에 돕니다. 그래서 순번 목록이라는 형태만 가져오고 두 가지를 바꿨습니다.

자동으로 실행하는 내림(down) 마이그레이션도 만들지 않았습니다. 문제가 생기면 Dolt의 커밋 이력을 보고 수동으로 복구합니다. 스키마와 데이터가 함께 변한 커밋을 되돌리는 일은 별도의 호환성 판단이 필요하므로, 커밋 이력이 down 마이그레이션과 같은 것은 아닙니다.

새 데이터베이스를 연결한 사용자가 query error: branch not found를 만났습니다.

원인은 DDL 실패가 아니었습니다. DoltHub에서 방금 만든 데이터베이스는 커밋이 하나도 없어서 main 브랜치 자체가 없습니다. 목록을 읽는 첫 질의가 거기서 실패한 것이었습니다.

이 응답을 오류 화면에 그대로 띄우면 사용자가 할 수 있는 일이 없습니다. 지금은 이 메시지를 알아보고 준비 안내로 보냅니다. 다른 오류는 그대로 오류 화면으로 갑니다. 존재하지 않는 데이터베이스 이름까지 준비 안내로 덮으면 진짜 고장을 감추게 됩니다.

브랜치가 없는 데이터베이스에 write 엔드포인트로 CREATE TABLE을 보내면 테이블과 함께 브랜치도 생깁니다. 이것도 문서에 없는 동작입니다.