playbuns 소개

playbuns는 설치도 가입도 없이 브라우저에서 바로 여는 웹게임을 만듭니다. 게임은 전부 한 사람이 기획·개발·계측·배포합니다.

무엇을 만드나

playbuns의 게임은 대부분 하이브리드입니다. 이미 규칙이 널리 알려진 고전 장르 하나에, 그 장르가 원래 다루지 않던 판단을 하나 얹습니다. 스도쿠에 추리를 얹으면 「숫자를 채우는 일」이 「단서를 버는 일」이 되고(Murder Grid), 스도쿠에 카드 드래프트를 얹으면 「어디에 넣을까」가 아니라 「지금 이 카드를 쓸까 버릴까」가 됩니다(Draftoku). 2048에 시세를 얹으면 타일을 합치는 손이 매도 타이밍을 재는 손이 됩니다(Market 2048). 리버시에 생태계를 얹으면 「많이 뒤집을수록 이긴다」가 「너무 많이 차지하면 기근이 온다」로 뒤집힙니다(EcoFlip).

이 방식을 택한 이유는 분명합니다. 규칙 설명에 드는 시간을 0에 가깝게 줄이면서도 새로운 결정을 만들 수 있기 때문입니다. 처음 보는 사람도 «스도쿠구나», «2048이구나», «리버시구나»까지는 3초면 도달하고, 나머지 한 겹만 배우면 됩니다. 그 한 겹이 진짜 게임입니다 — 나머지는 이미 아는 것이라 설명할 필요가 없습니다.

지금 playbuns에는 이 공식을 따르는 게임이 14종 있습니다. 전부 나열하는 대신 이 페이지에서는 그 중 몇 개로 «왜 이 조합인가»를 보여 드리고, 게임 각각의 규칙과 공략은 각 게임 안내 문서에서 다룹니다.

설계 원칙

다섯 번째 원칙 — MVP를 만든 뒤 봇으로 계측해 스펙의 결함을 찾는다

손으로 몇 판 해 보고 «재미있다»고 판단하는 것은 검증이 아닙니다. 만든 사람은 규칙을 알기 때문에 무의식적으로 잘 되는 길로만 갑니다. 그래서 MVP가 나오면 반드시 무입력 봇 또는 그리디 봇을 돌려 게임을 실제로 몇백 판씩 시뮬레이션하고, 그 결과로 스펙 자체의 결함을 찾습니다. 세 가지 사례를 실제 계측 기록에서 그대로 가져왔습니다.

Magnet Break — 자석을 한 번도 켜지 않는 무입력 봇으로 12스테이지를 각각 60초씩 돌려 보니, 12개 중 4개(5·7·8·10 스테이지)가 조작 0회로 클리어됐습니다. 핵심 메커닉인 자석이 게임의 3분의 1에서는 없어도 되는 장식이었다는 뜻입니다. 원인은 목표 블록이 전부 공이 출발하는 중앙 열에 있었기 때문이었고, 처방은 공을 완전 수직으로 발사하고 목표를 절대 중앙 열에 두지 않는 것이었습니다. 재설계 후 같은 봇을 다시 돌리자 무입력 클리어는 0/12로, 정상적으로 자석을 쓰는 봇의 클리어율은 12/12로 나왔습니다 — 양쪽을 다 재야 «아무도 못 깨는 레벨»과 «누구나 깨지는 레벨» 양쪽 실패를 함께 피할 수 있습니다.

Chroma Drop — 게임오버 시점의 보드를 자동으로 분석하는 스크립트로 재 보니, 화면에 쌓인 줄 중 21~36%가 «수복 불가» 상태였습니다. 서로 다른 혼합색이 한 줄에 섞이면 그 줄은 영원히 지울 수 없는데, 플레이어는 그 사실을 알 방법도 되돌릴 방법도 없었습니다. 이건 밸런스가 아니라 규칙 자체의 구조적 결함이라고 판단해, 죽은 줄을 미리 경고하는 신호와 원색으로 되돌리는 «표백» 기능을 함께 추가했습니다. 처방 후 수복 불가 비율은 9%대까지 떨어졌고, 그 중에서도 실제로 효과를 낸 쪽은 경고 신호였다는 것까지 재측정으로 확인했습니다.

