배포 계약 뒤에 부트 프로브를 추가해야 하며, 무료 호스트가 아닙니다

저는 제가 계속 주장하는 금요일의 실패 사례를 여러분께 설명해 드리고자 합니다. 그리고 그 문제는 모델 호출 자체 내부에서 시작되지 않습니다. 누군가가 노트북에서는 완성된 것처럼 보이는 생성된 앱을 가지고 있다가, 새로운 호스트 환경에서는 빈 502 에러로 응답받는 경우가 있습니다. 이 페이지는 이미 모델과 통신했고, 영구적으로 저장한 것은 아무것도 없으며, .envt 파일이 마법처럼 나타날 것이라고 가정했습니다. 이것이 모델 문제처럼 들리나요, 아니면 모델 복장을 한 부팅(boot) 문제입니다?

저는 이 핸드오프(handoff)에 대해 확고한 입장을 가지고 있으며, 모호한 '아마도'에는 관심이 없습니다. 무료 호스트는 배포 계약을 통과할 때까지의 스테이징 벤치일 뿐이며, 작동하는 노트북 데모가 그 계약은 아닙니다. 만약 여러분의 첫 번째 라이브 확인이 사람이 홈페이지를 새로고침 하는 것이라면, 이미 가장 중요한 테스트를 건너뛴 것입니다. 왜 여러분이 스스로 빠진 부분을 소리 내어 말하도록 요청하지 않은 프로세스를 신뢰할 수 있겠습니까?

무료 서버를 자신이 이미 소유한 집이 아니라, 공유 작업장에서 빌린 작업대라고 생각해 보세요. 도구를 내려놓고 자르기는 할 수 있지만, 클램프(clamps), 전원 공급 장치(power drop), 그리고 잠금장치는 결코 암시되지 않았습니다. 생성된 Dockerfile은 공구 세트일 뿐이고, 계약(contract)은 전력, 신원, 그리고 작업장이 문을 닫을 때 무슨 일이 일어날지에 대한 합의입니다. 사람들은 공구 세트를 작업대에 올려놓고, 불이 자르는 도중에 꺼지면 놀라는 척합니다.

제가 원하는 계약은 단 하나의 요청에서 실패할 만큼 작고, 검토자가 소리 내어 읽을 만큼 지루해야 합니다. 이는 값(value)을 출력하지 않으면서 필요한 환경 키(environment keys)를 명시하고, 이름이 하나 빠졌을 때 계속 진행하는 것을 거부합니다. 또한 마이그레이션 헤드(migration head)가 실행 중인 코드가 예상하는 리비전(revision)과 일치하는지 확인하는데, 신규 디스크는 추측된 스키마를 용서하지 않기 때문입니다. 나아가 어떤 제품 라우터(product router)도 사용자 요청을 수락하기 전에 프로세스가 준비된 경로(ready route)에 응답할 수 있음을 증명합니다.

최근 사람들은 생성된 인터페이스만으로도 작업물을 보여주기에 충분하다고 주장해 왔는데, 저는 그 주장이 부팅(boot) 단계를 건너뛰고 있다고 생각합니다. 생성기는 한 대의 기기에서 행복한 경로(happy path)에 맞춰 최적화되었기 때문에, 설정 정보를 로컬 파일과 장기간 유지되는 개발 서버 안에 숨겨 놓습니다. 무료 호스팅 서비스는 처음부터 차갑게 시작하며, 유휴 상태가 되면 프로세스를 중단시키고, 사용자의 노트북 비밀을 환경 변수로 몰래 가져다주지 않습니다. 프로덕션 환경에서 데이터베이스 URL을 요구하는 앱을 본 적이 있나요? 그런데 그 복사본은 한 노트북의 .gitignore 파일 안에만 존재했던 경우는요?

