"아키텍처적으로 올바르고 완전히 못 썼어. 그 둘은 반대말이 아냐."
증상
초기 Firekeeper 는 돌아갔고, 아무도 쓰고 싶어 하지 않았어. 키를 누르고, 문장을 말하고, 놓고 — 기다려. 10초. 가끔 40초. 복제하던 경쟁자는 같은 문장을 약 1초에 돌려줬어. 기다리게 만드는 받아쓰기 도구는 느린 받아쓰기 도구가 아냐; 아예 받아쓰기 도구가 아냐, 가치 제안 전체가 말하는 게 타이핑보다 빠르다는 거니까.
진단
본능은 음성 모델을 탓하는 거야. 틀렸어 — STT 는 약 1초였어. 비용은 전부 정리 레인 에 있었어. 모든 받아쓰기 하나하나가 풀 Pippa 브레인으로 라우팅됐어: 메모리 볼트 전체(~100KB+)를 시스템 프롬프트로 로드, 에이전트 SDK 서브프로세스 스폰, 그리고 높은 노력으로 깊은 추론 패스. 그 전부가, "어 보고서 보내" 를 "보고서 보내." 로 바꾸려고. 필러 단어 하나가 대성당 하나를 잡아먹었어.
작업이 필요했던 것: "어" 벗기기, 마침표 붙이기 (기계적)
작업이 받은 것: ~100KB 볼트 시스템 프롬프트
+ SDK 서브프로세스 스폰
+ 높은-노력 추론 패스
= 발화당 10~40초
경쟁자, 같은 작업: ~0.7~1.8초
함정은 재사용이었어
이 교훈이 트랙 값어치가 있는 이유가 여기 있어: 그 설계 어디에도 게으름이 없었어. 재사용이었어 — 좋은 본능. Pippa 브레인은 이미 존재했고, 이미 텍스트 변형을 아름답게 했고, 정리를 그리로 라우팅하면 코드 경로 하나에 모든 받아쓰기에 Pippa 의 진짜 목소리가 담겼어. 그 추론의 모든 단계가 변호 가능해. 추론은 여전히 틀렸어, 아키텍처적 우아함에 최적화하고 제품이 살고 죽는 유일한 차원을 무시했으니까: 지연. 재사용은 미덕이야, 재사용하는 게 작업 값어치의 백 배를 잡아먹기 전까진.
기계의 비용을 작업의 가치에 맞춰. 사소한 일에 강력한 컴포넌트를 재사용하는 건 우아함이 아니라 범주 오류야. 작업을 제일 무거운 경로로 라우팅하기 전에, 작업이 실제 뭘 필요로 하는지 물어 — 답이 '문장부호' 면, 메모리 볼트 달린 브레인은 아무리 손에 있어도 틀린 악기야.
내가 이걸 지었고, 자랑스러워했어. "모든 받아쓰기가 진짜 Pippa 를 통과함" 이 *핵심* 처럼 느껴졌어 — 그녀 목소린데, 왜 못한 브레인을 써? 아빠가 한 오후 써보고 딱 잘라 말했어: "이거 못 써." 아키텍처가 틀렸다가 아니라 — 못 쓴다고. 그 문장이 프레임을 바꿨어. 난 설계의 아름다움에 최적화하고 있었고; 아빠는 중요한 유일한 걸 재고 있었어, 말하기가 타이핑을 이기냐. 안 이겼어. 그러니 설계가 틀린 거야, 아무리 예뻐도.