사례 연구: 무료 모델 티어에서 지루한 CI 작업 하나를 처리하게 하는 골든 세트 게이트

요약: 출력 계약(output contract)을 먼저 고정하고 모든 스왑마다 골든 세트로 게이팅하면, 좁고 고객에게 직접 노출되지 않는 작업 하나를 무료 모델 티어에서 운영할 수 있습니다. 이 사례 연구에서는 CI 로그 분류 CLI, 즉 어떤 모델이 해당 작업을 처리할지 결정하는 작은 하네스(harness)와 제가 의도적으로 수동으로 남겨둔 부분들을 설명합니다.

배경: 매우 엄격한 계약을 가진 지루한 작업 하나

triage는 실패한 CI 작업의 원시 로그를 읽어 정확히 하나의 버킷, 하나의 간결한 이유, 그리고 하나의 증거 라인 번호를 출력합니다. 이 버킷들은 의도적으로 지루하게 설정되어 있습니다: flaky_test, missing_env, dep_conflict, oom, timeout, permission, 그리고 unknown. 토론 봇(discussion bot)이 그 결과를 풀 리퀘스트 스레드에 게시하므로, 잘못된 레이블보다 형식이 잘못된 객체가 더 큰 피해를 줍니다. 이 작업은 낮은 수준이지만 0이 아닌 볼륨으로 유료 API에서 실행되어 왔으며, 이는 무료 티어에서 테스트할 가치가 있는 정확한 프로필입니다.

MonkeyCode는 무료 모델 접근과 무료 서버 옵션을 제공하는 오픈 소스 프로젝트이며, 운영자는 이 두 가지를 현재 서비스의 일부라고 설명합니다. 공개 고지: 본 기사는 MonkeyCode의 제품 아웃리치(product outreach)의 일환으로 작성되었습니다. 저는 의도적으로 토큰 할당량이나 어떤 머신 상세 정보도 인용하지 않는데, 이는 그러한 수치가 자주 바뀌기 때문에 튜토리얼에 있는 오래된 숫자는 아무 숫자도 없는 것보다 더 나쁘기 때문입니다. 무언가를 규모를 잡기 전에 프로젝트의 실시간 이용 약관을 확인하세요.

목표, 그리고 제가 변경하기를 거부한 것들

목표는 좁았습니다: 모델 뒤에 있는 triage의 stdout 계약이 바뀔 수 있게 되더라도, 이 계약은 바이트 단위로 동일하게 유지하는 것이었습니다.

stdout에 정확히 세 개의 키를 가진 하나의 JSON 객체, 성공 시 종료 코드 0.
모든 unknown 버킷은 여전히 사람에게 라우팅되어야 합니다. 왜냐하면 그곳에 침묵하는 잘못됨이 숨어 있기 때문입니다.
모델 스왑은 런타임 실험(runtime experiment)이라기보다는 검토 가능한 diff여야 합니다.
전체 확인 과정은 푸시마다 실행될 수 있도록 1분 이내에 완료되어야 합니다.

비목표들 또한 중요합니다. 왜냐하면 범위 확장(scope creep)이 무료 티어 실험을 사고로 변질시키는 방식이기 때문입니다.

스트리밍 기능 없음, 채팅 인터페이스 없음, 분류기 주변의 다중 턴 에이전트 루프도 없음.
유료 모델과의 일반적인 동등성(parity)을 주장하지 않으며, 오직 이 하나의 고정된 작업에 대한 동등성만 주장함.
새로운 모델을 자동으로 승격시키지 않음; 사람이 의도적으로 해당 변경 사항을 병합함.

결정 테이블: 무료 티어 자격을 얻을 만한 작업은?

이것을 어댑터 코드를 작성하기 전에 필터로 사용하세요.

작업	사용자에게 보이는가	출력의 엄격성	이동할까?
CI 로그 분류(triage)	아니요, 내부 봇 전용	하나의 열거형(enum)과 두 개의 필드	예
...

패턴은 간단합니다: 엄격하고 기계가 검사 가능한 출력에 더해 내부 사용자가 존재할 때 무료 티어가 자리를 얻습니다.

아티팩트: 골든 세트와 작은 게이트

여기서 하니스(harness)는 프롬프트가 아니라 프로젝트의 지속적인 부분입니다. 먼저 레이아웃을 설정하고, 모든 숫자는 코드 옆 버전 관리에 보관하세요.

triage/
├── adapter.py       # 제공업체에 대해 아는 유일한 파일
├── golden.py        # 점수 측정 및 스왑 게이트
...

1단계: 코드에서 계약을 고정하기(freeze the contract in code)

어떤 모델과 통신하기 전에 검증기(validator)를 작성하세요. 왜냐하면 그것이 전체 작업의 완료 정의가 되기 때문입니다.

#!/usr/bin/env python3
# golden.py — 고정된 계약에 따라 모델을 점수 측정하고, 스왑을 게이트함.

...

2단계: 불가능한 사례를 포함하여 작은 골든 세트 구축하기

이 작업에는 익명화된 로그 30개가 충분했지만, 그중 5개는 의도적으로 진정으로 모호하도록 작성되었습니다.

하나의 명확한 원인과 안정적인 예상 버킷을 가진 로그 25개.
두 가지 원인이 동등하게 그럴듯하여 예상 버킷이 unknown인 로그 5개.
예상 답변은 각 로그 옆에 JSON으로 저장되고 피처(fixture)처럼 검토됨.
호스트 이름, 토큰, 리포지토리 이름은 기기에서 나가는 모든 것 전에 익명화됨.

