[기술블로그 개발기] 2. 블로그 개발 목표 및 기획

young_pallete·2024년 5월 7일
0

블로그개발

목록 보기
2/2
post-custom-banner

기술블로그 목표 및 기획

서론

본격적으로 일단 기술블로그를 어떠한 방식으로 운영하면 좋은지에 대해 고민해보고자 한다.
(velog에서 새로운 기술블로그를 개발한다는 이야기를 하니, 꽤 머쓱하기도 하다 🤣)

요새 항상 다른 사람들의 글들을 많이 참고하는 편인데, 가장 와닿았던 말은 다음과 같다.

현재 우리가 좋다고 생각하는 서비스는 이전의 서비스들의 단점들을 합산한 것이다.

따라서 이번 기획은, 내가 블로그를 쓰면서, 느꼈던 장점과 단점들을 어떻게 develop할 건지에 초점을 맞추고자 한다.

본론

velog에서 좋다고 생각했던 점들

장점 1. 시리즈

나는 여러 콘텐츠들을 볼 때, 시리즈 물들을 좋아한다.
어려운 고민은 여러 번 생각을 되뇌어야 실마리를 풀어낼 수 있듯, 시리즈 형식의 콘텐츠는 누군가의 무거운 고민을 양과 질이 높은 방식으로 해결했다고 생각하기 때문이다.

velog는 이러한 사람들의 니즈를 충족하는 시리즈 기능이 있다.
이는 그대로 살릴 것 같다.

장점 2. 목차

처음에 velog를 볼 때 가장 마음에 들었던 부분이다.
목차를 통해 간략하게 이 콘텐츠가 이야기를 풀어나가는 부분들을 알 수 있고, 빠르게 필요한 부분을 살펴나갈 수 있다.

아마 개발을 할 때에도 이러한 빠르게 훑어볼 수 있는 기능은 중점으로 풀어내지 않을까.

단점

단점 1. SEO

나의 최근 가장 많은 관심사는 SEO였다.
기본적으로 개발자는 비즈니스를 생각해야 한다고 생각하는 편이다.
우리가 개발하는 이유는, 궁극적으로 개발을 통해 비즈니스 가치를 높이기 위함이라 생각하기 때문이다.

그런 관점에서, SEO를 많이 관심 가지기도 했고, 최근에는 회사에서 SEO 프로젝트를 총괄하고 있기도 해선지 요새 이쪽에 눈을 많이 들이고 있다.

그런데 아쉽게도 내가 애정하며 사용하는 velog에서는 이러한 부분이 좀 아쉽지 않았나 싶다.

예컨대 다음과 같다.

1-1. h1에 대한 제어 미비

논리적으로 한 문서 당 h1은 하나만 존재해야 한다.
(* 실제로 이를 지키지 않아도 보이는 것에서 별다른 문제는 없지만, 논리적으로는 그렇다)

나 역시 SEO를 잘 몰랐던 당시, h1을 남발하면서 포스트를 쓰는 바람에(...),
조만간 이전에 썼던 글들의 내용을 수정할 겸, 모두 다 업데이트할 예정이다.

더군다나 h 태그의 크기가 과연 온전히 콘텐츠들에 대한 계층적 배치를 다 담을 수 있을까 싶다.
현재 velog의 h 태그는 헤딩의 계층 크기에 따라 폰트 크기도 커지는 구조인데, h5부터는 기본 텍스트보다 작아진다. 좀 더 세부적인 계층 부분 역시 잘 컨트롤 할 수 있는 방법을 생각해야겠다.

1-2. 일부 시멘틱 태그에 대한 기능이 약하다.

간단히 말하자면, 검색엔진마다 좋아하는 콘텐츠 양식과 태그들이 분명 존재한다. 이에 반해 velog는 특정 키워드 검색 우선순위를 높이기 위한 시멘틱 태그 (table) 등에 대한 지원이 약하다. 이에 관해서는 나중에 별도로 콘텐츠를 만들까 생각 중이다.

단점 2. 패키지 버전

나는 글을 볼 때, 패키지 버전을 중요시한다. 이슈트래킹을 할 때 패키지가 어떤 버전에서 있는지에 따라서 이 글을 보아야 하나 말아야 하나를 결정하는 편이기 때문이다.

여태까지 수많은 글들을 보았지만, 패키지 버전의 경우 잘 써준 글들을 보면 정말 고마웠지만, 실제로 많은 글들은 쓰여져 있지 않다. 이럴 때에는 대충 몇 년도에 써진 글인지 보고 '아, 이때 쓰여진 글이겠구나' 추측한다.

이왕이면, 버전까지 기술하는 것이 좋은 콘텐츠이지 않을까 고민하면서, 이 역시 추가해보려 한다. 방식은 아직 고민 중이다.

단점 3. 콘텐츠 수정 시점을 알 수 없음

우리가 접하는 많은 블로그들은 웬만한 글들 모두 어떤 버전에서 썼는지, 어떻게 수정이 일어났는지, 왜 수정을 했는지에 대한 이유를 알 수 없다.

즉, 사용자에게는 편하지만, 독자에게는 불편한 UX로 전개되어 있다고 생각한다.
하지만, 과연 사용자에게도 편할지는 의문이다. 내 변경에 관한 history가 전혀 제어되지 않기 때문이다.

약간 confluence와 같이, 왜 업데이트를 진행했는지 등을 정리할 수 있도록 하고 싶다.

단점 4. 세부 커스터마이징에 대한 고민

아직 이는 내가 많이 찾지 못해서일 수도 있지만, 세부적인 설정들을 내가 직접 하지 못하고 시스템에 의존해야 한다는 점 역시 다소 아쉽다.

물론 너무나 간편하고, 좋은 블로그 시스템이기는 하지만, 나는 좀 더 욕심이 드는 게 사실이다.
콘텐츠를 발행했으면 RSS를 통해 구독자들에게 뿌린다던지, 메타 태그에 대한 세부적인 설정이라던지.
좀 더 시스템에 의존하지 않고, 내 의도에 맞게 콘텐츠를 만들고 싶다.

wrong meta description example

예컨대 velog의 경우 초기 콘텐츠 몇 자 이상까지는 절대 마크다운 형식을 쓰지 않아야 하는 시스템이다. 해당 콘텐츠가 날 것 그대로 description에 반영되기 때문이다.

결국 이런 것들에 대한 하나하나의 러닝커브를 따지다 보면, 만드는 것과 비슷할 것 같아서 제작해보려 한다.

주요기능

따라서 블로그를 개발할 시 반드시 있어야 할, 최소 기능은 다음과 같이 설정하려 한다.

  1. (당연하게도) 블로그 목록 / 상세 조회 기능
  2. 블로그 포스트 시리즈 조회 기능
  3. 목차를 통한 탐색 기능
  4. 작성된 기술 포스트의 패키지 버전 열거 기능
  5. 업데이트 이력 및 변경 내역 조회 기능
  6. 표준에 맞는, 시멘틱한 레이아웃 구성 및 RSS 피드 자동 업데이트 등 강력한 SEO 지원

일단 두루뭉실하게 기능을 작성해보기는 했는데, 이는 함께 할 팀원 분들과 좀 더 이야기해보아야겠다. 사이드 프로젝트와 더불어 병행할 거라, 5월은 여러모로 바쁜 달이 될 것 같다. 🙇🏻‍♂️

profile
People are scared of falling to the bottom but born from there. What they've lost is nth. 😉
post-custom-banner

0개의 댓글