S-TTS 실시간 음성 번역 자막

S-TTS 는 Chrome·VLC·Safari 등에서 재생 중인 영상의 음성을 실시간으로 인식해 한국어 자막을 화면 위에 띄우는 macOS 메뉴바 앱이다. 기본 모드는 음성 인식과 번역을 Mac 안에서 처리해 오디오를 외부로 보내지 않고, 품질이 필요하면 같은 Mac 의 로컬 LLM(Qwen3.8-27B)을 번역 엔진으로 고른다. macOS판은 본인이 지금도 쓰고 있고(본인 확인 2026-10-30), iOS·Android 프리뷰를 개발 중이며, 2.1 실시간성 개선과 Windows 이식은 2026-10-30부터 일시 중단했다.

• 영어 강의·컨퍼런스 영상과 VLC 로 여는 로컬 영상에는 한국어 자막이 없는 경우가 대부분이다. 유튜브 자동 번역은 유튜브 한정, 브라우저 번역 확장은 화면 텍스트만, macOS 라이브 캡션은 원문만 보여 준다.
• 콘텐츠(오디오·전사·번역)를 앱이 외부로 보내지 않아야 했다.

• 정의·기준: 1인 PO 로 문제 정의와 PRD(v1.0, 2026-08-15)를 쓰고, 단계마다 합격선을 먼저 정한 뒤 실측으로만 채택하는 규칙 — 「측정 없는 채택 금지, 미검증을 완료로 표시 금지」 — 을 세웠다.
• 결정: 로컬 LLM 모델을 지정했고(Qwen3.8-27B 4bit + MTP), Windows 범위(로컬 음성 인식, macOS 2.0 과 같은 기능), 세 플랫폼 병렬·준비된 순서로 출시·iOS 1차 범위·시험 기기 등 12개 항목(2026-10-29), iOS·Android 우선과 나머지 트랙 일시 중단(2026-10-30)을 정했다.
• 실기 시험: 60분 라이브 자막을 직접 보며 지연 체감을 확인했고, 다른 Mac 에 설치해 「잘 작동합니다」로 확인했으며, 실사용 중 Safari 캡처 불가와 메뉴바 아이콘 잘림을 찾아 고치게 했다.
• 구현 주체: 0.3~0.7 은 Claude Code 가 구현했고, 2.0 핵심 구현은 Codex 가 하고 Claude Code 가 구현 검토를 2회 했다. 이식은 Windows=Codex, iOS·Android=Claude Code 서브에이전트가 맡았다.

1. 재생 소스마다 대응하지 않고 OS 오디오 출력 지점 한 곳에서 잡는다. 소스별 대응은 끝이 없기 때문이다. Core Audio Process Tap 으로 앱별·시스템 전체 오디오를 캡처했고, 0.5.0 에서는 코드에 등록된 적 없는 재생기 소리에도 자막이 떴다.
2. 본 개발 전에 위험 검증(M0 스파이크)부터 닫는다. OS 내장 음성 인식·번역 API 의 실제 제약이 가장 큰 위험이었다. 번역 세션 수명주기(100문장 100/100, p50 380ms)와 전체화면 위 자막 표시를 첫날 실측으로 닫았고, 회고는 「이후 방향 전환이 한 번도 없었다」고 적었다.
3. 번역 엔진은 블라인드 평가 결과로 바꾼다. 라이브 60초에서 모은 6쌍 평가에서 Apple 번역은 충실도 2.8/5 였고, 주원인은 음성 인식 오류가 번역으로 번지는 것이었다. 그중 5쌍으로 두 엔진을 블라인드 비교해 로컬 LLM 이 합격선(충실도·자연스러움 4.0 이상, 치명 오역 0)을 넘자 기본 엔진으로 삼았고, 지연 p95 가 기준을 328ms 넘은 사실도 함께 기록했다.
4. 측정 없이는 채택하지 않는다. 2.1 개선안은 같은 코퍼스로 짝지어 측정해 판정했다. deadline 계산을 바꾼 R2a-1 은 원문 대체가 44~61% 로 늘어 불통과였고, R2b 개선 기능은 Apple 번역 모드에 채택했다. LLM 번역 모드에서는 지연 기준을 충족하지 못해 이 개선 기능을 기본으로 끈 상태다.