Peak Load — 시작 직후를 시뮬레이션하는 스크립트로 정전 게이지 추이를 재 보니, 플레이어가 손쓸 수 없는 게임 시작 20초 만에 이미 실패 예산의 22%가 소진되고 있었습니다. 첫 줄을 완성하는 데 15~25초가 걸리는데, 그 전에 이미 벌을 받고 있었던 것입니다. 처방으로 첫 방출 또는 25초 중 먼저 오는 시점까지는 정전이 쌓이지 않는 예열 구간을 넣었습니다. 같은 계측에서 국면별 난이도도 뒤집혀 있었다는 것이 드러났습니다 — 원래 «쉬워야 할» 아침 국면이 판당 게이지 누적 37.4로 «가장 험해야 할» 피크 국면의 24.2보다 오히려 가혹했습니다. 아침 수요 밴드를 올려 재조정한 뒤에는 아침 18.8, 피크 25.8로 의도한 순서가 회복됐습니다.

세 사례 모두 사람이 몇 판 해 봐서는 절대 못 잡는 종류의 문제였습니다. «어렵다»와 «불가능하다», «완만하다»와 «오히려 더 가혹하다»는 몸으로 느끼기엔 구별되지 않고, 숫자로 재야만 드러납니다.

어떻게 만드나

게임은 대부분 빌드 도구 없는 정적 웹앱입니다. 하나의 index.html과 순수 자바스크립트 모듈, CSS로 끝납니다. 프레임워크를 쓰지 않는 이유는 취향이 아니라 첫 화면이 뜨는 속도 때문입니다 — 모바일에서 링크를 눌렀을 때 로딩 화면을 보여 주는 순간 상당수가 떠납니다.

배포는 Cloudflare Workers이고, 게임마다 자체 서브도메인을 갖습니다(14개 게임 서브도메인 + apex 도메인, 총 15개 호스트). 계측은 GA4 통합 속성 하나로 대부분의 게임을 한 곳에서 보고, 일부 게임만 자체 GA 속성을 별도로 씁니다.

배포마다 검증이 자동으로 따라붙습니다. scripts/verify-site.sh는 배포한 호스트 하나를 실제로 curl로 두드려 canonical 태그가 있는지, GA4 태그가 있는지, AdSense 태그가 있어야 할 도메인(허브 안내 문서·덕질도감처럼 콘텐츠가 있는 곳)과 없어야 할 도메인(본문이 얇은 게임 셸)에 각각 맞게 붙어 있는지, robots.txt에 sitemap 지시자가 있는지, sitemap.xml의 각 <loc>이 실제로 200을 반환하는지, ads.txt에 퍼블리셔 ID가 있는지, 존재하지 않는 경로가 진짜 404를 돌려주는지(soft 404 방지)까지 14개 호스트 전수로 확인합니다. scripts/check-docs.mjs는 그와 별개로 안내 문서 40개를 배포 전에 기계적으로 검사합니다 — canonical이 자기 경로와 일치하는지, H1이 정확히 하나인지, JSON-LD가 전부 파싱되는지, hreflang ko/en 짝이 서로를 가리키고 실제로 존재하는지, meta description 길이, 내부 링크가 실제 파일을 가리키는지까지 전부 통과해야 배포합니다. 게임마다 별도의 Playwright 테스트 스위트도 있습니다 — 예를 들어 murder-grid의 CSS를 9개 파일에서 번들 1개로 합쳤을 때는 모바일·데스크톱 양쪽 전체 페이지 픽셀 비교로 차이 0px을 확인하고 테스트 163건을 통과시킨 뒤에야 배포했습니다.

AI 코딩 도구를 쓴다는 사실을 숨기지 않습니다. 다만 무엇이 맞는지 설계하고, 계측하고, 판단하는 것은 사람입니다. 실제로 새 게임을 만들 때 쓰는 스캐폴드 스크립트가 한동안 실수로 게임 화면에 광고 태그를 계속 심고 있었던 적이 있는데, 이건 사람이 짠 자동화가 낸 회귀였고, 그걸 잡아낸 것도 배포 직후 자동으로 도는 verify-site.sh였습니다. 잡힌 즉시 태그를 제거하고 스캐폴드 자체도 고쳤습니다. 도구가 코드를 만들어도, 그 코드가 지켜야 할 규칙을 정하고 위반을 확인하는 것은 사람의 몫으로 남겨 둡니다.

광고에 대해

운영 비용을 충당하기 위해 Google AdSense를 씁니다. 다만 어디에 실리고 어디에는 절대 싣지 않는지는 명확한 기준으로 나눠 두었습니다.

