이전 노트에서 DeepSRT가 클라우드를 떠난 이유를 다뤘다. 자연스러운 다음 질문: 왜 Mac 앱에 정착했나? 애초에 v1은 브라우저 확장이었다——그것도 무거운 확장. content script를 YouTube 페이지에 주입하고, 자막 요청을 가로채고, 이중 언어 자막을 남의 DOM 위에 겹쳐 그렸다.
"남의 DOM"——바로 그게 문제였다.
또 하나의 고양이와 쥐
이전 노트에서 중앙화된 수집을 플랫폼 리스크 시스템과의 고양이-쥐 게임이라고 했다. 브라우저 확장은 같은 게임을——상대를 둘로 늘려서——치른다. YouTube가 프론트엔드를 바꾸면 셀렉터가 깨지고 자막 오버레이가 어긋나고 기능이 하룻밤에 죽는다. 몇 번을 고쳤는지 셀 수도 없다. 브라우저 쪽 규제도 계속 조여온다: 확장의 백그라운드 프로세스는 더 이상 상주할 수 없고, 확장이 할 수 있는 일의 규칙은 해마다 바뀐다.
제품이 두 플랫폼의 규칙이 교차하는 지점에 살고 있는데, 어느 쪽도 당신에게 빚진 게 없다.
상주는 하나의 능력이다
네이티브 앱이 사주는 것 중 가장 저평가된 것이 "상주"다. DeepSRT는 당신의 Mac에서 로컬 API(127.0.0.1)를 계속 열어둔다——확장은 이걸 할 수 없다. 백그라운드 프로세스가 플랫폼의 회수 주기를 살아남지 못하기 때문이다.
상주하는 로컬 API가 있어야 클라이언트가 얇아질 수 있다. Chrome 확장은 v1의 로직 덩어리에서 로컬 API만 호출하는 사이드바로 줄었다. 곧 올 MCP 지원으로 AI 에이전트도 같은 계약으로 DeepSRT와 대화한다. 키는 브라우저 localStorage가 아니라 macOS 키체인에. 자막과 요약은 디스크에 캐시되어 재시작해도 이어진다. 전부 OS가 네이티브 앱에게 주는 대우다.
플레이어는 우리 것
v2는 자체 플레이어를 내장하고, 이중 언어 자막은 우리 자신의 view에 그려진다. 드래그로 위치 조정, 단축키로 크기 조절, 문장 병합으로 ASR 자막이 문장 중간에 끊기지 않는다——자기 view 안에서 이것들은 오후 한나절 일이지만, 남의 DOM 안에서는 끝나지 않는 전쟁이다. YouTube가 리디자인해도 오버레이는 더 이상 깨지지 않는다. 그들의 페이지에 아무것도 겹쳐 그리지 않으니까.
OS의 일등 시민
네이티브 앱은 OS 통합 표면 전체를 얻는다. deepsrt:// 딥링크로 Safari 확장, 런처, 어떤 스크립트든 클릭 한 번에 영상을 DeepSRT로 넘긴다. 애초에 Safari 확장은 네이티브 앱에 내장해야만 배포할 수 있다. 클립보드에 YouTube 링크가 있으면 실행 시 바로 요약할지 물어본다. 그리고 이 모든 게 몇 MB짜리 앱에 들어간다——네이티브 SwiftUI이지, 브라우저에 앱 옷을 입힌 것이 아니다.
정직한 한계
대가는 분명하다: 지금은 macOS뿐. 그리고 브라우저 안의 경험은 여전히 중요하다——보고 있는 탭 옆에 사이드바를 원하는 사람이 많다. 그래서 얇은 클라이언트 확장은 계속 남고, 곧 오픈소스가 된다. 어려운 일은 전부 앱에 있기에, 확장은 누구나 소스 전체를 읽을 수 있을 만큼 얇아질 수 있다.