프로젝트 Gemini
(geminiprotocol.net)- 텍스트 문서 중심의 전자 도서관을 지원하는 새로운 인터넷 기술로, 상호 연결된 문서 구조를 기반으로 함
- 기존 웹의 복잡한 기능 대신 단순하고 가벼운 온라인 공간을 구축하는 데 초점을 둠
- 혁신이나 파괴보다는 프라이버시, 주의력, 대역폭 보호를 중시하는 접근
- 다른 기술을 대체하거나 세상을 바꾸려는 목적이 아닌, 과도하게 변화한 인터넷 환경에서의 휴식 공간 제공
- 문서가 본질 그대로 다뤄지는 인터넷 공간을 지향한다는 점에서 지속 가능한 정보 접근 방식의 중요성 강조
Gemini 개요
- Gemini는 상호 연결된 텍스트 문서의 전자 도서관을 지원하는 새로운 인터넷 기술
- 기존의 웹 개념과 유사하지만, 단순성과 본질적 정보 전달에 초점을 맞춤
- 이 기술은 시대에 구애받지 않는 개념으로, 단순히 과거의 잔재가 아닌 ‘1급 개념’으로서의 문서 구조를 다룸
- 혁신이나 파괴적 변화를 목표로 하지 않고, 이미 충분히 변화된 인터넷 환경에서의 안정감을 추구
설계 철학
- Gemini는 가벼운 온라인 공간을 구축하여, 문서가 단순히 문서로 존재할 수 있도록 함
- 복잡한 웹 애플리케이션이나 광고 중심 구조에서 벗어나 읽기 중심의 경험을 제공
- 프라이버시 보호, 주의력 유지, 대역폭 절약을 핵심 가치로 설정
- 다른 기술을 대체하거나 경쟁하지 않으며, 사용자에게 선택 가능한 대안적 인터넷 공간을 제공
공식 자료 및 라이선스
Hacker News 의견
-
예전에 Gemini 프로토콜을 가지고 놀 때 정말 즐거웠음
하지만 직접 실험하는 단계를 지나자, gemtext의 제약이 흥미를 많이 떨어뜨렸음
텍스트 중심의 마크업 언어라서 글을 쓰는 사람에게는 완벽하지만, 내가 주로 공유하는 그림이나 시각 자료에는 불편했음
이미지나 썸네일 디렉터리 노출 방식이 산만함을 유발할 수 있다는 주장도 이해하지만, 시각 예술도 중요한 표현 수단임
결국 Gemini는 본래 목적에는 잘 맞는 프로토콜임. 내 필요에는 안 맞지만, 맞는 사람은 분명 좋아할 것임- 일부 Gemini 클라이언트는 인라인 이미지를 지원함
방문자가 원하면 썸네일 목록을 볼 수 있도록 설정할 수 있음 - 동의함. 사실 Gemini는 Gopher가 남긴 빈틈을 메우지도 못함
그냥 “motherfuckingwebsite.com” 같은데, 너무 진지하게 굴고 있음
- 일부 Gemini 클라이언트는 인라인 이미지를 지원함
-
나는 smol web을 즐기며, 기술 애호가들에게 정말 좋은 공간이라고 생각함
그래서 내 사이트 sava.rocks에 finger://, gemini://, gopher://, https:// 미러를 모두 만들어둠 -
나이 때문일 수도 있지만, 왜 굳이 모든 걸 새로 만들지 이해가 안 됨
약간 수정된 HTML 2.0이나 3.2로 돌아가도 충분하다고 봄
나도 현대 웹의 문제점을 싫어하지만, 이미 존재하는 “비현대적 웹”을 개선하는 게 더 낫다고 생각함
상호운용성(interoperability) 을 절대 과소평가하지 말아야 함- 별도의 프로토콜을 쓰면 모든 사이트가 동일한 제한을 가진다는 장점이 있음
제한된 브라우저로 검색해도 읽을 수 있는 결과만 나오기 때문에 발견성(discovery) 문제를 줄일 수 있음 - Gemini는 웹의 부정적 변화에 대한 반작용임
웹이 확장 가능하게 설계된 게 근본적 실패라고 보고, Gemini는 확장 자체를 어렵게 만들어버림
하지만 나는 이런 태도에 공감하지 않음. 웹의 문제는 출판자 중심으로 발전했다는 점임
결국 사용자는 “Google의 에이전트”를 쓰게 되었고, 나는 그런 출판자 중심 소프트웨어보다 사용자 중심 도구를 원함 - HTML 2.0과 NOSCRIPT는 서버와 클라이언트 양쪽에서 강제하기 어렵음
- 흥미로운 결론임. 상호운용성이 이 프로토콜의 큰 이유 중 하나일 것임
직접 Lagrange를 설치하고 gemini://bleyble.com/cgi-bin/random 에 접속해보면 느낌이 다름 - 무언가를 새로 만들면 사람들이 참여감을 느끼고, 구현이나 설계에 기여할 수 있음
사람들은 이런 과정에 함께하는 걸 좋아함
- 별도의 프로토콜을 쓰면 모든 사이트가 동일한 제한을 가진다는 장점이 있음
-
나는 Gemini용 검색엔진과 Wayback Machine을 직접 구축했음
gemini://kennedy.gemi.dev
약 4천 개의 호스트와 100만 개의 문서·이미지·파일이 있음
크롤러나 인덱서 실험을 하기 좋은 놀이터이고, 대부분 정적 사이트지만 CGI로 약간의 상호작용성을 추가함
예: gemini://gemi.dev/cgi-bin/moon.py -
이름의 유래는 NASA의 우주 프로그램에서 따온 것으로 기억함
Gopher는 Mercury, Web은 Apollo, 그리고 Gemini는 그 중간 단계임
Gemini는 새로운 인터넷 프로토콜로서- Gopher보다 무겁고
- Web보다 가볍고
- 둘 중 어느 것도 대체하지 않으며
- 최대 효율 대비 최소 복잡성을 추구하고
- 사용자 프라이버시를 매우 중요하게 여김
- 이미지가 없다는 점은 대부분에게 결정적 단점일 것 같음
- 문서들이 단순히 링크로 연결되어 있다면 검색과 발견은 어떻게 작동하는지 궁금함
Gemini 외부에 검색엔진이 존재해서 연결해주는 구조인지 알고 싶음
-
팬데믹 시기에 Gemini를 다루는 게 정말 즐거웠음
단순한 프로토콜을 새로 배우는 도전감이 있었고, 직접 GUI 클라이언트를 만드는 재미도 있었음
세상을 뒤흔들 정도로 성공하진 않았지만, 여전히 인터넷의 아늑한 구석으로 남아 있음- 나만 그 시기를 완전히 놓쳤음 ㅠ
-
100단어 소개문을 읽었는데도 여전히 뭔지 모르겠어서 그냥 나왔음
- FAQ에 설명이 있음
Gemini는 경량 하이퍼텍스트 형식을 지원하는 클라이언트–서버 프로토콜로, 파일 배포에 초점을 둠
URI, MIME, TLS 같은 표준 기술 위에 구축되어 있고, 단순함과 비확장성을 핵심 철학으로 함
요약하자면, 극도로 축소된 웹 스택임 - 기본적으로 HTTP와 HTML의 대안 프로토콜임
복잡도는 초기 HTTP/1과 Gopher의 중간쯤이며, 텍스트 중심으로 설계되어 멀티미디어나 인터랙티브 기능은 없음 - 나도 같은 반응이었음. 소개문이 너무 공허한 수사로 가득 차 있어서 실망스러웠음
- 결국 Gopher + TLS + UTF8 + 텍스트 래핑 + 헤더 + 비정렬 리스트 정도임
- 요약하자면, 이미지나 스크립트가 없는 웹임
- FAQ에 설명이 있음
-
나는 Gemini의 철학 — 인라인 이미지 없음, 추적 없음, 산만함 없음, 확장 불가, 보안 중시 — 에 공감했음
그래서 안드로이드용 Gemini 브라우저 Buran을 설치하고 여러 링크를 탐색했음
그런데 gemini://hellomouse.net에 들어가자마자 인라인 이미지가 보였음
Gemini의 원칙에 어긋나는 것 같은데, 내가 뭘 잘못한 건지 모르겠음- 잘못한 건 없음. 실제로 Gemini 사용자들도 인라인 이미지의 유용성을 인정함
-
2021년부터 Gemini Capsule(웹사이트/블로그)을 운영 중임
방문자는 거의 없지만, 저녁에 small web을 탐색하며 흥미로운 콘텐츠를 찾는 재미가 있음 -
이 사이트는 너무 수다스러워서 핵심을 잡기 어려웠음
하지만 요약하자면 “현대화된 Gopher”라는 설명이 크게 틀리지 않은 것 같음