주말 빌드 로그: 무료 티어 데모 호스트의 콜드 스타트 테스트

주말 동안 배포하는 데모는 두 가지 상태 중 하나로 출시됩니다. 작가 자신의 노트북에서 작동하거나, 리뷰어들이 열게 될 호스트 환경에서 콜드 스타트로 작동하는 경우입니다. 이 두 상태 사이의 격차는 거의 항상 애플리케이션 코드 때문이 아닙니다. 그것은 대부분의 빌드 로그가 측정하지 않는 세 가지 호스트 속성 때문입니다.

핵심 결론: 사이드 프로젝트를 '완료'라고 부르기 전에, 실제 호스트에서 콜드 스타트 시간(cold-start time), 디스크 내구성(disk durability), 유휴/재시작 동작(idle/restart behavior)을 측정하세요. UI 폴리싱, 추가 엔드포인트, 모델 선택 등 다른 모든 것은 선택 사항으로 간주하십시오.

범위 축소: 세 가지 티어, 하나의 주말

아래 빌드 로그는 어떤 무료 티어 호스트에서도 재현될 수 있도록 작성되었습니다. 여기에 제품 벤치마크 숫자는 포함되어 있지 않은데, 이는 무료 티어의 동작이 지역별로 다르며 예고 없이 변경되기 때문입니다. 스크립트가 결과물(artifact)이며, 숫자는 여러분이 채워 넣어야 할 부분입니다.

빌드에 사용된 티어 배정:

티어 1 — 반드시 출시해야 함. /healthz 엔드포인트 하나, 읽기 전용 경로 하나, 콜드 스타트 프로브(cold-start probe), 내구성 프로브(durability probe), 그리고 복사 붙여넣기가 가능한 명령어가 포함된 README.
티어 2 — 금요일 측정 결과가 허락할 경우에만 출시. 시드 픽스처(Seed fixtures), 환경 플래그 뒤에 숨겨진 쓰기 경로 하나, 짧은 데모 스크립트.
티어 3 — 이번 주말에는 명시적으로 절대 아님. 인증(Auth), 다중 테넌트 데이터(multi-tenant data), 백그라운드 워커(background workers), 대시보드, 실제 데이터 마이그레이션 등.

티어를 정직하게 유지하는 규칙은 하나 있습니다. 티어 2 항목을 추가하려면 티어 1 항목을 제거하거나 데모 스크립트의 시간을 같은 양만큼 단축해야 합니다. 그렇지 않으면 이 티어 목록은 마감 기한이 붙은 위시 리스트가 되어버립니다.

무료 호스트가 데모를 망가뜨리는 세 가지 특정 방식

유휴 후 콜드 스타트. 프로세스가 잠드는(sleeps) 호스트는 200ms의 요청을 수 초에 달하는 시간으로 만듭니다. 링크를 가장 먼저 여는 리뷰어가 그 비용을 지불하게 됩니다.
휘발성 디스크. 런타임에 작성된 파일은 재시작 시 사라집니다. 마운트된 볼륨이 없는 컨테이너 내의 SQLite가 전형적인 사례입니다.
알 수 없는 재시작 정책. 감독자(supervisor)가 충돌한 프로세스를 재시작하는지, 그리고 얼마나 빨리 하는지는 보통 무료 티어에서는 문서화되어 있지 않습니다.

이러한 것들이 무료 호스팅을 피해야 할 이유는 아닙니다. 오히려 데모가 의존하는 부분이므로 측정해야 하는 이유입니다.

아티팩트 1: 콜드 스타트 프로브 (the cold-start probe)

이 프로브는 저장소를 임시 디렉터리로 복제하고, 설치하며, 부팅한 다음, 상태 엔드포인트가 응답할 때까지 폴링합니다.

#!/usr/bin/env bash
# cold-start.sh  <git-url>
# 측정 항목: 클린 체크아웃 -> 첫 번째 성공적인 /healthz 응답.
...

이것을 로컬에서 세 번, 호스트에서는 세 번 실행한 다음, BUDGET_MS를 관찰된 가장 느린 값의 약 두 배로 설정하세요. 이 단언문(assertion)은 금요일과 일요일 사이의 회귀(regressions)를 포착하기 위한 것이지, 속도 주장을 발표하기 위함이 아닙니다.

아티팩트 2: 내구성 프로브 (the durability probe)

내구성은 예/아니오 질문이며 답변하는 데 약 2분이 걸립니다. 디버그 경로를 환경 변수 뒤에 숨기고, 측정 후에 삭제하세요.

# 재시작 전
curl -s -X POST "$BASE/debug/token" -d "value=$(date +%s)" -o before.txt
# 호스트 자체 제어판 또는 CLI를 사용하여 서비스 재시작
...

일시적인 결과가 데모를 망치지는 않습니다. 이는 설계를 변경합니다: 읽기 경로는 이미지에 베이크된(baked) 고정 값(fixture)에서 제공되며, 런타임 쓰기는 README에 재시작 시 손실됨으로 선언됩니다.

아티팩트 3: 분류표 (the triage table)

