<div id="readability-page-1" class="page"><div>
    <p><span>
        <time datetime="2026-08-22">
            2026-08-22</time>
    </span>
    
</p>
    
    <p>Go와 htmx로 만든 TIL 기록장을 무료 배포처 세 곳을 거쳐 Cloud Run에 올린 과정입니다. Back4app 무료 티어의 임시 URL 만료, Cloud Run 전환에서 걸린 두 가지, 데이터베이스 리전과 Netlify 프록시가 응답 시간에 미친 영향을 실측값과 함께 정리합니다.</p>

  
    
    <div id="content">
       <div id="toc">
<p>Table of Contents</p>
<ul>
<li><a href="#앱_구성과_최소_재현_절차">1. 앱 구성과 최소 재현 절차</a></li>
<li><a href="#배포처_후보_비교와_cloud_run_선택">2. 배포처 후보 비교와 Cloud Run 선택</a></li>
<li><a href="#back4app_containers의_임시_url_만료">3. Back4app Containers의 임시 URL 만료</a></li>
<li><a href="#cloud_run_전환에서_걸린_두_가지">4. Cloud Run 전환에서 걸린 두 가지</a></li>
<li><a href="#데이터베이스_리전을_도쿄로_옮기고_잰_응답_시간">5. 데이터베이스 리전을 도쿄로 옮기고 잰 응답 시간</a></li>
<li><a href="#netlify_프록시가_더하는_지연">6. Netlify 프록시가 더하는 지연</a></li>
<li><a href="#이_구성의_제약">7. 이 구성의 제약</a></li>
<li><a href="#참고_자료">8. 참고 자료</a></li>
</ul>
</div>
<div id="preamble">
<p>Markdown으로 짧은 메모를 쌓는 TIL(Today I Learned) 기록장을 만들어 <a href="https://til.benelog.net/">til.benelog.net</a>에 올렸습니다.
기능은 단순합니다. 글을 쓰고, 고치고, 지웁니다.
그래서 관심은 기능이 아니라 <strong>개인 앱 하나를 계속 띄워 두는 데 무엇을 고르는가</strong>에 있었습니다.</p>
<p>조건은 두 가지였습니다. 운영 비용이 들지 않아야 하고, 주소가 항상 살아 있어야 합니다.
결과만 적으면 배포처는 Google Cloud Run(<code>asia-northeast3</code>, 서울), 저장소는 Turso(<code>aws-ap-northeast-1</code>, 도쿄), 도메인은 Netlify의 프록시입니다.
여기까지 오는 동안 배포처를 세 번 바꿨고, 그 과정에서 확인한 사실을 정리합니다.</p>

</div>
<div>
<h2 id="앱_구성과_최소_재현_절차">1. 앱 구성과 최소 재현 절차</h2>
<div>
<p>앱은 Go 표준 <code>net/http</code>와 htmx로 만들었습니다.
웹 프레임워크는 쓰지 않았고, 화면 갱신은 htmx가 HTML 조각을 갈아 끼우는 방식입니다.
의존성이 전부 순수 Go라 CGO 없이 정적 바이너리로 빌드되고, distroless 이미지가 28MB입니다.</p>
<p>처음부터 끝까지 따라 하려면 다음 순서입니다.</p>
<div>
<ol>
<li>
<p>Turso에서 도쿄 리전 그룹과 데이터베이스를 만들고 토큰을 발급합니다.</p>
<div>
<pre><code data-lang="bash">turso group create tokyo --location aws-ap-northeast-1
turso db create til --group tokyo
turso db tokens create til</code></pre>
</div>
</li>
<li>
<p>GCP 프로젝트에 결제 계정을 연결하고 API 세 개를 켭니다. 결제 계정 연결은 무료 한도만 쓸 때도 필요합니다.</p>
<div>
<pre><code data-lang="bash">gcloud billing projects link &lt;project&gt; --billing-account=&lt;ACCOUNT_ID&gt;
gcloud services enable run.googleapis.com cloudbuild.googleapis.com artifactregistry.googleapis.com</code></pre>
</div>
</li>
<li>
<p>기본 컴퓨트 서비스 계정에 빌드 권한을 부여합니다. 이 단계를 건너뛰면 첫 배포가 실패합니다.</p>
<div>
<pre><code data-lang="bash">gcloud projects add-iam-policy-binding &lt;project&gt; \
  --member=serviceAccount:&lt;projectNumber&gt;-compute@developer.gserviceaccount.com \
  --role=roles/cloudbuild.builds.builder</code></pre>
</div>
</li>
<li>
<p>저장소 루트에서 배포합니다. <code>--source .</code>가 Cloud Build로 Dockerfile을 빌드합니다.</p>
<div>
<pre><code data-lang="bash">gcloud run deploy til --source . --region asia-northeast3 \
  --allow-unauthenticated --env-vars-file run-env.yaml</code></pre>
