첫 검증 가능한 Diff를 얻기까지 걸리는 시간

제가 실제로 신뢰하는 온보딩 지표는 설치에 걸리는 시간이 아니라, 도구가 제가 검증할 수 있는 diff를 제공하기까지 걸리는 시간입니다. 총 설치 시간은 체인 어딘가에서 무언가 잘못되었다고만 알려줄 뿐이며, 어느 연결 고리를 끊어야 하는지 말해주지는 못합니다. 그리고 바로 그 간극 때문에 많은 평가가 막연한 느낌(vibes)으로 끝납니다. 저는 AI 피로도에 대한 대화를 계속 접하게 되는데, 제 생각엔 이 중 상당 부분이 모델의 품질 문제가 아니라 아무도 현지화하는 데 신경 쓰지 않은 온보딩 마찰(onboarding friction) 때문입니다. 그래서 저는 이를 현지화하는 작은 도구를 만들었고, 이 도구가 산출한 수치는 제가 도구를 시험하는 방식을 바꾸어 놓았습니다.

이전에 저는 첫 15분을 측정하는 것에 대해 글을 썼고, 여전히 그 시계가 가치가 있다고 믿습니다. 문제는 단계별 기록(per-step ledger)이 없는 지속 시간은 진단이 아니라 판결이라는 것입니다. 전체 실행 시간이 11분이 걸렸다면, 제가 회원가입을 고칠지, 런타임을 고칠지, 문서를 고칠지, 아니면 제 프롬프트를 고쳐야 할까요? 단일 스톱워치 측정만으로는 답할 수 없으며, 잘못 추측하는 것이 사람들이 실제로 자신의 네트워크 문제였던 것을 도구가 느리다고 결론 내리는 방식입니다.

단계를 기록하고, 그 단계들을 순위화하기

아래의 하네스(harness)는 제품 래퍼가 아니라 템플릿이며, 제가 여기서 어떤 것도 측정했다고 주장하지 않을 것입니다. 이 코드가 출력하는 모든 숫자는 오직 사용자 본인의 장치에서, 사용자의 네트워크를 대상으로 한 첫 실행 결과에서 나온 것이며, 이것만이 전이 가능한 유일한 측정값입니다. 이는 각 단계 전환(phase transition)마다 하나의 JSON 라인을 작성하므로, 기록부(ledger)는 추가만 가능하고 나중에 재현할 수 있습니다. 여기 공급업체별 작업이 들어갈 자리 표시자 명령어와 함께 레코더를 보여드립니다.

#!/usr/bin/env bash
# step-ledger.sh — illustrative harness, not tied to any vendor CLI.
set -euo pipefail
...

규칙이 코드보다 중요하다. 문서화된 명령을 있는 그대로 복사해야 한다. 기억에 의존하여 바꿔 쓰면 문서를 확인하는 순간의 실패를 숨기게 되기 때문이다. 각 단계마다 짧은 메모를 태그로 달아라. 그 메모가 차트 위의 막대를 실행 가능한 불만 사항으로 바꾸어 주기 때문이다. 원장(ledger)을 손으로 편집하지 마라. 왜냐하면 손으로 수정한 측정값은 하나의 이야기가 되고, 이 연습이 대체하고자 하는 것이 바로 그런 이야기들이기 때문이다.

로그를 순위가 매겨진 불만 목록으로 변환하기

원시 로그(raw log)는 여전히 그저 로그일 뿐이다. 따라서 장치의 후반부는 비용별로 단계를 순위를 매기고 총합을 출력한다. 내림차순 정렬은 의도적이다. 가장 위에 있는 줄이 우선 시도해야 할 수정 사항이며, 그 아래의 모든 것은 이 하나가 해결될 때까지는 잡음(noise)에 불과하다. 프린터는 한 번에 읽기에 충분히 짧아서 중요하다. 왜냐하면 당신은 그것을 신뢰하고 싶어 할 것이기 때문이다.

#!/usr/bin/env python3
"""ledger.py — onboarding.jsonl을 순위가 매겨진 마찰 원장(friction ledger)으로 변환합니다."""
import json, sys
...

실행하면 signup 3.9s, install 214.0s, firsttask 41.2s와 같은 형태가 나오는데, 이 수치들은 어떤 도구에 대한 주장이라기보다는 형식(format)을 보여주기 위한 예시일 뿐이다. 흥미로운 부분은 가장 큰 줄이 모델이나 회원 가입 과정(signup)이 아니라 로컬 런타임 설치(local runtime install)인 경우가 얼마나 자주 있는가 하는 점이다. 또한 이는 사람들이 재시도할 때 건너뛰는 단계이며, 이 때문에 기계가 단순히 따뜻해졌을 때 두 번째 시도가 더 빨랐다고 결론 내리게 만든다.

중요했던 단 하나의 수정 사항

