무료 모델이 실제 데이터에 접근하기 전에 거쳐야 할 일곱 가지 실행 가능 게이트

목표는 작습니다. 자유 모델이 설정 파일 하나를 정리하게 하는 것입니다. 위험은 작지 않습니다. 파일을 작성하는 모델은 사용자의 권한을 가진 프로그램입니다.

저는 이 체크리스트들을 산문(prose)으로 충분히 작성했습니다. 아무도 산문을 실행하지 않습니다. 그래서 이번에는 체크리스트가 스크립트입니다. 이는 0이 아닌 코드를 반환합니다 (exits non-zero). 증거를 기록하고, 계속하는 것을 거부합니다.

전체 내용은 이렇습니다. 일곱 개의 게이트(gates), 하나의 증거 파일, 그리고 기계가 스스로 승인할 수 없다는 확고한 규칙입니다.

종료 코드가 체크박스를 능가하는 이유

체크박스는 약속입니다. 종료 코드(exit code)는 사실입니다. 게이트가 실패하면, set -e는 쓰기 작업이 발생하기 전에 파이프라인을 중단시킵니다.

이것이 "우리가 보통 확인한다"와 "진행할 수 없다"의 차이점입니다. 지금 어떤 것을 가지고 있는지 스스로에게 물어보세요.

1단계: 실제로 게이트를 설정할 수 있는 가장 작은 작업을 선택하라

리팩토링부터 시작하지 마십시오. 하나의 입력 파일과 하나의 출력 파일로 시작하십시오. 제 규칙은 다음과 같습니다: 작업은 사람이 60초 안에 읽을 수 있는 단일 diff에 들어맞아야 합니다.

먼저 계획을 텍스트로 작성하십시오. 이 계획은 나중에 위한 문서가 아니라 게이트의 입력입니다.

job: tidy-config
reads: ./input/app.toml
writes: ./out/app.toml
...

만약 writes 라인을 채울 수 없다면, 멈추십시오. 범위 게이트(scope gate)는 강제할 것이 아무것도 없습니다.

2단계: 모든 게이트를 하나의 파일에 넣으라

모든 게이트는 명령어(command)입니다. pass는 종료 코드 0을 의미합니다. 그 외의 것은 중단을 의미합니다.

#!/usr/bin/env bash
# readiness.sh — one AI task를 위한 fail-closed 체크리스트
set -euo pipefail
...

일곱 개의 gate 호출 라인입니다. 이것이 전체 체크리스트이며, 검토(review)에서 diff가 가능합니다.

3단계: 각 게이트가 실제로 무엇을 증명하는지 알라

아무것도 증명하지 못하는 게이트는 장식품입니다. 여기 진실된 열을 소개합니다.

일곱 개 게이트 중 여섯 개는 기계적인 것입니다. 나머지 하나는 사람입니다. 그렇게 유지하십시오.

4단계: 예산 게이트에 날카로움을 부여하라

기록하고 계속 진행하는 예산은 예산이 아닙니다. 호출을 감싸고 보내기 전에 카운트해야 합니다.

call.py — 한 요청, 하나의 제한, 재시도 없음

import os, json, urllib.request

...

재시도 루프는 없습니다. 재시도 루프는 2만 달러 예산을 6만 달러 청구서로 만드는 방법입니다. 호출이 실패하면 게이트가 실패하고 사람이 결정합니다.

단계 5: 무료 호스팅 환경의 역할

MonkeyCode는 오픈 소스 프로젝트이며, 호스팅된 측면에서는 무료 모델 접근과 무료 서버 옵션을 광고합니다. 팀은 현재 1천만 단위의 무료 토큰 할당량을 명시하고 있습니다. 무료 등급 수치는 변동하므로, 이 글을 포함하여 블로그 게시물에 의존하기보다는 프로젝트 페이지에서 오늘 날짜의 수치를 확인하세요.

공개 고지: 본 기사는 MonkeyCode의 제품 아웃리치(product outreach)의 일환으로 작성되었습니다.

여기서 얻는 것은 돈을 쓰지 않고 실제 엔드포인트에 대해 실패 게이트를 실행할 수 있는 능력입니다. 이것이 체크리스트 워크플로우에서 무료 등급의 목적입니다: 행복한 경로(happy one)뿐만 아니라 나쁜 경로(bad path)도 봐야 합니다.

무료 서버는 또한 중요한 경로에서 하드웨어 결정 요소를 제거합니다. 동일한 readiness.sh를 노트북이 아닌 박스에서도 실행할 수 있으며, 이것이 바로 롤백 게이트가 원하는 바입니다.

제공자가 문서화한 대로 BASE_URL과 MODEL을 설정하세요. 게이트 스크립트에 모델 이름을 하드코딩하지 마세요. 이름은 빨리 구식이 되므로 체크리스트는 그것들보다 오래 지속되어야 합니다.

단계 6: 기능을 배포하기 전에 실패 테스트(fixture)를 먼저 배포하라

반드시 실패해야 하는 입력 하나를 작성하세요. 제 것은 중복 키와 끝에 비밀 문자열 형태의 값이 있는 설정 파일입니다.

./readiness.sh jobs/tidy-config
# FAIL-CLOSED: boundary
# exit 1

위 출력은 기준점(benchmark)이 아니라 예상해야 할 형태입니다. 만약 나쁜 테스트 케이스가 통과한다면, 당신의 경계 게이트는 주석 처리된 추가 단계에 불과합니다.

전체 과정을 포기할 때

시작하기 전에 종료 기준을 설정하세요. 제 순서는 다음과 같습니다:

1. 두 개의 게이트를 한 시간 안에 자동화할 수 없다 → 작업을 보류(park)한다.
2. 롤백 복원(rollback restore)이 두 번 실패한다 → 쓰기 작업은 아직 안전하지 않다.
3. diff가 60줄을 초과한다 → 작업이 너무 컸으니 분리하라.
4. 무료 등급 대기가 인내심을 넘어서면 → 돈을 내거나 작업을 축소하고, 게이트를 제거하지 마라.

Criteria 4가 중요합니다. 호스트(host)가 느리다고 해서 게이트를 비활성화하고 싶은 유혹이 있습니다. 게이트를 삭제하고, 증거도 삭제하면, 다시 느낌(vibes)에 의존하게 됩니다.

명확히 밝히는 한계점들

이러한 게이트들은 모델의 품질이 아닌 프로세스를 입증합니다. 모델은 일곱 가지 모든 게이트를 통과할 수 있지만 여전히 잘못된 설정을 생성할 수 있습니다. 테스트가 여전히 필요합니다.

또한 이들은 사용자가 쓰기 경로(write path)를 제어한다고 가정합니다. 만약 도구가 데이터베이스에 직접 쓴다면, 스냅샷 게이트는 허구입니다. 그곳에서는 이 패턴을 사용하지 마십시오.

규제 데이터를 처리하거나, SLA가 필요하거나, 당일 내에 사람의 서명을 받을 수 없다면 이것은 건너뛰세요. 승인(signoff) 게이트는 당신을 영원히 막아설 것이며, 그것이 당신에게 올바른 동작입니다.

솔로 빌더나 작은 팀이 하나의 작은 AI 기능을 배포하는 경우, 이 스크립트는 대략 80줄이며, 오후 한 번 만에, 의존성 없이 완료할 수 있습니다.

다음 빌드를 바꿀 수 있는 질문 하나

자동화할 수 없는 게이트는 무엇인가요? 계속해서 수동 단계를 추가하고 결국 건너뛰게 되는 그 단계 말입니다. 바로 그 특정 단계에 제가 다음에 서명 확인(signature check)을 넣을 것입니다.