
최근 긱뉴스를 둘러보다가 흥미로운 스레드를 발견했습니다.
Discord가 한대의 서버로 2백만명의 동시 사용자를 서빙하는 방법
평소 매일같이 사용하는 디스코드가 수백만 명의 동시 접속자와 실시간 음성/채팅 트래픽을 어떻게 감당하는지에 대한 내용이었습니다. 비결의 핵심에는 BEAM 위에서 동작하는 Elixir(엘릭서)라는 언어가 있었고, 비슷한 구조를 웹 서비스에 적용할 때 많이 쓰이는 프레임워크인 Pheonix(피닉스)도 있었습니다.
해당 스레드에서 설명한 “길드마다 하나의 프로세스, 세션마다 또 다른 프로세스”라는 아이디어를, 훨씬 작은 스케일의 실험으로 옮겨 보고 경험해보고 싶었습니다.
그렇게 바이브코딩으로 개발한 프로젝트가 바로 Cursor Party입니다.
Cursor Party 체험해보기
Cursor Party 깃허브
(14일 무료 호스팅플랜이 끝나 2026년 1월 9일부로 베타 테스트 서비스를 종료했습니다.
관심 가져주셔서 감사했습니다!)
(Show GN에 올렸더니 어떤분이 오토클리커 돌려놓으셨네요 😂)
이 웹 게임은 아주 간단합니다.
핵심은 이 모든 상호작용이 지연 없이 모든 클라이언트에게 동기화되어야 한다는 점입니다.
직접 만들어보며 느낀 Elixir와 Phoenix LiveView의 경험은 기존의 웹 개발 방식과는 달랐습니다.
보통 이런 실시간 기능을 구현하려면 React나 Vue로 복잡한 프론트엔드 상태 관리를 구축하고, WebSocket 서버와 통신하는 코드를 작성해야 합니다. 상태 동기화 로직만 짜다가 1시간이 다 갈 수도 있습니다.
하지만 Phoenix LiveView는 접근 방식이 완전히 달랐습니다.
결과적으로 최소한의 JS hook만으로, 대부분의 인터랙션을 서버 렌더링(LiveView)만으로 구현할 수 있었습니다.
수십~수백 명 규모로 좌표를 브로드캐스트하는 테스트를 해도 서버는 여유로웠습니다.
Elixir/BEAM이 설계상 수십만 프로세스를 동시에 다루도록 만들어져 있어서, 규모를 더 키워도 구조적으로는 같은 패턴을 그대로 적용할 수 있습니다.
Node.js나 Python으로 구현했다면 스레드 관리나 성능 최적화를 고민했겠지만, Elixir 환경에서는 BEAM이 프로세스·메시지 패싱·클러스터링을 언어/런타임 차원에서 지원해 주기 때문에, 최소한 이 규모의 토이 프로젝트에서는 성능 병목보다 도메인 로직에 더 집중할 수 있었습니다.
이 프로젝트는 1시간 개발로 시작해 현재 오픈 베타 상태로 배포되었습니다. 기능은 단순하지만, Elixir가 자랑하는 분산 처리의 안정성을 직접 눈으로 확인하기엔 충분했습니다.
앞으로는 매주 새로운 기능을 하나씩 추가하며 이 프로젝트를 발전시켜 나갈 예정입니다.
더 궁금하신 분들은 아래 글을 읽어보시면 좋을 것 같습니다.
왜 Elixir를 공부해야 할까? Erlang/OTP BEAM으로 살펴보는 엘릭서