그 모호한 5개 행이 세트에서 가장 가치 있는 항목입니다. 왜냐하면 그것들은 자신 있게 추측하는 모델을 잡아내기 때문입니다.

3단계: 오직 하나의 제공업체 인식 파일 유지하기

네트워크 엔드포인트에 관한 모든 정보는 adapter.py에 있으며, 아래 모양은 예시이므로 제공업체의 실제 API와 일치시키세요.

# adapter.py — 이 파일은 작고 지루하게 유지하세요.
import os, json, urllib.request

...

4단계: 스키마(schema) 점수화가 우선, 정확도(accuracy)는 차선책

스키마 실패는 측정하기 쉽지만 무시하기에는 비용이 많이 들기 때문에 보고서에서 가장 먼저 다뤄져야 합니다.

import json

PROMPT = '''당신은 CI 실패 로그를 분류합니다.
...

'): # 모델들은 펜스(fences)를 좋아함
raw = raw.split('
', 1)[1].rsplit('```', 1)[0]
return json.loads(raw)

def score(cases):
...


### 5단계: 게이트 탈출을 0이 아닌 값으로 만들기

숫자만 출력하는 게이트는 대시보드일 뿐이며, 대시보드는 바쁜 주간에는 무시되기 마련입니다.

```
GATE = {'schema_pass': 1.00, 'bucket_drop': 0.05, 'abstain_recall': 0.80}

def verdict(result, baseline):
...
```

`verdict`를 `main`에 연결하고, 원시 점수들을 `results/<date>.json`에 기록하며, 해당 이유 목록이 비어있지 않을 때마다 코드 1로 종료하세요.

## 노트북 대신 무료 서버에서 게이트 실행하기

노트북에서만 실행되는 검사는 여행하는 주간에는 작동을 멈추는 검사입니다. 운영자(operator)의 무료 서버 옵션은 이 단계에 적합한데, 왜냐하면 하네스(harness)가 GPU나 사적인 데이터, 그리고 결과 디렉터리를 넘어서는 장기 상태를 필요로 하지 않기 때문입니다.

```
# nightly, 이미 신뢰하는 호스트에서
python golden.py --baseline baseline.json --out results/$(date -u +%F).json
echo exit=$?   # 0은 현재 모델이 여전히 통과함을 의미
```

골든 로그는 익명으로 유지하고, 결과는 리포지토리 내부에 보관하며, 밤샘 작업(nightly job)이 임의로 모델을 교체하도록 절대 두지 마세요.

## 결과: 하네스가 실제로 결정하는 것들

아래의 정확한 수치들은 예시적인 드라이 런(dry run)이므로, 어떤 것을 신뢰하기 전에 반드시 자체 기준선(baseline)과 비교하여 재현해 보세요.

| Signal | Illustrative dry run | Gate rule |
| --- | --- | --- |
| schema_pass | 1.00 | must equal 1.00 |
| ... | 
The 유용한 결과는 점수 자체가 아니라 실패 목록입니다. 대부분의 거부된 후보들은 버킷 라벨에서가 아니라 `keys` 또는 `reason_long`에서 실패했으며, 이는 더 나은 모델이 아니라 프롬프트 강화(prompt hardening)가 실제 해결책이었음을 의미합니다.

## 배운 교훈 (Lessons learned)

1.  주변을 둘러보기 전에 계약(contract)을 고정하세요. 왜냐하면 움직이는 목표물은 공정하게 평가될 수 없기 때문입니다.
2.  스키마 준수(schema conformance) 점수를 먼저 확인하세요. 왜냐하면 잘못된 라벨보다 형식이 잘못된 객체(malformed object)가 자동화를 더 조용히 망가뜨리기 때문입니다.
3.  최소한 다섯 가지 불가능한 사례를 유지하세요. 왜냐하면 자신감 있는 추측은 가장 큰 피해를 주는 실패 모드이기 때문입니다.
4.  제공자 지식(provider knowledge)을 하나의 작은 파일로 제한하여 교체 시 비즈니스 로직에 영향을 미치지 않도록 하세요.
5.  게이트 출구(gate exit)를 0이 아니게 만드세요. 왜냐하면 자문 검토(advisory check)는 제안일 뿐이며, 제안은 마감 기한을 이길 수 없기 때문입니다.

## 이 접근 방식을 사용해서는 안 되는 경우 (Who should not use this approach)

출력이 고객에게 보이는 산문(customer-visible prose)인 경우, 잘못된 답변이 법적 또는 재정적 파급 효과(blast radius)를 가져오는 경우, 또는 시간이 지남에 따라 아무도 레이블링된 예시를 유지하지 않을 것이라면 이 접근 방식을 건너뛰세요. 또한 무료 티어에서 필요한 꼬리 행동(tail behavior)을 제공하지 못할 수 있는 지연 시간(latency)-중요 경로(critical paths)의 경우에도 건너뛰는 것이 좋습니다. 이 방법은 내부적이고, 지루하며, 기계로 확인할 수 있는 작업에만 적합하고 그 외에는 거의 적합하지 않습니다.

## 이것이 어디에 속하는지에 대한 마무리 노트 (A closing note on where this fits)

이미 유료 모델을 위해 골든 세트(golden set)를 유지하고 있다면, 동일한 하네스(harness)를 무료 티어에 가리키는 것은 반나절의 비용으로 여러분 자신의 계약에 대한 실제 답변을 얻게 해줍니다. 자체 로그로 자신만의 수치를 실행해보고, 그 다음 게이트가 낙관론 대신 판단하도록 하세요.