"짓기 전에 적어둔 숫자만이 네가 실패하고 있다고 말해줄 수 있어."
왜 예산을 적어 두나
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 라는 목표는 엔진이 데워져 있다고 전제해. 실행할 때 프리웜하는 게 최적화가 아니라 기능인 이유가 정확히 이거고. 예산이 두 번째 호출부터만 지켜진다면, 유저가 널 판단하는 건 첫 번째 호출이야. 그날 첫 누름에도 예산이 버티게 웜업을 설계해.