개발자 도구 사이트에서 일단 해보는 곳으로 바꾼 이유
bobob.app을 개발자 멀티툴 중심에서 Blog + Play 중심의 작은 작업장으로 바꾸며 실제로 따져본 유입, 체류, 원본성, 운영 부담 기준입니다.
회의록 닫기 도장판 바로 하기도구 사이트만으로는 이유가 약했다
처음 bobob.app은 개발자 멀티툴에 가까웠다. JSON 포맷터, Regex, JWT, Base64 같은 도구는 검색 의도가 분명하고, 만들기도 비교적 명확하다. 입력이 있고, 출력이 있고, 복사 버튼이 있으면 한 페이지가 된다. 그래서 처음에는 이쪽이 가장 빠른 길처럼 보였다.
문제는 그다음이었다. 도구를 많이 만들수록 사이트가 조금씩 비슷해졌다. 이미 큰 도구 사이트들이 있고, 검색 결과에는 오래된 페이지와 강한 도메인이 많다. 새 사이트가 같은 도구 이름을 더 붙인다고 해서 갑자기 선택받기는 어렵다. 더구나 사용자는 필요한 값을 얻으면 바로 떠난다. 도구가 나쁘다는 뜻은 아니다. 다만 새 사이트의 중심을 전부 도구로 두면, "왜 여기여야 하는가"를 설명하기 어렵다.
그래서 방향을 바꿨다. 도구는 `/tools` 아래에 남겨둔다. 다만 첫 화면과 새 작업의 중심은 글과 Play로 돌린다. 글은 내가 실제로 막혔던 판단을 남기고, Play는 그 판단을 손으로 만져보게 만든다. 이 조합이 완벽해서가 아니라, 적어도 남의 사이트를 다시 조립한 느낌은 덜하다.
바꾸기 전에 본 기준
| 기준 | 도구 중심일 때 | Blog + Play 중심일 때 | 내가 택한 쪽 |
|---|---|---|---|
| 검색 의도 | JSON, Regex처럼 분명하지만 경쟁이 강함 | 개발 기록과 작은 게임은 검색량이 작아도 고유성이 있음 | 둘 다 두되 첫 화면은 Blog + Play |
| 체류 이유 | 값 복사 후 바로 이탈하기 쉬움 | 읽고, 한 판 해보고, 관련 글로 이어질 수 있음 | Play 결과 링크를 강화 |
| 원본성 | 기능이 비슷하면 차이가 흐림 | 제작 판단, 실패 기록, 작은 상호작용이 남음 | 직접 만든 기록을 전면에 둠 |
| 운영 부담 | 기능별 QA와 로컬 처리 경계가 필요함 | 글 품질, sitemap, 색인 상태를 계속 봐야 함 | 제출 표면을 작게 유지 |
| 확장 방식 | 새 도구를 계속 추가하면 얇아질 수 있음 | 글 하나와 Play 하나를 묶어 깊이를 만들 수 있음 | 짧은 글은 제작 로그로 통합 |
이 표를 적고 나서야 방향이 조금 분명해졌다. 새 도구를 하나 더 추가하는 일은 쉬워 보이지만, 실제로는 설명, 예시, 실패 케이스, 복사 전 체크, 관련 도구까지 같이 채워야 한다. 그렇지 않으면 페이지는 생겼는데 내용은 얇다. 반대로 Blog + Play는 글과 게임이 서로를 보완한다. 글은 왜 이런 작은 게임을 만들었는지 설명하고, Play는 그 글이 그냥 의견으로 끝나지 않게 만든다.
첫 화면에서 보여주고 싶은 것
첫 방문자가 들어왔을 때 "무료 도구 모음"만 보이면 사이트의 정체성이 흐려진다. 그래서 홈에서는 Blog + Play가 먼저 보여야 한다. 단, 흔한 랜딩 페이지처럼 거창한 선언을 늘어놓고 싶지는 않았다. 내가 원하는 첫 화면은 이런 느낌에 가깝다.
- - 최근에 실제로 손본 Play가 보인다.
- - 글 목록은 짧은 메모 수십 개가 아니라 대표 글 중심으로 보인다.
- - 도구는 숨기지 않지만 archive 역할로 보인다.
- - 로그인, 랭킹, 댓글, 결제 같은 무거운 장치는 없다.
- - 읽기, 한 판 하기, 필요한 도구 열기가 자연스럽게 이어진다.
이 기준 때문에 짧은 제작 메모를 전부 Blog 목록에 펼쳐두는 방식도 다시 봤다. 처음에는 "글이 많아 보이면 좋겠지"라고 생각했다. 그런데 실제로는 반대일 수 있다. 150단어짜리 변경 기록이 50개 늘어 있으면 사람에게도 검색 시스템에게도 중심 글이 잘 보이지 않는다. 그래서 짧은 메모는 삭제하지 않고 Play별 제작 로그로 묶기로 했다. 개별 메모는 남기되, 대표 목록과 sitemap에는 깊은 글을 먼저 둔다.
직접 만든 흔적이 보여야 한다
작은 사이트에서 가장 위험한 상태는 겉으로 페이지 수는 많은데, 읽어보면 어디서나 볼 수 있는 말만 반복되는 것이다. 나는 bobob.app이 그렇게 보이면 안 된다고 생각했다. 그래서 대표 글에는 최소한 하나 이상은 들어가야 한다고 정했다.
- - 왜 그 판단을 했는지
- - 바꾸기 전 화면이나 구조가 왜 약했는지
- - 바꾼 뒤 어떤 확인을 했는지
- - Search Console, sitemap, feed, Play 결과 링크처럼 실제 운영 경로가 어떻게 이어지는지
- - 실패했거나 아직 기다리는 부분이 무엇인지
이런 내용은 문장이 조금 거칠어도 사이트 주인이 직접 만졌다는 증거가 된다. 반대로 키워드를 자연스럽게 넣은 문단만 길게 붙이면 금방 티가 난다. 내 목표는 완성된 잡지가 아니라, 작은 작업장이 계속 정리되는 모습이다.
심사 전에 다시 줄인 표면
방향을 바꾼다고 말만 하고 목록을 그대로 두면 아무것도 달라지지 않는다. 그래서 가장 먼저 한 일은 많이 만든 글을 다시 나누는 것이었다. 내가 남기고 싶은 것은 "글이 많다"가 아니라 "대표 글을 고르고, 짧은 메모를 합치고, 검색에 제출할 표면을 설명할 수 있다"는 상태였다.
| 표면 | 그대로 두면 보이는 인상 | 지금 바꾼 판단 |
|---|---|---|
| Blog 목록 | 짧은 작업 메모가 많이 보이고 중심 글이 묻힘 | pillar 3개와 대표 글을 먼저 보이게 둠 |
| Play 제작 메모 | 작은 수정 기록이 각각 독립 글처럼 보임 | Play별 제작 로그로 흡수하고 개별 메모는 archive로 둠 |
| sitemap/feed | 약한 글까지 같은 무게로 제출됨 | 대표 글, category hub, Play, trust page 중심으로 줄임 |
| 검색 결과 | archive 메모가 제목 검색으로 다시 튀어나올 수 있음 | noindex 글은 목록, category, 기본 검색, 직접 검색에서 빼도록 확인함 |
| 개별 archive URL | 직접 열면 대표 글처럼 오해될 수 있음 | `제작 메모 보관` 표시와 noindex 메타를 같이 확인함 |
이 표면 정리는 통과를 위한 꾸밈보다 실제 사용자 경험에 더 가깝다. 처음 온 사람은 내 git 기록이나 frontmatter를 보지 않는다. 홈, Blog 목록, Play detail, 관련 글, sitemap에 남은 URL을 보고 판단한다. 그래서 짧은 메모를 삭제하지 않더라도, 앞에 세울 글과 뒤에 보관할 글을 분리해야 했다.
대표 글에 남길 최소 증거
대표 글을 고를 때 단어 수만 보지는 않았다. 길어도 빈 글이 있고, 짧아도 중요한 결정이 있다. 그래도 검색에 제출하고 첫 목록에 둘 글이라면 최소한 아래 중 몇 가지는 보여야 한다.
| 증거 | 왜 필요한가 | 이 사이트에서 확인한 예 |
|---|---|---|
| 제작 판단 | 단순 감상이나 키워드 글이 아니라 실제 선택이 보인다 | 로그인, 랭킹, 댓글을 미루고 정적 Play와 결과 링크부터 둔 결정 |
| 화면 기준 | 글이 실제 페이지와 연결된다 | 홈 pillar, `/blog` 대표 목록, Play detail의 관련 글 링크 |
| 검증 기록 | 배포 후 무엇을 봤는지 남는다 | route smoke, sitemap/feed count, robots noindex, Search Console 관찰 분리 |
| 흡수 기록 | 짧은 글을 숨긴 이유가 설명된다 | password-lock, ten-box-rush, notification-mole 같은 제작 로그 |
| 남은 기다림 | 아직 증명되지 않은 외부 상태를 과장하지 않는다 | discovered pages, 실제 색인, 노출, 클릭을 따로 본다 |
이 기준을 세우니 글을 더 쓰는 것보다 먼저 해야 할 일이 보였다. 이미 있는 대표 글을 더 두껍게 만들고, 짧은 글은 같은 Play의 판단 안으로 접고, 외부 도구에서 아직 확인되지 않은 상태는 기다림으로 남긴다. 이 편이 느리지만, 나중에 누가 봐도 "이 사이트는 실제로 정리 중이다"라고 말할 근거가 된다.
도구를 버린 것은 아니다
도구를 archive로 내렸다고 해서 버린 것은 아니다. `/tools`는 여전히 중요하다. 글을 읽다가 JSON을 정리해야 할 수도 있고, DNS 상태를 확인해야 할 수도 있고, JWT를 열어봐야 할 수도 있다. 다만 도구는 "사이트의 전부"가 아니라 "작업 중 필요할 때 쓰는 보조 표면"으로 둔다.
이렇게 역할을 나누면 우선순위도 달라진다. 새 도구를 무작정 늘리는 것보다, 기존 핵심 도구의 결과 요약, 경고, 복사 전 체크, 관련 다음 행동을 채우는 편이 낫다. Blog + Play도 마찬가지다. 글 개수를 계속 늘리는 것보다, 대표 글과 제작 로그를 더 깊게 만드는 편이 낫다.
지금 기준으로 남긴 체크
- - 홈에서 Blog + Play가 먼저 보이는지 확인한다.
- - `/blog`에는 대표 글만 많이 보이도록 둔다.
- - 짧은 제작 메모는 Play별 제작 로그로 묶는다.
- - `/sitemaps/en`은 대표 글, category hub, Play, trust 성격의 핵심 페이지 중심으로 줄인다.
- - Search Console에서 sitemap 제출 성공과 실제 색인, 노출, 클릭을 분리해서 본다.
- - 바로 재신청하거나 바로 결론 내리지 않고 며칠 관찰한다.
이 방향은 느리다. 하지만 적어도 내가 직접 만든 글과 Play가 중심에 남는다. bobob.app은 거대한 도구 포털이 아니라, 계속 만들고 고치고 적는 작은 작업장에 가깝다. 지금은 그 정체성이 더 중요하다.
이번 전환에서 실제로 확인한 장면
마지막으로 내가 직접 다시 보는 장면을 적어둔다. 이 장면들이 맞아야 방향 전환이 말이 아니라 화면에 남는다.
- - 홈 첫 화면에서 세 pillar 글이 보이고, 오래된 도구 목록이 첫인상을 전부 차지하지 않는지 본다.
- - `/blog`에서 대표 글과 category가 먼저 보이고, 짧은 archive 메모가 긴 목록처럼 밀려나오지 않는지 본다.
- - Play detail에서 관련 Blog가 단순 홍보가 아니라 제작 판단이나 운영 기록으로 이어지는지 본다.
- - `/sitemaps/en`, `/feed.xml`, `/atom.xml`, `/feed.json`이 같은 대표 Blog + Play 세트를 가리키는지 본다.
- - noindex archive 글을 직접 열었을 때 보관 표시가 있고, 목록과 검색에서는 앞으로 나오지 않는지 본다.
- - Search Console에서 sitemap 제출 성공을 색인 성공으로 착각하지 않고, 며칠 뒤 discovered pages와 URL inspection을 따로 본다.
이 체크가 남아 있어야 다음에 마음이 급해졌을 때 같은 실수를 덜 한다. 글 수를 늘리는 쪽으로만 가면 다시 얇아진다. 대표 글을 고르고, 그 글 안에 실제 판단을 남기고, 작게 만든 Play를 연결하는 쪽이 지금 bobob.app에 더 맞다.
바로 해보기
회의 끝낼 단서 찾기는 이 전환을 상징하는 작은 Play다. 글로 "회의를 줄이자"라고 말하는 대신, 사용자가 직접 결정 신호와 소음을 눌러보게 만든다. 이런 식으로 글 하나가 작은 상호작용으로 이어질 때, 이 사이트가 단순한 도구 목록이 아니라는 점이 조금 더 분명해진다.
읽고 나서 해볼 것