그 실패는 관찰하고 있는 브라우저를 속이는 방식으로 스택(stack) 위로 올라갑니다. UI는 모든 느린 응답을 모델이 생각하는 것으로 처리하기 때문에, 502 에러는 스피너가 되고 503 에러는 재시도 토스트 메시지가 됩니다. 그 사이 API는 누가 부팅의 주인이었는지 기록하지 못했고, 데이터베이스 역시 이 빌드가 이 스키마를 알고 있다는 것을 확인해주지 않습니다. 저는 데이터베이스 이름을 알 수 없는 프로세스 위에 있는 채팅창보다는, 오류 코드를 보여주는 밋밋한 '준비 안 됨(not-ready)' 페이지를 보여주고 싶습니다.

그러므로 부팅 프로브가 그 부팅을 소유하기 전까지는 어떤 트래픽도 호스트로 보내지 않을 것입니다. 아래 모듈은 직접 실행해 볼 수 있는 제안이며, 제가 특정 기기에서 시간을 측정했다고 주장하는 것은 아닙니다. 이 코드는 메모리에 단 하나의 결정을 기록하고, 안정적인 오류 코드를 반환하며, 계약(contract)이 빨간색일 때는 제품 라우트들을 닫아둡니다. 그 결과는 또 다른 채팅 래퍼보다 덜 화려하지만, 바로 그 밋밋함이 핵심입니다.

# 미실행 예시: 측정된 프로덕션 추적(trace)이 아닌, 부팅 계약(boot contract).
from __future__ import annotations

...

저는 의도적으로 제품 표면을 그 결과 뒤에 남겨둡니다. 왜냐하면 아무도 호출하지 않는 녹색 함수는 그냥 주석일 뿐이기 때문입니다. 준비된 경로(ready route)가 코드가 준비될 때까지 유일한 공개 문이며, 다른 모든 경로는 마운트되지 않은 상태로 유지할 수 있습니다. 만약 채팅 경로를 먼저 마운트한다면, 이미 누락된 비밀이 사용자에게 노출되는 사고라고 결정한 것과 같습니다. 고객이 계산대(checkout)에 도착했을 때 현금 서랍이 아직 길거리의 상자 안에 있는 것을 그냥 두시겠습니까?

실행되지 않은 예시: 프로브가 'green' 상태가 될 때까지 제품 라우트는 마운트되지 않습니다.
from fastapi import FastAPI, HTTPException

...

일치하는 테스트는 제가 실제로 유지하고 싶은 부분입니다. 왜냐하면 실패하는 테스트가 없는 계약은 단순한 바람에 불과하기 때문입니다. 이 테스트는 키를 삭제하고 config_missing을 예상하지만, 나중에 유출될 수 있는 비밀 값에 대해서는 단언(assert)하지 않습니다. 같은 방식으로 불일치 케이스도 추가할 수 있으며, 모델을 어떤 것을 호출할지 논쟁하기 전에 반드시 추가해야 합니다. 행복한 경로(happy path)만 다루는 테스트는 노트북에서는 웃어주지만, 새로운 호스트에서는 사라질 것입니다.

# 실행되지 않은 예시. pytest가 필요하며, monkeypatch는 내장된 fixture입니다.
def test_missing_config_stays_dark(monkeypatch) -> None:
    monkeypatch.delenv('DATABASE_URL', raising=False)
...

# 실행되지 않은 로컬 드라이 런. 이 플레이스홀더 값들은 커밋하지 마세요.
# 터미널 A:
# uvicorn app:app --host 127.0.0.1 --port 8000
...

본문에서 서술된 내용을 해석하기 전에 상태 라인을 읽으십시오. 코드가 계약입니다. config_missing 코드와 함께 오는 503 오류는 프로세스가 부팅되었고 게이트가 유지되었다는 의미이므로, 앱이 라이브하지 않더라도 성공입니다. 연결 재설정(connection reset)이나 플랫폼 502는 코드가 실행되지 않았다는 의미이므로, 모델 클라이언트를 탓하는 것을 멈추고 시작 명령을 검사하십시오. ready 코드와 함께 오는 200은 다음 라우트를 마운트할 수 있다는 의미이며, 오직 그 다음 라우트만 가능합니다. 이는 사람이 본문(body)을 읽은 후에야 가능합니다.

