# Show HN: TownSquare, 웹사이트를 위한 작은 존재감 레이어

> Clean Markdown view of GeekNews topic #30699. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=30699](https://news.hada.io/topic?id=30699)
- GeekNews Markdown: [https://news.hada.io/topic/30699.md](https://news.hada.io/topic/30699.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-06-22T06:38:52+09:00
- Updated: 2026-06-22T06:38:52+09:00
- Original source: [townsquare.cauenapier.com](https://townsquare.cauenapier.com/)
- Points: 2
- Comments: 1

## Topic Body

- 콘텐츠만 보이던 웹사이트에 **방문자 존재감**을 얹어, 같은 페이지에 있는 사람들이 서로를 보고 짧게 대화할 수 있게 함
- 계정이나 알고리듬 없이 현재 접속 중인 사람만 드러내는 방식이라, 복잡한 소셜 기능보다 **즉시성**에 초점을 둠
- 설치는 `</body>` 앞에 단일 `<script>` 태그를 붙이는 방식이며, 빌드 단계나 별도 의존성이 필요 없음
- 데모에서는 방향키 이동, `T` 말하기, `J` 점프, `H` 하이파이브처럼 가벼운 상호작용을 제공함
- Hacker News 공개 이후 데모가 붐비며 지연·혼잡·봇이 있을 수 있지만, 실제 사이트마다 별도 TownSquare와 커뮤니티가 생김

---

### 웹사이트에 작은 실시간 공간 추가
- TownSquare는 콘텐츠 중심 웹사이트에 **사람이 함께 있는 느낌**을 더하는 도구임
- 방문자는 같은 페이지 안에서 서로를 볼 수 있고, 몇 마디를 주고받으며 같은 공간을 공유할 수 있음
- 기본 방향은 **No accounts**, **No algorithms**, “Just the present”임
- 추가 과정은 단순한 흐름으로 구성됨
  - `</body>` 앞에 단일 `<script>` 태그를 붙임
  - 방문자가 도착하는 즉시 서로 보임
  - 방문자가 이동하고, 환경과 상호작용하고, 인사하며 순간을 공유함
- 무료로 추가할 수 있고, 계정을 만들 필요가 없으며 약 1분이 걸린다고 안내됨

### 데모와 현재 상태
- 라이브 데모에서는 **Activate demo**를 눌러 공유 공간에 들어감
- 조작 방식은 클릭, 탭, `←`, `→` 이동을 지원함
  - `T`를 누르거나 이름을 탭하면 말할 수 있음
  - `J`는 점프, `H`는 다른 사람과 하이파이브임
- TownSquare는 사이트를 “inhabited corners of the web”의 네트워크에 연결하는 것을 목표로 함
- 공개 지표 영역에는 등록된 TownSquares, 지도상의 항목, 교환된 메시지, [GitHub stars](https://github.com/cauenapier/TownSquare)가 표시되지만 제공된 본문에는 숫자가 없음
- Hacker News에 올라간 뒤 공개 데모가 **overflowing** 상태가 되어 지연, 붐비는 방, 몇몇 봇이 있을 수 있음
  - 실제로는 각 웹사이트가 자체 TownSquare와 자체 커뮤니티를 가지며, 보통 더 조용하고 친근하다고 안내됨
  - 운영자는 moderation system 개선 작업 중이며, 그동안 서로 친절하고 존중해 달라고 요청함

## Comments



### Comment 60087

- Author: neo
- Created: 2026-06-22T06:38:53+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48608570) 
- 페이지 자체의 **타운 스퀘어**를 봤는데, 지금은 대체로 그냥 공격적인 말을 하려고 모인 사람들로 가득함
  - 수년간 여러 커뮤니티에서 운영자를 해봤고—90년대 BBC, 00~10년대 niche 포럼, 20년대 Reddit 게시판—이제는 방해성 이용자들이 서로 섞여 지내는 **그림자 서비스**를 운영하는 게 최선일 수 있다고 보게 됨  
    LLM의 등장은 이런 “커뮤니티 구성원”들을 따로 흘려보낼 길을 열어줌. 떠나거나 조용히 있느니 웃기려고 반사회적으로 기여하려는 사람들은, 자기들만큼 맞받아치는 상호작용형 메아리방에 참여하면 됨. 강력한 모델도 필요 없어서, 커뮤니티 입장에서는 공동체 방화범들과 공존하려 애쓰는 대안보다 전체 비용이 낮을 가능성이 큼  
    몇 년 동안 사람들을 생산적으로 “안으로” 끌어들이는 방법을 찾으려 했지만, 어떤 경우에는 중간 지점을 찾는 일이 개인에게도 커뮤니티에도 가치가 전혀 없어서 헛수고라는 걸 깨달음. 그들은 불타는 걸 보고 싶어 하고, 커뮤니티는 그들이 나가길 바랄 뿐임
  - 300ms쯤 지나자마자 “**운영 관리**가 문제가 되겠군”이라고 생각함
  - 아주 가볍고 빠른 **LLM**이 메시지를 실시간으로 검토할 수도 있을 듯함. 다만 비용이 얼마나 들지는 모르겠음
  - 그러니까 **Twitter 플러그인**인가?

- 마음에 듦. HN 방문자 한 명이 계속 “dick and balls”만 치고 있는 것도 마음에 듦. **운영자 없는 익명 광장**이란 게 원래 그렇지
  - 틀리지 않았다면 그건 dang이었음

- 재미있어 보였음  
  안타깝게도 들어가 보니 누군가 봇을 붙여서 여러 사람이 “dick and balls”를 계속 도배하고 있었음  
  그래도 관심을 받으면 예상 가능한 일임. 다른 사이트에서는 괜찮은 추가 기능이 될 수 있고, 개념도 훌륭함

- 예시 스크린샷과 라이브 데모의 **일반적인 인터넷 행동** 사이 대비가 웃김
  - 바꿔 말하면, 인터넷과 접촉한 뒤에도 살아남는 **운영 관리/검열/필터링** 방식은 없음. 그냥 불가능함. 사람들은 그걸 도전 과제로 받아들이고, 유용성을 유지하면서도 이를 처리하는 시스템은 설계할 수 없음  
    단어를 금지하면 사람들은 오타나 다른 철자를 도입함. 개념을 금지하면 개념 자체를 바꿈. 요즘 유행하는 “unalive” 같은 게 그 예임. 사람들이 불쾌하게 굴고 싶으면 그렇게 굴고, 새 단어를 만들거나 완곡어법을 써서 자기 의도를 전달함

- 운영 관리, 운영 관리, 운영 관리. 큰 문제임  
  내 브라우저 게임/엔진에도 비슷한 **운영 관리 우려**가 있는데, 욕설은 막지 않고 모욕적 비하 표현만 금지함. 대신 그 단어가 허용되지 않는다는 시각적 힌트는 전혀 주지 않음  
  플레이어가 입력 내용을 볼 수 있는 유일한 표면은 공유 카드이고, 게임을 끝내고 공유 카드까지 가야 공격적인 단어가 **REDACTED** 처리된 걸 알게 됨  
  장난이 아무 데도 이어지지 않는다는 걸 알아내기까지 피드백 루프가 길어지는 셈임
  - 비하 표현과 욕설의 차이가 뭐임?
  - 아니면 그냥 사람들이 말하게 둘 수도 있지 않나? **소셜 기능**을 쓰는 사람들은 대체로 다른 사람과 말하고 싶어서 쓰는 거고, 거기에는 본질적인 위험이 있음

- 정말 멋짐. 내 작은 **웹버스** 영역에서 어떤 사람들을 못 들어오게 할 방법이 있을까?  
  댓글들을 읽어보니, 몇몇 못된 사람들이 나타나지 않게 내 사이트에서만 날려버릴 수 있다면—가능하면 Doom 샷건으로—기꺼이 쓰겠음. 또 내가 설정할 수 있는 필터, 예를 들어 비하 표현 등을 자동 차단하는 기능도 있으면 좋겠음. 다른 사람들은 원하는 대로 운영하면 되지만, 유독한 사람들이 모든 걸 망치는 게 이제 지겨움

- 작년에 비슷한 걸 만들었음. 페이지 오른쪽 아래에 말풍선처럼 붙는 **P2P 채팅 팝업**으로, 모든 방문자가 서로 채팅할 수 있게 해줌. 간단한 키워드 기반 운영 관리가 내장되어 있었지만 쉽게 우회 가능했음  
  GitHub OAuth를 붙여 알려진 신원을 만들고, 사이트를 넘나들며 방문자들이 서로 대화할 수 있도록 영속 메시징도 추가할 계획이었음  
  웹마스터가 자기 사이트에 스크립트를 추가하는 방식이 아니라, 브라우저 확장 기능이었음  
  목적은 두 가지였음. 비슷한 관심사를 가진 사람들을 알아가는 것, 그리고 탈중앙 채팅/메시징 시스템 비슷한 걸 시도해보는 것
  - 좋은 아이디어 같지만, 규모가 커지면 한 번만 작동하는 유형일 듯함. 수억 개 페이지가 있으면 확장 기능이 이미 아주 인기 있지 않은 이상 가장 흔한 페이지에서만 다른 사람을 만나게 되지 않을까?

- 90년대에 이와 비슷한 **Third Voice**라는 게 있었음. 멋진 아이디어였지만, 브랜드들의 반발이 꽤 컸던 걸로 기억함  
  [https://en.wikipedia.org/wiki/Third_Voice](<https://en.wikipedia.org/wiki/Third_Voice>)

- Matt Webb이 예전에 이것의 한 버전을 만들고 글도 썼음—Cursor Party: [https://interconnected.org/home/2024/09/05/cursor-party](<https://interconnected.org/home/2024/09/05/cursor-party>)  
  한동안 내 사이트에 구현할까 고민했지만 JavaScript를 추가하고 싶지 않아 접었음. 그래도 여전히 아주 귀여운 개념이라고 봄

- 권한을 **수신 클라이언트**에 두고, 의견이 반영된 기본값을 제공하는 운영 관리 방식을 시험해보고 싶음  
  클라이언트가 스스로 필터링하고, 이용자를 음소거하고, 보이지 않게 만들게 하는 것임. 앱에 맞는 합리적인 기본 설정은 두되 사용자가 덮어쓸 수 있게 함  
  OpenAI의 무료 moderation endpoint 같은 저렴한 목적 특화 LLM으로 텍스트를 분류하고, 원문과 분류 결과를 클라이언트에 보내서 클라이언트가 무엇을 할지 선택하게 하면 됨. 앱에 맞는 강한 기본값을 함께 두고  
  콘텐츠만 보고 처리하는 것보다 지속적인 악성 행위자를 식별할 필요는 여전히 있을 수 있음. 그래도 그 정보로 무엇을 할지는 클라이언트가 정하게 해야 함  
  이런 프로젝트가 사용자에게 환영받는 경험을 제공하려면, 가해자에게 보이지 않는 강한 기본 자동 운영 관리가 필요하다고 봄. 하지만 그 권한을 LLM과 고정 필터 목록에 맡기는 건 매우 잘못된 느낌이라, 그런 도구들을 클라이언트 권한을 키우는 데 쓰자는 생각임. 다만 어차피 아무도 기본 설정을 바꾸지 않는다면 차이가 없을지도 모름
  - 반대로, 누군가 자기 사이트를 만든다면 방문자에게 그 사이트가 주는 **인상**을 중요하게 생각할 수 있음  
    자신이 만들고 호스팅하는 사이트에서 어떤 인상을 줄지 선택할 자유가 있어야 한다고 봄. 자기 광장을 신호보다 소음으로 채우고 싶다면 그것도 당연히 선택임. 하지만 소음보다 신호로 채우는 선택도 할 수 있어야 함. 핵심은 사이트 소유자가 자기 창작물에 원하는 인상을 줄 선택권을 가져야 한다는 것임  
    다시 말해, 그 인상이 시끄러운 트롤에게 탈취되길 원한다면 그것도 선택할 수 있음