본문으로 건너뛰기
2026년 8월 8일 · 게임

사람들이 실제로 함께 즐길 수 있는 게임

이 글은 발행 시점의 제품을 설명합니다. 현재 기능은 AI 빌더에이전트 팀을 참고하세요.

사람들이 실제로 함께 즐길 수 있는 게임

취미로 만든 게임 빌드가 잘못되는 걸 세 번 목격했고, 각각의 사례가 뒤에 남긴 문제를 통해 올바른 설정이 실제로 어떤 모습이어야 하는지 알려줍니다.

실수 1: 브라우저에게 점수를 맡기기

가장 흔하면서도 가장 피하기 쉬운 실수입니다. 누군가 리더보드가 있는 게임을 만들고, 멀티플레이어 부분에 웹소켓을 연결한 뒤, 클라이언트가 최종 점수를 계산해서 서버로 POST하도록 내버려둡니다. 입력값 검증은 전혀 없습니다. 이런 일이 실제로 벌어지는 걸 직접 목격했는데, 지루해진 플레이어가 개발자 도구를 열고 네트워크 탭을 찾아 9자리 점수를 제출하기 시작하는 데 약 4분 걸렸습니다. 해커라서가 아니라, 게임이 그에게 펜을 쥐여주고 스스로 시험을 채점하라고 한 것과 다름없었기 때문입니다.

해결책은 대단한 게 아니라 그저 번거로운 일입니다. 클라이언트를 절대 신뢰하지 않는 것이 원칙입니다. 모든 동작은 서버 측에서 재검증되고, 모든 물리 틱은 서버가 사실이라고 판단하는 상태와 조정되며, 로컬 렌더링으로 겉만 그럴듯하게 넘기는 대신 상태를 왕복시키는 지연 비용을 감수해야 합니다. 그래서 여기서 서버 측 권한은 있으면 좋은 항목이 아니라 기본 기준입니다. 브라우저 콘솔로 이길 수 있는 게임은 크래시와 같은 심각도의 결함으로 취급됩니다. 실질적으로 그게 결함이기 때문입니다.

실수 2: 캔버스 요소와 비프음을 게임이라고 부르기

이런 경우는 시연에서는 근사해 보이지만 실제 플레이 90초 만에 무너집니다. CSS 트랜지션 몇 개, 충돌 검사, 펀치 소리를 대신하는 사인파 하나로 화면 녹화는 그럴싸하게 나오지만, 첫 실제 플레이어는 조작감이 이상하다고 말하면서도 이유는 설명하지 못합니다. 물리 엔진 문제입니다. 직접 만든 "겹치면 튕기기" 코드는 질량, 마찰, 충돌 반응을 제대로 구현하지 못하고, 플레이어는 이름 붙이지 못해도 그 차이를 체감합니다.

여기서 만드는 게임 빌드는 대신 실제 엔진 렌더링을 사용합니다.

  • 물리와 렌더링 — 웹 콘텐츠에는 실제 물리 시뮬레이션이 적용된 three.js를, 더 무거운 작업에는 에서 정식 Unity 6을 사용합니다.
  • 아트 — 스톡 에셋 팩이 아니라 디자인 디렉터에게서 나옵니다.
  • 오디오 — 발소리를 흉내내는 오실레이터가 아니라 샘플링된 악기 음원.

이게 왜 선택 사항이 아닌지에 대한 더 긴 설명은 Real engines, real builds에 있습니다.

검증 체인은 스크린샷 한 장으로는 잡아낼 수 없는 실패를 잡아냅니다:

  • 키를 누릅니다.
  • 점수가 실제로 변하는지 확인합니다.
  • 오디오 출력을 감지합니다.

너무 기본적이라 쓸모없어 보일 수 있지만, 완벽한 첫 프레임을 렌더링해놓고 이벤트 리스너가 연결되지 않아 조용히 멈춰버리는 빌드가 얼마나 많은지 알면 생각이 달라집니다. 정적 이미지로는 이걸 알 수 없습니다. 세 번의 플레이 라운드를 견뎌내야 하는 검증기라면 알 수 있습니다.

