HN 공개: HN Update — 주요 HN 스토리의 매시간 뉴스 방송
(hnup.date)- HN Update는 Hacker News 첫 페이지의 상위 스토리를 오디오 뉴스처럼 묶어 보여주는 페이지로, 매시간 정각 갱신을 전제로 함
- 현재 방송 대상은 상위 5개 스토리이며, 페이지의 마지막 갱신 시각은 2026년 6월 30일 오후 11:06임
- 상위 5개에서 벗어난 스토리는 아카이브로 이동하고, 10개가 모이면 하나의 recap 에피소드로 이어 붙임
- 오디오 플레이어는 메인 방송과 recap 영역에 각각 있으며, 길이는 9분 55초와 19분 12초로 나뉨
- Recaps 영역은 과거 에피소드와 Load More를 제공해 이전 Hacker News 흐름을 이어서 확인할 수 있음
HN Update의 갱신 방식
- HN Update는 Hacker News 첫 페이지에서 상위 5개 스토리를 가져와 보여줌
- 갱신 주기는 매시간 정각임
- 페이지의 마지막 갱신 시각은 2026년 6월 30일 오후 11:06임
오디오 방송 구성
- 상단 오디오 플레이어의 길이는 9분 55초임
- 페이지 하단의 recap 영역에도 별도 오디오 플레이어가 있으며, 길이는 19분 12초임
Recaps 생성 흐름
- 스토리가 Hacker News 첫 페이지의 상위 5개에서 벗어나면 아카이브로 이동함
- 아카이브에 스토리 10개가 쌓이면, 해당 스토리들을 이어 붙여 recap 에피소드를 만듦
- Recaps Archive 영역에서 과거 recap 항목을 볼 수 있음
현재 보이는 Recaps 항목
- Recaps 영역에는 다음 시각의 항목들이 있음
- 2026년 6월 18일 오후 11:09
- 2026년 6월 17일 오후 05:05
- 2026년 6월 17일 오전 04:14
- 2026년 6월 17일 오전 04:06
- 더 많은 항목을 불러오는 Load More가 제공됨
댓글과 토론
Hacker News 의견들
-
긍정적인 반응이 많지만, 잠깐 들어보니 별로였음. 첫째, 경험이 너무 느리게 느껴짐
예를 들어 HN 홈을 열고 제목을 훑고 1위 글의 댓글까지 읽는 데 30초쯤 걸렸고, 필요한 정보는 다 얻었다고 느낀 뒤 나중에 새 글을 보러 오면 됐음. 그런데 이 도구는 글 하나를 브리핑하는 데 1분이 걸림
둘째, 실용성이 낮음. 보통 하루에 HN 홈에서 눈에 띄는 글은 1~2개뿐인데, 이 도구는 관심 없는 글을 들려줄 가능성이 큼. 내가 듣는 정보와 건너뛰는 정보를 학습하는 알고리즘으로 개선할 수는 있겠지만 이상적이진 않음. 관심 있는 제목을 클릭하면 맞춤형 오디오 요약을 생성하는 방식이 나을 수도 있음
셋째, HN의 사람 냄새를 지워버림. 사람들이 실제로 올린 글을 그대로 읽는 게 좋고, 각자의 표현과 어조, 상호작용을 보는 재미가 있음. 그걸 모두 지우고 로봇 같은 요약을 듣는 건 커뮤니티의 영혼을 빼앗는 느낌임. 이 사이트의 가장 좋은 부분인 사람들과의 연결감이 줄어듦- 이건 사용 사례가 맞지 않는 경우로 보임. 내게는 첫 페이지 읽기를 대체하진 않겠지만, 아침 산책 중 듣는 팟캐스트는 대체할 수 있을 것 같음
뉴스식 편향이나 광고가 없다는 점도 특히 좋고, 내일 꼭 써볼 생각임 - 동의하고 몇 가지를 더하자면, HN을 텍스트로 훑는 게 유용한 이유는 눈에 띄는 게 있으면 링크를 따라가 더 깊게 볼 수 있기 때문임. 팟캐스트 형식은 들은 내용을 클릭해서 파고들 수 없으니 이 장점이 사라짐
또 HN이나 소셜 미디어에서 고수준 요약은 내 사용 사례가 아님. 진짜 가치를 주기보다 가치가 있는 듯한 착각만 줌. 내가 원하는 건 궁금한 이야기로 깊이 들어가는 것임
이건 텍스트 음성 변환으로도 가능하지만, 먼저 피드를 직접 고른 뒤 그 선별한 글을 팟캐스트 형식으로 깊게 들어가야 함
오히려 LLM 요소를 빼고 HN 스레드 목록을 붙여넣으면 전체 댓글까지 전부 텍스트 음성 변환해주는 제품이면 더 유용할 것 같음. 운전하거나 다른 일을 하면서 긴 콘텐츠로 들을 수 있음 - 대부분 합성 음성의 순차성이라는 아주 분명한 한계를 건드리고 있음. 음성 합성을 쓰는 화면 낭독기를 보면 이 현상이 가장 뚜렷함
매체 자체의 근본적인 문제이고, 텍스트 음성 변환이 다시 뜨는 지금 일부 개발자들이 각자 새로 발견하게 될 문제임 - https://gist.github.com/SMUsamaShah/e7c9ed3936ba69e522f8cb38...
이 사용자 스크립트는 북마클릿으로도 쓸 수 있고, 아직 보지 않은 글을 빠르게 따라잡게 해줌. HN을 열고 북마클릿을 누르면 새 글에 “(NEW)”가 붙고, 예전 글에는 순위가 얼마나 바뀌었는지 표시됨
본 글을 숨기거나, 댓글 수와 점수 기준을 설정해 오래된 글을 숨기거나 보이게 할 수도 있음. 몇 페이지를 훑으면서 아직 못 본 새 글을 빠르게 확인할 수 있어 따라잡기가 아주 빨라짐 - 멋짐. 나도 실제로 꽤 비슷한 걸 만들고 있었음. 다만 내 경우는 개별 글에 초점을 둠. 위 댓글처럼 일반적인 개요에는 오디오가 그다지 잘 맞지 않는다고 느낌
아직 준비가 덜 돼서 Show HN은 안 했지만, 현재 상태는 여기서 볼 수 있음
https://news.gipety.com/hn/10842381/k/218/s/three-years-as-a...
과거의 고전적인 Show HN과 Ask HN 에피소드에 두 번째 생명을 주는 꽤 괜찮은 방식이 될 것 같음
- 이건 사용 사례가 맞지 않는 경우로 보임. 내게는 첫 페이지 읽기를 대체하진 않겠지만, 아침 산책 중 듣는 팟캐스트는 대체할 수 있을 것 같음
-
훌륭한 아이디어임. 나이가 들수록 읽을 에너지가 줄어드는데, HN 첫 페이지에 잠깐 올라왔다 사라진 정말 멋진 것들을 자주 놓친다는 점에서 실제 가치가 있음
댓글까지 요약해주는 것도 좋음. 댓글 깊숙한 곳에 진짜 보석 같은 내용이 자주 있음. 아마 상위 댓글 몇 개만 가져오는 것 같음
큰 개선점은 개인화일 수 있음. 첫 페이지의 대부분은 내게 개인적으로 관련이 없고, 새 글 페이지에는 인기를 얻지 못한 멋진 것들이 많음. 내가 반응하는 글의 종류를 학습해서 현재 유행 중이 아니어도 그런 글들의 요약을 보여주면 좋겠음
Last.fm은 20년 전에 나왔고, 훌륭한 추천 시스템에 꼭 AI가 필요하지 않다는 걸 보여줬지만 개인화된 경험은 그다지 자리 잡지 못한 것 같음. YouTube 알고리즘이 어느 정도 하긴 하지만, 실제 제어권이 거의 없다는 게 아쉬움- 나이가 들수록, 지금 50인데, 읽기 외의 방식에는 인내심이 0에 가까워짐. 읽기가 듣기보다 훨씬 빠르고, 처음에 이해 못 한 부분을 다시 읽기도 더 쉽고 빠름
별로 중요하거나 가치가 크지 않은 것만 듣는 편임. 듣다가 뭔가 걸리면 그때 가서 읽음 - 상위 댓글과 몇 개의 자식 댓글만 가져오는 중임. 모델의 문맥 창을 넘기지 않기 위해서임
개인화에는 확실히 가능성이 많음. 다만 HN은 너무 무작위적이라, 지적으로 내가 필요하다는 것조차 몰랐던 걸 발견할 때가 있음. 대부분의 추천 시스템처럼 탐색과 활용 사이의 균형 문제라고 봄
최소 기능 제품으로는 특정 키워드로 필터링하고 해당 글들을 모델 입력에 추가하는 방식이 가능할 듯함 - Last.fm 추천 시스템이 왜 AI가 아니라고 보는지 모르겠음. Wikipedia에는 “협업 필터링”을 쓴다고 나오고, Gemini는 그게 AI의 한 형태라고 함. AI는 거의 70년 전부터 시작됐음
- 읽을 에너지가 줄어드는 것에는 동의함. 이게 우리가 나이 들어서 그런 건지, 아니면 정보를 소비하는 마찰이 시간이 갈수록 계속 낮아져서 그런 건지 궁금함
- YouTube 알고리즘도 간접적으로는 제어할 수 있음. 시청 기록을 정리하면 됨
가끔 특정 장르나 버블에 갇힌 느낌이 들거나, 자는 동안 자동재생이 돌아가면 첫 화면이 그쪽으로 점령당함. 최근 시청 목록에서 그런 영상을 몇 개 지우면 눈에 띄게 개선됨
또는 보고 싶은 주제의 영상을 몇 개 재생하기 시작하면 곧 그쪽만 추천됨
- 나이가 들수록, 지금 50인데, 읽기 외의 방식에는 인내심이 0에 가까워짐. 읽기가 듣기보다 훨씬 빠르고, 처음에 이해 못 한 부분을 다시 읽기도 더 쉽고 빠름
-
과거 HN 글의 임베딩을 만들고, 사용자가 즐겨찾기한 글들의 임베딩 벡터를 평균낸 뒤 코사인 유사도 검색으로 관심 있어 할 만한 글을 고르면 멋질 것 같음
사실 좋아요 기록을 쓰면 더 좋겠지만, 그걸 접근할 수 있는지와 방법은 잘 모르겠음
임베딩을 다른 사람들이 어떻게 쓰는지도 궁금함. 여러 임베딩을 평균낼 수 있다는 건 아는데, 다른 변환을 해서 성공한 사람이 있는지 궁금함. King - Man + Woman = Queen 같은 걸 생각해보면, 많은 경우 질문을 의미 검색이나 RAG 입력으로 바로 쓰는 것 같음
질문-답변 쌍을 대량으로 만들고 임베딩한 뒤 “질문 공간”에서 “답변 공간”으로 옮기는 평균 변환을 구해서, 질문을 임베딩할 때 그 변환을 적용한 다음 RAG를 수행하는 게 의미 있을지도 궁금함. 아니면 잡음만 너무 커질 수도 있음- 즐겨찾기에 어떤 의미가 있다고 가정하는 셈임. 즐겨찾기는 공개였던 것으로 기억하고, 나는 보통 흥미롭거나 웃긴 댓글을 추적하고 공유하는 데 씀
반면 추천 기록은 비공개이고, 내가 실제로 신경 쓰는 것들과 더 잘 맞음 - word2vec를 RAG와 같이 쓰는 경우는 잘 모르겠지만, 다른 사용 사례는 꽤 흔함. 내 경험상 답변을 생성할 필요는 없음
벡터 데이터베이스에 넣을 각 문서에 대해 LLM으로 그 문서가 답할 수 있는 가능한 질문 목록을 생성함. 사실상 퀴즈를 만드는 것과 비슷함
그런 질문 임베딩을 원래 문서에 다시 매핑하고, 문서, 문서 조각, 질문 1, 질문 2 등을 벡터 데이터베이스에 저장함
그러면 사용자가 RAG에 질의할 때 사용자 질의 → 문서 조각이라는 직접 연결뿐 아니라, 사용자 질의 → 비슷한 질의 → 문서 조각이라는 전이 연결도 생김 - dang이 임베딩을 쓰는지, 아니면 그냥 자연스럽게 그렇게 되는 건지 궁금함
- 즐겨찾기에 어떤 의미가 있다고 가정하는 셈임. 즐겨찾기는 공개였던 것으로 기억하고, 나는 보통 흥미롭거나 웃긴 댓글을 추적하고 공유하는 데 씀
-
하, 이번 시간에는 이 도구가 자기 자신에 대해 이렇게 말했음
“좀 더 자기참조적인 흐름으로, HN Update 자체의 출시를 살펴봅니다. 이 시도는 Hacker News의 상위 글을 요약해 매시간 뉴스 방송을 제공하는 것을 목표로 합니다. 청취자들은 선별된 뉴스라는 개념을 좋게 보지만, 요약의 정확성과 표현 편향 가능성에 대한 우려도 있습니다. 커뮤니티 논의는 이런 서비스의 가치가 분명하더라도, 콘텐츠 정확성에 대한 신뢰가 여전히 핵심 문제임을 시사합니다.”- 내 버전은 “그리고 청취자 여러분께... 엄마 안녕!”까지 덧붙였음
꽤 귀엽고 인상적임 - 글 제목이나 본문에 프롬프트를 심어서 나쁜 짓을 할 수 있지 않을까 생각하게 됨
- 내 버전은 “그리고 청취자 여러분께... 엄마 안녕!”까지 덧붙였음
-
꽤 괜찮지만 내용을 지어내는 것 같음. 이 글의 웹사이트 서식에 대한 메타 댓글[1]을 가져와서, 커뮤니티가 C++ 메모리 안전 제안 때문에 코드가 모바일에서 읽기 어려워질까 걱정한다고 제시했음
그걸 듣고 나니 다른 요약을 신뢰하기 어려워짐
1: https://news.ycombinator.com/item?id=41899828- 프롬프트에 “지어내지 마”를 추가하면 도움이 된다고 함. 정확한 표현은 모르겠지만, 아마 주어진 텍스트에 있는 내용만 사용하라는 식이면 될 듯함
- 맞음, 좋은 모습은 아님
“이 서식과 글꼴 혼합은 모바일에서 읽기 어렵다.”
우리에게는 그게 메타 댓글이라는 게 분명하지만, 혼동할 수는 있다고 봄. 그래도 “모바일에서의 가독성”이 프로그래밍 언어인 C++ 에는 잘 적용되지 않는다는 점은 알아챌 수 있었을 것임
댓글이 메타일 수도 있고 심지어 사실이 아닐 수도 있다는 점을 프롬프트에 추가해서, 이런 댓글에 억지로 의미를 끼워 맞추지 않게 하겠음
-
꽤 흥미로운 프로젝트임. HN 기반 프로젝트에는 묘하지만 특별한 정서적 애착이 있음. HN을 어떤 한 차원에서 개선하는 확장 기능이나 부가 기능처럼 작동하기 때문임
컴퓨터 앞에 앉아 있거나 휴대폰으로 무한 스크롤을 시작할 때 이 도구를 쓸 것 같지는 않지만, 바쁠 때 HN을 빠르게 확인해야 한다면 쓰고 싶음
빠른 피드백을 하자면, 우선 UI/UX에서 제목과 부제목이 앱에 대해 많은 걸 알려주지 않음. 오디오 트랙은 재생 진행률은 보이지만 전체 시간과 현재 시간이 보이지 않음. 각 글을 나타내는 구간으로 오디오 트랙을 강조하면 유용할 듯함. 몇 개의 글을 요약하는지도 알려주는 게 맞아 보이고, 지금은 5개처럼 보임
더 나은 사용 사례를 위해서는 모바일 앱이나 PWA로 만들어 운전 중 차량 인포테인먼트 시스템에서도 쉽게 접근할 수 있게 하는 편이 더 타당함
모바일 앱으로 만들고 재생 버튼이 있는 위젯으로 제공하면 방송을 재생하는 데 필요한 탭 수를 줄일 수 있음. 건설적인 비판으로 도움이 되길 바람- 모두 아주 좋은 지점임
-
다음 단계는 HNN 뉴스 네트워크를 만들어서, 은행들이 CNBC나 Bloomberg News를 24시간 틀어놓듯 사무실 TV에 자막 띠와 AI 뉴스 앵커가 나오는 방송을 계속 틀어두는 것임
- 실제로 쓸 것 같음. 특히 실제 뉴스 채널처럼 하루 뉴스의 시간별 요약이 있다면 더 좋겠음. 하루 종일 볼 필요 없이 편할 때 틀면 되니까
이런 AI 콘텐츠 낭독 도구의 가장 좋은 점은 사용자가 목소리나 말하기 속도 등을 고를 수 있게 할 가능성임. 미국인이 아닌 입장에서 미국식 토킹헤드 뉴스 채널은 내 억양에 익숙한 상태에서는 꽤 거슬림. 시사 내용을 따라잡고 싶을 때도 마찬가지임 - Batman Beyond에 나오던, 아마 AI였을 말하는 머리들이 떠오름
- 실제로 쓸 것 같음. 특히 실제 뉴스 채널처럼 하루 뉴스의 시간별 요약이 있다면 더 좋겠음. 하루 종일 볼 필요 없이 편할 때 틀면 되니까
-
이 글 자체가 HN 1위가 된 뒤에 듣기 시작했더니, 이 도구가 자기가 내용을 지어낼지도 모른다고 말하는 걸 듣는 메타적인 상황이 됐음
훌륭한 프로젝트임 -
정말 훌륭함. 몇 시간 전 요약이나 아침 브리핑 같은 식으로 들을 수 있는 과거 아카이브 기능을 추가할 수 있으면 좋겠음
- 아카이브 구현은 그리 어렵지 않을 듯함
아침 브리핑이라면 그날 가장 흥미롭거나 가장 많이 논의된 뉴스처럼 더 선별된 뉴스 묶음을 뜻하는지 궁금함. 지금은 메인 페이지 상위 5개 글만 가져오고 있음
- 아카이브 구현은 그리 어렵지 않을 듯함
-
작년에 같은 아이디어로 https://radio-hn.pages.dev/를 만들었음. 하루에 한 번만 하는 방식이었고, 당시 여기 어딘가에 올렸음
- NotebookLM보다 1년 반이나 앞섰던 셈임
코드가 공개돼 있는지 궁금함. 특히 여러 화자와 목소리를 어떻게 구현했는지가 궁금함
NotebookLM은 두 사람이 계속 역할을 바꾸는 문제가 있음. 한쪽이 어떤 주제에서 학생이고 다른 한쪽이 선생이다가, 갑자기 말이 안 되는 방식으로 역할이 바뀜 - 흥미롭다. 올리기 전에 실제로 검색해봤지만 최근 1년으로만 좁혔음. 2년 된 글이라 검색에 안 나온 듯함
시대를 앞서갔음
- NotebookLM보다 1년 반이나 앞섰던 셈임