"짓기 전에 적어둔 숫자만이 네가 실패하고 있다고 말해줄 수 있어."
왜 예산을 적어둬
10~40초 재앙이 벌어진 건 부분적으로 '충분히 빠름' 이 뭔지 아무도 안 적어둬서야. 숫자가 없으면, 개별 결정 하나하나가 합리적으로 보여 — 당연히 정리는 똑똑해야지, 당연히 좋은 브레인을 써야지 — 그리고 총합이 조용히 못 쓰게 돼. 지연 예산은 유혹이 도착하기 전에 하는 약속이야. '이거 느린 것 같아' 를 '이건 예산을 8초 초과해' 로 바꿔, 그건 논쟁을 시작하는 대신 끝내는 논거야.
Firekeeper 의 예산
단축키 -> 녹음 시작 150 ms 미만 (웜 스타트 후)
첫 부분 전사 1.5 s 미만 (평범한 말)
최종 STT, 짧은 발화 1 s 미만
최종 STT, 30초 받아쓰기 3 s 미만 (Apple Silicon)
정리, 평범한 받아쓰기 2 s 미만 (데워진 로컬 모델)
# 각 단계가 숫자를 소유해. 합이 제품이야.예산이 단계별 이란 걸 봐. 그게 중요해: 단일 종단간 숫자는 네가 느리다고 말하지만 어디가 인지는 안 말해주고, 느린 단계가 빠른 단계 뒤에 숨을 수 있어. 단계별 예산은 퇴행이 자기 이름을 댄다는 뜻이야 — 정리가 2초를 넘으면, 마이크 코드를 뒤지러 안 가.
벤치마크 하니스가 진짜로 만들어
안 재는 예산은 소망이야. Firekeeper 는 녹음 클립을 각 엔진과 모델에 돌려 전사와 지연을 찍는 작은 벤치마크 CLI 를 실어, '뭐가 더 빠른가' 가 감이 아니라 데이터가 되게. 같은 규율이 정리 레인에 적용돼: 네 기계에서 단계별 비용을 못 재면, 다음에 순진해 보이는 재사용이 기어들 때 40초 버그를 다시 발견할 거야.
기능 쓰기 전에 예산을 써. 미리 정한 성능 목표는 설계 제약이고; 나중에 정한 건 합리화야. 각 단계가 처음부터 숫자를 소유하면, 모든 구현 선택이 자동으로 그것에 대조돼 — 그리고 조용히 30초를 더했을 선택이 실망한 유저한테 발견되는 대신 설계 시점에 거부돼.
웜 스타트는 변명이 아니라 예산의 일부야. 150ms 단축키-부터-녹음 목표는 데워진 엔진을 가정해 — 그게 정확히 실행 때 프리웜이 최적화가 아니라 기능인 이유야. 예산이 두 번째 호출에서만 달성 가능하면, 첫 호출이 유저가 널 판단하는 그거야. 그날 첫 누름에 예산이 버티게 웜업을 설계해.