작은 웹게임이 블로그보다 체류 시간을 잘 만드는 이유

읽는 시간과 조작하는 시간은 다르다

블로그 글은 정보를 전달하기 좋다. 하지만 짧은 글은 빠르게 소비되고 끝난다. 솔직히 나도 검색해서 들어간 글은 필요한 문장만 보고 닫을 때가 많다. 방문자가 한 번 더 머무르려면 읽은 내용을 손으로 확인할 수 있는 작은 행동이 필요하다. 클릭, 분류, 선택, 결과 확인 같은 단순한 상호작용이 그 역할을 한다.

가벼운 웹게임은 거창할 필요가 없다. 규칙 하나, 조작 하나, 결과 하나면 충분하다. 예를 들어 회의 중 결정 신호를 누르고 잡담 신호는 넘기는 게임은 1분 안에 이해된다. 아니, 10초 안에 이해되어야 한다. 그래야 “뭐야 이거” 하면서 한 번 눌러본다.

좋은 작은 게임의 조건

• - 첫 화면에서 규칙을 이해할 수 있다
• - 모바일에서 엄지로 조작할 수 있다
• - 실패해도 바로 다시 할 수 있다
• - 결과가 짧고 공유 가능한 문장으로 나온다
• - 글에서 다룬 관점을 손으로 확인하게 만든다

검색 유입을 노리는 글만 늘리면 사이트가 얇아 보일 수 있다. 반대로 글과 Play가 연결되면 같은 주제를 읽고, 해보고, 결과를 확인하는 흐름이 생긴다. 이 흐름이 bobob.app의 1차 실험 방향이다.

한 페이지에서 확인하려는 신호

작은 게임을 붙이는 이유를 “체류 시간이 늘어난다”로만 잡으면 금방 이상해진다. 그러면 조작은 많지만 기억나는 판단은 없는 페이지가 된다. 그래서 지금은 한 Play를 열었을 때 아래 신호가 보이는지를 먼저 본다.

이 표를 두는 이유는 내 욕심을 줄이기 위해서다. 작은 사이트에서 랭킹, 계정, 댓글, 저장 기능을 한 번에 붙이면 운영 부담이 먼저 커진다. 지금 필요한 것은 “이 사람이 직접 만들고 고치고 있구나”가 보이는 표면이지, 큰 서비스처럼 보이게 하는 장식이 아니다.

글과 Play가 서로 보완하는 지점

체류 시간을 억지로 늘리고 싶은 것은 아니다. 의미 없는 애니메이션이나 광고성 요소로 붙잡고 싶지도 않다. 다만 사용자가 글을 읽고 "아, 이 판단을 손으로 해보면 이런 느낌이구나" 하고 한 번 더 눌러보는 흐름은 좋다. 그 흐름이 있으면 사이트가 단순 정보 목록보다 조금 더 살아 있다.

그래서 목록을 줄인다

Play가 있다고 모든 짧은 메모를 전부 공개 목록에 펼칠 필요는 없다. 오히려 대표 글과 제작 로그가 먼저 보여야 한다. 짧은 변경 기록은 Play별 로그 안에 들어가면 충분하다. 방문자는 작은 게임 하나가 여러 번 다듬어진 과정을 한 페이지에서 보고, 바로 그 Play를 열 수 있다. 이 편이 검색어만 맞춘 짧은 글 수십 개보다 낫다.

이번 정리에서 특히 조심한 것은 “짧은 글을 숨기기만 하는 것”이 아니다. 숨기기만 하면 기록이 사라진다. 대신 금고 번호 추리판, 합 10 드래그, 회의 끝낼 단서 찾기처럼 Play별로 흩어진 메모를 제작 로그로 묶는다. 한 페이지 안에서 처음 만든 이유, 고친 기준, 버린 표현, 검증한 항목이 같이 보이면 짧은 메모 여덟 개보다 훨씬 낫다.

제작할 때 버린 선택

