목차
블로그 댓글을 만들 때 선택지는 많다. 직접 테이블을 만들 수도 있고, 외부 댓글 서비스를 붙일 수도 있다. 이 블로그에서는 개발 글을 읽는 사람이 GitHub 계정을 갖고 있을 가능성이 높았고, 댓글의 원본도 공개적으로 남기고 싶었다. 그래서 giscus를 골랐다.
Giscus는 GitHub Discussions를 댓글 저장소로 사용한다. 화면에서는 블로그 댓글처럼 보이지만, 실제 대화는 레포의 Discussions에 남는다.
댓글 데이터를 따로 관리하지 않았다
이 방식의 장점은 댓글을 위한 별도 사용자 시스템과 데이터베이스가 필요 없다는 점이다. GitHub 로그인을 그대로 쓰고, 답글·알림·관리도 GitHub의 익숙한 흐름을 따른다.
대신 전제가 있다.
- 대상 레포가 공개 상태여야 한다.
- GitHub Discussions가 활성화돼 있어야 한다.
- giscus GitHub App을 설치해야 한다.
- 댓글을 담을 Discussion 카테고리를 만들어야 한다.
이 준비가 끝나면 giscus가 알려주는 레포 ID와 카테고리 ID를 환경 변수로 넣는다.
글마다 같은 댓글방을 보지 않게 했다
이 블로그는 mapping="pathname"을 사용한다. 즉 /blog/a와 /blog/b는 다른 Discussion에 연결된다. 제목으로 연결하면 글 제목을 바꿀 때 기준이 흔들릴 수 있어서, URL 경로를 식별자로 택했다. strict="1"도 함께 켜서 느슨한 경로 매칭을 피했다.
댓글 입력창은 위에 두고, GitHub reactions도 사용한다. 테마는 사이트의 라이트/다크 모드에 맞춰 바꾸며, 로케일도 현재 사이트 언어를 전달한다. 긴 글을 읽는 순간에 바로 불러올 필요가 없으므로 loading="lazy"로 둔다.
설정 전에도 읽기 페이지는 그대로 열려야 했다
외부 서비스는 환경 변수와 계정 설정이 끝나기 전까지 준비 중인 시간이 있다. 그래서 글 페이지가 giscus에 직접 의존하지 않도록 경계 컴포넌트를 뒀다.
NEXT_PUBLIC_GISCUS_REPO, 레포 ID, 카테고리 ID가 모두 있을 때만 실제 giscus 컴포넌트를 렌더한다. 하나라도 빠져 있으면 댓글 영역은 “곧 제공” 안내로 바뀐다. 글을 읽는 경험은 댓글 설정의 완성 여부와 무관하게 유지된다.
이 선택이 맞는 범위
giscus는 모든 방문자에게 가장 쉬운 댓글 시스템은 아니다. GitHub 계정이 필요하기 때문이다. 그래서 이 블로그에는 GitHub 계정이 없어도 남길 수 있는 Supabase 방명록을 따로 뒀다.
둘은 경쟁 기능이 아니다.
- giscus: 개발 글에 대한 맥락 있는 대화
- 방명록: 포트폴리오를 본 사람이 남기는 짧은 인사와 피드백
댓글 기능을 만들 때 먼저 정해야 했던 것도 라이브러리가 아니라, 누가 어떤 방식으로 말을 남기게 할 것인가였다.