"해법은 더 빠른 브레인이 아니었어. 대부분의 받아쓰기가 브레인이 아예 필요 없다는 걸 알아챈 거였어."
통찰
진단은 정리가 너무 비싸다고 말했어. 순진한 해법은 '브레인을 더 빠르게' 야. 더 작은 모델, 덜한 추론. 진짜 해법이 더 나아. 브레인한테 아예 묻지 마. 받아쓰기 정리는 대부분 기계적이야. '어' 벗기고, 마침표 붙이고, 사전 용어 강제하고. 어느 것도 판단이나 기억이나 볼트가 필요 없어. 그걸 한 번 보고 나면 답이 더 빠른 대성당이 아니게 돼. 레인 네 개짜리 길이고, 그 일을 해낼 수 있는 제일 싼 레인을 타는 거지.
받아쓰기 레인들
DictationCleanupLane:
1. 결정론적 순수 코드, ~0ms -- 필러, 문장부호, 사전
2. 로컬 빠름 작은 Ollama 모델 -- 제한된 프롬프트, keep_alive, 강한 타임아웃
3. Pippa 유틸리티 Pippa, 볼트 없음 -- 추론 패스 없음, 유틸리티 모델
4. Pippa Full 대성당 -- 명시적 옵트인만
CommandCleanupLane:
풀-브레인 사다리 — 의도적, 지연 관용, 판단 필요받아쓰기 레인은 싼 쪽을 기본으로 두고 유저가 요청할 때만 올라가. 눈여겨볼 건 Pippa 유틸리티 레인이 비용 없이 Pippa 를 루프 안에 남겨 둔다는 거야. 같은 브레인인데 볼트 시스템 프롬프트도 없고 추론 패스도 없어. 알고 보니 'Pippa 처럼 들린다' 랑 'Pippa 기억을 통째로 로드한다' 는 애초에 같은 요구사항이 아니었던 거지. 우리가 그냥 묶어서 사고 있었을 뿐이고.
커맨드 레인은 대성당을 그대로 둬
이 분리가 우아한 건 아무것도 안 빼앗기 때문이야. 커맨드 모드는, 그러니까 '내 목소리로 더 간결하게' 같은 건 진짜 판단이 필요하고, 다시 써 달라고 부탁한 쪽이니까 한 박자 기다릴 마음도 의식적으로 있어. 그래서 커맨드 레인은 풀 브레인 사다리를 그대로 유지해. 대성당이 문제였던 적은 없어. 문장부호 찍는 데 그걸 쓴 게 문제였지. 이제 레인마다 비용이 작업에 맞고, 둘 다 옳아.
컴포넌트가 뭘 주느냐가 아니라 작업이 뭘 필요로 하느냐로 쪼개. 경로 하나가 요구사항이 크게 다른 일들을 다 떠맡고 있으면, 해법은 대개 레인이야. 싼 일엔 너무 느리고 비싼 일엔 너무 약한 어중간한 타협 설정이 아니라. 레인마다 자기 트래픽에 딱 맞게 두고, 작업이 실제로 필요한 걸 보고 보내.
기본값이 옮겨가면 옛 설정도 부드럽게 데려와. 느린 설정을 저장해 둔 유저가 해법이 나온 뒤에도 거기 갇혀 있으면 안 되잖아. Firekeeper 는 레거시 설정을 한 번 슬쩍 밀어 줘. 추론 노력이랑 지나치게 큰 컨텍스트 창을 상식적인 기본값으로 내리는 거야. 유저가 일부러 고른 값은 그대로 두면서. 아무 설정도 안 데려오는 해법은 배포 안 된 해법이야.