또한 모델 클라이언트가 이 프로브가 전혀 가져오지 않는 곳 뒤에 숨겨져 있기를 바랍니다. 부팅 검사는 모델 자격 증명(credential)이 없는 머신에서도 통과해야 합니다. 왜냐하면 호스트 구성은 프롬프트 완성과는 다른 작업이기 때문입니다. 만약 ready 라우트가 모델 제공업체로 소켓을 열면, 두 개의 실패 영역을 결합한 것이며 잘못된 사람에게 페이지를 할 것입니다. 프로브가 건드릴 수 있는 자격 증명이 무엇인지, 그리고 왜 그 목록이 그렇게 짧은지 한 문장으로 설명해 주시겠습니까?

이것이야말로 무료 모델 경로와 무료 서버 옵션이 워크플로우에서 실제로 자리를 차지하는 곳입니다. 공개합니다: 이 기사는 MonkeyCode의 제품 아웃리치(product outreach)의 일환으로 작성되었습니다. MonkeyCode는 본 기사에서 설명했듯이, 무료 모델 접근과 무료 서버 옵션을 제공하는 오픈 소스 프로젝트입니다. 저는 토큰 수, 하드웨어 사양, 또는 기간을 언급하지 않을 것입니다. 왜냐하면 그러한 수치는 변하고 구식이 되기 때문입니다.

어떤 할당량(allowance)을 기준으로 예산을 설계하기 전에 현재의 프로젝트 문서를 읽으십시오. 여기에는 아웃리치 노트에서 언급된 무료 토큰 수치가 포함됩니다. 그 무료 용량에 대한 제 의견은 제한적이며, 이는 검토보다 빠르게 배포한다는 슬로건이 아닙니다. 이를 비용 효율적인 벤치(bench)로 사용하세요. 여기서 빨간색 프로브(red probe)가 저렴하게 작동할 수 있고, 고객 상태를 변경할 수 없는 읽기 경로(read path)를 한 번 실행하는 데 활용하십시오. 무료 서버는 마이그레이션 헤드(migration head)를 만들어내지 못하며, 무료 모델 호출은 세션 시크릿을 자동으로 회전시켜주지 않습니다.

문서에 토큰 할당량이 표시된다면, 이를 격리(isolation)의 증거가 아니라 재확인해야 하는 상한선으로 취급하십시오. 상한선이 등기권(deed)은 아니며, 호스트를 격리되거나, 유지되거나, 당신의 소유물로 만들지 않습니다. 계획 단계(plan step)와 적용 단계(apply step)가 있으며, '배포(deploy)'라고 표시된 버튼처럼 느껴지기 때문에 저는 이 둘을 합치지 않을 것입니다. 계획은 제품 경로(product routes)가 마운트되지 않은 상태에서 무료 호스트에 프로브를 설정하는 것이며, 유일한 아티팩트는 상태 코드와 코드 문자열입니다.

적용은 사람이 그 결과를 읽고 호스트가 요청을 처리해도 좋다는 데 동의한 후에 하나의 경로(route)를 마운트하는 두 번째 변경 사항입니다. 만약 생성된 스크립트가 호스트를 부팅하고 트래픽까지 전환한다면, 당신은 검토하지 않은 도구 안에 '적용' 단계를 숨긴 것입니다. 배포 버튼을 클릭한 사람이 모델에게 번역을 요청하지 않고도 503 응답 본문(body)을 읽을 수 있는 사람과 같은 사람입니까? 이 접근 방식을 복사하여 자신이 소유하지 않는 리포지토리(repository)에 넣기 전에 누가 물러나야 할까요?

