리브의 아침 브리핑

01VoiceStudio - 음성 복제, 더빙, 받아쓰기를 로컬에서 처리하는 오픈소스 스튜디오

계정도 API 키도 구독도 필요 없이 내 컴퓨터에서 음성 작업을 끝내는 데스크톱 앱을 만들었습니다. 필요한 모델만 내려받으면 오프라인에서도 돌아가고, 깨끗한 샘플 5-15초만 있으면 별도 학습 없이 목소리를 복제해 원하는 문장을 읽게 할 수 있습니다. 나이·억양·음높이·말투를 설명해 없던 목소리를 새로 만드는 것도 됩니다.

• 영상의 말을 받아쓰고 번역한 뒤 화자별 목소리를 유지해 더빙본으로 내보내는 과정, EPUB/PDF를 등장인물별 목소리로 나눠 .m4b 오디오북으로 굽는 과정을 모두 한곳에서 처리합니다.
• 음성 합성 엔진 16개와 인식 엔진 11개를 골라 쓸 수 있고 언어 목록은 646개지만, 실제 지원 언어와 복제 품질은 엔진마다 다릅니다.
• 음성/배경음 분리, 화자 구분, AudioSeal 워터마크 삽입과 감지를 넣었고, 로컬 API·OpenAI 호환 음성 API·MCP 서버로 다른 앱이나 에이전트에서도 호출할 수 있습니다.
• GPU 없이 CPU로도 돌지만 RAM 16GB 이상, GPU 사용 시 VRAM 8GB 이상을 권장하며 대형 엔진은 더 필요합니다. 앱은 AGPL-3.0, 모델은 별도 라이선스입니다.

github.com/debpalash · 관심사 상 · 추천 상위 7.7%

02타임스탬프를 시·분·초로 변환하는 더 빠른 방법

요일 계산을 빠르게 만드는 글의 후속으로, 하루 안의 초 [0..86399]를 시·분·초로 쪼개는 계산을 다룹니다. 주요 날짜/시간 라이브러리는 앞 계산 결과를 차례로 기다리는 구조라, 비트 기법을 꺼내기 전에 계산 순서만 바꿔도 대기 시간이 크게 줄어듭니다. 글을 쓰기 시작하고서야 함수 구조 변경이 속도 향상의 가장 큰 원인이었고 기존 라이브러리들이 대체로 놓친 접근이었다는 걸 알았습니다.

• 전통적 방식 1(Linux 커널·glibc·Go·CPython·OpenJDK)은 초가 분에, 분이 나머지에, 나머지가 시에 의존해 근사 16사이클, 방식 2(V8·Boost·musl)는 12사이클입니다.
• V1은 전체 분과 시간을 먼저 독립적으로 구한 뒤 초와 분을 병렬로 계산해 복잡한 비트 기법 없이 8사이클로 내려갑니다. 핵심은 분을 원래 입력이 아니라 두 중간 결과로 구하는 것입니다.
• V2는 고정소수점 곱셈의 상·하위 비트를 함께 써 약 6사이클, V3는 60진법을 64진법 나머지 연산으로 바꿔 일부 대상에서 5사이클까지 갑니다.
• 컴파일러가 알아서 재배열해 주기를 기대하지 마십시오. .NET JIT과 MSVC는 인식하지 못했고 Clang과 GCC는 %를 뺄셈·곱셈으로 바꿨을 때만 인식했습니다.

benjoffe.com · 관심사 중 · 추천 상위 12.3%

03Ask HN: 스킬 파일을 어떻게 관리하시나요?

AI 에이전트용 스킬을 어디서 구하고, 어떻게 관리하고, 실제로 작동하는지 어떻게 확인하시는지 묻습니다. 답변은 범용 스킬을 모으는 쪽보다 직접 만든 업무별 스킬 이야기로 크게 기울었습니다.

• git 저장소에 원본을 두고 각 에이전트의 스킬 디렉터리에 심링크를 거는 구성이 반복해서 등장하며, 공통 스킬과 프로젝트 전용 스킬을 나눠 두고 공개용과 사내용 저장소도 분리합니다.
• 항상 필요한 규칙만 AGENTS.md에 짧게 두고 긴 절차는 필요할 때 읽을 스킬로 빼되, 본문을 안 읽어도 이름과 설명 목록이 컨텍스트를 먹으므로 설치 수가 늘어나는 문제까지 사라지지는 않습니다.
• 검증은 성공한 작업을 스킬로 만든 뒤 대화 기록을 비운 새 세션에서 다시 돌려 보는 방식이고, 실패 사례는 회귀 테스트로 남깁니다. 모델이나 실행 환경이 바뀌면 같은 스킬도 다르게 동작합니다.
• 반드시 지켜야 하는 제한은 지시문으로 보장하려 하지 말고 훅·권한 설정·검증 코드로 강제해야 한다는 의견이 나옵니다. 정해진 동작은 스크립트로 빼고 판단이 필요한 부분만 에이전트에 맡깁니다.