</div>
</li>
<li>
<p>배포된 URL을 Netlify의 <code>proxy/_redirects</code>에 적고 푸시합니다. 그때부터 til.benelog.net이 그 서비스를 가리킵니다.</p>
</li>
</ol>
</div>
<p>환경변수는 YAML 파일로 넘깁니다. 커맨드라인에 토큰이 남지 않고, 한 번 넣으면 서비스에 저장되므로 다음 배포부터는 <code>--env-vars-file</code>을 생략해도 됩니다.</p>
</div>
</div>
<div>
<h2 id="배포처_후보_비교와_cloud_run_선택">2. 배포처 후보 비교와 Cloud Run 선택</h2>
<div>
<p>처음 세운 조건은 "카드 등록 없이 상시 가동"이었습니다.
찾아본 결과를 정리하면 아래와 같습니다.</p>
<table>
<colgroup>
<col>
<col>
<col>
</colgroup>
<thead>
<tr>
<th>후보</th>
<th>무료 조건</th>
<th>걸린 점</th>
</tr>
</thead>
<tbody>
<tr>
<td><p>Google Cloud Run</p></td>
<td><p>월 2M 요청, 360,000 GiB-초, 180,000 vCPU-초</p></td>
<td><p>무료 한도만 써도 <strong>열려 있는 결제 계정 연결이 필수</strong>입니다. 결제 계정이 닫혀 있으면 API 활성화조차 되지 않습니다.</p></td>
</tr>
<tr>
<td><p>Back4app Containers</p></td>
<td><p>컨테이너 1개, 256MB RAM / 0.25 CPU</p></td>
<td><p>카드가 필요 없습니다. 대신 무료 요금제의 주소가 임시라 만료되면 배포가 삭제됩니다.</p></td>
</tr>
<tr>
<td><p>Render</p></td>
<td><p>Free web service, workspace당 월 750시간</p></td>
<td><p>15분 동안 요청이 없으면 컨테이너가 중지되고, 복귀에 30초에서 1분이 걸립니다.</p></td>
</tr>
<tr>
<td><p>Hugging Face Spaces</p></td>
<td><p>CPU Basic, 공개 Space 한정</p></td>
<td><p>유휴 시 중지됩니다. 데이터베이스 이름과 화면이 공개됩니다.</p></td>
</tr>
<tr>
<td><p>Northflank</p></td>
<td><p>프로젝트 1개, 서비스 2개</p></td>
<td><p>리소스를 생성할 때 카드 등록을 요구합니다. 무료 리전도 us-central과 europe-west뿐입니다.</p></td>
</tr>
<tr>
<td><p>Fly.io, Railway, Koyeb, Heroku</p></td>
<td><p>없음</p></td>
<td><p>Fly.io는 신규 조직 무료 할당을 폐지했고, Koyeb은 신규 가입자에게 무료 티어를 제공하지 않습니다.</p></td>
</tr>
</tbody>
</table>
<p>Northflank는 카드 요구로 먼저 제외했고, 다음으로 Back4app Containers를 골랐습니다.
카드 없이 GitHub 저장소를 연결하면 Kaniko가 Dockerfile을 빌드해 배포하고, 컨테이너가 중지되지 않아 콜드스타트도 관측되지 않았습니다.
여기까지는 조건에 맞았습니다.</p>
</div>
</div>
<div>
<h2 id="back4app_containers의_임시_url_만료">3. Back4app Containers의 임시 URL 만료</h2>
<div>
<p>배포한 지 30분이 되지 않아 til.benelog.net이 응답하지 않았습니다.
대시보드의 배포 로그에 원인이 그대로 남아 있었습니다.</p>
<div>
<p>Back4app Containers의 배포 로그 (UTC)</p>
<div>
<pre><code>2026-08-21T23:58:26Z  SYSTEM  LAUNCHING CONTAINER...
2026-08-21T23:59:19Z  SYSTEM  CHECKING HEALTH...
2026-08-21T23:59:20Z  SYSTEM  DEPLOYMENT READY
2026-08-22T00:27:12Z  SYSTEM  The Back4app custom domain has expired for free plan
2026-08-22T00:27:12Z  SYSTEM  COOLING DOWN...
2026-08-22T00:28:12Z  SYSTEM  FINISHING CONTAINER...
2026-08-22T00:28:12Z  SYSTEM  DEPLOYMENT DESTROYED</code></pre>
</div>
</div>
<p>컨테이너가 고장난 것이 아니라 <strong>무료 요금제의 임시 주소가 만료되면서 배포 자체가 삭제</strong>됐습니다.
그 사이 서비스는 정상이었고, 앱 로그에 <code>GET /</code> 요청이 200으로 남아 있습니다.
대시보드에는 "URL is temporary and will be live for 60 minutes"라는 안내가 있는데, 공식 문서에는 설명이 없습니다.</p>
<p>만료 시점은 재현하지 못했습니다.
위 사례는 <code>DEPLOYMENT READY</code> 이후 약 28분이고, 다른 때는 65분이 지나도 같은 주소가 살아 있었습니다.
안내문의 60분은 보장이라기보다 상한으로 보는 편이 안전하다고 판단합니다.</p>
<p>진단이 어려웠던 이유는 따로 있습니다.
만료된 주소가 <strong>한 번도 존재한 적 없는 서브도메인과 똑같은 응답</strong>을 돌려줍니다.</p>
<div>
<pre><code data-lang="bash">curl -sI https://til-nsh62xv6.b4a.run/healthz   # 실제로 만들었던 앱
curl -sI https://til-zzzzzzzz.b4a.run/healthz   # 존재한 적 없는 이름
# 둘 다: HTTP/2 404, "not found", x-cache: Error from cloudfront</code></pre>
</div>
<p>컨테이너가 죽었다면 502나 503이 나왔을 텐데 그렇지 않았습니다.
헤더까지 같아서 밖에서는 앱이 고장난 것인지 주소가 회수된 것인지 구분할 수 없습니다.
대시보드의 배포 로그를 봐야 알 수 있습니다.</p>
<p>여기에 재배포하면 주소 접미사가 바뀌는 문제가 더해집니다.
실제로 되살릴 때마다 <code>til-nsh62xv6</code>에서 <code>til-xu9uffq7</code>로 바뀌었고, 그때마다 Netlify의 <code>_redirects</code>를 고쳐야 했습니다.
잠깐 띄워 보여 주는 용도라면 쓸 만하지만, 주소가 항상 살아 있어야 한다는 조건에는 맞지 않았습니다.
영구 주소는 월 5달러 요금제부터입니다.</p>
<p>카드 등록을 받아들이기로 하고 Cloud Run으로 옮겼습니다.
개인 TIL 앱의 트래픽은 월 2M 요청 무료 한도 근처에도 가지 않으므로, 결제 계정을 연결해도 청구액은 0원입니다.
서울 리전을 쓸 수 있다는 점도 이유였습니다.</p>
</div>
</div>
<div>
<h2 id="cloud_run_전환에서_걸린_두_가지">4. Cloud Run 전환에서 걸린 두 가지</h2>
<div>
<div>
<h3 id="기본_서비스_계정의_빌드_권한_부족">4.1. 기본 서비스 계정의 빌드 권한 부족</h3>
<p><code>gcloud run deploy --source .</code>의 첫 실행이 실패했습니다.</p>
<div>
<pre><code>ERROR: (gcloud.run.deploy) PERMISSION_DENIED: Build failed because the default
service account is missing required IAM permissions.
... IAM permission denied for service account
788537242173-compute@developer.gserviceaccount.com</code></pre>
</div>
<p>Google이 기본 컴퓨트 서비스 계정의 빌드 권한을 축소한 뒤 새 프로젝트에서 나타나는 증상입니다.
<code>roles/cloudbuild.builds.builder</code>를 한 번 부여하면 해결됩니다.
앞의 재현 절차 3단계가 이것입니다.</p>
</div>
<div>
<h3 id="google_frontend가_가로채는_healthz_경로">4.2. Google Frontend가 가로채는 /healthz 경로</h3>
<p>배포 후 헬스 체크 경로를 확인하니 앱이 아니라 Google의 404 페이지가 돌아왔습니다.
앱은 정상이어서 <code>/</code>도 기록 목록도 잘 나오는데 <code>/healthz</code>만 그랬습니다.
경로를 바꿔 가며 확인한 결과입니다.</p>
<table>
<colgroup>
<col>
<col>
<col>
</colgroup>
<thead>
<tr>
<th>경로</th>
<th>응답</th>
<th>누가 응답했나</th>
</tr>
</thead>
<tbody>
<tr>
<td><p><code>/healthz</code></p></td>
<td><p>404</p></td>
<td><p>Google의 404 HTML. 컨테이너까지 도달하지 않습니다.</p></td>
</tr>
<tr>
<td><p><code>/healthz/</code></p></td>
<td><p>404</p></td>
<td><p><code>404 page not found</code>. Go의 <code>ServeMux</code>가 응답했습니다.</p></td>
</tr>
<tr>
<td><p><code>/health</code>, <code>/readyz</code></p></td>
<td><p>404</p></td>
<td><p><code>404 page not found</code>. 역시 앱까지 도달합니다.</p></td>
</tr>
<tr>
<td><p><code>/entries/2</code></p></td>
<td><p>200</p></td>
<td><p>앱이 정상 응답합니다.</p></td>
</tr>
</tbody>
</table>
<p><strong>정확히 <code>/healthz</code> 하나만</strong> 앞단에서 가로챕니다.
슬래시를 붙인 <code>/healthz/</code>는 그대로 통과하므로, 앱의 라우팅 문제가 아닙니다.
헬스 경로를 <code>/healthz</code>로만 열어 두면 모니터링이 조용히 실패합니다.
그래서 같은 핸들러를 <code>/health</code>에도 등록했습니다.</p>
<div>
<p>main.go</p>
<div>
<pre><code data-lang="go">// Cloud Run 앞단의 Google Frontend 가 정확히 /healthz 경로를 가로채 자체 404 를
// 돌려주므로(다른 경로는 그대로 통과) 헬스 경로를 /health 로도 열어둔다.
health := func(w http.ResponseWriter, r *http.Request) {
	w.Write([]byte("ok"))
}
mux.HandleFunc("GET /healthz", health)
mux.HandleFunc("GET /health", health)</code></pre>
</div>
</div>
</div>
</div>
</div>
<div>
<h2 id="데이터베이스_리전을_도쿄로_옮기고_잰_응답_시간">5. 데이터베이스 리전을 도쿄로 옮기고 잰 응답 시간</h2>
<div>
<p>저장소는 Turso(libSQL)입니다.
SQLite 파일 하나 분량의 데이터를 다루는 개인 앱에 맞고, 드라이버(<code>libsql-client-go</code>)가 순수 Go라 CGO 없는 이미지에 그대로 들어갑니다.
로컬 개발은 SQLite 파일을 쓰고 배포는 Turso를 쓰는데, 같은 <code>database/sql</code> 코드가 그대로 돕니다.</p>
<p>처음에는 데이터베이스를 <code>aws-us-east-2</code>(오하이오)에 두고 있었습니다.
앱을 서울 리전에 올려도 이 상태면 요청마다 태평양을 건너게 됩니다.
이 앱은 페이지 한 장을 그릴 때 질의를 한 번 보내므로, 데이터베이스 왕복이 응답 시간의 대부분입니다.</p>
<p>그룹을 도쿄로 옮기고 같은 조건에서 다시 쟀습니다.
앱은 제 노트북에서 실행했고, 바꾼 것은 접속할 데이터베이스뿐입니다.</p>
<table>
<colgroup>
<col>
<col>
</colgroup>
<thead>
<tr>
<th>Turso 그룹 위치</th>
<th>한국에서 <code>GET /</code></th>
</tr>
</thead>
<tbody>
<tr>
<td><p><code>aws-us-east-2</code> (오하이오)</p></td>
<td><p>197 ~ 220ms</p></td>
</tr>
<tr>
<td><p><code>aws-ap-northeast-1</code> (도쿄)</p></td>
<td><p>38 ~ 45ms</p></td>
</tr>
</tbody>
</table>
<p>코드도 앱의 위치도 그대로인데 5배 차이가 났습니다.
배포처 리전을 정하기 전에 데이터베이스 리전부터 맞추는 편이 낫습니다.</p>
<div>
<table>
<tbody><tr>
<td>
<p>Note</p>
</td>
<td>
<p>Turso 그룹의 primary 위치는 나중에 바꿀 수 없어서, 새 그룹을 만들어 옮겨야 합니다.
무료(starter) 요금제의 사용량 표시가 <code>groups 0/1</code>이라 그룹을 하나 더 만들지 못할 것처럼 보이는데, 실제로는 두 번째 그룹이 생성됐습니다.</p>
<p>옮기는 과정에서 확인한 것을 적어 둡니다.</p>
<div>
<ul>
<li>
<p><code>turso db create &lt;새 이름&gt; --group &lt;새 그룹&gt; --from-db &lt;기존 DB&gt;</code>는 그룹이 다르면 <code>record not found</code>로 실패합니다.</p>
</li>
<li>
<p><code>--from-dump</code>는 데이터베이스만 만들어지고 덤프가 적재되지 않은 채 종료된 경우가 있었습니다. 빈 데이터베이스가 남으므로 <code>select count(*)</code>로 확인해야 합니다.</p>
</li>
<li>
<p><code>turso db shell &lt;새 DB&gt; &lt; dump.sql</code>로 밀어 넣는 방법이 확실했습니다. <code>sqlite_sequence</code>와 인덱스도 함께 들어갑니다.</p>
</li>
<li>
<p>새 데이터베이스에는 토큰을 새로 발급해야 합니다.</p>
</li>
</ul>
</div>
</td>
</tr>
</tbody></table>
</div>
</div>
</div>
<div>
<h2 id="netlify_프록시가_더하는_지연">6. Netlify 프록시가 더하는 지연</h2>
<div>
<p>Back4app도 Cloud Run도 커스텀 도메인은 유료이거나 별도 설정이 필요합니다.
그래서 til.benelog.net은 Netlify에 두고, 모든 요청을 백엔드로 넘기는 rewrite 한 줄로 붙였습니다.</p>
<div>
<p>proxy/_redirects</p>
<div>
<pre><code>/*  https://til-788537242173.asia-northeast3.run.app/:splat  200</code></pre>
</div>
</div>
<p>상태 코드 <code>200</code>은 리다이렉트가 아니라 rewrite라서 주소창은 til.benelog.net으로 유지됩니다.
DNS와 TLS 인증서는 Netlify가 관리하므로 백엔드를 어디로 옮겨도 이 한 줄만 고치면 됩니다.</p>
<p>편리한 대신 지연을 냅니다.
같은 시점에 두 주소를 번갈아 호출해 봤습니다.</p>
<table>
<colgroup>
<col>
<col>
<col>
</colgroup>
<thead>
<tr>
<th>경로</th>
<th><code>GET /</code></th>
<th>TCP 핸드셰이크</th>
</tr>
</thead>
<tbody>
<tr>
<td><p>Cloud Run 주소로 직접</p></td>
<td><p>92 ~ 109ms</p></td>
<td><p>5.5ms</p></td>
</tr>
<tr>
<td><p>til.benelog.net (Netlify 경유)</p></td>
<td><p>328 ~ 384ms</p></td>
<td><p>71ms</p></td>
</tr>
</tbody>
</table>
<p>TCP 핸드셰이크가 71ms라는 것은 Netlify의 가장 가까운 접속 지점이 그만큼 떨어져 있다는 뜻입니다.
요청이 한국에서 그 접속 지점을 거쳐 다시 서울로 오므로, 서울 리전을 골라서 얻은 이득을 프록시가 되돌립니다.
데이터베이스를 도쿄로 옮겨 160ms를 줄였는데, 프록시 홉이 235ms를 더합니다.</p>
<p>커스텀 도메인이 유료인 배포처를 쓸 때는 유용한 방법이지만, 지연이 중요하면 배포처가 제공하는 도메인 매핑을 먼저 확인하는 편이 낫습니다.
저는 til.benelog.net 주소를 유지하는 쪽을 택했습니다. 개인 메모장이라 300ms대 응답으로도 충분하다고 판단했습니다.</p>
</div>
</div>
<div>
<h2 id="이_구성의_제약">7. 이 구성의 제약</h2>
<div>
<p>같은 방식을 검토하실 분을 위해 걸리는 점을 정리합니다.</p>
<div>
<ul>
<li>
<p><strong>Cloud Run은 결제 계정 연결이 필수입니다.</strong> 무료 한도 안에서만 써도 그렇습니다. 카드를 등록하지 않겠다는 조건이면 이 선택지는 빠집니다.</p>
</li>
<li>
<p><strong>Back4app 무료 요금제로는 상시 운영을 할 수 없습니다.</strong> 임시 주소가 만료되면 배포가 삭제되고, 되살릴 때마다 주소 접미사가 바뀝니다.</p>
</li>
<li>
<p><strong>자동 배포는 따로 설정해야 합니다.</strong> GitHub 연동으로 푸시할 때마다 배포되던 Back4app과 달리, Cloud Run은 <code>gcloud run deploy</code>를 직접 실행합니다. Cloud Build 트리거를 붙이면 자동화할 수 있습니다.</p>
</li>
<li>
<p><strong>Netlify 프록시는 응답 시간을 200ms 이상 늘립니다.</strong> 위의 실측값 그대로입니다.</p>
</li>
<li>
<p><strong>Turso 무료 요금제의 그룹 위치는 나중에 바꿀 수 없습니다.</strong> 처음 만들 때 앱이 뜰 리전에 맞춰야 합니다.</p>
</li>
</ul>
</div>
<p>배포처를 Northflank, Back4app, Cloud Run으로 옮기는 동안 저장소 접근 코드와 Dockerfile은 한 줄도 바꾸지 않았습니다.
Turso가 SQLite이고 이미지가 표준 컨테이너라서, 옮기는 비용이 설정 파일 몇 줄에 그쳤습니다.
무료 요금제의 조건이 자주 바뀌는 영역에서는 이렇게 옮기기 쉬운 구성이 선택 자체보다 중요하다고 생각합니다.</p>
</div>
</div>

    </div>

    

    
</div></div>

JBake

Table of Contents
1. 앱 구성과 최소 재현 절차
2. 배포처 후보 비교와 Cloud Run 선택
3. Back4app Containers의 임시 URL 만료
4. Cloud Run 전환에서 걸린 두 가지
5. 데이터베이스 리전을 도쿄로 옮기고 잰 응답 시간
6. Netlify 프록시가 더하는 지연
7. 이 구성의 제약
8. 참고 자료
Markdown으로 짧은 메모를 쌓는 TIL(Today I Learned) 기록장을 만들어 til.benelog.net에 올렸습니다.
기능은 단순합니다. 글을 쓰고, 고치고, 지웁니다.
그래서 관심은 기능이 아니라 개인 앱 하나를 계속 띄워 두는 데 무엇을 고르는가에 있었습니다.
조건은 두 가지였습니다. 운영 비용이 들지 않아야 하고, 주소가 항상 살아 있어야 합니다.
결과만 적으면 배포처는 Google Cloud Run(asia-northeast3, 서울), 저장소는 Turso(aws-ap-northeast-1, 도쿄), 도메인은 Netlify의 프록시입니다.
여기까지 오는 동안 배포처를 세 번 바꿨고, 그 과정에서 확인한 사실을 정리합니다.
소스는 benelog/til에 있습니다.
같은 시기에 만든 DoltHub에 데이터를 저장하는 애플리케이션과는 저장소 선택의 방향이 반대입니다.
그쪽은 데이터를 사용자 계정에 두고, 이쪽은 제 계정 하나에 둡니다.
1. 앱 구성과 최소 재현 절차
앱은 Go 표준 net/http와 htmx로 만들었습니다.
웹 프레임워크는 쓰지 않았고, 화면 갱신은 htmx가 HTML 조각을 갈아 끼우는 방식입니다.
의존성이 전부 순수 Go라 CGO 없이 정적 바이너리로 빌드되고, distroless 이미지가 28MB입니다.
처음부터 끝까지 따라 하려면 다음 순서입니다.
Turso에서 도쿄 리전 그룹과 데이터베이스를 만들고 토큰을 발급합니다.
turso group create tokyo --location aws-ap-northeast-1
turso db create til --group tokyo
turso db tokens create til
GCP 프로젝트에 결제 계정을 연결하고 API 세 개를 켭니다. 결제 계정 연결은 무료 한도만 쓸 때도 필요합니다.
gcloud billing projects link <project> --billing-account=<ACCOUNT_ID>
gcloud services enable run.googleapis.com cloudbuild.googleapis.com artifactregistry.googleapis.com
기본 컴퓨트 서비스 계정에 빌드 권한을 부여합니다. 이 단계를 건너뛰면 첫 배포가 실패합니다.
gcloud projects add-iam-policy-binding <project> \
  --member=serviceAccount:<projectNumber>-compute@developer.gserviceaccount.com \
  --role=roles/cloudbuild.builds.builder
저장소 루트에서 배포합니다. --source .가 Cloud Build로 Dockerfile을 빌드합니다.
gcloud run deploy til --source . --region asia-northeast3 \
  --allow-unauthenticated --env-vars-file run-env.yaml
배포된 URL을 Netlify의 proxy/_redirects에 적고 푸시합니다. 그때부터 til.benelog.net이 그 서비스를 가리킵니다.
환경변수는 YAML 파일로 넘깁니다. 커맨드라인에 토큰이 남지 않고, 한 번 넣으면 서비스에 저장되므로 다음 배포부터는 --env-vars-file을 생략해도 됩니다.
2. 배포처 후보 비교와 Cloud Run 선택
처음 세운 조건은 "카드 등록 없이 상시 가동"이었습니다.
찾아본 결과를 정리하면 아래와 같습니다.
후보
무료 조건
걸린 점
Google Cloud Run
월 2M 요청, 360,000 GiB-초, 180,000 vCPU-초
무료 한도만 써도 열려 있는 결제 계정 연결이 필수입니다. 결제 계정이 닫혀 있으면 API 활성화조차 되지 않습니다.
Back4app Containers
컨테이너 1개, 256MB RAM / 0.25 CPU
카드가 필요 없습니다. 대신 무료 요금제의 주소가 임시라 만료되면 배포가 삭제됩니다.
Render
Free web service, workspace당 월 750시간
15분 동안 요청이 없으면 컨테이너가 중지되고, 복귀에 30초에서 1분이 걸립니다.
Hugging Face Spaces
CPU Basic, 공개 Space 한정
유휴 시 중지됩니다. 데이터베이스 이름과 화면이 공개됩니다.
Northflank
프로젝트 1개, 서비스 2개
리소스를 생성할 때 카드 등록을 요구합니다. 무료 리전도 us-central과 europe-west뿐입니다.
Fly.io, Railway, Koyeb, Heroku
없음
Fly.io는 신규 조직 무료 할당을 폐지했고, Koyeb은 신규 가입자에게 무료 티어를 제공하지 않습니다.
Northflank는 카드 요구로 먼저 제외했고, 다음으로 Back4app Containers를 골랐습니다.
카드 없이 GitHub 저장소를 연결하면 Kaniko가 Dockerfile을 빌드해 배포하고, 컨테이너가 중지되지 않아 콜드스타트도 관측되지 않았습니다.
여기까지는 조건에 맞았습니다.
3. Back4app Containers의 임시 URL 만료
배포한 지 30분이 되지 않아 til.benelog.net이 응답하지 않았습니다.
대시보드의 배포 로그에 원인이 그대로 남아 있었습니다.
Back4app Containers의 배포 로그 (UTC)
2026-08-21T23:58:26Z  SYSTEM  LAUNCHING CONTAINER...
2026-08-21T23:59:19Z  SYSTEM  CHECKING HEALTH...
2026-08-21T23:59:20Z  SYSTEM  DEPLOYMENT READY
2026-08-22T00:27:12Z  SYSTEM  The Back4app custom domain has expired for free plan
2026-08-22T00:27:12Z  SYSTEM  COOLING DOWN...
2026-08-22T00:28:12Z  SYSTEM  FINISHING CONTAINER...
2026-08-22T00:28:12Z  SYSTEM  DEPLOYMENT DESTROYED
컨테이너가 고장난 것이 아니라 무료 요금제의 임시 주소가 만료되면서 배포 자체가 삭제됐습니다.
그 사이 서비스는 정상이었고, 앱 로그에 GET / 요청이 200으로 남아 있습니다.
대시보드에는 "URL is temporary and will be live for 60 minutes"라는 안내가 있는데, 공식 문서에는 설명이 없습니다.
만료 시점은 재현하지 못했습니다.
위 사례는 DEPLOYMENT READY 이후 약 28분이고, 다른 때는 65분이 지나도 같은 주소가 살아 있었습니다.
안내문의 60분은 보장이라기보다 상한으로 보는 편이 안전하다고 판단합니다.
진단이 어려웠던 이유는 따로 있습니다.
만료된 주소가 한 번도 존재한 적 없는 서브도메인과 똑같은 응답을 돌려줍니다.
curl -sI https://til-nsh62xv6.b4a.run/healthz   # 실제로 만들었던 앱
curl -sI https://til-zzzzzzzz.b4a.run/healthz   # 존재한 적 없는 이름
# 둘 다: HTTP/2 404, "not found", x-cache: Error from cloudfront
컨테이너가 죽었다면 502나 503이 나왔을 텐데 그렇지 않았습니다.
헤더까지 같아서 밖에서는 앱이 고장난 것인지 주소가 회수된 것인지 구분할 수 없습니다.
대시보드의 배포 로그를 봐야 알 수 있습니다.
여기에 재배포하면 주소 접미사가 바뀌는 문제가 더해집니다.
실제로 되살릴 때마다 til-nsh62xv6에서 til-xu9uffq7로 바뀌었고, 그때마다 Netlify의 _redirects를 고쳐야 했습니다.
잠깐 띄워 보여 주는 용도라면 쓸 만하지만, 주소가 항상 살아 있어야 한다는 조건에는 맞지 않았습니다.
영구 주소는 월 5달러 요금제부터입니다.
카드 등록을 받아들이기로 하고 Cloud Run으로 옮겼습니다.
개인 TIL 앱의 트래픽은 월 2M 요청 무료 한도 근처에도 가지 않으므로, 결제 계정을 연결해도 청구액은 0원입니다.
서울 리전을 쓸 수 있다는 점도 이유였습니다.
4. Cloud Run 전환에서 걸린 두 가지
4.1. 기본 서비스 계정의 빌드 권한 부족
gcloud run deploy --source .의 첫 실행이 실패했습니다.
ERROR: (gcloud.run.deploy) PERMISSION_DENIED: Build failed because the default
service account is missing required IAM permissions.
... IAM permission denied for service account
788537242173-compute@developer.gserviceaccount.com
Google이 기본 컴퓨트 서비스 계정의 빌드 권한을 축소한 뒤 새 프로젝트에서 나타나는 증상입니다.
roles/cloudbuild.builds.builder를 한 번 부여하면 해결됩니다.
앞의 재현 절차 3단계가 이것입니다.
4.2. Google Frontend가 가로채는 /healthz 경로
배포 후 헬스 체크 경로를 확인하니 앱이 아니라 Google의 404 페이지가 돌아왔습니다.
앱은 정상이어서 /도 기록 목록도 잘 나오는데 /healthz만 그랬습니다.
경로를 바꿔 가며 확인한 결과입니다.
경로
응답
누가 응답했나
/healthz
404
Google의 404 HTML. 컨테이너까지 도달하지 않습니다.
/healthz/
404
404 page not found. Go의 ServeMux가 응답했습니다.
/health, /readyz
404
404 page not found. 역시 앱까지 도달합니다.
/entries/2
200
앱이 정상 응답합니다.
정확히 /healthz 하나만 앞단에서 가로챕니다.
슬래시를 붙인 /healthz/는 그대로 통과하므로, 앱의 라우팅 문제가 아닙니다.
헬스 경로를 /healthz로만 열어 두면 모니터링이 조용히 실패합니다.
그래서 같은 핸들러를 /health에도 등록했습니다.
main.go
// Cloud Run 앞단의 Google Frontend 가 정확히 /healthz 경로를 가로채 자체 404 를
// 돌려주므로(다른 경로는 그대로 통과) 헬스 경로를 /health 로도 열어둔다.
health := func(w http.ResponseWriter, r *http.Request) {
	w.Write([]byte("ok"))
}
mux.HandleFunc("GET /healthz", health)
mux.HandleFunc("GET /health", health)
5. 데이터베이스 리전을 도쿄로 옮기고 잰 응답 시간
저장소는 Turso(libSQL)입니다.
SQLite 파일 하나 분량의 데이터를 다루는 개인 앱에 맞고, 드라이버(libsql-client-go)가 순수 Go라 CGO 없는 이미지에 그대로 들어갑니다.
로컬 개발은 SQLite 파일을 쓰고 배포는 Turso를 쓰는데, 같은 database/sql 코드가 그대로 돕니다.
처음에는 데이터베이스를 aws-us-east-2(오하이오)에 두고 있었습니다.
앱을 서울 리전에 올려도 이 상태면 요청마다 태평양을 건너게 됩니다.
이 앱은 페이지 한 장을 그릴 때 질의를 한 번 보내므로, 데이터베이스 왕복이 응답 시간의 대부분입니다.
그룹을 도쿄로 옮기고 같은 조건에서 다시 쟀습니다.
앱은 제 노트북에서 실행했고, 바꾼 것은 접속할 데이터베이스뿐입니다.
Turso 그룹 위치
한국에서 GET /
aws-us-east-2 (오하이오)
197 ~ 220ms
aws-ap-northeast-1 (도쿄)
38 ~ 45ms
코드도 앱의 위치도 그대로인데 5배 차이가 났습니다.
배포처 리전을 정하기 전에 데이터베이스 리전부터 맞추는 편이 낫습니다.
Note
Turso 그룹의 primary 위치는 나중에 바꿀 수 없어서, 새 그룹을 만들어 옮겨야 합니다.
무료(starter) 요금제의 사용량 표시가 groups 0/1이라 그룹을 하나 더 만들지 못할 것처럼 보이는데, 실제로는 두 번째 그룹이 생성됐습니다.
옮기는 과정에서 확인한 것을 적어 둡니다.
turso db create <새 이름> --group <새 그룹> --from-db <기존 DB>는 그룹이 다르면 record not found로 실패합니다.
--from-dump는 데이터베이스만 만들어지고 덤프가 적재되지 않은 채 종료된 경우가 있었습니다. 빈 데이터베이스가 남으므로 select count(*)로 확인해야 합니다.
turso db shell <새 DB> < dump.sql로 밀어 넣는 방법이 확실했습니다. sqlite_sequence와 인덱스도 함께 들어갑니다.
새 데이터베이스에는 토큰을 새로 발급해야 합니다.
6. Netlify 프록시가 더하는 지연
Back4app도 Cloud Run도 커스텀 도메인은 유료이거나 별도 설정이 필요합니다.
그래서 til.benelog.net은 Netlify에 두고, 모든 요청을 백엔드로 넘기는 rewrite 한 줄로 붙였습니다.
proxy/_redirects
/*  https://til-788537242173.asia-northeast3.run.app/:splat  200
상태 코드 200은 리다이렉트가 아니라 rewrite라서 주소창은 til.benelog.net으로 유지됩니다.
DNS와 TLS 인증서는 Netlify가 관리하므로 백엔드를 어디로 옮겨도 이 한 줄만 고치면 됩니다.
편리한 대신 지연을 냅니다.
같은 시점에 두 주소를 번갈아 호출해 봤습니다.
경로
GET /
TCP 핸드셰이크
Cloud Run 주소로 직접
92 ~ 109ms
5.5ms
til.benelog.net (Netlify 경유)
328 ~ 384ms
71ms
TCP 핸드셰이크가 71ms라는 것은 Netlify의 가장 가까운 접속 지점이 그만큼 떨어져 있다는 뜻입니다.
요청이 한국에서 그 접속 지점을 거쳐 다시 서울로 오므로, 서울 리전을 골라서 얻은 이득을 프록시가 되돌립니다.
데이터베이스를 도쿄로 옮겨 160ms를 줄였는데, 프록시 홉이 235ms를 더합니다.
커스텀 도메인이 유료인 배포처를 쓸 때는 유용한 방법이지만, 지연이 중요하면 배포처가 제공하는 도메인 매핑을 먼저 확인하는 편이 낫습니다.
저는 til.benelog.net 주소를 유지하는 쪽을 택했습니다. 개인 메모장이라 300ms대 응답으로도 충분하다고 판단했습니다.
7. 이 구성의 제약
같은 방식을 검토하실 분을 위해 걸리는 점을 정리합니다.
Cloud Run은 결제 계정 연결이 필수입니다. 무료 한도 안에서만 써도 그렇습니다. 카드를 등록하지 않겠다는 조건이면 이 선택지는 빠집니다.
Back4app 무료 요금제로는 상시 운영을 할 수 없습니다. 임시 주소가 만료되면 배포가 삭제되고, 되살릴 때마다 주소 접미사가 바뀝니다.
자동 배포는 따로 설정해야 합니다. GitHub 연동으로 푸시할 때마다 배포되던 Back4app과 달리, Cloud Run은 gcloud run deploy를 직접 실행합니다. Cloud Build 트리거를 붙이면 자동화할 수 있습니다.
Netlify 프록시는 응답 시간을 200ms 이상 늘립니다. 위의 실측값 그대로입니다.
Turso 무료 요금제의 그룹 위치는 나중에 바꿀 수 없습니다. 처음 만들 때 앱이 뜰 리전에 맞춰야 합니다.
배포처를 Northflank, Back4app, Cloud Run으로 옮기는 동안 저장소 접근 코드와 Dockerfile은 한 줄도 바꾸지 않았습니다.
Turso가 SQLite이고 이미지가 표준 컨테이너라서, 옮기는 비용이 설정 파일 몇 줄에 그쳤습니다.
무료 요금제의 조건이 자주 바뀌는 영역에서는 이렇게 옮기기 쉬운 구성이 선택 자체보다 중요하다고 생각합니다.
8. 참고 자료
benelog/til — 이 글에서 설명한 저장소
Cloud Run 요금 — 무료 한도와 리전별 단가
Cloud Run: 빌드 서비스 계정 — PERMISSION_DENIED가 나올 때 확인할 문서
Back4app Containers 요금 — 무료 요금제의 조건
Turso CLI: group — 그룹 생성과 리전 지정
Netlify: Rewrites and proxies — 상태 코드 200 rewrite
DoltHub에 데이터를 저장하는 애플리케이션 개발 — 같은 시기에 만든 앱. 데이터를 사용자 계정에 두는 반대 방향의 선택
이 포스트는 Claude Code와 정상혁이 함께 작성했습니다.

개인 TIL 앱의 배포처와 데이터베이스 리전 선택

댓글