속성	측정 방법	실패할 경우	데모를 그래도 진행할까요?
콜드 스타트	`cold-start.sh`을 호스트에 적용	정적인 워밍업 페이지를 보여주고 검토 전에 핑을 보냅니다	예, 실행 매뉴얼(runbook)에 워밍업 단계를 추가하여 진행합니다
...

표에 적용된 규칙: 실패한 속성은 문서화된 데모 단계가 되며, 절대 언급되지 않은 가정(unstated assumption)이 되지 않습니다.

무료 모델 액세스가 들어가는 곳

고지 사항: 이 문서는 MonkeyCode의 제품 홍보 목적으로 작성되었습니다. MonkeyCode는 무료 모델 액세스와 무료 서버 옵션을 제공하며, 둘 다 운영자가 제시하는 가용성 주장입니다. 따라서 모델 이름, 할당량(quota), 지역 및 약관이 변경될 수 있으므로, 계획을 세우기 전에 반드시 프로젝트 자체 페이지에서 최신 세부 정보를 확인하십시오. 이 문서에는 측정된 바가 없으므로, 할당량 수치, 하드웨어 사양 또는 벤치마크 결과는 언급되어 있지 않습니다.

무료 모델 액세스는 주말 동안의 작업 중 정확히 다음 세 가지를 처리합니다:

소규모로 직접 작성한 예시로부터 피처(fixture) 변형을 생성하는 것.
최종 diff로부터 README 초안을 작성하고, 이를 사람이 수정하는 것.
배포 실패 후 부팅 로그를 원인과 노이즈로 분류하는 것.

이는 라이브 데모의 요청 경로에 포함되어서는 안 됩니다. 페이지 로드마다 모델을 호출하는 데모는 검토자가 클릭할 유일한 요소에 네트워크 종속성을 추가합니다. 대신, 호출 횟수를 명시적으로 유지하십시오:

MAX_MODEL_CALLS = 3  # 작업만: 피처, README 초안, 로그 분류
calls = 0

...

무료 서버 옵션은 이 정도 규모의 데모에 가장 자연스러운 호스팅 환경이지만, 한 가지 주의할 점이 있습니다. 위의 프로브(probes)들이 제품 페이지가 아닌 데모를 유지할 수 있을지 결정합니다. 먼저 무료 티어에서 측정하고, 그 후에 README가 무엇을 약속하는지 결정하십시오.

의도적으로 생략된 부분

인증 (Authentication). 이 데모에는 사용자가 없으므로 사용자 모델이 없습니다.
쓰기에 대한 영속성 (Persistence for writes). 읽기 경로는 데모를 담고 있으며, 쓰기는 메모리에 남아 있습니다.
두 프로브 이상의 CI. 프로브만이 검토 경험을 보호하는 유일한 테스트입니다.
사용자 정의 도메인 (A custom domain). 기본 호스트 이름은 일요일 밤에 고장 날 수 있는 항목 하나를 줄여줍니다.

이 목록의 모든 항목은 알려진 격차(known gaps) 섹션 아래 README에 포함되어야 합니다. 알려지지 않은 격차를 발견한 검토자는 나머지 부분도 추측이라고 가정할 것입니다.

데모가 실제 사용자 데이터를 보유하는 경우, 무료 티어에서는 내구성(durability) 보장을 제공하지 못할 수 있습니다.
고객에게 가동 시간(uptime)이나 지연 시간(latency)에 대한 약속이 필요한 모든 것은 명시된 SLA를 가진 유료 호스팅을 사용해야 합니다.
이미 인프라를 운영하고 있는 팀은 이를 재사용해야 하며, 단지 주말 동안 두 번째 플랫폼을 추가하는 비용은 절약되는 것보다 더 많이 들 수 있습니다.
내구성 프로브(durability probe)는 디버그 경로에 쓰기 및 읽기를 수행합니다. 측정 후 해당 경로를 제거하고, 호스트의 약관이 프로브가 생성하는 트래픽을 허용하는지 확인하십시오.

일요일 밤 운영 매뉴얼 (Sunday-night runbook)

배포된 URL에 대해 cold-start.sh를 실행하고 그 횟수를 기록합니다.
서비스를 재시작하고, 데모 링크를 열어 첫 번째 요청 경로가 콜드(cold) 상태에서 작동하는지 확인합니다.
데모 스크립트를 처음부터 끝까지 소리 내어 진행해봅니다.
건너뛴 모든 항목이 README에 나열되어 있는지 확인합니다.
브랜치를 동결합니다. 5단계 이후로는 커밋하지 않습니다.

주말 사이드 프로젝트는 얼마나 많은 것을 담고 있느냐로 평가되지 않습니다. 월요일에 낯선 사람이 열어보고 그것이 하는 단 하나의 것(one thing)을 볼 수 있는지 여부로 평가됩니다. 만약 그 트레이드오프가 다음 주말과 맞다면, 무료 서버 옵션은 시작하기에 합리적인 장소입니다. README를 작성하기 전에 콜드 스타트 프로브를 실행하고, 측정 결과가 범위를 설정하도록 하십시오.