• 2026-08-15~17: PRD → M0 스파이크 → 60분 통합 시험(확정 자막 259건, 오류 0) → 4.4시간 연속 실행 → 첫 설치 파일 0.3.0, 다른 Mac 설치 확인.
• 2026-08-23: 실사용 피드백 반영 뒤 로컬 LLM 엔진(0.4.0), 입력 언어 자동 감지·시스템 전체 캡처(0.5.0), 명시 동의 뒤에만 텍스트를 보내는 GPT API 엔진(0.6.0), 다른 Mac 이 이 Mac 의 LLM 서버를 쓰는 원격 모드(0.7.0).
• 2026-10-19~21: 2.0.0 내부 검증 빌드 — 임시·확정 번역을 나누고 시간 예산을 두는 라이브 스케줄러, 로컬 영상 재생 동기화, Chrome 확장 브리지.
• 2026-10-21~30: 2.1 짝 측정(기준선 → R1 → R2a → R2b), 멀티플랫폼 계획과 공통 Core 설계 고정(Codex 5회 검증) 뒤 iOS·Android 프리뷰 개발.

• 안정성: 4.4시간 연속 실행에서 확정 자막 382건, 오류·overrun·크래시 0(2026-08-17). 메모리 증가율은 후반 3시간 8.14%/시간으로 기준(2%/시간 미만)에 미달했고, leaks 검사로 앱 코드 누수는 아님을 확인했다.
• 번역 품질: 블라인드 비교 5쌍에서 Apple 번역 → Qwen3.8-27B 로 충실도 2.6 → 4.4, 자연스러움 2.2 → 4.4, 치명 오역 3/5 → 0/5(2026-08-23).
• 로컬 LLM 서버: 같은 Mac(36GB)에서 MTP 적용 40.4 tok/s(단독 22.5 tok/s), 피크 메모리 17.1GB.
• 지연: 2.0 기준선을 파일 오디오 주입과 표시 대리지표(숨긴 자막 창의 문자열 반영)로 쟀을 때 구절 종료 → 첫 한국어 p50 은 영어 0.87초·일본어 0.90초로 목표 1.2초를 충족했고, p95 2.4/2.2초는 목표 2.0초에 미달했다(Apple 엔진, pilot 코퍼스 3회 중앙값, 2026-10-22). 자동 정렬 라벨을 쓴 측정이라 정식 출시 판정용은 아니다.
• R2b(2026-10-29): Apple 번역 모드의 원문 대체 비율이 영어 −12.4%p·일본어 −8.1%p 줄었다.

• 정식 배포 전 내부 빌드다(Developer ID 공증 없음). 2.0 출시 게이트 — 실서명 앱의 지연·품질·60분 시험, 실제 YouTube 광고·전체화면 — 는 수행 전이다.
• 지연 목표 중 p95·확정 표시·절 단위 성공률은 미달이고, 측정 코퍼스 라벨은 사람 검수 전이다.
• 장시간 실행 메모리 증가는 기준 미달이며 대응 방식 결정이 남아 있다.
• macOS판은 시스템 오디오만 캡처한다. 마이크(회의 발화)와 DRM 스트리밍은 범위 밖이다.
• 모바일은 초기 프리뷰다. Android 는 WAV 주입으로만 인식을 확인했고 iOS 는 실기 서명 전이다. 실제 자막 화면 캡처도 새로 찍어야 한다.

• macOS 앱: Swift 6, SwiftUI·AppKit, SpeechAnalyzer·SpeechTranscriber, Apple Translation framework, Core Audio Process Tap, AVFoundation. 번역 엔진은 Apple 번역·로컬 LLM Qwen3.8-27B(MLX 4bit + MTP, mlx_vlm 서버)·GPT API(동의 시).
• 연동·측정·이식: Chrome MV3 확장 + native messaging, Tailscale serve, Python 측정 스크립트, Kotlin(Android), C#·.NET(Windows).

• 도구가 한 일: 구현은 위 「구현 주체」대로 나눴다. PRD·실행계획·단계별 계획은 Codex 가 2회씩 적대적으로 검증했고(2.0 실행계획은 Claude Code 2회), 2.0 코드는 Claude Code 가 읽기 전용으로 2회 검토했다(1차 High 6·Medium 15, 2차 확정 High 0). 이식 에이전트는 각자 작업 트리에서 일하고 자원 잠금 런처로 빌드·측정이 겹치지 않게 했다.
• 본인이 한 일: 무엇을 만들지와 합격선, 측정 결과에 따른 채택을 정했다. 회고에 「Codex 지적이 전부 실제 문제로 확인됐다」와 「오진·무효 실험·기준 미달을 숨기지 않는다」를 남겨 다음 단계의 규칙으로 삼았다.