블로그를 직접 만들면 얻는 것과 잃는 것 — 내 블로그 vs velog

블로그·웹 만들기 2026-07-26 13:46:48 veloggithub-pagesastrossg

글 목록 →

플랫폼 비교는 일반론으로도 할 수 있지만, 직접 만든 블로그가 하나 있으면 실측이 가능해진다. 이 글은 그 실측 기록이다. 대상은 GitHub Pages 위에 Astro SSG로 지은 이 블로그 — 글은 마크다운 파일로 쓰고 git push로 배포하는 구조다. 비교군은 한국 개발자 블로그의 기본값인 velog. 결론부터 말하면 이렇다. 직접 구축은 사이트라는 제품(product)의 제어권을 가져가고, 독자를 데려오는 힘(distribution)은 velog가 가져간다. 어느 쪽이 나은가가 아니라, 무엇을 얻고 무엇을 포기하는지의 문제다.

얻는 것 1 — 디자인이 ‘내 것’이 된다

velog의 강점이자 약점은 모든 블로그가 똑같이 생겼다는 것이다. 직접 만들면 이게 뒤집힌다. 이 블로그는 단일 액센트 컬러와 카테고리별 색상, 타이포그래피 규칙을 담은 자체 디자인 시스템을 CSS 한 벌로 갖고 있고, 플랫폼 블로그에는 있을 수 없는 화면을 만들 수 있다. 예를 들어 —

  • 아카이브 그래프: git 네트워크 그래프처럼 카테고리를 트렁크로, 글 사이의 후속 관계를 곡선 간선으로 그린 인터랙티브 화면. 글의 계보가 한눈에 보인다.
  • 발행 히트맵: GitHub 잔디 스타일로 매일 발행 스트릭을 시각화.
  • 워크플로 다이어그램: 발행 파이프라인을 궤도 애니메이션으로 표현한 소개 화면.

이런 건 기능이라기보다 정체성이다. 플랫폼 위에서는 글만 내 것이지만, 직접 만들면 화면 자체가 포트폴리오가 된다.

얻는 것 2 — 읽기 경험을 끝까지 제어한다

읽기 경험은 직접 구축이 플랫폼을 이길 수 있는 대표 영역이다. 본문 폭과 행간을 한글에 맞게 조정하고(line-height 넉넉하게, word-break: keep-all), 코드 블록은 Shiki로 라이트·다크 듀얼 테마에 언어 라벨과 복사 버튼까지 붙이고, 목차는 스크롤스파이로 현재 위치를 따라온다. 다크모드도 순검정·순백 대신 눈부심을 줄인 톤으로 직접 고른다. 하나하나는 작지만, 전부 합치면 “플랫폼 기본값”과는 다른 밀도가 나온다.

얻는 것 3 — 기능은 생각보다 다 만들 수 있다

“직접 만들면 기능이 부족하지 않나”는 걱정은 절반만 맞다. 정적 사이트라도 붙일 수 있는 게 많다.

기능이 블로그velog
마크다운 글쓰기O 파일+gitO 웹 에디터
목차+스크롤스파이OO
댓글O giscusO
검색O 클라이언트 모달O
관련 글 추천O 태그 스코어링△ 시리즈
RSS·사이트맵O
SEO 메타(JSON-LD)O 글마다△ 자동
다크모드OO

댓글은 giscus(GitHub Discussions 기반)로, 검색은 빌드 때 만든 JSON 인덱스로, 관련 글은 태그 겹침 점수로 — 전부 서버 없이 해결된다. 정적 사이트의 “동적 기능 없음”이라는 약점은 이런 우회로로 대부분 메워진다.

잃는 것 — 그리고 이건 구현으로 못 메운다

문제는 여기부터다. 아래 항목들은 “아직 안 만든 것”이 아니라 1인 정적 사이트라 구조적으로 없는 것이다.

독자 유입. 가장 큰 격차다. velog는 트렌딩·피드·팔로우 덕에 가만히 있어도 개발자 독자가 흘러들어온다. 직접 만든 사이트는 0에서 시작한다 — 홍보하지 않으면 아무도 오지 않는다. 기능 표에서 아무리 이겨도, 이 한 줄이 실제 조회수를 결정한다.

즉흥적 글쓰기. velog는 브라우저에서 바로 쓰고 이미지를 드래그해 올린다. 마크다운+git 워크플로는 개발자에겐 오히려 장점일 수 있지만, 폰에서 떠오른 생각을 바로 올리는 용도로는 명백히 불편하다.

통계. 조회수·유입 경로를 보여주는 대시보드가 기본으로는 없다. 이건 넷 중 가장 메우기 쉬운 항목이긴 하다 — GA4나 Plausible 같은 애널리틱스를 붙이면 된다.

유지보수. velog는 무료에 무관리다. 직접 만든 블로그는 내가 계속 고쳐야 하는 코드베이스다. 다만 이건 관점에 따라 비용이 아니라 목적이다 — 애초에 웹 기술을 배우려고 짓는 거라면, 유지보수가 곧 커리큘럼이다.

격차를 좁히는 현실적인 순서

직접 구축을 골랐다면, distribution 격차는 이렇게 좁혀갈 수 있다. 노력 대비 효과 순이다.

  1. 애널리틱스 연결 — GA4나 Plausible을 붙이면 조회수·유입 경로가 보인다. 가장 싸게 메워지는 격차다.
  2. RSS·사이트맵 정비 — 검색 엔진과 피드 리더가 새 글을 알아서 가져가게 만드는 기본 유입 경로다. 정적 사이트에서도 빌드 시점에 생성할 수 있다.
  3. 유입 채널 만들기 — 글마다 커뮤니티 공유, 또는 velog에 교차 게시하면서 canonical URL을 내 사이트로 지정하는 방법. 플랫폼의 유입을 빌리면서 검색 권위는 내 도메인에 쌓는 절충안이다.

정리

직접 만든 블로그는 “플랫폼 위에 얹은 글”이 아니라 “직접 만든 제품”이다. 디자인·읽기 경험·기능의 제어권은 확실히 얻는다. 대신 velog가 공짜로 주던 독자·편의·무관리를 스스로 조달해야 한다. 이 트레이드오프를 알고 시작하면 후회가 없다 — product를 만드는 재미로 시작하되, distribution은 별도의 일이라는 것을 처음부터 계산에 넣는 것. 그게 직접 구축파가 velog파에게 배워야 할 한 가지다.

댓글

이 글에 대한 의견은 아래 댓글로 남겨주세요 (GitHub 계정 필요). 로그인 없이 남기고 싶다면