작은 사이트를 크게 포장하려다 멈췄던 날

처음엔 이름표부터 붙이고 싶었다

새 사이트를 만들 때 제일 먼저 하고 싶어지는 건 이름표를 크게 붙이는 일이다. 어떤 서비스인지, 어떤 사람을 위한 건지, 왜 필요한지 한 줄로 정리하고 싶다. 그럴듯한 문구를 만들면 뭔가 시작한 느낌도 난다. 근데 이상하게 그 단계가 길어질수록 실제 페이지는 잘 안 늘었다. 문장은 점점 매끈해지는데, 눌러볼 건 그대로였다.

이때 알았다. 아직 별게 없을 때 너무 큰 말부터 붙이면 부담이 커진다. “개발자 생산성을 바꾸는 도구 모음” 같은 말은 멋있지만, 오늘 만든 게 버튼 두 개짜리 화면이면 좀 민망하다. 민망하면 고치면 되는데, 크게 말해버리면 고치기도 어색하다.

처음의 bobob.app도 그랬다. 도구 목록을 크게 보이게 만들고 싶었고, 없는 체계를 있는 것처럼 설명하고 싶었다. 하지만 실제로 매일 만지는 것은 제목, 설명, 라우트, 작은 Play 데이터, sitemap, feed 같은 좁은 표면이었다. 소개 문장은 커졌는데 운영 루틴은 작았다. 그 어긋남이 손을 멈추게 했다.

작은 말이 더 오래 버틴다

그래서 요즘은 문구를 조금 낮게 잡으려고 한다. 완성된 서비스라기보다 만드는 중인 공간. 멋진 선언보다 오늘 뭐라도 올리는 곳. 이렇게 말하면 부족한 화면도 숨기지 않아도 된다. 아니, 부족한 상태 자체가 다음 글감이 된다.

블로그도 마찬가지다. 검색어 하나를 잡고 억지로 글을 쓰는 것보다, 오늘 실제로 막힌 부분을 남기는 쪽이 오래 간다. 완성된 튜토리얼이 아니어도 된다. 이 판단은 틀렸고, 이 설정은 다시 봐야 했고, 이건 생각보다 귀찮았다. 그런 기록이 쌓이면 나중에 사이트의 냄새가 생긴다.

이 표를 만든 뒤에야 조금 편해졌다. 사이트가 작으면 작은 말이 맞다. 작은 말은 도망갈 곳을 남긴다. 다음 주에 방향을 바꿔도 문장이 크게 부서지지 않고, 오늘 새 Play 하나를 붙여도 과장처럼 보이지 않는다.

작게 남기는 운영 단위

처음에는 “사이트 하나”를 한 번에 설명하려고 했다. 지금은 훨씬 작은 단위로 본다. 오늘 공개해도 되는 글 하나, 결과까지 닿는 Play 하나, 목록에서 빠져야 하는 짧은 메모 하나. 이 정도로 쪼개야 다음 날 다시 열었을 때 무엇을 고칠지 보인다.

이 단위로 보면 글을 덜 쓰게 되는 게 아니라, 글을 합칠 이유가 생긴다. 짧은 생각은 그냥 버리지 않는다. 다만 바로 대표 URL로 내보내지 않고, Play 제작 로그나 운영 기록 안에서 맥락을 만든 뒤 공개한다. 작은 사이트가 작아 보이는 문제는 글 수가 적어서가 아니라, 각 글이 어떤 역할인지 모를 때 생긴다.

오늘의 제작 기준

• - 너무 큰 설명을 먼저 붙이지 않기
• - 기능보다 실제로 열린 페이지를 먼저 늘리기
• - 멋있는 말보다 다시 읽어도 부끄럽지 않은 기록 남기기
• - Play는 떠오를 때 만들고, 글은 글대로 쌓기
• - 대표 글은 표, 체크리스트, 제작 판단, 검증 기록 중 하나를 꼭 남기기
• - 짧은 메모는 바로 지우지 말고 archive/noindex 후보로 두기
• - 첫 방문자가 `/blog`와 `/play`만 봐도 누가 계속 만지고 있는지 느끼게 하기