이것은 어떤 모델이 답변했는지와는 아무 관련 없이 숫자를 가장 많이 움직인 변경 사항이다. 첫 번째 작업을 검증 가능한 diff로 끝나야 하는 작업으로 대체하라. 이미 정답을 알고 있는 두 파일짜리 고정값(fixture)을 사용한다. 채팅 응답은 처음 15분 동안은 반증할 수 없다(unfalsifiable); 실패한 테스트에 대한 diff는 그렇지 않다. 그래서 나는 모든 시도를 이렇게 시작한다.

mkdir -p fixture && cd fixture
printf 'def add(a, b):
    return a - b
' > calc.py
printf 'from calc import add
assert add(2, 3) == 5
' > test_calc.py
...

지금 첫 번째 프롬프트는 의도적으로 지루합니다: 실패하는 어설션(assertion)을 수정하고 설명이 아닌 패치(patch)를 반환하세요. 당신은 그 패치를 적용하고, pytest를 재실행하며, 실행 결과가 통과했는지 아니면 통과하지 않았는지를 알게 됩니다. 이는 온보딩 측정 지표가 인상(impression) 대신 부울 값(boolean)으로 끝남을 의미합니다. 저는 이 메트릭을 '첫 검증 가능한 diff까지 걸리는 시간'이라고 명명하며, 수많은 모호한 첫 실행 불만들을 스타일 논쟁 없이 도구 간에 비교할 수 있는 하나의 숫자로 압축시킵니다. 40분이 지나야 녹색 테스트(green test)에 도달하는 도구를 신뢰하겠습니까, 아니면 두 번째 도구가 관련 없는 모든 질문에도 아름답게 답변하면서도 단 4분 만에 도달하는 도구를 신뢰하겠습니까?

제로 비용 티어(zero-cost tier)가 장부를 바꾸는 방식

그 장부의 단계 중 두 가지는 순수한 오버헤드(overhead)이며, 어느 것도 그 도구에 대해 아무것도 가르쳐주지 못합니다. 하나는 결제 설정이고, 다른 하나는 편집 루프(edit loop) 자체가 당신에게 작동하는지 여부를 보기 전에 기계(machine)를 프로비저닝(provisioning)하는 것입니다. 오픈 소스 코딩 에이전트 프로젝트로 접한 MonkeyCode가 이 두 가지 문제를 모두 해결합니다. 결제 단계 없이 접근할 수 있고 무료 서버 옵션을 제공하기 때문에, 장부의 첫 번째 통과는 이 두 항목 중 어느 것도 없이 실행될 수 있습니다. 공개 고지: 본 기사는 MonkeyCode의 제품 홍보 활동의 일환으로 작성되었습니다. 무료 모델 액세스는 평가를 포기할 만큼 충분히 저렴하게 유지하는 부분이며, 솔직히 제가 가장 중요하게 생각하는 속성입니다.

저는 여기서 토큰 할당량(token allowance), 모델 목록(model list), 또는 서버 사양(server specification)을 인용하지 않을 것입니다. 왜냐하면 저는 지금 앉아 있는 곳에서 그것들을 확인할 수 없고 무료 티어는 조용히 변경되기 때문입니다. 프로젝트 자체 페이지가 현재 제한 사항과 약관에 대한 유일하게 정직한 출처이므로, 무엇인가를 구축하기 전에 반드시 읽어보십시오. 무료 경로는 실제로 재현성(reproducibility)이 필요한 파이프라인의 기반이라기보다는 첫 데이터 포인트를 얻는 방법으로 취급하십시오. 내일 다시 실행할 수 있는 장부가 예측할 수 없는 할인보다 더 가치가 있습니다.

이 접근 방식을 건너뛰어야 하는 사람들

만약 코드가 네트워크를 벗어날 수 없다면, 무료 서버 경로는 무의미하며 이 하네스(harness)는 당신이 애초에 비용을 지불하지 않았을 마찰력만을 측정하는 데 도움을 줄 뿐입니다. 만약 팀이 SSO, 감사 로그(audit logs), 그리고 결정론적 모델 고정(deterministic model pinning)이 필요하다면, 첫 실행 시간 단축은 잘못된 축을 최적화하는 것이며, 원장(ledger)에는 그저 잘못된 제약 조건만 기록될 것입니다. 그리고 이미 신뢰할 수 있는 작동 루프를 가지고 있다면, 이 도구는 불필요합니다. 왜냐하면 더 이상 온보딩(onboarding) 과정이 아니기 때문에 국소화(localize)할 것이 아무것도 없기 때문입니다.

다른 모든 사람들에게 있어 전송 가능한 아티팩트(artifact)는 약 60줄의 셸(shell)과 Python 코드이며, 이는 다음 분기에 포기하든 어떤 도구를 사용하든 살아남을 것입니다. 만약 비용이 들지 않는 첫 번째 테스트가 이 도구를 실행하기 저렴하게 만든다면, 거기서부터 시작하고, 숫자의 자체 사본을 유지하며, 원장의 최상단 라인이 내일 무엇을 수정해야 할지 결정하도록 하십시오.