• - 로그인해서 결과를 저장하는 기능은 이번 단계에서 뺐다. 개인 사이트의 첫 Play는 저장보다 즉시 이해가 더 중요하다.
• - 순위표도 뺐다. 작은 실험에서 순위표가 먼저 보이면 사용자는 결과 공유보다 경쟁 규칙을 찾게 된다.
• - 긴 튜토리얼을 뺐다. 규칙 하나를 화면에 올리고, 나머지는 첫 조작에서 느끼게 하는 편이 맞다.
• - 외부 배너나 가입 유도 버튼도 붙이지 않았다. 사용자가 입력하고 결과를 보는 흐름보다 앞에 나오면 Play의 이유가 흐려진다.
• - 비슷한 짧은 변경 글을 계속 indexable로 두지 않는다. 대표 로그가 있으면 짧은 메모는 archive/noindex 후보로 남긴다.

이런 선택은 기능을 못 만들어서가 아니라 지금 표면에 필요한 밀도를 맞추기 위한 결정이다. 처음 들어온 사람이 “게임이 있네”보다 “글과 게임이 같은 사람이 같은 문제를 두고 만든 흐름이네”라고 느끼는 쪽이 더 중요하다.

바로 해보기

회의 끝낼 단서 찾기는 회의 중 진짜 결정 신호만 누르는 탭 게임이다. 읽는 대신 바로 눌러보면 회의가 왜 길어지는지 감으로 알 수 있다.

검증하면서 남기는 항목

Play를 하나 추가하거나 고칠 때는 화면에서 몇 가지를 꼭 본다. 첫 화면에 h1이 하나만 있는지, 결과 영역이 `data-play-result`로 잡히는지, 공유 버튼이 `data-play-share`로 동작하는지, 결과 뒤 관련 Blog와 related Play가 실제 링크로 이어지는지 본다. 모바일에서는 엄지로 누를 수 있는지 보고, 데스크톱에서는 키보드나 마우스 조작이 어색하지 않은지 본다.

콘텐츠 쪽에서는 그 Play와 연결된 대표 글이 400단어를 겨우 넘기는지보다, 제작 판단이 남아 있는지를 본다. 무엇을 넣었는지보다 무엇을 뺐는지가 더 중요한 때가 많다. 예를 들어 회의 게임은 “회의 문장 분류”가 핵심이지 회의록 관리 도구가 아니다. 우선순위 게임은 “오늘 판 밖으로 미룰 일”을 느끼게 하는 것이 핵심이지 프로젝트 관리 앱이 아니다.

체류 시간보다 먼저 봐야 할 것

작은 게임을 붙인다고 자동으로 좋은 사이트가 되는 것은 아니다. 사용자가 왜 눌렀는지, 눌렀더니 글에서 말한 판단이 실제로 느껴졌는지가 먼저다. 회의 게임이면 “잡담과 결정 신호를 구분한다”가 보여야 하고, 우선순위 게임이면 “오늘 할 일과 미룰 일을 나눈다”가 보여야 한다. 그냥 클릭 시간이 늘어나는 것은 목표가 아니다.

그래서 Play를 붙일 때도 관련 글을 억지로 많이 연결하지 않는다. 자연스럽게 이어지는 글 하나, 바로 해볼 Play 하나, 결과 뒤에 다시 갈 링크 정도면 충분하다. 이 밀도가 맞아야 Blog와 Play가 서로를 보완한다.

지금 bobob.app에서 Play는 블로그의 보조 장식이 아니라, 글에서 말한 판단을 손으로 확인하는 장치다. 글만 있으면 운영자의 생각이 남고, Play만 있으면 짧은 장난감으로 끝날 수 있다. 둘이 붙었을 때 “왜 이런 규칙을 택했는지”와 “눌러보니 어떤 감각인지”가 같이 남는다. 그 방향이 맞는지 확인하려고 대표 글을 줄이고, 짧은 메모를 묶고, Play 결과 링크를 계속 점검한다.