이 정도면 충분하다고 적었지만, 실제로는 충분하지 않은 날이 더 많았다. 부족한 화면을 보면 다시 크게 포장하고 싶어진다. “곧 더 좋아질 예정” 같은 말도 쓰고 싶어진다. 그런데 그런 말은 방문자에게 별 도움이 안 된다. 차라리 지금 열린 페이지가 무엇이고, 다음에 무엇을 뺄지 적는 편이 낫다.

목록에서 보일 때 다시 읽는 것

글을 쓸 때보다 `/blog` 목록에서 볼 때 더 잘 보이는 문제가 있다. 제목이 너무 큰지, 설명이 본문보다 앞서 나가는지, 같은 이야기가 다른 날짜로 반복되는지, 관련 Play가 억지로 붙어 있는지 같은 것들이다. 편집 화면에서는 괜찮아 보여도 목록에 놓으면 금방 드러난다.

그래서 대표 글 후보는 본문만 보지 않는다. 홈의 pillar 영역, `/blog`, category hub, search 결과, feed 제목까지 같이 본다. 그 표면에서 이 글이 “직접 만든 기록”으로 읽히는지 확인한다. 읽히지 않으면 글을 늘리기보다 합치거나 archive로 내리는 편이 낫다.

작은 사이트가 믿음을 얻는 방식

작은 사이트가 믿음을 얻는 방식은 큰 회사의 방식과 다르다. 로고가 크거나 문장이 매끈하다고 믿음이 생기지는 않는다. 오히려 만든 사람이 어떤 기준으로 줄이고, 무엇을 확인하고, 어떤 글을 제출 표면에서 뺐는지가 더 중요해 보인다.

그래서 요즘은 첫 화면에서 모든 걸 말하려 하지 않는다. Blog에는 방향을 바꾼 이유, 정적 Play 구조, 색인 대기 체크리스트 같은 글을 먼저 둔다. Play에는 30초에서 1분 안에 눌러볼 수 있는 작은 화면을 둔다. 도구는 버리지 않고 `/tools`에 남긴다. 이 세 가지가 같이 있으면 적어도 “아무 글이나 찍어낸 사이트”처럼 보일 가능성은 줄어든다.

내가 다시 볼 체크리스트는 이렇다.

• - 오늘 만든 것이 실제 URL로 열린다.
• - 그 URL이 sitemap에 들어가야 하는 글인지, archive로 충분한 글인지 나눴다.
• - 제목과 설명이 본문보다 커 보이지 않는다.
• - 같은 이야기를 다른 날짜로 반복하지 않는다.
• - Play로 이어지는 글은 실제 Play와 서로 연결된다.
• - 운영 기록은 제출 성공과 실제 색인을 섞어 말하지 않는다.

이 기준을 지키면 속도가 느려진다. 그래도 느린 편이 낫다. 글 수를 늘리는 건 쉽고, 나중에 그 글을 다시 줄이는 건 훨씬 힘들다. 처음부터 조금 덜 멋있게 말하고, 조금 더 정확하게 남기는 쪽이 오래 간다.

지금 남기는 결론

아직은 대단한 이름보다 다음 파일 하나가 더 중요하다. 하지만 이제는 그 다음 파일도 아무거나 올리면 안 된다. 방문자가 처음 들어왔을 때 이 사이트가 직접 만든 원본 콘텐츠 중심으로 보이려면, 작은 글도 역할이 있어야 한다. 어떤 글은 대표로 남기고, 어떤 글은 archive에 두고, 어떤 글은 Play 제작 로그 안으로 합친다.

처음부터 거창하게 보이려다 멈췄던 날의 결론은 단순하다. 작게 말하고, 실제로 열리는 것을 만들고, 남길 글과 숨길 글을 나눈다. 그게 지금 bobob.app이 버틸 수 있는 가장 현실적인 시작점이다.