블로그에 댓글이 필요한가, 라는 질문을 먼저 해야 했다. 2026년에 블로그 댓글은 구시대의 유물이라는 시각도 있다. X에 링크를 던지면 거기서 토론이 일어나고, Reddit에 올리면 서브레딧에서 논쟁이 벌어진다. 굳이 블로그 본문 아래에 댓글 창을 둘 이유가 있을까?

있다고 결론 내렸다.

글 바로 아래에서 일어나는 대화

SNS에서의 토론은 금방 흩어진다. 3일 뒤에 누군가 그 글을 읽으면, 관련 논의를 찾으려고 X를 뒤져야 한다. 글과 그 글에 대한 반응이 물리적으로 같은 장소에 있어야 한다는 건, 블로그라는 매체의 오래된 장점이다.

기술 블로그는 특히 그렇다. "이 방법보다 저게 낫다", "우리 팀은 이렇게 해결했다" 같은 피드백은 본문만큼이나 값지다. 그래서 댓글은 넣기로 했다. 문제는 어떻게.

Disqus의 시대는 끝났다

블로그 댓글 하면 제일 먼저 떠오르는 이름이 Disqus다. 2012년쯤에는 모든 워드프레스 블로그에 달려 있었다. 지금은 상황이 다르다.

무료 플랜을 쓰면 광고가 강제로 삽입된다. 남의 블로그 하단에 "Sponsored" 딱지 달린 클릭베이트 링크가 주렁주렁 달린 걸 본 적 있을 텐데, 그게 무료의 대가다. Postlark 사용자의 블로그에 그런 광고가 뜨는 건 용납할 수 없었다.

프라이버시 문제도 크다. Disqus는 상당량의 서드파티 트래커를 심는다. 우리가 "JS 없이도 돌아가는 블로그"를 지향하는 플랫폼인데, 댓글 하나 때문에 트래커를 잔뜩 불러오면 앞뒤가 안 맞는다. 사용자에게 "프라이버시를 존중합니다"라고 말해놓고 뒤에서 Disqus가 데이터를 수집하고 있으면 그건 거짓말이다.

utterances — 가까웠지만

giscus 전에 utterances라는 선택지가 있었다. GitHub Issues를 백엔드로 쓰는 오픈소스 댓글 위젯으로, 한때 개발자 블로그에서 꽤 인기 있었다.

문제는 유지보수가 사실상 멈췄다는 거다. 그리고 좀 더 근본적으로, GitHub Issues는 이슈 트래킹용이지 토론용이 아니다. 댓글이 이슈로 쌓이면 실제 프로젝트 이슈와 섞여서 난잡해진다. 개인 블로그 하나에 쓰는 거라면 상관없겠지만, 플랫폼으로서 수백 개 블로그에 권장할 만한 구조는 아니었다.

giscus가 남은 이유

giscus는 utterances의 후속 프로젝트 같은 포지션이다. 가장 큰 차이는 GitHub Discussions를 백엔드로 쓴다는 점. Discussions는 애초에 토론을 위해 설계된 공간이니까, 댓글 저장소로 쓰는 게 의미적으로 맞다.

조건을 나열하면 이렇다:

  • 무료 — 완전 무료, 숨겨진 요금 없음

  • 오픈소스 — 코드를 직접 확인할 수 있다

  • 광고 없음 — 무료인데 광고도 없다

  • 트래커 없음 — 사용자 데이터를 수집하지 않는다

네 가지를 동시에 만족하는 댓글 솔루션이 giscus 말고 뭐가 있는지 모르겠다.

단점은 하나다. 댓글을 달려면 GitHub 계정이 필요하다. 일반 블로그였으면 치명적일 수 있다. 하지만 Postlark 사용자는 개발자와 인디해커다. GitHub 계정이 없는 개발자를 찾는 게 더 어렵다. 이 제약은 동시에 스팸 방어막이기도 하다. GitHub 계정을 새로 만들어가면서 스팸 댓글을 다는 사람은 극소수다. 별도의 스팸 필터링 없이도 댓글 품질이 유지된다는 뜻이다.

정적 페이지에 동적 위젯을 얹는 긴장감

Postlark 블로그 페이지는 기본적으로 JavaScript가 없다. 순수 HTML과 CSS만으로 렌더링된다. 빠르고, 가볍고, 접근성도 좋다.

댓글은 여기에 예외를 만든다. 사용자 생성 콘텐츠는 본질적으로 동적이다. 아직 작성되지 않은 미래의 댓글을 정적 HTML로 렌더링할 방법은 없으니까.

giscus script 하나가 추가되는 건 받아들였다. 대신 조건을 걸었다. 블로거가 대시보드에서 giscus 연동 설정을 직접 입력한 경우에만 script가 HTML에 포함된다. 설정을 안 하면 댓글 영역 자체가 존재하지 않는다. 0바이트 그대로.

다크 모드 대응도 giscus 자체 기능으로 해결된다. 시스템 테마 설정을 따라가도록 옵션 하나만 지정하면 위젯 색상이 자동으로 바뀐다. 이건 따로 코드를 쓸 필요가 없어서 좋았다. 외부 위젯을 붙일 때 가장 걱정되는 게 "내 테마랑 안 어울리면 어쩌지"인데, 이 부분이 깔끔하게 처리된다.

직접 만드는 건 나중의 나에게

댓글 시스템을 자체 구축하는 건 기술적으로 어려운 일이 아니다. 테이블 하나, 입력 폼 하나, 스팸 방지 CAPTCHA 하나. 그러나 "어렵지 않다"와 "지금 해야 한다"는 다른 문제다.

1인 개발에서 자원은 유한하다. giscus가 잘 동작하는데 같은 기능을 다시 만드는 건 시간 낭비다. 비개발자 사용자가 늘어나서 "GitHub 계정 없이도 댓글을 달고 싶다"는 요청이 쌓이면, 그때 이메일과 이름만으로 작성할 수 있는 자체 시스템을 만들 생각이다. giscus와 자체 시스템 중 블로거가 선택하는 구조까지가 장기 로드맵에 들어 있다.

지금은 giscus로 충분하다. "충분하다"는 판단을 빠르게 내리고 다음 문제로 넘어갈 수 있는 것. 그게 외부 오픈소스를 쓰는 진짜 이유다.