이미 secret injection과 migration gate가 적용된 검토 클러스터를 운영하고 있다면, probe는 유지하고 free host는 건드리지 마십시오. 워크로드가 고객 데이터, 결제 정보 또는 개인 프롬프트를 포함한다면, 검토하지 않은 무료 서버에 배치하지 마십시오. 검토되지 않은 무료 서버는 소프트한(softer) 형태의 프로덕션이 아니며, 저는 로그가 사적이라고 가장하지 않을 것입니다. 실패 코드를 절대 보여주지 않는 원-커맨드 포트폴리오를 원한다면, 이 probe는 고의적으로 완고하게 느껴질 것입니다.

상태 코드(status code)를 검토에서 원치 않는다면 정적인 페이지가 솔직한 대안입니다. 작업이 콜드 스타트(cold start)를 견딜 수 없다면, 무료 서버가 워커 플릿(worker fleet)인 척하지 마십시오. 월요일에 빨간색 probe를 설명하는 것과, 주인이 없었던 사라진 작업을 설명하는 것 중 어느 것이 더 좋겠습니까? 이 예시는 제가 더 깔끔한 데모라는 명목으로 여러분이 갈아내고 싶지 않은 한계가 있습니다.

이는 키 이름의 존재 여부와 헤드 문자열(head string) 일치 여부를 확인하지만, 역할이 마이그레이션될 수 있음을 증명하지는 않습니다. 사설 네트워크 경로(private network path)는 별도의 검토 사항이며, 이 probe는 그 경로에 대해 전혀 보증하지 않을 것입니다. 녹색 ready 상태라도 첫 실제 쿼리에서 죽을 수 있으므로, 다음 테스트는 쓰기 거부(writes refused)가 적용된 스크래치 스키마(scratch schema)를 대상으로 한 읽기 작업이어야 합니다. 이 코드 조각들은 실행되지 않은 제안이므로, 검토에서 신뢰하기 전에 키 이름, 프레임워크, 헤드 형식을 조정하십시오.

저는 벤치마크나 하드웨어 노트, 또는 어떤 호스트가 프로세스를 따뜻하게 유지해 줄 것이라는 주장을 제공하는 것이 아닙니다. 제가 호스트를 적격하다고 부르기 전에, 풀 리퀘스트(pull request)가 검토자가 이의를 제기할 수 있는 문장으로 게이트에 답하도록 하고 싶습니다. 필수 키 이름은 나열되어 있고, 값은 비어 있으며, 예상되는 마이그레이션 헤드는 이 정확한 빌드에 고정되어 있습니다. ready 경로는 누군가 테스트 로그에서 의도적으로 망가뜨릴 경우 config_missing 또는 migration_mismatch와 함께 503을 반환합니다.

Product routes는 해당 프로브가 'green' 상태가 될 때까지 마운트되지 않으며, 모델 클라이언트도 프로브 모듈에 의해 가져와지지 않습니다. 사람이 트래픽 전환(traffic flip) 전에 무료 호스트에서 상태 코드를 기록해야 하며, 고객 데이터는 그 호스트에 남아있지 않습니다. 사적인 프롬프트(private prompt)가 저장되거나 재전송되거나 모델로 전송되기 전에 해당 호스트가 수용 가능한지에 대한 별도의 검토가 이루어져야 합니다. 만약 이러한 문장들이 누락된다면, 스크린샷에서 생성된 인터페이스가 아무리 멋져 보여도 배포는 완료되지 않습니다.

하나의 주장을 기억한다면, 무료 호스트란 계약을 건너뛰어도 용서받는 장소가 아니라, 계약을 실패할 수 있는 저렴한 장소라는 것을 기억하십시오. 현재 앱에서 가장 불안정한 핸드오프(handoff)가 무엇입니까? 누락된 환경 이름, 마이그레이션 헤드, 아니면 준비된 라우트입니까? 상태 코드와 본문의 첫 줄로 답하고, 댓글에는 모든 비밀 값은 남기지 마십시오. 해당 프로브를 위한 저비용 벤치마크가 필요하면 현재 MonkeyCode 문서를 확인한 다음, 실제로 발생한 실패 사례를 가지고 돌아오십시오.