news.ycombinator.com · 관심사 최상 · 추천 상위 20.4%

04Build vs Buy - AI로 개발은 싸졌지만, 3년 뒤 유지보수는 누가 맡을까?

AI가 낮춘 것은 만드는 비용이지 계속 운영하는 비용이 아닙니다. 초기 스타트업에서 라이선스를 아끼려고 인증을 직접 만들었는데, 예상대로 일주일 만에 붙었고 부담은 그다음부터 시작됐습니다. 아낀 라이선스 비용은 보안 패치, 출시하지 못한 기능, 경영진의 고객 대응 시간으로 되돌아왔습니다.

• 결국 상용 인증으로 갈아탔고 약 한 달 뒤 쓰던 오픈소스 구성요소에서 심각한 취약점이 터져 여러 사이트가 침해당했습니다. 30일 차이로 피했지만 운이 좋았던 것과 처음부터 옳게 판단한 것은 다릅니다.
• 반대로 공식 서버가 없어 직접 만든 내부 MCP 서버는 공식판이 나오자 즉시 갈아탔습니다. 차이는 엔지니어링 품질이 아니라 피해 범위와 교체할 경로에 있었습니다.
• 만들기 전에 넷을 물으십시오. 장애나 침해의 피해 범위, 앞으로 수년간 새벽 2시 호출을 받을 사람의 이름, 사업 차별화 여부, 1년 뒤 좋은 제품이 나왔을 때 버릴 수 있는지.
• 회의에서 하나만 묻는다면 '3년 차에는 누가 패치하는가'입니다. 답이 없다면 그 의사결정은 아직 끝나지 않은 것입니다. 자체 개발의 실패는 첫 분기가 아니라 18개월 뒤에 드러납니다.

substack.com/kevingoldsmith · 관심사 상 · 추천 상위 32.1%

05Apache Maka - 에이전트가 한 일을 기록으로 남기는 로컬 우선 워크스페이스

원하는 모델을 붙여 데스크톱이나 터미널에서 작업을 맡기고, 에이전트가 무엇을 했는지 실행 과정까지 되짚을 수 있는 작업 공간입니다. 대화만이 아니라 도구 호출과 그 결과, 권한 승인 여부, 종료 상태를 순서대로 남기고 그 기록을 화면 표시와 다음 요청 구성, 비정상 종료 후 복구에 씁니다.

• 모델에 넘기는 문맥을 줄여도 원래 실행 기록은 보존합니다. 오래된 도구 출력을 다음 요청에서 빼더라도 이력에서 지우지는 않습니다.
• 데스크톱과 TUI/CLI, 평가 도구가 같은 실행 엔진을 쓰며, 같은 모델과 공식 채점기로 다른 에이전트 도구와 비교한 완료율·비용·개별 실행 기록을 평가 보고서로 공개합니다.
• 파일 작업과 셸 실행에 권한 확인과 OS 샌드박스를 걸지만 보호 범위는 플랫폼과 설정에 따라 다르고 모든 도구를 격리하지는 않습니다. API 키는 로컬 평문 파일에 두되 저장된 값을 화면 프로세스로 되돌려 주지 않습니다.
• 아직 Apache 공식 릴리스가 없는 Incubator 프로젝트라 데이터 형식과 CLI가 바뀔 수 있고, Windows·Linux 빌드는 서명되지 않은 프리뷰입니다.

github.com/apache · 관심사 상 · 추천 상위 49.8%

06Xteink X3, 70달러짜리 초소형 전자책 리더

신용카드 크기의 3.7인치 전자책 리더를 iPhone 뒷면에 자석으로 붙이고 다녔습니다. 화면은 가장 작은 Kindle의 절반쯤이지만 1,344쪽짜리 《The Power Broker》를 세 시간 연속 읽어도 눈이 아프지 않았고, 한 페이지에 한두 문단만 들어가는 게 오히려 계속 읽게 만들었습니다. 어느 리뷰어는 이걸 '독서의 TikTok화'라고 불렀습니다.

• 쓰기 전 두 달 동안 책 한 권을 겨우 끝냈는데, 쓰고 나서 한 달에는 힘들이지 않고 세 권을 읽었고 iPhone 일평균 화면 사용 시간이 25분 줄었습니다.
• Amazon 69달러짜리답게 터치스크린도 컬러도 백라이트도 없고, 기본 소프트웨어는 책 표지 표시와 일부 텍스트 서식 처리조차 제대로 못 합니다.
• 팬들이 만든 오픈소스 펌웨어 Crosspoint가 독서 통계·글꼴·페이지 스크린샷을 얹었고, 2026년 8월 말에는 도서관 앱 Libby의 책을 여는 기능까지 붙었습니다.
• 매력은 첨단이 아니라 싸고 단순하고 고칠 수 있다는 데 있습니다. 예측 가능해진 2026년의 기기 시장에서 이 빈자리를 중국 업체들이 채우고 있습니다.

theatlantic.com · 관심사 최상 · 추천 상위 56.1%

