Gemini 프로토콜은 지난 5년 동안 캡슐 수가 크게 늘고 클라이언트도 개선됐지만, TLS 강제와 빈약한 Gemtext, 서비스의 휘발성, 가상 호스팅 부재 같은 한계는 여전하며 대안 프로토콜의 등장으로 ‘스몰 웹’ 커뮤니티가 분열되고 있다는 글.
Kevin Boone
참고
이 글은 문서 브라우징을 위한 HTTP 유사 인터넷 프로토콜인 Gemini에 관한 것이며, 같은 이름의 대규모 언어 모델이나 암호화폐에 관한 것이 아니다. 점성술에 관한 글도 아니다.
약 5년 전, 나는 비교적 새로웠던 Gemini 프로토콜에 대한 내 견해를 게시했다. Gemini는 (그때도 지금도) 클라이언트-서버 방식의 문서 검색을 위한 단순한 프로토콜로, 오래된 Gopher 프로토콜과 다소 비슷하지만 더 현대적인 기능이 몇 가지 들어 있다. Gemini의 설계자들은 이것이 학계와 애호가들의 관심을 끌고, 상업적 착취는 전혀 불가능하길 계획했다. 우리—학자와 애호가—가 웹을 만들었는데, 아무도 필요로 하지 않는 무의미한 소비재 잡동사니를 더 팔기 위해 그것이 우리에게서 빼앗기고, 그 과정에서 모두의 프라이버시가 망가지는 모습을 보는 건 분통 터지는 일이다.
Gemini 프로토콜은 본질적으로 확장 불가능하다. 설령 널리 채택된다 해도, 사용자 추적이나 타깃 광고 전달에 사용할 현실적인 방법이 없다. 구글 등은 큰 관심을 갖지 않을 가능성이 높다.
Gemini 프로토콜은 인터넷의 어떤 구석을 비상업적 용도로 개척해 보려는 흥미로운 시도다. 사용 방식은 일반적인 월드 와이드 웹과 조금 비슷하지만, 광고도 없고 스파이웨어도 없고 AI 슬롭도 없다. 흔히 말하는 “작은 웹(small web)”이다. 누구도 엄청난 채택을 예상하진 않았지만, 채택하는 사람들이 뭔가 흥미로운 것을 게시하길 기대(혹은 희망)하긴 했다. Gemini는 진입 장벽이 높아서, 실제로 그곳의 거의 모든 콘텐츠는 그때도 지금도 괴짜들의 작업물이다. 전부 기술적인 내용은 아니지만, 비기술적 콘텐츠에도 부정할 수 없이 괴짜 취향의 풍미가 있다. 나 역시 숨김없는 괴짜로서, 이 점이 전적으로 만족스럽다.
2020년 당시 나는 Gemini가 월드 와이드 웹에 영향을 미치는 문제들을 해결해 줄 거라 확신하지 못했고, 지금도 여전히 그렇다. TLS 암호화를 필수로 만든 것은 실수라고 느꼈다. 그렇게 하면 레트로컴퓨팅 및 최소 컴퓨팅 애호가들이 배제되는데, 그들은 그렇지 않았다면 쉽게 끌어들일 수 있었을지도 모른다. 기본 문서 포맷인 ‘Gemtext’는, 내가 보기엔, 다루는 재미도 읽는 재미도 느끼기엔 표현력이 너무 부족했다. 특히 Markdown처럼 단순한 것조차, 널리 쓰이는 다른 문서 포맷을 Gemtext로 쉽게 변환할 방법이 없었다.
또한 그때는 리눅스용 괜찮은 그래픽 클라이언트가 부족했다. 나는 이 문제를 내 클라이언트 JGemini를 직접 작성하는 방식으로 우회했다.
긍정적인 면부터 말하면, Gemini의 채택은 상당히 증가했다. 2020년에는 캡슐(사이트)이 몇백 개에 불과했지만, 이제는 최소 6천 개로 늘었다. 그리고 이들은 대부분 열성 사용자들이 손수 만든 사이트라는 점을 기억할 필요가 있다. 점점 더 일반 웹을 괴롭히는 LLM 생성 쓰레기가 아니다. 찾아볼 의지가 있다면 흥미로운 콘텐츠가 좀 있다.
또한 2020년 이후 새 클라이언트들이 등장했다. 나는 Lagrange를 사용하고 있는데, Gemini뿐 아니라 뒤에서 다룰 몇 가지 더 새로운 유사 프로토콜도 지원한다. Lagrange는 훌륭한 크로스플랫폼 클라이언트로, 그래픽 인터페이스와 세련된 타이포그래피를 갖추어 읽는 즐거움을 준다. 내 성의 없는 클라이언트 개발 시도보다 훨씬 낫다.
2020년 이후 Gemini 기반 서비스들도 여럿 온라인에 등장했다—뉴스 애그리게이터, 검색 엔진, 게시판 등. 하지만 이 부분도 전부 좋은 소식만 있는 건 아니다—뒤에서 다시 이야기하겠다.
첫째, 그리고 가장 중요한 점은, Gemini에서 가장 많이 비판받아 온 두 가지 약점이 해결되지 않았다는 것이다. 프로토콜은 여전히 TLS를 요구하며, 이는 다른 조건에서는 열성적이었을 사람들을 여전히 배제한다. TLS가 너무 널리 퍼진 세상에서는 잘 드러나지 않을 수 있지만, TLS는 엄청나게 복잡하고 자원 소모가 큰 암호화 방식이다. 게다가 새 프로토콜을 처음부터 설계한다면 선택지는 TLS뿐이 아니다. 더 나쁜 점은, 대부분의 Gemini 캡슐은 애초에 암호화의 이점을 전혀 얻지 못한다는 것이다. 그들에게 TLS는 불필요한 장애물일 뿐이다.
또한 빈약한 Gemtext 문서 포맷도 변하지 않았다. 여전히 텍스트를 강조할 방법이 없고, 하이퍼링크를 텍스트 줄 안에 넣을 수도 없다. 여전히 각 문단을 하나의 길고 긴 단일 줄로 작성해야 한다.
Gemini 창립자들이 이처럼 원시적인 포맷을 택한 이유는, 내 생각엔, 클라이언트를 구현하기 쉽게 하기 위해서였다. 타당하다. Gemtext는 적어도 파싱하기 쉽고 표시하기 쉽다. 그래도 쓰기 짜증나고, 다른 포맷에서 변환하기도 꽤 지루하다.
문서 포맷 주제는 여러 포럼에서 반복적으로 논의되었다. 기본 문서를 Markdown에 더 가까운 형태로 만들자는 제안도 종종 있었다. 어느 정도는 Gemini 클라이언트 유지보수자들도 그 아이디어에 열려 있었다. Markdown은 파싱이 특별히 어렵지 않다. 솔직히 Markdown은 사용자에게 있는 그대로 보여줘도 읽을 만하다.
Gemtext 문서에서 ANSI 터미널 이스케이프를 허용하자는 제안도 있었다. 그러면 무엇보다도 텍스트의 색상과 강조를 쉽게 바꿀 수 있었을 것이다. 나는 이 계획에 전적으로 찬성하진 않았다. 콘솔 기반 클라이언트에서는 구현이 쉽고, 사실 리눅스에서는 콘솔에 이미 표시 로직이 있으니 거의 자동으로 되는 셈이다. 하지만 그래픽 애플리케이션이나 리눅스가 아닌 환경의 애플리케이션에는 성가신 일이 되었을 것이다.
그럼에도 여러 클라이언트가 이 제안에 대한 초기 지원을 제공했고, 실제로 동작하는 것도 확인할 수 있었다. 하지만 이 아이디어는 Gemini 개선을 위한 대부분의 제안과 마찬가지로—정중하되 완강하게—거절됐다. Gemini 열성 지지자 핵심층은 지금 모습 그대로가 만족스러운 모양이다.
그러면 “작은 웹” 프로토콜의 다른 잠재 사용자들은 Gemini의 결함을 참고 살아가거나, 대안 구현을 만들어야 한다. 이에 대해서는 뒤에서 더 이야기하겠다.
둘째 문제도 2020년과 동일하다. Gemini 기반 온라인 서비스의 휘발성이다. 예를 들어 Gemini용 검색 엔진을 만드는 것은 충분히 가능하지만, 이런 것들은 생겼다 사라진다. 지금 내 최애는 Kenedy(gemini://kennedy.gemi.dev/)다. 하지만 운영자는 이렇게 말한다.
“Kennedy runs on an Late 2014 Mac mini…”
이 역시 장기적으로 의존하기 어려운 서비스일 수 있다. 물론 다른 서비스가 나타날 수도 있지만—문제는 그것들을 찾아내는 일이다.
다른 서비스들도 마찬가지로 생겼다 사라졌다. 한때 “gemipedia”라는 Gemini 기반 온라인 백과사전이 있었다. 그것도 사라진 것 같고, 다시 돌아올지는 전혀 모르겠다. 뉴스 애그리게이터, 게시판, 기타 여러 유용한 것들이 있지만—내일도 여전히 있을지 확신하기 어렵다. Gemini 관련 서비스 목록을 어디서 찾더라도, 몇 주만 지나면 구식이 될 것이다. 좋든 나쁘든, 이것은 Gemini가 취미 기반이라는 특성의 결과다.
셋째, 그리고 앞의 점과 관련해서: 내가 아는 한, 가상 호스팅 지원을 갖춘 상업적 Gemini 호스팅을 제공하는 곳은 없다. Gemini 커뮤니티가 작기 때문에, 지금은 누군가의 서버에서 공간을 얻는 것이 그리 어렵지 않다. 하지만 가상 호스팅이 없으면, 장기적인 용도로는 그 공간을 효과적으로 쓰기가 어렵다.
예를 들어 나는 내 도메인 이름을 갖고, 공유 서버의 특정 콘텐츠 디렉터리로 해석되도록 만들 수 없다. 이것이야말로 모든 상업적 웹 호스트가 동작하는 방식이다. Gemini 서버가 이를 지원하지 못하는 것이 아니다—일부는 지원한다. 다만, 누구도 그것을 널리 사용 가능하도록 설정해 놓지 않은 것 같다.
가상 호스팅의 부재는 제안된 Gemini 확장들 중 일부가 잘 동작하지 못하게 한다. 예컨대 Gemini 캡슐에 “favicon”을 추가하는 초안 사양이 있는데, 일반 웹사이트에서의 동작과 유사하게 하려는 것이다. 하지만 제대로 된 가상 호스팅이 없으면, 서버를 사용하는 캡슐이 몇 개든 상관없이 서버 전체에 대해 favicon을 하나만 설정할 수 있게 된다.
이런 것들은 Gemini 프로토콜 자체의 한계도 아니고, 이를 지원하는 클라이언트와 서버의 한계도 아니다. 오히려 Gemini의 보급이 비교적 느려서 대규모의 상업적 수준 호스팅을 하는 사람이 없다는 점을 보여주는 현상들이다.
2020년 이후 우리가 알아차린 것 중 하나는 인증이 다소 번거롭다는 점이다. 공정하게 말하자면, Gemini는 원래 인증이 필요한 종류의 웹 기반 애플리케이션을 염두에 두고 만들어진 것이 아니다. 하지만 단순한 게시판 서비스조차 사용자 A와 사용자 B를 구분할 방법이 필요하다.
Gemini는 TLS에 의존하기 때문에, 필요하다면 클라이언트 인증서를 인증에 사용할 수는 있다. 불행히도 여러 서비스에 대해 클라이언트 인증서를 만드는 일은 번거롭다. Lagrange 같은 클라이언트는 이를 자동으로 할 수 있지만, 그럼에도 인증서를 안전하게 보관하고 백업하는 문제는 남는다. 사용자/비밀번호 조합은 그냥 기억하면 되지만, TLS 인증서는 저장되어야 한다.
일반 웹에서는 수십 년 전부터 TLS 클라이언트 인증서를 인증에 사용할 수 있었지만, 기업 간 운영을 제외하면 실제로 사용하는 곳은 없다는 점이 눈에 띈다. 여전히 대부분은 사용자/비밀번호이고, 보안이 정말 중요한 경우에는 OAuth2와 다중 인증이라는 악몽이 뒤따른다.
하지만 가장 큰 새로운 문제는, Gemini의 약점 때문에 “작은 웹” 커뮤니티가 분열되었고, 이미 제한적인 자원이 더 얇게 퍼지게 되었다는 점이다.
내가 언급한 Gemini의 한계 때문에, 열성 사용자들은 대안 프로젝트들을 만들어 냈다. 예를 들어 Spartan은 Gemini와 매우 비슷하지만 암호화가 없다. 불행히도, 문서 포맷은 Gemini와 동일한 Gemtext를 여전히 강제한다. 게다가 암호화를 선택할 옵션조차 없으니, 보안이나 프라이버시가 필요한 어떤 애플리케이션에도 적합할 수가 없다.
Scorpion은 또 다른 단순한 Gemini 유사 프로토콜로, 동일한 포트에서 암호화/비암호화 트래픽을 모두 처리하도록 설계됐다. 이는 클라이언트 요청의 첫 바이트를 사용해 암호화를 할지 말지를 결정함으로써 구현한다. 따라서 암호화 사용 여부는 클라이언트 사용자의 선택이 된다.
원칙적으로 이는 두 세계의 장점을 모두 제공한다. 보안이 필요한 사용자는 보안을 얻을 수 있고, 평문 통신도 가능하게 남는다.
좋든 나쁘든, Scorpion은 다소 이상한 바이너리 문서 포맷을 갖고 있다. 이 포맷이 Gemtext의 일부 한계를 해결하는 것은 사실이다. 굵게/이탤릭 같은 단순한 서식을 지원하고, 문서 본문 중간에서 문자 인코딩을 바꾸는 것도 가능하다. 그리고 문서를 타입/길이 헤더를 가진 바이너리 블록으로 나누는 방식으로, 파싱을 어렵게 만들지 않으면서 이 두 가지를 수행한다. 각 블록은 특정 서식이나 특정 인코딩을 지정할 수 있다.
하지만 (내가 아는 한) Scorpion 포맷을 위한 편집 도구는 없다. 그래서 할 수 있는 최선은 다른 문서 포맷(예: Markdown이나 HTML)에서 변환하는 것뿐이다. 그렇다면 애초에 왜 Markdown이나 HTML을 쓰지 않는가?
어떤 새 프로토콜들은 Gemini보다도, 심지어 Spartan보다도 훨씬 단순하다. 나는 Nightfall Express, 즉 nex를 꽤 좋아한다. 이 프로토콜은 암호화되지 않았고, 고정폭 글꼴을 위한 사전 포맷 레이아웃으로 일반 텍스트 데이터를 반환한다. 즉, 작성자가 보는 이에게 어떻게 보일지를 정확히 정해 레이아웃을 만들 수 있다.
nex 문서 포맷의 문제는 명백하다. 우리는 더 이상 80x25 터미널의 세계에 살지 않는다. nex 문서를 스마트폰 같은 세로형 디스플레이에 맞게 제대로 포맷할 수 있을지 모르겠다. 그래도 nex용 문서를 작성하는 건 매우 쉽다.
이 모든 대안들의 문제는, Gemini와 비교해도 채택이 작다는 점이다. Gemini 자체도 세상을 뒤흔들 정도는 아닌데 말이다. 내가 보기엔, 전 세계적으로 Spartan을 호스팅하는 서버는 대략 스무 개 정도다. 물론 아직 초기이고, 이런 대안 프로토콜들의 채택이 늘어날 수도 있다. 하지만 그동안, 이런 종류의 기술에 관심 있는 작은 커뮤니티는 점점 더 작은 그룹으로 쪼개지고 있다.
나는 Gemini라는 아이디어를 좋아하지만, 그 구현에 완전히 만족하진 못한다. 처음 Gemini를 접했을 때, 너무 깊이 투자하기 전에 더 나은 무언가가 나타날지 지켜보기로 했었다.
안타깝게도, 더 나은 것이 나타났는지 확신이 서지 않고, 앞으로도 나타날지 모르겠다. 제안되는 모든 대안은 나름의 약점이 있다. 지금 시점에서는, 또 다른 프로토콜을 제안해 사용자 기반을 더 쪼개기보다는, 결함이 있더라도 Gemini를 지원하는 편이 더 합리적으로 느껴진다.
그래서 나는 이 웹사이트의 글 일부를 Gemini 포맷으로 변환하기 시작하고 있다. 또한 여기에는 나타나지 않을 새 글들도 추가할 예정이다. 내 전문적 관심사와 관련이 없거나, 직장에서 보기엔 안전하지 않은 내용이기 때문이다. 내 Gemini 캡슐이 본 사이트만큼 커질 가능성은 없지만, Gemini에 어떤 콘텐츠라도 올려 두어 조금이나마 도움이 되고 싶다.
내 Gemini 캡슐은 gemini://larsthebear.me/에서 찾을 수 있다. 거기에 어떤 내용이 있는지 보고 싶지만 Gemini 브라우저 설치가 번거롭다면, HTML 버전도 있다. 다만 콘텐츠는 실제로 Gemini 브라우저로 읽도록 설계되어 있어, 일반 웹 브라우저에서는 다소 이상하게 보인다.
어쨌든 나는 계속 상황을 지켜보며 Gemini와 다른 것들이 어떻게 발전하는지 볼 생각이다.
나는 Gemini(또는 그와 비슷한 무언가)가 성공하길 정말로 바란다. 성장하고는 있지만, 5년 동안 캡슐이 약 5000개 늘었다는 건 그리 고무적이진 않다. Gemini가 제공하는 것을 원하는 사람들이 더 많아야 한다. 사실 나는 그런 사람들이 있다는 걸 알고 있다. “작은 웹”이 괴짜 취미 이상의 무언가가 되진 않을 것 같지만, 세상에는 괴짜가 많다.
나는 어떤 임계 질량이 존재하길 바란다. 사용자 기반이 충분히 커지면, Gemini가 눈덩이처럼 불어날 것이라는 기대다. 내가 기술적 한계라고 여기는 것들을 고치는 것만으로는 충분하지 않을 것 같다. 사람들이 진지하게 사용하기 시작해야 한다. 나도 내 작은 방식으로 그렇게 할 계획이고, 다른 사람들도 같은 일을 해주길 바란다.
_이 페이지에 대한 응답을 게시했나요?
이 글을 언급하는 블로그나 페이지의 URL을 적어, 나에게 알리기 위해 webmention을 보내도 좋다._
보내기
카테고리: small webMar 01 2026