실수 세 번째: 친구한테 게임 하려고 서버를 돌리게 하는 것

좋은 멀티플레이어 프로토타입은 게임이 나빠서가 아니라 "일단 서버를 npm install하고, 환경 변수 세 개를 설정하세요"라는 요구가 화요일 저녁에 하기엔 너무 부담스러워서 이 단계에서 계속 죽어나갑니다. 재미있는 걸 만들어놓고 설정 가이드 뒤에 묻어버린 셈이죠.

여기서 싱글플레이 게임은 다른 사이트와 똑같은 방식으로 공개됩니다 — 클릭 한 번으로 라이브 서브도메인이 생기고, 따로 배울 흐름이 없습니다. 멀티플레이어는 어딘가에서 계속 켜져 있어야 하는 실제 서버 프로세스가 있다는 점에서 다르기 때문에, 호스팅이 자동으로 처리되는 공개 플레이 페이지로 배포됩니다. 목표는 단순합니다: "같이 할래?"가 README가 아니라 그룹 채팅에 붙여넣는 URL이 되어야 한다는 것.

이 대비가 남기는 것

위 세 가지 실수에서 빠진 게 하나 있습니다: 로컬 2인 플레이입니다. 키보드 하나, 사람 둘, 대개 WASD 대 방향키, 팔꿈치가 부딪히는 그것 — 유통 문제가 전혀 없다는 이유로 과소평가받는 모드입니다. 링크도 필요 없고, 서버도 필요 없고, 밤 11시에 뭔가를 클릭해줘야 하는 친구도 필요 없습니다. 그냥 옆에 앉은 사람과 30초짜리 "아니 잠깐, 넌 플레이어 2야, 방향키 써"만 있으면 됩니다.

로컬 2인 플레이온라인 멀티플레이어
온보딩"아니 잠깐, 넌 플레이어 2야, 방향키 써" — 30초매치메이킹, 텅 빈 "상대방 대기 중" 화면
유통제로 — 링크도, 서버도, 밤 11시에 뭘 눌러줘야 할 사람도 필요 없음공개 플레이 페이지와 동시 접속할 다른 누군가가 필요함
전환율거의 100% — 유일한 마찰은 "의자 돌리기"상대방을 기다리다 이탈함

쇼케이스에 있는 에어하키와 아레나 브롤러 빌드가 정확히 이 점을 활용합니다.

세 가지 해결책 — 서버 사이드 권한, 실제 엔진, 호스팅되는 공개 플레이 페이지 — 에 로컬 2인 플레이의 기본 장점까지 더하면, 이 시스템이 지원하는 실제 범위가 나옵니다:

  • 싱글플레이어 — 기본값.
  • 로컬 2인 플레이 — 공짜로 얻는 승리.
  • 온라인 멀티플레이어 — 개발자 도구를 켠 심심한 10대도 버텨내도록 만들어짐.

모든 게임은 게임별 배포 상태와 함께 내 게임 라이브러리에 모이므로, 어느 빌드가 괜찮았는지 찾으려고 예전 채팅 스레드를 뒤질 필요가 없습니다. 그리고 Android용으로 패키징했다면, 처음부터 다시 시작하는 대신 곧바로 스토어 경로로 이어집니다.

경험에서 우러난 경고 하나: 로컬 2인 플레이 빌드는 검증에 필요한 것보다 훨씬 오래 "검증 목적으로 테스트"됩니다. 15분짜리 스모크 테스트가 40분짜리 에어하키 리매치 시리즈로 변하는 걸 본 적 있습니다. 시간도, 그리고 QA 자원봉사자들이 이제 패들 속도에 대해 강한 의견을 갖게 될 거라는 사실도 감안해두세요.
게임
공유XLinkedInFacebookRedditQuoraWhatsAppTelegram이메일
← 모든 게시글