Spegel - LLM을 활용해 웹페이지를 재구성하는 터미널 브라우저
(simedw.com)- Spegel은 HTML 웹페이지를 LLM 프롬프트로 변환해, 터미널에서 마크다운 형태로 보여주는 브라우저
- 사용자 프롬프트를 기반으로 페이지를 실시간 맞춤 변환할 수 있어, 중요한 정보만 간결하게 표시하도록 설정할 수 있음
- 핵심 동작 방식은 HTML 크롤링 → LLM 프롬프트 처리 → 마크다운 변환 및 출력
- Textual 기반 TUI로 직관적이고 가벼운 터미널 UI 제공하며, 뷰와 프롬프트는 설정 파일로 쉽게 관리 및 실시간 변경 가능
- Lynx, Links2, Browsh 등 기존 터미널 브라우저와 달리 LLM을 활용한 사용자 맞춤 콘텐츠 최적화에 특화되어 있음
-
pip install spegel
로 간단 설치 가능, 오픈소스로 다양한 실험 및 확장에 적합
프로젝트 개요 및 특징
- Spegel은 터미널에서 동작하는 웹 브라우저의 일종으로, HTML을 LLM에 전달하여 사용자 정의 프롬프트로 페이지를 재구성함
- 출력은 마크다운으로 변환되어 Textual 기반 터미널 UI에서 직관적으로 표시
- JS 미지원, GET 요청만 처리하는 미니멀 설계
- LLM 프롬프트 커스텀으로 다양한 변환 뷰 지원 (예: 레시피 요약, 주요 액션 강조 등)
개인화와 활용 예시
- 프롬프트와 뷰를 사용자 설정(
~/.spegel.toml
)으로 자유롭게 관리 - 예시:
- 레시피에서 재료와 핵심 단계만 추출
- 복잡한 설명을 ELI5 스타일로 간단하게 변환
- 필요시 여러 개의 뷰를 동시에 등록하여 빠르게 전환 가능
동작 방식
- Spegel은 HTML을 가져와 설정 파일의 프롬프트와 함께 LLM에 전달
- LLM 결과를 마크다운으로 변환, Textual을 통해 터미널에 렌더링
- 프롬프트·뷰는 탐색 중에도 실시간으로 조정 가능
- 결과를 줄 단위로 스트리밍하며, 마크다운 포맷 오류를 방지하는 버퍼 처리 구현
기존 터미널 브라우저와의 차별점
- Lynx, Links2, Browsh 등은 HTML 구조 자체만 터미널에 표시
- Spegel은 LLM 기반 변환으로 불필요한 정보 제거·최적화 뷰 제공에 특화
- 현대 웹사이트는 CSS·JS 의존도가 높아 터미널 환경에서 번잡함, Spegel은 핵심 콘텐츠만 추출해 집중도와 접근성 개선
설치 및 사용법
- pip로 간단 설치:
pip install spegel
- 실행:
spegel <URL>
- 설정 파일(~/.spegel.toml) 커스텀 필요, 예제는 GitHub 참고
- 소스코드 및 기여: https://github.com/simedw/spegel
참고 사항
- 아직 Proof-of-Concept 단계라 일부 미완성 기능과 거친 부분 존재
- POST 요청 미지원, 폼 입력 등 향후 확장 아이디어 구상 중
- 기존 터미널 브라우저의 대체라기보다는, LLM+TUI 기반 콘텐츠 개인화 탐구 실험 성격이 강함
Hacker News 의견
-
이 기술 정말 흥미로운 아이디어라고 생각함, 브라우저를 완전히 대체하지는 않지만 결정적 검색과 프롬프트를 조합해서 웹 브라우징의 전혀 다른 방식을 만들어 낼 수 있을 것 같음, 명령줄 도구 형태로 제공하면 더 잘 어울릴 거라는 생각임
-
다음 단계로는 여러 "탭"을 동시에 다루는 기능을 상상해봄, 예를 들어 탭 1은 뉴스 A의 보도, 탭 2는 뉴스 B, 탭 3은 Wikipedia를 넣고 이런 자료들을 요약하고 참조 링크를 생성하는 형태임, 그런데 이런 워크플로우를 지원하기에 충분히 안정적인 모델이 과연 있는지 의문임, 최신 SOTA 모델도 한계가 있다는 느낌임
-
위와 같은, 여러 매체의 보도를 한 눈에 보고 요약, 참조 제공하는 기능, 사실상 Ground News에서 하고 있는 일이라고 생각함, 나는 그들과 관련 없고 단지 Kurzgesagt 영상에서 후원사로 언급된 걸 봤음, UI에는 분명 차이가 있을 수 있음
-
나는 여러 탭/뷰를 동시에 보여준다고 해도 같은 출처(source) 내에서만 하려고 생각함, 예컨대 한 탭엔 CLI에 최적화된 원본 표현, 다른 탭엔 fact-checking(구글, Brave로 내용 근거 찾기)만 집중하는 방식임, 이런 실험 매우 재미있을 것 같음
-
LLM 기반 SEO 스팸을 온 힘을 다 해 만들어내고, 또 다른 LLM이 이를 대충 요약해서 다시 뱉어내는 구조라고 보면 됨, 참으로 대단한 미래라고 생각함
-
-
유명 레시피 사이트에서 레시피만 추출하는 예시가 첫 번째 등장하는 게 정말 고전적인 장면이라고 느꼈음, 개인적으로 이런 프로젝트는 바로 추천하고 싶어짐, 아주 기발한 프로젝트 느낌임
-
또다시 LLM 유행이, 이미 존재했던 걸 재해석해서 훨씬 나빠지고 비결정적으로 만든 예시라고 봄, schema.org/Recipe와 같은 표준 구조는 이미 있던 것임
-
레시피 추출 과정에서 내용이나 재료, 분량 등이 무작위로 변형된다는 점이 흥미로움, LLM의 특성이 이런 마이크로코즘에서 아주 잘 드러난다고 생각함, 다만 대다수 코멘트들이 기대하는 방향과는 완전히 다름
-
이미 LLM 없이 결정적 방식으로 레시피만 뽑아주는 확장 프로그램이 있음, 예를 들어 Chrome의 Recipe Filter 확장 같은 건 페이지 내 레시피를 인식하면 팝업으로 보여줌
-
-
LLM이 중간에서 들어가서 최근 구글의 SEO 최적화된 글쓰기 트렌드와 SEO 구조 자체를 우회한다는 점이 마음에 듬, 모든 불필요한 부분을 제거하고 레시피만 추리는 건 LLM에 정말 잘 어울리는 사례라고 생각함, 앞으로 LLM을 필터로 적극 활용하는 사례가 더 등장할 거라 예감함, 물론 HTML에서 레시피만 바로 뽑을 수 있으면 좋겠지만, SEO 전쟁이 너무 심해져서 현실적으로 불가능해진 상황임
-
LLM이 모든 불필요한 요소를 제거하는 용도라는데, LLM이 예측 불가능하게 레시피를 바꿀 수도 있다는 점 생각해볼 필요 있음, 오류를 허용할 수 없는 에러-허용불가 환경에 이런 확률적 소프트웨어를 신뢰하는 게 이해되지 않음
-
몇 년 전부터 이런 미래를 예상함, 이미 검색 내장 LLM 도구가 있는데 여러 검색을 연결해 처리하는 기능이 정말 강력함, 하지만 Spegel은 완전히 다른 방식임, 미래의 광고 차단기는 작고 효율적인 로컬 LLM일 거라 봄, 예를 들어 타임라인을 시간순 정렬, UI 변경, 특정 항목만 노출 등 다양한 변형이 가능함, 저품질 댓글은 자동으로 숨긴다든지 LLM이 중간에 프록시나 에이전트로 작동할 때 전부 가능함, 이런 흐름이 광고주에겐 상당히 불편하게 다가올 거라 예감함
-
웹 브라우징 과정에서 LLM이 분당 수백만 토큰을 처리해야 할 수도 있다는 점, 그만큼 연산 비용이 크다는 걸 생각해 볼 필요 있음
-
LLM이 불필요한 부분을 만들고, LLM이 또다시 불필요한 걸 제거하는데, 서로 오해 없이 흘러가는 순환 구조라는 생각임
-
-
덜 복잡한 모델(심지어 LSTM 기반도 가능하다고 봄)로 DOM을 훑어서 필요한 부분만 골라 직접 브라우저에 표시할 데이터 구조로 수집하면 가능성 있다고 생각함, 이미 작성자의 LLM 기반 도구 체인 활용해서 훈련 데이터도 쉽게 만들 수 있을 것이라 느낌
- 하지만 JS로 콘텐츠가 늦게 렌더링되는 현대 웹에선 DOM만 순회하는 건 한계임, JS가 다 로드되고 모든 요청이 끝난 후에야 필요한 데이터를 얻어낼 수 있는데, 이 경우 어차피 그냥 브라우저 렌더러를 돌리는 거나 마찬가지임
-
많은 사람들이 html이 시작일 뿐이라는 점을 간과하는 듯, 웹페이지를 다른 시각(view)으로 변환할 수 있다면 사실 모델이 받아들이는 모든 입력에 대해 변환 가능함, PDF, 이미지가 담긴 zip, 대형 json 등 어떤 것도 view화 가능함, 결국 중요한 건 html 입력이 아니라 출력 결과 view라는 점임
-
spegel에 -p 옵션 추가 제안임
spegel -p "extract only the product reviews" > REVIEWS.md
처럼 프롬프트 기반으로 원하는 정보만 추출하는 기능임
-
페이지마다 매번 새로 rewrite하지 않고, 방문 한 번에 마크다운으로 바꾼 뒤 서로 깔끔한 버전을 공유하면, 연산 리빌딩을 줄일 수 있을 것이라 생각함
-
각 사용자마다 필요와 사전 지식이 다르기 때문에, 아무리 깨끗한 공용 자료를 만들어도 결국 개인별로 손질하는 과정이 남아있을 거라고 생각함, 다만 P2P 캐시(IPFS 등) 같은 글로벌 중복 캐시가 데이터 보존, 가용성 확보, 자원 절약에 도움 될 수 있음
-
캐시 헤더는 서버가 클라이언트에게 정보를 얼마나 오래 캐시해도 되는지 알려주는 용도임, 클라이언트 쪽에도 이런 헤더를 준수하는 캐시 계층을 추가하면 좋겠다는 생각임
-
일관적 레이아웃이 목표라면, 마지막 페이지의 마크다운 결과물을 예시로 모델에 함께 넘기는 방식(one-shot example)도 가능성 있음
-
이 프로젝트는 "개인 맞춤 프롬프트 기반 뷰"라는 목적이 있으니까, 적어도 디폴트 프롬프트 결과물은 캐시해놓고 써도 좋겠다는 생각임
-
-
정말 훌륭한 POC라고 느꼈고, 내가 평소 쓰는 크롬 확장 "reader view"와 매우 유사한 부분이 있음
reader view 확장 링크 -
아이디어가 굉장히 멋지고 접근성 측면에서도 잠재력이 크다고 생각함
- 하지만 역시 LLM은 비결정적이기 때문에 접근성은 무엇보다 신뢰성과 예측가능성이 담보되어야 하는 영역이라는 점이 문제임
-
내 은퇴한 AI 에이전트가 웹페이지 실시간 변환해주는 걸 시연한 오래된 영상 있음
HN을 My Little Pony로 변환하는 데모(동영상)
대략 37초부터 결과물을 볼 수 있음
오픈소스 크롬 확장도 만들어뒀으니 궁금하면 ChromeGPT 참고할 것