07Navier-Stokes, Tristan Buckmaster 의 성명 [pdf]

Navier-Stokes – Tristan Buckmaster [pdf]

Tristan Buckmaster 가 유체역학 문제 작업에 관해 직접 올린 성명 PDF 입니다. 원문은 짧은 문서지만 HN 상위 0.7%까지 올라온 이유는 문서 자체보다 그 배경에 있습니다.

• 댓글에서 정리된 경위에 따르면, Buckmaster 와 Alpöge 는 지난 1년간 AI 를 써서 유체역학 문제를 다뤄 왔고 8월 중순 Navier-Stokes 의 더 단순한 버전에 대한 반례를 찾아 논문을 준비하고 있었다고 합니다.
• 9월 초 X 에서 특정 연구소가 밀레니엄 문제를 풀었다는 소문이 돌기 시작하면서 발표 순서가 꼬였다는 것이 댓글에서 재구성된 이야기입니다.
• Terence Tao 의 수학적 해설과 Buckmaster 본인의 Mastodon 글이 함께 링크돼 있어, 주장의 실제 범위는 그쪽을 봐야 합니다.

cims.nyu.edu · 관심사 중 · 프런트 상위 0.7%

08OpenAI 가 내놓은 Navier-Stokes 밀레니엄 문제 결과

On the Navier–Stokes Millennium Prize Problem

OpenAI 가 Navier-Stokes 밀레니엄 문제에 대한 결과를 공식 페이지로 발표했습니다. 시도한 문제 전체에 걸쳐 에이전트가 490만 개의 메시지를 주고받고 약 3,000억 개의 출력 토큰을 썼다는 수치가 함께 공개됐습니다.

• 댓글의 첫 반응은 비용이었습니다. 일반 API 가격으로 환산해 볼 엄두도 나지 않고, 내부 전용 모델이면 더 비쌀 것이라는 지적이 이어집니다.
• 발표문의 'Concurrent Work' 절 반대편에 「Navier-Stokes 반례」 스레드가 있다는 안내가 붙어 있고, 그쪽이 훨씬 걸러지지 않은 이야기라는 평이 많습니다.
• '그냥 문제를 풀라고 시켰을 뿐'이라는 설명과 달리 팀이 붙어 있었고 제3자 연구자의 작업이 동원됐다는 주장이 댓글에서 나옵니다. 이는 어디까지나 반응이지 발표문에 적힌 내용이 아닙니다.

openai.com · 관심사 중 · 프런트 상위 0.8% · 화제

09Kimi K3(2.8T)를 SSD 네 개로 스트리밍해 맥북에서 1토큰/초로 돌리기

Kimi K3 (2.8T) at 1 token/s on a MacBook Pro, streamed from four SSDs

Kimi K3 는 2.78T 파라미터에 전문가 가중치만 약 1.45TB 라 메모리에 들어가지 않습니다. 그래서 (레이어, 전문가) 하나당 17.5MB 파일로 쪼개 디스크에서 스트리밍하고, 레이어마다 896개 중 16개만 pread + F_NOCACHE 로 읽습니다. 장비는 128GB M5 Max 맥북프로에 Thunderbolt 5 인클로저 셋과 내장 SSD 입니다.

• 전문가 가중치는 공개된 MXFP4 정밀도 그대로 두었고, 상주하는 어텐션 트렁크만 int8 입니다. BF16 대비 비트 일치는 주장하지 않고, 기록된 프롬프트에 대해 자체 레퍼런스와 토큰 단위로 같은 출력이 나오는지를 매 승격마다 확인합니다.
• 결과는 초당 1토큰입니다. 저자가 먼저 단서를 달아 두었고 수치를 미화하지 않습니다.
• 댓글 반응은 갈라집니다. 이 속도로는 쓸 데가 없고 비용만 든다는 쪽과, 이런 종류의 극한 실측 자체에 감탄하는 쪽입니다.

github.com · 관심사 최상 · 프런트 상위 28.4%

10herdr, 기기들을 하나로 연결하기

Connecting the machines

herdr 가 여러 머신을 하나로 잇는 이야기를 내놨습니다. 흩어져 있는 세션을 한곳에서 보게 하는 것이 목표입니다.

• 실사용자 쪽 반응은 반갑다는 쪽입니다. 몇 달째 회사와 집에서 daily driver 로 쓰고 있는데 가장 큰 불만이 정확히 이것이었고, 모든 ssh 세션을 한 자리에서 보고 싶었다는 댓글이 있습니다.
• 반대편에는 디스커버리 서비스는 직접 돌릴 수 있는데 왜 서비스로 받아야 하느냐, SyncThing 처럼 셀프호스팅용으로 풀 수 없느냐는 지적이 있습니다.
• 애초에 머신 네트워크가 필요할 만큼 일을 뿌려야 하는 이유가 뭔지 모르겠다는 회의적인 반응도 함께 있습니다.

herdr.dev · 관심사 최상 · 프런트 상위 59.3%