• 광고는 playbuns.com의 안내 문서, 제작 노트, 이 소개 페이지처럼 실제로 규칙·공략·설계 과정을 쓴 콘텐츠 페이지에만 실립니다.
• 게임 화면 — 14개 게임 서브도메인 전부 — 에는 광고가 없습니다. 게임 판 위는 본문이 얇아 콘텐츠 없는 페이지에 광고를 싣는 형태가 되기 쉽기 때문입니다.
• 개인정보처리방침·이용약관·문의 페이지에도 광고 태그를 아예 싣지 않습니다.
• 자동 전면광고(인터스티셜)나 게임 캔버스를 덮는 오버레이, 수동으로 배치한 광고 슬롯은 쓰지 않습니다 — 현재는 Google Auto ads만 문서 페이지에서 돌고 있고, 게임 판 위에는 아무 형태의 광고도 없습니다.
• 아동 대상 사이트가 아닙니다. 대상 연령은 만 14세 이상이고, 회원가입·문의 폼처럼 연령이 확인되는 경로 자체가 없습니다. 광고 개인화는 EEA·영국·스위스에서는 별도 동의가 없는 한 기본적으로 거부됩니다.
• 덕질도감(fandomdex)은 2026년 9월 5일부로 광고 대상에서 제외했습니다. 실존 인물과 기존 IP를 소재로 한 콘텐츠라 광고 정책상 보수적으로 판단했습니다.

자세한 기준은 개인정보처리방침에 적어 두었습니다.

운영

• 서비스명: playbuns (playbuns.com)
• 운영자: 진희수
• 소재 국가: 대한민국
• 문의: 문의 페이지 · jiniancompany@gmail.com

제작 노트

만들면서 실제로 틀렸던 것을 기록해 둡니다. 전체 목록은 제작 노트 인덱스에서 볼 수 있습니다.

• 이길 수 없는 게임을 두 개 만들었다 — 하루에 만든 2048 변형 둘이 각각 다른 이유로 클리어 불가능이었던 이야기입니다.
• 자석 없이도 깨지던 스테이지들 — 무입력 봇이 잡아낸 12개 중 4개의 조작 0회 클리어, 그리고 수직 발사로 고친 과정입니다.
• 지울 수 없는 줄이 3분의 1이었다 — 혼합색 규칙이 만든 «수복 불가» 줄을 찾아내고 표백 기능으로 대응한 기록입니다.
• 아침이 피크보다 험했다 — 가장 쉬워야 할 국면이 수치로는 가장 가혹했던 밸런스 역전을 계측으로 찾은 이야기입니다.

게임이 추가되거나 규칙이 바뀌면 각 게임 안내 페이지와 이 문서를 함께 갱신합니다.

자주 묻는 것

계정이 없는데 플레이 기록은 어디에 남나요?

이용자 브라우저의 localStorage에만 남고 서버로는 전송되지 않습니다. 회원가입도, 로그인도 없습니다. 기기나 브라우저를 바꾸면 그 기기의 기록은 사라지지만, 대신 저희가 보관하는 개인정보 자체가 존재하지 않습니다.

광고가 왜 게임 화면에는 없나요?

게임 화면은 본문이 얇아 콘텐츠 없는 페이지에 광고를 싣는 형태가 되기 쉽습니다. 그래서 14개 게임 서브도메인 전부에서 광고 태그를 뺐고, 광고는 규칙·공략·설계 노트를 실제로 쓴 playbuns.com의 안내 문서와 이 소개 페이지에만 둡니다.

데일리 퍼즐이 전 세계 모두 같은 이유는 무엇인가요?

퍼즐을 Math.random이 아니라 날짜에서 결정론적으로 만들기 때문입니다. 같은 날짜에 접속한 사람은 지역에 관계없이 완전히 같은 문제를 받습니다. 배포 전에는 1년치를 전수 검증해 풀리지 않는 날이 없는지 확인합니다.

규칙 문서와 실제 게임이 다르면 어느 쪽이 맞나요?

게임 코드가 맞습니다. 안내 문서는 코드를 읽고 쓰지만 사람이 쓰는 이상 어긋날 수 있습니다. 실제로 한 게임에서 도움말 문구가 실제 규칙과 다른 것이 발견된 적이 있고, 그때는 코드 기준으로 문서와 게임 내 문구를 함께 정정했습니다. 어느 쪽이든 발견 즉시 정정하고 갱신일을 갱신합니다.

덕질도감(fandomdex)에는 왜 광고가 없나요?

덕질도감은 실존 인물과 기존 IP를 소재로 한 콘텐츠라, 2026년 9월 5일부로 광고 정책상 보수적으로 판단해 광고 대상에서 제외했습니다. 다른 12개 게임과는 다른 기준이 적용되는 유일한 서비스입니다.

문의는 어떻게 하나요?

문의 페이지의 양식을 쓰거나 jiniancompany@gmail.com으로 메일을 보내면 됩니다. 운영자 한 사람이 직접 확인하고 답합니다.