Tech

스터디 아카이브 사이트 만들기

스터디에서 쌓인 글을 모아 둘 아카이브 사이트를 만들며 남긴 기록

스터디를 시작한 지 어느덧 7달이 되었다. 3월부터 매달 스터디를 진행하며 각자 블로그 글 하나씩을 산출물로 만들기로 했고, 네 명이 이어오다 보니 20여 개의 글이 쌓였다.

그런데 글이 쌓일수록 한곳에 모이지 않는다는 점이 걸렸다. 각자 블로그를 관리하는 방식이 다르니 어떤 글이 몇 회차에 나온 건지, 누가 어떤 주제를 다뤘는지 한눈에 보이지 않았다. 스터디의 결과물이 네 갈래로 흩어져 있는 셈이었다.

그리하여 사이드 프로젝트 경연대회가 열렸다. 우리의 블로그 포스트 링크를 한데 모아 보여 주는 아카이브 사이트를 만드는 것이었다.

간단한 사이트인 만큼 깊게 고민하기보다 결과물로 판단하자는 의견이 주를 이루었고, 다들 부담 없이 만들 수 있도록 바이브 코딩으로 진행하게 되었다.

핵심 가치

만들기 전에 이 사이트가 무엇을 위한 것인지부터 정했다. 기능을 떠올리다 보면 끝이 없는데, 판단 기준이 없으면 있으면 좋은 것들을 계속 붙이게 된다고 생각했다.

내가 생각한 핵심 가치는 세 가지였다.

  • 각자 블로그로의 유입
  • 쉬운 탐색
  • 특색 있는 기능

가장 기본이 되는 건 각자 블로그로의 유입이라고 봤다. 링크 목록을 모아 두는 게 목적이 아니라, 그 글을 실제로 읽게 만드는 게 목적이기 때문이다. 그다음으로는 사이트 안에서 원하는 주제를 찾기 쉬워야 한다고 생각했다. 20개가 넘어가는 순간부터는 목록을 훑는 것만으로 원하는 글을 찾기 어려워진다. 마지막으로 1등을 하려면 특색 있는 기능이 필요했다.

이후의 모든 결정은 이 세 가지 중 무엇에 기여하는지로 판단했다.

개발 방식

바이브 코딩으로 사이드 프로젝트를 만든 건 처음이 아니었다. 요즘은 꽤 잘 만들어 주지만, 원하는 수준의 품질을 뽑으려면 간단한 사전 작업이 필요했다.

  1. 기술 스택 지정
  2. 사이트가 예뻐 보이도록 디자인 시스템 구성 — 간격, 폰트, 색상
  3. 여러 시안을 만들게 하고 그중에서 골라 나가는 형태

기술 스택을 먼저 못 박아 두면 중간에 구조가 흔들리는 일이 줄었다. 디자인 시스템을 미리 잡아 둔 이유는, 화면마다 그때그때 값을 정하게 두면 간격과 색이 제각각이 되어 결국 다시 손봐야 했기 때문이다. 간격·폰트·색상만 정해 두어도 완성도가 눈에 띄게 달라졌다.

가장 효과가 좋았던 건 세 번째다. 원하는 화면을 말로 설명하는 것보다, 여러 시안을 만들게 한 뒤 그중에서 고르는 편이 훨씬 빨랐다. 내가 원하는 게 뭔지는 보고 나서야 알게 되는 경우가 많았다.

이렇게 만든 결과물이 프론트엔드 아카이브다.

핵심 가치를 어떻게 구현했나

각자 블로그로의 유입

블로그로 유입시키려면 SEO가 가장 중요하다고 생각했고, 이 사이트 자체가 검색에 노출되어 유입을 견인해야 한다고 봤다.

그래서 처음에는 한 페이지로 구성할까 하다가 분류별 페이지를 여럿 두는 쪽으로 바꿨다. 한 페이지짜리 사이트는 검색엔진에 걸릴 표면적이 그 페이지 하나뿐이다. 반대로 태그·멤버·회차·주제마다 페이지를 두면 그만큼 색인될 입구가 늘어난다.

가장 공을 들인 건 상세페이지다. 링크만 덩그러니 있으면 클릭할 이유가 없다고 생각해서, 원문의 앞부분을 긁어와 흥미가 생기면 원글까지 이어서 읽게 만드는 구성으로 짰다.

쉬운 탐색

태그, 멤버, 회차, 주제별로 탐색할 수 있도록 구성했다. 같은 글이라도 찾아 들어오는 경로가 사람마다 다르다고 봤다. 관심 기술로 찾는 사람, 특정 멤버의 글을 따라 읽는 사람, 이번 회차에 뭘 했는지 보는 사람이 각각 있기 때문이다.

그래서 어느 화면에 있든 어떤 카드를 누르든 거미줄처럼 서로 연결되게 했다. 태그를 누르면 그 태그의 목록으로, 작성자를 누르면 그 사람의 글 목록으로 이어진다. 막다른 길 없이 계속 다음 글로 넘어가게 만드는 것이 목표였다.

특색 있는 기능

두 가지를 넣었다.

첫 번째는 읽은 글 기능이다. 어떤 글을 읽었는지 우측 하단 FAB에서 모아 볼 수 있고, 안 읽은 글만 골라 볼 수도 있다. 아카이브는 한 번 보고 끝나는 사이트가 아니라 다시 찾아오는 사이트라고 생각했고, 그렇다면 어디까지 읽었는지를 사이트가 기억해 주는 게 맞다고 봤다.

두 번째는 쉬운 입력이다. 블로그 링크만 저장하는 저장소가 따로 있는데, 새 글이 나올 때마다 마크다운 형식에 맞춰 직접 입력해야 했다. 형식을 하나만 틀려도 깨지고, 저장소를 열어 편집하고 커밋하는 과정 자체가 번거로워 보였다. 그래서 사이트 안에서 그 마크다운 저장소를 바로 수정할 수 있는 기능을 추가했다.

성과

sitemap 기준으로 총 71개의 페이지가 만들어졌고, 검색엔진에도 많이 올라갔다.

그리고 투표 결과 1등으로 선정되었다.

앞으로의 계획

추가하고 싶은 기능이 세 가지 정도 있다.

첫째는 조회수 체크 기능이다. 어떤 글이 실제로 읽히는지 알 수 있어야 유입이라는 가치가 달성되고 있는지 확인할 수 있다.

둘째는 AI API를 붙여, 상세페이지에서 원문 앞부분을 긁어오는 대신 요약을 보여 주는 것이다. 앞부분은 도입부일 뿐이라 글의 핵심이 뭔지는 알려 주지 못한다.

셋째는 번역이다. 영어 번역을 추가하면 페이지가 71 * n 이 되지 않을까 생각한다.

느낀점

바이브 코딩으로 만들었지만 결과를 가른 건 코드가 아니었다. 무엇을 위한 사이트인지 먼저 정해 둔 것, 그리고 그 기준으로 매 결정을 판단한 것이 차이를 만들었다고 생각한다.

핵심 가치를 세 가지로 좁혀 두니 이 기능이 유입에 도움이 되는지 물어볼 질문이 분명해졌다. 덕분에 한 페이지로 끝낼 수 있었던 사이트를 71개의 페이지로 끌고 갈 이유도 생겼다.

구현 자체는 점점 더 쉬워지는 시대다. 앞으로 더 중요해지는 건 무엇을 만들지 정하고 그 기준을 끝까지 들고 가는 쪽이라는 생각이 들었다.

이 글이 도움이 되었나요?좋아요는 다음 글을 쓰는 힘이 됩니다

다른 글