1. 문제 정리: STT는 세 가지 SLO
(1) 실시간 vs 배치: 회의는 p95와 WER, 아카이브는 피크 상주와 처리량이 지배합니다. (2) 통합 메모리 경쟁: 브라우저·NLE·STT가 대역을 공유합니다. (3) 체인 전체: VAD·리샘플·청크·후처리까지 포함해야 오판이 줄어듭니다.
2. MLX Whisper vs whisper.cpp
| 축 | MLX | whisper.cpp |
|---|---|---|
| 통합 | Python/MLX와 하류 LLM 재현 용이 | CLI·배치 팩토리에 강함 |
| 저지연 | 청크 정책을 명시 | TTFA p95 측정 필수 |
| 장시간 | 버퍼·프로세스 배치 점검 | 멱등 세그먼트 키 |
| 디버그 | mlx·가중치·샘플레이트 고정 | Metal·스레드·양자화 빌드 |
3. 다섯 단계 런북
- 오디오 계약 고정(16 kHz mono 등).
- 실시간·오프라인 큐 분리.
- 추적 가능한 샤딩과 세그먼트 ID.
- 피크 상주와 p95 동시 기록.
- 하류 LLM 동시성 제한(launchd 가이드).
4. 인용 가능한 숫자
- 32GB 인터랙티브 Mac: 배치 STT에 약 8GB 이상 여유 권장.
- E2E 700ms 미만: 청크 1.5s 이하에서 p95 먼저.
- 주 5시간 이상 낭비 시 원격 전용 워커 ROI 검토.
5. 원격 Mac 매트릭스
| 신호 | 조치 |
|---|---|
| 야간 큐 적체 + 동시 편집 | 고메모리 노드에 고정 워커(SSH/VNC) |
| 24/7 필요·노트북 슬립 | 상시 노드·데몬 감독 |
| STT+LLM 이중 피크 | 프로세스/머신 분리(스택) |
| 벤치 통과·지연 드리프트 | 샤드·샘플레이트 diff 우선 |
6. FAQ: 클라우드, 화자 분리, 포맷, WER, 원격 속도
클라우드 STT? 탄력은 좋지만 RTT·재시도·전송 요금을 WER과 같은 문서에 적으세요. 패킷 손실 아래에서 지연 SLO를 깨면 정확해도 사고입니다.
화자 분리 전/후? 화자별 자막이나 상담 품질이면 분리를 독립 단계로 검증하세요. 전체 초안만 필요하면 과한 분리가 경계 오류 연쇄를 만듭니다. 타임스탬프 거친 초안 후 고가치 클립만 사람이 손보는 게 현실적입니다.
WAV vs AAC? 오프라인은 무손실·고정 비트레이트로 디코더 경로를 고정하고, 실시간은 캡처 버퍼·먹스 지연이 지배합니다. WAV는 안정적인데 VBR에서 흔들리면 모델이 아니라 디코더·링 버퍼를 의심하세요.
WER 낮으면 출하? 고유명·숫자·통화 단위가 무너지면 계약 문단이 위험합니다. 도메인 어휘 적중과 숫자 샘플 대조를 별 KPI로 요구하세요.
원격이 더 빠름? 업로드·거대 JSON이 지배하면 느립니다. 전용 RAM·GUI 비경합·병렬 워커가 이점입니다. GPU 필수? 실사용 동시성에서 레인당 p95를 재고, 평균 RTF만 보지 마세요.
7. 운영 관점의 심화
2026년 전사는 로그와 재현성 문제입니다. 평균 RTF만 보면 첫 주에 무너집니다. 통합 메모리는 STT와 소형 LLM 공존을 가능하게 하지만 경합은 숨어 꼬리가 길어집니다. 야간 배치를 대화형 Mac에서 떼어내는 건 무한 가속이 아니라 예측 가능한 p95를 사는 일입니다.
블루투스 프로파일, 리샘플러 소버전, OS 패치가 타이밍을 바꿉니다. 수용 기준은 캡처→정규화→추론→후처리로 쪼개 한 번에 한 층만 바꾸세요.
인적 검수 경제도 중요합니다. 필러 오인과 금액 오인의 비용은 다릅니다. 계약·의료 등 고위험 구간을 태깅하고 구간 유형별 오류 밀도를 추적하세요. 검수 분을 돈으로 환산해 모델 업그레이드·노드 추가·샤드 조정으로 되돌려야 WER 튜닝에 주를 새지 않습니다.
OpenAI 호환 LLM이 있으면 긴 STT blob을 그대로 넣지 말고 JSON Lines/SSE로 청크·최대 길이·타임아웃을 정해 백프레셔를 보이게 하세요. 음성→텍스트→구조화는 세 개의 큐입니다.
8. 관측성
세그먼트 실패율, p95, 스왑 이벤트를 고정합니다. 셋 다 악화면 입력·디스크, 스왑만이면 멀티태스킹을 의심합니다.
| 지표 | 수집 | 1차 의심 |
|---|---|---|
| 세그먼트 실패율 | 천 세그먼트당 코드·재시도 | 샘플레이트 드리프트, 손상 프레임, 과민 VAD |
| p95 지연 | 고정 코퍼스 50회 | Metal 경로, 스레드 경합, 큐 적체 |
| 스왑 | 브라우저·NLE 타임라인 대조 | 헤드룸 부족, 레인 과다 |
9. 증거 패키지
고정 버전, 샤드 정책, 실시간/오프라인 SLO, 실패 ID 목록 외에 조용한 회의실·오피스 잡음·협대역 전화·동시 발화를 포함한 골든 세트와 일주일치 분위수(길이·동시·재시도)를 첨부하세요.
10. 마무리와 MACGPU
노트북은 반복에 강하지만 야간 공장·이중 피크엔 한계가 있습니다. 원격 Apple Silicon은 같은 Metal·오디오 스택으로 경합을 줄입니다. 고메모리 원격 Mac을 낮은 마찰로 시험하려면 CTA의 플랜을 확인하세요(별도 로그인 불필요).
최종 게이트: 목표 기기에서 골든 세트와 야간 샘플을 재실행하고 입력 계약·모델 리비전·샤드 ID·출력 체크섬을 로그로 복원할 수 있어야 합니다. 안 되면 RAM보다 관측성을 먼저 고치세요. 장애 대응 연락망도 같은 문서에 적어두면 온콜이 헛돌지 않습니다.
11. MLX 연구와 whisper.cpp 운영
Python/MLX로 실험하고 whisper.cpp·데몬으로 배치를 안정화하는 팀이 많습니다. 실패는 “내 노트북에선 됨”과 “서버에선 됨”의 구전입니다. 가중치·양자화·샘플레이트·샤드 경계를 단일 정본으로 묶고 릴리스 전 양쪽 WER·p95를 비교해 임계 넘으면 막으세요.
크리에이티브와 동일 기기를 쓰면 라이브 캡션과 마스터링용 장시간 전사를 다른 세션·LaunchAgent로 나누세요. Final Cut보내기 중 자막이 튀는 현상은 평균 RTF에 안 잡힙니다.
12. 용량·보안 최소선
처리량은 평균/p95 세그먼트 길이, 레인 수, 골든 오디오 RTF로 적산하고 재시도·핫픽스용 20~35% 헤드룸을 얹으세요. 브라우저 탭이 늘 때 스왑이 튀는데 표로 설명 못 하면 재무·운영 모두 설득이 어렵습니다. 임시 파일·덤프 유출을 막으려 암호화·짧은 스크래치·자동 삭제를 기본으로 하세요.
13. 스택 연동·원격 운용
요약·티켓 분류를 STT 직후에 붙이면 토큰 예산·KV를 공유하니 버스트를 어긋나게 하거나 여유를 측정으로 증명하세요. MLX 개발 환경·Ollama 검수·OpenAI 호환 API 가이드와 함께 읽으면 메모리 피크가 겹치는 지점을 미리 설계할 수 있습니다. 원격 Mac도 SSH/VPN/비특권 워커/중앙 로그를 본 서버급으로 적용하고, STT가 자동화의 미스터리 지연으로 보이지 않게 하세요.
워커를 배치 중간에 kill하고 노드를 재부팅해 중복 없이 재개되는지 짧게 리허설하세요. 한 번의 훈련이 데모급인지 프로덕션급인지 드러냅니다.
재무와의 대화에서는 “하루 몇 파일”이 아니라 분당 처리 분수·재시도율·인적 검수 비용으로 설명하세요. 클라우드 분당 요금과 온디바이스 CapEx를 비교할 때도 데이터 상주·온콜 시간을 같은 표에 넣어야 결정이 흔들리지 않습니다. 스크립트만 넘기고 수천 시간을 돌리는 문화는 큐·메트릭 없으면 마이크 달린 기술 부채이므로 최소한 작업 ID·구조화 로그·실패율 알림은 필수입니다.